Web Design with Thumbs in Mind

Anyone with a big phone knows that the comfortable reach of your thumb when holding the phone in one hand does not extend to the top corners of the screen. Far from it. The only comfortable area of reach on larger phones is in the lower ½ to ¾ region. (Scott Hurff wrote a great piece on this which includes some pretty compelling graphics of “pain maps”. Definitely worth a look.) Even so the traditional position of main navigation and other interactive elements has been at the top of the screen, often a Hamburger icon in the top left corner.

This is design based on convention and laziness, and it ignores the reality of current user behavior – which is holding a large phone in one hand.

Observe as I use my statistically large hand to navigate a standard website on my not-quite-as-large-as-the-gigantic-iPhone-Plus Sony Xperia Z3:

Painful, and dangerous as the thumb reach makes me prone to drop my phone.

Design with Thumbs in Mind

At WordCamp Miami 2015 I presented the slide above and suggested maybe a better position for important navigation would be on the bottom of mobile screens in easy reach of the thumbs of its users. This is hardly revolutionary, but it still a rarity on the web.

This design pattern is now starting to pop up on sites all over the mobile web (I’m not taking credit for this btw. I’m just observing what’s happening). Or rather, a version of this pattern is appearing in which the mobile screen is divided into two sections: A high interaction area at the bottom of the screen and a low interaction area at the top.

On phones, the top part of the screen is a low-interaction area while the bottom is a high-interaction area.
On phones, the top part of the screen is a low-interaction area while the bottom is a high-interaction area.

What’s interesting about this is it allows us as designers to decide what type of behavior is to be considered high interaction and what behavior is low interaction.

In the examples below, from CarThrottle, Gizmodo, and Medium respectively, overall site navigation and interaction is placed in the low interaction area while the high interaction area is populated by content interaction tools like social sharing, liking, recommending, and saving:

The high interaction area is typically populated by social media and other content interaction tools.
The high interaction area is typically populated by social media and other content interaction tools.

On other sites, like Quartz below, social sharing and content interaction elements are placed in the low interaction area while site navigation is found in the high interaction area:

Quartz has flipped the script placing content interaction in the low interaction area and site navigation in the high interaction area.
Quartz has flipped the script placing content interaction in the low interaction area and site navigation in the high interaction area.

I’m tempted to infer from this something about the overall goals and intentions of the respective sites: The use of the two interaction areas is obviously deliberate and meant to make certain types of interactions easier for the visitor. Based on this we can stipulate that while CarThrottle, Gizmodo, and Medium are mainly focussed on single content items and social sharing of these, Quartz puts greater emphasis on keeping the reader on the site and getting them to dive deeper into the content.

This is of course pure conjecture.


With these newly defined interaction areas, whether by design or by accident, one particular anti-pattern is emerging, as exemplified by Forbes and IFL Science:

Some sites choose (by accident or design) to place 3rd party ads in the high interaction area.
Some sites choose (by accident or design) to place 3rd party ads in the high interaction area.

The choice to place 3rd party advertising in the high interaction area by these and other publications creates a situation in which it is easier for the user to click an ad and leave the site than it is to interact with the content or site itself in a meaningful way. It is tempting to think that this is intentional, but I am inclined to believe this is either a matter of poorly informed design or clever advertising networks taking advantage of old design patterns. That said, Forbes also forces the user to go through a full-page ad before accessing their content, so…

Building Interfaces for People

The conclusion here is pretty obvious: If you want the people who visit your sites to interact with them, place your interactive elements in the vicinity of their interaction tools. On a computer or laptop, the natural place is either at the top of the screen with the other chrome elements or in the context of the content. On mobile screens, that is most likely along the bottom of the screen.

App developers have known this for ages, and most apps have all their major interactive elements in the high interaction area. Now it’s our turn to make the web more thumb friendly.


The Hamburger is Bad for You

A couple of weeks ago I came across this tweet from Luke Wroblewski:

It asks a the simple question about people’s general understanding of the hamburger icon and links to a larger conversation on Twitter on the topic. If you don’t have the time to read through the 20+ tweets here’s the gist: Anecdotal and somewhat scientific evidence indicates people do not intuitively understand the hamburger icon as an indicator of a menu but have to learn its function. Pardon me as I feign shock and surprise.

