The Right Tool For the Job

A few days ago Bryan Rieger posted some fantastic slides about rethinking the layout of site resources for content meant to go to mobile devices from Yiibu. There’s some great stuff in there related to applying progressive enhancement principles to the layout as a whole, and the follow-on has spilled over into the mobile web discussion group about how to deal with desktop browsers that don’t do well with media queries. Great technical discussion and happy to see it happening.

However, I’m struggling with a big disjoin between what’s possible and whats practical and productive. We’ve gone through the discussions plenty of times before regarding the economics of developing for lower end capability devices (users of those devices segment into different demographic buckets, finding ways to address them is more difficult, etc). So lets just assume that folks using lower capability devices make good users and they’re people you want to address as users.

I talk to a pretty decent set of web developers on a pretty regular basis. Some of them have started to get excited about developing for the mobile web. I hear them say things like they’re happy they don’t have to pick up a whole additional set of markup to make things work on mobile devices, that they’re happy lots of the base functionality is showing up directly in javascript API, and that the layout engines have gotten good enough that they can make pleasing web experiences. Generally I don’t hear too much from the web developers about being able to hit wide swaths of devices with the same set of markup and styles. And I can’t recall any of them saying they’re anxious to supplant the programming models they’ve come to develop with different architecture for web design. Actually, I hear things like “it works on the iPhone, that’s what I have anyway, I don’t care about Android” more often than I’ve heard people discuss how to make things work consistently on both platforms.

Whenever the discussion starts to revolve around hitting multiple handsets, it’s always driven by people already in mobile. It was my impression that the next generation of mobile web technologies was supposed to cater to the existing set of web developers and make mobile an attractive option for them. I’m not seeing that happen however.

So my question is for what group of folks is this going to be the right tool? I’m certainly not a web developer, but I understand the stuff that goes on there. But you don’t even really need to be familiar with the technology, all you have to do is take a look at Twitter on any given day at the discussion going on with web developers. Quite a bit of it revolves around bitching about “cross-platform” issues, which normally means getting the stuff to work on different browsers even when we’re dealing with full desktop layout. Now we’re talking about supporting different device resolutions and orientations all using different browsers (or at least different versions)? I can’t see the web devs I know jumping out of their seats to volunteer for that.

The technique that I see most folks using is segmenting their traffic and swapping things out on the web server. They design for desktop, high capability mobile, and low capability mobile. They detect what device they’re serving to normally based on the user-agent, and then serve up the correct version directly. Both techniques have issues, granted. Lots of issues. It seems like the “new new” of progressive enhancement laid out in the slides would work best when you’ve got:

  • Folks working on the implementation who are at the deep end of HTML/JS/CSS
  • An environment where the pages need to be static and server side switching isn’t available
  • There’s a minimal amount of application logic.. trying to interleave dynamic content updates and event responses with the complexity of adaption seems problematic

Or am I missing the boat here? Is there a way to apply this stuff that significantly lowers the bar for implementers? Or plasters over a bunch of these complexities? Or merges together the different models and techniques? Cause it’s hard enough to convince the web folks I know to even play around with iPhone, we’re just starting to make some inroads there. If I laid something like this in front of them they would probably kick me. So, please, educate me. How do we put things together so that doing web development this way is compelling to someone who isn’t already a mobile devotee?

UPDATES:

PPK is rising to the challenge and trying to lay out how things should be working. Here are his responses:

Daniel Hunt has also followed up, with a different take than PPK, saying that device detection is an essential element of being able to deliver a great mobile web experience.

This entry was posted in Browser, Community, Software, ThisIsMobility. Bookmark the permalink.

