Comments on: Don’t go native UI on your mobile web app

By: me

me — Sat, 24 Dec 2011 03:46:06 +0000

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.

By: Tweets that mention Don’t go native UI on your mobile web app -- Topsy.com

Tweets that mention Don’t go native UI on your mobile web app -- Topsy.com — Mon, 10 Jan 2011 12:42:52 +0000

[...] This post was mentioned on Twitter by Jitendra Vyas. Jitendra Vyas said: Don’t go native UI on your mobile web app http://lnkd.in/AhJKar [...]

By: Matteo Spinelli

Matteo Spinelli — Thu, 09 Dec 2010 18:52:00 +0000

very well done, Robert. Thanks for sharing.

By: Robert Biggs

Robert Biggs — Thu, 09 Dec 2010 17:35:39 +0000

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/

By: giuliano

giuliano — Tue, 26 Oct 2010 13:25:19 +0000

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)

By: Quality Code « Mr Chris Jones

Quality Code « Mr Chris Jones — Sun, 11 Jul 2010 00:33:52 +0000

[...] In my last post I was suggesting to stop cloning the default Apple UI for web applications and start creating custom controls. This time I want to put my words in practice and present you with a rotating wheel select control, 150 lines of code all included (HTML+CSS+JS). [...]

By: Markus Palmanto

Markus Palmanto — Fri, 05 Feb 2010 11:01:57 +0000

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.

By: Matteo Spinelli

Matteo Spinelli — Tue, 12 Jan 2010 03:13:02 +0000

@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.

By: Jann

Jann — Sun, 10 Jan 2010 18:14:50 +0000

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.

By: Fabrizio

Fabrizio — Wed, 30 Sep 2009 15:31:15 +0000

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.