usability

3 entries have been tagged with usability.

Hacking the Press – A point for usability in press kits

[Screenshot of the folder window for an example press kit by Realmac Software]

I once saw Adam Engst, of TidBITS fame, hold a talk called Hacking the Press at the Advanced Developers’ Hands-on Conference (the first successor to MacHack). It was a great introduction to how the press works, told with the average programmer in mind, translating the life of a journalist into words we geeks can understand. I don’t remember much of it in concrete details, but whenever the topic of press releases comes up, I realize that I know much more about this stuff than by all means I should, so I guess Adam managed to insinuate himself into my brain quite well.

Recently, Nik Fletcher of Realmac software gave a great interview about press kits, press releases and related matters on the MDN Show Podcast, and I realized that all that great information that was provided there was missing one important answer that I probably first heard from Adam:

Why do I need a nice press kit?

Nik and Scotty were kinda struggling with vague benefits, like “being nice” or “convenience”. But nothing hammers home the point better than a bit of enlightened self-interest:

There are oodles of Mac applications out there. Moreover, there are tons of good ones among them. And all of them send out press releases to the same three score or so journalists who, like Adam, have pull in the Mac world. All of these applications are equally worthy of coverage. So, all those journalists are sitting there, sifting through huge piles of press releases for both bad and good applications, picking out the worthwhile ones. And once they have those, they have to go over these releases again and again, and find the ones they will finally cover in the space they have.

Some choices are obvious: If it’s a “big”, well-known product, it gets covered. If some other similar product has been in the headlines somehow, or hasn’t been in the press (or that particular publication) for a while, a product may get covered to “fill that slot”. Photoshop not done much for you lately? Great! More coverage for Pixelmator and Acorn! After all, users are still looking for good painting and retouching applications. Similarly, if a problem is on the journalist’s mind at the moment, an application that addresses this issue is more likely to be covered.

But what if you don’t fit that pattern? Well, you have to compete with the rest of the worthy apps. It’s a tough call. Now, if your application has a gorgeous press kit with beautiful screenshots/box shots/whatever of your product, and provides a lot of background information and links to relevant articles on Wikipedia etc. that the journalist can make use of for their article, that may just tip the balance in your favor.

We all know how cool it is to find a list of links and information about a particular topic: You start on one Wikipedia page on embroidering and suddenly you’ve read half the site, getting to modern computing via the Jacquard loom, and you’ve learned some interesting things in the process.

You’ve just helped the journalist find an angle that helps cover your product. They can write a witty little intro piece about embroidering, how far it’s come, and if you’re lucky they’ll say that your embroidering application is what all this has naturally led to. Even if the journalist has to truncate the article and that stuff goes away again, the journalist will remember. There’s a personal experience that now connects the journalist to your application, and helps you when it’s up against similarly worthy opponents the next time:

“Let’s see what interesting things the EmbroiderWorks press kit for their new product contains…”

Yes, I’m aware I’m illustrating the ideal, hit-the-jackpot case. But the bottom line remains: When it comes to being covered in the press, you are not just competing against similar applications, you’re also in competition with every other application out there. Many of these are as well-executed as yours.

Having a well-structured, discoverable press kit with the best user experience you can come up with, including URL clippings (.webloc) to lead them to your web site at a double-click, including spec sheets, including a collection of dictionary entries and sources for any required domain knowledge, maybe even including suggestions for articles on topics that include your application, but also others … all of that can help you get ahead of the others and turn a tie into a win.

Installation and Uninstallation on MacOS X

Soeren found an article on easier deinstallation on O’Reilly. The general idea (for the pointy-haired bosses among you who don’t have time to read it) is that every application would get an additional .plist file in its bundle containing the paths of files (like its prefs file) that can be safely deleted along with the application to clean up support files, like the ones in ~/Library/Application Support.

Problems of this approach

