flow|state

Like snapping together a skyscraper: Web components will catalyze a completely new ecosystem for creating UI

In just a few years, the ecosystem in which we create UI will change so dramatically that it will be hard to remember how we did things way back in 2012.

For a sense of perspective, consider a similar change that transpired over a much longer period of time in a different industry: home construction. If you were building a house hundreds of years ago, you might have directly built or overseen most of the elements that went into your house: the framing, the hearth, the chimney, the roof, the windows, doors, you name it. You built nearly everything yourself — there were hardly any components. Depending on where you lived, the only pre-built components you might have used would have been small and simple: glass from a glazier, bricks from a brickmaker, hardware from a blacksmith, and pipes or tiles from a ceramist. Even a glass window would have its surrounding parts — the case or sash, the wooden frame, the sill — measured, cut, and assembled on site and for a specific window. If you hired a craftsman like a carpenter or mason, everything they built for you would have been created on site specifically for your house.

Now build a house in a modern economy. The majority of your home’s elements are components assembled elsewhere by specialists and shipped to your construction site ready for final installation. When you design a house, you now spend a lot of your time looking through catalogs of these components. Most of those components come in standardized dimensions or configurations. Many are quite complex. You can buy an intricate multi-part casement window in a variety of window configurations as a single, complete unit that includes wood, metal, multiple layers of glass, glass treatments, hinges, locks, screens, and other hardware. You can find a similarly dizzying selection of pre-built roof joists, plumbing fixtures, or light sconces, or other components. If you want a component that someone doesn’t already offer for sale, you are either visionary or insane.

 

A tiny handful of configurations for window components (source: Window Express)

 

The componentization of the building industry means you can get a lot more house for a lot less money, and the resulting home can be better suited to your needs. Most of the factory-made components will be of better quality than what any one individual could make themselves on site. (It’s the site-built skylights that leak, not the factory-made ones.) And not only is the resulting building different; the component ecosystem brings about myriad new roles and industries.

Now consider software, where we’ve labored for years hand-crafting every element of the user experience like a medieval builder. The browser or OS gives us a tiny number of simple UI primitives; we must write nearly everything else in the UI by hand. For simple designs that are essentially fancy documents, one can use a visual editor of the Adobe DreamWeaver ilk, but you still have to roll up your sleeves. And any UI that affords any significant degree of interactively is created substantially in code on either the back end or front end. To the extent that UI code is “shared”, most often it’s actually copied and then hacked to fit, rather than implemented with a truly shareable component. If you did static analysis of the UI code for the 100 most popular web apps, I’ll bet you’d find that only a tiny percentage of that UI code is actually shared with another organization.

If only there were some standard for composing and extending web UI components, we’d be able to unleash a UI ecosystem that would transform the UI world as thoroughly as the physical building component ecosystem has changed home construction.

The UI field may actually undergo a bigger transformation, because the software world isn’t subject to the same constraints as the physical world. It is possible to create responsive UI components that change based on the device context, meta-controls that generate UI from more basic controls, adaptable components that change based on the user’s abilities and experience, and components that directly exploit third-party services.

With such tools in hand, it should be possible to create huge, complex interfaces in a fraction of the time it currently takes, and for far less money. You’ll be able to assemble the UI of a significant application very quickly, and get something interesting that in many ways actually works. It will be like snapping together building parts to create a skyscraper.

This transformation is still in the future, but it’s coming. One important step here is Google now taking the lead on a spec for web components that will standardize how components are defined and interact. A good summary can be found in Web Components Explained. (Years ago, Microsoft tried to promulgate a standard for HTML Components, but it never caught on.) While closure on the web component spec is still off in the future — and broad availability is, of course, even further away — this new world is coming.

This can’t happen soon enough. It will finally free us from having to waste such an ungodly amount of time attending to the design, coding, and testing of common user interface patterns, and let us move our attention up the value ladder to focus more on our own products’ domains.

This development will ultimately commoditize some large portion of the industry’s UI output. As with the building industry, commoditization of UI elements will catalyze the creation of new roles in the UX industry: specialists who create components, component integrators, component testing labs, standards groups, and many more people in more organiziations creating better UI because they can start with solid, usable components addressing many of their needs.

