Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Design and Command Line Applications

pvande
June 27, 2012

Design and Command Line Applications

Design has permeated our culture and our tools, but the software you're building doesn't have a graphical interface. That doesn't exempt you from thinking about user experience design! Learn how UX principles apply to even basic command line scripts.

Talk given at Open Source Bridge 2012.

pvande

June 27, 2012
Tweet

More Decks by pvande

Other Decks in Technology

Transcript

  1. ---------------------------------------- Pieter van de Bruggen UX Designer at Puppet Labs

    Software Enthusiast and Developer [email protected] Github / Dribbble / Twitter: @pvande About Me
  2. ---------------------------------------- * Design for the Mind * User Interface Design

    * Information Architecture * Interaction Design * Design for the Heart * Graphic Design * Interactive Design * Emotion Design * Design for the Body * Industrial Design * Holistic Design * User Centered Design * Experience Design * User Experience Design What is design?
  3. ---------------------------------------- User Experience Design: Metadesign Balances user-facing design disciplines. Goals:

    * Self-describing software * Improved usability * Elegance * User delight What is design?
  4. ---------------------------------------- Design is “the art of removing choice.” * Flexibility

    vs. Utility * Less maintainable code * Visible options typically sap joy * Required decisions induce fatigue Each design is “a hypothesis.” What is design?
  5. ---------------------------------------- == Personas == A simple dossier describing the priorities

    of a particular user type. Simple Personas: * A name and a face * Typical needs and ambitions Complex personas: * Family life * Favorite breakfast cereal More info: bit.ly/ux-personas The Tools of UX Design
  6. ---------------------------------------- == User Stories == High-level description of user needs.

    * Audience * Desire * Motivation “Why” is typically a business goal As [a particular kind of user] I want [some function of your software] So that [my needs are adequately met] The Tools of UX Design
  7. ---------------------------------------- == Workflows == Specific outline of user processes. How

    do users find a particular feature? How are they expected to use it? What context are they expected to have? Take your most common use cases, and describe the process of getting things done -- from start to finish. The Tools of UX Design
  8. ---------------------------------------- == Sketches / Wireframes == Low-fidelity mockups. These provide

    a quick channel for testing designs and getting quick feedback from friends and co-workers. The more rapidly you can iterate on a design, the less time you waste on bad ones. The Tools of UX Design
  9. ---------------------------------------- == Paper Prototypes == Moderate-fidelity mockups. Used to validate

    interface choices and workflows with real users. Still simple to create and update, but with enough detail to complete specific tasks. The Tools of UX Design
  10. ---------------------------------------- == Interactive Prototypes == High-fidelity mockups. Useful for proving

    out highly complex workflows, but at a higher cost of implementation. The Tools of UX Design
  11. ---------------------------------------- This is not a comprehensive list of design tools.

    Each project has different needs: choose the appropriate tools accordingly. The Tools of UX Design
  12. ---------------------------------------- Those tools weren’t intended to be used for non-graphical

    interfaces... So what? The biggest difference is the scope of what can be designed. Design for Command Line Applications
  13. ---------------------------------------- | GUI (1996) | CLI (Now) Resolution | 1024

    x 768 | 80 x 24 Colors | 1.6 million | 8/16/256 Inputs | Mouse moves | STDIN | Mouse clicks | | Mouse drags | | Modifier keys | | Text input | Structured?| Yes | Yes / No Outputs | Dialog boxes | STDOUT | Windows | STDERR | System tray | File | Sounds | Non-Linear?| Yes | No Design for Command Line Applications
  14. ---------------------------------------- Additional constraints: User is not guaranteed to be behind

    I/O. $ ls | ./my-script > file # Only $STDERR is user-facing! Not all tools play nicely with color! Printing too many lines of output may prevent the user from ever seeing earlier messages. Design for Command Line Applications
  15. ---------------------------------------- (Puppet “modules” are code libraries) Originally shipped outside the

    core Puppet distribution. Included functionality for: * Creating new modules * Packaging modules * Installing modules from packages * Installing modules from repository Functional, not particularly elegant. Uptake of the tool was low. Case Study: Puppet’s Module Tool Redesign
  16. ---------------------------------------- Goal: Build a useful tool, deployed as a part

    of our core product, for immediate distribution. Case Study: Puppet’s Module Tool Redesign
  17. ---------------------------------------- Step 1: User Stories Initially described 34 distinct user

    desires. Validated and prioritized by the UX Designer, Product Owner, and Team Lead. MVP described as five CLI action: * Search * Install * List * Upgrade * Uninstall Case Study: Puppet’s Module Tool Redesign
  18. ---------------------------------------- Step 2: Concerns Actual example: From the command line

    I want to… * find a package… * by name ✓ * by keyword ✓ * by description ✓ * by author Provided a simple way to validate that user desires were going to be met. Case Study: Puppet’s Module Tool Redesign
  19. ---------------------------------------- Step 3: Workflows Actual example: Uninstall modules that aren’t

    used. * List currently installed modules * Try to uninstall a module which is depended upon * List the dependency tree for installed modules * Uninstall a module which is not depended upon * List currently installed modules Case Study: Puppet’s Module Tool Redesign
  20. ---------------------------------------- Step 3: Workflows Actual example: Uninstall modules that aren’t

    used. * List currently installed modules * Try to uninstall a module which is depended upon * List the dependency tree for installed modules * Uninstall a module which is not depended upon * List currently installed modules Case Study: Puppet’s Module Tool Redesign
  21. ---------------------------------------- Step 4: Wireframes Initially led with UI discussion. *

    How does command invocation look? * What is the form of the response? * What does the use of color signify? * How do we show feedback vs. results? * How do we report warnings and errors? Wireframes were “executed workflows”, demonstrating the result of the design decisions. Case Study: Puppet’s Module Tool Redesign
  22. ---------------------------------------- Step 4: Wireframes (cont.) Actual Example: # puppet module

    list --tree Missing dependency `bup` (v1.x): `lvm` (v1.1.0) requires `bup` (v1.x) /etc/puppet/modules └─┬ mylvmbackup (v1.1.0) ├── UNMET DEPENDENCY bup (v1.x) └─┬ mysql (v1.0.2) └── puppet (v1.0.1) Case Study: Puppet’s Module Tool Redesign
  23. ---------------------------------------- Step 5: User Testing At this point, we can

    trace each choice we’ve made back to its origin, which gives us a moderate confidence. Testing with real users can validate or refute our choices. In order to be useful, we must act on what we learn. Case Study: Puppet’s Module Tool Redesign
  24. ---------------------------------------- Developing a design discipline takes non-trivial time and effort.

    Less rigorous design can be a valuable tool for learning to think about design, and for socializing the ideals within your team. Informal Design
  25. ---------------------------------------- Before you write code, write the README. A good

    README: * Explains the project’s existence * Provides clean examples * Demonstrates the public interface Writing this first forces you to consider -- and document! -- your design up-front. Document the ideal interface; iterate when necessary. README-Driven Development
  26. ---------------------------------------- Design isn’t magical. README-Driven Development isn’t magical. Functional programming

    isn’t magical. They all have the potential to change the way you think and work. README-Driven Development