Are you designing a rule builder? It seems like I’m asked to design one or two of these every year. In this article, I walk through pretty much everything you need to know to pull this design together.
This topic comes up a lot in conversations with our clients and other designers: users don’t like it when you change their software. What do we do about it? The very talented Jared Spool likes to tell a story about how much users hate change. He asks us to begin by imagining our kitchen and our morning routine.
The closest analogy I’ve been able to come up with is “A builder is to an architect”. But when I use this analogy I get some push back. “Wait a minute,” they say, “a builder can create a house without an architect.” It’s true – many builders do build houses without architects.
I downloaded the new versions of iWork on my iPhone and iPad and went through the Getting Started guides. On the whole I’m very impressed with Apple’s UI design work on these applications and with how much I can do on a computer that fits in my pocket.
On February 23, 2012 I taught a UIE Virtual Seminar on Dashboard design, but I wanted to do a little writing about Dashboards because I just didn’t have time to cover everything I’d wanted to.
You know, I’ve just about had it with the poor design of all the address books out there. I use Apple’s built in Address Book at the moment, mostly because of iPhone integration and all that whatnot, but over the years I’ve used a LOT of different address management applications and they all operate with a very basic assumption that is just wrong.
I spend a lot of time working on designs for large, complex applications. These are typically B2B applications, SaaS applications, intranet applications – not necessarily public, consumer-type applications but rather enterprise applications.
Over the last couple of years I’ve worked with many clients that had navigation systems that were out of control: tabs that had outgrown the screen, left side trees that scrolled down for days, navigation systems that eat pixels in the application… All had big problems with controlling navigation and making sense of it.
I was in a meeting a few weeks ago where there was an argument over whether to use “New” or “Add” as a label for a command. The truth is, they’re different and not interchangeable at all. The simplest way I can explain this is by showing this example:
I started out designing applications for the desktop on the Windows, Mac, and Unix (Motif) platforms. Now my design work is mixed between web based applications and desktop applications. Most of these are web-based enterprise-class applications.
Today I want to talk about using Context Menus in web application design. What is a context menu? A context menu is a menu that contains commands specific to the object that the cursor (* see note about touch screens, below) is currently pointing at – the “target object”.
Many of you may be familiar with the use of ellipses in menus, but do you know the rules for when to use them?
I was working with a client earlier this year and I asked their top QA person to pull me a list of any open UI bugs in their bug tracking system. He did, and I got a list of a few dozen bugs. This is hardly the first time I’ve looked at one of these lists – I’ve made contributions to them many times. But I was really struck by a something as I read the bug list.
I’ve been thinking about books and eBooks. And I’ve been thinking that “eBooks” just isn’t going to cut it as a name for what’s coming. Let me give you an example of what I mean.
I often see trees that have a single root item at Level 1. This root item is one parent from which the entire tree is descended (in the example below this is “Acme-MSU”). Because it’s there, all the other items in the tree are indented an extra 20 pixels. In any tree control the horizontal real estate is at a premium – tossing 30 pixels away for nothing is pointless.
The tree control is a popular choice for navigation in large, complex, web applications, but it’s one that I usually avoid. I avoid it because I think trees have a number of serious usability problems, which I’ll share here today.
Today, I want to showcase a navigation widget that I’ve been seeing quite a bit lately: the Mini Menu Bar, or (for fun) the Minibar. The first time I really noticed the Minibar was in the family of products produced by 37Signals: Basecamp, Highrise, etc.
On the desktop double click always meant edit. If you double click on a file, you open the application that edits that file. If you double click on a button in Dreamweaver, you get the properties for that button. A single click on the desktop was always selection. You can select one or more things and do stuff to them (select 3 photos in iPhoto and choose Export, for example).
In the past when I’ve spoken about Web Applications and Navigation systems in particular, I have mentioned hub & spoke diagramming and even shown a few simple hub & spoke diagrams that I’ve created. I’ve started calling these diagrams Application Maps, rather than Hub & Spoke diagram. Today I wanted to show a video of an actual application map as I build it.
Design is an act of creation. All designers suffer from “Designer’s Block” from time to time. Everyone who has designed has experienced this block, usually followed some time later by the “ah hah!” moment in the shower or during a walk.
We work with a lot of clients that are struggling with their navigation systems. Usually these are large, complex applications that have grown over time (with little or no planning). Therefore, the navigation system is also large and complex. When we’re asked to fix these systems, one of the first things I try to identify is whether we’re dealing with a widget problem, a ic problem in the navigation system or (shudder) both.
It got me thinking about disruptive designs, and in particular the TiVo. We bought our first TiVo a little over 10 years ago. At the time, I thought it would be nice to have a VCR that would be easier to program. I liked the idea of being able to set up a program quickly and be sure that my show would actually record. I also thought the idea of being able to pause during a show (for a snack run or bathroom break) might come in handy.
I started my career as an interaction designer working on desktop applications. I designed for the Windows, Apple and Motif interfaces (and still do). Each of those platforms had a toolkit of interaction controls that we could use: buttons, text fields, radio buttons, check boxes, and of course menus. We had a menubar and also context menus (which appear on PCs when you click the right mouse button).
I spoke with Jared Spool earlier this month about Escaping Navigation Hell, which is the title of my upcoming talk at the UIE Web App Masters Tour. We talked about some of my crazy ideas for navigation systems.
We’ve been doing it for the last 30 years – clicking Save. Everyone is used to it – you work for a while, you press Save. You work some more, you press Save again. Things crash, you lose your work since your last Save.
I always wince when I hear people say things like “we’ll just make unfinished items yellow” or “we’ll make it red so everyone knows there’s an error”. Color can be a great way to convey information, but you cannot rely on color cues.
Last week I attended a UIE Virtual Seminar called Leveraging Search & Discovery Patterns for Great Online Experiences, with Peter Morville & Mark Burrell. During his talk, Peter mentioned that navigation on web sites has swung back and forth over time between Browse based navigation and Search based navigation.
I’ve run into a lot of pie charts that are tilted, so that they appear to be a thick disk, as viewed at an angle. I think this effect is used so that it will look cool, because I can’t imagine any other reason to use it.
A lot of applications that we are asked to redesign are using reporting, and one of the most beloved reporting graphs is the pie chart. Some of these pie charts suffer from a major No No: using too many wedges.
One of the things I love about my work is the opportunity to work on large, complicated software products. My favorites are ones that have been around for years – often more than a decade (a long time in this industry). These applications are usually very feature rich, mature products, but as they have aged and more features have been added they’ve become more complicated and difficult to use, especially for new users.
We use a lot of icons in our web application designs. In the past, we always hired an icon artist to create unique icons for our clients. A typical icon typically costs anywhere from $25-$100 to create, depending on its size and how many drafts it takes to come up with a final idea (the icon for “user” is probably a bit easier to produce than the one for “relay switch”).
Periodically, David and I will show you some Before & After examples of redesigns that we’ve done. This isn’t client work – just a chance to flex our skills and rework a design.
In order to be able to develop new interface designs, I need to make lots of wireframe sketches. I do many of these with a pencil on paper, but when I’m ready to bring them on to the computer, the main tool that I use is PowerPoint.
I’ve been collecting screen shots of web applications and web sites since 1994, when I was working at Netscape. I’ve got an iPhoto library of about 12,000 screen shots.