
Mobile Last? - tacon
https://jonathanstark.com/blog/mobile-last
======
forrestthewoods
Totally insane to call mobile free. No, if you spent a whole bunch of time
testing on a bunch of platforms and a whole bunch more time writing things
very carefully to work on a bunch of platforms then you can totally make a
great experience for all of them.

I mean I get it. I also think it's insane to not support mobile. Everyone
should be supporting mobile. Let's just not lie and say it's easy. It's a
bunch of work that everyone should be doing. But it's still work.

~~~
hipsterrific
People often forget that testing cross platform functionality is difficult and
time consuming. It can easily tie down designing and add more constraints than
necessary. This is why I advocate focusing on essentials like usability,
experience, and functionality rather than some gung-ho attitude of "we MUST be
mobile first regardless."

~~~
jonathanstark
I'm not saying everyone must ALWAYS design mobile first. I'm saying it should
be our default position, like doing layout with css instead of tables.

If you have some reason to ignore mobile (and there are many good ones) then
go ahead and make an exception.

My issue with desktop-first in RR is that because of the nature of the
situation, there were no good reasons to make that exception.

------
Daiz
_> When building a site from scratch, the additional effort required to
support a wide range of devices is extremely low._

If all you're doing is designing a simple website (like a blog - not exactly
that complicated), then yes, mobile might not be that hard.

If you're designing a web app though, that's a whole another story. If you
want everything to work properly, from user interface to the actual features
(one could think that cross-browser compatibility is really good these days,
but in practice there's still a surprisingly large amount of places where
things differ and you need to account for it), then that will mean a lot of
testing across browsers and devices, which will increase your development time
_a lot._ Hell, just getting cross-browser compatibility with common up-to-date
desktop browsers is a considerable time investment with web apps.

So with that said, I must agree with the organizer quoted in the post - when
all you have is 48 hours, you can't really blame anyone for not spending the
time making their web app work well on mobile. Hell, I probably wouldn't spend
that much time on cross-browser compatibility either (probably latest Chrome &
Firefox compatibility _at most_ \- and even that can be surprisingly
involving), since the time really is quite limited, and if you end up with
something cool (incidentally, as the blog post says, they didn't win, and
spent time making things mobile & desktop -friendly) then you'll have all the
time in the world to worry about compatibility and making it truly
"production-ready" after the hackathon is over.

