Chapter 3: Breaking the Browser (Part 2)
3.2 Embracing the desktop: the new old paradigms
I have given a lot of space so far to browser paradigms and user expectations of them. Interaction paradigms can also come from the desktop, by which I mean both the operating system and also client-side applications such as Microsoft Word, Adobe Photoshop, etc.
Although I’m sure there’s a small contingent of computer users who connect in coffee shops and schools only to the net (and are subsequently oblivious to the desktop and client-side applications), I’m still going to make the sweeping generalization that most computer users are familiar with desktop interaction paradigms. They know to double-click on a folder to open, know that right-clicking will reveal shortcut menu commands, and know to drag a folder here or there to change its location on the hard drive. All of this knowledge falls apart on the web however, because of a change in context and the demands of the browser. Sure, many newbie users double-click impatiently on links and other objects, but through daily negative reinforcement they have learned this and other desktop interactions are a no-no.
The browser can stand in the way of many desktop interaction paradigms. One thing to always remember is that your application is subservient to the browser, and at times the browser is a cruel master. The browser can make the decisions about display options, rendering, keyboard shortcuts, and other things. And it’s difficult to map these obstacles because each browser is different (Firefox, Internet Explorer, Safari, etc.), there are differences between platforms (Mac, PC, Linux, etc.) and worst of all, the user may just decide to go ahead and tweak the preferences in a completely unique way (block popups, configure keyboard shortcuts, etc.).
Your application may have other masters too, and may need to adhere to other platform or plugin considerations. Flash is one application that can confuse browser behaviors. Some web browsers swallow the keyboard commands before they make their way into Flash. For example, Gliffy allows the keyboard shortcut for copy, but so does the browser. The browser doesn’t know if it should handle a copy command itself or pass it to Flash, resulting in unpredictable behavior. Some embedded media players also have their own scripted behaviors that may or may not be at odds with that of the browser. Also consider what kind of instruction the operating system may be passing along.
There are many, many desktop paradigms to tap into, far too many to be covered here. Instead I’m going to focus on some of the current crop of web paradigms harvested from the desktop. Standards such as double-click, right-click and keyboard shortcuts can be employed in RIAs, but gently… very gently.
3.2.1 Drag and drop
I tend to separate what I see are two kinds of drag and drop. There is one kind of drag and drop that moves things about the screen. I can move cells in Excel this way, move a rectangle in Illustrator, etc. This is very spatially direct in concept, and I think easy for most to understand.
As a designer, you can create affordances for this kind of drag and drop by rendering things both in look and spirit as objects (for more info on objects, see Think in objects, not links, Chapter 2). Objects tend to have hard borders and drop shadows, along with the occasional dot pattern (to indicate a draggable area) that designers have come to call “grippies”. The content of these should be discrete pieces that users can easily visualize as objects: an email, a pair of pants, a vcard, etc. For the most part, it easy to indoctrinate your users on this kind of drag and drop, as long as your visual and interaction language is clear and your use is consistent.
The other kind of drag and drop, I consider an initiation action. This is when you drag something to another place to change its state. One example of this is in Gliffy, where I can drag an item from the palette onto my canvas. Clickshirt employs the same kind to move graphic elements and text onto a shirt design. This kind of drag and drop may, on the surface, seem to employ the spatial metaphor, but in reality this is a greater conceptual leap that users generally are not familiar with and will not find consistently among sites.
Encouraging this kind of interaction requires you to be far more explicit, including instructional text, visual affordances, and some kind of “undo” action if possible. Once the action has been completed, it is also essential that the change in state be represented somehow. Sometimes the target area can reflect the change, for example a shopping cart (of which the contents are hidden) may give a little “bump” feedback and change the quantity display. Or the item being moved may reflect the change. In click-shirt the button that is dragged to the canvas has a different look than the object that actually appears on the canvas. I love these kinds of interactions, but enter them carefully as they are not readily understood by most (and may be candidates for the cool-but-fluffy category).
3.2.2 Double-click
Double-click is absolutely second nature in operating systems. Most of the time the concept represented by double-click in this environment is “open”, “launch”, or some variation: open this folder, launch that application, etc. In desktop applications, double-click is not quite as standardized, but again refers often to “opening”, or perhaps ‘enable editing”. For example, double-clicking a symbol in Flash will let me edit its contents, and double-clicking on a folder in my mail client allows me to rename that folder. On the web however, double-click is simply not done. Users are so accustomed to an HTML world free of double-clicking that the thought never enters their minds to double-click on an object.
Examining double-click standards on the desktop and in client applications shows that double-click functionality usually does not have affordances, meaning there is nothing about a look of an object that indicates that double-clicking will yield an interaction. In very few instances, text will be visible instructing the user of double-click functionality, but often the way to learn about double-click functionality is by either just trying it or reading about it in the help docs. On the desktop this is forgivable because double-click is part of the genus of desktop interaction standards. On the web this discoverability issue is cause for concern.
I would imagine that as desktop and online worlds eventually collide, double-clicking will become ubiquitous (most certainly for the open/launch/edit functions). But in the mean time, it is an option that must be weighed carefully. Ask yourself if you can afford to hide key pieces of functionality behind a double-click, hoping that users will catch the scent. Would it be a wise use of space to create affordances for double-clicking? Better advice is to avoid it altogether for now. Many alternatives, such as rollover buttons leading to action menus are available, and more obvious for users
.
3.2.3 Right-click
Much of what I said about double-click can be said about right-click. It is something with which users are quite familiar, but with caveats. In client-side applications, users expect a full range of functionality available with right-click menus, functionality which is also replicated on the top menus of the application (Although some RIAs are incorporating top menus found in desktop
applications, I don’t find this to be an appropriate navigational
scheme. Top menus utilize space reserved for them by the operating
system. There is no such standardization on browsers or web pages). Real estate in web applications is always tight, so redundant controls are rarely found.
Also, users who employ right-click in a browser expect browser controls there (copy link, save image, etc.) Although you can put your own controls in there, there are a few pitfalls you should consider:
• Creating “hit areas” for right-click is tricky and time consuming for both the designer and developer. All of the screen real estate needs to be divvied up and assigned controls. Areas which do not have your application’s right-click menu specified may either have browser’s default menu appear or you must suppress right-click altogether.
• Depending on the technology you’re using, browser defaults may not be suppressed. If you’re directing a non-savvy user to employ right-click, consider whether that user will be confused by seeing under-the-hood commands like “View Page Source”.
• If the right-click menu is not there, the browser may read the action as a single mouse click. Be sure if you include right-click that you have considered the “cost” of an inadvertent single click occurring in the same place.
• Right-click commands must be duplicated elsewhere in the application
• Mac users continue to be resistant to right-clicking, despite cajoling from the PC community
If you choose to incorporate right-click, but sure to create and affordance for it or provide some instructional help before it’s needed. Be sure that any items included in the menu are accessible elsewhere in the application. And be patient: right-click’s time will come.
3.2.4 Keyboard shortcuts
Keyboard shortcuts or hotkeys are a feel-good feature on the computer. Using them not only saves time, but also gives the user a sense of proficiency with the application. Although it may not be the best way to impress your friends, learning keyboard shortcuts puts you a little closer to the expert category of user.
More and more applications are employing keyboard shortcuts on the web, especially those that can tap into users’ experience with existing desktop applications. Google Docs is one such example, evoking familiar applications (Microsoft Word and Excel) on the web. Anyone with a passing knowledge of those applications will instantly catch the basics of using Google Docs, and keyboard shortcuts are a way to support intermediate users of those applications as well.
Gliffy is another fabulous example for this section, successfully creating a desktop-like application on the web. Gliffy, in case you’ve never used it, is an online application that is similar to Omnigraffle or Visio, tools used to make flow charts and wireframes among other things. Although Gliffy is not as robust as the offline applications, it has lots of the goodness you’d expect from a desktop application, plus thoroughly modern features like online collaboration and publishing. Drag and drop, double-click and keyboard shortcuts are all well-integrated and promote a desktop feeling. I was surprised to find I had slipped completely into “desktop mode” and inadvertently used a keyboard shortcut... successfully!
Keyboard shortcuts really add to the efficiency of an application and help the user find flow in their work, but unfortunately this again is where our antagonist, The Browser steps in. In the example of Gliffy, I used CTRL+C to copy an item and CTRL+V to paste. That worked, and increased my confidence in hotkeys within the application. Then I click CTRL+B to bold some selected text. Slap! Instead of bolding my text, this opens up my bookmarks in Firefox. “Flow” down the drain. I’ve had similar shocks to the system when I’ve attempted to save a file I’m working on in an online application (CTRL+S), forgetting that I’m in the browser and am instead confronted with a saving interface for the web page instead of my document.
In these instances, there’s really nothing you can do to override the browser, but I still wouldn’t suggest throwing the baby out with the bathwater. All in all, I love having these features there for advanced users. Just try to familiarize yourself with the commands most hoarded by the browser (CTRL +D and CTRL +S for example are never going to be available in a browser) and look for obvious ways for your users to access those commands.
3.2.5 That Desktop Feeling
As you incorporate all of the above, keep in mind that “desktop” is also a feeling, a spirit, a vibe that the user may sense without really being aware of it. There is always a base-level of uncertainty present for users on the web, and I would be remiss if I didn’t point out that RIAs exacerbate that uncertainty to a degree. Steve Krug in his book Don’t Make Me Think refers to question marks floating above people’s heads when things are not clear. I see some of these question marks relating to the online experience at a base level. Am I connected? Is the site up? If I submit this form and it doesn’t go through, will I have to fill it out again? Desktop applications have their difficulties for sure, but for the most part allow you to attain a low level of zen knowing that at the very least things are stable and “on”.
Creating a desktop feeling online for your users means doing your level best to assuage all of those background fears. Minimize surprises for your users. Create a state of flow. Provide feedback on any action, and provide actionable information in the event of failures. Make all actions as low-cost as possible and give your users a back door to escape when they mess up. You can’t make sure their internet connection is always up, but you can design for the cases when it isn’t, creating a more stable and comfortable environment for work or play.
These are a few of the desktop standards creeping into RIAs, but there are many more. Desktop applications are often built with different goals in mind than RIAs, but as connectivity and bandwidth become less and less of an issue, the boundaries between the two may be erased. It’s a good idea to be aware of the desktop world, and decide for yourself what other standards may be right for your project.
