Friday, February 22, 2013

Unsynchronized folder lists in Windows

In Windows 7, Microsoft introduced a new design for the Taskbar. One of its best features, in my opinion, is Jump Lists.
The Jump List for Windows Explorer. Pinned folders are at the top; other frequently used folders are below.
A Jump List is a list of relevant commands an application can perform, brought together in a list that's directly accessible from the application's icon in the Taskbar (and also in the Start Menu). Application developers can customize the list, but even if they don't, two things are available by default: a list of frequently used files, and a persistent list where users can 'pin' files they want easy access to.
Pinned items for Windows Explorer.
The ability to pin folders to Windows Explorer's Jump List is something that's become a seamless part of my computing routine. Pinning items to Jump Lists is easy -- simply drag a folder to Explorer's Taskbar icon, or pin an item that's already in the list of frequently used folders. However, there's a problem.
Another list? What now?
Windows Explorer also includes a separate list of favorite folders within the application itself. This Favorites list is completely separate from the list of pinned items in Explorer's Jump List. My question is: why use two lists? Why not keep these lists synchronized?

My argument in favor of synchronization is that users probably want the same set of folders available for frequent access, whether they're inside Explorer or outside it. Having to curate two lists is extra work, and will probably lead to one list or the other not being used at all. (Personally, I rarely find myself modifying the Favorites list within Explorer.)

I'm not necessarily right about this, however -- debates in usability are best settled with empirical evidence. It could turn out that users do not in fact want these two lists to be synchronized. However, if I had to guess, I'd say this is simply evidence that the finer intricacies of how different parts of the UI could interact have not been thought through. (Note that although my screen captures are from Windows 7, I checked, and the same situation exists in Windows 8 as well.)

What would I do about this, given the chance? I'd gather usage data from users in the wild, seeing how they use these lists. For a given user, I predict one of the following outcomes:
  1. The user uses both Pinned Folders and Favorites actively, and keeps them synchronized (or attempts to).
  2. The user uses both Pinned Folders and Favorites actively, but makes no attempt to keep them synchronized -- each list is radically different, and the user doesn't attempt to change this.
  3. The user uses only Pinned Folders.
  4. The user uses only Favorites.
  5. The user uses neither.
