flow|state

UI Control of the Week: standard Collapsible panel for content that can be put away

It's fairly common for a UI to present some content whose value to the user may be unknown or may change over time. To avoid permanently distracting the user, the app can show the content in a panel the user can collapse. Consider the following two gadgets from Google’s Gmail client, the first expanded, the second collapsed:

 

 

Perhaps the user leaves the calendar gadget open because they find the considerable clutter it adds is worth its informational value. The “Invite a friend” gadget, however, isn’t worth much to them, so they collapse it and leave it that way. In the rare event they're suddenly inspired to invite a friend, it's easy enough to re-expand that panel to bring the UI back.

Key attributes

• Clicking anywhere in the heading collapses the panel's content, leaving only the heading visible.
• The heading generally reacts to mouse-over by changing the cursor to a hand. The heading may also react in other ways, e.g., its background color may change.
• In many cases, including the above example, the heading includes a small button element on the far right. Clicking this button has the same effect as clicking the heading itself, but the button offers a more obvious affordance of interactivity.
• If present, the button's icon or contents generally reflect the panel's collapsed or expanded state. The button may show plus and minus signs or down- and up-pointing arrows. The icon usually suggests what will happen if you click it (e.g., if you click the plus, you’ll get more UI), rather than indicating the current state.
• The transition between the expanded and collapsed state is usually animated to suggest that the content is rolling up into the heading, where it will be stored until the user decides to retrieve it again.
• Many applications save the collapsed/expanded state for future sessions. In effect, the collapsible panel is offering a persistent user-configurable option, without any of the overhead of a separate Settings or Preferences area.

Collapsible and CollapsibleWithHeadingButton

I've posted a Collapsible control to the QuickUI Catalog that offers the bare-bones functionality. Because the pattern of including a little button on the heading’s right is so common, I also added a subclass called CollapsibleWithHeadingButton:

 

 

Use these Collapsible classes to confer a limited degree of customizability to a home page or information pane on the side. If most users are likely to want the information most of the time, collapsible panels might not be necessary. However, in cases where there's a fairly even split between users that want a given type of information and those that don't, such a panel can be a reasonable compromise. Similarly, if there are situations where an individual user may change their mind about whether they want the information (because it's useful) or not want the information (because it's distracting), consider a collapsible panel.

Implementation notes

To avoid requiring lots of graphic resources, for many of these controls I use text glyphs as button icons. Here a plus sign (“+”) is used in the collapsed state to indicate the content can be expanded, and a minus sign (“−”) is used when the content can be collapsed. I've seen some sites that, perhaps unintentionally, use a hyphen (“-”) instead of a minus sign. A hyphen is too narrow, and ends up feeling like a weak counterpart to the plus sign. (Google avoids this by using a bitmap image, probably for tighter control over the final result across different browsers.)

One thing that feels a bit unresolved about gadgets like Gmail's, which offer a heading button on the right, is that the button and the heading text both do the same thing, but that shared behavior is not obvious until you click. My general feeling is that multiple controls that respond the same way to a click should respond the same way on hover. In this case, I arranged for mousing over the heading text to force the application of the button’s hover effect, even if the mouse isn’t actually over the button, as an extra cue that clicking either UI element will accomplish the same result. See Where should the hit target boundaries for UI elements go? for more thoughts on reflecting hit target boundaries.

The animation effect includes a combination of a slide and a fade: the contents fade out during collapse, and fade in during expansion. To me, this enhances the effect of the content rolling away and unrolling again. The fade effect is more pronounced when there’s a large block of content.

 

Aside: I've invested work in reducing the number of files necessary to use controls in the QuickUI Catalog. It used to be the case that several files were required to use all the controls, but the whole catalog has been consolidated into just one pair of files: quickui.catalog.js and quickui.catalog.css. As described on How to use these controls, you can include that pair of files directly. You can also follow the instructions for cloning the quickui-catalog repo and choosing the specific controls you want. Among other things, this makes it easier to try out the controls. For example, here's a jsFiddle that uses the QuickUI catalog (including, for the time being, the CollapsibleWithHeadingButton control shown above).

flow|state will off for the next few weeks for the end-of-year holidays. See you next year!

UI Control of the Week: a PanelWithOverflow to create toolbars with overflow menus and maximum layout efficiency

Applications with toolbars should generally give the user access to all toolbar commands, even when the window isn't large enough to show all of them. Wrapping a toolbar's contents is one possibility, but this is usually avoided because it begins to steal too much space away from the application's main content area. The standard technique is to have the commands which can't fit horizontally overflow into a dropdown menu.

This technique is used, for example, in the Bookmark (or Favorite) toolbar in every mainstream web browser. Here's Safari:

When the user makes the window too small to see all the bookmark buttons, the buttons which don’t fit overflow into a dropdown menu:

Key attributes

• The toolbar contents (usually buttons) are arranged horizontally.
• Items which don't fit are clipped entirely; no item (e.g., Bookmark 5 in the toolbar of the second image) is ever shown partially visible.
• If there are any items which don't fit, an overflow menu button appears. The standard is for the button to show a pair of right-pointing chevrons (»).
• Clicking the menu button produces a dropdown menu containing the items which don’t fit in the toolbar.
• Items may appear slightly differently in the menu than they appear in the toolbar. In the Safari example above, plain-looking toolbar buttons become vertically-oriented menu items with icons. Beyond the change in appearance, the items generally behave the same in the menu as they do in the toolbar.
• As the user resizes the window, the control recalculates whether an overflow menu (and therefore a menu button) is necessary.

This overflow pattern is apparently so successful that the exact same user interface — down to the use of right-pointing chevrons to indicate overflow — is used by Chrome, Firefox, and Internet Explorer. The funny thing is, each of these other browsers fumble one small aspect of the behavior: determining whether or not to allocate room for the menu button.