I’m excited by what this will mean for the QuickUI control framework. Google’s web component spec will eventually let the browser natively address the lowermost functions which QuickUI must currently perform in JavaScript. This will enable much better performance, better isolation and modularity, and faster adoption. It’s too early to say how QuickUI evolve in this regard, but I want to direct its evolution such that it will transition smoothly to the standard web component foundation when that becomes widely available. Among other things, I’d looking at how to evolve the open QuickUI Catalog of common UI controls so that they can someday be delivered as web components on the standard foundation. The goal is that someone using QuickUI controls today will find their investment preserved and profitable when the component future arrives.

If you’re interested in tracking Google’s work on the topic, they are posting announcements on Google+ on the Web Components page.

Control of the Week: Pinterest-style PackedColumns efficiently fills space with tiles of varying heights

Image-sharing site Pinterest is the current darling of the social media world, and the core of its user experience is its attractively-designed home page:

 

 

This page takes good advantage of available window real estate. As the user makes the window wider, the page re-lays out the columns of image tiles (or “pins”, in the parlance of the site) to take advantage of the extra width:

 

 

The page must accommodate a wide range of tile heights, as the photos have different aspect ratios, and the number of comments per pin can vary. If the page simply laid out the tiles in a strict grid, it would waste a great deal of space. To use the space more efficiently, the page employs a “packed columns” layout.

Key attributes

The packed columns layout algorithm is straightforward:

1. Divide available width by the standard item width to determine how many columns can fit.
2. Make all columns initially empty.
3. For each item in turn, add the item to the column which is currently shortest.

The simplicity of this algorithm is such that it’s been independently recreated multiple times. The algorithm has some nice properties:

• It’s fast.
• As much horizontal space is used as possible (while still showing entire items). If a user gives the site more width, they’re rewarded with more information.
• The arrangement is visually interesting.
• The positions of the first few items are stable.
• At any given page width, the overall heights of the columns will be roughly equivalent. If the user scrolls to the bottom, they won’t find an unbalanced amount of space under any particular column.
• The relative vertical position of any two items is preserved across resize operations. If item A appears above item B at one window size, then item A will always be above (or on the same row) as item B at any other window size. The user doesn’t need to understand this; it just means that if some interesting item is “near the top” before a resize, then after the resize the same interesting item will still be “near the top”.

The last point speaks to another benefit of the algorithm which doesn’t show up in Pinterest, but does show up in other applications: the consistent relative positions of items means you can offer users the ability to specify an order or prioritization for the items that affects (but doesn’t completely determine) where items end up. I used this years ago in the design for a home page for Microsoft Money, a personal finance application whose home page included a user-customizable set of home page modules. A Settings dialog let the user specify the priority of those modules by dragging the modules within a one-dimensional list. While the ultimate two-dimensional position of the modules depended on the window width and the modules’ current heights, the priority of any given module determined how close to the top of the page that module would end up. This limited degree of customization was sufficient to meet many users’ needs without having to create a full-blown customizable layout UI.

PackedColumns

I’ve added a PackedColumns control to the QuickUI Catalog. There’s a link to a demo that simulates the general appearance of Pinterest’s home page. (I initially centered the items in the demo the way Pinterest does, but turned centering off to make it easier to observe the layout behavior.)

Usage: Use PackedColumns to arrange a collection of child elements whose widths are fixed but whose heights vary substantially. If the heights are relatively consistent, users will likely find a traditional grid presentation easier to interpret and use.

Commentary

Given the simplicity of the algorithm, this wasn’t all that hard to code up. I expect it’s not necessarily the actual cost of a layout like this that deters sites from adopting it. Rather, it’s the current need to independently discover or reverse-engineer behavior like this that most inhibits its adoption. As design knowledge gets coded into controls, however, such UI should become more pervasive.

In essence, an ability to easily create and adopt create web components will lead to a commodification of user interface elements. Today Pinterest’s insight and ability to create a packed columns layout may confer a slight competitive edge, but someday commodification will quickly eliminate such edges. This will be true not just for UI elements that can easily be independently created, but for nearly anything. The day after a new site launches with a cool new UI trick, that trick will be copied and packaged up as an openly available and readily adoptable UI control anyone can use.