My one regular reader may not be surprised to hear that I don’t think the paths idea is a robust enough approach. For one, it would break when the user renames a hard disk. Secondly, some support files’ paths (e.g. Photoshop’s swap files) could be configurable, and then the .plist-info would need to be modified. And it’d be even messier if several users could provide different places to keep these files.

Putting support files in the app bundle itself, as some commenter suggested, has similar problems, especially if the software is on a server and shared between hundreds of users. It’d circumvent users’ disk quota and make permissions for an app bundle unnecessarily complex.

Alternative solution

My suggestion would be to simply add some sort of metadata to such support files and then use the Spotlight index to get rid of such files. Whether it’s done using access control lists, an xattr that simply says: kIsSupportFileOwnedBy = de.zathras.talkingmoose, or they define an OS9-style creator code in your Info.plist that says that all files with this creator are deletable support files, I don’t really care.

If all apps were required to give their support files such attributes, one could even have hard disk clean-up apps that can quickly find any orphaned files, like it was possible on Classic MacOS with creator codes (e.g. FileBuddy checked for files with unknown creators and offered to delete them). It should also be supported by NSDocument without too much work … NSDocument‘s bad support for creator and typecodes is the main reason for bad creator support, along with an ambiguous policy on Apple’s part and the discontinuation of the type/creator registry on their homepage ages ago.

Maybe it should even be a list of owning apps’ bundle IDs in an xattr. That would allow extending this to other kinds of files. E.g. a shared Framework could be auto-deleted when all apps that own it have gone.

Of course, Finder should generally ask whether the admin wants to delete all support files for all users who’ve used this app. After all, they may want to remove the global copy of the app and give two users who still need it local copies when an app is phased out. In that case, they’d want to be able to keep those users’ files.

Other installation/uninstallation improvements

While I’m at it, here’s an idea for making all applications drop-installable, even when they need an installer/uninstaller: Apple could support install and uninstall executables (which could be any of applications, shell scripts or .pkg files) that reside in an application’s bundle in a standardised location:

Users simply copy over the app, and when they first launch it, the Finder runs the installer in it, deploying all needed files. When you delete it, Finder finds the uninstaller and offers to run that.

My Ideal OS

Note: This is not an existing program, neither is this a design for a theme for some operating system. This is a concept how an intuitive operating system should behave.

The situation right now

There used to be a wonderful article by Matthew Thomas, called When good interfaces go crufty which described most problems modern GUIs are suffering right now. After it had gone offline, a kind reader pointed me to a mirrored copy at the WebArchive.

In his article, among other things, Matthew mentioned how annoying it is when there is only a single menu bar left of a program that has no open windows on MacOS. Typically, the user will not notice that this menu bar belongs to another program than the frontmost window, and, after a little confusion, will realize that he has to click the frontmost window to activate it.

Windows tries to avoid this problem by having menu bars at the top of the window they belong to, instead of at the top of the screen. This leads to a proliferation of menu bars on the screen, where many users click the wrong one accidentally, as well as making it harder to open a menu, because when a UI element is at the top of the screen, you simply shove the mouse violently until the arrow stops at the top of the screen, move it sidewards and click the appropriate menu. Since the screen edge stops the mouse arrow, you needn’t precisely hit the object you want to work with (“mile-high menu bar”-metaphor). That may not sound like much, but considering the typical user probably chooses thousands of menu items during a sitting at the computer, it quickly adds up.

Below you’ll find my attempt at a solution. Tell me what flaws you see in it and/or how you’d attempt solving them.

The Menu Situation

[Image of a window with a shortcut menu that has a stylized arrow in the corner pointing at the object the menu is shown for]I think it was Acorn that came up with the idea of an operating system that works entirely using contextual menus without a menu bar. For the uninitiated, a contextual menu is the kind of menu that pops up when you click an object on the screen with the right mouse button (“shortcut menu” in Windows parlance). It contains only the commands relevant to this particular object, and it also is very intuitive to use, because you perform the actions you want directly on the object, just as in real life.