• Google Chrome always allocates room for the menu button, even when the button isn’t visible. This means there are cases where the toolbar button would have fit, but the invisible menu button is still taking up room, which forces overflow to be triggered a bit earlier than strictly necessary. For comparison, in the top screen shot, Safari can fit the button for “Bookmark 6”, but in the same situation, Chrome will force that button to overflow. Effectively the user has something like 10-20 pixels or so less room in Chrome for their browser bookmarks.
• Mozilla Firefox is a bit smarter, but inconsistent. It doesn't allocate room for the menu button if the menu button's not currently visible, so Firefox can squeeze in an extra bookmark in cases where Chrome drops it. However, once the menu button is visible, the menu button takes up room — even when hiding the menu button would now leave enough room to show the last bookmark!
• Internet Explorer 10 gets things right — but get points off for incessantly flickering the menu button during a window resize. Presumably on any window resize, IE is always hiding the menu button, then re-showing it if it’s needed. This doesn't feel nearly as solid as Safari’s treatment, which smoothly moves the menu button left and right as the window resizes.

These are all small points, and I doubt most users of these browsers have ever noticed them. Still, this is not ideal. I think this is what happens when designers and developers, even those on huge software teams, are forced to roll their own solution to a common problem. Either they don't notice the issue or, if they do, don't feel like it's worth taking the time to fix.

And here we're talking about large, production web browsers built upon rich client-side UI frameworks. Many web sites aren’t building on a rich UI framework, so they’re forced to code everything by hand. The result is that web application toolbars are typically far clunkier. They often blithely assume the user’s window will be wide enough to show all the commands, and clip or wrap the buttons when the window is narrow.

A correct, solid implementation (like Safari’s) should be available to any site that wants it — by coding the correct solution in a reusable component. By treating something as basic as overflow as a component in its own right, it suddenly becomes worth lavishing the attention and effort to achieve maximum layout efficiency, including properly handling those last 10-20 pixels, because lots of users across multiple apps will benefit.

PanelWithOverflow

I've posted a basic PanelWithOverflow control to the QuickUI catalog.

As discussed above, use PanelWithOverflow in situations like toolbars where you want to constrain the height of a toolbar while simultaneously guaranteeing access to all the toolbar's commands at a wide range of window sizes. For a toolbar that docks to the top of the page, nest the PanelWithOverflow inside a PersistentPanel.

Implementation notes

The simplest way to implement this behavior in a web control seems to be to force the control’s contents to appear on the same line (white-space: nowrap), then calculate which items completely fit. The ones that don't are explicitly made invisible (using visibility: hidden) to avoid a partially-clipped item.

In coding this, it became obvious why Chrome and Firefox browsers display the layout oddities they do. To decide whether the nth item can fit, you need to know how much room is available for it, which depends on whether or not the menu button is going to be needed — which in turn may depend on whether the next item to the right (item n+1) will fit. The layout logic gets much simpler, however, by applying the expedient of looping over the control's contents from right to left. If item n+1 is going to overflow, you know for sure that you need to allocate room for the menu button when considering item n.

Just because this QuickUI control avoids a small layout bug in the various browser toolbar implementations above doesn't mean it’s necessarily better than those implementations. Those toolbars have many more features (e.g., customization), and surely have received much more testing overall. Still, I’d argue that the QuickUI implementation is a reasonably solid start on an open, component-based solution.

UI Control of the Week: basic ListBox, and how keyboard navigation is never as simple as you think

The standard list box is such a pervasive element of traditional client GUIs that it’s surprising how hard it is to find a good list box implementation on the web. A typical Windows example:

 

 

Your browser will probably render a standard HTML <select> tag as a dropdown list box, but as far as I know, there’s no standard way to get a in-line list box that supports single selection. (You will get a list box if you set the select tag’s “multiple” attribute, but then it will let the user select multiple items, which may not be what you want.) And all browser list elements can only render list items as plain text; as in the earlier discussion of combo boxes, none of the standard web list boxes support a rich presentation for a list item. Most sites create their own “list box” elements as divs with clickable inner elements. This usually means they end up without good keyboard support: e.g., you can’t move the selection up or down with the Up and Down arrow keys.

Key attributes

1. In the most basic type of list box, zero items or one item can be selected at a time. It’s always possible to change which item is selected, but once a selection has been made, it’s often not possible to revert to the state where no item is selected. There are other types of list boxes that support multiple selection.
2. When the list box has focus, pressing the Up key moves the selection to the previous item.
3. Pressing Down moves the selection to the next item.
4. Pressing Home (Fn+Up on the Mac) selects the first item.
5. Pressing End (Fn+Down) selects the last item.
6. Pressing Page Up (Option+Up) scrolls up a page. Or does it? See below.
7. Pressing Page Down (Option+Down) scrolls down a page.

Pop quiz: Off the top of your head, do you think you can describe exactly how Page Up and Page Down should work?

You’d think they would just scroll the viewport by one page height in the indicated direction. That’s the basic idea. However, the actual behavior of these keys in a list box is more intricate. Consider Page Down. On Windows, if the currently-selected item is somewhere in the middle of the viewport, then hitting Page Down selects the control currently visible at the bottom of the viewport. That is, the first press of the Page Down key in a list generally doesn’t scroll the list at all! It’s only once the selection is already at the bottom of the viewport that the list scrolls by one page. Page Up works the same, only in the opposite direction. On the Mac, the standard behavior is different: Page Up and Page Down scroll the viewport by a full page, regardless of selection position, but these operations don’t move the selection. (I’m not sure why. To me, at least, the Windows behavior feels more useful.)

Another complexity of keyboard navigation is tracking whether the list actually did anything in response to a key press. If it did, the list box needs to stop propagation of the keyboard event. But if the list box didn’t do anything with the key (say, the user hit the Down key, but the selection was already sitting on the last item), then the event should bubble up and, for example, scroll the entire page instead of just scrolling the list box.

Finally, following any keyboard navigation, the list may need to adjust its scroll position to ensure that the currently-selected item is completely visible.

I think it’s safe to say that keyboard navigation is a good and desirable thing: it can make certain tasks easier and faster, and it makes a UI more accessible. I can’t see a significant downside to letting a user navigate a list with a keyboard, as the UI doesn’t get in the way of mouse or touch users. So how come more sites don’t have list boxes? It’s a bit of work to handle the keyboard, but not that much work. I think one problem is that it’s not free. If someone’s on deadline to produce a list of items for a web page, even supporting the selection and navigation described above is going to take them some time, and maybe they’re not going to get any immediate credit for going that extra mile. This is one reason I’m hoping a good UI framework will help make basic usability improvements in controls easier for any site to pick up.

ListBox

I’ve posted a basic, single-selection, in-line ListBox control to the QuickUI Catalog:

 

 

