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

Mixing User Experience with Open Source

Ef5dd10447fe974d9e21fa0f0ecb195a?s=47 Erin Jo Richey
February 18, 2015

Mixing User Experience with Open Source

My talk on ux and open source for the Bay Area UXPA.

Ef5dd10447fe974d9e21fa0f0ecb195a?s=128

Erin Jo Richey

February 18, 2015
Tweet

Transcript

  1. Mixing User Experience with Open Source Erin Jo Richey @erinjo

    erinjorichey.com erinjo.is
  2. None
  3. withknown.com

  4. Notes Pictures Locations Audio Learning ! management systems Social !

    networks
  5. None
  6. None
  7. Me Ben

  8. None
  9. What is open source software? It is software that can

    be modified because its source code and essential blueprint is publicly accessible.
  10. Who are the people in open source projects? They are

    the owner, the maintainers/collaborators, the contributors, the community members, and the users.
  11. Owner Maintainers Contributors Community Users

  12. How does contributing to open source work? For many projects,

    being a “contributor” consists of making a change to code, submitting a pull request, and having that change merged back into the main code base.
  13. How does contributing to open source work? This isn’t usually

    a common task for people whose work focuses on usability and user experience.
  14. Why do UX people like participating in open source?

  15. Why do UX people like participating in open source? …it

    feels rewarding
  16. Why do UX people like participating in open source? …they

    are motivated to help others
  17. Why do UX people like participating in open source? …they

    get to see their work being used
  18. Why do UX people like participating in open source? …they

    get to develop a relationship with the users
  19. Why do UX people like participating in open source? …it

    can feel more freeing then a typical job
  20. Why do UX people like participating in open source? …they

    get to learn new things
  21. Why do UX people like participating in open source? …they

    like facing different challenges
  22. Why don’t UX people participate more often in open source?

    it’s daunting…
  23. Why don’t UX people participate more often in open source?

    it’s intimidating…
  24. Why don’t UX people participate more often in open source?

    the tools aren’t familiar…
  25. Why don’t UX people participate more often in open source?

    it’s hard to know where to get started…
  26. Why don’t UX people participate more often in open source?

    there are fewer incentives to stick with it if you don’t or can’t use the tool or platform…
  27. Why don’t UX people participate more often in open source?

    not all communities feel welcoming to beginners or non-developers…
  28. Why don’t UX people participate more often in open source?

    in a lot of projects, it can feel like design is decorating the cake - it’s a touch up job for code that already exists…
  29. [ is there a gap to bridge?]

  30. Developers have certain methods, tools, and workflows that aren’t always

    familiar to designers. ! This can be challenging, confusing, and create obstacles. !
  31. The following story was left as a blog comment… “Open

    source needs designers”! http://benwerd.com/2011/06/27/open-source-needs-designers/
  32. Developer: Hi Designer! We’re really glad you decided to join

    our project. We could really use a great UI because we suck at design.
  33. Designer: Thanks! I’m looking forward to helping out. I have

    some really great ideas for the project.
  34. Developer: That’s awesome Designer. I’ve got you an svn account

    setup. ! fred/23rSD@#$SDRsdfEasd5323. ! Go ahead and check out the source.
  35. Designer: Where do I check out the source?

  36. Developer: svn://open-source-project-x.com/svn/trunk

  37. Designer: Cool, thanks!

  38. [ 10 minutes later… ]

  39. Designer: Uhh…I don’t see anything at the url.

  40. Developer: ???

  41. Designer: When I go to that url, I don’t see

    anything. Safari just gives me a message saying it can’t open that url or something.
  42. Developer: Haha! You’re not supposed to ‘check out’ the source

    as in ‘view’, you’re supposed to run that command from the command line. svn co svn://open-source-project-x.com/svn/trunk
  43. Designer: Oh! Sorry, never done this before. So just type

    that in…. Terminal I suppose?
  44. Developer: yeah.

  45. [ 10 minutes later… ]

  46. Designer: Man, I’m just having bad luck or something. When

    I type that command in I get the message: ! - bash: svn: command not found
  47. Developer: You’ve got to have svn installed. Have you installed

    it yet?
  48. Designer: No, where do I get it?

  49. Developer: Just run sudo part install svn

  50. Designer: sudo port intall WTF?

  51. Developer: Do you have Darwin ports installed?

  52. Designer: I don’t think so? What’s that?

  53. Developer: Grab it from here https://www.macports.org/install.php

  54. [ 2 hours later… ]

  55. Designer: Ok, I’ve managed to get Darwin ports installed and

    I’ve checked out the source. Finally!
  56. Developer: Awesome! You should be able to rock and roll

    now.
  57. Designer: Great, going to check it out now (as in

    view).
  58. [ 30 minutes later… ]

  59. Designer: Developer, you know I think we should really change

    the way feature-x is implemented. It’s just not that intuitive. From a user’s perspective, we should probably implement it like… ! (insert well-founded design decision)
  60. Developer: Hmm… ! I don’t know. I think it’s fine

    the way it is. Besides, it would take forever to implement it the way you think it should be. We’d have to change too much stuff.
  61. Designer: Hmmm… ! OK.

  62. Developer: So, think you can make this look like a

    really awesome app?
  63. [ The End ] cancel bubble (cancelbubble.com) June 27, 2011

  64. Designers may also have a way of working that is

    unfamiliar to developers or out of sync with how they are working.
  65. “You’ve come into our front room, and, while we were

    making a cup of tea, you moved all the furniture around. Not only that, but you redecorated, changed the carpet, and removed all of our belongings.” View from a developer: “Design in Open Source”! http://www.markboulton.co.uk/journal/design-in-open-source
  66. [ we can bridge the gap ]

  67. [ but we need a few things ]

  68. We need UX and design professionals who feel empowered to

    contribute to open source.
  69. We need developers who are interested in bringing a people-centric

    perspective to open source projects.
  70. We need people from both design and development who are

    comfortable closely collaborating.
  71. Tonight, I can help you feel a bit more knowledgeable

    and empowered to participate in open source.
  72. 6 steps for getting started with open source

  73. step 1 Find a project that interests you.

  74. Step 1 - Find a project that interests you. Do

    you use it? Do you feel passionate about it? Do you want to dedicate time to it?
  75. step 2 Introduce yourself to the community.

  76. Step 2 - Introduce yourself to the community Email or

    message the project maintainers or project lead. Introduce yourself and your skill set. Ask if there are areas where you can help. Follow along with the community (on IRC, mailing lists, issue lists, forums, etc).
  77. step 3 Choose a tangible first problem.

  78. Step 3 - Choose a tangible first problem. Start with

    small, actionable things. Don’t just point out problems, pick out important issues and offer suggestions for fixing the problem. Your contributions will be easier to put in place if the problem, solution, and benefit is clear and easy to enact.
  79. step 4 Communicate your solution well.

  80. Step 4 - Communicate your solution well. Communicate your solution

    clearly. Document your findings and suggestions. Focus on effective communication, not overwhelming communication. Screenshots with descriptions or videos with explanations can help convey the message.
  81. step 5 Share your solution with the community.

  82. Step 5 - Share your solution with the community. Point

    out your solution to the project maintainers or contributor community. You can leave an issue, email the maintainers directly, or send a message to the community mailing list. You can also blog about it and point people at your post.
  83. step 6 Get feedback from the leaders.

  84. Step 6 - Get feedback from the leaders. After sharing,

    follow up with the core team or project leaders. Ask if your solution is hard to implement or isn’t a priority. Remember: They may have other priorities or interests. Your solution might not fit their roadmap.
  85. Tips for choosing a project to contribute to. Look for

    something that other people have contributed to.
  86. Tips for choosing a project to contribute to. Look for

    something that is actively being worked on.
  87. Tips for choosing a project to contribute to. You might

    have luck with a newer or smaller project on Github or an older project that is going through a resurgence.
  88. Tips for choosing a project to contribute to. Look for

    a community. This could be on Github, in a forum, on a mailing list, on IRC, or elsewhere.
  89. Tips for choosing a project to contribute to. Check for

    a readme.md file and some instructions for getting started.
  90. Tips for choosing a project to contribute to. Check for

    a wish list or a page that addresses “how to contribute.”
  91. Places to find projects. github.com - a network and repository

    for code sourceforge.net - a directory or open source projects alternativeto.net - compares software and suggests alternatives openhub.net - a network of open source projects openhatch.org - matches first time contributors with projects
  92. Good projects for UX people to start with. ThinkUp -

    known for being friendly to beginners in open source https://www.thinkup.com/docs/contribute/ OwnCloud - has specific guidelines for design, usability, ux https:// owncloud.org/contribute/design/ Drupal - big project that carries out usability testing and has resources around user experience https://www.drupal.org/ community-initiatives/drupal-core/usability Known - we’ve been making our user research materials open to help bring about more user testing and usability https://github.com/idno/User-Research
  93. Areas where you can contribute beyond development. Contribute design skills

    for a logo or icons.
  94. Areas where you can contribute beyond development. If you speak

    more than one language, translate copy or documentation to another language.
  95. Areas where you can contribute beyond development. Help write user

    guides and documentation.
  96. Areas where you can contribute beyond development. Help with bug

    finding, testing, and QA.
  97. Areas where you can contribute beyond development. Focus on usability

    or conduct user research.
  98. Areas where you can contribute beyond development. Create a style

    guide.
  99. Areas where you can contribute beyond development. Build a pattern

    library for UI elements.
  100. Areas where you can contribute beyond development. Contribute wireframes or

    user flows around specific areas that are being updated or are in development.
  101. Areas where you can contribute beyond development. Is it responsive?

    Does it have apps? Provide feedback from different devices.
  102. IRC (internet relay chat)! Many discussions within open source communities

    take place on IRC. Check out Colloquy or IRCCloud as apps to get started. ! http://colloquy.info/ - Colloquy http://www.irccloud.com - IRCCloud ! Tools to get started
  103. Github! Lots of modern projects post their code on Github.

    This is often where you can download files, find resources, and initiate pull requests. ! Create an account and get familiar with the website and apps. ! http://github.com Tools to get started
  104. Pull requests! Pull requests are the standard way that people

    “contribute” code to open source projects. ! ! ! ! http://pullup.io/- initiate your first pull request http://www.thinkful.com/learn/github-pull-request-tutorial/ - learn about pull requests ! Tools to get started
  105. How you can contribute to Known #knownchat - chat with

    the community on IRC ! withknown.com/developers - for open source information ! https://github.com/idno - check out our repositories on Github ! founders@withknown.com - email Ben and I with your interests ! https://groups.google.com/forum/#!forum/known-dev - join our community mailing list !
  106. How you can contribute to Known writing - help us

    write documentation, faqs, and guides ! usability - help us test user flows, new features, and devices ! language - help us translate the platform into other languages ! HTML & CSS - contribute a new theme or clean up existing styles ! UI - help us compile a pattern library for common interface elements ! accessibility - help us test with assistive devices and pinpoint issues
  107. None
  108. Articles and info on UX and open source… jancborchardt.net/usability-in-free-software -

    Usability in Free Software ! opensourcedesign.net - Resources for designers working on open source projects ! www.markboulton.co.uk/journal/design-in-open-source - Design in Open Source ! disambiguity.com/contemplating-open-source-ux/ - Contemplating Open Source UX ! medium.com/words-about-design/designing-open-source-e3adc220cfa7 - Designing Open Source
  109. Erin Jo Richey erin@withknown.com @erinjo Thank you!