The MEX Mobile User Experience Awards shortlist was unveiled yesterday, and we’re thrilled to bits to hear we’ve been shortlisted in both the Commercial category and the Innovator of the Year one.

We’re shortlisted alongside some very cool companies, like Vuzix, who make virtual reality glasses - which friends of ours have been known to use to marvel at the back of their own heads - as well as Mobyko and Zeemote.

The winners will be officially announced at a special evening reception in London on 27th May, the opening night of the 4th annual MEX conference, and we’ll be there with our fingers crossed!

Recently we gave our results page a facelift. One of the ways we’ve made the page cleaner is to simplify – we’ve removed the source URL string from the results page.

In the past we thought it was a good idea to display it. At the time it made complete sense: it helps the user decide the relevance of the result; A video from ‘youtube.com’ may seem to be more attractive than one from ‘zooblr.com’. Many of the big players (Google, Yahoo!, etc.) display the source URL on their result pages. But the interaction within Taptu is very different - click a result in Taptu and you’ll be whizzed to a mobile-friendly Taptu Summary page. Do the same in Google Mobile and you’ll go to a transcoded source site.

People have established perceptions of how a search engine should work. When a URL is displayed beside a link, first-time users perceive it to directly link to the external site – in the old version of Taptu at least, the user’s expectation would differ to the actual behaviour.

So for now at least we’re experimenting by removing the URL. What do you think – should we continue to display it? Did you find it useful?

As mobile UE designers, we face a constant challenge - how to offer our users lots of great features without creating a complex experience for them?

Within our team, we talk often about the experience we want to create - as people use our service for the first, second and future times. We work to create an experience where features are ‘revealed’ to users as they choose. We want this to happen progressively over time, so the user deepens their experience with the service under their own control.

Rather than purely taking in consideration what features to include in the service - which is what Kathy Sierra refers to in her Featuritis Curve below - we look at how the features could be unveiled so that the first visit isn’t overwhelming! On a mobile phone in particular, where we face constraints of limited screen space, network latency and navigation, it’s crucial that we fight the urge to tell a user everything at once.

Some users just want a simple search experience. Others will want to share what they find with friends by SMS. Others will want to broadcast a link to all their friends - direct to their favourite social network or microblog feed, (i.e. Twitter). We need to consider every one of those scenarios when designing.

For the first time user, our service is clearly a mobile search engine. We keep it simple and don’t offer stacks of features that will overload them either onscreen or cognitively. As users explore the service, they can discover other features - or ignore them - as they wish.

There is a concept in User Interface (UI) design called progressive disclosure, which Jakob Nielsen referred to in 2006.

A classic example of progressive disclosure in computer software is the ‘Print’ dialog box displayed when printing a document. First, you’ll see the dialog which shows only a few important options. If you want to, you can also ‘disclose’ a whole range of other settings/controls - the ‘advanced mode’ - peeling away at the layers of the onion until you get to what you need.

As a concept, progressive disclosure is similar to what we’re trying to achieve with the user experience of Taptu. We want this approach not only to work at individual widgets level, but to underpin the whole service experience as it unfolds to our users.

Have you used a service that gave you this feeling of revealing features? Or one that utterly failed at it by either overloading or hiding them too far away? We’d love to hear more about any you think do it well, or not so well!

Everyone has a first time. It’s a special moment, one where we enter a world of unknown and uncertainty, fumbling around and finding enjoyment in the discovery.

I’m talking about the first time we design a mobile site. Obviously. Ahem.

So since everyone’s got to start somewhere, here are some choice resources for anyone new to creating for the mobile web. It’s one thing to create a design and hack some code together, but don’t forget the importance of testing and promoting what you create!

Designing

• Sitepoint’s Brian Suda writes about the basics of designing for mobile, starting with thinking about screen size and why these people are coming to your site.
• Sender 11 is an extremely useful blog on mobile interaction, filled with great posts and tips on designing for mobile
• Oriented towards the iPhone, A List Apart suggests ways to exploit the unavoidable device with Mobile Safari and beyond.
• For those of us who still occasionally crack a book open, Cameron Roll’s Mobile Web Design comes highly recommended.
• Even further, if you enjoy social interaction, you might like to take part in a MobileCamp, which is an opportunity to get together with people who work in or love the mobile world. It’s a great place to swap ideas, find new development partners or just check out what everyone else is up to.

Developing

