- From: James Graham <jgraham@opera.com>
- Date: Tue, 07 Feb 2012 10:28:24 +0100
On 02/06/2012 11:05 PM, Boris Zbarsky wrote: > On 2/6/12 3:20 PM, James Graham wrote: >> 1) Same URL structure as the main site > > OK, makes sense. > >> 2) Less (only citical) information on each screen > > Why not do this for the "desktop" version as well? > > Alternately, if it's nice to see the information at a glance on desktop, > why not make the UI such that this information is at the top in both > versions and the less-critical information is effectively below the fold > on mobile? I realize that this may be more work and that there may be > other constraints here, but it seems like that would be ideal in this > situation. This basically amounts to "the requirements were wrong". Since the same developer made both the desktop and mobile frontends and he is one of the major users of the system, and the mobile frontend was purely scratching his own itch, I find it very difficult to justify the position that he ought to have wanted something different to what he actually wanted and made. In general the idea that sites/applications should be essentially the same, but perhaps slightly rearranged, regardless of the device they run on just doesn't seem to be something that the market agrees with. It seems to me that we can either pretend that this isn't true, and watch as platform-specific apps become increasingly entrenched, or work out ways to make the UX on sites that target multiple types of hardware as good as possible. >> 3) No looking up / transfering information that would later be thrown >> away > > Again, this seems to apply to desktop as well. Of course. The critical point was that there was different information in the two cases. The unacceptable solution here would have been to compute the union of all possible information required but only display the relevant subset. >> 4) Fast => No extra round trip to report device properties > > Agreed that this is desirable. This is the only property that is currently hard to achieve in conjunction with the others. If one gives up this requirement one can simply download a minimal framework, detect whatever device properties you like through the DOM and then pull down the rest of the site. The only problem is that this introduces ? possibly significant ? extra latency. One can avoid this by browser sniffing. Which never causes problems. Obviously. So it seems to me that we have a problem that real people are hacking their way around by using techniques that are known to be suboptimal or downright harmful. Therefore we should take the desire for a solution seriously, even though I agree that sending the device screen size, or some sort of nebulous "device class" in the HTTP header isn't good enough.
Received on Tuesday, 7 February 2012 01:28:24 UTC