4 ms·

I've always thought that building an iPhone specific version of a site is the wrong path to take, and that site operators should create a mobile friendly versio

by rm-rf 17y ago

I've always thought that building an iPhone specific version of a site is the wrong path to take, and that site operators should create a mobile friendly version that works on iPhones and other PDA/Mobile like devices. It seems to me that for an approximately equivalent work effort, one can cover a handful of mobile platforms instead of just one. I'm especially annoyed when the sites iPhone version re-directs Opera Mobile and Fennec browsers to the main site. A decision like that limits the usefulness of non-Apple mobile users.

masklinn 17y ago
> It seems to me that for an approximately equivalent work effort, one can cover a handful of mobile platforms instead of just one. As pretty much everybody who tried it discovered (and PPK is currently documenting, see http://www.quirksmode.org/m/table.html http://www.quirksmode.org/m/table.html and http://www.quirksmode.org/m/css.html http://www.quirksmode.org/m/css.html), while this is simple in theory it's extremely difficult in practice, because there's much more variance within the mobile space than within the desktop one (if you think 10 browsers -- including variants -- over 3 platforms is difficult, consider an order of magnitude more on as many low-power low-perf platforms). Even if you restraint yourself to fairly advanced phones (and don't have to deal with WML, cHTML or XHTML MP) anything beyond basic (unstyled) markup is risky. Thank science the space is currently coalescing into either Webkit or Opera browsers, but it's still a pain.
rudenoise 17y ago
In some ways the native app route solves the browser problem (or at least it would if Apple and Android supported Web widgets like Nokia WRT/Ovi SDK and Opera Web Widgets). This way there is no doubt which browser will be used, whilst still using easily portable code (HTML, JavaScript etc...). Also if these widgets interact with the service over an API then any developer can adapt the service to their favourite platform.

by rm-rf 17y ago

masklinn 17y ago

> It seems to me that for an approximately equivalent work effort, one can cover a handful of mobile platforms instead of just one. As pretty much everybody who tried it discovered (and PPK is currently documenting, see http://www.quirksmode.org/m/table.html http://www.quirksmode.org/m/table.html and http://www.quirksmode.org/m/css.html http://www.quirksmode.org/m/css.html), while this is simple in theory it's extremely difficult in practice, because there's much more variance within the mobile space than within the desktop one (if you think 10 browsers -- including variants -- over 3 platforms is difficult, consider an order of magnitude more on as many low-power low-perf platforms). Even if you restraint yourself to fairly advanced phones (and don't have to deal with WML, cHTML or XHTML MP) anything beyond basic (unstyled) markup is risky. Thank science the space is currently coalescing into either Webkit or Opera browsers, but it's still a pain.

rudenoise 17y ago

In some ways the native app route solves the browser problem (or at least it would if Apple and Android supported Web widgets like Nokia WRT/Ovi SDK and Opera Web Widgets). This way there is no doubt which browser will be used, whilst still using easily portable code (HTML, JavaScript etc...). Also if these widgets interact with the service over an API then any developer can adapt the service to their favourite platform.