EDIT: Not to mention that depending on what kind of web app you're building,
it might not even make that much sense on mobile - generally speaking, you
don't use mobile devices for serious productivity, so if you're building a
serious productivity app, full mobile support could be a waste of time when
no-one would even use it seriously on mobile. If you're storing data server-
side with user accounts, though (as in, your app's not purely client-side),
then you could probably get away with a limited mobile version that only gives
read-only data or something. Of course, this all depends on what exactly
you're building and should be evaluated on a case-by-case basis.

~~~
robertnealan
While I think Jon made it seem a little easier than in reality, as someone who
uses and designs for both mobile/desktop I have to agree that when done right
it's not that much more of a time investment - generally ~10% extra on a full
design/build project. There's a real argument that in a hackathon 10% extra
time isn't worth it, but in the real world where you don't always have 48 hour
time limits I've always been in the opinion that the initial time investment
is far outweighed by the benefits and the additional cost that you would incur
by making it mobile-ready later (which usually requires either rebuilding the
frontend templates from scratch or hacking away at the existing codebase in a
way that is far less organized/sustainable).

As far as the long standing argument of whether building mobile-first or
desktop-first, I honestly think that's up to developer preference so long as
the whole team is building with the same mindset. Building responsive, mobile-
ready sites/applications isn't free, but a lot of web developers/startups seem
to make it out to be much more difficult than it actually is when done
consistently and right.

~~~
Daiz
_> There's a real argument that in a hackathon 10% extra time isn't worth it,
but in the real world where you don't always have 48 hour time limits I've
always been in the opinion that the initial time investment is far outweighed
by the benefits and the additional cost that you would incur by making it
mobile-ready later (which usually requires either rebuilding the frontend
templates from scratch or hacking away at the existing codebase in a way that
is far less organized/sustainable)._

Oh, I completely agree with this. I'd say that even during hackathons, mobile
is definitely something you should keep in mind when you're building your
design, markup, etc. just like you normally would so that things will be
easier in the long run. However, the key thing is that when you hit something
that would be easy to deal with on desktop but hard on mobile, you should just
go the easy desktop route and leave the mobile solution for later (post-
hackathon). And when you're building web apps, those kinds of moments will
pretty much inevitably come because mobile is hard - compared to desktop, you
will generally speaking always have less screen real estate (and input
elements need to be larger, making it even smaller), a lot less processing
power, lack of precise pointer input and hover (touch vs mouse), etc etc.

Again, the point here is the difference between building websites and web
apps. With websites, your biggest concerns are generally that the site scales
nicely to various screen sizes and that links are comfortably clickable (and
that it all looks nice). This wouldn't be all that hard to do even under time
constraints. Web apps on the other hand generally feature a lot more (single-
page) interactivity, and getting that right is a lot harder.

------
izolate
Desktop is dead? I'm not surprised a "mobile software consultant" would say
something so ridiculous.

~~~
api
I visited a place with a "desktop is dead" / "mobile is the next everything"
message a while back. Couldn't help but notice all the desktops. Nobody was
doing their work on a mobile device.

The boat people are totally missing is this: sure, mobile is growing like
crazy, but what we're seeing isn't the death of PC. What we're seeing is the
filling out and explosive diversification of the computing ecosystem. The
future isn't a "next platform," it's a whole ecosystem of devices serving
specialized functions or function domains. For PC that's "personal computing"
\-- doing "big" stuff and "real work." For mobile that's mostly communications
along with navigation, etc., the sort of thing you want an ultraportable
micro-communicator for.

I own a tablet, a smart phone, and a laptop, and of the three the tablet is
probably the one I could do without. The smart phone and the laptop are used
constantly. But the tablet is nice for reading and note taking.

~~~
gphil
This is exactly my feeling as well. I would take a huge productivity hit
without a phone, or without a laptop. I would mostly miss my tablet on plane
rides. I would love to see more data on this though, because I wonder if most
non-HNers feel the same way.

~~~
api
I'd say of the three losing the laptop would be the worst. I would be unable
to do any of my work at all, and the comm functions of the phone could
technically be made up by the laptop and a dumb phone.

Laptop: essential like indoor plumbing

Phone: _very_ useful, major time-saver, but could live without

Tablet: nice for reading but dispensable

Tablets are the only endangered class that I see. They occupy an uncanny
valley: too small and restrictive for what you do on laptops, too big to be as
portable as a smart phone.

------
hipsterrific
I personally make decisions based on what the project requires rather than
some template. Most websites for me are informational, so mobile-first works
well. Not a whole lot of functionality to test so we can focus on building the
website and make it look on any size device.

However, apps are a different ball game. I'd rather focus on usability,
experience, and functionality. I'm not going to try and hobble the app by
trying to beat a round peg into a triangle, square, whatever shaped hole. I
find that most web applications which have large swathes of functionality
benefit from native code, so I usually skip mobile-first design and just do a
native app (Xamarin or Titanium works). Why? Because I don't want to sacrifice
usability, experience, and functionality. Most apps, I've found out, have
different experience, usability, and functionality on difference devices.

~~~
armandososa
You can do great mobile experiences on web, but it does require extra time and
extra thinking. I don't want to download a new app for every new service I
want to try, so I will say that there's still space for really good mobile web
apps.

~~~
hipsterrific
Try and not all web apps should have a mobile web app. But there's are
instances where a productivity app will benefit from having a mobile app than
just a responsive website. I've worked on a couple of web apps that made
mobile-first their paradigm and it sucked. Testing sucked. Dev'ing it sucked.
We had to sacrifice a lot on usability and experience which sucked a lot. A
mobile app would have made more sense than a responsive site. Then again, I
used trulia and having them ask me to download their app was just stupid as
the app provided zero value to me (their responsive site was perfectly fine).

------
armandososa
(Disclaimer: I'm not a native english speaker)

Responsive design, at least when it comes to web applications, is just lazy.
Sure, your layout will totally shrink, but that does not make it "mobile
ready".

The set of UI conventions that work and have worked for a long time on desktop
won't work on tiny touch-enabled screens.

And if you really care for the user experience of those 2 billion mobile
users, you'll have to rethink and redesign every widget and every interaction
for fat,lazy and impatient fingers.

So I have to disagree with the notion that supporting a wide rage of devices
requires an extremely low additional effort. That's simply not the case if you
care about user experience both on mobile _and_ desktop.

I'm guessing that, while on a hackaton, you'll have to choose.

------
untog
Honestly, if you asked these Rumble devs how many of them even tested in
Firefox I think the percentage would be low. Such is the nature of these
events - you move fast. And as the post says, the aim is to make an
"innovative web application", not a "web application that would be delivered
to users in an optimal fashion". It was also a Ruby hackathon - given that
it's a server-side technology I doubt the client presentation form was given
much focus.

I've made this mistake plenty of times before myself. I've dwelled on the the
actual real life issues my concept would face and come away at the end of the
weekend with a well-considered concept. But what people _want_ at these events
is a catchy, flashy demo that wows attendees and that can be
tweeted/Facebooked/etc.

This is part of the reason I don't bother sacrificing my weekend to hackathons
these days, but still. You're optimising for the wrong use case.

~~~
jonathanstark
> But what people want at these events is a catchy, flashy demo that wows
> attendees and that can be tweeted/Facebooked/etc.

And then what? Opened on a mobile phone where the demo doesn't work? Mobile is
where people are reading facebook/twitter so if you want to optimize for
catchy/flashy for sharing in social media, you should _definitely_ focus on
mobile-first.

~~~
untog
You're assuming the tweeted link would go to the app itself - it wouldn't. It
would go to their roundup of the event. These events are not built around
making long-lasting projects.

------
ianlevesque
I just want webview-based mobile apps to support basic platform navigation
conventions like scrolling to top when the top of the screen is tapped. That
one simple gesture immediately outs webview apps 90% of the time. I'll stop
preferring native apps when webapps start offering a benefit to me, the user,
instead of just the developer.

~~~
BenSS
The other one on iOS is edge-dragging to go back/forward in the navigation
stack. Neither of these things is -hard- to implement with current tech
either!

------
ErikRogneby
I wonder if the desktop first attitude at the Rails Rumble had something to do
with when Rails came on the scene? That when people started using Rails
desktop was king and mobile was painful. (wml anyone?)

I would bet that a node.js or a MEAN stack hackathon would have a higher
percentage of mobile friendly results.

~~~
jonathanstark
I too wondered that while writing the post, but I can't think of anything
about Rails that inherently makes the framework desktop-first.

------
PSeitz
I always build mobile-first websites ... and they suck on desktop because they
have vastly different screen sizes. Proper multi device support ist not cheap
or free.

------
PaulHoule
In a short time frame I'd hate to commit to cross device testing.

That said I wonder what the root cause of the incompatibility. Are these
people using a fashionable client side framework that doesn't work on mobile?
Or is there a problen with ror?

I can say lately I have made sites using java on the back end and very simple
front ends (as little is as possible, very simple html, CSS for formatting and
without trying at all these work great on tablets and phones.

~~~
gabemart
I don't think you actually need to do cross-device testing to qualify as
"mobile-friendly" in the context of a 48 hour hackathon. You just need to put
together a view @media rules such that your UI is usable on all sizes of
browser window and insert a meta tag to indicate to mobile browsers they
shouldn't try to emulate higher resolutions.

It's impossible to say how hard this would be without discussing a specific
web app. But if the benchmark is simply "usable" rather than "elegant", I
don't imagine it would be very hard for most web applications.

------
softdev12
First comment, those competitions shouldn't be entered only to "win". the goal
should be to build something useful not to have a few judges pick the idea as
a "win". The percent of successful companies that come from these types of
competitions is absurdly small.

Second comment,Cordova/Phonegap make it really easy to build mobile friendly
apps that can be extended to the desktop web, all in pretty much 1 codebase.

------
ch8230
Why was 'mobile last' a takeaway from a hackathon? Most dev's probably focused
their efforts on the breakpoint they would demo. It is possible that are
indeed doing 'mobile last' but I wouldn't conclude that from a survey of
hackathon projects.

~~~
jonathanstark
Good point about "the screensize they would demo" but in the case of Rails
Rumble, the contestants don't demo their work. The judges browse through them
on their own on whatever device they like.

~~~
ch8230
thanks for clarifying that does open up the need for responsiveness.

------
al2o3cr
Meh. I looked at the winners - many of them wouldn't make a damn bit of sense
as "mobile apps" or even mobile websites.

[http://railsrumble.com/entries/winners](http://railsrumble.com/entries/winners)

~~~
jonathanstark
I strongly disagree.

------
kevinSuttle
Had a similar sentiment earlier this year.

[http://kevinsuttle.com/posts/the-right-questions-to-ask-
mobi...](http://kevinsuttle.com/posts/the-right-questions-to-ask-mobile-first-
deniers)

------
bjacobel
As long as we're talking about mobile usability - why is this site's font huge
on desktop, then get smaller as you reduce the viewport?

