Diese Präsentation wurde erfolgreich gemeldet.
Die SlideShare-Präsentation wird heruntergeladen. ×

Full stack conference talk slides

Wird geladen in …3

Hier ansehen

1 von 65 Anzeige

Weitere Verwandte Inhalte

Diashows für Sie (20)

Ähnlich wie Full stack conference talk slides (20)


Aktuellste (20)

Full stack conference talk slides

  1. 1. Full Stack Tech, November 2017 Maintaining a great User Experience In Open Source Software Sameer Al-Sakran
  2. 2. Who am I? Founder of the Metabase project 
 (metabase.com | github.com/metabase/metabase) Built Gitalytics.com (people search + analytics for Github, Bitbucket, Jiira, etc) Was CTO of Expa, Blackjet, etc etc
  3. 3. What is Metabase?
  4. 4. Metabase is free, easy, open source BI • Designed for non-technical users • Bring your own database (SQL or NoSQL) • Installs in 5 minutes • Gets smarter about your data with usage • Provides an easy, non-intimidating experience for users and admins
  5. 5. Our users appreciate our focus on their experience
  6. 6. Unbelievable that we haven't had something powerful and simple like @metabase up until now. Even now there isn't something else close to it. @petmongrels
  7. 7. Very impressed by @metabase. Easy to setup and an intuitive interface. The first BI tool I’ve encountered in my life that I actually want to use. @vikasgorur
  8. 8. @metabase I just found you and I frigging love you. Love love love love love. @davesuperman
  9. 9. But enough about me, let’s talk about The Problem
  10. 10. UX in Open Source software sucks can be less than amazing
  11. 11. What is User Experience anyway?
  12. 12. How software feels for the end user. What is User Experience?
  13. 13. The functionality of the app is “well organized” What is User Experience?
  14. 14. It’s obvious what the user can do at any point What is User Experience?
  15. 15. Surprises are pleasant. There are no traps. What is User Experience?
  16. 16. The user doesn’t need to know extra information What is User Experience?
  17. 17. But really a good user experience means people want to use your application
  18. 18. Why should I care, Sameer?
  19. 19. … SAP made 22B euros last year with this interface…
  20. 20. You should care because the world is changing iPhones + faster buying cycles + more competition + end users have more power in selecting tools. Better End User experiences results in winners. What’s the difference between Dropbox and every other storage app?
  21. 21. Why should you personally care? • Learn how to work with designers • Making Open software with good UX is playing on #HardMode
 Take the lessons back to work, commercial, and solo projects
 • All the same lessons apply for API design and other more classic“engineering” problems. • Help make the Open Source that we all use better!
  22. 22. How do you create a wonderful User Experience?
  23. 23. What most people think design looks like 1. Gather requirements 2. Code up a basic version 3. A designer “Cleans it up” 4. The manager’s | engineer’s vision is accomplished. 
 They get the raise they deserve.
  24. 24. What designers actually do all day 1. Get told 25% of the context they need of the problem 2. Design a solution 3. Realize it’s not quite right. Go back to step random.choice([1,2]) 4. Show the solution to engineers | product | designers.
 They point out some huge hole. Go to step 1 5. Get it coded…
  25. 25. What designers actually do all day (continued) 6. Realize it doesn’t quite work, go back to 1 7. Show the solution to real users and realize it doesn’t quite work. 8. Go back to step random.choice ([1,2,5])
  26. 26. What designers actually do all day • It’s work. • Long thankless work, with a final payoff in beauty and flow. • The kind of thing you typically need to get paid to do….
  27. 27. ….. you thought you were done? The fundamental tension of having a great UX is — Your Users want you to break the reason they love you (great UX) by adding more features… “Can’t you just add a button for ….”
  28. 28. ….. you thought you were done? • UX decays as you add features • It requires constant re-working to maintain a given level of quality. • Additionally, this is similar to the API versioning problem — how do you change interfaces people have gotten dependent on?
  29. 29. An example from Metabase
  30. 30. Example - Initial actions in the Metabase query builder
  31. 31. “We need a way to let people browse related fields or tables.”
  32. 32. Example - Added reference
  33. 33. “We need a way to let people convert GUI queries to SQL.”
  34. 34. Example - Added SQL
  35. 35. “People are asking for a way to add alerts to questions…”
  36. 36. 8 requests later…
  37. 37. (Please note we did not actually do this)
  38. 38. “We need a way to make sure this doesn’t become utter madness”
  39. 39. Lets create a structure that lets us add new things while keeping things predictable
  40. 40. Manage Share Item specific
  41. 41. Edit this ques+on View revision history Move Archive
  42. 42. This extremely simple example demonstrates what’s so frustrating about UX Design
  43. 43. The better the job you do, the more obvious the result looks
  44. 44. But to answer the original question • Spend lots of time evaluating different UIs before writing code • Show them to your end users • Think carefully about the consequences of each additional feature in other parts of the application • Plan on having a major re-working of the feature after letting users use it • Schedule time for UX Refactoring, you’ll need it.
  45. 45. So why is it worse in Open Source applications?
  46. 46. Well, sometimes it’s not that bad • When the end user is a developer, you tend to get reasonable UX. • You can make the case that Rails, Mongo, etc were really all about developer UX (eg an elegant API)
  47. 47. Reason 1: Drive-by Pull Requests • Metabase annecdote — despite a fairly clear contributors guide, we still get half-broken PRs that have broken UX or design, don’t have tests, don’t pass our linters, etc. • Limited ability to force people to re-work a PR • A dedicated, team player that wants to help is a near impossibility
  48. 48. Reason 2: Dirty Secret of Open Source • Most projects are the result of 1-3 people. • 78% of github repos have all commits contributed by 3 or fewer people • 97% of github repos have 3 or fewer people contribute more than 50% of the commits And this is a drastic undercounting, as many commits are small and/or minor documentation fixes.
  49. 49. Most people who are able to write good code and chose to do it for free aren’t “normal” 1. They’re probably smarter than average
 2. FAR more technical than average
 3. FAR more immersed in the specific domain
 Hint: More features != Better As a result, the average* contributor is unable to understand 
 what a normal human being would think is a “good” User Interface.
  50. 50. Reason 2.5: Talent Very few people are good at • Coding • Visual Design • UX Design The odds of a random OSS contributor having all three of these skills is ~0%
  51. 51. Why not get a designer to “fix your UI”? • Good design is done at the beginning. It’s not just a matter of “fix this” or “improve this” • People who don’t know how to design things think it’s magic and/or effortless + more about the tools (eg “oh, my friend knows how to use photoshop too”) • Good design takes time and has lots of missteps. There are a lot of bodies on the path up to the summit. How do your contributors feel about making a bunch of prototypes for a feature they “had working” in a PR a month ago?
  52. 52. But really… why is it so much worse in Open Source Applications?
  53. 53. Well… how do Open Source projects make money?
  54. 54. Most Open Source Companies sell • Support • Training • Adding Custom Features • Services i.e. building custom systems • Hosting
  55. 55. All of these get less compelling the better your user experience becomes.
  56. 56. So… what can you do?
  57. 57. In general • Accept that if you want to make something beautiful and amazing it’s going to be hard work. • You’ll get 1/3 of the features of the other projects. Pick which features wisely. • Make sure users see possible solutions and use their responses to guide you to the right solution • Support projects that get this right
  58. 58. As a solo developer • Use your product outside of working on it. • Create working end to end prototypes and get them in front of your users earlier • Listen to what they say — A Confused User is never stupid. • Talk to your users, especially ones that are different from you
  59. 59. Working inside of a company • Use your product outside of working on it. • Hire a good designer. 
 Side note: Product Designers, UX Designers and Visual designers are all different. You’ll eventually want people good at each of those. • Help designers understand the costs of what they propose • Remember that “clean” applications need to be clean for the end user and not just the developer
  60. 60. As an Open Source Project • Pull in designers • Make simplicity, elegance and quality your goals • Behave accordingly • Review all Pull Requests from the user’s perspective • Use the application • Set up automated user surveys (via google forms, twitter, etc) • Promote a culture of continuous improvement that means reworking “done” features
  61. 61. As a community • Build and use standardized interfaces (aka the Bootstrap model) • Support companies exposing their commercial quality work to the open source world. Maybe chill out about Open Core and License Wars • Question the current monetization models (services + hosting providers make 99% of the revenue in eg linux) results in UIs that look + feel like backend software • If you’ll pay for instance hours (Xen-as-a-Service) but not software, then software will get worse
  62. 62. We’re Hiring! Want to write Open Source Software full time? metabase.com
  63. 63. metabase.com Frontend - ReactJS + Redux Data Visualization - D3 Backend - Clojure, Machine Learning, Compiler Theory, Data Science Databases We’re Hiring!