New Windows in Safari Touch: A Proposal

By Matt in Constructive Criticism, Design, Usability

Browsing the web on the iPhone is great — page scaling works wonderfully with the high-resolution screen, and Safari Touch (or Mobile Safari, if you like) is well-designed and makes reading in bed or on the bus a breeze. But there’s one thing that irks me: no easy way to open a link in a new window. When you’re browsing blog posts, Wikipedia articles, or, really, any webpage, it quickly becomes limiting to browse the Web in a linear fashion. If you’re like me, there’s some unease associated with trying to remember all the links you wanted to follow on a page. You want to finish reading the page you’re on, but that becomes more difficult as your working memory fills up with all the links you wanted to click further up. By the time you get to the bottom of the page, you’ve forgotten what they were, and you have to go reread from the top. The quickest way around the problem on the iPhone is to open a new page, open History, load the same page again and find the link you want. But that’s inconvenient and less than ideal.

But we’ve a better idea. Two, actually. In our traditionally constructive approach, here’s how ‘Open Link in New Window’ could work on the iPhone.

Click-and-Hold

The trick is in the click-and-hold. On iPhones and iPods Touch, touching a link and not releasing your finger brings up a little callout box with link text and URL, if available.

The Solution

Here’s where we step in. There are two ways, using another finger, that we could imagine opening a new window. The first requires no interface adjustments: just use another finger to hit the ‘Multiple Windows’ button in the lower right, and a new window is opened from that link.

Our second solution contextualizes the ‘New Window’ button by making it even closer to the link: it’s a button in the callout box itself.

If you don’t want to open a new window, and just want to follow the hyperlink, you’d just release your finger and the page would load in the same window, as it does now.

Admittedly, opening links in new windows isn’t the sort of thing every user does (on purpose), even on a desktop computer. The introduction of tabs has undoubtedly affected behavior in that direction, but it’s still the sort of feature that many people won’t miss. On the other hand, we might be willing to wager that the kind of user that has adopted the iPhone is the kind of user that opens multiple links in tabs. But the relatively hidden nature of the functionality in our proposal means there isn’t really a downside: the feature is conveniently tucked away where only those who will use it will see it. For those curious enough to click and hold a link, they’ll likely recognize the ‘New Window’ icon and experiment with it.

We tossed around other ideas (gestures, using the same finger to move to the ‘New Window’ button in the callout), but nothing seemed as natural and obvious as using the existing button. There aren’t any exact analogs to this sort of multi-touch functionality currently, but if you see the multi-touch page and photo zooming functions as “manipulation” actions, then this is a sort of manipulation itself — you’re performing an action on the link. Furthermore, the click-and-hold gesture brings up a loupe when editing text — it’s a sort of “closer look” to specify where you want to place the cursor. Similarly, click-and-hold on a hyperlink is a way to look closer at that link: it functions this way currently, showing you the URL. The addition of a ‘New Window’ button offers the choice of specifying how the link is opened.

So, there you have it: ‘Open in New Window’ for Safari Touch. Any alternative proposals?

Usability on Facebook: The People Take Charge

By Matt in Information Design, User Science, Design, Commentary, Usability

Something is happening on Facebook, but it’s not the sort of thing you’re going to read about on Techmeme. It has to do with usability; specifically, the readability of a collection of comma-separated interests in a person’s profile. Apparently some people think the lists are too close together, and because Facebook doesn’t allow the sort of customization that MySpace does, the users are bending what they can’t break.

For those unaware, one of the default applications that comes “installed” on all Facebook profiles is the “Information” application, which allows the user to list their points of contact as well as their interests, favorite books, movies, and music, and a few other mundane details. Here’s what mine looks like, for reference.

But recently, on a few of my friends’ profiles, I started to notice something different. Here, a friend has separated her massive list of interests with a single dash.

For some, a single dash isn’t enough:

So: users obviously think their interests are hard to read when smushed so close together, right? Or is it just a trend they’re following?

People gussy up their MySpace profiles for a plethora of reasons, none of which we would assume is very practical. I’m sure they’d do the same on Facebook if profiles there were customizable, but it’s interesting to see that this change is one that has to do with usability. The choice and arrangement of applications on one’s profile are one of the most customizable aspects of Facebook, but also prone to increasingly random placement as their number rises on a given profile page. Unlike the placement of applications, this dashes alteration is deliberate. Or is it? I decided to find out. I asked the two friends behind the profiles above about their choice:

