flow|state

Squeeze wide page content into narrow windows: let the content overlap the left navigation pane

UI designers can find themselves challenged today by the need to address a huge range of window sizes. In Cozi’s case, we still target 1024x768, but we want to take advantage of additional space in larger sizes (sometimes much larger), and we want pages to function all the way down to 800x600. Sometimes we have to invent to tricks to work well across this range of sizes.

That 800x600 minimum size, for example, comes into play surprisingly often. It never fails to surprise me how many users with small monitors leave windows in their default positions, which can often be unnecessarily small. And the current generation of netbooks (and now tablets) can have rather short or narrow displays, so even users who maximize window size can still end up with a pretty small window.

Cozi’s current design places navigation links in a left pane, and page content on the right. One challenge at small window sizes is leaving ample room for the left-hand navigation at all sizes, while still making right-hand page content (e.g., calendar data) wide enough to be useful. Typical patterns for balancing these forces:

1. Make the left navigation as narrow as possible. The downside here is that, on large monitors, the navigation ends up feeling narrow — literally marginalized.
2. Size the left navigation width as a percentage of window width. Others might find that they can pull this off, but in our case, we couldn’t find a simple percentage that worked well across the range of window sizes we wanted to support.
3. Let the user set the width of the left navigation. This can work well, but punts the problem to the user to solve. Many users won’t realize they can resize the left pane, and even for those who do, many won’t bother investing time tuning the display of a tool they only use sporadically.
4. Let the user collapse/dismiss the left navigation. A special case of the above point, with the same issues.

We came up with another solution: let the page content overlap with the left navigation pane.

It’s likely we’re just independently reinventing an existing solution, but it’s worked out well, so here’s how it works. At wide window sizes, a typical Cozi page looks like this. The navigation links and other content (e.g., the family photo) on the left are completely exposed.

As the user resizes the window to be narrower, the page reduces the width of the right-hand page content. When a threshold is reached, however, the right-hand content begins to overlap the left pane. This threshold varies by page, depending on how much width they need to show their content. (The calendar shown here in Month view demands a good deal of width, so its threshold is above 1024px page width. Other pages, like Settings, don’t need so much.)

This overlap continues all the way down a size that reveals a minimum amount of the left pane. (Below this size, the right content will start to clip.)

In this overlapped state, the user can still see enough of each navigation link to tell what each one is. E.g., the visible text “Calen” on the left is obviously a link to the calendar; “Shopp” is the shopping list, and so on. In this state, the user can mouse over the left navigation to see the full pane pop forward:

If the user now moves their mouse back to the right, the left pane drops back to the background.

The show-navigation-on-hover solution requires that we handle one case specially: If the user clicks a navigation link on the left, then when they arrive on the new page, the mouse will still be over the left pane.

• The user’s most likely next action is to move the mouse to the right to interact with the page content. As soon as they move the mouse, the page will sense the mouse hovering over the left pane. It’d be annoying at that point to pop the navigation forward again — this would distract the user, who is trying to get to the right. So we disable the hover on page load until the user got the mouse to the right, then turn it on.
• However, some of the time, the user may be using the left pane to surf around the product. Perhaps they’re just exploring, or they’re looking for something and don’t know what page it’s on. They’ll be clicking in the left pane immediately after the page loads, without ever moving the mouse to the right. To support that case, we examine two factors: the direction the mouse is moving, and the time that has elapsed since the page loaded. If the user moves the mouse to the right reasonably quickly, we continue to suppress the hover behavior. However, if they move the mouse straight up or down, or linger on the left, then we re-enable the hover behavior.

(The latter behavior was borrowed from a similar trick used to finesse pop-up behavior in hierarchical menus. I believe it was Microsoft who first came up with this trick for Windows or Office; it then made its way to OS/X. [UPDATE: Commenters recall that the Mac had this first.] If the user wants to move from a top-level menu item to a submenu, their mouse may cross over a point that’s not over either of those elements. So the OS uses a combination of timing and mouse direction to decide whether the user is still moving towards the submenu, or has decided to explore other top-level menu items instead.)

So far this overlap solution seems to be working in practice. Most users don’t see it much, and users with narrow window sizes can now see more page content while still having full access to site navigation. All of this is achieved automatically; the user doesn’t have to pick up the burden of optimizing the page display for the current window size.

Some observations of the pluses and minuses of Android's user experience

For the last few weeks I’ve been playing with an Android phone, a Motorola Droid X. The UI takes some adjustment for an iPhone user like me, not unlike they adjustment I’ve made going back and forth between the Mac and PC several times over the years. In evaluating the Android user experience (including aspects shaped by Motorola), the following points seemed interesting to me.