This ListBox control is also used as the dropdown portion of a ListComboBox.

Usage: Use an in-line ListBox in situations where picking a single item from a list is a significant part of the UI’s task. A list box will consume more real estate than a combo box, but also requires one less click to select an item. A list box also makes at least some of the choices visible to the user without forcing them to first interact with the control; this can make the task of selection more approachable. A standard list box doesn’t allow the user to add a choice of their own; for that, a combo box is the standard answer.

Implementation notes

As might have been expected from the above discussion, the trickiest aspect of this control was the keyboard navigation, especially the behavior of Page Up and Page Down. For now, at least, I’ve let Page Up and Page Down work the same on the Mac as on Windows. (If anyone can explain to me a common situation where the Mac’s standard viewport-scrolling behavior is better than the Windows behavior, please let me know!)

On the plus side, now that the QuickUI Catalog finally has a rudimentary ListBox control, I was able to drop a ListBox essentially unmodified into the ListComboBox control to give the latter basic keyboard support. ListComboBox originally used the more primitive List control, which simply renders a JavaScript array as a set of controls. ListBox builds on List, so it also has the ability to render array items as controls; to this it adds the concepts of single selection and keyboard navigation. A core promise of a control framework is code reuse. In this case, there was no need to reproduce single selection and keyboard navigation again in ListComboBox, since ListBox already provided it. It’s wonderful when that object-oriented promise can actually be realized.

One thing I left off this time around is making it easy to have a ListBox be an integral number of lines tall. If you look carefully at the bottom of the above ListBox shot, the bottom row is just a bit clipped. It would look better if the list box were just a bit taller, so that an integral number of lines could be completely visible. I also began experimenting with a multiple-selection list box, but that’s a fairly intricate bit of work all on its own.

 

Thanks to those of you who wrote expressing interest in using QuickUI with plain JavaScript (i.e., without markup). I’m continuing to work on that, and hope to have some basic documentation in place by year’s end. Stay tuned.

UI Control of the Week: HighlightEffects to expand a highlighted item without affecting layout

Johannes Tonollo’s excellent Meaningful Transitions site does a thorough job cataloguing animated transitions that can be used to convey specific messages to a user. One animation I’ve always liked was expanding an element on hover, as in this screen within Windows Media Center:

 

 

Key attributes

• When the mouse hovers over a list item (or the keyboard focus moves to it), the item becomes highlighted.
• The highlighted item animates in size, expanding in every direction. It covers the adjacent items. The other items (the ones which are not highlighted) retain their position.
• Bringing the highlighted item forward conveys the feeling that the item is ready for use or instruction, like a volunteer in a line of people stepping forward. In this case, the highlighted movie is brought forward to indicate that it’s ready to be played.
• When the highlight moves to another item, the previously-highlighted item animates back to its original state in parallel with the highlight animation being played on the new item.

For more discussion of this specific expand-to-highlight transition and some live demos on the Meaningful Transitions site: click Categories, then click Highlight, then Expand to Highlight.

HighlightEffects

I’ve posted a HighlightEffects control to the QuickUI Catalog that permits the easy creation of animated effects such as expand-to-highlight. Here’s a sample showing the result of moving the mouse over the second of five items:

 

 

Usage

Use HighlightEffects with lists to help the user see which element is highlighted, and to suggest that the highlighted item is ready for use. You can apply a variety of highlight effects to achieve different results. The one shown here – expand to highlight – effectively draws the user’s attention to the item without being too distracting.

Implementation notes

I thought it would be elegant to let the UI designer/developer define the package of highlight effects as CSS in a JavaScript property map, just as in jQuery’s $.animate() function. The HighlightEffects control uses this property map to determine which CSS rules will need to be un-done when the highlight moves away from an item. E.g., if the property map includes background-color, then the element’s original background-color is saved; when the highlight is removed, this original background-color is restored.

The main challenge with the expand-to-highlight effect is keeping the layout of the page steady as the highlight moves around. To get the highlighted element to pop out, we need to change its size and z-index, and apply absolute positioning. Without that, the expanded item would push the other items in the list to the sides. However, the use of position: absolute will remove the item from the layout flow. To keep things from moving around, we can empty the same technique discussed last week for PersistentPanel: wrap each list item in a placeholder of the item’s normal size. This placeholder remains in the layout flow even when the item is highlighted, so nothing behind the highlighted element will move around.

In playing around with various animation effects, it was clear that some arrangements animate more smoothly than others. For example, I originally tried to keep the text of the elements centered, but the repositioning of the text during resize was a bit jittery. Animations which change size, position, and color all seem to behave fairly smoothly on the devices and browsers I’ve got. It turns out that jQuery’s built-in $.animate() function doesn’t support color animations out of the box, but that ability can be supplied with a plugin like Color Animation.

As was the case when writing the post on ListComboBox, I left out keyboard support, so this currently only works with a mouse (and touch, although the effect isn’t as nice). My plan is to follow up with a ListBox control that can handle moving a selection with a keyboard, then update HighlightEffects to work with that.

UI Control of the Week: Facebook-style PersistentPanel keeps important controls from scrolling away

Whether or not you’re the type of person that likes the way Facebook is evolving their UI, Facebook is certainly leaving no stone unturned in their search for possible improvements. In a recent change, they introduced a panel on the right side that shows the user’s live activity feed and an ad. This side panel is initially a bit below the blue toolbar, and vertically aligned with the top of “Recent Stories” on the left:

 

 

Keep an eye on the upper-right corner. When the user starts to scroll the page, the left side of the page scrolls out of view, but the right side panel bumps up against the toolbar and remains docked there:

 

 

It’s hard to see in static images like this, but the right side panel remains entirely visible during scrolling, while the main portion of the page scrolls away under the blue toolbar.

This is a pretty subtle bit of work to finesse the treatment of a small number of vertical pixels above the panel. It would be have been much simpler to have the panel always docked up right under the toolbar. I’d hazard a few reasons Facebook used this technique here. First, they really want to focus user attention on the critical “Update status” button at the top. Keeping the feed panel below that line creates a nice wide band of white space that puts the eye’s focus on the “Update status” button. If the panel were initially docked right below the toolbar, that button would be harder to find. At the same time, permanently keeping a vertical gap of 30 pixels or whatever between the toolbar and the panel wouldn’t be satisfactory either. Facebook users spend a lot of time scrolling through this page, and that gap would probably stand out once the buttons above the news feed were scrolled away. Finally, it’s possible that Facebook had plans to show an ad or other content above the panel, and developed this solution for that purpose, then later dropped that ad but kept the solution.