One problem of contextual menus, however is that they are rectangular, and after you’ve clicked an object, it may be hard to see exactly what object the contextual menu belongs to. To levitate this, I chose to have a little arrow in the corner of the menu, pointing at the object that caused the menu. MacOS X has something similar for contextual menus of its dock icons. Use of smart and reliable positioning algorithms is very important here.

[Image of a mouse arrow with an icon of a menu to its lower right]Some users will probably remember how many problems they had with two-button mice, clicking the wrong button by accident and all that, and ask how this approach is supposed to be less flawed. Simple: Modern mice usually have a scroll wheel stuck between the two mouse buttons. Since I got a mouse with a scroll wheel, I never mis-clicked again. The scroll wheel functions as a tangible separator between the two buttons. So, in practice, it is quite hard to hit the wrong mouse button on modern mice (buggy technology like the Mighty Mouse excluded), and it has finally become useable even for beginners.

Also, my ideal OS would reserve the right mouse button exclusively to bringing up contextual menus. By hard-wiring the connection between menus and the right mouse button in the UI, users will quickly comprehend that the right mouse button is simply a “menu key”, maybe supported in that conviction by actually printing a symbol on the right mouse button. That way it’s just like learning that the return key takes you to a new line.

[Image of a contextual menu plus submenu with a border of 4 pixels indicated around them, and two lines connecting the corners of these borders]However, contextual menus have one flaw: It is impossible to distinguish manipulatable objects on screen from those that can’t be manipulated. To make it more obvious to the user what can be manipulated, I opted for a cursor change, as it is used in most web browsers. Whenever the mouse is over an object for which a contextual menu makes sense, a small icon of a menu is overlaid over the current cursor, to indicate a right-click isuseful here.

To avoid confusing users, this little image should disappear again once the menu is being displayed, to strengthen the user’s impression that this menu was always there, and they merely enlarged it by clicking, and to avoid the misconception that a right-click on a menu itemwould bring up another contextual menu. This could even be made to really zoom out from a thumbnail image with today’s graphics technology.

Also, contextual menus should automatically hide themselves again when the user clicks outside them, or when the mouse leaves a certain area around the menu. This area should be chosen thus that the user can still safely drag from a menu item that has a submenu to one of its sub-items in a straight line (after all, that’s what most people will be doing). Through this behaviour we avoid that the user feels “stuck” in a menu, which sometimes happens e.g. on MacOS, where you must click to get rid of a menu. Alternate ways of exiting, like hitting “escape” are fine as well.

Also, if when the mouse passes over a menu item with a submenu while on a line between a menu item and its submenu, there should be a delay so that the second submenu doesn’t pop up by accident if the user really is just dragging across. Hovering for a moment or clicking will of course change to the next submenu, as needed.

This approach has the following problems, though:

  • The user has to move the mouse over an object to see whether it can be edited, and has to click different locations on the screen to find out what options are available. Overlooking one of these objects means the user can’t see a particular part of an application’s functionality, while a menu bar contains all commands available. However, in most OSs these days, this is true for pretty much everything, and users have long since become used to secondary clues to the clickability of a UI element. Careful design and a little research should be all that’s needed.
  • Programmers of complex applications are tempted to add lots of submenus to their contextual menu, thus effectively turning them into “pop-up menu bars”. Thus, one would have to take great care to improve navigation through submenus. Maybe one would even want to create a pop-up menu bar, as it existed back in the day for HyperCard as an extension. That way one would have horizontal navigation to switch between menus, and vertical to choose items from a menu.
  • Users of Notebooks may have a hard time because trackpads typically allow clicking by tapping the pad, which doesn’t distinguish between left and right mouse buttons. Same goes for people with pen-controlled computers. While right-click on a trackpad could probably be simulated using the two-finger-tap, I’m not sure there’s a good solution for pen PCs yet. Maybe a button on the pen like graphics tablets have them?
  • As contextual menus show up next to the mouse arrow, they often obscure part of the object you’re working on. However, since a menu is usually only used shortly to choose a command, it should be gone by the time users need access to information displayed by other objects on the screen.