UI Control of the Week: Repeater control generates multiple copies of UI elements

User interfaces invariably entail a certain degree of repetition; they’re filled with vertical or horizontal sequences of UI elements that behave identically are are styled identically. Sometimes the elements in such a sequence vary only in their label, and sometimes even that doesn’t vary; the controls really are all exactly the same. As an example, if we go back to the first post in this series on UI controls, we find that Apple’s sliding pages with dots control contains a horizontal sequence of little dot buttons. The variant of this control on Apple’s web Store uses blue dots:

Those little dots along the bottom don’t contain any data, and so their DOM representation of each is essentially identical. (The blue selected state comes from a style applied with a class.) Sequences of completely identical UI elements like this are relatively rare in a production UI. During design and development, however, it’s pretty common to want to throw a bunch of placeholder controls into the UI. Early in the design process, a prototype’s toolbar might have buttons labeled, “Button 1”, “Button 2”, “Button 3”, and so on, until the team can work out exactly what commands they want to offer users there.

But, despite the repetition, creating a collection of buttons like that is generally a manual process: the designer or developer must manually create a set of buttons, and carefully give them each a unique, placeholder name. Alternatively, one writes a bit of throwaway script to generate a given number of controls, although that can take a few minutes to work up.

The recent post on placeholder controls pointed out that it can be worthwhile to have a UI control even if it’s only used during the design process; anything that saves time helps. Here, I think it’s interesting to have a control specifically for the task of generating repetitions in a UI. As with the previously-discussed ListBox, this is effectively a higher-order meta-control: a control that creates or manipulates other controls. This can be useful for mocking things up during design. And, per the Apple example above, it might even be useful in production UI.

Repeater

The QuickUI Catalog contains a Repeater control. Given a control class and a number, it will create that many instances of that class. If you create a Repeater and give it a dot button class and a count of 5, you’ll get:

 

 

With that in hand, you can easily bump the count up or down to get whatever number you need. If you want to see what things look like with 20 copies of the dot control, instead of doing a cut-and-paste of your UI code, you can just change the desired count to 20:

 

 

If you give the Repeater some content, each generated copy of the control will end up with that content. Here a Repeater has been told to create 5 instances of a simple button class and set their content to the text, “Button”:

 

 

For a bit of variety, you can also ask the Repeater to append an incrementing integer to the content:

 

 

This is another one of those controls that, now that I have it, I end up using quite a bit. When poking around with a layout idea, it’s great to be able to fill up the UI quickly with a sequence of elements.

Implementation notes

It’s easy enough to create a one-off bit of JavaScript that creates an arbitrary number of controls, but why rewrite that code every time you need it? By investing just a bit of time in creating a reusable component, even that simple bit of code has already been written for you.

The implementation of Repeater has become simpler over time as the QuickUI framework has gotten better at supporting the creation of meta-controls. These controls generally have one or more properties that accept a control class as a value. Creating such a property is easily done in a single line using a Control.property() declaration. A recent update to the QuickUI runtime makes it also possible to pass in arbitrary UI in Control JSON format, so you can use the Repeater control to generate n copies of some brand-new UI fragment containing a mixture of other controls.

As suggested above, a Repeater is incorporated into the implementation of the Catalog’s SlidingPagesWithDots and RotatingPagesWithDots (which adds automatic rotation) controls. Once the number of children (pages) is known, the control can simply pass that number to the Repeater’s count() property to generate the required number of dot buttons.

UI Controls of the Week: Making HTML check boxes and radio buttons work the way they should have in the first place

Here’s the current Sign In UI on a typical e-commerce web site (United Airlines, one of the largest airlines in North America) with a minor but common user interface bug:

 

 