A hamburger by any other name…

Did you ever wonder where the hamburger came from? I’m not talking about the incredibly inaccurately named ground-beef-patty-between-too-buns meal option here nor the first use of the hamburger as a symbol for a menu. I’m talking about the actual hamburger icon itself. If you think it was invented by Apple or some genius designer you are about a mile and a half off. The hamburger is actually a symbol known as a “triple bar” used in logic and math to mean absolute equivalence or identical. I have stacks of notebooks full of logic trees and calculations littered with these hamburgers from my philosophy days. And that’s where they should have stayed. Instead this symbol, technically described as “a = sign with a third line”, has become a staple of modern mobile, flat, and no-UI design. The triple bar has become identical to an unintuitive and uninformative user experience. Oh, the irony!

Edit April 8, 2014: According to this article the first known use of the triple bar as a UX icon was on Xerox photocopiers. Thanks to Steve M.G. for the tip!

The Fictional Origins of the Hamburger

For the past week I’ve been theorizing as to the origins of the hamburger as a menu icon. I say “theorizing” because I don’t have the patience nor desire to dig up the actual origin of this idea. Here’s what I imagine happened:

A designer at a company named after a fruit … let’s call it “Pear” … is making a new user interface for the company’s new phone called the oPhone. Said designer discovers that there is very little screen real estate on the oPhone and decides to hide the context menu under an icon. “Hey, Stefan” he shouts across the room to the boss: “What is the universal icon for a menu?” “How would I know Johan” Stefan responds. “Just rip some underused icon from the database like we did with the Abilities button on our keyboard!”

And thus the hamburger was born. (The accuracy of this fictional account is irrelevant).

After its introduction as a menu icon the hamburger has become prevalent throughout the web and in web applications (I can see it in the top right hand corner of Chrome as I write this indicating the settings menu). But the hamburger is also used for several other things in those same applications, most notably to indicate that items in a list are draggable and sortable. Which makes little more sense than its use as an indicator of a menu.

The Meaning of the Hamburger

It’s pretty obvious why the hamburger is meant to indicate a menu: If you really want to it kind of maybe just possibly theoretically might maybe look a little bit like a vertical stack menu. In the same way that the letter ‘L’ looks like a shoe.  The problem of course is that it doesn’t look like a menu unless you already know that it’s supposed to look like a menu. What we have here is a classic case of theory dependence and tacit knowledge: The designer and everyone involved in the application being built know from experience that the hamburger means a menu and thus they assume it’s intuitive. What they fail to remember is that the first time they encountered the hamburger they did not know what it was and had to be told like in the screen grab in Luke’s tweet:

So what does the hamburger look like? Ignoring the actual meaning of the triple bar here is an unordered list of things it does look like:

  • A hamburger
  • Three shelves
  • The jQuery UI accordion
  • The black keys on a keyboard seen from the top at a 90 degree angle
  • A crosswalk
  • … three black lines

In truth the triple bar / hamburger only looks like a triple bar, because that’s what it is. It is only through an incredible feat of skeuomorphism it comes anywhere close to looking like a menu. Which is strange considering the reign of the hamburger was brought on by the move away from sekuomorphism. So the hamburger is really an anti-pattern!

No hamburger for you!

You may have noticed that my designs never feature hamburgers. The theme you are currently looking at has replaced the hamburger for the word “Menu” which in my view is far more descriptive. And when I use icons I try to use ones that indicate actions (arrows, plus or minus, etc) because I am cognizant (I mean “mindful” – gotta stay on trend) of my own theory dependence and work to keep my knowledge focal.

I believe in providing criticism only when it is constructive and I truly wish I could serve up a new and perfect menu icon to solve the hamburger bloat once and for all. Sadly I don’t, at least not yet. In place of this I have a couple of suggestions to curb the desire to use a hamburger as a menu icon:

  1. Try using the word “Menu” instead
  2. Consider using a down arrow or another active icon
  3. Reconsider the menu position and function
  4. Use an off-canvas menu and use a tab with an arrow to indicate active interaction