• ThinkVitamin: Coding for the Mobile Web gives tips and tricks to help tackle mobile-specific issues.
• W3C Mobile Web Initiative provides information on mobile development standards.
• Considering mobile billing? Why not let experts like Bango take that challenge head on?
• DotMobi and Blue Flavor produced a Mobile Web Developer’s Guide last year to give a boost to both new and experienced mobile developers. I hear a revised version is on its way, but until then, last year’s edition is still helpful.
• If all else fails, adapt your desktop site using Mowser and let somebody else do the hard work.

Testing

• Ready.mobi: Score your mobile-readiness with this useful tool provided by dotMobi
• DeviceAnywhere is the de facto commercial testing tool, allowing you to test mobile sites on a wide range of networks and devices.
• Tarek Esber wrote a great post about mobile device testing services and products, ranging from non-profit services to manufacturers’ own developer portals and other options like emulators and outsourcing.
• Forum Nokia Launchpad is a cheaper alternative to the Forum Nokia Pro program, for those who are developing mobile applications.
• Only available to the American market is Amazon’s Mechanical Turk which can be used to outsource testing. Your mileage will most likely vary, depending on the complexity of the testing you require.

Promoting

• AdMob is the largest mobile advertising network out there. Useful if you’re looking to either publish ads on your site for some revenue, or if you want to advertise on other sites.
• Wapreview is not only an excellent blog by Dennis Bournique, but also an index of useful mobile sites, all rated out of 5 for content and usability.
• Twitterfeed allows you to automatically share your blog entries to your Twitter feed. Why not create a feed of mobile-friendly content for those mates of yours who mainly use Twitter from their phone? They’ll love you for it!
• AdSense for Mobile Content: Google’s widely used ad network is also available on mobile. Like AdMob, you can sign up as advertiser or publisher to meet your promo goals.
• Got a great mobile site? If we’re not already including it in the Taptu search engine index, it may not be on our radar yet. Email me on vero@taptu.com and we’ll visit your site when we next let the crawlers loose.

Got some resources you want to share?

The mobile web is still only a fragment of the wider desktop web we use everyday, so one of the challenges operators, website owners and users face is how on Earth to cram this big web onto small screens.

Different people tackle the problem in different ways, as the Sender 11 blog points out:

Apple: Adapt the phone to the web.
Opera: Adapt the web to the phone.

But then, there’s a third option: Bulldoze everything with a transcoder, including sites which are already mobile, and don’t shed a tear for the casualties.

This approach has unfortunately been adopted by a number of operators, namely Vodafone and TeliaSonera with Novarra, and Sprint with OpenWave.

When I think of the carelessness these guys are exhibiting, I get a Hulk moment “Vero angry, Vero smash phones! ARGGHHHH!” It boggles the mind how Sprint can go as far as saying it’s in the customer’s best interest. If they really cared about the customer experience, they wouldn’t highjack user agents, they would acknowledge sites which are already mobile-ready and they would listen to the community’s needs.

Anyone who isn’t directly involved in the mobile industry is unlikely to realise that the site they’re browsing looks crap on their phone, not by the website owner’s fault or because their phone isn’t up to par, but squarely because of the operator’s complete disregard for its customers. A little bit of me dies every time I see a friend criticize the mobile web’s shortcomings when it’s really due to bastardised transcoding.

Operators claim to be offering a proverbial olive branch by telling mobile website owners to request to be added to a whitelist. Dennis at Wapreview sounded the alarm on the latest whitelist to join but this is a neverending game of whack-a-mole! As far as I know, between Spain and the UK, Vodafone doesn’t even share its whitelist! (If anyone can tell me I’m wrong on this one, I’ll regain a bit of faith in the Big Red.)

As Dennis explains, unless you have a handset on the local network, it’s difficult to find out what’s happening to your site once it goes through the shredder:

Unless you have a Sprint handset there’s really no way to tell if your site’s being transcoded. If you do have a Sprint phone you can generally tell just by looking at the screen but if in doubt use the device’s Show URL browser menu command. If it starts with http://sprint.aopwv.com/ you are being transcoded.

Mobhappy, Mike Rowehl, Techype, RCR Wireless News and Semapedia, amongst others, have picked up on the issue, and they’re all as unimpressed as I am with the situation.

How could anyone, in their infinite wisdom, think this was a scaleable and manageable way to decide what sites to leave as-is? Seriously, I’m willing to give anyone from an operator a fair hearing, I’ll even buy ‘em a beer, if they can explain to me how they’re going to improve on the current situation from here.