Key attributes

• The persistent panel can either be to the side of the page content (as in the Facebook example above), or can span the width of the page content (as a toolbar).
• In both the side panel and toolbar cases, any content above the panel can scroll off, but the panel stays visible. In Facebook’s case, it just happens there’s only white space above the panel (and below the blue toolbar). Other sites put content above the panel or toolbar that they initially want the user to see at least once, but which can later scroll away.
• As the panel just begins to move out of view (off the top of the viewport), there may be a single jerky repositioning of the panel, but otherwise it’s quite stable. This is a significant improvement over earlier techniques to keep certain page elements visible. Some sites have tried to keep a side panel visible by using JavaScript to constantly adjust the panel’s position as the user scrolls, but the resulting performance is jerky and distracting. Yelp used to do this, for example, and tried to add a Map, stay put! check box that disabled the behavior, but ultimately concluded it was better to just drop this repositioning behavior entirely. In contrast, the technique here uses JavaScript to flip the document’s CSS position to “fixed”whenever the panel would otherwise be scrolled out of the viewport. This may jerk the panel into the correct position once, but thereafter the result feels very stable.

In general, I think this is a technique more sites, particularly advertising-funded sites, could productively adopt. For example, I’ve noticed that Google’s recent app redesigns are leaving them with much thicker sets of controls permanently stuck at the top of a page. It’d be nice if at least some of those controls could scroll away, leaving only the most important there all the time, and giving more room to the document I’m reading or editing.

PersistentPanel control

I’ve posted a PersistentPanel control to the QuickUI Catalog. There are two demos:

1. A demo of a persistent side panel
2. A demo of a persistent toolbar

Usage

Use a PersitentPanel to offer a small number of controls that are so important they should always be within quick reach. As shown in both demos, a PersistentPanel can be used when some content must initially appear above the panel so that it attracts enough attention. If this content can later scroll away, a PersistentPanel can ensure that the tools or information below the ad can remain visible. Without this requirement (for content to appear above the panel), it’s probably simpler to give the toolbar or panel a permanent position along the top, side, or bottom of the page.

Note: Both demos show an ad scrolling away. Facebook uses the same panel concept to keep an ad visible. Which way you go depends upon how likely it is that your users are going to click ads as soon as they see them, or whether you think the additional revenue from persistent ads makes up for the permanent clutter.

Implementation notes

The basic strategy here is to have the panel content sit within a placeholder element that can occupy the same space as the content whenever the content is switched to position: fixed. Without that placeholder, content below the panel would reflow in an unacceptable manner whenever the panel pops into and out of the normal document flow.

This is the first control I’ve done in this blog series that actually worked in IE8 without modification. Hooray! I usually start in Firefox, then test in Chrome and IE9. (I rarely test in Safari, as I’ve yet to create something that works in Chrome but not in Safari.) Then I take a deep breath, open the demo in IE8, and brace for some weird bugs. But this time IE8 played nice and everything worked. Good IE! Sit. Stay.

Although I’ve never seen a PersistentPanel dock against the bottom of the viewport, that case wasn’t hard to handle, so I added support for that as well.

In both the toolbar and side panel demos, I wanted to block out the space for an IAB universal ad unit, so I created a general AdPlaceholder control for that purpose. Now I’ve got a control I can use to quickly say, “Leave room for a Leaderboard here”, which is nice. This is one case where I’m thinking the control’s generic style should be a bit more colorful and distracting, to better approximate the visual noise of a page with ads.

 

Extra: In response to feedback, I've begun investing in documentation for using the QuickUI framework in plain JavaScript. People are often intrigued by the framework, but put off by idea of having to use a proprietary markup language (however elegant and efficient it may be). Everything in QuickUI, including all the catalog controls, is already accessible in plain JavaScript, although there's yet sufficient documentation for how to do this. So, in parallel with these control posts, I'm also working on documentation that addresses that gap. The first piece in that series is a list of the core principles which serve as the framework's foundation.

