{This is the second user experience related post from my “personal” blog at strawberryjamm.blogspot.com}
Originally Posted: Monday, April 19, 2004
In my current position as a Microsoft UX PM in the Windows Security Core I am responsible for the administrative user experience of a V1 product being developed to support web service federated authentication. This is a wonderful opportunity, and one I am grateful to my new group for. All too often UX professionals focus on the end user experience, concentrating on the usability of client tools and leaving the men and women who are responsible for installing, monitoring and maintaining the servers the end users interact with - otherwise known as "IT Pros" - stuck in a dismal world with little more than an esoteric CLI (Command Line Interface) and an application-centric GUI (Graphical User Interface) shell.
Some IT Pros would sit up at this point and shoot back at me with the comment that they actually prefer using the command line for their work. One claim I've heard is that trying to use a GUI for daily IT tasks is too slow and often much more complex than just opening a command window and banging off a few, usually well known, command line parameters. Another comment is that they prefer to write scripts for frequent and/or repetitive tasks anyway.
I think a lot of this attitude is really alpha geek posturing:
<quote who="Alpha-Geek">
At the drop of a hat I can quote the syntax of any command line parameter for applications X, Y and Z. I can and you can't, therefore I must obviously be much cleverer and technologically savvy than you are.
</quote>
But the truth is even IT Pro's are human (trust me, they are. Even the ones that you'd swear are aliens from an alternate dimension), and they are also users. And any human user can benefit from the application of a user centred design approach on any tool that is developed to help them meet their goals. The key, of course, is to focus on the right kind of users - in this case, the technically savvy IT Pro, who wants to complete daily tasks quickly and be made instantly aware of problems in the system so that operations will continue to run smoothly.
One thing that I've been trying to teach my new team is that it really doesn't have to be an "Either/Or" choice between having a good GUI or a good CLI. Instead, it should be an "And/Both" - that is, have a good GUI AND a good CLI. When both kinds of interface have been designed to meet the user's ability to achieve goals and tasks, then the user is truly free to choose the tool that best suits the current scenario.
If we want IT Pro users to actually use a GUI-based administration tool, it must be at least as straightforward for an expert to do common tasks with it as with CLI (preferably, it would be even more straightforward). Using the GUI-based tool should not impose a significantly greater amount of key strokes than using a CLI would.
On the other hand, a CLI should also be designed with ease of use in mind. Parameter names should be meaningful and sensible so they are easy to remember and reasonable defaults should be provided whenever possible so that the process of scripting a task is straightforward. Additionally, every single action that can be done in the GUI-based tool must also be possible through the CLI, and vice versa (I'd be rich if I had a dollar for every time I've encountered a tool with some operations that could only be done through the GUI and some operations that could only be done using the command line.)
Give administrative users the best of both worlds - GUI and CLI - and they might actually like installing and maintaining a server application.
What a great idea!