There is a lot of chatter about the unintuitive nature of the hamburger in UX circles right now and I have no doubt that in due time someone will come up with a new and better icon. It might even be you! In the meantime I urge you to abandon the use of the triple bar as anything other than what it actually is for – logical identical – and find better solutions to your menu woes.

Further reading

Mobile Navigation Menus and Great User Experience – Newfangled


Design Projects – Metro and WordPress hand in hand

WordPress + Metro style + responsive design. That was the baseline when designing and building – the Microsoft Expression Blend Team Blog: Create a modern design that used the latest in web technologies (HTML5), played well with mobile devices and reflected the new and quite different look of Microsoft. Though the site launched in late December I haven’t had time to write about the process until now, so here is a quick rundown how came about and how we handled the challenges inherent in the project.

Metro + WordPress

One of the most important aspects of the new site was a strict adherence to the new Metro design language introduced by Microsoft. If you are not aware of Metro yet you will be. This new/old style is starting to make its way into everything Microsoft does, from cell phones to web apps and eventually on your desktop through Windows 8. I say “new / old” style because Metro harks back to the classic Swiss style clean typography trend that was introduced early in the 20th century in Europe that is still a staple of choice for typographers and designers to this day. When I think Metro I think, literally, European Metro stations: Clear sans-serif font on solid colours. You can read more about the Metro design language at WikiPedia and all over the web.

The design principles in the Metro design language are fairly simple: Solid colours, sans-serif fonts, lots of white space, edge-to-edge images with overlays. But as any designer knows, minimalism is not as easy as it seems. By adhering strictly to these rules you have nothing to hide behind. The typography and layout is centre stage and any misjudgement on your part becomes glaringly obvious.

Though there have been some forays into Metro style WordPress themes before I had yet to see one that really captured the essence of the style when I started the project. At the same time I did not particularly like the way Microsoft themselves were using the style on their own websites. They seemed to still be stuck in the old way of doing things and not quite willing to embrace the big fonts and white space as much as they needed to. As a result I was basically starting from scratch, which to be frank is a good thing even though it’s more of a challenge

Breaking the grid

The first decision I made in my drafts was to break the grid. With the introduction and convergence to mobile devices on the web, the traditional grid with massive sidebars and rigid section designs seems obsolete to me. What I wanted to do was bring some of the mobile experience to the desktop while still retaining a sidebar and typographical line width. The result was a full spanning header outside the grid with the post content and sidebar below. It’s a simple design trick, and I’m neither the first nor the only one to use it, but it makes for a striking fundamentally different look. Of course this full span header could only be used on single pages and posts, but seeing as most visitors these days land on single pages or posts first and only later venture to the index pages that is not a big concern.

Metro icons

One of the features of the Metro design language is heavy use of icons. When I started the design I was concerned about how I was going to find the correct icon sets, but after reading documentation and watching videos published by Microsoft I found a hidden gem of information: The Metro icons are actually just standard Windows font icons. That made things a lot easier and apart from the calendar icon which I had to make myself all the icons on the site are rendered from the Segoe UI or Wingdings fonts.

Metro style Facebook facepile

I am not afraid to voice my disdain for Facebook’s draconian design implementation, especially where their social widgets are concerned. Out of the box Facebook like boxes, facepiles and other widgets look like… Facebook, and that does not jive with Metro at all.

In early drafts I had to work around the hideous Facebook like box and it was driving me crazy. In previous projects I had been able to manhandle Facebook’s API and override their stylesheets, but it looked to be impossible due to deprecated code.

Then I  made a chance discovery that though deprecated, the Facebook Fan Box is still active, and unlike the horrid Like box, the Fan box allows some level of customization.

I’m not going to go into great detail about how exactly this is done (there are tutorials out there that have covered that extensively), but as you can see I was able to Metrofy the Facebook facepile into something resembling acceptable.

Responsive Design vs Pixel Perfect

As of 2012 Pink & Yellow Media has converted to a mobile-first design strategy, but we took a head start with One of the key requirements of the project was that the site play nice with cell phones and tablets as well as the traditional computer (as should all websites built today) so the site was designed with the smallest screen – a vertical mobile screen – in mind from the get go.