UI Control of the Week: Straight-up DateComboBox (and why your browser won't solve your date picker needs)

Once again, it’s amazing how hard it is to get the small stuff right. Building on both last week’s CalendarMonthNavigator post and the earlier ComboBox post, this week’s control is the standard date picker found in countless web sites and applications. Date pickers are generally optimized to pick a date in the near future, such as a date of travel or a date for an upcoming appointment. Here’s a typical example from Google Calendar:

 

 

Key attributes

• The control always includes a text box. In the control's normal state, this may be all that is visible. Generally speaking, clicking in the text box or moving focus to it opens the dropdown calendar.
• The control may include an icon, often a downward-pointing arrow, to the right side of the text box to indicate that the user can interact with the control to make a selection from a set of choices (i.e., the popup calendar). Some controls that offer an icon will require the user to click there to open the calendar, and will not dropdown the calendar when the user clicks in the text box.
• The input portion of the combo box and the dropdown portion are generally kept in sync. As the user types, the calendar reflects the new date. As the user navigates the calendar, the text box shows the new date.
• The user is generally expected to enter dates in short date format. In the U.S., this is month/day/year.
• The control validates the user’s typed text to verify it represents a date. This validation may occur as the user types, after they move the focus away, or when they try to save the form.
• Some variants of this control (e.g., Expedia’s) show two calendar months at a time. This makes it easier to select a date in the next few weeks when the current month is almost over.
• Ideally, the dropdown should implicitly close if the user tabs away from the field or switches to a different window.
• The dropdown calendar may offer a “Today” button that lets the user quickly select, or jump back to, the current date.

Given the wide variety of implementations, and the complexity of this control, it’s not surprising to see wide variation of the quality of implementations. Some do a terrible job dealing with loss of keyboard focus, some don’t parse dates very well, some can’t keep the text and calendar in sync, and so on.

Commentary

Date pickers seem boring, but I think there’s something quite fascinating about them: they may represent a theoretical maximum of complexity possible in a monolithic approach to creating user interface elements. Nearly every user interface framework will offer a date picker — but they will rarely offer something more complex. Why is this?

1. Apps need to let people enter valid dates that a program can understand. This means constraining input and/or parsing dates, and usually rendering a month calendar — and all these tasks turn out to be pretty hard. The problem gets even harder when one wants to handle multiple cultures.
2. The standard combo box solution for a date picker means that, in its normal state, the control to look very boring. It’s just a text box. This lets it fit in with pretty much any application’s visual style.
3. The popup calendar month navigator may not always look elegant, or fit in with the app’s visual style, but since it’s only a transient part of the user experience, design teams decide they can live with it — especially when confronted with a realistic development cost for something better.
4. The variety of situations that come up when picking a single date in the near future is small enough that a monolithic control can handle most of the common situations. Suppose you want to constrain the selected date to a weekday. You can probably find a date picker that lets you handle that specific constraint.

The problem is that, once you get outside the narrow set of common scenarios, you’re out of luck. Suppose you want to let the user pick two dates that are usually close together. In the example above, they want to let the user pick the departure and return dates for a trip. But picking a date range is beyond the complexity of most date pickers. Even if they wanted to support that scenario, the variety of needs would quickly multiple out of control. Some apps would want to force the two dates to be within a certain number of days of each other, others would want to force the two dates to be a minimum number of days apart, and so on. There’s just no way to build a monolithic date picker than can handle all the common cases with a big pile of properties governing control behavior. So user interface frameworks give up on this problem, offer the single-date date picker, and let everyone cobble together multiple date pickers to get the desired result.

In an extensible user interface framework, you could simply provide all the building blocks required to construct a date picker, then let app designers snap those together to get the control they want. So if they want a stock single-date picker, fine, that’s provided, but the same parts can also be snapped together to produce a two-date date picker, or whatever else is needed. Those in turn can be offered as reusable user interface controls.

HTML 5 is not going to solve your problem

The HTML 5 spec defines a new “date” input type, allowing the browser to provide a standard date picker UI. That effort is laudable, but so far inadequate for all but the most basic needs.

The stock date picker controls in the mainstream browsers are god-awful. (Try your own browser’s date control.) Here’s a screen shot of Chrome’s date control:



This is an unadulterated user interface disaster. The format Chrome’s decided to support (YYYY-MM-DD) is one that might be helpful to programmers, but I expect essentially zero consumers actually use it in their personal lives. I can’t think of a single situation in normal life where that format is even seen. In the U.S., at least, people expect to enter a short date like “11/7/2011”, but this format is rejected by Chrome’s control. So this browser’s standard date picker fails to support its home country’s single most common input format. And the little up/down spinner arrows are completely out of place here. They only advance the day portion of the date, they’re tiny hit targets, they don’t let people think in calendar terms, etc., etc. And let’s not overlook the fact that so little attention has been paid to this control that the “up” spinner button is missing its top border.

If you take a look at Opera’s date picker, it’s more functional (it adds a dropdown arrow, a real calendar navigator, etc.) but, visually speaking, it still looks terrible. It’s hard to imagine a design team happy including this bit of UI in a consumer-facing application.

If these controls represent the sorts of designs which browser creators are capable of creating, that doesn’t bode well for the notion that adding more semantics to HTML is going to solve any meaningful user interface problems. Either the browser designers don’t care about those controls, or they don’t have the expertise to design them well, or they don’t see a payoff in doing so. It’s worth noting that having the browser try to solve everyone’s date picker needs is an even more implausible answer than having a monolithic date picker control solve everyone’s date picker needs. Browser controls are less flexible than nearly every date picker control out there.

Whatever the case, in their current state, I wouldn’t advise anyone to use these controls on a web site where even modest usability or aesthetics are a requirement. For reference: Even Google Calendar doesn’t even use Google Chrome’s own date picker.

The situation is different on mobile platforms, where the browser can fall back to the OS’ native date picker UI. They are generally well-designed, or at least have received a considerable amount of design attention (those are different statements).

On all platforms, it should be observed that there’s nothing that says a dropdown combo box is the ultimate UI for picking a date. In fact, in many applications, an inline calendar might actually be preferable. If you have a page that’s all about getting the user to pick a date in the near future, why force them to have to dropdown the calendar first? This is just to say that the right control for the job really depends on context. If anyone tells you that you must use the stock HTML 5 elements to let users enter data, I’d think very hard about whether that person actually has the interests of your users (and your business) in mind, or are simply touting a standard because it’s a standard.

The DateComboBox control

I’ve posted a DateComboBox control to the QuickUI Catalog. (Taxonomy note: this control is called DateComboBox instead of DatePicker to reflect the fact that it’s a combo box, and the fact that there are many other UIs possible for picking a date.)

 

 

As noted last week, the generic appearance of these controls is minimalist by design; they’re meant to be useful and unobtrusive as is, but can also receive further styling, subclassing, etc.

Usage

Use DateComboBox in situations where you want to let the user type or choose a single date (especially one in the near future) and space is a concern or you don’t want to focus too much attention on the date. If picking a date is, in fact, the focus of a UI, then it may be more appropriate to use an inline calendar, such as a CalendarMonthNavigator.

Note that, if the user omits a year, the current year will be assumed. In applications I’ve worked on that let users enter dates (Microsoft Money, Cozi), we always found that users generally expect dates without a year to reflect the future. E.g., if it’s November 2011, and a calendar user in the U.S. creates an appointment with a date of “2/15”, they expect the appointment to end up on February 15, 2012 (in the future) and not February 15, 2011 (the current year, but in the past). At some point, this might be worth fixing in DateComboBox, but for now the control makes the more simplistic assumption about current year.

DateComboBox uses asymmetric validation, which is to say that it will be slow to complain and quick to forgive. By default, if the user types an invalid date, this fact is not reflected visually by an error state until the user leaves the field (or, depending on the UI, saves the form). However, any error state is removed immediately upon the keypress that fixes the error; the user doesn’t have to leave the field to see whether their date entry is now acceptable to the app.

Because the content of the days in the dropdown calendar can be customized, you’re not limited to just showing dates in the calendar. You could show a small amount of date-specific information (e.g., room availability) in the calendar itself, helping the user make a more informed initial date choice.

Implementation notes

To me, the most interesting aspect of the implementation here is that the DateComboBox is assembled by snapping together three main controls, are three of which are interesting in their own right:

• The dropdown portion of the combo box is a CalendarMonthNavigator, the exact same control used to create the FlickrInterestingnessNavigator last week.
• The input portion of the combo box is a DateTextBox. This is a subclass of ValidatingTextBox, and is responsible for parsing typed dates.
• The above elements are joined in a ComboBox. This is the same parent class which was used to create the ListComboBox and ColorSwatchComboBox discussed earlier.

Since I already had the first and third controls in the catalog, the bulk of the work this week was building a reasonable solid date-parsing text box. The hardest part of that work was handling tricky event interactions to ensure, among other things, that the user could navigate within a dropped-down calendar; that behavior to some extent conflicts with the desire to have the dropdown automatically close whenever the user moves the focus away from the text box.

I was happy I could delegate much of the date parsing responsibility to the fantastic jQuery Globalize library mentioned last time, which covers a huge range of culture-specific date formats. In addition to supporting a standard short date format, Globalize also parses a number of other date formats, which is nice even if most users won’t ever use them. (If the culture is set to English, for example, you can type “January 2012”, and that will get parsed and shown as 1/1/2012.) If Globalize is not present, then the control falls back to a simpler parser that supports U.S.-style short dates (e.g., 12/31/2011).

I extended the supported abbreviated formats to handle short years (e.g., 12/31/11) and missing year (12/31). Those formats come up daily in people’s normal lives, so I thought it was important that a date control handle them. (It drives users absolutely nuts that, when scheduling a flight or booking a hotel, they have to enter a full four digit year. Is there some other century they’re going to be traveling in?) The supported abbreviated formats are sensitive to the local culture, so in France those examples would look like 31/12/11 and 31/12, respectively.

This control is designed for full web browsers only. At noted above, mobile browsers already provide fairly good date pickers. It should be straightforward to create a control that uses the HTML 5 date field on a mobile browser and a DateComboBox otherwise.

UI Control of the Week: Rendering arbitrary data on a calendar with a Flickr-style CalendarMonthNavigator

This week’s UI control comes from Flickr, which for a number of years has offered a cool way to browse the most interesting user-contributed photos with their Interestingness calendar:

 

 

As cool as this is, most of the work to build this specific page was probably allocated to reproducing the same aspects of any month calendar built anywhere. That is, some Flickr developer spent a long time mucking about with date math, writing code that had nothing to do with Flickr. I’m guessing that, since the web was first created, the logic to render and navigate a calendar for an arbitrary month in HTML like this has probably been written hundreds if not thousands of times. And there are probably web sites that would benefit from displaying data in a month calendar, but can’t be bothered to make that investment.

Key attributes

• The calendar shows a complete month at a time.
• The user can navigate to the previous or next month. In Flickr’s case, navigation into the future is disabled.
• Each month shows 4 to 6 rows of seven days a week.
• Days in the previous month (on the first row, to the left of the first day of the month) and the next month (in the last row, to the right of the last day of the month) are hidden.
• Given how the photos are selected based on historical data, Flickr only shows photos for days in the past. The current date and days in the future are grayed out.
• A given date is represented visually in two ways: 1) as the number for the day of the month, and 2) as a photo thumbnail. In this case, the photo is the most interesting photo (according to the number of comments, etc.) on Flickr for that given day.
• Clicking a thumbnail pops up more thumbnails of interesting photos on that same day. The popup offers links to specific photo pages, or to a more complete list of the interesting photos for that day.

