Make the simple things simple and hard things possible

IMHO, this tenet applies perfectly in how UI should be designed. Typically, the most direct way to use a UI control should result in the most awaited feature from a user perspective (make the simple things simple). Then, some extra/hidden UI control facilities can be added to the control to support more in-depth scenario (make hard things possible).

Case 1: NDepend Start Page

We tried to apply this tenet in the NDepend UI. For example, on the start page there is a DataGridView that lists the most recent NDepend projects. We estimated that left-clicking a project should result in loading the results of the most recent analysis done on this project. This is clearly what the user wants most of the time. But sometime the user might wish to do something else from a project: maybe she just wants to open the project in order to view or tweak it, without being bothered with any analysis result. Maybe she wants to open the result of an analysis done 3 months ago. This is why the DataGridView lets the user right click a project and access to such options:

Case 2: NDepend Project Properties Page: Code to Analyze Panel

This tenet also drove the way the Project Properties window has been designed. Basically, a NDepend project is just a list of .NET assemblies to analyze. Even thought an NDepend project can be made of dozens of options the Project Properties window must reflect this simplicity at first glance. This is why the first things a user see when editing a project is a DataGridView that can be populated with a list of assemblies (eventually drag and dropped from Windows Explorer):

Besides assemblies of the application that must be analyzed, there is a list of tiers assemblies, i.e assemblies referenced by the application assemblies, such as mscorlib for example. The list of tier assemblies is automatically populated and real-time refreshed from the list of application assemblies. Thus, we hope that the user doesn’t perceive this second list as a burden but more as interesting extra information.

Actually listing some assemblies can sometime be a little trickier:

• Assemblies of a same NDepend project can be located in different folders

• When working as a team, bin folders are usually rooted differently on the various developers machines and build server machines. But only one NDepend project file must be shared by all machines.

• Microsoft .NET Framework assemblies, such as mscorlib or System.Core, can be located in some tricky folders such as C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727 or C:\Program Files\Reference Assemblies\Microsoft\Framework\v3.5. And these folders can slightly vary depending on your installation drive or if you are on a 32 or 64 bits machine.

To handle this extra-complexity, there is a single button View Folders. When clicking this button, a folder panel expands. This folder panel let’s tweaks the list of folders that contains application and tiers assemblies.

• There is an option Relative Path Mode that makes all folder referenced by the NDepend project relative to the folder where the NDepend project file is located.

• The .NET Framework assemblies tricky folders are automatically referenced. These folders are not impacted by the Relative Path Mode option because they depend on the .NET framework installation on the current machine and not on the development working environment.

The great consequence is that users that don’t need to cope with folders will never see this panel since the list of folders is automatically filled up when application assemblies get browsed.

The problem with this approach is that it is a bit scary: Do users that wish to tweak folders will figured out that there is a whole deep folders panel? Or will she skip the View Folders button and think that the tool is not well designed for real-world use?

So far, we got only one user’s mail about how to handle folders so it seems that it is worth trusting users when it comes to dig a bit into the UI to achieve what they want to do.