If you’re a developer and your mobile site is affected by the latest Sprint issue, register on the Sprint forums and leave a comment in this thread to get whitelisted.

[Update: Russ at Mowser posted, following my angry post, to shed light on how what Mowser does is different to the operator’s transcoders, so if you’re still fuzzy on what is proper and improper behaviour for adapting content, check out his post. At the core of it all though, Mowser listen to their users and are part of the community rather than living up in that cozy ivory tower. That makes all the difference.]

In technology, we’re always so focused on the future, on what’s coming next and what’s going to be the next big gadget or web app to break into the spotlight. Gizmodo’s Jesus Diaz looks to the past for the designs that inspired Apple’s products. It’s impossible to deny the resemblance in some of the 60’s styling and our latest shiny goodies.

We’re big fans of great, simple design here, so it’s comforting to think that great design is here to stay, revived in different forms through the ages. I’ve had this quote from Rams stuck in my scrapbook for years now, but it’s good to see Gizmodo bring it up as well.

This passion for “simplicity” and “honest design” that is always declared by Ive whenever he’s interviewed or appears in a promo video, is at the core of Dieter Rams’ 10 principles for good design:

• Good design is innovative.
• Good design makes a product useful.
• Good design is aesthetic.
• Good design helps us to understand a product.
• Good design is unobtrusive.
• Good design is honest.
• Good design is durable.
• Good design is consequent to the last detail.
• Good design is concerned with the environment.
• Good design is as little design as possible.

[Via Thought Balloons]

Computers shouldn’t be unusable. You don’t need to know how to work a telephone switch to make a phone call, or how to use the Hoover Dam to take a shower, or how to work a nuclear-power plant to turn on the lights. — Scott McNealy (via Usernomics)

Contrary to popular belief, one of the biggest challenges we face when developing an application isn’t deciding what features to put in. It’s what features not to put in.

At least once a month, we get some of our users together to play with the latest prototypes we’ve created. But guess what? Few of those actually make it out of the lab. And that’s a good thing, if we put every feature in, you’d need a user manual bigger than the phone book just to get started!

So why do we hold back on all those funky features? As Kathy Sierra puts it, we want to make sure you can kick ass without having to spend too long below the Suck Threshold. In other words, keeping it simple means you can have a fun, enjoyable experience right away.

Even if we liked complicated, whizzy things with lots and lots of buttons, it just wouldn’t make sense to attempt it on mobile. We want fast, easy-to-digest content when we’re on the move, right?

With this in mind, we still want to add the features you’re most interested in. Is it the ability to post your search results to Jaiku or to send them by SMS? What would make your experience more fun? We’re always listening and we will put the best ideas in place.

If you want to make a suggestion, you can…

• leave a comment right here on the blog
• pop your ideas in the feedback form (you’ll need to register first)
• or drop me an email at vero@taptu.com

What would the mobile search engine of YOUR dreams do? (Other than telepathically order the right flavour of ice cream just when you want it, of course. We’re working on that one.)

Having been in Austin, Texas for a few days now, I’ve witnessed one of the greatest social gathering of tech-minded people to ever happen, once a year at South by SouthWest Interactive.

The killer app this year is undeniably… the same as last year. It’s Twitter through and through. In the context of a conference where thousands of people are milling around between panels, looking for each other and the Next Big Thing, Twitter is the killer app. It’s assumed and expected amongst all attendees that, just as we have a little heart pumping on the inside of our ribcage, we all have a Twitter username.

However, the observation that I found most interesting is the energy everyone put into communicating what they were hearing. The Zuckerberg keynote got the room buzzing and, in no time, even bloggers who were nowhere near the event were getting the echos of a poorly led interview. In previous years, it would have at least taken a few hours until someone did a write-up of the keynote, but with these social devices and the perfect system to communicate short snippets of information, it was broadcasted as soon as the sentiment arose amongst the crowd.

I’m at risk of pointing out the very obvious here but the Blackberry - probably the most common phone here at SXSW - is mindblowingly business-focussed. Even the font is dry, harsh and doesn’t make the faintest attempt at being visually pleasing. It is a stark, utilitarian device in contrast to the iPhone’s soft, rounded curves and swish user interface - the other baby of the conference. While each device has its pros and cons - attempts at typing while walking on an iPhone very much results in an epic failure - it’s fascinating that this geekfest brings together the two polar opposites, the functional and the creative, in one place as the two most used devices.

What they have in common is that they bring people together socially. From Ballroom A to the depths of Room 19-B, and from Austin to the rest of the world, they make communication easy. Comforting to know that even geeks need to be social too, no?