Hi! I’m writing up a post for the Sakuzaku blog about something I noticed on your and a few other Facebook profiles. You separate your interests, music, TV shows, etc. with little dashes, like this: [Here I provided an example.]

I find it really interesting that you and a bunch of other people are doing this, and I wanted to ask whether you began doing it yourself or you noticed it somewhere else first? Do you remember where you first saw it, and when? Why, in your own words, do you separate them that way?

I had my replies in only a few hours. C— wrote:

Hiya! Well, actually, I was editing my profile one day and saw that it was a mite long-winded… I wanted to make it look less cluttered and easier to read. A couple of years ago, I had an even longer list of quotations, because Facebook didn’t have as much of a character limit. So, I used a separator at that point too, but it was a long row of stars (the Shift-8 kind). However, with the new character limits, I couldn’t do that anymore. Plus, the areas besides my quote wall were looking kind of cluttered too. So, the dash just seemed like the best solution. It was the first thing I came up with, after I realized I couldn’t do the stars anymore.

Note that she’d been doing it for years, and only recently switched from a row of asterisks to double-dashes because of a character limit.

Coincidentally, the other friend I asked had stopped “dashing” her profile by the time I got around to asking. K— replied:

I actually began doing that on my own when I saw that it was sort of hard to distinguish between what was in what section without a space in between just because of the amount of text I put in there. It doesn’t keep a space between sections if you press enter a few times, except for between the last section and about me. I’m really organized like that, so it was bothering me. I’m not really sure why I changed it back… I think it’s because I started deleting sections and just putting my music and my about me and then gradually added the others again over a short period of time.

Both mentioned, in their own words, that it was about usability: “I wanted to make it look less cluttered and easier to read.” “I saw that it was sort of hard to distinguish between what was in what section without a space in between just because of the amount of text I put in there.” Regardless of whether their desire to separate things visually is driven by a desire to draw more focused attention to their interests, the fact remains that they believe they’re correcting an error in Facebook’s design judgment. This is bolstered by the particularly interesting claim that they each made the decision independently. In a way, they were designing with their “users” in mind: the people consuming their profiles.

The central argument of the piece I published last year, in response to Clay Shirky’s article on A Brief Message about the iPod and MySpace, was that good design is not necessarily arrogance. But there was something else I hinted at: users care about usability, but don’t realize they do. Most people probably aren’t even familiar with the term on a daily basis, but they could probably give you examples of what it means in an applied sense, at least. Thus the popularity of the “beautiful and useful” iPod — it’s popular because it’s pretty and the easiest-to-use MP3 player on the market. They likely can’t tell you that it’s a masterpiece of usability engineering, but they can tell you that they like how it “just works.” Like the iPod, Facebook is a tool that is both usable and popular: A social network done right.

So what does it all mean? I think there are two important and intriguing things to take away from this.

The first is that once users are committed to something (or even, indeed, forced to use it for lack of alternatives), they will change what they think isn’t perfect, to the best of their ability, to adapt the thing to their own standards of usability. Ergo, iPod cases to prevent scratching, and dashes separating big lists of interests in Facebook. (If they can’t change it enough, of course, they’ll leave, if they can.) Secondly, trends in style (especially in technological contexts) inevitably include elements of usability — however unnoticeable they might be to the people participating in the trends.

Sometimes the most fascinating and telling elements of the user experience are found in the smallest of details. Do you agree? Have you seen anything else like this on the Web?

Dollar Signs, Dollar Signs, Dollar Signs!!!

By Matt in Information Design, Constructive Criticism, Usability

We don’t think you should use dollar signs to indicate the price of an eating establishment. It’s too ambiguous and deliberatively uncommunicative to be very useful, and it needlessly conceals one of the most important factors in making a dining decision.

Want some reasons why we think so? Well, here you go:

• There’s no consistency across the myriad websites that have decided to perpetrate this disaster of information design — what should be shorthand always needs to be supplemented with some sort of popup that explains the approximate value range that each group of dollar signs represents.
• The strategy suffers even more when it is out of context. Google search results quite ingeniously display excerpts from each individual page, which are concordanced around your keywords. It is these snippets which guide your decision to click on a page or ignore it as irrelevant. Searching for “greek restaurant honolulu” returns results with useless strings of dollar signs littered everywhere; it’s just not helpful when you’re skimming results looking for grub. You want to know which pages feature Greek restaurants with meals that cost $8–12, not ones with meals that cost two dollar signs.
• The definitions of “cheap” and “expensive” are entirely subjective. A $30 dinner may seem completely reasonable to a working professional, but to a college student, for example, it’s a complete deal breaker. Prices differ significantly in different geographic areas, too.

We’ll pick on Yelp for our constructive criticism this time around, because they sprung to mind (and to the top of our search results page), and because they provide a perfect example.

It’s okay to include a popup to explain how the price strata were established and assigned, but in this case it’s completely unnecessary to enforce that level of indirection — the ambiguous iconography should just be changed to what the symbols represent. (At least, though, Yelp explains what the dollar signs mean — neither Frommer’s nor New York Magazine give even a clue as to what a three–dollar-sign restaurant translates into in real dollars.)

But, this post isn’t really just about dollar signs in restaurant reviews. The general problem here is that the symbols serve very little purpose, except to cloak information and degrade communicative efficacy. The string ‘$30–$50′ takes up precious little more space than ‘$$$$’. Why would you not just include the information itself rather than a placeholder for it? On a map, for example, where information is correlated to coordinates with absolute spatial interpretations, it may very well be prudent to succinctly condense information with symbols. However, a table of results or a restaurant detail page are not maps or graphs — their design should be crafted to expose the information they need to communicate. In these cases we think you should consider very carefully the reasons for employing a scheme that requires further explanation. If you find your interface needs a legend embedded somewhere, that should set off warning bells. There’s usually always room to be clear.

Hunt and Peck: An Investigation and Proposal for Better Custom Keyboard Shortcut Management in OS X

By Matt in OS X, Constructive Criticism, Design, Commentary, Usability

The short story: The interface and functionality of custom keyboard shortcuts in OS X is awkward and unreliable. There are two possible direct reasons for this — Apple’s development priorities and non-standard application resource organization — and any number of underlying causes. I propose a solution.

This is the very long story. I am primarily a Camino user, but like anyone developing for the Web on a Mac, I usually have Firefox and Safari open at the same time too. My keyboard shortcut habits were formed in Firefox, though, and it’s too late to switch from ⌘+K for the search box, and ⌘+⌥+← and ⌘+⌥+→ for tab navigation. Having acquired a new laptop recently, I was reminded just how awful the process for setting up custom keyboard shortcuts is in Mac OS X.

Of Mysteries and Ellipses

If you’ve set custom keyboard shortcuts before, this interface will look familiar. In fact, it remains unchanged since OS X 10.3.

The problems here are manifold.

First, you have to find the exact name of the menu option you want to access. This requires switching back and forth between an open application and the Keyboard & Mouse preference pane, with nowhere but your mind (or a piece of paper, or a Sticky, but come on) to store the title of the menu command, which is itself potentially buried several levels below the top-level menu options.

This is further complicated by the fact that keyboard shortcuts don’t take effect until you’ve closed the very application you were getting the menu option from. (It doesn’t say that anywhere in the interface itself; you just have to come to that conclusion by trial and error or Help when it doesn’t work immediately.) Even if you remember whether, say, that app capitalizes “to” or “from,” there’s no way to assure you’re typing the right thing. The best example of this is the ellipses, used to denote a menu option that triggers further action in a dialog box.

Can you spot the difference?

Here you go:

Apple specifies in the HIG section on Style that menu options requiring further input or confirmation should feature genuine ellipses:

Important: Be sure to create the ellipsis character using the key combination Option-; (Option-semicolon). This ensures that an assistive application can provide the correct interpretation of the character to a disabled user. If you use 3 period characters to simulate an ellipsis, many assistive applications will be unable to make sense of them. Also, 3 period characters and an ellipsis do not look the same because the periods are spaced differently than the points of an ellipsis.

But just because something’s in the HIG doesn’t mean developers will abide. Firefox is a great example. A sample custom shortcut:

And sure enough, it matches up:

This is problematic.

