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!

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.)

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]

The Taptu office is like a buzzing hive of activity on this Monday morning!

We’ll be releasing the beta soon, but first, we all need to put our testing hats on and do our best to spot bugs, flukes and try to break the system. Much to the pleasure of the developers, it’s holding up very well.

Testing on mobile is a challenge on a grander scale than testing purely for desktop computers - Forget IE, Firefox, Safari testing, there are many different browsers on mobile, with screens in sizes varying from 128 pixels to 320 pixels wide and with many different rendering capabilities and standards.

This screenshot gives you some insight into some of the many phones on which we’ve been testing Taptu - it’s enough to give us all thumb-RSI!

[Updated: Slightly bigger screenshot when you click on it!]

Last week, we gave a few tips and highlighted some resources available for those new to designing for the small mobile screens.

Dan Appelquist left a comment linking to the W3 Best Mobile Web Practices flip cards, which are the cheat sheets of mobile web design. They’re an invaluable resource for a designer who wants to understand the different challenges of the mobile screen.

Having had a look at these, I couldn’t let this resource sit only in comments, and wanted to share such a useful tool more prominently. Thank you, Dan!

Yes, much excitement happiness and pleasure in the office today. Us Europeans are a bit behind you Americans with this whole iPhone thing, but today – OhhhMyGaud!!! – one materialised in our office, beamed from Boston to Cambridge by beautiful benevolent angels.

The thing I really love about Apple is the way they wrap their stuff. It’s as if Jonathan Ive finished off the iPhone one hour early on Friday afternoon and he says why don’t I just redesign the box before I go home? In its shiny shrink-wrap it looks like a very expensive little box of chocolates. We decided to give Stef (our CTO) the honour of opening it.

Guess what? Unlike every other mobile I’ve ever bought, it powers up straight out of the box. That AT&T activation message was slightly disconcerting though. I’m figuring their nearest base station is about 4,000 miles away. It took Simon just 3 minutes to locate the code on the Web that would crack it open, and we were surfing away onto our local WiFi.

My first impressions: gorgeous hardware design, clever gesture-driven touch screen concept that works well, easier to enter text than I was expecting, and a GREAT microbrowser. Finally you can see the next big evolution step on the mobile internet, the step that’s going to turn it into a mass market. But it’s still going to need optimisation of web sites and web services for the small screen – surfing normal desktop sites on the iPhone is better than my Nokia N95 but still something that I’d only do if I really had to.

Just one other thing – it did feel rather warm after the whole office had played with it – is it a bit of a power hog or was it just our hot little hands?

The number of web-enabled mobile devices is growing every day. Worrying about how your site looked on a mobile device used to be a fringe issue, reserved for the geekiest and most niche markets, but it is now beginning to rise on everyone’s list of priorities.

Virginia DeBolt writes an article for Vitamin demystifying how to make your site mobile friendly.

“Making your site mobile friendly can be boiled down to a few concepts. Use validated, standards-based HTML or XHTML, ensure meaningful semantic markup with presentation removed to a stylesheet, and add handheld media rules as needed.”

A number of free services are available to help developers test their websites such as ready.mobi and Bango’s own MobileChecker, with the former providing vastly more detailed information on what caused your site to pass or fail the check.

Some sites simply aren’t mobile friendly yet but will contain RSS feeds, which can be consumed via readers like Google Reader Mobile. [As an aside, I’m a huge fan of Google Reader Mobile and will review it in greater details at a later date.]

If you’re a reader of a blog or website that hasn’t put much effort into becoming mobile-friendly, why not drop them a line and suggest it? Sometimes, all they need is a show of hands to get the wheels in motion for a new lush mobile-friendly site. If you’re a designer, what steps are you taking to make your website more mobile friendly? The changes needed to make a site mobile-friendly can sometimes surprisingly small, but will make a world of difference to readers who is using a device with a smaller screen to browse it.

In case you haven’t noticed the links in the top left, Taptology comes in both mobile and desktop flavours to suit everyone. Bookmark the mobile version (http://www.taptu.com/blog/m/) or sign up for the RSS feed to get your daily dose of mobile goodness.

[tags]mobile web, web design, thinkvitamin, taptu, taptology, google reader mobile, virginia debolt, bango, ready.mobi[/tags]