Chris Doig's Blog

Thoughts on User interfaces - Pages vs Dialogs

I am one of those people who like to keep their financial affairs in order. To help with this task I have used MS Money since about 1993. A while ago problem with Money made me decide to change to Quicken. It was then that I realized the difference between the two classes of interface you find in the software world:  broadly speaking they are dialog boxes versus pages.

Dialog boxes developed out of the character mode world where screen real estate was very limited. These days typical Windows applications have dialog boxes scattered throughout. A dialog box works by popping up over the underlying screen, and displaying relevant, context sensitive information when it is needed. Although dialog boxes work very well in some situations, they tend to be over used. Quicken (2006 version) is a very good example of this. When working with Quicken it is very easy to get into a situation where so many dialog boxes are open that you have no idea of where you are. And at that point the user interface has failed. What also shows up in Quicken is that dialog boxes do not scale. They work well when deployed on a small scale, but quickly break down when they are over used.

Although MS Money uses dialog boxes in many places, they also use pages to control many options.  Because pages are larger, you can get more on them without cramming everything in (just like printed page layout, white space is important to help make sense of everything presented.) But there is something else going on here: it turns out that the paged interface is just easier for people to use. Our brains seem to be wired that way. As evidence I offer the way the internet has caught on. I think a large part of the success of the internet is that people relate to pages much better that they do to dialog boxes.

I spent about three months reviewing Quicken before taking the plunge and changing over. Doing my homework, reading the reviews, deciding that this was the right thing to do, etc. But very soon after converting my files and using it with real data, it became apparent that a huge mistake had been made. Now I have been working with software for over 10 years, so learning a new package should not be that hard. Yet even allowing for the fact that Quicken was a new package, I was taking 2 to 3 times longer to get the same tasks done compared to MS Money. And that was after using Quicken for two months. I can only attribute the difference to the user interface. And a large part of that is the difference between over using dialog boxes and the page interface.

