Ah the things you learn from an emergency in-house BPM project deployment. If you think that all parts of a high tech company would be well versed and experienced in their own products, then you probably don’t actually work for a high tech company. So I was called in as an “expert” to expedite a very straightforward Human BPM project.

Thursday around 5pm: introduction to project. Friday morning: working prototype to prove the approach would work. Monday morning: the server up and running. Next few days: design and implement the application, including multiple reviews with the various stakeholders. I won’t bore you with all the details, but instead focus on one curious phenomenon that I call “Mouse Candy“.

Management asked development team to produce a “very attractive user interface” for the process participants to use. What does “very attractive user interface” mean? The application in question is one in which the typical user will use only once per year. That is an important design point: it needs to be entirely obvious how to use it, because training for one use simply is not worth while in advance, and anything they learn this time will most likely be forgotten before next year.

I favor simplicity when it comes to this kind of application. The more it looks like a single page of paper the better. A single “flat” form that displays all the various pieces of information with a single scroll bar on the right. The user can scroll up and down, see all the options, assess the situation, and complete the task. Then they are done for the year.

The developers felt this was too simplistic. They wanted a really “good” user interface (a.k.a. flashy) so to them the choice was clear: use “Flash” or “Flex” because they had been impressed by such nice programs written in those technologies. They wanted to impress the big boss upstairs with the great UI they could produce. I have nothing against Flash and Flex. Both good technologies which can make excellent user interfaces, but are not necessarily good for quick applications, and they can be difficult to debug. The real problem was that a workflow application has a couple of different display formats, but those formats are seen by different people playing different roles. There is no reason to bundle all of these displays into a single program. Developers often get mixed up between the concept of a process moving forward to another person, and the display “switching” to a new mode of display. The developer flips between the modes of display, but this never happens for users who only gets to see one of the display modes. Those modes are controlled by the server & the state of the process, not the user.

I tend to favor relatively low-tech solutions, and convinced them that a simple HTML based page (where the server substitutes data values on the page) would be the most effective. Being simple HTML does not mean it has to look bad. Use of good style sheets and graphics make a clean look which is easy to use and attractive. Cool technology does not necessarily equal cool look and feel.

Using “appropriate technology” means to keep it as simple as possible until there is a clear reason for something more complex. My initial implementation of the required screen did not have any graphic art treatment, and needed it badly. I expected the addition of a graphical header, footer, and color/font use to make the appearance pleasing. I got this from development team, but I got a couple of surprises as well.

First surprising change was to embed the worklist into a scrolling subpane on the page. This means that as the worklist gets longer and exceeds the size of this subpane, the additional lines are hidden, and a scroll bar appears on the right of that area. One can scroll the entire page (including the subpane) up and down, and the contents of the subpane as well. To be honest, I have never understood the desire to put a scrolling box within a scrolling page. This design involves twice as many controls to click on. There are more ways to manipulate the display, so I call these extra controls “Mouse Candy” — cool things to click on that manipulate the display but don’t necessarily provide any additional value. It is not “Eye Candy” because it doesn’t make the page visually more attractive, it just makes the page more manipulatable: it has more controls to click on and alter the display.

I would say this scrolling subpanel is not needed. For example, imagine that the scrolling subpane did not exist, and the entire page grew in length to include all the workitems. This page would grow to be longer than my screen, but using the main browser scroll bar I could scroll any part of it into view, so there is no real problem with the page getting longer. I prefer this because once the header graphics is scrolled up there is more area devoted to the workitems — the actual information that is the purpose of this display.

I understand that the graphic artist is quite proud of his header and footer artwork, and so may feel justified in providing a display that makes it impossible to remove this art from the screen. This relegates the worklist to a considerably smaller display area. Sometimes we need to realize that a good user interface is not just to display art, but in fact to make it easy to get the job done. Limiting the information display to a smaller scrolling window does not actually help the user deal with large amounts of information.

