Posts tagged UI design

Using native HTML elements has positive effects on web content accessibility. Elements can be read properly by screen readers according to their function or role. For instance, a button written using the markup below will be announced as: “Refresh Button” by screen readers.

<button id="refresh">Refresh</button>

Nice and easy. However, web development isn’t always this straight forward. We often need to write more complex widgets using a combination of native elements. And in some cases, we use frameworks to tap into well-defined/designed patterns to fulfill this need. That’s largely due to the deficient nature of the HTML spec. But can you imagine for a second a richer HTML standard? A standard encompassing all the well-established widgets that we’ve been inventing, re-inventing and using for years?

Let’s consider a paging toolbar widget … I imagine a markup (in its simplest form) to be something like this:

<pagingtoolbar numPages="10" recsPerPage="10" totalRecords="100"/>

Obviously this is a simple case. There are certainly more complex use cases for paging toolbars. But the point is, we have been using this pattern for years, yet HTML hasn’t caught up to provide an API for it. So, since the example above doesn’t exist in the HTML standard, we use frameworks such as Bootstrap or Foundation or we roll our own. A common markup for pagination is one that Bootstrap provides:

There is nothing wrong with this markup. In fact, it’s perfectly valid, and well-structured. Now, let’s consider how it will be announced by screen readers (VoiceOver on my Mac):

Link. Left pointing double arrow.
List 7 items
Link 1
Link 2
Link 3
…

Screen reader users will gather the context by the time screen reader announces the 5th or 6th line (Link 2 or Link3). The context is gathered by the way things are ordered and where objects are located in the DOM. But wouldn’t it be better if we can announce the context as soon as the user lands on the pagination widget itself?

Here is an example of how one might improve on Bootstrap’s pagination widget:

Now, the widget name/type is announced immediately, making the context much more understandable for screen reader users. This immediate announcement happens because we’re using ARIA (Accessible Rich Internet Application) roles and labels. The ARIA standard helps developers provide additional context to composite/complex widgets and can describe the various states (disabled, checked, busy, etc.) on these widgets.

We can improve this widget even further by introducing a few tweaks. The full, improved markup for this widget can be found here

Following the ARIA spec is instrumental in making web applications more accessible. For more information on ARIA, visit the W3C website

“Pity gives way to respect when much more value is delivered than originally expected.” - John Maeda, The Laws of Simplicity.

What a great quote! That’s exactly how I felt a few weeks ago when I helped a friend install Nest in his house. Nest is a classic case of simple design. It is also a great example of a Natural User Interface (NUI). These interfaces encourage users to interact through their simple, seemingly familiar design. For instance, in Nest, there is only one/two input controls; the ring and the clickable screen itself. There is nothing else that gets in the way. The user is not overwhelmed with a bunch of options and, therefore, decisions become more obvious. Watch this 4-minute video on the setup process then read on…

The most interesting part to me was the use of the same input device (the ring) with inherently different UI components.

List Menu:

The ring is used with different list options (Wifi Networks in the video). By rotating the ring, the user is able to step through (highlight) each option in the list.

Input Field:

Another use case for the ring is typing in a text box (password in the video) by selecting letters, numbers and special characters from the screen.

Spinner/Range Fields:

Yet a third use case is applying the ring as a spinner field to loop through a list of numbers to set the zip code. And lastly, the main use case, adjusting the thermostat, is also controlled with the ring. Rotate right for heating and left for cooling, as the interface provides feedback through the temperature in degrees and color codes (orange=heating, blue=cooling).

Design Decision:

The interface highly demonstrates good design decisions. Notice, for instance, how confirming actions are made a bit more explicit by clicking on the screen or the ring. This way, users don’t get frustrated confirming an action they didn’t explicitly make. All other options are made more forgiving by using the ring/wheel.

Conclusion:

When users have a limited set of options, they have no choice but to zero in on those available options and start interacting with them.

“Proportionately more attention shall be paid to that which is made less available.” - John Maeda, The Laws of Simplicity.

By the time users work their way through the first UI control, they’re experts at using the thermostat. Learning one use case means learning a whole set of familiar interactions in this UI.

As designers, we have to remember that each time a user gets introduced to a new option, there is some level of uncertainty. It takes a special designer to cut down on those uncertainties by reducing the options in a way that’s still fully functional and appealing. Now compare Nest my friend’s more familiar-looking, older thermostat.