Mobile devices with touch-screens are starting to be more and more popular. When you’re building your site or web app, you should take this in consideration when designing the interface. Some people might use a mouse, other will use the fingers. This two have different needs and limitations, but with a little planning you can make the most of both.

Drop-down menus

First of all, when designing a drop-down menu, the trigger should have a visual hint, to let the user know that there’s one. It’s usually a small triangle, or arrow.

Horizontal menu prototype. Can you find which option has a drop-down?

Upon clicking the option, or sometimes on mouse over, the menu expands. How should it behave in order to provide the best experience for mouse and touch-screen users?

The expanded drop-down menu.

Most of the options that trigger drop-down menus that I see online, usually behave differently upon mouse-over and click. Typically mouse-over expands the menu and clicking takes you to a different page. In this case, a touch-screen user will never see the menu.

This is how your horizontal menu should behave.

Most of the times, the click on the option that expands the menu is really unnecessary, because it just takes you to a page with a more or less complex list of the drop-down menu options. It just adds one more step.

As I state on the picture above, you should trigger your menu with a mouse over or click. This approach will be acceptable for mouse and touch-screen users, providing real shortcuts for both.

What happens after the drop-down menu is expanded?

As any normal drop-down menu, you can close it with the mouse out event. It’s an expected behavior for a mouse user. But what if you don’t have a mouse? How can you close the menu if it doesn’t have the option you were looking for?

The answer is simple: Another click on the same button, or anywhere else on the page, should close it. This closing behavior can also be hinted by the change of the icon on the button, as you can see on the picture.

Be careful when using a time out to close your menu. You can program it to close after, let’s say, 5 seconds. This time can be more than enough for some people to check if the menu has the options they’re looking for, while others might find it too short. This kind of events should be tested and only be used if there is a real advantage – most of the times there isn’t.

Mouse over candy

You can have a mouse over candy on your menu. However touch-screen users won't see it.

Remember that the mouse over effects can’t be seen by a touch-screen user. These can be used for visual hints only when using a mouse. Fancy menus like like the Lava Lamp Menu, for instance, don’t look that good on a tablet.

Visual information upon click will be visible to both mouse and touch-screen users.

Active states and mouse down effects are also advisable. These provide a response to the user action. It could compensate for the lack of a mechanical response that you have on a physical button or keyboard. By having a down state, you remove the doubt of the user’s mind: “Did I really tapped it?”.

This is more important when your site takes more time to respond. When the user taps something, he expects a result. If nothing happens straight away, he’ll tap again, and again, and again, sometimes with disastrous results. The down state can help prevent this.

Mouse over exploration

You should never rely on mouse over alone to reveal or help navigation. On the image below there’s an example of a carousel used at Delicious.com.

Delicious.com carousel. Static.

Without a mouse over you don’t have any clue that you can scroll it. In a carousel like this, you should allways have the arrows on each side, to serve as visual hint for the user, to let him know that there’s more information. A mouse user would click the arrows, and a touch screen user could tap the arrows or drag to scroll.

When you put the mouse over it, you'll see that there's more to it than meets the eye.

Another good hint would be if the carousel scrolled automatically from time to time, which it doesn’t.

Different behaviors for different platforms

If you want, you can detect the OS or system that’s accessing your site and deliver different contents/behaviors for each one. On the carousel pictured above, one could detect the access through a mobile device and display the navigation arrows.

I really don’t agree with this way. Your user might be accessing your site or web app on a tablet and later access it through his computer. If you change things, the way it works or the visual language, you’re creating a barrier. You shouldn’t make your user learn it, or try to figure it out again.

Finger sized elements

Another thing to take into consideration, is that a finger is not as precise as a mouse cursor. When creating your clickable elements think about two things:

Size and Proximity: Your elements should be big enough and sufficiently far apart for a finger to tap them without error.

Placement: Is your element correctly positioned so that it is usable by a touch screen user?

Size and Proximity: Which one do you think is more suitable for a touch screen user? If it's good for the finger, it's good for the mouse.

Placement: Remember that on a touch screen, the user's hands hide everything below the elements. Here are some examples of elements that clearly don't work.

Final considerations

Tablets, smart phones and even some desktop computers have touch screens, and these are starting to be a more usual way to get to websites or web apps. When the users use their fingers, there’s no mouse over, and you shouldn’t cripple the navigation because of it. Do not rely on things like tool tips to explain what a certain icon does. Everything should be clear and self explanatory.

Good usability is invisible. People use it without thinking about it or without having to stop to ask for directions. So make your layouts and interfaces so clear and transparent that they become invisible (but beautiful).

The Pros

More screen real estate – On a big screen this might not be a big advantage, but if you’re using a netbook, or even a tablet, every pixel counts. Removing a 30 pixel bar is not that bad. Yes there’s still a top bar, but in some places, like Google Docs and Gmail, it was redesigned to save space.

Kind of a start menu – Don’t you think it looks a bit like the Start menu used on some OS? It is a familiar way to display the links/apps, but then again, the Operating Systems always have an alternative way for the user to quickly get to their most used or favorite applications. With Google there’s not such option.

More Options – Being a vertical menu, it has much more space for more options. Will it grow? I hope not, it’s quite elegant the way it is.

The Cons

What other Google services? – By hiding their services on a drop-down menu, visitors won’t immediately see the other services that Google has to offer. They’ll have to be curious enough to put the mouse cursor over the logo and wait to see the menu. However, they did a smart workaround, turning it to a possible advantage: Whenever you enter Google.com, it’s fully opened. This way, the other Google services might even get more attention, as opposed to being on the top bar, where they might pass unnoticed.

Where is that Docs shortcut? – Going from the top bar to a menu takes some getting used to. The thing I find more awkward is waiting for the menu to open and then slide the cursor down to the Docs option, compared to the top bar, where you looked up and your hand would instinctively follow your eyes to press the desired option. It’s not that serious but that bit of a second when you must think about what you’re doing to get where you want, I consider it an issue.

Why did you have to change it? – There will always be people that hate change. Even if you prove that the new way is better, it will happen. Google usually gives the user a keep it the old way option, I’m not sure it would happen this time.

The new Google drop-down menu.

In conclusion

So is there room for improvement? Right now I can think of at least one thing: How about if Google lets us organize the items order? That would be nice. This way, we could place our most used services on top and it would even ease the “Where is that Docs shortcut?” problem that I talked about.

As for the menu, I believe it is a nice step towards the modern design that Google is implementing, despite some disadvantages that I talked about. And if it doesn’t work the way it should, you can be sure that they’ll take it down or change it completely.