Design and Command Line Applications Open Source Bridge 2012 

---------------------------------------- Pieter van de Bruggen UX Designer at Puppet Labs Software Enthusiast and Developer [email protected] Github / Dribbble / Twitter: @pvande About Me 

---------------------------------------- * 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? 

---------------------------------------- None of this properly captures “design” Design is optimization with constraints What is design? 

---------------------------------------- Software Architecture: * Performance * Scalability * Fault-Tolerance * Maintainability * Conceptual Correspondence What is design? 

---------------------------------------- Industrial Design: * Time * Material Cost * Physical Space * Ergonomics * Style What is design? 

---------------------------------------- User Experience Design: Metadesign Balances user-facing design disciplines. Goals: * Self-describing software * Improved usability * Elegance * User delight What is design? 

---------------------------------------- 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? 

---------------------------------------- == 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 

---------------------------------------- flic.kr/p/5eGzHh The Tools of UX Design 

---------------------------------------- == 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 

---------------------------------------- The Tools of UX Design 

---------------------------------------- == 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 

---------------------------------------- flic.kr/p/9jUgPC The Tools of UX Design 

---------------------------------------- == 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 

---------------------------------------- flic.kr/p/5vHtS2 The Tools of UX Design 

---------------------------------------- == 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 

---------------------------------------- flic.kr/p/36QG2B The Tools of UX Design 

---------------------------------------- == Interactive Prototypes == High-fidelity mockups. Useful for proving out highly complex workflows, but at a higher cost of implementation. The Tools of UX Design 

---------------------------------------- This is not a comprehensive list of design tools. Each project has different needs: choose the appropriate tools accordingly. The Tools of UX Design 

---------------------------------------- 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 

---------------------------------------- | 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 

---------------------------------------- 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 

---------------------------------------- (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 

---------------------------------------- Goal: Build a useful tool, deployed as a part of our core product, for immediate distribution. Case Study: Puppet’s Module Tool Redesign 

---------------------------------------- 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 

---------------------------------------- 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 

---------------------------------------- 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 

---------------------------------------- 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 

---------------------------------------- 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 

---------------------------------------- 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 

---------------------------------------- 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 

---------------------------------------- Wireframes Final Product Case Study: Puppet’s Module Tool Redesign 

---------------------------------------- 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 

---------------------------------------- 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 

---------------------------------------- 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 

---------------------------------------- Find the vision of the tool you want… …then go bring it into existence. README-Driven Development 

Thank you.