My name is
Jack Moffett. I am an Interaction Designer with over ten years of experience. According to
Herb Simon, that makes me an expert, so I must have something worth sharing. I have started this venture as an exercise to spur critical thinking about my chosen profession. I hope that others may find it thought provoking as well.
DesignAday will present a brief thought about Design every weekday.
Beware of the extra step. If it is part of a procedure that the user carries out within a software application, chances are that it is an action that will be repeated many times over.
When creating diagrams, a common action is to center a connecting line with the object it connects to. In Freehand, this could be accomplished in three clicks: 1 each to select the objects to be aligned, and one to press the align button. The default behavior in Freehand dictates that if one object is narrower than the other and is within the bounds of the wider object, it will center to the current position of the wider object without the wider object moving. 99.9% of the time, this is the desired behavior.
In Illustrator, this is not the default behavior. Instead, both objects will move an equal amount of distance toward each other to center on the space between their previous positions. To achieve the aforementioned behavior, you must select an option to center on a key selected object from a menu. Then, if the wider object isn’t already selected as the “key”, you must click on the object that you want to be the key. This takes twice as many clicks to accomplish in Illustrator, and I’ll likely do it over a hundred times while creating a diagram.
I’d like to feature the work of one of my graduate students. I gave an assignment in which each student was to design a map of the design landscape depicting major disciplines, organizations, educational institutions, firms, luminaries, and methods. They didn’t necessarily have to include all of this information, nor were they limited to it. Forrest Conroy incorporated everything just mentioned, and then added conferences, related companies, and example products. He mapped everything over time, showing relationships between them. The resulting chart is a beautiful piece of work.
Forrest used three major categories: communications in yellow, which is equivalent to Graphic Design, interactions + activities in blue, which includes Interaction Design, Information Architecture, and Service Design, and products in red, which is basically Industrial Design. You can watch these intertwine as digital products like computers and mobile phones incorporate hardware and software design.
Lines track the careers of prominent designers along the horizontal axis of time, while vertical lines make connections between people, organizations, and methods.
Insets on the right-hand side list all NASAD approved design programs.
Efficient data entry is arguably the most difficult goal to achieve in a mobile UI. On-screen keyboards, while not as efficient as touch typing on a physical keyboard, can be useful for short amounts of text, such as filling out a form. Tablets have enough screen real estate to display full keyboards, and smaller devices can display specialized data entry pop-ups. Typically, the operating system installed on the device will provide a keyboard, which may be good enough in some instances, but custom designed keyboards that address the needs of specific user groups have the potential to be much more efficient.
- In a typical data entry form, there will be fields intended for specific types of data: dates, numeric values, time of day, locations, or “free” text entry. Rather than using a single, full-size keyboard to enter all of these, an efficient UI will provide data-specific pop-ups: a calendar pop-up for date selection, a pop-up specifically for entering the time of day, a numeric keypad, etc. These pop-ups can be smaller, obscuring less of the screen, and can make data entry quicker while also reducing errors.
- When data entry pop-ups open, they should try not to obscure the field in which the data is to be entered.
- Data entry pop-ups should be movable, so that if they do happen to obscure something that the user needs to see, they can be moved to another part of the screen.
- As data is entered, it should be displayed in the pop-up, as well as in the field it is being entered into.
- Buttons should be large enough to be very easily targeted by a stylus or finger. However, this should be balanced by the need to keep the pop-ups to as small a footprint as possible.
- Pop-up keyboards must include access to special characters needed by the users.
- Pop-ups should have a “clear” button. Keyboards should have a “backspace” button as well.
After my brief post last week about the litl, I was contacted by James Gardner, litl’s VP of marketing. He pointed me to a post on Pentagram’s site and to a video on YouTube. As I was hoping, they painted a picture of very thoughtful design and filled in a lot more detail. In fact, as it turns out, they had an all-star cast working on this thing. Lisa Strausfeld lead Pentagram’s team in the design of the GUI, and Pentagram was also responsible for the visual identity, designed by Abbott Miller. The logo, business cards, and packaging are all exquisite.
The UI has the polish one would expect from Apple. Animated transitions bring a natural flow to state changes. The dial that is used for serial navigation in “easel” mode is repeated on the remote. They designed several channels that deliver specific information from the internet, like the weather, as well as a number of “widgets” like a clock or a feed reader. Visual treatments clearly distinguish between widgets, channels, and standard webpages. Arrangement of these items is automated much like the rearranging of photographs in iPhoto. It hooks up to your hi-def television with an HDMI cable to play movies or show photos. And, if you have more than one in the house, they can be set up to share things with each other.
Also working on the project were Cooper, Fort Franklin, and Fuseproject, although I don’t know what their contributions were. Fuseproject was also behind the OLPC XO laptop, so I’m betting they worked on the industrial design.
The video is pretty awful—lot’s of “um-uh” and fumbling around, but the product shows off well. They should really put together a professional video demonstration of the UI. I think they have a lot to be proud of. This could be a very successful product, although I’m curious to see if they’ve hit a low-enough price point. At $699 or $1,398 for a two-pack, it seems a bit much for something without local storage.
A new netbook-type product has been released: the Litl. I find this one more interesting than the underpowered laptops we have seen thus far, however. It takes what I consider to be an Apple approach. The creators must have asked the question, “If we were to design a laptop that was strictly for web use only, what would it be?”
The Litl looks like a small laptop—it folds open revealing a screen in the top and a keyboard and trackpad on the bottom. However, the lid rotates around to an angle at which the device can stand like an easel. The hinge acts as a handle.
The biggest change is that they realized a typical desktop OS was unnecessary. Much as Apple did with the iPhone, they created a custom UI designed specifically for web use. It is truly a case of browser as operating system.
The one flaw, to my mind, is that it doesn’t have a touch-screen. Instead, they opted for a dial on the hinge that allows you to flip through selections. I haven’t yet seen a demonstration of the UI in action, but this is begging for touch input.
The ebook reader product space just got interesting with last week’s release of the Nook form Barnes & Noble. It is very close to the Kindle in size with the same E Ink display. A majority of the features found on the Kindle are mirrored on the Nook, including wireless connectivity for book purchases and subscription downloads. Where they differ significantly is in their user interfaces.
While they both place buttons for page turning on both sides of the screen, this is as far as the similarity goes. The bottom third of the Kindle’s face is given over to a physical keyboard—row upon row of tiny buttons. The Nook, on the other hand, sports a 3.5 inch color touchscreen. This screen is used for navigation, providing access to the various functions of the device, and browsing of your library in a coverflow-esque fashion (although not as fluid). It also provides the means by which you can highlight content, bookmark pages, and make annotations. This is what I was most curious about. How do they provide a touch UI in that small space that affords these complex interactions without direct manipulation, and presumably text entry. Unfortunately, they don’t demonstrate any of this in the screenshots or videos on the site. It’s almost as if they purposefully didn’t show it, perhaps to hide a kludgey interaction.
From what I’ve seen, the Nook seems more elegant than the Kindle, but I’ve never had the opportunity to try either one. And this is one instance in which having brick and mortar may provide an advantage. According to the website, you can try the Nook in the physical stores. I may have to pop in the next time I see a Barnes & Noble in my vicinity.
When dragging within a window, standard behavior dictates that when the cursor contacts the edge of the window, the page will scroll. This allows objects to be dragged to a location that isn’t currently in view, or a selection to be made that extends past the window’s edge. There are a couple of different methods for accelerating that scrolling. For example, when creating a selection with the marquee tool in Photoshop, the farther the cursor moves outside the boundaries of the window, the faster it will scroll in that direction. On the other hand, when dragging folders in OS windows, there is a narrow area inside the border of the window within which dragging will cause scrolling. The closer to the edge the object is dragged, the faster the scrolling will be.
The problem with the selection dragging is that a window will often be right against the edge of the desktop. If such is the case, it isn’t possible to move the cursor outside of the window, so the window scrolls very slowly. This can be painful if you are trying to select several paragraphs of text, or if you are at a high zoom level.
Clayton Miller has posted an intriguing concept demonstration for multi-touch interaction as applied to traditional desktop systems. Rather than turning our monitors into touch screens, he suggests adding a large trackpad capable of sensing all ten fingers. This gets around the major problems that he points out as the primary roadblocks to touch interactions at our desks: fatigue from non-ergonomic techniques and occlusion by our own hands.
Clayton’s video artfully explains the problems he is trying to solve, the rationale for his approach, and both the hardware and software that form the solution. As such, it is a much more effective presentation than those recently released by Microsoft.
I can certainly see this concept in use. The track pad on Apple’s Macbooks is moving in that direction. However, I’m of the belief that one of the greatest benefits of a touch interface is direct manipulation. Clayton’s solution is still just as indirect as the mouse—just with nine more cursors. We can learn to type and play the piano without seeing what our fingers are touching due to the static placement of the keys and the tactile feedback they give us. Clayton’s pad would offer neither of these, and I imagine it would take a lot of effort to become proficient in its use.
Finally, I have to wonder about its actual utility. He presents a good case for its usefulness in managing windows, but that’s not what I use a computer for. I don’t sit down at my Mac thinking, “I’m going to move some windows around.” I use my computer to pay bills, prepare to teach my class, specify UI designs, and write blog posts. How will 10/GUI help me do those things more efficiently? I’m not saying it can’t, but I’d like to see it applied to more important tasks. Managing desktop clutter is just a place to start.
There are three types of JavaScript dialogs: prompts, alerts, and confirms. A prompt displays a field to collect information from the user, while alerts and confirms can only display messages. An alert box has a single button labeled “OK”, while a confirm provides both “OK” and “Cancel”.
Developers tend to be rather fond of these boxes because they are so easy to implement. Unfortunately, they are not optimal methods by which to communicate with the user. Let’s take a simple confirmation dialog for example. We’ll say that the user has just pressed a button that will delete something. Assuming there is no undo feature, best practice is to display a modal confirmation dialog that asks the user if they are sure they want to delete it. Because the button labels are not customizable, the message must be written as a question that can be answered with “OK” and “Cancel”. So, you end up with a message like “You’re about to delete something. Are you sure?”
I typically specify custom alert dialogs that are implemented as divs. This gives me the freedom to state the message as I see fit. More importantly, it allows me to customize the button labels to be more specific to the action the user is completing. Let’s face it, we’re often deluged with dialogs, and we tend to quickly dismiss them without reading them word for word. I’m much less likely to make a mistake if the button is labeled “Delete”, rather than “OK”.
Finally, the dialogs can become much more useful than simply confirming an action. For example, if the item being deleted is a node in a hierarchy containing other items, I could specify a dialog that provides specific options.
The node Foo has the following children:
Fee
Fi
Fo
Fum
(Delete Node and Children) (Delete Node Only) (Cancel)
The ease of implementing a JavaScript dialog is no excuse for poor usability. The flexibility to provide tailored messages, button labels specific to the actions they perform, and additional actions makes the extra effort worth it.
The very first project I was assigned in Visual Interface Design during my first semester of graduate school at CMU in 1996 was to redesign the QuarkXpress print dialogs. There were several different dialogs that were accessed individually from the File menu. My solution combined them all in a single dialog where options were grouped based on whether they applied to the page, the printer, or were specific to offset printing. You could choose Print from the File menu and have access to all of the options, rather than having to change a few settings in one dialog, close it, and open another to specify something else.
It still aggravates me today every time I use an application that doesn’t allow me to change the page orientation in the Print dialog. Sometimes a button will be provided that will open the Page Setup dialog where you can do this, but sometimes I still have to cancel out of the Print dialog and select Page Setup in the File menu. Take the Print dialog from the most recent version of Adobe Reader, for example.
It does have an option to “Auto-Rotate and Center”, which orientates the page based on the orientation of the document you are printing—and this is typically what I want to do—but it doesn’t allow me to specify the page orientation otherwise. To do that, it’s another trip to the File menu.
You would think that in 13 years this little problem could be solved.