The bug is this: the “Remember me” check box can only be checked by clicking the tiny 13 by 13 pixel square; clicking the text label for the check box has no effect. This minor but common bug appears on many web sites because an HTML <input> check box on its own can’t define a label. The label can only be defined by creating a separate <label> tag. I have no idea who came up with this arrangement, and can only imagine that this was intended to allow flexibility. It does allow, for example, a check box label to be placed above, under, or to the left of, a check box. But this flexibility comes at a cost: many web developers aren’t aware of the need for <label> tags, and so they end up with check boxes with static, unclickable labels. HTML radio buttons suffer from the same issue.

Of course, users have been long trained by client OSes that the text next to a check box or radio button should be clickable. It makes sense, after all, to give the user a large hit area (especially on a touch device). If the site above were to correctly define a check box label, the hit target would be 600% times as large as using the box alone, at no additional cost in screen real estate. Furthermore, the UI would be more accessible to a larger population, including vision-impaired people using screen readers.

The situation is improving, and a quick survey of some highly-trafficked web sites shows that many of them do correctly define labels for check boxes and radio buttons. But even some popular sites do not, or don’t do so consistently. Quantcast estimates the above United Airlines site gets about 1M U.S. visitors a month, and it’s fair to guess that some significant portion of those people are being driven through the faulty Sign In UI above.

The problem persists because here it’s harder to create a correct UI than an incorrect one. For the correct result here, the developer has to:

1. Hear about the need for the <label> tag and learn how it works.
2. Remember to use a <label>.
3. Set an ID on the <input> element.
4. Create the <label> element.
5. Type in the user-visible text.
6. Set the label’s “for” attribute to the input element’s ID.

In contrast, to create this check box the wrong way, the developer just has to:

1. Type in the user-visible text.

A check box created the wrong way looks pretty much like one created the right way, so it can be hard for the team creating the UI to spot the bug. And, of course, when the problem exists in UI that’s generally shown only to new users (like the UI above), team members will rarely be exposed to the bug themselves.

Usability experts can exhort the correct use of <label> tags until they’re blue in the face, but a real fix requires that it be easier to create a correct UI than an incorrect UI. Client OSes have made this easy for years, and I can probably count on one hand the number of times I’ve seen a check box in a client app in which the text was not correctly clickable.

Oh, and one more thing. On the web, it turns out that even if you do things the way you’re told to, your check box or radio button UI may still have a tiny bug. By default WebKit and Mozilla put an unclickable 3px margin around the input element. So even if you use a <label> tag in the recommended fashion, you still end up with a 3 pixel gap (highlighted below in red) between the input element and the label:

 

 

Clicks in this gap have no effect! This is a teeny tiny bug that nevertheless happens to show up in WebKit and Mozilla on nearly every web site. (IE takes care to leave no gap.) This probably means that on any given day thousands of users happen to click in that gap, and are puzzled that nothing has happened before they quickly click again. I noticed that one site, Gmail, carefully works around this very issue by overriding the margins on the check box and label to eliminate the gap. Once again, it seems the platform makes it harder to create a correct UI than an incorrect one.

CheckBox and RadioButton

I’ve added CheckBox and RadioButton controls to the QuickUI Catalog that implicitly associate a label with an input element, and close up the gap described above.

These aren’t particularly fancy or interesting components, but they’re nevertheless simple to use and solve the problem defined above. I wish HTML check boxes and radio buttons had always worked like this.

Implementation notes

Both CheckBox and RadioButton inherit from a LabeledInput base class that creates the automatic link between the label and the input element.

I originally implemented the LabeledInput base class as an inline div containing an input and a label element, and had some JavaScript explicitly link the two elements with a generated ID. But then I noticed something interesting on Gmail’s sign in page: the input element is inside the label element, right before the static text. I’ve never seen this approach documented on pages that describe the use of <label>. Every site seems to document the label appearing in the HTML immediately after the input. But putting the input inside the label seems to work in all the mainstream browsers. The advantage of this approach is that there’s no need to set the “for” attribute on the label; the label automatically binds to the input element it contains.

Taking another hint from Gmail, the LabeledInput class also sets margins so as to leave no gap between the input element and the adjacent text.

Finally, as an extra bonus, the RadioButton control solves an annoyance specific to HTML radio buttons. An HTML developer must manually designate an internal radio button group name for each radio button in the group that should work together (i.e., which should be mutually exclusive). This isn’t hard to do, but it’s still an extra step, and more work than should really be necessary. So, by default, if you don’t explicitly put a RadioButton into a group, it will automatically group itself with any siblings (with the same DOM parent) that are similarly ungrouped.

