Stop! You are doing mobile wrong!
For as long as mobile sites have been around the conventional wisdom has been: build your website first and then create a mobile site as an add-on; creating a distilled, streamlined version of the desktop site. This makes sense, no? A few weeks ago I discovered that we've been doing it wrong*. Here's why:
- Mobile devices will outpace traditional computers.
- Devices with fewer capabilities need to be the default.
- There is no mobile.
1. Mobile will outpace traditional computers.
The first point is the most important: the use non-desktop (mobile) devices to browse the web will soon outpace access by traditional computers. I've been predicting within the next two years domestically within the United States - although new results regarding iPad adoption may mean this is conservative. It may be even faster in developing countries.
2. Devices with fewer capabilities need to be the default.
Rather than trimming websites down via CSS or JavaScript detection, the default experience should be the simplest (aka mobile) one. Functionality can then be layered on via progressive enhancement, depending on the device capabilities. If you don't, you're relying on less capable devices to filter information, rather then taking advantage of devices than can easily integrate more complex content.
3. There is no mobile.
This one is tricky. With the advent of of the iPad, netbook & GoogleTV browser detection is starting to fail and there is no way to accurately predict what devices the future holds in terms of non-traditional computing. On the other side of the spectrum, with the inclusion of locative information in html5, laptops and desktops are now expanding into realms previously reserved for smartphones. By way of example, what would you call my laptop if I'm using wi-fi on a plane or train? What would you call a computer built into a car?
So what can we do?
Look at device capabilities - not devices - and layer on functionality that they accept. The key metrics would be:
- Javascript - Combined with AJAX this opens the door for dynamic progressive enhancement.
- Resolution - Certain functionality should be reserved for larger screens.
- Bandwidth - With the advent of EDGE and 3G networks, we're not quite back to the days of dial-up but we should be aware of bandwidth before trying to push large files.
- Location - If a device provides you with location, this can dictate specific functionality.
There are certainly other things that could be detected here, but with those four cornerstones you can progressively build a site that will work on any device, no matter what viewable area, connection or features that are currently available. There's still the problem of implementation for most content management systems, especially those that are beholden to WYSIWYG editors for large chunks of their markup (thanks to @grigs for pointing this out), but some CMSs - like Drupal - could be retrofitted to make this possible. Design also becomes more challenging and would require flexible, modular designs.
All told, this brave new process is not for the faint of heart - or your local floral merchant. It has the biggest impact on the biggest sites out there. However even when designing for your local floral merchant if you want a site retain its value past 2012, you may want to go mobile and build the desktop site as an add-on.
* Credit for this epiphany belongs to Bryan Rieger. His epic slideshow (140 slides) is both beautiful and mindblowing.
Comments
Hey, we know we're doing it wrong, but it's hard to get a company to go in a different direction like this. It took years to convince people that writing for print and writing for web was different. Now, the text has to fit on a mobile phone screen, so it needs to be even more condensed. Making these shifts takes time whether the technology is there or not (and I don't think the technology for mobile web is fully there yet).
Thu, 10/21/2010 - 14:58
The biggest question (and decision point) really should be "how long do you want this website to last?" If the answer is, not more than a few years than building for specific devices is still an option. However, if they are building something that will continue to evolve and/or has a longer planned lifetime, a flexible layout targeting devices attributes is the way to go. That said, it won't be easy!
Thu, 10/21/2010 - 16:41
Joaquin,
Thanks for writing this. I think the idea is sound, but I'm wondering how it might work in practice.
The first approach that comes to mind is to have the server send back just the most essential content to the client, then have the client request secondary and tertiary content via Ajax to build up the full interface if the device supports it.
This doesn't solve 2 cases:
- Users without JavaScript
- Users with capable browsers, but small screens
With so many combinations of browsers, screen sizes, and mobile versus stationary use cases, it seems like in practice this could get very messy very quickly. Can you offer any guidance from your own experience? Have you used this with clients of any scale to good effect?
Thanks,
-Andrew
Thu, 10/21/2010 - 17:43
First off - I haven't had a chance to implement it, but I am going to try with a map+list website I'm building internally. It's going to be tough to retrofit Drupal to load regions/blocks on demand instead of as a single cached unit (this also has implications on the entire caching mechanism).
Now for the cases:
1. Users without JavaScript get the base experience, with no enhancements. If you don't have JavaScript turned on, you're ignoring huge advances in user interface and deserve to get something simple.
2. Users with capable browsers but small screens, would get a small experience - with the option to toggle to the full experience. This toggle should be added in via JavaScript.
The net result (I think) will be more work from the server, in terms of requests. But a much better (faster & tailored) experience for the user. For example, even though I can handle Flash and large screen content on my phone, I don't necessarily want to want for all of it to load across a wonky 3G connection.
Thu, 10/21/2010 - 17:16
Look at device capabilities - not devices
Well yes... but also look at mobile humans!
The point is not only whether the glass is this size or that, whether you can access some Javascript API or not, but... what it is that mobile users want to do.
Our assumptions about what people want from web sites are *so* baked into our psyche that we forget really obvious stuff.
e.g. On a desktop site, the contact page is often hidden at the end of a secondary menu somewhere. It just always is. On mobile (where it's much more likely that the reader wants to call you or see a map so they can find your damn office), it should be far more prominent.
(And yes, of course the map should formatted to fit the screen and so as to invoke native route finder applications on devices that have them)
On the whole I agree with your gist that mobile should be the primary target.
But we must see past the aether, plastic and glass and understand the new contexts the web is now creeping into, and the new user behaviors and priorities that might arise.
http://tripleodeon.com/2010/10/not-a-mobile-web-merely-a-320px-wide-one/ for more debate along these lines ;-)
Thu, 10/21/2010 - 17:32
Devices really should be treated as a spectrum (based on capabilities) rather than put into a mobile vs. destktop bin. I there's enough viewable area, there's no reason not to provide more content - even if the device is technically mobile (like an iPad with 3G). Conversely if there's locative information on a laptop or desktop, there's no reason you shouldn't use that information to give people a better user experience - say tailoring the initial map to display lunch recommendations in the immediate area.
Further blurring the lines between traditional desktop and mobile is the fact that you can now pass data - like maps - back and forth between the two. I may look up directions to a meeting on my desktop, but send them over to my Droid2 to actually get me where I want to go.
Ideally you'd also want things like processor power and ram, so you can figure out how much you can throw at it - but I'm not aware of any easy way to grab that via browsers. Plus it would likely be overkill.
Overall if a device can do something, the human using it will use it to do just that.
Thu, 10/21/2010 - 17:47
A site designed in such a way would probably not use flash, eat low server resources and function quickly. This would impact SEO, usability, you name it. Plus, it would cut down on flash (think of us poor Iphone users).
One thing I don't agree with you on is that it's not for the floral store down the street. I believe that large companies should not be the only ones limited to this kind of design and functionality. It's up to us as web developers to provide a platform for creating cross-platform compatible sites that add features on as device capabilities increase.
Drupal + Mobile Tools + Mobile Garland + Wurfl are some great starting points for this to happen, but there's still a lot of room for improvement in this area.
Thu, 10/21/2010 - 18:36
I absolutely agree with you that this can be made available even for small vendors as a platform, but I also think there's some trailblazing that needs to be done right now. The return on doing this simply isn't there except for people with large amounts of diverse traffic.
Thu, 10/21/2010 - 18:12
Devices with fewer capabilities need to be the default.
No. Devices that your viewers are actually using need to be your default.
Thu, 10/21/2010 - 18:27
Good point - and as long as the device that your viewers are actually using are fully supported via progressive enhancement you're still golden.
The trouble with this approach is that you are focusing on what your viewers are using today - not next year or the year after. Testing on the devices that your viewers use today is absolutely critical, and I think via capability detection and progressive enhancement you can build for tomorrow at the same time.
Thu, 10/21/2010 - 19:18
The devices your viewers have next year will be better than what they are using today :) And if you're building for a North American audience, chances are your viewers are already using iPhones and Androids.
Technically, where things are going is a "feature detection" HTML page out front that determines what features your browser supports. Think has.js or modrnizr, with mobile specific tests like master-class. You're looking for things like "has JavaScript" "has JavaScript that works" "has Touch" etc. The results will be stored in a cookie, and from there the server will send content perfectly optimized for your device, whether it's WAP, noscript HTML or a whiz bang HTML5 app.
Thu, 10/28/2010 - 16:02
Joaquin,
Thank you for your post. You bring up some really interesting points and I look forward to seeing how you implement them.
The idea of designing websites for multiple devises has been on my mind as well, especially after reading an article on how one layout can adjust to multiple sizes using flexible images and (primarily) css. I've only seen this done for very simple sites--but with your ideas about adding functionality to devises with more capabilities this has a lot of potential.
Ethan Marcotte provides an example of how website design can flex on different sized devices:
http://www.alistapart.com/d/responsive-web-design/ex/ex-site-FINAL.html
Once open, resize your browser to see the full effect.
The full article is available: http://www.alistapart.com/articles/responsive-web-design
Thanks again,
-Tamara
Sat, 11/06/2010 - 06:37
Hi Tamara - I love that reference! It's a great site, showing what is possible via CSS. However, it doesn't address the issue of trimming content that won't work (Flash, Video, etc) or change the bandwidth going across the wire.
Wed, 10/20/2010 - 14:55