Rather than following the traditional path of a fully fluid layout, each component of the layout was handled on its own and media queries were inserted at incremental points to properly position each item for any screen size. My thinking is that if the site is to be responsive, it should format perfectly to all screen sizes, not just the predefined mobile-horizontal, mobile-vertical, tablet-horizontal and tablet-vertical sizes. At the same time I want to give the content as much space as possible to always showcase what’s important.

The result of this responsive-but-pixel-perfect approach (you may call it nitpicky if you like) is that as you resize your browser window you’ll see the content jump around and conform not just to the mobile sizes but also to any random desktop window size.

A responsive slider

The design spec called for a slider. I personally hate sliders, but they are all the rage and any website worth its salt must apparently have one. Now sliders are easy to build, as long as they have a fixed size. When you start talking about responsive sliders, things get tricky really fast.

Sliders are usually based on one of two principles: Either you have a long horizontal or vertical row of images and / or content where only the content in the slider window is visible and then you just shift the row left or right to display he new items. Or you have a window that toggles visibility on and off for different layers of content. In either case you use JavaScript and CSS to make everything work. But problems arise when you start messing with the size of the window:

First off you have to consider what happens to the images. Do they resize with the window? Or do they just get cropped. Secondly you have to consider what happens to any text superimposed on top of the images. Does the text shrink with the window, or does it reorganize? And what when it starts to cover the text entirely? Thirdly, are you going to let the box resize both vertically and horizontally or just one or the other?

All these questions are actually design decisions, and they were made in the draft stage. But when I had a clear idea of what was going to happen to the content as it was resized, I needed to find a responsive slider solution that worked. And I also wanted one that was semantically sound and standards based. Not an easy task. But after a lot of searching I came across Mat Marquis excellent Dynamic Carousel (Github link) which fit the bill almost perfectly.

WordPress and Microsoft? Yep, and it’s hosted on Windows!

The final requirement for the project, though an implicit one, was that this WordPress site had to be hosted on a Windows server. I know that sounds like heresy to a lot of WordPress users, but it is sound – at least as long as the server runs properly. We had to go through several hosts before we found one that had a properly installed and configured Windows Server implementation that would allow us to run WordPress without a hitch (GoDaddy’s Windows hosting for example was about as fast as skateboard with wheels made of Play Dough) but we did end up with a workable solution and the site now runs smoothly on Windows.

Check it out and let me know what you think

As with all my other projects is a bit of a work in progress so I’d love to hear what you have to say about it and what you’d like to see changed or updated. I would also like to hear if anything on the site warrants a tutorial. Drop a comment below and let’s start a conversation!

Design MIX11

User behaviour and interaction tracking with IOGraphica

IOGraphica map of a 3 hour projectDuring Sara Summers‘ talk Get Real! Sketch, Prototype, and Capture Great Ideas with Expression Blend and SketchFlow at MIX11 the question of recording user interaction and mouse behaviour on a prototype or a real application or website. In the talk Sara touched on how you can use SketchFlow to record user interaction with active elements such as buttons, but the question concerned live tracking of all mouse movements — i.e. where the user moves the mouse to, where she leaves it to rest and generally how she navigates the site. That made me realize I never got around to writing an article on how I do this with the free art tool IOGraphica so I guess it’s time I do just that.

What does your mouse tell you about your tools?

When you build applications or websites you (should) spend a lot of time thinking about how to make the user interface as intuitive as possible. That means placing navigation and key elements in the most obvious places and make them so that the user finds them easy to interact with. But there’s an additional layer to this process, and it is one that is usually ignored unless you are working for a large company: Actual live user behaviour.

Let me give you an example: Say you design a website with the main menu on the top left and a call to action button on the middle right. This configuration would likely lead to the user first moving her mouse up to the top left and then down to the middle right. Because most web users start their web surfing by placing the cursor at the front of the web address window it means you have created a situation in which they make a left reclining V movement to interact with the site. This is inefficient, but you are not likely to ever know because all you see are the actual actions (click) on the website. To discover this created behaviour you need to actually watch the mouse move in real time or record it.