The second surprise was similar: there were two main display modes the user could choose from: a list of workitems that needed their attention, and a list of running processes they were responsible for including who currently “had the ball” on those processes. Again, my favored design would be simply to make two web pages, one for each, and provide navigation button between them. Those buttons can look like “tabs” so that the user has a clue that they are two options to choose from. This would be too easy for these developers. They insisted on making a third page, which was a container, which had two tabs. When one of the tabs was pressed, the interior page was fetched and displayed within the smaller scrolling area. This introduced interesting new problems. For example, it was possible to have the containing page on your screen until your login session had timed out, and then hitting the tab caused the login prompt to appear in the small scrolling area. “Oops,” the developer said, “I didn’t think about that happening.” Making a design more complex than necessary means that there is greater possibility for “things you didn’t think about”. I prefer to play it safe, keep the design as simple as possible, and avoid such problem. The attraction for Mouse Candy in the form of tabs that actually fetched and displayed another page was too strong.

The third surprise came from the users. This particular process involves a set of repeating items. A typical person will need four or five items, so we designed the process with room for ten which was agreed to be more than any forseeable extreme case. The lead developer suggested that the form should contain one item, and then a button you press to get another item. I felt this was unnecessary complexity. A simpler approach is a form that had all ten slots exposed all the time. If the user needs 4, they type in four of them, leaving the other 6 blank. No need for the button, no need for script, no questions from the users about how to manipulate the list, no need to answer questions on how many slots they can have, and not need to implement logic to make sure that the number is in the acceptable range. See, there is method in my laziness.

The first argument put forward is that users will find it “confusing” if there are ten slots for information and they only have to fill in 4 of them. Confusing? Do these same people find paper forms confusing in the same way? Everyone knows that a paper form contains a set of spots to fill in, and you fill in the ones that apply to you. How does it become confusing when the same thing is presented on a screen? So I convinced the development team to go with the simpler design. We did the initial demo to the CIO and he said “It would be better if the screen showed only one slot, and then there was a button to add additional slots.” I gave him the same argument, but then the EVP of the department arrived, looked at the screen and said: “Can we have a button that adds items as you need them?” The customer had spoken.

The developer was happy to add a button that unhid sections of the HTML page as you clicked the button and we had our most important piece of Mouse Candy. In the first major review of the application, with a dozen important users on line, we discovered a few critical flaws. The first time you accessed the form, you click once to get the second item, and again to get a third. Say that at that point you saved the page and returned later. You would see the three items, but when you clicked the button nothing happened. Click a second time, again nothing. Finally, on the third click a fourth item appears. “Oops, forgot to initialize the click counter to the number of exposed panels.” Then the demonstrator accidentally clicked the button one too many times. It was at this point that we all noticed that there was no button for removing items. Nobody had ever asked for it. I believe nobody had thought past the idea of “click to get another”. Where should the remove button be? Does the remove button delete the data, or just hide it? Should it warn you if the item had data in it? What if I want to remove an item out of the middle? Can I move items around? Once again, the increase in complexity had opened the possibility to many more modes of error that nobody had anticipated. The idea of being able to click a button and make something appears is somehow very “appealing” but there is no clear evidence that this makes the application easier to use in any way.

After a largish discussion on these topics, the developers played the schedule card: “if we have to implement all this, we will never make the deadline.” How about we just make a form that exposes all ten, and people use the slots they need? People do not give up their Mouse Candy easily, but the threat of delay of an already late project held sway, and the form ended up with all ten slots exposed all the time.

It is worth noting that no user ever expressed any confusion over this.

In summary, there is a strong desire among programmers (and users) to make displays that can be manipulated by the mouse. Some of these manipulations (a.k.a. Mouse Candy) add no substantial benefit. Like the red button under the desk that the evil Blofield uses in a James Bond film to expose all the super-secret display screens: they are kind of cool, but pointless. I am not saying that Mouse Candy is entirely useless: sometimes users like the Mouse Candy, and users that like programs can turn into good customers. Developers are sometimes motivated to add extra controls in an attempt to make a “good user interface” but for a user interface “less is more” is the rule. My recommendation is to avoid Mouse Candy by eliminating unnecesary controls whenever possible. Make everything visible if possible without needing to click on anything. Extra controls add extra risk for modes of failure, and these delay projects. Make the display as much like a long sheet of paper, fixed width, fixed layout, and allow the user to scroll to the part they need. This is particularly important for these kinds of internal workflow projects, which have the need to be implemented quickly and cheaply. Such a simple display can still be clean, attractive, most importantly very easy for the user to understand and use without trouble.