1. On a touch device, it’s easy to constantly forget the presence of the hardware buttons. A glowing, colorful screen with detailed interactive elements is just too visually compelling to remember that, in some applications, critical features are only available via the hardware Menu button. A typical experience for me has been to stare at a screen looking for the UI element I’m certain should be there, and only a frustrating minute realize, “Oh, that’s right, I forgot to check what’s hidden behind the Menu button.” If it’s not on the screen, I can’t be bothered to keep checking it. It took me forever how to get out of “directions” mode in Google Maps because I was in a maze of twisty little passages (all alike) each of which produced a slightly different Options menu when the Menu button was pressed.
   
   I think the Menu button flies in the face of evidence that users do better when they have a clear and consistent search path for finding the commands available at any given point. Jensen Harris wrote on this topic in his discussion of why the Microsoft Office team invented the Ribbon to provide “the one and only place to look for functionality in the product”.
   
   The same thing goes for the other hardware buttons, especially the Search button. It seems like a shameless ploy to plug Google search out of all proportion to the button’s utility. Even if an application has a Search feature, it seems like they’d want to be certain users remembered it was there by offering an on-screen UI to invoke it. Given that, why burden the user with an extra hardware button?
   
   
2. Long press to invoke commands = Win. The ability to hold down one’s finger on an object to invoke what’s essentially a context menu (“Quick Actions”) is a gain for power users, and doesn’t impact users who are unaware of this facility. When I go back to the iPhone, this is the Android feature I miss the most. Thankfully, this useful UI convention is already starting to make its way over to iPhone apps.
   
   On the downside, this UI will likely lead to a wave of “long press people”. Their habit will parallel that of “right-click people” on Windows: users who, at some point in the past, found the right click button produced some interesting commands. They therefore now right-click on everything—the Windows Start menu, OK buttons, everything—whether it has a context menu or not.
   
   
3. Dear Google: Thanks for taking the iconic dropdown arrow, an element which otherwise universally communicates “Click me”, and using it as a completely static element that offers no interaction whatsoever.
   
   
   
   That little arrow-in-a-circle next to "Map mode"? Users want to click on it. They want to click on it because every other app they have ever used has used a similar icon as an affordance for interactivity. By abusing this dropdown arrow icon, Google might untrain users from clicking on it when they see it. Google’s non-standard use of this arrow is precluding the standard use of it on Android. (Cozi’s own mobile UI plans called for using a dropdown arrow-in-a-circle very much like the one above, and we’ve had to abandon that for fear that Android users wouldn’t click on it.)
   
   
4. Motorola made a curious decision to set the geeky robotic “Droid” sound from a Droid X marketing campaign as the phone’s default error sound. So Motorola has decided that, at completely random intervals throughout a customer’s day, the device should proclaim in a loud robotic voice, “MY. OWNER. IS. A. GEEK.”
   
   If you like that, great; I'm all for self-expression. If you want to customize your phone to announce new emails with Worf's voice stating, "Captain... Incoming message", more power to you. That's your choice. Having a phone manufacturer make a choice like this without user participation seems unaccountably presumptuous.
   
   This one tiny experience made me feel like Motorola views me as nothing more than a marketing tool, and they don't care if they make me feel stupid in front of my friends. I disabled the sound at the first opportunity. It took a bit of hunting around. Let’s imagine there’s a normal person out their who doesn’t want to have their phone scream that they’re a geek. How quickly will they learn to hate their new phone?
   
   
5. Motorola has managed to completely conflate Droid and Android in the minds of mainstream consumers. Perhaps this is due to the aforementioned marketing campaign, but it’s more likely a result of Motorola’s savvy willingness to pay Lucasfilm through the nose for the rights to the “Droid” name. I’ve personally seen the effectiveness of this branding decision—on a daily basis I see requests from Cozi users asking when we’re going to have a “Droid version”. It’s certain that many of those users are actually asking for an Android version (which we’re working on, BTW)
   
   [UPDATE: A reader pointed out that Verizion, not Motorola, is the firm that licensed the "Droid" trademark from Lucasfilm.]

1. I still don’t see the high value of Home page widgets. Maybe my usage will change over time, but it still seems odd to have to, say, swipe my Home page to the left twice in order to see a few calendar appointments, when I could also just launch the Calendar app and see all my calendar appointments. When I go back to the iPhone, I don’t miss Home page widgets at all. Widgets seem like a great idea in theory. In practice I’d imagine most people just can’t be bothered to invest a bunch of time optimizing their phone’s Home page in order to get a miniscule gain in efficiency. YMMV.
   
   
2. It’s fantastic to be able to install apps without valueless interference by the carrier, manufacturer, or OS provider. Freedom to install the apps you want is a core part of the Android value proposition. It’s good for users. It’s great for ISVs during app development. Platforms that make ISVs happy often do well; the conventional wisdom is that it’s an unnatural—and probably unsustainable—state of nature for developers to hate the OS they’re developing for. Installing a prerelease build of Cozi’s iPhone application is a pain: I have to get my device ID to a developer, who has to embed that ID in a list of devices approved to run the prerelease build, and then have to go through shenanigans with iTunes to install the app. Installing a prerelease build of Cozi’s Android application is a breeze: just click a link to download and install the app, and I’m done.

