One of Luke's key tenets on Mobile First is about how smaller screen sizes force you to focus your messages -- and lack of focus is a huge issue for most Web sites.
Fred seems to be coming at it from a slightly different angle, but I think it's important to include Luke's ideas here in the discussion... it's how designers and UI experts think about the term "Mobile First".
Yes, and the OP is also using the term "Mobile First" differently than my own sense of it.
To me, Mobile First means developing websites targeted at smartphone screens first, that scale gracefully upward to desktop size. The 320andup boilerplate is a good example [1].
I see it also means a more general business strategy of focusing on your mobile app first, be it native or HTML5, and then your website. But could be some mixed messaging due to the multiple meanings of that term.
From a UX perspective I think you're at an innovation disadvantage if you launch today without a touch-focused UI. Its a somewhat trivial leap to go from mobile UX to desktop, but much harder the other way around.
Desktop focused products have been making slow and really clumsy forays into mobile but I've yet to see a mobile product translate poorly onto desktop...
I agree with this. Mobile first doesn't necessarily mean native first. From both design and engineering perspectives, it is much easier to build a website that looks good on both mobile and desktop and then add components to the desktop site than it is to start with a desktop site and pare it down to work well on mobile.
This is how we view the "mobile first" movement - not in terms of first developing a mobile version and then working out later how to turn it into a desktop site, but instead using the laser-like focus that "mobile" requires to properly identify and prioritize your goals.
It's much more about getting your design requirements listed in order of importance - if you spend the time thinking about questions like "if I have to fit this product/site/app onto a 4inch diagonal screen, what are the absolutely most important bits to show first?", you'll have a much easier time designing upwards to the tablet/netbook/laptop/desktop sized versions. Shrinking down to a 4" screen from the 1600pixel wide monstrosity that every single stakeholder has insisted has _their_ "critical" piece included is _way_ more work.
I've often used the "mobile first" approach to gently encourage clients to prioritize goals properly "I know we're not considering a mobile version of this site at this stage, but there's a _lot_ of conflicting requirements for your homepage here. If we were in the future to develop a mobile version, which of these things would we cut and which would we keep if we only had a phone screen to display everything on?" is an approach thats worked well for me…
I agree with the author, but not for the same reason they mentioned. Currently, the biggest problem in mobile is discovery. If you're not in the top 25 for your category, its difficult to gain enough organic traffic to build a sustainable business on. Companies much larger than you are buying out all the paid inventory. As a startup, you'll be doubly hurt because no one will know who you are. So you have all the problems of sustaining as a brand on the web plus the added disadvantage of surviving on a platform where discovery is inherently broken.
So unless you think long and hard about how to solve distribution and come up with some interesting hacks, you're at a large disadvantage from day 0.
This is assuming the product you are developing is a consumer product with the intetion of marketing through an app store of some kind.
There are plenty of app markets for which an app store is only a method of distribution (the only one, really), and sales/marketing is handled in the traditional manner.
Many different ways. For organic traffic theres links, search results, facebook posts and other social media. For the app store theres added friction bc users have to install the app on their phone and there will be a dropoff between viewing a listing and downloading (and also from downloading to launching). For paid traffic, its much easier to build a sustainable business on the web because the costs are, for the most part, cheaper.
I think a key indicator of the equilibrium point is the market share of mobile to desktop in emerging markets. I think we're going to see usage patterns in the US trend to those over time. For example, check out this graph from the KPCB 2012 internet trends report on internet usage in India: https://dl.dropbox.com/u/120/Screenshots/emerging_market_int...
The evidence in the US and UK seems to suggest that people that can afford desktops or laptops aren't so eager to abandon them. It seems just as likely to me that people in developing economies will upgrade to real machines given the chance.
It is actually different for economies like India. Majority of the population never had computers or internet. But everyone is starting to have a mobile phone.
They are doing an Ice -> Vapour thing skipping a step.
Comparing pure visits or pageviews to sites with a counter is not capturing the whole story. App interactions are not necessarily hits for a stat counter. A better indicator is time actually spent on different devices (which is not the same as 'time on site' in analytics). How many hours are people in front of a desktop computer and how much time do they spent on mobiles and tablets?
If you start on December 2008 and end in May 2012, it is much easier to see the trend. I agree that it is an exaggeration to say rapid, but it does look like a definite downward trend for desktop and upward for mobile.
Jamie, what experience or research backs your claim that mobile development is an order of magnitude slower than web development?
I've been coding iOS apps for the past 6 months now (after coding web apps for years before that). If anything, I think iOS development is easier and faster than web development.
In every company I know where there is a capable web programmer and a capable iOS programmer adding the same features to their apps (supported by a shared backend), the web programmer is an order of magnitude faster. There's no peer reviewed studies on this subject but my anecdotal evidence (from advising dozens of startups through YC) is all on one side.
If you're trying to duplicate a document-centric interface on iOS (without using UIWebView), you are in for a lot of work. Similarly, if you are trying to duplicate an application-centric interface in the web browser, you are in for a lot of work.
There is overlap, of course. If your solution is document-centric you can simply use UIWebView on iOS. If your solution is application-centric, there are a number of Javascript frameworks that look a lot like UIKit in design. This should reduce the difference as the tools end up being similar, no matter what the target. Cappuccino even lets you use much of the Apple toolchain, including Interface Builder, while targeting the browser.
If each platform gets its own independent solution, it is going to largely depend on the complexity handed down by the designers. If the web version comes with less design complexity then it will naturally be easier to implement.
An order of magnitude? Do you really mean that you've seen iOS programmers spend 10x as long on something (e.g. 10 months vs. 1 month)?
Let's imagine a simple, specific example: you want to add a button that sends a message to the shared backend and displays an alert upon success. Let's walk through the code.
In your web app, you could add an HTML button, style it with CSS, and then use jQuery to send a request and define your success handler. Probably not more than 10 lines and a few minutes (depending on much time you spend with the CSS).
In your iOS app, you could add a button with Interface Builder, link it to a method on the relevant view controller that sends an NSUrlRequest, then add a delegate method that displays a UIAlertView when the response returns successfully. Again, not more than 10 lines. And no CSS, thank god. :-)
Where is the extra overhead that you're talking about coming from?
Perhaps a binary or ternary order of magnitude, rather than a decimal one. 10x is probably an exaggeration I would say typically it's more like 2-4x.
As I'm not an expert iOS programmer, I'm not exactly sure where the overhead comes from. Given the bugs that are usually present in iOS apps, the tricky bits appear to be:
- Handling screen reorientation
- Making scrolling smooth (it's easy to load either to lazily or too greedily)
- Making it feel "snappy"
- Not segfaulting when you have an error
The web executes on hardware far faster than mobile does so you have a lot more leeway to be sloppy. Ditto for the fact that web apps can't segfault, and it's hard to actually crash a browser.
Another really important point: Doing things on mobile is easy, almost as easy as the web. Doing things WELL on mobile is much harder comparatively because the platform is lower level and less powerful.
Even if that's true, you are developing for one platform so the comparison is a bit disingenuous. Mobile development is made slower because of fragmentation, not the tools. Unless you've magically found a way to port your apps over to Android and Windows Mobile..
Windows Mobile is a bit player still, doesn't matter for startups (or non-startups).
That leaves you with Android and iOS. Most startups can start with iOS and add Android later -- there just aren't the sales numbers to prioritize Android development.
So we're back down to one platform, with native development providing definitively better results with less time.
Supporting differing platforms is not ideal, but somehow we built the entire PC industry on top of this concept, and it worked out. Maybe we should be looking at ways to bring ObjC code bases over to Android, or something that would let us re-use non-UI code.
I've been doing iOS for a year now and it's just painfully slow for anything involving a database or doing a lot of web service traffic, which seems to be most apps these days.
I'm actually looking into Monotouch now because C# is just so much easier for anything beyond snapping components together snd because every client wants an Android port now.
I think this skews the definition of mobile first a bit (I'm working from the Luke Wroblewski definition). I've been designing/building a couple of web apps that are "mobile first" and being built responsively. The result is fantastic and makes for a much cleaner, more streamlined interface. Not to mention code complexity is cut down, too. Mobile is imperative. If you're building an app for the web, it should be mobile first.
I would say that mobile browsing is supplementing desktop usage (not replacing it). I just don't see how you could replace the experience of a large 21" monitor, multi-core high powered processor, and a large quantity of ram on a form factor several orders of magnitude smaller.
Emerging markets are directly transitioning to mobile instead of web. Developed markets will take little more time to shake off legacy. But if you are starting today, you are ignoring mobile at your peril.
Last weekend some friends and I participated in a hackathon. Our app was primarily mobile, with some web. The web guys had a great looking product done, along with our backend, in about 10 hours. The android guys had an okay looking app that barely worked, plagued with memory issues, in about 23 hours, 1 hour before we had to submit. We ended up doing well, but the android dev just took much longer to hack out than the web part.
Eh, people's skill in stuff is all over the place. I think android, especially UI based android, IS slower currently than iOS to make, however I am guessing your iOS app was done by people who were better at their type of apps in general
Clarification: It was an app based around picture taking, and you could view those pictures online. The viewing online looked great, but the taking pictures, and view pictures on the android app was slow and running out of memory all the time. We could barely get it to run on Android 4.0 which has a larger heap size for apps than our target 2.3.3.
Unfortunately once you get into heavy picture viewing, you need to go to OpenGL. In fact, almost all of the top selling custom launchers and live wallpapers are OpenGL.
"Mobile First" shouldn't necessarily mean you should build a native mobile app. You can put your efforts to build a responsive web app, that would scale from mobile to web.
It's better if your MVP is ubiquitous, without being tied to either desktop or mobile. This allows users of both demographics to explore and engage with your app.
This is a great post and I couldn't agree more. On top of the development cycle something else comes into play.
There are so many dynamics around mobile, especially on Android you need to understand. With Android, you really stand no chance to build a slick app, unless you have 600+ devices at hand where you can test the app.
With iPhone, it is very hard to track where your signups come from and content marketing on the web becomes a lot more difficult if you start with a mobile version. Directing traffic to a mobile only solution is never a very streamlined process for the user we found.
I think the author is coming to the wrong conclusion for the wrong reasons. You can iterate VERY fast with mobile and dev doesn't have to be slow at all. You can use HTML5 with PhoneGap or whatever and get to 80%-90% of the quality of a native app, especially an informational/shopping app.
The key is that you probably will end up rewriting your app to be proprerly native once you fight the right "product market fit" if you don't have good enough performance. That being said, you don't have to be the worlds fastest or best app to prove out a business model.
This is a common mistake made these days: use webviews to jump start development and then go native later. Many of the supposed benefits of webviews simply don't exist, from increased reliability through fast iteration to faster development. They are also hell on earth to work with because they are far more fickle than a normal web browser. The reason mobile development is slow right now is that the languages and frameworks are not optimized for moving quickly and you need to do a more traditional software release cycle if you plan on having an even remotely bug free app.
I had the same reaction. Anybody with HTML/CSS and decent JS skills can pick up any of the mobile platforms pretty fast. Not to mention, the abundance of responsive frameworks out there like Foundation and Twitter Bootstrap.
Also, modern web development makes it insanely easy to pivot your message or your marketing direction to whatever market you're trying to focus on.
"we believe that the future of shopping is primarily mobile (particularly tablets), but we’ve consciously chosen a “web first” strategy. The reasoning behind this is simple, mobile development is still slower than web development by nearly an order of magnitude"
This makes absolutely no sense. Are you saying that though your customers are approachable via mobile, you are choosing web because it is easier? This reminds me of the guy looking for a lost ring under a streetlamp though he had lost it elsewhere because it is easier to see under the streetlamp
It may be a little misguided to say that companies like Parse are speeding up the iteration cycle for mobile apps. Every business is going to need a backend to store all its data, so the time spent architecting and building the backend layer should be equal regardless of whether your frontend is browser-based or native mobile.
Parse only helps if you don't have anyone on your team who is fluent in building backends. That being said, Parse is an excellent choice when you're in that situation.
I disagree with the author. I think writing an app is easier than making a website.
HTML was invented as a format for document. it's essentially a document format like Microsoft word file. Now, with the idea of web app, people try to make a document look like an app or even a desktop application. And this is difficult.
will you use Microsoft word to develop an app?
I feel that writing an ios prototype is much easier than working with javascript.
A what? I have never heard the words "hypermedia" and "API" juxtaposed as such. Is this something different to a REST API, which the results returned by Google seem to suggest without clearly articulating the difference.
A Hypermedia API is essentially what a by-the-book REST API is. Most "REST" APIs don't meet the hypermedia requirement outlined in the original dissertation. But because the term REST has been generalized beyond what it actually was defined as, some purists have taken to calling truly RESTful APIs "Hypermedia APIs"
That seems to happen a lot, kinda like how the Rails framework misapplies the MVC pattern and is really a MVA framework. I just assumed it was some new fad around APIs; I found a conference talk I'll watch later.
One day I'm going to release the OMFGBBQ pattern. I don't know what it does yet.
Twilio is a good example. It boils down to delivering links with API results. So, given the root endpoint, a client can navigate/discover available actions for data retrieval/manipulation.
You could certainly argue that it is a "buzz word" or whatever, but there is a fundamental lack of buzz around the subject. REST is one of those terms that has been beat to death. Used/misused to describe so many things so as to be useless. Hypermedia adds a specificity to the equation that is useful, at least to me.
I like Fowler's description of the Richardson Maturity Model[1], which describes the "levels" of RESTfulness an API can have, with a full-on hypermedia API being the top level. Steve Klabnik's "Designing Hypermedia APIs"[2] is also shaping up to be a good resource, though it isn't free.
Sounds like you are mobile first (because you're targeting tablets). Which makes this discussion about native (obj-c, java) vs web for prototyping consumer tech services.
Most consumer tech services are seeing usage move to native apps which emphasis great experience - surely working on that counts towards reaching product-market fit.
The revenue stream is also more mature for web than it is for mobile. So you have a better chance of reaching profitability faster, giving you more time/money to invest in the mobile platform in the future.
Cool site that he links to. It was fun to play around and only require an email address to get in with no validation. My only gripe is that the pants only goes up to 36 waist while weight options are upwards of 300lbs.
http://www.lukew.com/ff/entry.asp?933
One of Luke's key tenets on Mobile First is about how smaller screen sizes force you to focus your messages -- and lack of focus is a huge issue for most Web sites.
Fred seems to be coming at it from a slightly different angle, but I think it's important to include Luke's ideas here in the discussion... it's how designers and UI experts think about the term "Mobile First".