A recent project pushed the boundaries of what is possible in mobile browsers. We learned a lot including some surprisingly simple things that everyone takes for granted like the volume buttons on the iPhone and how they work.
One of the features was a quiz that people could take on their phone. The quiz design was handled by another agency and they provided us with some cool sound files to use when the person got an answer right or wrong.
We built the site using HTML5 and quickly found that Android didn’t support HTML5 audio. Android 2.3 now supports HTML5 audio, but it was too late for this project.
On the iPhone side, we discovered what appeared to be a strange bug related to audio. Adjusting the volume didn’t seem to have any affect on the volume of the HTML5 audio clips. We began to fear that people playing the quiz would be upset when an ear drum piercing buzz came from the quiz and they couldn’t turn it down.
After nearly two weeks of believing HTML5 audio was broken, we encountered a phone that used to be loud that was suddenly quiet. What’s going here?
It was then that we learned about iPhone volume contexts. If you own an iPhone, you’re already aware of these volume contexts, but never consciously think about them because 99.9% of the time, it just works.
What do I mean by volume contexts? There is only one set of volume buttons and depending on what your iPhone is doing, they adjust different volume settings.
For example, if no audio or video is playing, the volume buttons adjust the ringer volume. However, when audio or video is playing, the volume buttons control the media audio level.
The iPhone provides feedback on what volume you’re adjusting by adding “ringer” above the volume level when you’re adjusting the ring level and leaves that out when you’re adjusting the volume of other audio.
But it’s not simply ringer or media contexts. The iPhone also keeps track of the volume level separately in each of these contexts:
* Headphone
* Headphone w/ microphone
* Speakers
* Bluetooth headsets
There may be more that I’m not aware of. I also don’t own a bluetooth headset so I’m relying on what I’ve been told.
The point is that it was nearly four years after owning my first iPhone before I gave any thought to how the iPhone was doing this. This is truly a remarkable design. It handles at minimum six different volume settings without the user ever giving thought to what volume they want to control.
They simply use the two volume buttons and 99.9% of the time the phone magically knows what they want it to do. You never have to think about it.
Until you build a quiz that falls into the .1% of the time when it doesn’t work the way you expect.
Our problem? the audio files were very short. Around a second each.
And unless you’re a speedster, you can’t hit the volume buttons quickly enough during that one second of audio.
Once that second passes, you’re back to adjusting the ringer volume and mistakenly wondering why the volume buttons don’t work on HTML5 audio.
Over the last year, we’ve been talking to people all over the country about what it means to have a comprehensive mobile strategy. That’s one of the many reasons why we were so pleased to work with HauteLook on their mobile web site.
From the very first conversation we had with HauteLook, we were impressed with how they were approaching their mobile strategy and how their infrastructure was built in a way that gave them flexibility to support new devices via robust APIs.
One of the things we talk to customers about is what I refer to as the email problem. It isn’t so much a problem as a user scenario.
Someone sees something that you offer that they are interested in sharing with someone else. Maybe they email a link to their spouse. Or they share it on Facebook or Twitter.
What happens when they follow that link? They go to your web site. What is the experience like if the person is on a mobile device? Is that experience representative of your brand?
This is especially important for companies that have social media campaigns. Links are social media currency.
The challenge is to make sure that when a customer reaches your site that
- no matter what device they are using,
- no matter where they are in the world
that you provide them with the best possible experience.
HauteLook got this from the very beginning. They wanted to support as many mobile phone users as possible.
To that end, the m.hautelook.com can be used on everything from feature phones with screens as narrow as 128 pixels to images optimized for the iPhone 4′s retina display.
Every morning, HauteLook members receive emails letting them know what the sales are that day. Those links point to the desktop web site. But when those links are viewed on a mobile device, you get a mobile-optimized version of the same page.
The email blast also triggers a morning rush of traffic. The traffic spike is significant enough that performance was key. John and Lyza spent a lot of time working on both the front and backend to make sure the site was fast under the heaviest of loads.
And mobile web is only one part of HauteLook’s mobile strategy. They worked with our friends at Small Society to create an iPhone app for HauteLook members that offers features like push notifications and reminders.
There’s a lot more to this project than can fit in a single post. Everyone at Cloud Four helped in some way to make the site a success. There are lessons from this project that we can’t wait to share.
But for the moment, we just want to thank HauteLook for the opportunity to work with them on such a great project and to thank those people on twitter who have given positive feedback. Nothing made us happier than seeing comments like this one from a Blackberry user who said:
That’s why mobile is amazing. Provide a great mobile experience and your customer will not only use it, but they’ll love you for it!
One conference I’ve been looking forward to all year is the Design4Mobile conference coming up September 20-24th in Chicago. I was excited before I saw the speaker list. Now, the conference can’t come soon enough!
(This was supposed to be a short post, but I got excited about all the cool speakers and wrote too much. So skip to the bottom to find out how to get a limited number of 15% discount codes for registration.)
I’ve attended a lot of conferences over the last few years. The conferences I’ve attended either have a broader focus and if I’m lucky, they have a mobile track. Some simply have have a session or two on mobile.
Other conferences that are focused on mobile tend to be of two different types. They are either focused on one platform exclusively (e.g., Apple’s WWDC) or are older conferences focused on telecoms (e.g., CTIA).
I’ve enjoyed the majority of the conferences I’ve attended so I can’t complain much about the format. But what has me excited about Design4Mobile is that it is the only conference I know of that is focus on mobile design and user experience. Four days of in depth conversations on these topics.
The conference is organized by Barbara Ballard and Little Springs Design who have been working on mobile design long before the iPhone. They are experts who I follow closely.
That alone would be enough, but come on, the speaker list is just insane. Here are just a few highlights:
- Josh Clark, Global Moxie and author of Tapworthy: Designing Great iPhone Apps — I saw Josh speak at SXSW long before I met him on Twitter or knew of his book. His session was the best one I saw. Phenomenal.
- Suzanne Ginsburg, Ginsburg Design and author of Designing the iPhone User Experience: A User-Centered Approach to Sketching and Prototyping iPhone Apps — I saw Suzanne speak earlier this year in Seattle before her book was published. She interviewed a lot of designers and developers in the process of developing her book so it’s great to hear the stories of how different people tackle problems.
- Scott Jenson, Mobile UX Designer at Google — Scott was on a panel with Barbara Ballard at SXSW. He has a practical approach to mobile, has a quick wit, and was talking about how phone can be used without taking them out of your pocket which I found fascinating.
- Corey Pressman, Exprima Media — It’s strange to look forward to seeing someone speak who works down the hall from you, but Corey spoke last week at Mobile Portland and I learned two things. 1. I learned just enough about his thoughts on mobile in education and the future of textbook publishing to want to know more. 2. That he is an excellent presenter and very funny.
- Katrin Verclas, MobileActive — I admire Katrin and her work at MobileActive so much. It is this sort of work that inspires me for what mobile technology can mean for society.
- Luke Wroblewski, Entrepreneur in Residence at Benchmark Capital — I saw Luke speak at Web Visions a few years ago before he got bitten by the mobile bug. His talk was full of both data and insights. Can’t wait to hear more of his thoughts on mobile and try to figure out what his is up to next (ssshhh… It’s a secret!)
And there are many more people I can’t wait to see. I’ve meant to write this for quite some time to say simply, if you are interested in mobile—particularly mobile design—this is the conference you should attend.
I have a limited number of 15% off registration codes for the conference. If you are interested in a code, please leave a comment or fill out the contact form and I’ll send it to you.
I hope to see you in Chicago!
In the midst of the conversation last week about CSS media query for mobile, Brian Fling said, “this is very similar to the ‘one web’ debate which has been raging in mobile for over five years.”
Exactly. In fact, it’s the same debate with new participants.
Blast from the Past: One Web Debate in 2006
Four years ago, Barbara Ballard described the debate like this:
“There are two main camps in the mobile web:
- One Web. The Internet is the Internet, and sites should run well on all devices. Optimization should be based on CSS and device detection, but should not change site function or content beyond the necessary.
- Mobile Web. The mobile is a different platform with different capabilities and different user needs. Sites should be optimized for mobile in many (but not all) cases.”
One of the things that struck me about last week’s discussion of CSS media queries was that there was an assumption on the part of many that delivering a single html document no matter the device was a desirable goal.
Whether people realize it or not, they’ve subscribed to the One Web viewpoint.
By contrast, many of the people who I consider leaders in mobile thought—Brian Fling, Jeff Croft, Barbara Ballard, Cameron Moll, etc.—were quick to point out that delivering different HTML makes sense most of the time for a variety of reasons ranging from performance to user context.
A Contrasting Viewpoint from Opera
In a bit of fortunate timing, between last night when I finished the draft of this post and this morning, Daniel Davis from Opera wrote about his perspective on CSS media query and One Web.
Daniel points out that Opera has “championed media queries for several years now” and points to a dedicated page detailing Opera’s full support of One Web.
Daniel outlines several positives of the One Web approach including “the obvious benefit of having only one codebase, albeit possibly more complex, to update and maintain,” and points out some potential pitfalls of content adaptation including the “there’s always likely to be an off–the–wall or cutting–edge device that falls between the cracks” of device detection databases like WURFL.
Daniel’s article is well-articulated and worth a read.
I don’t disagree with the points he makes about appeal of delivering a single HTML document, but I have yet to see anyone do it on anything other than small sites and personal blogs. And even then, the ones I’ve seen suffer from the performance items I mentioned last week.
Opera has been promoting CSS media query for mobile for several years and has a stated position on One Web, yet it doesn’t use these techniques for it’s own site.
Daniel writes that if his team “had more control over the company-wide CMS.” I wish that they did as well so we could see how they would build it.
So here we are several years after the One Web debate started and it’s easy to find sites that are based on the content adaptation and provide different html and assets based on the device class.
But outside of personal blogs and demo sites, it is difficult to find examples of pages based on delivering the same HTML to every device and using Javascript and CSS to progressively enhance the content.
Translation: We Don’t Deliver Single HTML Documents Now
Anyone who has worked on a site that supports multiple languages knows that we don’t have One Web on the desktop web. We don’t have any problem delivering different html documents and assets to someone who speaks a different language.
I have yet to see a single article arguing that we should deliver a baseline English version of web page and then use javascript to progressively enhance the page with Spanish or Chinese.
Why is it ok for us to deliver different HTML documents because the user uses a different language, but it isn’t ok for us to deliver different HTML documents because the user is using a different device?
W3C’s Definition of the One Web Does Not Mean One HTML Document
The W3C’s Mobile Best Practices Working Group tackled the issue of One Web long ago. They came to a conclusion that matches up well to my view of the mobile web.
The W3C’s Mobile Best Practices Working Group defines the One Web Principle as:
One Web means making, as far as is reasonable, the same information and services available to users irrespective of the device they are using. However, it does not mean that exactly the same information is available in exactly the same representation across all devices. The context of mobile use, device capability variations, bandwidth issues and mobile network capabilities all affect the representation.
They go on further to define “Thematic Consistency of Resource Identified by a URI“:
Content should be accessible on a range of devices irrespective of differences in presentation capabilities and access mechanism…
A bookmark captured on one device should be usable on another, different type of device even if it does not yield exactly the same experience. If the page that was bookmarked is not appropriate for the device that is now using it, an alternative that is suitable should be provided.
To summarize:
- Mobile devices should receive content that is thematically consistent with the content that someone would see at a given URI in a desktop browser.
- The content, functionality, and appearance of the information delivered to mobile devices may vary significantly from that which is delivered to the desktop web.
This is a definition of One Web that I can get behind.
One Web Means Access to Optimized Content
As more web developers start thinking about and developing for mobile, we can expect to see this debate about the One Web reemerge again and again.
You may not agree with the conclusions I’ve come to about the One Web. That’s fine.
But at minimum, make sure that you’re not simply adopting the idea of a single HTML document as being inherently better without questioning where that assumption comes from.
Is a single HTML document the best solution for your users? Or is it simply the best solution for you?
To me, One Web is about universal access to information, not delivering the exact same code, assets or even content.
In my vision, I can send a url to someone and know that no matter where they are in the world, no matter what device they are using, that they will be able see that information in a way that is optimized for them.
Some of the research we’ve been doing into mobile operating systems and browsers is now available as an article on O’Reilly Radar. Here is a short excerpt:
In 2006, two mobile operating systems controlled 81 percent of the market. This year there are 10 different smartphone operating systems.
Over that same period of time, mobile browsers have gone from many different proprietary rendering engines to the point where WebKit alone will power browsers in more than 85 percent of the smartphones sold.
Read the more of Mobile operating systems and browsers are headed in opposite directions at O’Reilly Radar.
We wrote the book:
Recent Comments