Author: Jochen Wolters

Among the well-established user interface controls are checkboxes and radio buttons for making selections from a list. With “well-established” I mean that users (tend to) have a common understanding of what checkboxes and radio buttons look like, and how they behave.

The difference in behavior between checkboxes and radio buttons lies in how many items you can select at a time.

A list of checkboxes allows you to select items arbitrarily: When clicking one checkbox, this has no effect on any other checkbox within the same list. You can check none, some, or all of the items.

Radio buttons, just like their namesake, let you select exactly one item at a time. Clicking on a radio button unselects the previous selection, and there always is an initial selection.¹

Interestingly, there is no well-established UI control yet that requires you to select at least one or more list items (vs. zero or more for checkboxes).

In some cases, designers do have to find a workaround for this problem. More often than not, though, there is no actual need for the one-or-more approach to start with. Here’s an example for the latter.

America’s latest premium TV channel: “None of the Above”

Across the US, TV programming differs slightly between regions and providers. Most websites that offer TV listings let you configure their schedule accordingly. On the TV Guide website, for example, you do so by filling out a simple four-step questionnaire.

In the final step of this process, you select any premium channels you subscribe to via a list of checkboxes. The odd thing about this design is the bottom-most option: “None of the Above”.

https://uiobservatory.com/media/2011/ListSelectionTVGuide.png” alt=”Fourth step of TV Guide form, showing a checkbox list of premium TV channels plus an option for “None of the Above”” border=”1″ width=”400″ height=”232″ />

Its appearance is perfectly identical to the other list items, which usually means that it should also behave identically, and control the same kind of functionality.

Nevertheless, if you do click this checkbox, any selections you may have made from this list are cleared, so that “None” is the only selection. Un-checking it again, however, does not restore your previous selections.

Because this option visually blends in with the others, it is also easy to overlook. If you do, and make the “mistake” of not checking any of the options, an error message appears, requesting you to “Please select at least one of the options”.

Unless you had discovered the “None” option and understood its meaning at this point, seeing those instructions may confuse you: “But I haven’t subscribed to any premium channels. Why, then, should I have to select one?!”

There are several ways to make this process more user-friendly, like making the “None” option stand out visually, by rephrasing the error message to make it easier to understand, etc.

When “None of the Above” should not be an option

The easiest solution in this case, though, is to simply remove the “None” option altogether. Not checking any of the available premium channels already constitutes the common understanding of “Nope, don’t have any of these!”.

Generally speaking, there are cases in which it does make sense to include a “None” option — namely for radio buttons! For checkboxes, however, the status of all checkboxes being unchecked perfectly covers the “None of these” option already.

One of the biggest festivals on Northern Colorado’s lively music scene is Bohemian Nights, which takes place during the New West Fest in Fort Collins. Kicking off tonight², this year’s event boasts 80 bands. A customizable concert schedule lets you pick and choose from this sonic abundance.

Here’s what I would consider a common scenario for using such a schedule: After deciding when you are free to attend the festival, you search (or filter) the schedule for all bands who will be playing while you’re there, and whose music appeals to you. You then make your selection from the resulting list.

Let’s see how easy it is to accomplish this on the Bohemian Nights website.³

Finding concert details

The schedule’s default view is a chronological list, grouped by day and start time.

Immediately visible are only the bands’ names. These are displayed against a colored rectangle to indicate their music’s genres. A list on the right shows what color corresponds to what genre (referred to on the site as “[music] types”).

For a better overview over the schedule, you can also view the concerts on a grid. In this case, though, you can only see one day’s schedule at a time, and depending on its length, the view may be paginated as well.

Complete information — comprising genre, date and time, venue, and a short info blurb — is available for each concert. You can view this information in three ways: hover your mouse pointer over a band name to make a tooltip-like overlay appear; …

… click on a band to show the information on a separate page; …

… or click on Show Details above the schedule to display information as in-line boxes on the schedule.

Obviously, it is rather tedious to “manually” scan all 80, or so, entries on the schedule to find interesting bands, regardless of which of these three methods you use to view the detailed information.

Equally tedious is the attempt to correlate a band’s color with the genre list. With a total of 35 genres, many of which share highly similar, if not identical colors, the limitations in your eyes’ ability to differentiate between these colors will soon become apparent.