Usage

I started by creating a general-purpose CalendarMonthNavigator to handle the date and navigation logic:

 

 

Basic controls like this in the QuickUI catalog deliberately come with very generic styling. This allows one to try out the control in a minimalist mode, which hopefully makes it easy to see what the control actually does without getting distracted by its appearance. The generic styling is automatically turned off in a subclass so one doesn’t have to fight much with styles defined by the parent classes. The class used to render individual days is intended to be overridden, so that arbitrary content can be placed within a day.

A month calendar like this is well-suited for displaying date-based information using the principle of small multiples. This could be done to render historical information (sales data, etc.) as Flickr has done here, or to represent information about the future (a weather forecast, a calendar of events, etc.). If navigation is not desired — for example, if the application wants to fix which month is shown — the lower-level CalendarMonthWithHeadings can be used.

Implementation notes

Following the principle of separation of concerns, the base CalendarMonthNavigator is comprised of LateralNavigator and a CalendarMonthWithHeadings, which itself breaks down into a calendar control cornucopia: MonthName, DaysOfWeek, CalendarWeek, and finally CalendarDay.

Once the base CalendarMonthNavigator was finished, creating a custom FlickrInterestingnessDay class was quite straightforward, as was styling the month navigator. Flickr’s calendar shows the names of the next/previous month alongside the next/previous buttons, which wasn’t hard to add. By dropping the day class into the month navigator, the FlickrInterestingnessNavigator (UPDATE: Now called FlickrInterestingNavigator.) fell out cleanly. The result is pretty close to the Flickr Interestingness calendar. One might even say it’s interestingnessish.

As far as I can tell, Flickr’s API lets you grab interesting photos only for a single date per call. Presumably they have an internal API that lets them grab the most interesting photo for each day of a given month in a single call, but no such call is documented. So this particular calendar is forced to make a separate call for each day, which is obviously terrible. Nevertheless, that performance seemed acceptable in a calendar intended mostly as a demonstration of how to create a custom CalendarMonthNavigator. In a real application, one would want to grab all the data in one call at the month level, then apportion the data to the corresponding days.

Given that performance was already an issue, I chose not to implement the popup Flickr shows when you click on a day (which shows additional interesting photos for that day). Instead, clicking a day takes you straight to the page listing the most interesting photos for a given date.

In creating the calendar controls, I was able to make use of the excellent jQuery Globalize project, which defines culture-specific information like month names and day names for a staggering number of cultures. (Thanks are due to Microsoft for contributing their vast culture database.) So the subcomponents MonthName and DaysOfWeek localize their output to the current culture if the culture has been set via Globalize.culture(). Since Globalize also indicates which day of the week should be shown as the first day of the week — i.e., in the leftmost column — I went ahead and localized that as well. For example, the first day of the week will be Sunday in the U.S., but will be Monday in France, or Saturday in Saudi Arabia. (Flickr’s own Interestingness calendar localizes the month and day names into other languages, but doesn’t correctly adjust the calendar presentation to reflect in the local culture’s first day of the week.)

 