11 Responses to The Right Tool For the Job

  1. The problem has more to do with the method towards how sites are designed/developed – if we started out with base content and then developed the presentation and functional layers later (as what’s described in the SlideShare piece you noted), then we’d be better able to capture modes of use, from low to high.

    The other thing that helps here are frameworks which help to pull in some of the harder pieces of code or functionality. For example, that group FeedForAll has a number of schemes and scripts to do things with RSS that lots of folks want to do. Its a matter of taking that, and wrapping it into your code. Not very hard, and simple to implement (usually).

    I think we are a well aways off from everyone doing mobile and non-mobile sites right; but if we have more people modeling good use, then we can finally have enough imitators to turn the web into something a bit more receivable by all.

  2. Hi Mike,
    I’ve been in the industry for a while, so I probably fall among those that call for 100% device coverage and my efforts in WURFL and DeviceAtlas are another proof of that, I guess. Yet, I’d like to share some thoughts :)

    Especially in the US covering the iPhone and not caring about the rest is very common and it also makes sense, since that accounts for most of the traffic AND requires the minimum effort. I think that what should be taken from Bryan’s presentation is that actually with little extra effort you can cover a broader range of devices. I think we are still in the field of 80/20 effort. I think that making something work for the iPhone and not for Android is just laziness, yes the browsers are not 100% the same, but the difference is so small that not doing it is just limiting. Nokia S60 devices on the other hand, still come with an old “snapshot” of the WebKit and unfortunately do not support a lot of the cool things that iPhone and Android support such as transitions and rounded corners in CSS. Yet, it is still a pretty good browser and with progressive enhancement you can provide a good presentation on Nokia devices (if Nokia devices are of any interest to you, i.e. if you don’t target the US market only).
    And one more thing, making your Web sites look like iPhone-native applications will look great on the iPhone, but stupid on all other devices. Nothing stops you from making GREAT design and not make it look like iPhone. COME ON, designers existed before the iPhone (and I hope will still exist in years from now).

    Also, there are low-end devices. Those devices that have a simple browser, most likely with a small screen and no touch. What Nokia groups as Series 40 devices, but also LOADS of Samsung, LG, Sony Ericsson and other brands in the US (is Kyocera still there?). These will not even get close to the rendering capabilities of iPhone, Android or Nokia S60, PLUS the device features are just too different to think of providing the same presentation and YET make it look good on all platforms.
    So, in support of what you said about server-side detection and “swapping” themes depending on the device class, I think today there are 2 classes of devices, some call them high-end and low-end, I think the whole point is about what the device features are (big screen? Touch? Joystick? Keypad or qwerty?). For these two classes you still very likely have to switch themes in order to achieve a good presentation on both. If you decide that the class of devices with small screen and no touch is not interesting because those guys are less likely to browse, then it’s fine (HEY! If I care about browsing, I’ll get a device with a big screen and a good browser, no?). If you tell me that you don’t support Android or Nokia S60 because it’s too hard, then you’re just DECIDING to focus on a specific segment and it’s your choice, not a limitation of the technology.

    PS: this would probably deserve a proper blog-post, but I think I’m too lazy ;)

    (DISCLAIMER: after about 10 years in device detection and content adaptation, I now work for Forum Nokia, so I’m probably the worst person to comment on this… Or maybe the best!)

  3. James Pearce says:

    One key as ever is tools.

    I don’t necessarily mean something like teaching PhotoShop how to carve up PNGs into different sized slices. (And at the other end of the scale, I have a disclaimer in DeviceAtlas too, but that and WURFL are concerned with much of the gritty detail of diversity.)

    But there is a missing heartland of easy, understandable techniques, patterns, enabling components, and, most importantly, stealable code. They don’t even have to be huge, complex frameworks… sometimes simple contributions make huge breakthroughs.

    In web design/development world, consider the impact that the reset.css style had: a reliable way to neutralize browser incompatibilities (back when their defaults were far more diverse). Suddenly designers had a whole less worrying to do.

    Or the 960 grid system and – which was more far more effective at encouraging elegant column layout in sites than years of merely preaching about not using tables had been.

    Perhaps not inconsequentially, browser design leapt forward in the same era.

    So now that we’re past the point of asking whether we even need it (ah! 2006!) what are the simple tricks and techniques that will unblock the tubes of the mobile web medium in the way that Bryan (correctly) demands? And where is the code that people can steal to do it without even having to think about it?

    jQTouch was on to something here, as are the (excellent) Nokia mobile templates. (My humble contribution so far is http://tinysrc.net … but stay tuned ;-) )

    There’s a lot more we can do to kick start ‘good ways’ to do things.

  4. James Pearce says:

    When I say ‘browser design’ I mean ‘web design’

  5. miker says:

    Thanks for the feedback. I’m actually not arguing (for once) if we should try to hit the “lower capability” devices. But assuming that we do want to, how can we make it something that web developers can practically address? Sounds like we’re making some good progress in that direction, but we’re still a long ways off.

  6. Bryan Rieger says:

    Thanks for writing this post as you’ve hit upon the very real issue of tooling and knowledge transfer. This stuff is not easy, and it’s going to take time for people to get their heads around new ways of doing things. The mobile web discussion group (mentioned in your article above) is really helpful as it is providing a much needed reality check.

    We (Yiibu) have been creating mobile sites the ‘traditional way’ for a few years now (ie: segmenting traffic, swapping things at the server, using device databases, etc) and were finding that it wasn’t scaling all that well as newer devices (with varying screen sizes and capabilities) were coming on the market. There is (and will continue to be) simply too much diversity to segment the mobile space so cleanly. After *a lot* of device/browser testing earlier this year we began to think we needed to approach the problem from a different perspective, and @lukew’s ‘mobile first’ idea seemed like an appropriate place to start.

    I was hoping to have an example site up along with files to download and experiment with when that presentation went up, unfortunately (like most things in life) that didn’t go as planned — however I am hoping to make them available in the coming weeks.

    PS – it’s also interesting to note that the ideas put forth in my presentation have been labelled as both ‘too simple and not scalable – useful only for small, designer sites’ *AND* ‘too complex and not accessible to anything but large-scale sites’… ;)

  7. miker says:

    @bryan Thanks for following up on the conversation. I think an example site or two might help out. Like James points out though, I also agree that general tools would really shift things.

  8. I guess it might be interesting to mention that there are efforts to go cross platform and we @uxebu may be one of the few to tackle that. In this article http://bit.ly/eventninja you can read about how we ported that one app to a couple platforms:

    The app runs on iPhone, Android, Palm’s WebOS, Blackberry, Windows Mobile, Nokia S60,
    Vodafone 360 phones and we are still adding to the list. But the most interesting fact is:
    it’s all the same code, just one and the same app.

    It was some effort but a very important learning for us. The core is the same everywhere and porting it to multiple platforms is actually just a question of knowing how to do it and working around quirks and bugs, but that comes second.

  9. Pingback: The ignored issues on mobile web: connection.mpulp | mpulp

  10. El Guapo says:

    The real issue is that vendors( desktop, mobile, etc. ) have little incentive to put out products that actually work well, and most importantly, adhere to a standard API. It benefits them to create things that work only on their devices, if they can get away with that. Market share determines how much they’ll go that way. The other is, in putting out half-assed implementations, it forces developers and companies to purchase dozens of devices to test on. This is simply not possible for small companies and independent developers( hence, developing for one platform ).

    Ultimately, it’s a confluence of many factors that makes mobile development suck so bad. But users are flocking to the new hotness and developers must march along if they want to remain relevant.

  11. Since the YouTube video clips are posted at this place same like I also embed YouTube video code at my own site, since it is easy to get embedded code.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre lang="" line="" escaped="" highlight="">