(Naturally, a user's tendencies in this regard are not static -- one of these conditions could easily morph into another one over time.)

Depending on how many users exhibit each of these conditions, I'd take one of the following actions in the next version of Windows:
  • Remove the Favorites list.
  • Synchronize the Favorites and Pinned Folders lists.
  • Provide the option to keep the two lists synchronized, leaving it up to the user.
This is a design oversight; however, I've also had problems with the implementation of Jump Lists. For instance, for a very long time, the Jump List for Microsoft Word would not work -- the Pinned and Frequently Used lists didn't show up, and items couldn't be pinned. That's unacceptable for first-party software. Also, Windows forgets the contents of all my Jump Lists every now and again, entirely out of the blue. I have no idea why. This sort of unreliability diminishes the amount of effort I'm willing to put into using a feature -- since the last time this happened, I've made less of an effort to curate Pinned Items.

Issues like this aren't quite the same as the synchronization issue. However, they all demonstrate that even conceptually strong features like Jump Lists need to be well thought out and properly tested in order to succeed.

Friday, February 15, 2013

Odd URL selection behavior in Chrome on iOS

Chrome on iOS uses a combined search/URL bar, just like the full version of the browser. However, there's a bug in the implementation that makes copying URLs a tiny bit more annoying.

Normally, on iOS, selecting text automatically brings up a set of options for what to do with it. In text-entry fields, you can cut, copy, and paste over the text, and in read-only text displays, you can copy the text.
Selection options for a text-entry field.
Selection options for a read-only text display.
When you tap the URL bar on Chrome, the entire contents of the bar get selected. (In my experience, this is standard behavior on most desktop browsers.) However, in this case, Chrome doesn't display any options.
Where'd the options go?
The only way I know of to bring the options up is to tap the bar again, which deselects everything; tap once more, which brings up text selection options; and then tap the 'Select All' option, which finally selects the entire contents of the URL bar while providing options for what to do with the selection.
Tap once to deselect...
Tap again to bring up selection options...
Tap 'Select All' to select the URL...
Finally, the options you wanted in the first place.
The whole process takes 4 taps, when it really ought to take just 1.

This can be really annoying when you're trying to copy multiple URLs (to share by email, for instance). It's a small bug, and so it ought to be easy to fix.

Update: I've found another way to select the entire URL: tap and hold the URL bar. This selects the entire URL, and brings up a list of options for text selection. Tapping 'Select All' then keeps the text selected, and gives you options for using the selected text.
Tap and hold the URL...
Tap 'Select All'...
The options are now available.
The odd thing about this, however, is that tapping and holding the URL selects the text, while also asking whether the user wants to select text. In order to be consistent with standard selection behavior, Chrome should display the list of actions that can be performed on the selected text ('Cut', 'Copy' and 'Paste') instead.

Monday, February 4, 2013

Facebook footer links

This is a rather daft usability oversight, to be honest. It concerns the set of footer links at the bottom of all Facebook pages.

This is what they look like:
Facebook footer links.
You'll notice I've taken this screenshot from Facebook's privacy settings page. The reason for this is that on the primary Facebook pages, Facebook actively prevents me from seeing these links.

Facebook's primary views (the News feed, Friend and Page Walls, Photo albums, etc.) display information feeds filled with a massive number of items. Obviously, trying to display these contents all at once is futile; therefore, Facebook displays them a few at a time. Good strategy so far.

When you reach the bottom of the current view of a feed, Facebook automatically lengthens the view, adding items from further back in the feed. (For convenience, let's call this type of view an auto-append view.) This has become a popular way of displaying feeds on the Web, recently. I have a few issues with this method; however, that's something I'll talk about later. The problem here is this: even while displaying auto-append views, Facebook still displays its footer links. You get to see them for about three seconds, before Facebook expands the feed, pushing the footer further down.

Now you see it...

...and now you don't.
It does this every time I scroll to the bottom, no matter what method I use (arrow keys, 'End' key, mouse scrolling). It's as if Facebook is playing keep-away with a piece of its UI, and it's aggravating.

You could argue that the links are accessible if you access a Facebook page that isn't an auto-append feed (like the settings page); however, I shouldn't have to visit another page in order to click on links that are clearly there on the front page. Furthermore, although two of the links in the footer ('Help' and 'Create an Advert') are available from the settings menu (which is a persistent part of Facebook's chrome), most of them aren't -- in fact, I haven't been able to find them anywhere else on the front page or in the chrome. (Confusingly, 'Privacy Settings' in the settings menu and 'Privacy' in the footer lead to different places. Meanwhile, 'Advertise on Facebook' and 'Create an Advert' lead to pages that are identical, except for slightly different title formatting. It's weird.)
The settings menu provides access to a different set of functions.
Even if the footer links were replicated exactly in an accessible part of the website, however, it would still be a problem. After all, how do I know the footer links are replicated if I can't see them? For all I know, there might be unique links down there that Facebook simply isn't letting me see. (Which it turns out there are.)

It's baffling that Facebook could leave a mistake like this on its website for so long. How would I fix it? One option would be to make feed views not automatically expand -- that way, anything at the bottom would be accessible. However, that would interfere with a feature (auto-expand views) that many users might like. (Personally, I think there needs to be a better system than append-based feeds, since they tend to get unwieldy, but that's a discussion for later on.)

I think the best method would be to incorporate the footer links into the persistent website chrome. They're clearly meant to be persistent, since they appear on every page; however, Facebook already has a place for displaying features persistently, and that's where these links should appear. (I wouldn't cram them all in the settings menu; instead, they should be divided into logical categories and grouped appropriately, perhaps using separate menus.) There's a rule here: if an information feed (or other information display) is going to expand into a space, don't put anything else important in that space. It'll simply disappear.