New Startup? Think Twice About Mobile First
jamiequint.com
jamiequint.com
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".
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.
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...
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…
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.
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.
I don't think the current usage stats support this claim at all:
http://gs.statcounter.com/#mobile_vs_desktop-ww-monthly-2011...
Mobile is definitely important but the truth is nobody knows if the equilibrium point is 20% of the market or 90%.
They are doing an Ice -> Vapour thing skipping a step.
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.
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.
If you're an Instagram or Pinterest or Flipbook the Android userbase it way too big to ignore.
If you're not one of them, then there's more than enough of a userbase on iOS to start with.
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.
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?
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.
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.
Really? "Primarily Mobile, with some web" doesn't sound like a web app to me. Sounds like a app that runs on a mobile phone, that's not android.
Perhaps he meant what you think he meant? It's unclear.
Sorry if that was unclear!
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.
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.
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.
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.
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
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.
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.
One day I'm going to release the OMFGBBQ pattern. I don't know what it does yet.
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.
[1] http://martinfowler.com/articles/richardsonMaturityModel.htm...
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.