Make the simple things simple and hard things
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
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):
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.
listing some assemblies can sometime be a little trickier:
of a same NDepend project can be located in different folders
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.
.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
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.
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.