Since starting at Puppet Labs four months ago, many friends have asked me why. “Puppet is a systems tool, right? Isn’t it all command line? Where’s the user experience? Don’t you usually work on the web? Are you designing their website?”
To the contrary, I’m happy to say that for the first time since the Internet was invented I’m working at a company whose web site doesn’t need much of my attention. We have fantastic people working on it already, and I think it’s quite good.
There’s a lot of user experience in Puppet if you look. That will be an easier argument to make if we have a good idea of what user experience is.
What is User Experience?
Back in the day, much of this was called Human Computer Interaction, or HCI. It is the theory and practice of how people interact with computers. Computers at the time were slow-moving and without much rich user interaction, and this started as academic work—a meeting point between psychology and computer science.
As we got faster at building software and interaction became richer, we began to apply HCI principles to one-off projects. “How can this corporate or consulting project succeed?” was the question. Usability became well-established as a discipline and method.
With the Internet, richer interaction is possible not just with a product but with a company. Perception of the company matters, including installing and using the product, filing bugs and receiving responses, updating software, finding and reading documentation, and interacting with the community. The path of the customer through this process is user experience.
So wait, is this just tarted-up brand psychology? No, because the heart of user experience is a deep interaction with software, and the user’s need to get something done.
The desire for, and techniques of, measuring much of this come from usability. How many people succeeded or failed? How many were frustrated, how many had positive or negative impressions of the product?
These metrics are all useful, but mine is simpler: Joy. My metric is joy.
I want people to look forward to using Puppet. I want people to enjoy using Puppet not because it has no bugs or prevents mistakes, but because it has a personality. A good tool is something you can relate to because you understand how and why it works. Enabling that emotional connection and building a framework around it is what I call user experience.
Is that ambitious? Absolutely, but good goals always should be.
What is User Experience at Puppet?
Certainly a lot of the work in Puppet is done by one computer talking to another, but all of that work is initiated and mediated by a human being. Without a human operator Puppet has nothing to do, and every interaction with each component of Puppet is user experience.
The Command Line
My first answer to my friends about working at Puppet is that for 25 years I’ve been a victim of bad command line tools and now it’s payback time. It’s been a great pleasure over the last few months to help create a first-class command line experience.
The command line is different from the GUI in fundamental ways. There’s very little context, no affordances, and interaction mostly relies on memory and low-density text display. Interaction principles are the same, though, and a successful user experience has the same properties regardless of the interface used to accomplish it.
For instance, we should be careful and deliberate about presenting help on the command line. We can’t use the GUI trick of contextual help; most help must be asked for explicitly. How do we tell our users that help is available? How much detail do we show at once? We’ve thought about this a lot for our new Faces commands.
The GUI
The graphical user interface is what most people think about when they hear “user experience” or “interface design.” Puppet’s GUIs today are the Forge and Dashboard.
The Forge is a place where Puppet users can find and share Puppet modules. It keeps accumulating useful modules, but has not seen much development from us in the last year. We have big plans, and will be talking about those soon in public.
Dashboard is a reporting tool and external node classifier. Its reporting features have improved, and we expect to ship version 1.2 in the near future with improved summary reporting and useful at-a-glance views of your nodes.
The DSL, or Puppet Language
Puppet’s DSL, also called the Puppet Language, is how Puppet users model the desired state of their systems. For example, this is the clearest and most compact way we’ve come up with for defining the properties we care about for one file:
file { '/var/log/syslog':
ensure => present,
mode => '0644',
} |
There are many user experience considerations here. This looks a little like Ruby code, but in fact it isn’t. Is the potential confusion to a new user worth the other benefits? What are those benefits and how do we weigh them?
For another example, there’s ticket #7599, discussing whether the trailing commas after “present” and “0644″ should be mandatory. Technical considerations aside, what would be the effect of making these optional, or even of prohibiting their use? Given that they are now required, would there be a migration costs for existing users? Would it be worth it?
The External API
An API is a structured way of issuing commands to a remote server and receiving responses. It’s a common way for web-based (and other) applications to communicate with each other. REST is one way of defining an API. Many Puppet commands are addressable via API.
Most user experience concerns here concern consistency and documentation. If a DELETE command works in one context it should work in another. Documentation should be clear and easy to access.
Not all of Puppet has an API, and not all of the APIs are as good as we would like. This is important to us and we will continue to improve.
The Internal API
The Internal API is a way of using Ruby both to define resources and to interact with Puppet internals. We have good documentation about how to define resources with the Ruby API. Our own Daniel Pittman has been writing a
series
of
posts
about our new Faces API and how to interact with it. These are a great introduction to manipulating Puppet’s internals.
The Future
It’s a mistake to think of this work as magic or guru-driven design. In fact its most important component is connection with the real users of our products. Puppet Camp was fantastic for this; our upcoming PuppetConf (watch for more information Monday) will be another great opportunity. We’re also starting more robust in-house usability testing for new work.
Next up in this space: What is user experience on the CLI? This will be a detailed look at user interaction on the command line, and extraction of useful principles to inform our work.