Aside: I’ve added a new gallery to the main QuickUI Catalog page, showing live demos of all the controls in the catalog so far. This is only the fourth Control of the Week, but the catalog started out with a handful of controls, and most weeks see the addition of multiple related controls to the catalog, so there’s about 40 controls there now. Based on community feedback, a high priority for the next month or so will be making it possible to use the catalog controls in plain JavaScript, without needing to know anything about how QuickUI controls are created, and without having to use the QuickUI markup language (which is more concise, but entails a learning curve).

UI Control of the Week: Microsoft Office combo boxes, still better than anything comparable in HTML

Sometimes the important user interface components aren’t the glamorous ones. One control the web could really use is a robust, extensible combo box. A standard dropdown combo box has been part of the UI lexicon for at least twenty years. I think I first heard about them when I was a summer intern at Microsoft in 1988 and some application group, perhaps the Microsoft Excel team, circulated a memo (on paper!) proposing their creation. (Perhaps there are antecedents in earlier platforms as well.) The gist of that memo then is the same as the core functionality now: let the user type whatever they want, but also offer them a list of choices they can pick from:

 

 

A combo box is one of those controls that seems like it couldn’t be that hard to implement, but in reality is ferociously complex.

Key attributes

• The user can type arbitrary text into the text box portion of the combo box. In some cases (such as the point size combo box directly to the right of the font combo box above), the text box performs its own validation (e.g., requiring that the input text be a number).
• The user can click the arrow button to dropdown the list of choices. When the user makes a selection from this list, the dropdown collapses, the choice is placed into the text box, and the text is left selected.
• The list provides AutoComplete behavior, even when the dropdown list is collapsed.
• While the choices in the list ultimately can be represented with a text string, the choices may be rendered in richer ways. In the image above, a font is represented by an icon (indicating the type of font: TrueType, etc.), the font name (rendered in the font itself), and additional information on the right in the local language of the culture associated with the font. (I have no idea what the examples on the right say in the image above, but their English equivalents elsewhere in the list indicate the recommended usage for the font: for headings, for body type, etc. UPDATE: Commenter Jonathan indicated that the characters next to the Hebrew font are the first several letters of the Hebrew alphabet. Presumably the other fonts show similar samples of the font’s alphabet.)
• If the current entry in the text box is present in the list, the corresponding list item is highlighted.
• The list provides extensive support for keyboard navigation. The user can toggle the list by pressing Alt+Down; they can navigate the list using arrow keys, Page Up/Down, Home/End; they can make a selection by pressing Enter; etc.
• The list is resizable.
• By default, the dropdown list is at least as wide as the text box. (This behavior is not shown in the image above, but can be found in other combo boxes.)
• The dropdown list is a transient popup that can be dismissed by clicking outside it.

It’s too bad there’s no support for a solid, extensible combo box in HTML, because it’s really quite an elegant control. Many controls on the web are described as combo boxes, but in fact are slightly different, or exhibit fewer features than standard Microsoft Office combo boxes.

• A dropdown list box created with a standard HTML <select> tag (without the “multiple” option) does have a dropdown list, but does not allow the user to type arbitrary text. Moreover, the resulting dropdown list can only render choices as plain text.
• A text box with AutoComplete does save the user some keystrokes, but does not give the user a way to see all the choices. The user may inadvertently (or intentionally) discover some of the choices through typing, but there’s no way to see the complete list.
• The HTML 5 spec defines a <datagrid> element which browsers can use to create a combo box. However, at the time of this writing, support for <datagrid> is lacking, even in the WebKit browsers. Moreover, the existing Mozilla implementation doesn’t offer the user a true combo box, but rather a text box with AutoComplete, and the choices are only represented in plain text (see both of the above points).

Usage

I’ve posted a reusable, extensible ListComboBox in the QuickUI Catalog. This accepts any array of items which can be rendered as choices in the list. By default, choices are rendered as a generic button (without borders), but any custom control class could be used as well.

As implied above, a combo box is well suited for any situation in which you want to allow the user to type arbitrary text, while at the same time offering them choices. The ability to render a choice in the list as a custom control gives you the option of adding more detail, or otherwise helping the user to make a more informed choice. Because a combo box is very compact in its normal state, it can be used in almost any place a text box can.

Although combo boxes have a long history in user interfaces, I’ve observed many usability studies where a user did not actually notice the dropdown arrow. This is most likely a result of the arrow’s small size and placement on the far right; I expect the problem is a bigger issue in very wide combo boxes. Perhaps as a response to this shortcoming, many web sites that have hand-rolled combo boxes automatically pop up the list of choices whenever the user clicks on the text box or moves the focus into it, rather than requiring the user to click the arrow. That actually seems like a reasonable improvement on Office’s combo boxes – it doesn’t seem to hurt much to have the list available, even if the user doesn’t want to use it – so I’ve included that behavior as well, with an option to turn it off.

Implementation notes

ListComboBox derives from the more fundamental base class ComboBox, which is the class that actually binds together a text input control, the dropdown button, and the popup containing the choices. ListComboBox happens to render the choices as a vertical, single-column list, but it’s easy to create controls that drive from ComboBox that present their choices in very different ways. (To present an example, I’ll follow up in a later post on how to create a traditional date picker by deriving from ComboBox.)

As a testament to the complexity of a combo box, I was forced to leave out certain aspects of the Microsoft Office example. In particular, full keyboard support would have taken to long to implement reliably in the time I allotted for this control. Along with keyboard navigation, I’ve postponed working on a means to highlight the current item in the list. The list box currently grows as tall as necessary to show all the choices; with long lists it would obviously be helpful to let the list grow no longer than the bottom of the viewport. Finally, the resizability of the list didn’t seem worth the trouble.

Per usual, various aspects of the control were much trickier to implement in IE. It proved challenging to implement the behavior described above in which choosing an item from the list closed the list and left the entire text selected. Attempting to affect the selection in IE after the list had been closed had the unfortunate side-effect of leaving the list open: programmatic inspection revealed that IE claimed the list was now hidden, when in fact it was still clearly visible. For now, in IE, when the user makes a choice from the list, the full text of their choice is placed into the text box, but is not left selected.

Possibilities