UI Controls of the Week: Quickly fill up a UI mockup with photos, placeholder text, and ads

When you’re designing a new UI, you often need to experiment with a variety of UI layouts in advance of having content that’s representative of what your UI will eventually display. This is a good thing — you don’t want to be burdened with the task of creating meaningful content when you’re focused on layout and navigation flow. In the exploratory stages of design work, it’s also important for you, or your design’s reviewers, to not get caught up too much in the generation of sample content.

This is why designers have long used Lorem Ipsum placeholder text to fill up a design. It looks like real text (which would not be the case if you simply mashed the keyboard), and you can generate an infinite amount of it to fill up any design you’re working on. Most designers also have a collection of placeholder images or advertisements they can use to fill up a design mockup. One service will dynamically serve up placeholder photos of kittens, although I’d imagine the conspicuous presence of zillions of kittens will be highly distracting for most web site designs.

Although end users never see these sorts of placeholders, they’re nevertheless an essential element in the software development process. I’ve yet to see placeholder components included in a UI library, but it seems eminently reasonable for these placeholders to be packaged up as reusable controls. Anything that cuts down on design time is money in your company’s pocket.

With that in mind, the QuickUI library now has several placeholder controls:

 

LoremIpsum

The LoremIpsum control generates an arbitrary number of paragraphs of Lorem Ipsum text. You can control number the number of sentences per paragraph. By default, the first sentence of the first LoremIpsum control starts with “Lorem ipsum dolor sit amet…”, but you can control that as well.

FlickrInterestingPhoto

The FlickrInterestingPhoto control grabs a photo from Flickr’s Interestingness collection for the previous day. You can pick one of Flickr’s standard image sizes, or you can use CSS to scale the photo to an arbitrary size.

I use Flickr for this control because it’s free, has a good API, has high-quality images, and the images will change each day. It’d be pretty straightforward to adapt the control to another photo service.

AdPlaceholder

Finally, the AdPlaceholder control creates a rectangle the size of any IAB standard ad unit, or you can specify an arbitrary size.

I’ve looked for a server that would serve up meaningful ad images, but haven’t found one. Some sites will give you a small set of ad placeholders, but they’re too boring to be convincing, and the small size of the sample set means you get too much repetition. An ad placeholder service would be quite useful. It would give advertisers free exposure, although the ad server would need to be rigged to not count such impressions as meaningful. All this means that it’s hard to provide a general-purpose ad placeholder control. It would be quite easy, on the other hand, to create an ad placeholder control that worked against a specific ad server and ad account.

 

Using placeholders like these let you quickly fill up a mockup. E.g., the demo for the PersistentPanel control uses all three types to block out a fairly interesting layout on the fly:

 

 

In practice, I’ve discovered that these dynamic placeholder controls deliver a substantial benefit over relying on static content: the random content forces me to cope with layout situations I might not expect or encounter until far later in the development process. Designers have a innate tendency towards perfection, and invariably pick sample content to make a layout look as appealing as possible. For example, a design for a window will typically show a set of content that perfectly fills the window, but as I noted long ago, such a design is probably too good to be true. Your team will end up evaluating a design according to a degree of theoretical perfection that will never be seen in production. By building mockups around dynamic content, you force yourself to recognize and adapt to a more meaningful range of text run lengths, picture aspect ratios, and so on.

UI Control of the Week: TabSet for traditional tabbed pages

This week's control is the standard tabbed page UI found throughout client apps and web sites. Here's a typical example, from iTunes Preferences:

Key attributes

