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-cenric 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 repetative 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 more clever and technologically savy 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 savy 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 acheive 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 straightfoward). 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 meaninful and sensible so they are easy to remember and reasonable defaults should be provided whenever possible so that the proces 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 UI 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!
1 comment:
I'm glad to know that somebody is actually thinking of making admin user interfaces usable! :)
One vector of administrative interfaces which is commonly overlooked is the configuration file. GUIs are good for some administration (particulary when first learning a product), CLIs are good once you have a grasp of what is going on or need to quickly or automatically make a change. The ability to open/edit/deploy/redeploy a configuration change through a plain text (or XML) file is where the most power lies. In days past, a lot of Microsoft server products only offered a GUI for administration, which required you to be a "button cowboy" and click you way around to making changes - sometimes moving changes from one stack to another (say staging to production) required a severe amount of overhead in making sure that you clicked all the same buttons on production as you had in staging. One client I work with has a binder full of screenshots, taken in the correct order, in the event that one of the machine stacks needs to be rebuilt. Config files might not alleviate all of that pain, but it would significantly reduce it by being easily deployed to multiple machines.
Post a Comment