Managing Files and Documents

[Image of a shortcut menu shown for an application's icon that contains items like 'New' and 'About']Most modern OSs, as Matthew notes, have the concept of “launching” an application. When was the last time you found yourself “launching” a piece of paper before using it in real life? Right, this concept is completely artificial. Moreover, while there was a necessity for having this behaviour in old OSs, most modern OSs don’t really need this. MacOS X has pretty much reduced the difference between a running and a not-yet-launched application to a littleperiod of waiting when first opening a program. Most Unixes can turn down any application to use 0% of CPU resources while its not being used, without unloading it in the traditional sense.

So, for my ideal OS, I declare the distinction of running and inactive applications dead. You no longer have a “dock” or a task bar which keeps icons for each running application, taking up screen space even for programs you’re not using right now, or forcing you to install your applications in a particular place. Instead, you simply right-click the application icon in your regular file manager, to get a menu with its important menu items, like “New” for creating a new file, or “Preferences” for setting up the program’s options.

This menu will be handled mostly by the OS. Only when you actually select such a menu item will the OS internally launch the application, pretty invisible to the user, save for maybe a short period of waiting. If the application has any windows open, a list of those will also be displayed in this menu (or maybe a submenu if there are too many).

So, as far as the user is concerned, an application is identified entirely by the application file. You put it (or a symbolic link to it) wherever you see fit. Thus you avoid the common dichotomy where some options are only available when you click an application’s icon in the file manager, others are only available from the dock, and again others are only available from the application icon in a window’s title.

Whenever you click an application’s icon, be it in a window title, or in a file manager (Explorer, Finder) window, you will get the same contextual menu. By having the application’s icon in the window title bar, you can quickly get at the options for the application that displayed the current document, the same way you could when you still had a menu bar.

Another thing Matthew pointed out is the “File Browser”. Although every OS I know of has a half-decent file manager application, most also offer a file browser window, which is basically a reduced version of the file manager so you can choose files to open, or you can choose where to save a file. While this was necessary in 1984, when you could only run a single program at a time, it isn’t anymore. Today’s computers happily let you switch between an application and the file manager. So, I’m declaring that one dead, too.

Instead, you get a”New Document” menu item in the application’s shortcut menu. This simply creates a new, empty file named “untitled” (or “untitled 1” if that name’s already taken) on your desktop. Then you can use the file manager to move it into a directory where you want it, and of course, you can rename it as you see fit. (note to programmers: Yes, renaming and moving should work even when the document is currently open and in use) So essentially, it works like astationery pad: You tear off a page, write something on it, maybe write a heading above it and that’s it. You can also tear off a page for later use, or whatever.

Note also that there is no “Save” menu item. You get unlimited undo capability, if you want that, and maybe an “Undo history” window, but beyond that, why bother with such artificialities? Computers today are fast enough to save as you go, and the application can keep backup copies of files internally if file corruption should become a problem, or the OS could use a database or subversion as the backend.

I received a lot of feedback about this choice to get rid of the “Open File” and “Save File” dialogs. In particular, people were complaining that files would end up in some default location and users would have to constantly move them where they wanted them to end up. There are numerous ways to work around this:

  • Creating them in some default location using one of the techniques below, but doing like MacOS and allowing that the user drag a file’s icon from the window’s title bar to wherever they want to save the newly created file.
  • Automatically having new files created in the frontmost (i.e. current) File Manager window, or on the desktop if there are none open. This has the same problem as current file managers, though, that it’s not a reliable place and you might “lose” a file.
  • Having the File Manager take note of the user moving files immediately after creation, and automatically creating them in that location the next time. This also has the disadvantage that the user may have problems finding a newly created file if the OS keeps creating them in different places.
  • Allow specifying default locations for files of different file types or files created by certain applications as a Preference, e.g. in the Control Center of the operating system, or in a standardized panel of the application’s preferences window.

Filling in the Blanks

[Image of a window with a tab instead of a title bar,docked at the bottom of the screen]

One more thing: Since the file manager of my ideal OS is pretty much run-of-the-mill otherwise, I thought I’d mention one peculiarity: To provide quick access to your documents and programs, apart from regular folder windows, you can have “query” windows as well as “docked” windows. The latter are probably known as “pop-up windows” to users of MacOS 9 and earlier. They are simply file manager windows that you can drag to the edge of your screen, where they will reduce to a “tab”. Click on that tab (or drag a file onto it) and the window will slide out, functioning just like the dock or the task bar. The difference is that this one can contain the contents of any file manager window, and you can drag items onto the items in the tab, e.g. to tell a compression program what file to compress.

A query window looks just like any other file manager window that lists the contents of a folder (aka directory) or drive. The difference being, that you can specify certain criteria as to what files it should display. For example, you can have it display the eight most recently used applications, or most recently used documents. Or you could have them display all image files on your disk, or whatever.

If you combine these, you get pretty much the behaviour of the task bar or the dock: A list of the items you’re currently working with, easy for quick access. Even better, you can have several of these, containing e.g. lists of your favorite applications for different purposes. You’d have a “DTP dock” and a “Programming dock” and a “Drawing dock” or whatever.

And finally, you could even have docked windows that do not slide in when unused, but rather stay open all of the time, in their own reserved area of the screen.

Feedback

[Sequence of application icons slowly 'running full']One of the biggest problems in modern, multi-threaded OSs is that of feedback. When you open an application in Windows, it simply takes a while before you actually see the result of your action. This delay causes many users to click twice, or three times,and they get two or three copies of the same application, or worse, file icons begin stacking up ontheir desktop or whatever.

MacOS X is a little smarter by having application icons bounce in the dock while they are being opened. While this is nifty, it is also quite annoying, as a similar bounce is used to indicate when an application needs your attention. Not to mention that, after clicking three or more applications, you start to become really seasick from all those bouncing icons.

What is needed is a more subtle effect. In the old, mostly single-threaded days, we had animated cursors, or a small animated cursor that was overlaid on the mouse cursor. While this is a nice approach, we can’t have the cursor constantly animating. One solution in Unix OSs to this problem is to only animate the cursor when it is on top of the window that is busy right now, but this again requires that users constantly swipe their mouse over several windows to find out whether it’s finished (a problem our contextual menus will already have).

So, what we need is something more precise than just infinitely bouncing icons. Also, it should be more subtle, and we also need something that works for any user interface element, as users always need feedback whether a button is finished doing its thing, or whether it’s still cranking away. So, my idea is to just hijack an effect I saw in Compact Pro, where an icon slowly inverted from the bottom up, just like a progress bar.

In principle, something like this can be done with any kind of UI element, and if we make sure that this goes smoothly (maybe using alpha blending), and instead of inverting an object we just tint it in a slightly darker shade, the user needs only a single glance to know whether it’s finished, while not being distracted by jumping pixels everywhere.

Note that this darkening must be noticeably different from that performed when the button is clicked,so the user is aware that the click was noticed by the UI, but it’s still working on the action. And this feedback should also happen for short actions, so the user can trust the UI to always behave the same. And the darkening should really correspond to the actual progress going on. While easy on the programmer, progress bars and animated cursors that are kept animating by a separate thread are next to useless for the user when trying to determine whether an application has frozen or crashed.

2006-11-05, merged this article with the addendum.

2003-03-31, thanks to Tilman, Sam Kington, Matthew Thomas and Reinhard Auer for their input.

2002-11-16, thanks to Matt and Reinhard for their input.