Recent Blog Posts

We've designed a couple of mobile browsers, which makes us always curious when a new design comes along. (I'd tell you which ones, but alas they've not given us permission). Especially fun is looking at what the browsers do on some of the challenging implementation decisions we wrestled with.

So, Opera Mini 5 has increasing amounts of competition from the likes of Obigo, Bolt, Skyfire, and so forth. Rather than sitting on their well-deserved laurels they took the design to the next level.

I won't really talk about features here; that's well covered elsewhere by folks you trust to talk about such things. Instead, design.

Control overlay is very nice

The most obvious change in design is of course the treatment of the Menu button. Previously, the design was inherited from Nokia UI of over 10 years ago, with a list of available actions in a menu above the left softkey. This time they took an approach similar to Gravity, with overlays showing available controls.

The advantage of this approach is both aesthetic (it's much prettier) and functional. Most softkey menus have just order and label to suggest their functionality; they become unwieldy as application capability increases. Opera Mini 5 uses the same familiar activation of the menu, but then provides a number of controls simply not available in a menu:

• Visual control distinction: Large icons for frequent actions
• Controls beyond just links/buttons: Integrated URL and search bars
• Controls beyond just links/buttons: Access to other tabs
• Progressive disclosure without submenus: Access to less important controls by a second action

And they didn't go overboard. They could have made a two-dimensional grid of controls, adding extra confusion. The control overlay could have been very intimidating, but it's not.

Overlay problems

By putting a "power" button (odd choice, that) in one of the five limited spots in the overlay, the more-used History and/or Bookmarks. By relegating the exit function to the menu, you reduce the need for the exit guard, allow use of the word "Exit," and provide space for other controls.

The forward and back buttons are poor choices for the overlay. The right softkey is also back, so this replicates the function. And the "forward" button remains disabled most of the time, as it is on most browsers. So three of the five controls in the icon bar of the overlay shouldn't be there. No wonder I spend so much time in the little menu.

Perhaps history and bookmarks were relegated to the menu because the quick-dial feature imported from the desktop browser needed prominence. This isn't a great design choice, especially for people who don't save bookmarks but instead use history.

Other visual choices

Page wipe-to-left for "forward" (and its reverse) is interesting, but mistimed and inconsistently applied. You'll have to try a few pages before you can be sure to have seen it, but when you do you'll find that the current page doesn't wipe off the screen until the new one is loaded. This solves the problem of wanting something to look at while the new page loads, but then has the problem of a perceived disconnect between action and result. I'd drop the wiping feature.

Wiping is also inconsistent with the display of the chrome controls. Here, things fly in from the bottom, but then is left and right once in the controls. Disconcerting.

Tabbed browsing, finally

Hooray for tabbed browsing! I can have two tasks going at once. And, unlike the iPhone, it doesn't force a refresh just to look at the other tab. This is terrific, and much easier than the native S60 non-touch browser.

Interface "cruft"

We've been hearing a lot from the design elite about the goal of "the content is the interface." Proponents point to Jef Han's work on multi-touch displays, full-screen browsers, and the like.

To a degree, Opera Mini delivers here. It sports a full-screen mode that lets you really maximize your view. And by putting all of the controls in the overlay, the same keypress that gets you access to the overlay in default mode also gets you access in full-screen mode. Very nice. In contrast, the native browser uses the first keypress to display the title and menu bar; the second keypress actually opens the menu.

I guess we're crufty people around here, but we like using tools when interacting with content. And in Opera Mini 5, the cruft is the weak spot.

Helpless Help

Help has no contents other than keyboard shortcuts and the "about" information. Maybe this is because it's a beta product. But if so, it's (almost) always best to leave a feature out than to implement it half-way. And yes, that counts for not-enough-content.

"Saved Pages" vs. "Bookmarks

Because there is no help, I don't know what they are thinking with regards to "Saved Pages." This appears to be a mechanism in which the web page is stored somewhere on the device, perhaps accessible offline? Certainly I had to approve the application getting device access (no explanation of what access) about six times to use the service.

Indeed, there are three separate ways to explicitly save a site: quick dial, saved pages, and bookmarks. Let's get rid of one of those, and better integrate the other two. Maybe they are, but at least the access methods and names imply they are not.

History

Given the fact that many people use history very extensively, we'd like to see it vastly improved on all browsers. The good: Opera Mini has a clear visual distinction between sites visited "Today" and "Earlier." The bad: when, earlier? And how do I pick between these?

Perhaps it isn't fair to pick on Opera here. Even desktop browsers do this at best indifferently. We'd like to see several changes to the history function. These start with, but are not limited to:

• Define browsing "sessions" within time. "Yesterday around 8am" is contextually different than "Yesterday at lunchtime," and makes it easier to search the way people think.
• Consolidate links for pages that are just refreshing themselves (cough - gmail).
• Go beyond the page title, perhaps grabbing the first h1 in the document.
• Include favicons in the display.
• History search, ideally searching the whole page and not just the title.

Blackberry challenges

I don't have any screen shots for you, but Jana downloaded the Blackberry version. And deleted it, as she couldn't figure out how to use it. She said the controls didn't work.

I still don't like the rendering

Opera hasn't changed some of their core rendering decisions. This is unsurprising, but disappointing. Stuff that is unchanged:

• Ignore the page keyboard shortcuts (access keys) in favor of the browser's.
• Reports itself as a desktop browser, causing sites to render the desktop version even when they have a mobile one they'd presumably rather offer you.
• Insufficient control over screen width. I can't use the desktop version of Google calendar even though I am forced there.

And, rendering bugs

I tried for 15 minutes to sign into ToodleDo before giving up and using the native browser. The page was telling me it was the wrong credentials, but I typed the correct ones. Opera somehow inserted, deleted, or changed characters when sending the content up. I don't know why, but it's enough to make me use the built-in browser instead.

There are several sites or on-screen widgets of one sort or another that tend to cause issues in one browser or another, and seem to not be getting better. To view the whole web, I have to use 2-3 browsers to get everything working. These are usually pretty detailed, niggly things causing failures, such that if I could view a style-less version I could make the site work. Whether that is the right answer, all browsers (not just Opera) that proclaim desktop compliance need to look at how they are being used, and think outside the box regarding workarounds, at the least.

As far as all the not-as-mobile-as-we-wish comments, maybe it's time to start another one-web rant and talk about what the mobile internet should really be offering. Maybe, if we can rope in the right people, that's a good panel for the next Design for Mobile conference.

Are you losing potential mobile users?

A group makes a mobile site or app. When making the desktop site to promote the mobile service, they say something like:

Use your phone and visit: m.google.com/reader

That's a direct quote from the Google site promoting their mobile services. I copied the source code, not just the text.

Usually this emphasized text is also underlined. This is true on the actual Google page with their CSS applied. It looks like a link. That's fine, right? It's a link?

That's the problem. It's not a link.

I thought, "I want to find the mobile version of my favorite service. I will search for that link from the search tool on my mobile." The Google search results were terrific, leading me right to the page where I would find the information I needed. But the link didn't work!

I had to look at the URL, remember it, and then type it in. Bad plan. Most smart phones' browsers will render desktop web pages. And search results will typically return desktop web pages.

Opera also did this last week when they launched Opera Mini 5 beta. I mentioned it on Twitter; they have fixed the problem. Kudos to Opera for monitoring social media. But shame on Opera for not thinking that some people might visit their desktop site from a mobile phone, and make it a link in the first place.

Your simple takeaway: when telling customers how to find your mobile content via a URL, make the URL also a link.

This includes you, Google.

There are a shocking number of jobs available in mobile design these days, and we’ve started posting them over at the Design For Mobile Job Board. If you are seeking a job in mobile user research, design, or usability for devices, apps, services, or sites, this is the place to go. And the rest of the site is good to help you learn enough to impress your future employer.

Want to really impress your potential employer? Become a contributor. Add a platform. Add an essay. Add links. Your name will appear at the bottom of the page.

If you are offering a position, posting is free and self-service. Want to stand out? We’re looking for sponsors.

As those who have tried to call me, or follow my tweets, may know my N95 has been dying for some weeks now. Some audio issues, followed by SIM synch errors, etc.

So since there is some other stuff on the horizon (both in the world, and things we're likely to get into the office) I just went back to the old N75 for a while.

And it totally surprised me. Sure it's got it's issues:

• Limited running memory; often refuses to launch things, hangs, pauses or crashes.
• AT&T put so much stuff on there that cannot be killed (always running), about half that memory is used for no good reason.
• AT&T crippled parts of the phone. Cannot delete or move some of their apps, and cannot create folders, for no clear reason.
• POP port for audio. Meaning I cannot listen to the World Service unless I go to transistor radio mode. Or I guess buy an adaptor. But that's not likely.
• Flip phone. S60 is not set up for that, so it doesn't work flawlessly. Often hard to tell who is calling, for example, and lots of themes don't work quite right.
• No GPS, though cell/sector/triangulation does a pretty good job.
• The AT&T music player is much worse than the Nokia one that came with the N95. Which would be okay if it didn't insist on taking over a hard key and running in the background all the time.
• No WiFi, but I never use that anyway, so I just mention it for completeness.

But what surprised me is how much it pleased me for a slightly operator-crippled two year old phone. And that was all the services that worked (though it did take me a few hours to install and configure this):

• twitter and sms in general.
• Google search from idle screen.
• Gmail.
• Calendar automatic OTA synch (over Google also).
• Maps, with a choice of several services.
• Browsing. With a choice of browsers.
• Address book synch (with some data bugs, I got the company contact list in the phone).
• A better calculator, a good stopwatch and other secondary-use apps I have grown to rely on.

With these, I am 95% back to where I was a couple days ago. I can do almost everything I did with the super-capable modern phones I have been using, just because most apps and services that make my life go are simple, or cloud-based.

The worst parts of the whole experience, in fact, are not the bad parts of the hardware like I listed above. They are the dumb parts of those cloud services. Google maps, for example, forgot all my favorites. It has my search history of all things, and is a cloud app really, so why are favorites stored on the hardware. Opera mini never really synchs right, even when I try to. And so on for most applications.

What I am learning more and more (even though I always knew it in theory) is that it's all about the experience, and not about speed or memory or megapixels or network or any other specs, directly, but about how well the device performs user tasks. To that end, old hardware, or more relevantly a featurephone might do just as well for many users.

It also supports a lot of the opinions we've already had. If you want everyone to use your application, make a mobile website, then a J2ME app, then platform-specific apps. Most of what are regarded as featurephones today can still install Java apps, so can do most or all of the functions expected of any phone, one way or the other.

The increasingly shrill decrying of texting while driving has made me more conscious of the alternatives, and a new problem arises for me as a designer.

Yesterday as we drive home, Alison is talking to my mom about radiation therapy appointments for my dad. Turns out we have the dates and times, so it would be most convenient to just go ahead and add it to my schedule so I don’t forget or have to call back. And our drive is around an hour, so its not totally plausible to just hope we remember until we get home.

So, I hand my phone to Alison who… stares at it. I think it’s trivially easy to use and am likely to keep buying handsets from this maker as a result. There’s a calendar icon right on the idle screen, for example. But she can’t find it. And when I tell her what to click, the calendar works differently from that on her mobile. And the text entry mode is different (space and next keys for predictive, for example, are there but in different places).

Whether it’s showing off pictures of the grandkids at a dinner party or trying to get a passenger to perform some navigational interaction to avoid distracted driving, I see this just getting more and more common.

“This” being the notion of first time use. Most mobile interactions I have worked on focus on learnability and habituated use. Whether it’s about learning the app/site, or just assuming the user has become used to their phone, the personal nature of mobiles means that’s a safe bet. But now I am starting to wonder if it really is.

Even aside from the stuff I do as a nerdy mobile designer shoving hardware into people’s hands – I am seeing more and more opportunities for device sharing. And it seems to be a known, if subconscious, problem to everyday people. Do you hold up the phone to show off the video, or pass it around? When they “break” it, do you tell them what to do, or have to take it back? (And how distracting is it to give step-by-step verbal instructions on using your phone to someone next to you, that you cannot really look at?)

A solution for me would be if all handsets, and all apps on the handset, were easy to understand for first time users. And I mean, arbitrary, ad hoc first time users. For example, I am playing with the Palm Pre; the neighborhood kids often want to mess with whatever new hardware I have laying around, and keep trying it out. As someone who set up a user profile and got the intro video/tutorial thingy, it’s reasonably easy for me to use. But the kids missed this. And there’s no affordances for back, or home, or killing an application. They are savvy enough to know those functions must be there, but still cannot find them.

So a first guideline for me is primary actions have to be obvious. This doesn’t preclude cool shortcuts with gestures or otherwise hidden features for the habituated user. But give an easy-to-use version as well, or add a hint.

Ideally, there would be more shared features between devices so it was clear how to perform at least the most basic functions on any device. Cars, for example, settled some time ago into a standard form, so you know how the turn signal works, and there are only so many ways the headlights are likely to turn on. And if you cannot drive a stick, it’s only one of two likely mechanisms, so you know you can’t drive that right off the bat.

And with these standards, there’s plenty of style, performance, build and design differences between makes, models and variants. For mobile (and really for interactive in general), I hope someday we can settle on some common UI components (and get everyone used to all of them) but for now, the best we seem to be able to do is emphasize guidelines and best practices.

Looking through my own design documentation, I don’t see anything consolidated about first-time use, so I thought about it a bit and have thrown together these guidelines.

Use common metaphors – Even if you are designing something with a different interaction method, you will tend to get far exploiting an existing metaphor. I cannot think of a calendar that uses a wheel or strip or dancing-antelope view; they all look like paper monthly calendars for a reason.

Make behavior predictable – If you employ a common UI element, make it act like it looks. Buttons should… submit things. Little, labeled enclosed areas with down arrows should open up into lists or menus. And if you make a wholly new interactive element, don’t hang it off one of these existing structures; make something new and give a (visual) hint as to what will happen when it’s activated.

Readability – I don’t mean that type needs to be big enough for the elderly, because you should be doing that anyway. I am referring more to comprehension. If someone can just stare at the icons in the footer and wonder what they mean (i.e. always), they need to have labels. If you are not sure, add labels. Or go ahead and test those icons in front of users, but you’ll be surprised at how badly it goes. Even when you think the plus sign is unambiguous, people who didn’t design or develop the product will wonder if it’s to add an event, a person, a profile, an access point, a new document or just opens up the panel to reveal more choices.

Make the structure visible – Your regular user can take time to get used to the underlying information architecture of your device/site/application. And often, it’s easily solved by having them explore (to even get lost they had to drive down from the top level). But casual users borrowing a handset might start anywhere. Do something to make the structure visible, or discoverable. Especially think about how misunderstanding the overall informational paradigm can get in the way of performing tasks. Auto-save vs. explicit-save is a huge problem in this space, and even causes issues when inconsistently employed for habituated users.

I am going to continue to keep my eyes open for interesting behaviors and opportunities to improve this, now that I am aware of it.