What’s more, many bands are listed under more than one genre, but the color only reflects one of these.

A much easier approach to work along the usage scenario would be to filter the schedule, so that it would only list those events that match the search criteria.

Add some music to your day

Although this is not directly apparent, you can, indeed, filter the schedule by genre by clicking on any of the genres in the list, but you cannot select more than one genre at a time.

To “reset” this filter, you need to click on “Full Schedule”, which is placed far away from the genre list. Finding this function would be easier if it were implemented as an All Genres option and grouped together with the other genre “selectors”.

What the genre list does include are two items called Most Popular and Venues that are not genres at all.

By (most) popular request

Most Popular ranks performers based on the number of people who signified via the schedule’s social features, that they are “interested” in a particular band.

Note how the genre list does contain an All Types item here. That is because clicking any genre in this view will display the rankings within that genre, and All Types takes you back to the full ranking.

In addition to filtering by genre, you can also filter the rankings by day, but you can only select one day (or All Days) at a time. What’s more, although they have their own group and are not placed close to the genres, clicking any of the Popular by Day filters also resets the genre filter!

That is, you can see the ranking for a certain genre (or All Types) or a certain day (or All Days); you cannot filter by genre as well as day at the same time, though.

Where did those guys play again?

The Venues view looks similar to the regular schedule, but it groups the concerts by venue. Through a Venues filter section, you can limit the display to show only bands playing on a certain stage.

If you click on a genre in this view, you are immediately taken back to the regular schedule for that genre instead of viewing the genre grouped by venue.

Take me back where I belong

If you’re in either Most Popular or Venues view, the link to get back to the “normal” schedule view is not atop the schedule where it was when filtering the list by genre. Instead, the link to click is the header-like Schedule line above People Directory in the column on the right.

Although the Schedule link is highlighted when you’re viewing the schedule, it was difficult for me to find. It just feels illogical to have to use links in two different locations to get to the same page on the site.

Tidying up just a lil’ bit

The extensive information that is made accessible via this schedule is great for planning a visit to Bohemian Nights, but the navigation of the schedule is confusing.

The key reason, in my opinion, is that the site’s information architecture does not reflect the underlying data structures very well.

In essence, there are four different views on the available data:

1. Concert list: Grouped by date. Sorted by date and time. Filtered by genre.

2. Concert grid: Grouped by date and venue. Sorted by date and time. (Cannot be filtered.)

3. Venue list: Grouped by date and venue. Sorted by date, venue, and time. Filtered by venue.

4. Most popular: Ungrouped. Sorted by popularity. Filtered by genre or date.

In all cases, filtering determines what data is being displayed, and grouping and sorting determine how the data is displayed. To make it easier to grasp this structure, the views should be separated from the filters, and this separation should also be reflected in the UI.

Based on this approach, here’s a suggestion for a slightly different layout⁴ for this page:

Venues and Most Popular are part of a view selection that also includes the default List view plus its Grid variation. All filter groups are always displayed in the column on the right. Instead of being links which only allow single selections, they provide checkboxes for multiple selections, and each filter operates independently from the others.

This design would not only provide more powerful filtering, but also arrange all UI elements in a consistent, logically grouped layout.

In a previous article I asked “What time is your zone?”, and compared the ways in which you set a computer’s system time zone in Mac OS X, Windows, and Ubuntu Linux. Besides the system-wide setting, you can also find support for time zones in application software like the three apps I observed for this article.

iCal: Setting the time zone for the calendar view

The obvious example is, of course, a calendar application like iCal, which ships with Apple’s Mac OS X operating system.⁵

The time zone for iCal’s calendar view is selected via a menu in the top-right corner of the application’s single main window.⁶ Note the nifty tooltip: when you hover the mouse pointer over the menu, a tooltip will display the time for the currently selected time zone.

Initially, the only entry in this menu is the computer’s system time zone. Selecting Other… brings up a dialog box with a map and a search field. By clicking on the map or searching for a city, you select another time zone to be added to the menu.

Unfortunately, the underlying database of cities is not nearly as extensive as the one that powers Mac OS X’s Date & Time system preferences. Where the latter even finds very small towns (and this has been improved further in OS X 10.7 Lion), iCal is only aware of one or two major cities per country and time zone.

