> Don’t go native UI on your mobile web app
In most of my mobile webkit examples I tried to resemble as close as possible the native iPhone user interface. I decided to use a familiar UI just to show off the power of the little mobile browser but I highly discourage using Apple’s graphics for your web applications.
Developers have the false assumption that users want a native UI. Users are lazy, I’ll give you that, they reluctantly spend time learning new interfaces, that’s why your UI must be well designed and easy to use, but not copied.
First of all remember that you are designing not just for the iPhone but actually for any webkit based mobile platform. An Android user won’t feel at home with your iPhonish sleek interface.
Secondly forcing yourself to find a native UI element that fits your application is limiting your creativity and not optimized for the web. Often to get the same look and feel of a native control you need dozens images and hundred lines of javascript. For what? Maybe something that could have been done more inventively with just a couple of CSS properties. Also keep in mind that is not always possible to have a perfect 1:1 clone of the original Apple designed control, having an element that looks very similar to the original one but that behaves differently is worst than having a totally unique element.
A blatant example is the on/off switch many frameworks try to resemble. The element looks similar to the native UI switch but usually it cannot be slided but just clicked. This different behavior may lead to frustrating user experience and to add the slide effect would require more javascript. I’m not against javascript, I love it, I’d use just JS if I could, but I prefer to spend time finding smarter ways of doing something instead of badly copying a native UI.
Summarizing, try to think what controls are needed for your application and reinvent them if they don’t exist, do not try to bend your application to work with a javascript-recreated native control just because it’s cool to look like a Mac.
I’ve been running into this with theming jQTouch. I have come to the conclusion that I will provide a default theme which is device-agnostic, and then a separate theme for iPhone/iPod Touch. I am planning to incorporate the on/off switch, though using code to detect the left/right swipe. Any of your thoughts on what else should be included would be greatly appreciated.
True!
I recently also came to this conclusion. I tried iWebkit and other, but the fact that its not an exact copy makes it annoying to use.
So I kicked them out and started to design something myself.
Oh, but I hope this doesn’t mean that you’ll forget your promise: http://cubiq.org/contact-list-on-webkit-for-iphone/8#comment-249
(-:
@Jeroen, don’t worry, a promise is a promise
Ciao Matteo.
I agree with you: I’ve tested iui & UiUIKit and I soon got bored. I have styled my own CSS with lists & tables (I find the odd/even webkit selector for table rows & columns a pretty helpful one), and I don’t regret going solo.
I find the default Apple controls useful to develop fast in XCode for the iPhone, but I am not going to use those in any iPhone styled website.
Some controls are neat though like the wheel selector. In fact, that’s how I came across your blog and I am giving now a try to your spinning wheel selector.
I didn’t know Florence had such good fellows within the Ruby/Rails/Cocoa environment; i found Matteo Bicocchi’s work also quite interesting.
Regards,
Matteo
(si, un’altro Matteo
I’m an iPhone developer and have 4 apps in the AppStore. One of them has been in the top ten list of its category for 7 weeks so far. Why do I mention this? Because I’ve tried various things and have a good feel for what works and what doesn’t.
This article is riddled with errors and misinformation. I can’t speak for other devices but users of iPhone WANT a UI that resembles native UI. I’ve tried 3-4 different UIs in one of my apps and the best response (i.e. sales) was when I replicated a lot of Apple’s UI. People just loved it and the feedback specifically mentioned it.
So yeah, go ahead, take this advice and make an app that doesn’t look like anything on your chosen platform and you will suffer the consequences of slow sales/downloads and users bitching about “shitty” UI… l’ve had that kind of feedback myself.
If you don’t believe me, go ahead, make the same mistakes I did.
I don’t care about other platforms when I create mobile applications. The question I ask myself is: do I want to reach many gadgets, or many people? Almost everyone that uses the application is iPhone users. So I target the iPhone.
Everybody knows you never go full native.
Sono completamente d’accordo con te.
Non usare il webkit e il javascript in favore di controlli nativi da programmare in un linguaggio “error prone” come l’objective c è come dover reinventare la ruota.
Si vedono in giro delle applicazioni che si collegano alla rete e fanno il rendering dei dati: tanto vale fare delle web-app !
Sono convinto che la maggior parte degli utenti non faccia caso alla UI, tranne pochi virtuosi, anzi probabilmente la maggior parte degli utenti non sa nemmeno cosa sia un UI.
L’unica giustificazione che vedo per usare objective c è fare un qualcosa di molto reattivo e veloce come un gioco o un’ applicazione che deve far uso di tutta la potenza del processore.
Per presentare liste formattate e fare bottoncini colorati preferisco usare webkit.
Speaking as someone who is targeting the App store with PhoneGap and JQTouch, Apple will *more easily* dismiss and deny apps that do not have the iPhone look and feel — or which violate the Human Interface Guidelines.
This make the decision easy: Copy the look and feel of native apps well enough and get your app published on the App Store…
Don’t copy the look and feel of native apps: you go through hell to get Apple to acknowledge that YOUR interface is valid.
This is not always the case, however, case in point:: Monopoly is an AWFUL interface — and still got approved. (I think it is cos they utilize the 3D graphics on the iPhone VERY well.)
’nuff said.
@Jann: what I’m trying to say is: push the device to the limit, don’t feel constrained by Apple’s dogma. Always push the boundaries even by a small factor.
Hmm. It’s not like Apple didn’t need to write any code to make the native switch work the way it does. So any javascript replica will require a certain amount of code to get there as well.
I think that by now it has been proven often enough that users don’t require native controls. They just want their controls to feel right. If you’re targeting the iPhone, the switch — however implemented — better feel the same as the native switch. Or look completely different but compelling, just like you presented in the next post.
It depends on the target of the app.
If you target the app or android store, a native interface (not design) is the way to go.
If you are writing a mobile webkit app you can opt for a mo universal interface that works well on most devices (and more than one skin if budget allow for it)
Matteo, I laud your efforts in creating iScroll and your Spining Wheel which both so nicely replicate the experience on the iPhone. I also understand your frustration with the poor implementation of iOS controls in so many frameworks. That’s my personal biggest complaint about them. In the end this frustration led me to seeing if I could do better. I came up with a switch control that is implemented with just CSS, no images. It slides with a touch or swipe (the both get interpreted as a touch). And it uses a hidden checkbox to store the form data. It’s not one-hundred percent perfect, but it’s better than any of the other Web-based implementations out there:
http://css3wizardry.com/2010/09/16/making-an-iphone-switch-control-without-images/
very well done, Robert. Thanks for sharing.
IMHO, any app that doesn’t resemble the native interface will look like a full screen web page (unless it’s interface has been VERY WELL designed). However, the javascript frameworks I’ve tried so far are either poorly documented or have a steep learning curve, or both. Honestly, I’d rather program in the device’s native language than break my head learning a new JS library.