What is Open Source UX? – Current status – A roadmap for Contributing UX



What is Open Source UX? – Current status – A roadmap for Contributing UX

0 0


fosdem2015


On Github pablocubico / fosdem2015

A quest for really open UX design

Pablo Cúbico - FOSDEM 2015

Psst!: Press V to see the slide notes

About me
I'm a Mozilla Rep in my country, despite having some differences with some latest year's decisions. Also, I'm the founder of the local chapter of Hacks/Hackers in my hometown. For those of you who don't know what Hacks/Hackers is, it's a crossover between journalists and developers for data journalism and related topics. As a first project, we mapped the drug related murders on my city for 2013. And last but not least, I recently started contributing very slowly to Diaspora, I hope the pace goes up next year.

What is Open Source UX?

So, we are here to talk about Open Source UX, or UX for free and open source projects. Sadly, this is something that doesn't quite exists yet, so let's use this time to talk about UX design processes and about opening them. But even before asking what is open source UX, we should ask this instead:

What is UX anyway?

As the sasquatch (or bigfoot), an actual definition of UX is a really hard thing to find. There is a lot of noise around what UX actually is. Let me introduce you to what I think UX is so we can all be in the same page for that matter.

UX stands for USER EXPERIENCE

Ok, I'm stating the obvious here. But let's use this as an exercise to clear our heads and reboot what we think of user experience.

User Experience is...

the experience a user has while using a product.

  • It can be measured
  • It can be improved
  • It can be developed and designed
The experience of a user can be measured through many tools, mostly, by the user's feedback.

GOOD User Experience

Symbiotic, Prosthetic, Uninterrupted , Continuous

Most authors try to avoid defining some universal rules, and I hate that. So I brought some of my own to share with you. I like to think of user experience (and design in all its flavors), as the way in which we communicate with technology.

Common misconceptions and myths

People have different views about what UX is or should be. Let's start by debunking some common misconceptions and myths around UX.

"UX is a process"

No, UX is an attribute of your product.

UX design is a process.