Reconsidering stock controls to create an optimized user experience

One of my core design principles is that, when a designer tackles a new problem, they start by trying the simplest thing that could possibly work. Once you get that into users’ hands, you’ll discover whether the simple thing works. You might have gotten lucky, and can move on — or else you’ll learn what users really want (as opposed to what you thought they wanted) and your next iteration will be much better. The thing to avoid is stopping after the first iteration, avoiding improvements to UI elements that are clearly core to a product’s function. This situation often comes up with the use of stock controls, because their ubiquitous presence and fundamental nature often blinds people to other possibilities.

Take the standard solution for entering a time into a form. Given the above design principle, it’s completely reasonable that people designing calendar or calendar-like interface would start by using stock HTML controls to input appointment or event data. In the case of entering the appointment time, the standard solution is a SELECT tag, which on most browsers produces a dropdown list box. Here’s a typical example from Expedia flight search form:

Expedia time picker

This time dropdown list works, but isn’t particularly elegant, and has numerous shortcomings. Depending on your browser, you may only see about 18 times at once, so you’re often forced to scroll to select a time. This scrolling issue is exacerbated by having the dropdown start by showing times from midnight through the early morning — times that are unlikely to be selected. (In other words, the first third of the options shown will rarely be picked.) Furthermore, the times aren’t aligned for easy reading. And, despite the heavy capitalized AM and PM markers, from usability experience I can attest to the fact that users will often overlook these, and select a time 12 hours off from the time they want.

Overall this is a brute force solution to a problem. That would be fine for an initial attempt, but seems puzzling on the home page of a site where task completion time (here, selecting flight parameters) almost certainly has an inversely proportional effect on revenue.

It’s even more puzzling to see the same stock control used as a core component of a web-based calendar, where the entire point of the site hinges on entering appointments. Yahoo! Calendar uses essentially the same stock control, with all the same shortcomings:

Yahoo! Calendar time picker

Google Calendar and Microsoft’s Hotmail Calendar (or Windows Live Active Calendar, or whatever it’s called this week) are more puzzling still. Both sites have developed custom time pickers, and in both cases they’ve created combo boxes to allow typing times (in addition to picking from a list). From experience, I can say that this is a non-trivial endeavor — it’s surprisingly difficult just to correctly reproduce all the keyboard navigation and other interaction behavior of a standard dropdown list, let alone improve upon it.

But for all their investment, as far as I can tell, in both cases the dropdown list behavior is no better than the standard solution. In fact, both solutions are worse because the dropdown list is, amazingly, shorter than the stock control. The Google solution only shows six times at once; Hotmail’s shows ten. It’s almost impossible to use these UIs without scrolling to find the time you want. It’s also noteworthy that both sites fail to take the opportunity to improve the legibility of the times and leave them left-justified.

Google Calendar time combo box

Hotmail Calendar time combo box

With these object lessons in mind, I really wanted to find a better time picker solution for Cozi’s own family calendar. When we began working on our own combo box time picker (following the same pattern as Google and Hotmail), it struck me that all the scrolling pain resulted from an insistence on showing all times in a single vertical column. Moving to multiple columns let us show a complete day’s worth of times at once, and completely eliminate scrolling:

Cozi multi-column time combo box

Once we introduced the idea of using the horizontal dimension, we realized we could take it even further. Each row normally shows just the top of the hour, but the row the mouse is over also shows additional fifteen minute increments within that hour. This allows the user pick, with a single click, from 96 discrete times. We also align right-align the hours to improve legibility. The fact a user can see all the hours at once makes it slightly more likely they will choose the AM or PM time correctly, an effect we’ve tried to reinforce through a background gradient to suggest day versus night.

In practice, this control works exceedingly well. It’s very fast, and thorough usability testing of the control over the years has shown that users intuitively grasp its use, despite never having seen anything like it before.

I mention this not (just) to toot Cozi’s horn or to sneer at other calendar sites. The other sites mentioned above all have aspects in which their user interface is better than Cozi’s, and I aspire to match them in those areas. My point is that stock controls such as dropdown lists are so pervasive as to be invisible even to the product’s own designers. These controls are a perfect starting point for a UI design—but they shouldn’t be the end. If your product uses a stock control (or any basic UI pattern) in a core function, it might well be worth your time to reconsider those controls and explore an optimized solution.