Recording what matters

If you are working for a huge company with a UX department you likely have the fancy, advanced and expensive tools to do proper real-time interaction and behaviour tracking. But chances are you’re not and those tools are both well beyond your reach and also well outside of the scope of your work process. Typically this is solved by either doing live interaction testing where you literally sit and watch someone else work with the site Big Brother over-the-shoulder style or on a separate monitor or you record the session with a tool like Camtasia for review later. Both of these processes gives you some idea of what’s going on, but they are neither time effective nor conclusive. To be frank watching people surf the web and interacting with applications is mind numbingly boring and it’s exceptionally hard to glean anything from it.

More importantly though, the real-time watching procedure doesn’t actually provide what you need which is a map, taken over time, showcasing overall trends in behaviour. In other words, it’s really just a solid waste of time. This is where IOGraphica comes in.

Using an art tool to make valuable data

My experimentation with IOGraphica, a tool created by Anatoly Zenkov and Andrey Shipilov, actually started out of pure curiosity. I had seen an article on the tool hailing it as a way to create cool art from your day-to-day work routine. IOGraphica is a simple Java app that runs on your computer and records all mouse movements, pauses and clicks for however long you want it. You simply download it, boot it up, click the play button and work normally. It has some very basic settings to turn mouse pause recording on and off and to add the desktop as a background but beyond that it’s as simple as can be. If you take a break you can hit the pause button and when you’re done you simply stop it and save the image.

What you get from IOGraphica is a visually stunning image of your mouse behaviour over the recording time period. With the mouse pauses turned on it looks a bit like a highly organized random doodle with ink spots all over the place.

The description of the app as a tool for making art is accurate — the output has an artistic flare and you could definitely print and frame it, but there is a much more important use for it: IOGraphica gives you a clear and often quite surprising picture of how people actually behave on a site or application. And because it is recorded over an extended period of time you uncover strong trends and get a very clear idea of whether your tools, layouts and designs are organized in a way that makes sense to your users.

The image above shows my interaction with PhotoShop over a 3 hour period while I was working on a redesign of a site. I recorded it to test IOGraphica, but once I saw what came out of it I realized I’d gotten way more than I expected. Looking at the map I saw that my workspace layout was quite inefficient. The largest clustering was in the middle where the actual design work took place, but there was also a lot of traffic going to the top left and bottom right corners. This is where I had my tools and layers respectively. On closer inspection I also found that I often traversed the entire diagonal of the screen from tools to layers or vice versa, the longest distance possible without making any curves.

Two things became obvious: First of all I am far less good at using keyboard shortcuts than I thought. Secondly the default position of the tools is inefficient. For quicker work and less mouse movements I should place the tools and layers directly next to one another. Now imagine what the same process will say about your apps and sites.

IOGraphica user interaction recording scenarios

Incorporating the IOGraphica tool into your user behaviour tracking (and incorporating user behaviour tracking in your overall design process) is a simple process, and it’s one you can do either locally or remotely. It requires the Java Runtime Environment (JRE) which is about a 5 minute download and install. IOGraphica itself is a standalone application consisting of one executable file and requires no install. There are versions for Windows, Mac and Linux.

Once you have the application, simply start it, choose whether you want to record pauses or not and click the Play button. If the user needs a break or has to leave the application you can pause the recording temporarily. When the testing is over simply stop the recording and save the file. You can then choose to save it just as a behaviour map or as a behaviour map with the desktop as a background. Or you can do both. Since the application doesn’t record the desktop itself you simply place the application or website you are testing in the front view and save it to get the map superimposed.

The key to making this work is to ensure that the user only uses the application or website being tested and that the recording is done over an extended period of time. Longer time means a more statistically relevant result.

Because of the nature of IOGraphica you don’t actually have to be present when during the testing, and you don’t have to do it on your own computer. You can simply send IOGraphica or its link to your tester along with the application or site to be tested and some basic instructions and have them do the actual test on their own time. Because it runs in the background and is dead simple you’ll end up with valuable data from multiple sources and you can do some pretty advanced testing without ever leaving your office.

Cool, eh? I think so.