Late last week, I linked my Forrst followers to Stephanie Rieger’s awesome post “A Plea for Progressive Enhancement” which offered a even-handed critique of a sliding menu interaction on the website for the Obama campaign. The main thrust of her complaint was that it didn’t work on most of the mobile devices she tested, including an iPhone 4 running iOS 4.3.5—one version prior to the release of iOS 5.
[T]he menu failed. Never even opened. Suddenly, the site was without navigation…at all.
Joe Seddon, a UK-based designer, shared his reaction to the post in the comment thread, but if you’re not a Forrst member, you can’t read the comments, so I wanted to share his reaction:
I know you’re a big fan of progressive advancement Aaron and I have huge respect for you as a designer, however I disagree with your way of thinking and feel it is holding our industry back.
Starting from the bottom instead of the top limits creativity. By designing from the top we as designers can take advantage of new technology and build the best user experience possible for those who use the best browsers. I agree that designs should work to a usable degree on every browser and device in which there is a decent level of traffic coming from, however this doesn’t mean we should have to start designing for them first.
In the case of Brad Frost, he should keep his nifty slider on Barack Obama’s website however on mobile he should find an alternative solution that works. If this means removing the slider all together and replacing it with a simpler navigation method then so be it. He shouldn’t limit the experience of the desktop user just because of the mobile user doesn't have a device that supports this or that.
I don’t mean to pick on Joe here, but he shares a common misconception about progressive enhancement. One I hope my response (below) dispels:
@JoeSeddon It sounds like you’re firmly in the Andy Clarke camp on this one, but I couldn’t disagree more with your statement that my “way of thinking” (i.e. progressive enhancement) is “holding our industry back.” If anything, I think it is the way forward. And for the record, I’m not the only one thinking this way: Jeffrey Zeldman, @adactio, Ethan Marcotte, Daniel Mall, Scott Jehl & the Filament Group, Brad Frost, Stephanie and @bryanrieger, and countless others support and promote progressive enhancement every day.
Starting from the bottom instead of the top limits creativity.
Actually no. Building a website is a heck of a lot like building a house—you need a solid foundation and “good bones” for it so stand the test of time and for it to be able to support the amazing things you want to do with it. Your server forms the foundation—keeping the whole website stable. And smart, semantic markup is the framing—the joists and supports that allow you to build higher without worrying about collapse.
To take the analogy further, your backend (assuming you have an API or at least a DB and some code to talk to it) is like the electrical, water, and communication systems which will support the fixtures of your site. CSS is your façade and interior design. Basic HTTP (e.g. links and communication via POST and GET) and JavaScript (probably in concert with an API) connects the systems to your fixtures (most likely a combo of HTML, CSS & JS) and makes them functional.
All of these pieces are orchestrated by your IA, User Flows, and UX design—the blueprints, elevations, etc. of the web world. And, to be honest, that’s where you should be doing the lion’s share of your creative thinking when it comes to interface.
By designing from the top we as designers can take advantage of new technology and build the best user experience possible for those who use the best browsers.
You, as a designer, should be considering the implications of technical decisions and options at the planning stage. If you’re a freelancer or run a small shop, you may be the UX person too, but if you aren’t, you should be working with your UX person to propose innovative interactions and then plan out how those can be used on the latest and greatest browsers and what the experience would be on less capable browsers and devices. It all starts with the planning.
Nothing in progressive enhancement says you can’t use the latest and greatest technologies and techniques, it just asks you to respect your content and your users by being smart about how you apply them. Remember: browsers and technologies come and go1; focus on your content and your users.
I agree that designs should work to a usable degree on every browser and device in which there is a decent level of traffic coming from, however this doesn't mean we should have to start designing for them first.
First of all, analytics are not always 100% accurate and, secondly, as a web designer or developer, we never know who is coming to our site and what they are looking to do. For all you know, there’s a lady out there looking to spend millions of dollars on the product or service your site (or your client’s) is providing and your analytics program can’t tell you that she’s the 0.001% that came to your site on an aging Blackberry. Analytics can tell you general trends, but they should only be used for general guidance. I’d rather build something that is going to work for a user regardless of her device. I’m not going to waste time trying to re-create the awesome experience she may have in the latest version of Chrome or Firefox, but I sure as hell want to make sure the experience she does have is a positive one.
In the case of Brad Frost, he should keep his nifty slider on Barack Obama's website however on mobile he should find an alternative solution that works.
Point of clarification: Brad does not work for the Obama campaign, he simply brought Stephanie’s attention to the interface, but to your point: “he should find an alternative solution that works.” Absolutely! Building from a workable baseline up to the hi-fi experience of the sliding nav would accomplish that. There’s nothing to say that you can’t have your cake and eat it too; you just need to be smart about your approach—proper planning is key.
He shouldn't limit the experience of the desktop user just because of the mobile user doesn't have a device that supports this or that.
Of course he shouldn’t. Progressive enhancement doesn’t say that he should.
I think you should rethink what progressive enhancement is all about. Not to plug my own work, but the first chapter of my book lays it out pretty well. You can download it for free as a PDF or read the web-based version on .net Magazine .
1. Don’t believe me? Look at how many companies built software and intranets around IE6. Why did they do it? It was considered a pretty good browser at the time. Need a more recent example? Look at WebDB (SQLite). It was introduced in Webkit and and looked to be on track to become a formal W3C recommendation, but then it was dropped in favor of IndexedDB. I speak from experience when I say things like this can and often do bite you in the ass if you work on the bleeding edge.
After reading my incredibly lengthy response, Joe kindly wrote back:
@AaronGustafson First of all I’d just like to say great post, and thanks for taking the time to reply to my post.
Your reply has actually made me think about progressive enhancement and “hardboiled design” and re-consider which one really is the best strategy. I like your analogy of building a house in particular and that’s what mainly made me re-think my stance. My biggest problem with progressive enhancement was building from the bottom, as I truly did believe building from the top would allow me to deliver a better experience to those who use the better browsers/devices. In the words of Andy Clarke, I didn’t want to just give users who are on the latest version of Google Chrome little visual rewards.
Thanks for linking me to the first chapter of your book, I’ve heard a lot of positive things about it and it certainly has gone down well with its readers and the media. I’ll read the first chapter and see where I stand after it.
I’m happy to have gotten him to reconsider his stance on progressive enhancement. Hopefully we’ve gained another convert. Time will tell. ;-)
Comments
I see no reason why you can’t build bottom up (mobile first) AND use progressive enhancement. It’s HOW you implement the latest bells and whistles that makes it PE. Build mobile first, carefully consider each increase in technology and sophistication and plan what someone *without* the latest in browser technology will fall back to and still be able to have a positive experience.
Thanks for sharing this exchange on here, I’m terrible at actually logging into and using Forrst. Is it just me, or is it actually a bit surprising that progressive enhancement still isn’t the de-facto approach most people take when planning and executing work that runs in the (any) browser?
After all these years, it seems like another round of campaigning might be in order.
The “UX as a dedicated profession” fad that has taken hold, has been all about being humane to your users, but “just make sure it works before trying to be clever” club has seemed to have lost some ground.
It is at one level, but we, as humans, are easily distracted by shiny objects. The shiny is, IMHO, what keeps bringing us back to the dark side.
Aaron,
I agree completely.
I was having a similar exchange on Forrst today. It amazes me how mis-understood the concept is, and how doggedly idea’s can be held even when outdated.
Progressive Enhancement is a design strategy intended to give enormous flexibility and compatibility. It is an umbrella concept into which other techniques are placed. It doesn’t limit you in any way, it’s core tennent is this:
Start with a core concept, add complexity only once your current level of complexity is complete. Carry on as high as you like.
As I noted in my comment in Jeffrey’s recent blog post about another post by Stephanie, I think good web design is inherently progressive. At its core, publishing content to the web is publishing text (and also usually images… but not always). Then we progressively enhance it with CSS. Serving*any* CSS at all is progressive enhancement—because it’s serving more than HTML.
Even when I wrote last year about making existing fixed-width web sites mobile-friendly*, that isn’t a top-down approach, either — even when the starting point is an existing web site. By adding media queries and overriding the fixed-widthness (heh, what a great new word!), one starts over from scratch with HTML and a goal to create an additional presentation that is optimized for mobile devices. Then you proceed with new layout rules, a mobile-friendly navigation, etc., all the while enhancing progressively.
* Mobilizing Web Sites: Develop & Design (Peachpit Press)
Aaron,
Thanks for clarifying that I didn’t make Barack Obama’s mobile navigation hahaha. When I read the comment I had a bit of a WTF moment.
Great post. The fact that he “converted” shows that these conversations are definitely worth having.
Completely agree with you (Aaron Gustafson), thanks for the great write-up and clarifications.
Just one thing, you are talking a lot about the content out approach. I think you should start with increasing the font-size on this site to 15-16px (1em).
I wonder why so many skilled responsive developers do not consider about ideal font-sizes and line-with on the screen?
Even Mark Boulton - uses way too small fonts on his site (talking about the table/smartphone size starting at approx. 740px width): http://www.markboulton.co.uk/journal/comments/responsive-advertising
A fair point. We do bump up the font size a bit based on the screen size, but it probably wouldn’t hurt to do so across the board.