With ListComboBox in hand, it’s quite easy to create a new kind of combo box that works basically the same way, but uses a custom input area and a custom list presentation. In about an hour, I was able to throw together a ColorSwatchComboBox that lets the user choose CSS colors by name or value:

Both the input area and the list show color swatches next to color names. The list of choices is populated simply by feeding the combo box a set of strings (the color names). The ComboBox ancestor class puts the input area and the list together, along with the dropdown behavior. The ListComboBox parent class takes care of rendering of the choices as list items, as well as doing the AutoComplete behavior. So most of the behavior of this rather intricate color picker is handled by the base classes; the classes specifically associated with picking colors are quite simple. It’s this sort of UI factoring that should allow people to quickly create much richer web sites than with the raw HTML controls, even the ones in HTML 5.

Announcing a UI control catalog and this week's Control of the Week: Apple-style SlidingPagesWithDots

I think the web UX field would benefit from having access to an open, comprehensive catalog of working, ready-to-use user interface controls. All programming platforms provide class libraries replete with hundreds of base classes, which are both standard implementations and starting points for custom work — but when it comes to user interface libraries, most provide something like a dozen very basic controls: a Button, a ListBox, a SpinBox, a Slider, etc. There’s also always a DatePicker, and it usually represents the pinnacle of complexity for the UI library. That’s about it. Everything else — i.e., much of the UI components a design team needs — has to be custom made from scratch.

This is incredibly inefficient, and a state of affairs tolerated perhaps in no other branch of software development. Few people seem to realize that a solution is even possible. I think at least one key reason for that is that most UI frameworks don’t define the semantics of specialization (subclassing) by which one person can take another person’s component and specialize both the component’s appearance and behavior to their needs. With such semantics in hand, it should be possible to build a much richer ecosystem for UI components.

A core purpose for the QuickUI framework is to address exactly that need: let people build robust, solid, well-tested base controls that can get quickly specialized for particular needs. To prove that is possible, and to verify QuickUI can do that well, I’m starting a project to create a large library of UI control base classes. My plan to tackle (first on my own, and then hopefully with the help of some of you) as many of the common UI controls found around the web as possible. Many of these aren’t even recognized as shareable controls; they’re often referred to as “patterns”, suggesting there’s no common behavior which could be shared.

These controls will get collected into a catalog of live examples and ready-to-use source code. Each control in the catalog will be live code: not screen shots of examples, not a pattern, not a template for a prototyping tool, not a recipe for doing it yourself. Each one should be ready to use in your web app. Furthermore, each control should be able to serve as the starting point for your own custom refinements. As a side effect, the catalog should also be a useful reference for developers building UI in other ways, but the biggest benefits should accrue to people who can just pick up the working controls and start using them.

As a working format for the project, I’ve been inspired by the efforts of various artists to create a something-a-day for 365 days (e.g., Noah Scalin’s Skull a Day). I think a good control implementation might take longer than a day to code and write up. I think a control a week is a more reasonable goal.

So here’s my plan for Control of the Week:

1. Each week I’ll pick a common control to implement (or improve) and discuss.
2. I’ll code up a solution in QuickUI. Each implementation will generally focus on doing a single UI task really well.
3. I’ll do my best to verify that the solution works as expected in the major browsers: Chrome, Firefox, IE 8+, and Safari. Visuals will be done in CSS3 whenever possible, so things might look different (clunkier) in IE8, but I’ll try to allow for graceful degradation.
4. I’ll add an entry for the control to the QuickUI Catalog. The control’s notes may include suggestions on when and how to use the control in a UI. The Catalog already contains a number of controls ready to go. Some of those will be revisited and spiffed up as part of this project.
5. I’ll post the control’s source code in the quickui-catalog repo on GitHub. From there the source could get copied into any web app project. For now, QuickUI is designed for use with an accompanying markup language, but they could fairly easily be invoked from regular JavaScript. I’ll be working on better documenting how to do that.
6. I’ll blog about the control here. This will likely include a look at one or two examples of sites using the control, and any thoughts on how the control came out. Additional related controls (like RotatingPagesWithDots, below) may fall out of the week’s work, and as time allows I will write up some of those as well.

The project format and details will certainly evolve, but rather than plan that all out, I want to dive in and get started. So without further ado, here’s…

Control of the Week: Apple-Style SlidingPagesWithDots

SlidingPagesWithDots presents its content as a horizontal sequence of pages in which navigation between pages shows a sliding animation. The classic representation of this control is found in the iOS app launcher:

Key aspects

• This control renders its content as a set of pages, one of which is shown at a time.
• A set of small dots below the pages show the user how many pages there are; a highlighted button indicates the current page.
• The user can navigate horizontally.
• The pages slide left and right to provide a sense of physicality — even the unseen pages are conceptually “there”, just not seen.
• To increase physicality, navigation doesn’t wrap once the user reaches the first or last page. Navigating from the last to the first page shows all intermediate pages sliding quickly by.

In a touch screen implementation like the one above, the user swipes left and right to navigate the pages. Apple’s store also uses this device in the “hero” element of a product page (e.g., the MacBook Air page) to rotate between product shots:

Here the pages automatically rotate once through on a timer; the user can also click a dot to navigate to a specific page.

Implementation

Since iOS doesn’t (yet) make swiping easy to implement, for the implementation I’ve focused on the Apple Store-style example. The control renders each child as a separate page, so their visual treatment and behavior is completely open. The dots can be replaced with custom controls. A subclass of SlidingPagesWithDots called RotatingPagesWithDots adds the Apple Store rotation behavior; the rotation interval can be customized.

As will likely become a common theme, getting this to work in Mozilla and WebKit was straightforward, and getting it to work in IE9 wasn’t too bad. Getting it to work in IE8 was an enormous pain that necessitated fixing some optimistic assumptions deep in the QuickUI framework. Furthermore, IE8's lack of border-radius support means that the circular “dots” will degrade to squares. This could be addressed by falling back to a sprited image on IE8, but as I’d already spent more time than I’d intended on IE8, I’ve punted on that for now.

Usage notes

This control seems useful for showing a small set of, say, 3-7 pages. The sliding animation is nice, but for high-frequency tasks could become annoying. The automatic rotation could be distracting in any situation where the user is forced to perform a task while the animation is playing. It seems more appropriate for, say, a site’s home page, where it could be used to temporarily highlight content in the hopes of showing something that interests the user.