The slides for a talk at https://ar-fullstack.tech about how to create a great User Experience in Open Source Software.

1. Full Stack Tech, November 2017
Maintaining a great User Experience
In Open Source Software
Sameer Al-Sakran

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. What is Metabase?

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

6. Our users appreciate our focus on
their experience

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

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

9. @metabase I just found you and I frigging love you.
Love love love love love.
@davesuperman

10. But enough about me, let’s talk about
The Problem

11. UX in Open Source software
sucks
can be less than amazing

12. What is User Experience anyway?

13. How software feels for the end user.
What is User Experience?

14. The functionality of the app is “well organized”
What is User Experience?

15. It’s obvious what the user can do at any point
What is User Experience?

16. Surprises are pleasant. There are no traps.
What is User Experience?

17. The user doesn’t need to know extra information
What is User Experience?

18. But really a good user experience means
people want to use your application

19. Why should I care, Sameer?

20. … SAP made 22B euros last year with
this interface…

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

23. 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!

24. How do you create a wonderful User
Experience?

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

26. 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…

27. 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])

28. 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….

29. ….. 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 ….”

30. ….. 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?

31. An example from Metabase

32. Example - Initial actions in the Metabase query builder

33. “We need a way to let people browse
related fields or tables.”

34. Example - Added reference

35. “We need a way to let people convert
GUI queries to SQL.”

36. Example - Added SQL

37. “People are asking for a way to add
alerts to questions…”

38. 8 requests later…

39. (Please note we did not actually do this)

40. “We need a way to make sure this
doesn’t become utter madness”

41. Lets create a structure that lets us
add new things while keeping things predictable

42. Manage Share Item specific

43. Edit this ques+on
View revision history
Move
Archive

44. This extremely simple example demonstrates
what’s so frustrating about UX Design

45. The better the job you do,
the more obvious the result looks

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

47. So why is it worse in Open Source
applications?

48. 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)

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

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

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

52. 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%

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

54. But really… why is it so much worse in
Open Source Applications?

55. Well… how do Open Source projects make
money?

56. Most Open Source Companies sell
• Support
• Training
• Adding Custom Features
• Services i.e. building custom systems
• Hosting

57. All of these get less compelling the
better your user experience becomes.

58. So… what can you do?

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

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

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

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

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

64. We’re Hiring!
Want to write Open Source Software full time?
metabase.com

65. metabase.com
Frontend - ReactJS + Redux
Data Visualization - D3
Backend - Clojure, Machine Learning, Compiler Theory, Data Science
Databases
We’re Hiring!