A few weeks ago, Matt introduced the User Experience team and gave a first bit of insight on what they do every day. This time, I’ve asked Marc to talk about prototyping and the early stages of creating a new site. - Vero

I’m Marc, a UE Designer working with Matt on the front-end of our mobile web site. A large portion of our role consists of realising ideas and creating prototypes before the production process will begin.

We’ve always been keen on prototyping for three reasons:

1. To design the end-to-end experience
2. To use as a believable product within a User Study
3. And to use as a discussion tool with Engineering.

The level of fidelity for a prototype varies greatly according to the purpose. I’ll talk a bit about each of the three prototyping methods we use in Taptu:

Paper Prototyping

At idea creation, the early concepts are so fluid and likely to change. Because of this we tend to stick with ol’ fashioned pen & paper. Paper prototyping can’t be beaten – even in this digital age, it remains the fastest way to flesh out early use-cases.

It also ensures we don’t get caught up in ‘pixel world’ and other visual design issues until the screen flows, interaction and navigation are all in place. Visual design is so subjective that it’s important to stay clear of it at this stage and stay focussed.
Because we’re talking about little more than just a sketch, it’s quick and easy to just rip a section up and redraw the next iteration.

By the time the scribbles are finalised and we’re happy with the feel of the design and its functions, it’s time to take it to the next stage…

Wireframes

This step seems best suited for concepts aimed at the Desktop-platform. Wireframing in the strangely-named OmniGraffle tool is the speediest method we’ve found. I’ve tried Visio and even Illustrator before settling on Omni. An 80-page spec can be put together with ease, covering all use-cases and page-states. The time we’ve saved documenting allows us to put the time back into designing.

Device Prototypes

This is where we start to focus on pixel detail too. Photoshop is used to compliment the wireframes. Rather than building out each and every page, only the key templates need to be created to avoid repetition.
When it comes to the Mobile-platform, our favoured method is knocking-up static cross-linking XHTML and CSS. This allows us to view the mock-up directly on the mobile, see how it feels on the target platform, and take browser limitations into consideration. Recently we’ve been using the iPhone, N95 and SE W880i as our initial testbed handsets. The Sony Ericssons seem to be pretty popular with our target users – surprisingly, 66% of users in our latest study stated they use a Sony Ericsson.

What happens next?

Well, the above process, although linear in appearance, should be thought of as more of a circle of reiterative design. Each prototype is tested monthly and the findings are then fed back into the next version. The amount of change that is required is usually what dictates which part of the process we’ll go back to refine.

I love tech. I truly do. In fact, I’ve got a severe condition called “gadgetitis”, which becomes particularly acute around tech expos and Christmas time where all sorts of new techy goodies are released. And I love beta versions, even though they’re flakier than Paris Hilton. I love sneak previews, even if the app turns out to only be worthy of the TechCrunch deadpool. It’s a terrible addiction and as far as I know, there are no cures.

By the same logic, I almost always say that the more technology, the better. Almost.

Today’s an exception. This is my plea to the RAC, once my most reliable source of up-to-date traffic news, to step away from the Flash animations and return to this old technology called text. The wonderful thing about text is that it’s clear, succint and doesn’t require any fancy plugins. It’s easy to use when on the road with only a phone at hand.

This new animation completely fails from a usability point of view:

1. It doesn’t respect the KISS rule: Keeping it simple means it’s more widely accessible. Not everyone has Flash enabled. My iPhone certainly doesn’t. :S
2. It’s utterly useless to someone who isn’t local. Very few cities, towns and villages are identified, no matter how close you zoom in. Why aren’t the primary non-motorway roads identified? It’s certainly not because the map is too cluttered!
3. The usefulness of the information displayed is questionable, especially in comparison to the detailed alternative that used to be available. Is the slowdown due to sheer traffic density or are we dealing with a 6 car pile-up where the motorway might get closed? That’s far more likely to affect my decision of what to do next than telling me vehicles are travelling at 10mph.
4. The colours, which represent severity of traffic, aren’t accompanied by a legend, so the user has to guess what the scale is!

With the holidays coming and more people on motorways driving long distances to see family and friends, it can be a lifeline, helping us make a quick decision on whether a detour is needed. I’m afraid that the RAC designers didn’t do their homework here. Back to the drawing board, guys!

[tags]design, gadgets, iphone, mobile, rac, road congestion, traffic, usability, user experience, Taptu, Taptology[/tags]