Unless you travel to a lot of different countries all over the planet, you will likely only require a handful of time zones to be listed in this menu. Hence, instead of providing a lengthy menu of all time zones known to man, it makes sense to require the user to manually add further time zones.

iCal: Setting the time zone for an event

In iCal, time zones are assigned to events via a menu in an event inspector window. This menu contains two items that are not found in the main window’s menu: UTC and Floating.

UTC — [Universal Time Coordinated](http://en.wikipedia.org/wiki/Coordinated_Universal_Time “Read the Wikipedia entry on UTC” ) — is the world-wide authoritative time reference, so it deserves its special spot.

“Floating” is not actually a time zone. Rather, it denotes that an event’s time should not be adjusted for time zones at all. Instead, floating events are displayed at the same time in the calendar view, regardless what time zone that view is set to.

This is a handy feature for events that you always perform at the same time, no matter where you are, for example your weekly GTD review or your daily meditation session.

When you create a new event, iCal pre-sets the inspector menu to the time zone selected for iCal’s main window. If the desired time zone is not yet included in the menu, you can add a new one from within the inspector window via the Other… menu item.

This brings up a little map view, in which the time zone for the current menu selection is highlighted, but no other information is displayed.

With your only option being to click on the map and then select a city from a popup menu, finding the right time zone can be tedious unless you already have at least a rough idea of its geographical location.

Finding a time zone based on a city name is easier when you use the main window’s menu, because that gives you the comfort of the search field. Since the menus in the main window and the event inspector are synchronized, you can freely choose which path you prefer.

iCal: Two menus that (unfortunately) are like one

While this synchronization of the two time zone menus generally makes sense, I have mixed feelings about this feature.

Unfortunately, there is no way to remove any entries from either menu (unless you are willing to manually edit iCal’s preferences file). Whenever you add a new time zone in iCal, you’re stuck with it.

What’s worse, however, is that both menus are always sync’ed even though it not always makes sense to add an events’ time zone to the calendar view menu.

Imagine, for example, that you have scheduled a phone call with someone in Sydney, Australia, and that person gives you the desired call time for their own time zone.

Entering the event for the appropriate time zone, Australia Eastern, spares you the trouble of converting the times to your own time zone. But unless you ever travel to Australia, why would you need to set your calendar’s main view to that time zone?

In other words, adding Australia Eastern to the event time zone menu makes sense, whereas adding it to the calendar view menu only adds clutter, because you will most likely never set your calendar to this location.

iCal: A major change of cat, a minor change of time zone support

For Mac OS 10.7, Apple redesigned the visual appearance of the calendar app. With regards to time zones, though, there is only one change: instead of time zone names, the menus now list countries. E.g., instead of Central European Time, it may list Germany Time.

This does result in multiple menu items for the same time zone, e.g., Germany Time and Netherlands Time, which both lie in the Central European Time zone. Then again, it is easier to remember what country you are traveling to than the time zone for that country.

Aperture: Being smart about daylight saving time

My favorite piece of advice on photo management is to always keep your camera’s clock set to UTC and make all time zone adjustments in your photo software. That way, you never have to remember to change the camera’s clock, or try to recall between which photos you did so.⁷

In Apple Aperture, which I use for managing my photos, you adjust the time zone via a pair of popup menus: one for selecting the camera’s time zone, and one for the selecting the time zone of the location where the photo was taken.

Aperture pre-selects the computer’s time zone in both menus, so that, in most cases⁸, all you need to do is set the camera menu to UTC when importing your pictures. The corresponding menu item is conveniently located at the bottom of the menu.

In a neat twist, Aperture is smart about daylight saving time: When you select a time zone for a photo, Aperture determines whether daylight saving time was in effect on the day the photo was taken. If so, an hour is added to the adjusted time, and the time zone identifier listed in a photo’s time stamp reflects this as well: For example, GMT+1 for Berlin and MST (Mountain Standard Time) for Denver turn into GMT+2 and MDT (Mountain Daylight Saving Time), respectively.

Aperture even takes time zones into account when sorting images. According to the nominal time stamps in the following screenshot, IMG_0545 was taken before IMG_0549 and IMG_0550. When converting MESZ to the GMT-6 time zone by subtracting eight hours, however, IMG_0549 and IMG_0550 were taken shortly after noon that day, and they correctly appear before IMG_0545.

Unfortunately, Aperture also applies this logic when selecting photos via the Calendar filter, sometimes causing a photo’s date to shift by a day. The photos in the following screenshot were taken on September 25 at GMT-6. Aperture translates the dates to the computer’s time zone — in this case, GMT+2 — and displays the images on the calendar for September 26.

I am not sure whether this is a bug or intended behavior. I do think, though, that it is wrong, because it feels more natural to link a photo to the date when it was actually shot, than to whatever date this corresponds to in another part of the world.

Similarly, Aperture displays both a “File Date” and an “Adjusted Date” in its import window, but already adjusts the former for the time zone you’re in. Therefore, very often the “File Date” is not the file date. Because Aperture bases the “Adjusted Date” preview on the “File Date”, the latter will be incorrect, as well, which is extremely confusing.

Apart from these two glitches, Aperture’s handling of time zones is very well designed: while you have complete control over selecting an image’s time zone, Aperture spares you unnecessary headaches and extra work by taking care of daylight saving time for you.

OmniFocus: The stealth approach to time zones

In both iCal and Aperture, these applications’ time zone features are easy to discover, because the related controls are easily visible. In contrast, OmniFocus, a high-end task manager by the Omni Group, takes a stealth approach to time zones.

Every task stored in OmniFocus can have a start date and a due date. A Completed date shows when a task was checked off. All three of these include both date and time.

When you enter a date without explicitly defining a time for it, the Start field will default to 12:00 midnight. The Due date’s default can be configured in the app’s preferences, and I keep this set to 6:00pm.

It came as quite a surprise to find out that OmniFocus does recognize your computer’s system time zone, and adjusts all of its Start, Due, Completed, and even the Added and Changed dates accordingly.

I only noticed this when I noticed that the dates for my tasks were off, just like in the screenshot above: instead of 12:00m and 6:00pm, the times are 4:00pm and 10:00am while I was in Colorado, whose Mountain Time zone is eight hours behind Germany’s Central European Time.

And yet, I checked OmniFocus’ online help, its user manual, and the online FAQ, and none of these mention this feature!

The major caveat is that this automatic adjustment can shift a task’s start or due dates to another calendar day: Let’s say I’d add a task with a due date of July 22, 2011 6:00 PM Mountain Time. When I travel back to Europe, that time stamp moves to July 23, 2011 4:00PM, effectively moving the due date to the next day.

While there may be circumstances where the date for a task should be adjusted for changes in time zones — e.g., when you have to hand in a deliverable to someone by a certain time –, I consider it much more likely that you set start and due dates within the mindset of a normal work day.

In other words, “due” usually means “finish this by the end of day X”, regardless of where and, thus, in which time zone, you work on that task. That’s why I would prefer a default behavior of not adjusting dates for time zones in this kind of application.

If a feature with this kind of (potential) impact is implemented, it should at least be fully documented, and allow some basic control over how it works.

Similar to iCal’s implementation, I wish time zone support in OmniFocus and similar programs were an option, and a time zone menu near the respective date fields should include a Floating setting.

Some suggestions for time zone support in software applications

In case you are developing an application that works with dates and times, here are a few ideas to keep in mind when implementing time zone support:

• Make it visible: If your application supports time zones, make this obvious. Don’t silently adjust the time, but include a time zone marker like “MST” or “GMT+2” in date fields. Also, describe the feature in the user manual.

• Show where you are: Point out to the user which time zone they are currently in (as defined by the computer’s system time zone setting), e.g., by highlighting it in the time zone menu.

• Keep time zone menus clutter-free: Depending on how your application is used, let the user manually configure that menu instead of providing a complete listing of all existing time zones.

• Sort time zone menus by location, not time zone: It is much easier to find a time zone based on its continent and city, than by offset versus GMT. Sort time zone menus accordingly.

• Make it obvious how daylight saving time is handled: Display the time zone name in date and time fields, so it becomes obvious whether that time stamp is shown for daylight saving time, or not. And, again, properly cover this in the application#s manual.