Things I’d Like to Not See Again In User Interfaces

Using Gray as an indicator for Off instead of Disabled

Let me show you an example, from the settings screen on my Xiaomi Mi3 phone, running the Miui user environment:

Settings screen

The Recurring do not disturb time toggle button, as awkwardly as it is named, is clearly indicating with a brighter, contrasting color, that it is set to on. Meanwhile, that Do Not Disturb toggle above it registers to me as disabled: it is grayed out and faint, conform to how functionality being disabled has been indicated since the first Macintosh. Well, guess what, it is not disabled, this is what the designers of this system decided off should look like. If you tap it, it will slide to an on state like the toggle below. I have no idea what an actually disabled toggle looks like in this system.

This color scheme goes against thirty years of accepted standard in visual interaction design, and I am disturbingly seeing it more and more. As interaction designers we are turning every interface into a place where users can’t see what can actually be done, what is available: we’re just asking them to swipe left and right anywhere and hope they discover that something might happen.

This mistake is a very strong indicator a system was never tested with actual users. It’s amateurish, it is a beginner’s mistake. An off button that can be switched to on must advertise it is ready for use, and making it faint and gray does not qualify. Don’t do it.

You see this flaw crop up a lot when a company insists on both having very few brand colors, and that no other colors should be allowed in digital. I had one of those in the last year: it’s primary brand color was a form of red, and only gray and black could be used with it. They wanted us initially to use that red to indicate on or selected. User testing immediately showed what everyone already knew: a control that turns red is actually seen as being wrong or unavailable. We had to have long conversations before we could use a second color, not on that brand palette.

Placing Titles And Buttons So Close Together The Button Takes On The Title

This is a result of pushing minimalism stupid far, and it is just so confusing. And it is all over Android right now.

Example, from Citymapper, an independent app maker:

Screenshot_2015-02-20-13-50-15 copy

When I look at the title bar of this screen, I see a control to click to go back to the results screen. That is actually not right, Results is the title of this screen, and that left arrow is to go back to whatever you came from, if you remember what it was. But that is not my first impression, nor the whole gestalt of that title bar, to me it says ‘go back to Results and god knows what it is you are looking at here.’

This is actually not the result of an independent app maker breaking interface convention: Google, owners of the Android experience, actually meant for this arrangement. Here, a screen shot from one of their workhorse apps, GMail:

Screenshot_2015-02-24-16-25-05 To me this title bar says: tap the arrow to go to the Compose screen. It isn’t, we are looking at the Compose screen here, and that left arrow goes to whatever.

iOS, while hideous at doing it, actually gets this right:

IMG_0879 IMG_0880

I see where I am right now, and I see where the arrows are, and where they will take me. Yes, it is a busy title bar, with a lot going on, but I am not left in the dark. The worst is how unnecessary Android’s confusion is; with just one tiny adjustment this could have been so much better:

Screenshot_2015-02-24-16-25-05 Screenshot_2015-02-20-13-50-15 copy

That’s it. That’s all it takes: moving a label to the right and adding a single line of white pixels. Done. We know what is title and what is control and how related to each other they are (they aren’t). Ok, so the arrow still doesn’t tell you where it goes, but the back arrow on Android has been a messed-up magic mystery tour since its inception anyway.

Swipely Pages, A Working Demo Of A More Capable “Off Canvas” Multi-Device Layout Pattern

In his blog entry about Multi-Device Layout Patterns, Luke Wroblewski describes different layout patterns for web-sites that adapt to the device they are being shown on. These layout patterns are a central component to making a website that can be said to have a Responsive Design. Using such a pattern is not the only component to a site that has Responsive Design, server-sniffing to serve up only the right size images, for example, is just as necessary to not overwhelm small devices. The layout pattern, however, is the heart to deciding how the site is going to feel for users as they interact with different devices. All Responsive Design sites should equally make sure to send the right images for the size and density of the screen, or not try to do too much with fonts or frameworks on devices with slow connections, but different patterns are only appropriate for specific sites; and there are choices to be made.

Luke mentions the “Off Canvas” design pattern, a design pattern where the content is adapted to work on smaller screens by pushing non-essential content off-canvas. It is used well in Facebook’s mobile apps for example. The description really only discusses how the pattern works on a small screen, and doesn’t scale it up for tablets or desktops. I became interested in this pattern since I wanted something similar for a portfolio site that needed to show well on all kinds of devices.

The portfolio site is much like Facebook’s mobile experience of a central menu with different pages of content: the portfolio has a central menu of pages, in my case projects, to choose from, and then the actual project pages itself. It would be easy to follow this pattern for touch devices, but what should happen on less capable phones? And how should it scale up? Because yes, for a proper Responsive site, it is necessary to think about the least capable device first, and then scale up for better devices from there.

Re-using the work of Torkil Johnsen in making an implementation of a 3-panel “Off Canvas” design, I made a template experiment for this called Swipely Pages, it is now available on GitHub for anyone who wants to check it out. The design scales as following:

Simple phone, no scripting

On a device with little or no scripting capabilities, the menu page and subsequent pages are shown by themselves, and the user jumps between them by clicking links.

Swipely Pages menu shown in the browser of a Nokia E71.
Swipely Pages content shown in the browser of a Nokia E71.

 

Touch phone, scripting

On a device like an iPhone or an iPod, the menu loads the first page of content into a panel that can be swiped in and out of view. By selecting Menu on the content panel the panel slides to reveal the menu, and tapping on a menu entry will load the page into the content panel.

Swipely Pages menu as shown on an iPod Touch. Note the content panel on the right to swipe into view.
The main panel can be swiped into view, and swiped away to reveal the menu again

 

Tablet

On a Tablet, the JavaScript in the menu page senses a bigger screen, and loads all the links in the menu into panels that are arranged horizontally. The user can swipe between the panels, and every swipe left or right neatly aligns the panel being swiped to with the left edge. The Menu button at the top of each panel is a quick shortcut back to the menu.

Swipely Pages menu on an iPad, with content pre-loaded in panels off to the right of the screen.
Every swipe to a panel neatly aligns it with the left border. The navigation in the <header> tags in each panel is-reused to make short-cuts at the top to go to the menu or move to the next panel.
The user can still scroll vertically with a touch in each panel separately.

 

Desktop

On the desktop the visual behavior is much like on a tablet. However, swiping with the mouse or touchpad has not been implemented yet, so the user has to use the Next link to go to the next panel. Before deploying this template, the positioning of the Next link should be tested with users, and proper swiping with the mouse should probably be implemented.

Screenshot of Chrome browser showing multiple panels and a menu in one swiping page.

As said, this template and experiment is available for download on GitHub. It needs work to be used in production, but I hope it accurately shows that more can be done with Responsive Design than just re-stacking elements into the viewport.