Of course, it’s known that third parties aren’t the only ones who don’t adhere to the HIG. The “Search Google…” menu option in Safari, pictured above, raises a few tangential questions: Does it even deserve an ellipsis? It just quietly puts focus on the Google search bar, which I didn’t notice until I’d tried selecting it a few times. The neglected HIG doesn’t account for menu items that do things like that. Hidden as it is, this menu option in Safari almost seems to exist for the sake of being custom-shortcut’d.

Assuming you do get the menu command title right, there’s no guarantee that setting the custom shortcut function is actually going to work. I spent twenty minutes trying to set keyboard shortcuts in Safari and wondering why they would show up sometimes but not others. In the end I had too many screenshots to deal with. I think this one, taken after I attempted to create a shortcut for “Private Browsing,” will suffice:

Some sort of type-ahead mechanism that would fetch the right menu command for you would solve this problem, but that brings us to why this functionality isn’t already built-in.

Not a Key Feature

Obviously, making the custom keyboard shortcuts interface eminently usable is not a priority for Apple. For the most part, only a minority of users actually know and use keyboard shortcuts. Of those I bet a significant number desire at least some level of customization, but at the end of the day, it’s not a feature that moves units. It’s understandable, then, that it hasn’t been prioritized.

I initially suspected another reason: that improving the process would actually be quite difficult. Here’s why.

While it’s possible to get a complete list of the menu options of any running application with Applescript, it would be best if the preference pane didn’t need to run the application just to get the menus. So instead, providing a searchable list of default menu options for an application (dynamic things like the bookmarks and history in a web browser should be ignored) would require a registered list thereof for every available application. But do these even exist? If so, where?

Turns out they do. But “where” is exactly the problem.

In many applications (both Apple’s and those by third parties), the default menus are found in the MainMenu.nib interface file of an application. See for yourself: ‘Show Package Contents’ on the Safari application, navigate down through Contents › Resources › English.lproj › MainMenu.nib. If you’ve got Developer Tools installed, you should be able to open that file. You’ll see in the MainMenu.nib window something called “MainMenu,” an object of the NSMenu class, which manages an application’s menus.

Theoretically, a list of menu options should be obtainable from this .nib file. Unfortunately, it’s not always in the same place. For Calculator, it’s in Calculator.nib instead of MainMenu.nib. With DVD Player, it’s in MenuBar.nib. For Mail, I couldn’t even find it. So the preference pane wouldn’t know where to look without loading the application to tell it. Right?

Wrong! The location of the MainMenu-containing interface file is specified in the NSMainNibFile property of a given application, listed in the Info.plist directly inside the Contents folder of every application. Knowing this, it’s easy, for instance, to find the appropriate .nib for Mail, MailViewer:

Peachy Key’n

I’ve leave the implementation for another day, but all of the pieces are already there. The Keyboard & Mouse preference pane can already tell when an application disallows keyboard shortcuts:

And it knows that because — and here’s the kicker — it checks the Info.plist file! Check it out:

If a property exists to disallow keyboard shortcut customization, we can only assume that the list of available applications listed in the Keyboard & Mouse prefence pane is drawn from a cached list of applications whose menu commands can be edited. It wouldn’t be too far a stretch to get Keyboard & Mouse to then cache a list of the available commands from the MainMenu object in the appropriate .nib for each safe application.

The interface for finding the right menu command should work just like the new Help menu in Leopard. The screen would dim and a facsimile of the selected application’s default menus would appear. Start typing a command, and the close matches would be pointed out visually with the bobber. Once you’d selected a command (by searching or by manually navigating through the menus with the mouse), the command would fly from the menubar into the preference pane, where you could set a keyboard shortcut for it which would then be checked against existing shortcuts.

Click for a larger view.

A warning dialog indicating that changes to existing keyboard shortcuts wouldn’t take place until the application was restarted would then appear, offering, like Software Update, to quit said application immediately or postpone quitting.

It can be done. It should be done. The ball’s in your court, Apple.

See Also

John Gruber’s article Losers, Weepers speaks to the problems of the OS X custom keyboard shortcut feature, and was written way back in 2003 when the feature first appeared. (There are a lot of similarities there, but it’s worse that the problems haven’t been addressed in four years than me not remembering John’s original post.) He mentions a key problems not mentioned or addressed here but just as vital — the lack of conflict management.