• The tabs typically represent different aspects of a single object, or different areas at the same navigational depth in a hierarchy.
• There's one button for each tab. Clicking a button selects the corresponding tab.
• The button for the active tab is always visually highlighted in some way. Often the active tab is shown on a surface contiguous with that of the active page. (iOS tabs don't do this.)
• The tab button are usually arranged horizontally across the top, but may also appear arranged along the left or, more rarely, the bottom.
• All tabs share the same width, and usually the same height as well. This consistent size probably was originally intended to reflect the consistent physical size of the atavistic tabbed paper folders that inspired this UI representation, but even now the consistent size is useful in helping the user recognize all the tabs as related aspects of some single thing. (Exception: On the Mac, a tabbed Preferences dialog like the one above, in which the window holds nothing but the tab set, will change size as the user changes tabs.)
• There's usually just one row of tabs. (Multiple rows are clunky: they prevent the active button from being adjacent to its corresponding tab, or else force tab rows to switch places.) This generally means the number of tabs is usually low, typically in the 3–9 range.

TabSet control

I've posted a TabSet control in the QuickUI Catalog that manages a set of tabs:

The pages within the TabSet can be any type of element or control, although for convenience a Tab control is provided to make it easy to set the page's descriptive label.

Usage: Use a TabSet when you need to fit a large number of controls into a comparatively small space, and the controls can be grouped into meaningful tabs with clear labels. The controls in each tab should generally only have local effects within that tab's UI; it would be extremely confusing if checking a box in one tab disabled some control on a different tab.

A scrolling page may often be a simpler alternative to a tabbed UI. One advantage tabs do have is that the labeled tab buttons provide a summary; they help give the user an overview of what object properties, navigational areas, etc., are available. To the extend the tab labels are meaningful and clearly reflect the tab's contained controls, this labeled structure may accelerate a user's search for a particular control.

Implementation notes

I've built TabSet top of a more primitive control called Switch. Switch acts as a container for other elements, and will only show one of those elements at a time. (The "Switch" name is inspired by the "switch" statement in programming languages like C and JavaScript.) There are actually plenty of cases where a UI will contain a mutually-exclusive set of elements, and not all of these cases happen to look like tabs, so upon reflection it's somewhat surprising to me that more UI toolkits don't offer something like a Switch control.

In this case, the TabSet wraps a Switch, adding a List of buttons and populating them with the description() property of the corresponding tabs.

The trickiest part of TabSet turned out to be handling the common case in which the TabSet itself should be as tall as its tallest tab (regardless of the individual tab heights). This allows for a consistent border or background, which helps the user interpret the disparate tabs as being closely related; it also avoids potential document reflow when the user switches tabs. The standard ad hoc solution in a case like this is to force all the elements to a known height (e.g., in pixels), but hard-coding element sizes seems like a cop-out if one's goal is to create a flexible control that handle a wide range of content. It seems like TabSet (or, actually, Switch) should be able to inspect the height of its contained elements and automatically resize itself to be as tall as the tallest contained element. This gets tricky because Switch normally hides all pages except the one which is active, and the height of an element hidden with display: none is reported as zero. To work around this, the underlying Switch class has been modified so that, in the auto-maximizing case like this, Switch hides the inactive pages with visibility: hidden instead (which lets the elements report their correct height), then uses absolute positioning to superimpose and top-align the pages.

A related complexity arose in the case shown in the TabSet demo: the height of a tab may change based on asynchronously loaded content (e.g., an image). So the update of any tab's content, even one which isn't currently visible, may potentially force the TabSet to resize. Unfortunately, there isn't a standard DOM resize event for elements other than elements the user can resize (such as the window). So QuickUI controls have to make do by raising a custom event when they resize, allowing controls like Switch to adjust their height accordingly.

It's boring details like resizing that forces most designers to throw up their hands and resort to hard-coded pixel dimensions, but UI controls that can flexibly handle dynamic content are ultimately far easier to use and work with as a design evolves.

Using QuickUI controls in plain JavaScript

I’ve heard from people who are interested in using QuickUI (including the controls I’ve been discussing here in Control of the Week posts), but who want to do so in pure JavaScript. If this sounds like you, I have good news:

1. The framework has received a number of updates over the past two months such that it is now practical to use QuickUI in pure JavaScript and CSS.
2. I’ve put together an interactive tutorial that shows you how to do this.

Until now, it’s been easiest to develop in QuickUI using a proprietary HTML-like markup language which, though nice and compact, also necessitates the need for a client-side compiler. Now that the markup requirement has been removed, you should be able to use any of the QuickUI controls described here in any web app.

By the way, the above link will take you to a new, separate QuickUI blog that’s intended as a more technical resource for people already using the framework. I intend to keep the flow|state blog here as a separate venue for discussing UI design topics. Posts here may touch on QuickUI (given my current work), but my goal is that those posts will still be interesting and relevant to an audience of designers who don’t code or aren’t interested in coding.

I'd just like to offer thanks to the individuals who have provided me with feedback on the evolving shape of QuickUI. Your thoughtful commentary has been invaluable!

UI Control of the Week: Coding a ListInlay pattern that lets user expand list items in place

I think the concept of a pattern language is a useful lens with which to consider interface design, but we don’t have to settle for patterns as static, textual descriptions. The first pattern language was grounded in the domain of physical architecture, and while the concept was deeply insightful, many people have applied it to the domain of software user interface design without, I believe, recognizing that the constraints of building architecture don’t apply to software design. Given a properly expressive UI framework, many UI techniques described as patterns can be implemented in code.

I’ve been a fan of attempts to catalogue UI patterns since I first came across Jenifer Tidwell’s Common Ground. Tidwell’s latest work is presented in her recent second edition of Designing Interfaces. Many of the patterns it describes contain some non-trivial element that can be given a functional manifestation in code. To use an analogy from programming languages, UI patterns are somewhat similar to abstract base classes. Such a class defines some, but not all, of the behavior necessary to create a useful result. In my mind, the more interesting a UI pattern is, the more likely it is that some aspect of the textual description can be identified and coded in a reusable UI control.

Take, for example, the List Inlay pattern, in which a list lets the user expand an item to see more detail in place. Tidwell points to Amazon’s mobile review UI as one example:

 

 

Each list item shows a capsule review. Tapping a review expands the item in place to show the full review text and some additional details:

 

 

Key attributes:

• All list items are typically collapsed by default.
• Clicking a list item expands it to reveal more information about that item, possibly including interactive controls. Clicking an item which is already expanded generally collapses it.
• The list may either allow multiple items to be expanded simultaneously, or may permit only a single item to be expanded at a time.

A List Inlay can also be used to implement the common “Accordion” user interface pattern as well. As far as I can tell, there’s not much hard difference between these two patterns. A List Inlay is essentially an Accordion which shows live data, whereas the UI elements described as Accordions tend to have static headings that have been hand-authored to summarize their contents. Beyond that, to me these two patterns seem nearly the same.

ListInlay control

Here, the above attributes of the List Inlay pattern are fairly straightforward to code. With those requirements in mind, I’ve created a ListInlay control for the QuickUI Catalog:

 

 

Usage: Tidwell suggests using a List Inlay when…

Each item has interesting content associated with it, such as the text of an email message, a long article, a full-size image, or details about a file’s size or date. The item details don’t take up a large amount of space, but they’re not so small that you can fit them all in the list itself. You want the user to see the overall structure of the list and keep that list in view all the time, but you also want her to browse through the items easily and quickly.

In contrast, if the item details are complex, or offer substantial editing capabilities, it may be more appropriate to navigate to the details in a separate window or dialog, or show the details in a separate detail pane, rather than expanding them inline.

The ListInlay class permits a single item to be expanded at a time, so clicking a new item to expand it will collapse any previously-selected item. I’ve also created a multiple-select variation called MultiListInlay that permits multiple items to be expanded at once.

Caution: Some applications use a variation of this UI for navigation, e.g., as an accordion pane on the left side of an app window. It’s not uncommon for such apps to dock the list items to the top or bottom of the navigation pane (with the selected item filling the remaining space in the middle). I believe such a UI is likely to exhibit usability problems: at large window sizes, a user looking at the navigation items docked to the top of the pane could easily overlook additional items docked to the bottom.

Implementation notes

This control was a pleasure to code up. A ListInlay is just a subclass of the previously-discussed ListBox meta-control that, by default, uses a Collapsible to represent list items. Combining these two controls worked right away, and from there it was simply a matter of customizing how ListInlay renders a list item’s selected state. Instead of just adding a CSS “selected” class, the list also needs to invoke the Collapsible’s collapsed() property. (I.e., when an item is selected, it’s collapsed property should be set to false.)

The real treat was that basing this control off of ListBox means that, with no additional work, ListInlay offers basic keyboard navigation. The control’s generic appearance doesn’t show the selected state, but once the list has focus, you can navigate the list with the Up and Down keys. It was a pleasant surprise to see that the navigation UI played well with the expand/collapse animation; score one for Separation of Concerns.

It’s hard to describe, but this sort of coding reminds me a lot of coding in Lisp. In Lisp you can make use of higher-order functions like mapcar to concisely express complex calculations. In the same vein, coding in QuickUI often entails using a meta-control like ListBox to quickly create the reasonably complex behavior of something like ListInlay.

Of course, the point of a control like ListInlay isn’t that it’s a polished, production-ready result in its own right. As with an abstract base class, what makes it useful is that it could form the basis of something interesting. As I’m going through “Designing Interfaces”, it’s possible to pick out those patterns whose interaction details are consistent or specific enough that they could similarly be translated directly to code. I’m adding the most interesting such patterns to the QuickUI road map for future work.

 

I'll be traveling this week to Dublin, Ireland, for the Interaction 2012 conference. If you'll be there, please drop me a line!

UI Control of the Week: Google-style TransientMessage to show quick, modeless progress or confirmation

Sometimes an application has to deliver to the user a brief, non-vital message. A number of sites, including Google’s app suite, show such messages in a transient popup that presents a small bit of information for a second or two, then disappears on its own. Here’s a typical “Loading…” message, which appears over the standard Google toolbar:

 

 

An earlier generation of client applications might have shown such information in a status bar. One disadvantage of a status bar is that it’s always there, which not only takes up room, but can inure a user to its presence; they might easily overlook a message that appears there briefly. In contrast, the very appearance of Google’s “Loading…” message over the top of the toolbar helps draw attention to the message.

The “Loading…” message above obviously disappears when the loading operation has completed. In other cases, the message is used to confirm the successful completion of an operation. For example, if you use Cozi to send a shopping list to a family member’s mobile phone, a transient message lets you know the list has been sent successfully. In these cases, a message typically remains visible for about two seconds before fading away, in order to give the user enough time to read it. This sort of message UI may be preferable to a traditional modal confirmation dialog in cases like these where because the information is not vital. If the user happens to look away while the message is visible, they can nevertheless assume the operation worked; the message is just providing explicit confirmation. The fact that the message fades away on its own avoids forcing the user to take a second to dismiss it manually.

Key attributes

• The message goes away on its own, either when an operation completes or when sufficient time has passed to let the user read the message.
• It’s not absolutely essential that the user see the message. Hence, the app doesn’t require that the user acknowledge the message.
• The message content is fairly short, perhaps one medium-length sentence at most. Since reading speeds vary, the longer the text is, the longer variation you’ll have in how long users need to read it. Even if the message is not essential, it would nevertheless be disconcerting to a user for the message to disappear before they could finish reading it.
• The message often visually appears docked to the top of the page (as shown above) or centered vertically.

TransientMessage

I’ve posted a TransientMessage control to the QuickUI Catalog. As you’ll see on that page, I’m experimenting with the impressive, embeddable ACE code editor from Ajax.org to let you experiment with controls directly within the Catalog documentation. If this works out, I’ll look at rolling it out to the rest of the Catalog. (Known issue: The page with the code editor doesn't work in IE8 yet.)

As usual, the generic styling of the message can be changed to suit an application’s visual aesthetic.

Use a TransientMessage to deliver a short message, e.g., as a modeless indicator of a short operation (the loading example above) or as a confirmation of an operation that has just completed. If the message text is more than a simple sentence, or if it’s critical that the user acknowledge the message, consider a standard JavaScript alert or a Dialog instead.

Implementation notes

This control is built on top of the general-purpose Popup base class, making implementation relatively straightforward. One side effect of this implementation is that any click the user makes while the message is displayed will dismiss the message. In future versions, it might be nice to let the user continue to interact with the UI during the short period while the message is visible.

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!