About six months later when Microsoft release their new version of Money that could import Quicken files I swapped back. And, finally, I can balance my loan accounts again (you simply can't do that in Quicken.). And I get my accounts done in less than half the time it too with Quicken.

(Note: In this article I am not reviewing Quicken. I am simply comparing the Quicken user interface to the one in MS Money to illustrate the difference between the two approaches. If you have been using Quicken for years, it obviously works for you.)

Revision History

A number of people have asked for a copy of the Revision History template, so here it is. You can use it in the following manner: Either manually copy the appropriate design elements into the target application, or set up Teamstudio Design Manager to do it.. Typically this takes 2 or 3 minutes, and about 200 hours of development have been added to the application - that makes developers look really good!

Revision History was created in about 1997 or so, and has been continuously updated and improved since then. This database is both a fully working design, and can be used as a template. You can play with it to get an idea of how it works. Probably the most important feature is that is can provide a watertight audit trail to changes in a database. Old versions of documents can be in the current or an archive database. And users can view these old versions, or roll back to them if required.

While there is some reasonable documentation, I make no apology for the fact that this is a development  application - it is not a finished product. However you may find it useful as a source of ideas, or you can even use it as is, by incorporating it into your design.

LibraryRevHistory_R5_DEV.zip

More on Corporate Directories

I have worked at a number of companies, and each time this entailed meeting lots of new people. I don't know about you, but sometime I can only remember the first or last name, and sometimes only the nickname e.g. Bob in the corner office. When I need to send an email or look up a phone number, the corporate directories often aren't very helpful.

There is a simple enhancement that can be added to corporate directories to significantly improve their usability, and that is listing people more than once, once by each name. Usually when this is proposed, I get a horrified look, but once people see it and use it, they really appreciate it.

As an example consider Robert Smith, also known as Bob. List him 3 times in the corporate directory, and the people can find him by first, last or nickname. In a small company this makes little difference, but once you are over a 1000 people, it really does make a difference. Suddenly the corporate directory becomes significantly more useful.

Note how Bob Smith appears 3 times, once for each name. That makes it really easy to find him.

This is but one example of a small improvement that adds to the "Continuous Improvement" bottom line.

Drill Down Views in Notes

In The View Nov/Dec 2001 (page15) Damien Katz wrote a short article on a technique for "faking" response documents. (Also see his very interesting articles on the R6 formula engine rewrite and the Formula Language's dirty secret.) This "fake response docs" technique can be used to create drill down lists in Notes. A very useful example of this is a hierarchical corporate directory, showing who reports to whom, and how many direct and indirect reports people have. Use this to drill down from the CEO to the janitor, and see the complete chain of command. Typically this information is updated automatically from the HR system every day, and is a LOT easier to manage and use that the endless out of date Visio diagrams that float around organizations. Recently I posted a screen shot of this type of directory, and Scott Giesbrecht asked me to describe how to do it - so here are the details.

Response documents have $Ref field which contains the UNID of the parent document. If a view's properties are set to "Show response documents in a hierarchy", and $Ref field exists on document "A" containing the UNID of parent document "B", then the view index makes document "A" a response of document "B".

Damien's technique is to use a FakeRef field with the UNID of the intended parent, and then use the view selection formula to set (i.e. fake) $Ref on all documents to the value in the FakeRef field - just for that view. This causes the view to be built with those documents as responses to their parents.

In the sample code posted at the  end of this article, each person document has a FakeRef field called "ManagerUNID" that contains the UNID of their manager. (See Notes 1 & 2 below) The only way I have got this to work is to use the LotusScript "MakeResponse" method of the document - see the code fragment below, which is part of a loop processing all documents. The parent doc is "docManager", and the person document is "doc'. This code runs in an agent that updates the values of the ManagerUNID fields after updated data has been manually entered or imported from the HR system. (See Note 3 below)

Call doc.MakeResponse ( docManager )      'Makes the person doc a response to the manager doc.
Set item = doc.GetFirstItem ( "$Ref" )
Call doc.ReplaceItemValue ( "ManagerUNID", item )      'Creates the FakeRef field
Call doc.RemoveItem ( "$Ref" )      'Removes $Ref so the person doc is no longer a response.
Call doc.Save ( True, True )

Now that evey document has it's parent defined, we are ready to create the drill down view (the Org Chart view in the sample code). To do this we fool the view into thinking that a document has a $Ref field by adding a line to the view's selection formula:

DEFAULT $Ref := ManagerUNID ;         'ManagerUNID is the FakeRef field in the sample code

And, in Damien's words, "This is all it takes". Remember that Notes limits you to 32 levels of response documents, but this is more than adequate for corporate hierarchies.

When you open the sample code, go to People by... Org Chart. Then expand all. You can experiment by adding people to the hierarchy. After adding people run the "Manual Org Chart refresh" agent (Under the View button).
Click link to download file
CorporateDirectory.zip


Note 1
For a document to appear as a response in a view, the FakeRef field (ManagerUNID in this example) MUST contain the hex / binary value of the UNID, and NOT the ASCII version (i.e. @text(@documentUnid) will not work.). The original article in The View was a little unclear here. If a field contains the hex / binary value of a UNID and that field shows on a form, then the contents of the field will appears as a doclink to the parent document. To see this in action, put the $Ref field on a response document form. Then open any response document created with that form in the Notes client. Instead of the UNID of the parent doc showing, you see a doclink to that parent document.

Note 2
You are not limited to just one FakeRef field - you can have several. Each view that uses fake response documents would select the appropriate FakeRef field. This is how one document can have different parents in different views.

Note 3
Heaven is when the HR system exports it's data with canonical names. This makes it trivial to update people's managers, and add the ManagerUNID field. Unfortunately this seldom seems to be the case, so you must find some way of linking manager names from the HR system to the canonical names used by Notes. The next best is when you have unique employee ID numbers, but some HR departments treat these like social security numbers and do their best to hide them. If that happens, you need a routine that somehow uniquely identifies people so that the update agent can put the correct name in the manager field. For more thoughts on the problems of names, see When is a name not a name?.

IBM web site not an example of "easy to use"

I often need to use the IBM web site to find information, but can be a hopeless task. Very little is where you expect to find it. Just try and find the Notes Domino fix list from the ibm.com and you will see what I mean. And the search does not respect context. For example, if I am in the Lotus part of the web site and search for a term, I am not interested in Tivoli, Websphere etc.... I just want items relating to Lotus. Yet 80-% of the items returned have nothing to do with Lotus. It is easier to use Google to search IBM than it is to use the native IBM searching!

Maybe this has something to do with this article on TechWeb..."IBM has agreed to support within its OmniFind corporate search engine Google Inc.'s desktop-search software, an indication of how the latter company is warming up to business software makers that can open the door to large corporations."

A new way of driving application development

It hit me right between the eyes - one of those "Duh!" moments. So obvious when you read it, but it took such inspiration to write in the first place.

I am referring to the blog entry "Listening to users considered harmful?" In this article Kathy Sierra makes the point that while users can drive incremental changes to a software application, they are not capable of driving breakthrough improvements. This is because they have no way of asking for something they have never conceived of. To quote Kathy: "This is about giving them what they really DO want... but simply don't realize it because they had no way to imagine it." Go and read the article. If you are in software development this will open your eyes...