UI Design - What Not To Do

I would never claim to be a good UI designer.  What I know of design is from personal use.  One principle that applies to both code and UI design is that consistency is king.  I often look to widely used commercial software as models for UI design.

Of course, one of the software packages I use most often is the Delphi IDE.  That’s why it’s particularly frustrating to see that when attempting to add a new unit test case to a project right clicking the project and choosing Add New -> Other… invokes the New Items Delphi dialog as shown below:

New Items Dialog invoked from Project Manager local Menu

New Items Dialog invoked from Project Manager local Menu

If I choose File -> New -> Other from the main menu I get the following New Items dialog, that does include the Unit Test folder in the tree, and provide a Test Case item.

New Items Dialog invoked from IDE Main Menu

New Items Dialog invoked from IDE Main Menu

Now considering the project I have selected in the project manager is a Unit Test project, one might think the Unit Test item should appear on the Add New local menu flyout.

Add New Flyout Menu

Add New Flyout Menu

I thought I could work around the initial limitations of the menu by Customizing it, but after adding the Test Case item using the Customize Dialog, it still doesn’t appear on the local menu.  It only appears on the main menu.

Customize New Menu Dialog

Customize New Menu Dialog

You might also notice the label “Default Application in Startup”.  To me this label is very confusing, so I invoked the help which indicates:

“If you want to set a default application type, drag the item that represents the application type from the center pane and drop it on this button. To remove the default application, click the button.”

Not only is the help incomplete, it is also inconsistent.  Within a single sentence it conveys conflicting semantics.  An application type is not the same as a default application.  It doesn’t mention anything to do with “Startup” as the label indicates.  In short, it does not sufficiently describe the functionality to which this option pertains.

I decided to experiment, so I changed the default application to a console application, closed all projects, closed the IDE, and re-launched it.  A new console application project was in fact created.  How this pertains to Menu customization is beyond me.  Personally, I don’t care if the IDE creates a new project because most of the time I am loading an existing project to work on it, or I explicitly create one.

In short, just as a poet carefully chooses his words, developers and documentation writers also have to do likewise.  In the case of documentation, it also makes more sense to be overly explicit to ensure the reader cannot misinterpret your prose.  Consistent UIs with logical grouping of functionality, meaningful hints and labels and discover-ability are also important in an age where users don’t read manuals, expecting software to be intuitive.  Of course it helps to dog food your own product, as if you were an actual end user…

3 Responses to “UI Design - What Not To Do”

  1. Joseph Says:

    >Of course it helps to dog food your own product, as if you were a an actual end user…

    Oh, this one change would make a world of difference to the quality of Delphi! I don’t doubt (especially for the offshored workers) that they develop Delphi for 8 hours a day and then go home, never actually using the end product themselves. Working on the VCL or IDE is a lot different than using the VCL or IDE, just as building a car is quite different from driving one.

    This is why open source is so successful in development tools and commercial development tools are an anachronism (unless you’re a monopoly). Open source developers are building the tools they want/need to use themselves. They’re not just creating them; they spent the rest of their time developing with them. They’re also targeted at other developers, not at selling to managers.

    An American retail chain called Bed Bath and Beyond has a very interesting policy put in place by its founder. EVERY employee begins their career training in a store. Lawyer, IT, accountant? No matter - you first report to a store and spend some time there learning how all the areas of the store operate, stocking shelves, cash registers, etc. The thinking was that the lifeblood of the company was the store - no matter anything else, if the stores weren’t working, there would be no income. It also serves to teach value and appreciation for customers - there’s also a set of policies regarding customers such as “Pass the buck” - if you don’t know, elevate a customer’s question up the chain of command, “Never say no”, etc. When a non-store employee eventually reports to corporate HQ, they are now told who their “customers” really are. For instance, when I worked there in logistics, the store was my customer and was to be treated as such; for IT people the end users were their customers, etc.

    I’ve thought for a long time that new EMBT Delphi employees should be given a copy of Delphi, placed in a room with no internet access to Stack Overflow (or maybe no net access at all) and then given a project assignment to perform - create a reporting tool, a simple accounting program, etc. Let them actually experience USING the product, and then they’d have an appreciation for the needs of the customer, their frustrations, the usefulness of the included libraries, etc.

    I think you hit it on the head with the last sentence of this article. If those who develop Delphi spent some time needing to develop WITH Delphi, we might see a huge amount of polish applied to the product.

  2. Jeroen Wiert Pluimers Says:

    Did you QC this? If so, let me know the ID and I will vote for it.

  3. Larry Hengen Says:

    I just put in a quick QC report (I am not a big believer in QC since it appears QC items are reviewed on a voluntary basis, and go unaddressed for numerous releases). It is 121485.

Leave a Reply