Making netatalk Work on Debian with Leopard

By Cody in OS X, Constructive Criticism, Systems, Design, Usability

If you’ve recently upgraded to Leopard, you might have started running into problems accessing AFP shares on Debian if you’re using netatalk with the cleartext UAM (uams_clrtxt.so).

Trying to connect to the shares results in the error

There was an error connecting to the server. Check the server name or IP address and try again.

It’s not a very helpful error, but if you do some digging, you’ll find out it’s Finder error code 5002, ‘afpBadUAM.’

It was at this point that I remembered that Debian’s netatalk doesn’t include any SSL-related authentication modules because of a licensing incompatibility (see Debian bug #191790). At the time, I wasn’t in the mood to dig into building the package manually, so I used the cleartext UAM — we’re on a secured closed network, and, though Tiger warns about sending a cleartext password every time you connected to a share, it’s more than happy to let you do so. There’s even an option to turn the warnings off.

This behavior has apparently been changed in Leopard — it appears to outrightly refuse to send cleartext passwords. This is probably a good idea, but it means you now have to build netatalk to include the DHX UAM that it doesn’t include by default.

I found two posts by Damon Timm and Durk Hellinga that describe the general process. However, as my comment on Durk’s blog says, I had some problems with circular dependencies. When you try to build the package with dpkg-buildpackage, it complains

Unfortunately, libcupsys2-dev and libkrb5-dev seem to be mutually incompatible with heimdal-dev — aptitude won’t install both at the same time. I tried installing each by themselves and forcing dpkg-buildpackage to build with the -d switch, but /usr/lib/netatalk/uams_dhx.so still wouldn’t show up.

As it turns out, I wasn’t looking at the build output carefully enough. This post mentions to look for the line ‘Configure summary’, and for me it didn’t list the DHX UAM as being built. Looking at the output from the configure script, I realized I didn’t have libssl-dev installed. After installing that, everything went smoothly.

Relatedly, Yvo van Doorn describes how to get your Linux-based AFP server to show up correctly in Leopard’s new Finder. Was Glück! I knew there had to be a Zeroconf daemon for Debian, but I had no idea what it was called, or how to make it work if I did. However, I think the XML configuration for Avahi that Yvo has in his post is suffering from some formatting problems. Here’s my version:

1
2
3
4
5
6
7
8
9
10

<?xml version="1.0" standalone=‘no’?><!–*-nxml-*–>
<!DOCTYPE service-group SYSTEM "avahi-service.dtd">

<service-group>
  <name>%u</name>
  <service>
    <type>_afpovertcp._tcp</type>
    <port>548</port>
  </service>
</service-group>

afpd.service

4 Kilobytes

Documentation for Avahi’s service configuration files

Usability Improvements to Interaction with Network Shares in Leopard

The frustrating and limiting way in which Finder forced you to access network shares in Tiger has long been a sore point with me. First you had to trawl through Network and its mess of ugly workgroup folders and iconless symlinks. Then you had to click ‘Connect’, wait for the authentication dialog to come up, enter the same authentication information every time, and then click ‘Connect’ again. Then you had to select a single share, and repeat the entire process if you wanted to work with multiple ones. And then, heaven help you if one of the connected shares subsequently becomes unavailable. If I was on my MacBook Pro, accessing a share on my Powermac or file server, and then left the house with the MBP, the entire operating system would be brought to a halt for minutes when the MBP was woken up, while Finder spins looking for the lost share. From a usability standpoint, it was completely awful.

The Finder in Leopard has completely solved all those problems. When shares become unavailable, the system doesn’t beachball — Finder just quietly and patiently keeps looking for the share while everything else remains responsive. Tiger left me wishing for an analog to Windows’ ability for network drives to reconnect at login. But the way Leopard has been redesigned to just reconnect to network shares automatically on demand (using the last username you used) beats mapped network drives hands down. It pleases me that Apple completely rethought the problem and introduced a far better solution.

These things all couple to allow me to work with network shares completely transparently, the way I want to. I can drag locations in network shares into the sidebar, and clicking them automatically connects to the share if unconnected. If the share is unavailable, the system doesn’t freeze looking for it. And it’s so great to be able to have our file server show up in Finder’s sidebar now! No more wading to find shares you don’t access regularly — they are instantly accessible. Bravo!