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?

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]

We’re just going through our next major design revision for Taptu, and it reminds me of just how important to us the whole topic of ‘click-distance’ is.

What is ‘click distance’? It is the sum of the number of clicks and the number of scroll actions that a mobile user must make when navigating to a specific item of content. It’s the critical measure of usability for mobile search.

Back in 2002, Professor Barry Smyth of University College Dublin carried out an experiment on the O2 mobile portal. For a sample of 150,000 users accessing the portal via the mobile browser, he measured their navigation behaviour. Specifically he measured the number of clicks and the number of scrolls that they would make on their phone keypads as they navigated the menu structure of the portal in their search for content. From this experiment came a very simple but incredibly important insight: the motivation of most users to continue navigating for content falls off a cliff when the click-distance exceeds 12.

Back at the end of 2005 we carried out our own research study into click-distance performance of mobile search engines. We asked a panel of users which 100 typical searches they would most like to do on a mobile phone, and which search words they would start with. We then selected the most popular mobile search engine, ran the 100 searches and measured the average click-distance. Shockingly, the average result was 36 clicks. It’s not hard to see why mobile search has yet to go mass market when you see a ‘usability gap’ of this magnitude.

When we design a mobile user interface for a device, or for a device family, the desire to minimise click-distance is always at the front of our minds. It’s become the central proposition of Taptu: how to deliver relevant mobile search results in 10 clicks or less. Needless to say, setting the objective of 10 clicks or less is the easy part. For a universal mobile search service, it is a very tough target.

We’ve just set up an internal research project to update our 2005 findings. This time around we have a lot more data on what mobile users actually search for, so our test database can be much more realistic. In the last couple of years, we’ve seen some improvement in the performance of the existing mobile search engines. We’ve also seen new kinds of devices like the iPhone which can do full Web search on a mobile using the desktop versions of popular search engines.

What effect will this have on click-distance performance for mobile search? Keep you posted.

I came across this quote this morning and find it rings very true. We’ve all experienced some great and some very poor User Interfaces on the web, at the cash machine, on our mobile. Things just get far more complicated than they need to be. Nelson Minar highlights how the iPhone takes a step towards simplicity.

While the sleek touchscreen defines the iPhone’s design, one of the things I like about it are the simple mechanical buttons on the side. There’s a dedicated volume rocker which instantly makes the iPhone a better music player than any iPod. But even better is the silent mode switch, an old fashioned mechanical two position switch. Slide it away, feel a satisfying click, and your phone is now in silent mode. There’s even an orange dot visible for visual confirmation.

You can measure the disaster of cell phone UI by how many button presses it takes to silence the damn ringer. My first Nokia phone took 2, the Ericsson took 3, and on the RAZR it’s like 17 button presses. You don’t need silent mode often, but when you do you need it quickly and without a bunch of screen reading distraction. The physical switch for that is lovely.

What can you do today to simplify the process your users go through?

[From Nelson’s Weblog via Merlin Mann at 43Folders]