Say what? UX is not a process?. You will find tons of sites saying how and why "UX" itself is a process. Well, if you say "UX", you are not talking about a process, you are talking about an attribute of your product (or someone else's). Remember, UX is an attribute, UX DESIGN is a process, or if you prefer, UX DEVELOPMENT.

UX is not beauty

Of course beauty plays an important role in something that we call "experience", but beauty is an elusive concept, you can try to measure it and going golden ratio all over your buttons and headings, but that won't magically translate into good user experience. However, beautiful design conveys many values, as TRUST. Users will often trust a beautiful design over a flawed one. We will come back to this later.

UX is UI

UX involves many other things

  • Visual design
  • Interaction design
  • User testing
  • Performance
  • etc.
UX is more than just UI design. UX is about developing your user's experience, and that alone requires involvement from a lot of different areas.

UX vs. UI: a few samples

Don't worry, I'll read aloud.

"Drop an asset libraryand BAM!: UX"

UX design is a process, it has to be deeply embedded into the development process, as it is iterative. Open UI libs may solve a problem or two, but UX is different in every product, so it will always be developed for that product only.

The infamous"Design is art" myth

"open source design is an oxymoron." -Chris Messina Whoa! Another title. This is a very unfortunate and misleading quote. Some say design is art so it can't be done by collaborating, but design is not merely art. Art is totally unpaired with function, maybe we can discuss what's the "function" of art, but that's another topic. Let's see an industrial design example.

Design is form + function

Style is unique to every designer, but design problems are constrained by the needs of function. Design comes from architecture (mostly), so does industrial design. Take this Siemens iron for example, it serves a purpose, so it basically looks like any iron, the color choice and ornamental details may vary from one to another, but the general function is dominant.

Flawed design

When design fails to serve its purpose, this happens. So this is not design, instead, it's a pretty strong art piece.

Style varies

It's a visual design problem, not a UX one

Style varies from one designer to another. This can lead to consistency issues, but it can be definitely solved by agreeing on style conventions which are deeply intertwined with identity choices.

Current status

"Free Software UX sucks"

"Commercial software does better"

I hate this quotes. This is yet another misconception, it's an unfair comparison and a generalisation that really hurts our community. Also, big corporations spend a lot of money to convince you that their UX is good. Let me show you an example from real life.
I think these pictures speak for themselves.

Problems in FOSS UX

1. Lack of participation

There is an obvious lack of involvement of designers into free software projects.

2. No clear paths for contribution

Often, when you go to a project wiki, docs, issue trackers, community forums or whatever, it is hard to find which UX problems are there and how to solve them. You'll find more "UI errors" than "UX problems".

3. Devs don't know where to start

People who is actually coding the UI don't know about the UX design process and they don't know where to start.

4. Disconnected lone rangers

UI coders who don't work together produce both inconsistent code and UIs. Not having "UI teams" working towards consistency creates random pieces of UI goodness distributed in isolated pieces through a product.

5. Style differences

When you actually have designers contributing, there will be style differences between them. As an artist, each designer has a unique style. These need to be sorted through a higher convention.

6. "Can I Haz" requests

Many times designers come with ideas that are unrealistic and difficult to implement, like whole new features. These won't help as much as doing little improvements.

7. Everyone is a designer

Open source is about collaboration, but sometimes this leads to hundreds of people trying to be involved in design choices.

8. Customize all the things

Free software makers often try to make software as customizable as possible. This is deeply linked to the heart and nature of open source, but it's really difficult to do well, and it leads to a lack of identity on many products.

9. No proper tools

Most tools of the trade for UX designers are closed and paid. We definitely need to find the right tools for design collaboration, design voting, UX prototyping, etc.

10. No T-shaped devs/designers

It's hard to find those with the skills to do both design and development. It is really useful to have one of those T-shaped people to integrate both worlds into one.

11. Code health

UI code can be a real mess. It's hard to do improvements on an unhealthy codebase, changing things as the underlying layout sometimes is just plainly impossible. You'll need to find a compromise between code quality, refactoring and improvement pace to even start minor things.

12. No room for you

Is design welcomed? If it's not in the mind of the current contributors, getting them to work with you on a timely basis will be impossible. Closed groups leave room for no one, sometimes it is difficult enough just trying to contribute, even more when you are a designer, an alien into the development world. That's why those T-shaped professionals are needed.

13. No visibility

Another situation may occur: you contribute, you send a pull request, a patch... and then no one sees it. It happened to me, I have some trouble getting people involved in things as Diaspora's identity. Many developers are not interested in design talk, many consider it irrelevant. This could also affect you emotionally, if you invest a couple of hours in a project, with confidence, and your worked gets drowned in a sea of nothingness, you'll get angry. Staying cool requires a lot of patience.

14. Style dilution

This is mostly for pure designers. Style will always have a strong influence from a core designer. Why? Because that's the artistic part of design, it's really hard to develop a style for a product by trying to please everyone. This is one of the hardest points, because this is the place where collaboration becomes an obstacle. For that reason, you have to struggle to justify your stylistic and aesthetic choices with reasoning, good will, and be ready to discuss a lot. But as you know, a picture is worth a thousand words, so maybe if you show your work and the community engages with your style, maybe making a few compromises, then you can earn the trust you need to continue working. Community has to trust and value a designer's vision, your style, and your aesthetics. By having a single person's vision and trust, UI coders and interested people can work faster under that aesthetic umbrella.

15. Assumptions, assumptions everywhere.

Sad but true, when a project is ongoing for a few years and the UX remains pretty much untouched, be pretty sure that everyone is making assumptions about what users do or want with almost no data. Common sense can be your friend or your enemy in this area.

16. Resisting change

We all heard this one, as it often happens in our daily lives. Change is hard, not everyone welcomes it and you'll find a lot of "oh, it has been this way for two years, why change it". However, you have to listen to that resistance, maybe you are trying to change something that actually... shouldnt be changed...

17, 18, 19... many others...

Have you tried? Share your experience!

So there are a lot of other issues when it comes to integrate UX design into the FOSS development processes. Share your findings now or after the slides.

A roadmap for Contributing UX

Challenges and opportunities

0: Introduce yourself

Become a member

  • Invite yourself to the party
  • Identify some measurable problems
  • Do some work to show your potential
  • Be bold, there is always time to go back
  • Be humble
The first need you'll to step into a FOSS project as a UX designer is introducing yourself. If you are being honest about your goals, it will come easy. Set your goals, find your motivations, don't try to be a hero. But be bold, invite yourself to it. No one is going to ask you to improve the UX of a particular project, if you believe you can, just jump aboard and make a suggestion. Some will welcome you, some not, some will just ignore you, but then you'll know if there is room for contributing or not.

1. Get to know the community!

Biggest perk from FOSS projects

  • Always ask the community
  • Get validation
  • Be honest
  • Invite others to join your quest
  • Give recognition
  • Don't take over
  • Relax your ego
Community is the biggest perk we have from FOSS projects. This is what most commercial projects don't have. It has it's pros and cons, but overall, we can leverage the community to build the basics of User Experience for a product, and to do many other tasks, specially, the most important one: user testing. First, you'll have to get validation from the community. Contributing a patch could be a great start, but also, showing your good will and your expertise could help. Remember, you'll not go anywhere unless you are a member of the community, so you'll need to have the social skills to do so.

2. Consider starting with identity

  • Analyze current status (colors, fonts, etc)
  • Gather community opinions (survey)
  • Begin with a proposal
  • Explain why brand matters
  • Beware of sensitive stuff (i.e.: LOGO)
What's the status of identity on an X project? Identity will give you the basis for color choices, fonts, and it's also the first part of User Experience. By gathering the current status of identity and asking the community to define a better brand for the product.

3. Identify current UX problems

  • Ask people, they know
  • How about some user testing?
Some UX problems may already be known in the community. Always ask the community first before asserting an assumption. Remember, assumptions are not good for UX. Data is.

4. Get UX into the integration loop

  • Make UX a phase of development
  • Get developers in the loop
  • Test everything
UX should be deeply integrated into the software development process, as in a continuous integration scheme. Do user testing for UI changes.

5. Prototype and discuss

  • A/B testing (if possible)
  • Test prototypes
  • Give UI coders a finished prototype
Once you get the prototype right, the widgets in place and the interactions in a well written spec, the task for developers is really easy.

6. Baby steps, small changes

  • Don't go for the full redesign
  • Propose small fixes
  • Minimize coding effort
  • Identify as many small problems as possible
  • If possible, code something and show it
What can be fixed through only CSS? What can be done with just a line of code? There are many UX situations that can be drastically improved by just a few fixes. If you have the skills, you can even show how a minor change would impact the UX in a browser window.

7. Find a team

  • There is people working on UI
  • Ask for participation
  • Identify potential "UX people"
  • Get coders, translators, users, testers
  • Create conventions and standards for consistency
Doing UX solo is not an easy task. You'll need tons of help from others. There is always people fond of UX and UI amongst coders. Some coders hate talking about UIs, but some actually love it. You can also recruit other kinds of people with different skills, to conduct a user testing session, to make prototypes, to translate things, etc.

8. Set goals and deadlines

  • Deadlines are the ultimate fast decision makers
  • Use UX metrics to set goals
No roadmap is a roadmap without goals and deadlines. Define sprints and use deadlines and milestones to give others feedback of what your progress is.

9. Show the larger picture

  • Build a longer roadmap
  • Get approval from the community
  • Be realistic
  • Review constantly
  • If needed, reformulate
A mid-term roadmap will build trust around your work and get everybody's expectations on the same page.

10. Avoid the "taste police"

Non-constructive criticism

  • "It feels weird..."
  • "I hate pink..."
  • "I don't like the font"
  • Ignore trolls and haters
  • Justify with reason and sources
You'll get a lot of subjective opinions specially after the prototyping phase, when design starts to look real. Beware of those really subjective things and justify your choices with reasoning, knowledge and of course, links to sources.

11. Adapt to the flow

  • Version control
  • Issue trackers
  • Languages (ruby, python, etc)
  • Frameworks
  • Contribution platforms
  • Mailing lists
  • IRC Chatrooms
Don't get into the group proposing new tools if you want things to go smoothly. On the contrary, learn where the contributors hang out, learn the current tools, platforms and frameworks used. Dive into the flow and get yourself soaked with it, until you become another member of the group. You'll know when you are. Don't be a solo warrior that comes up with magic solutions once a week. Contributing is not always making deliverables, or writing code. Discussing can be also contributing, teaching is contributing, helping others is contributing.

12. Use open formats

  • Educate designers on open tools (Inkscape, GIMP, etc)
  • Make assets freely available
As a free software advocate, I really encourage everyone to use open formats. I've been a closed format slave for way too long, and if we are talking about UX for free software, then why don't we do it for real and start using these formats.

What else?

  • It's up to you! Have any ideas? Share them.

A case study (kinda)

My first steps

  • Got advice (from Sean Tilley): get validation
  • Contributed a patch
  • Then contributed a greater patch
My very first contributions to Diaspora were some UI related patchs, but I was really anxious to explain why I though that we could do great improvements with little effort.

First proposals

***(open old and new diaspora site on tabs)*** I wanted to start making a bold move: a whole redesign of the Diaspora Foundation site. This goes against some of the UX methods I talked about in this talk, but it was good to set a starting point and get the discussion rolling.

Going back a step

  • Realized there was an identity problem
  • Get to work on identity first
  • Find out some identity inconsistencies:

    Helvetica vs. Roboto, etc

  • Started an identity project on github, made with Inkscape
With the Diaspora foundation redesign, I found there were some differences about identity in the community. So I decided I needed to help diasporians out and tackle identity first. Identity would give us the first choices on font, colors, and consistency.

Next steps (2015)

There are already some awesome guys working and giving feedback on UI, as Fla, Steffan, Goobertron, Augier, and more, so this is a great opportunity to do some planning. You'll find some of them hanging around on the Diaspora booth. Free stickers included.

Main drawback: TIME

  • Don't have money, have to work
  • My speed for contributing sucks
  • Don't have a detailed roadmap yet for crowdfunding
  • Also, crowdfunding can't be just for me
My contribution pace plainly sucks, I hope I could do better next year. I thought about crowd funding but I think it would be unfair to ask for money for myself. Right now, I think that we could do a crowd funding campaign once we set a good roadmap, some prototypes, and a UI team, then we can do a campaign to sustain the UI team as a whole.

An open UX ecosystem

everypixelhurts.tumblr.com

  • Building free software UX tools
  • Contact place for designers
  • Discuss sustainability
I'm trying to build an open UX ecosystem with the name of this talk: "Every Pixel Hurts". I have some ideas that I want to share with you, and maybe you can help.

Build free web-based UX tools

Coders wanted!

  • Invision-like clickable prototyping
  • User test recorders (screencast)
  • Design voting app
These are some tools that I want to turn into reality. Tried several free or closed ones in "free mode" but none do the job right. If you wanna join some of these projects, just say so!

Build a community

  • A place for designers to offer collaboration
  • A place for devs to seek for designers
  • Share knowledge, write articles
  • Teach about open formats
  • Teach about open tools (Gimp, Inkscape, etc)

Funding

How? How to raise money for this? Got any ideas? Please tell!.

A call for designers

Almost done here, I want to make a call for designers.

Ask yourself: what do you love?

Money or design?

Coders are really used to collaborating and sharing knowdlege and value. If you love design more than money, then there are tons of opportunities to collaborate.

A call for coders

Help designers to get on board

Coders have lots of experience collaborating and building stuff together. Let's try to help UX designers to get onboard of our projects, invite UX designers to join your team, mentor them to learn how to be a part of a free software project.
"Build free software for freedom, not propietary malware for cops." -Jacob Appelbaum

Conclusion

Doing UX for open source projects is pretty much about understanding how free software is built, how the communities work, and that is what coders know and designers don't.

Thanks!

Questions? Experiences? Feedback?Share it!

Sources:https://news.layervault.com/stories/29560-ask-dn-have-you-contributed-to-open-source-as-a-designerhttps://medium.com/words-about-design/designing-open-source-e3adc220cfa7http://programmers.stackexchange.com/questions/87994/how-can-open-source-projects-be-successful-without-documentation-about-their-deshttp://www.jefvanschendel.nl/blog/design_in_open_source_project_and_my_experiences.htmlhttp://web.archive.org/web/20080805012124/http://mpt.net.nz/archive/2008/08/01/free-software-usabilityhttp://web.archive.org/web/20081122141629/http://web.archive.org/web/20030201183139/http://mpt.phrasewise.com/discuss/msgReader$173http://smarterware.org/7550/designers-women-and-hostility-in-open-sourcehttp://www.markboulton.co.uk/journal/design-in-open-sourcehttp://factoryjoe.com/blog/2008/01/03/the-problem-with-open-source-design/https://wiki.diasporafoundation.org/Branding Paper: "Designers wanted: participation and the user experience in open source software development" (Microsoft Research)