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.

Transcript

1. Design and Command Line Applications Open Source Bridge 2012
2. ---------------------------------------- Pieter van de Bruggen UX Designer at Puppet Labs Software Enthusiast and Developer pvande@gmail.com Github / Dribbble / Twitter: @pvande About Me
3. ---------------------------------------- * 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?
4. ---------------------------------------- None of this properly captures “design” Design is optimization with constraints What is design?
5. ---------------------------------------- Software Architecture: * Performance * Scalability * Fault-Tolerance * Maintainability * Conceptual Correspondence What is design?
6. ---------------------------------------- Industrial Design: * Time * Material Cost * Physical Space * Ergonomics * Style What is design?
7. ---------------------------------------- User Experience Design: Metadesign Balances user-facing design disciplines. Goals: * Self-describing software * Improved usability * Elegance * User delight What is design?
8. ---------------------------------------- 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?
9. ---------------------------------------- == 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
10. ---------------------------------------- flic.kr/p/5eGzHh The Tools of UX Design
11. ---------------------------------------- == 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
12. ---------------------------------------- The Tools of UX Design
13. ---------------------------------------- == 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
14. ---------------------------------------- flic.kr/p/9jUgPC The Tools of UX Design
15. ---------------------------------------- == 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
16. ---------------------------------------- flic.kr/p/5vHtS2 The Tools of UX Design
17. ---------------------------------------- == 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
18. ---------------------------------------- flic.kr/p/36QG2B The Tools of UX Design
19. ---------------------------------------- == Interactive Prototypes == High-fidelity mockups. Useful for proving out highly complex workflows, but at a higher cost of implementation. The Tools of UX Design
20. ---------------------------------------- This is not a comprehensive list of design tools. Each project has different needs: choose the appropriate tools accordingly. The Tools of UX Design
21. ---------------------------------------- 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
22. ---------------------------------------- | 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
23. ---------------------------------------- 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
24. ---------------------------------------- (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
25. ---------------------------------------- Goal: Build a useful tool, deployed as a part of our core product, for immediate distribution. Case Study: Puppet’s Module Tool Redesign
26. ---------------------------------------- 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
27. ---------------------------------------- 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
28. ---------------------------------------- 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
29. ---------------------------------------- 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
30. ---------------------------------------- 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
31. ---------------------------------------- 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
32. ---------------------------------------- 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
33. ---------------------------------------- Wireframes Final Product Case Study: Puppet’s Module Tool Redesign
34. ---------------------------------------- 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
35. ---------------------------------------- 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
36. ---------------------------------------- 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
37. ---------------------------------------- Find the vision of the tool you want… …then go bring it into existence. README-Driven Development
38. Thank you.