Open Source Design Summit Notes

(Elio Qoshi) #1

Hi there!

Live from Open Source Design Summit in Berlin here. Sharing the etherpad with notes and schedule from day 1. Please write down any questions and comments you might have.

(Jan-Christoph Borchardt) #2

Copying over everything just in case the pad goes down or otherwise gets lost. (Except the Open Source Design manifesto part cause that’s already in the manifesto topic. :slight_smile: )

Open Source Design Summit 2017 - Berlin, Germany

General Code of Conduct

Summit guidelines
* Be mindful of when you speak too much and let others contribute too
* Encourage those who have not spoken as much to contribute if they feel comfortable
* Be respectful of others
* Raise your hand if you want to speak while someone else is speaking

Social media
* Hashtag: #opensourcedesign (no specific Summit hashtag)
* Please don’t post photos on Facebook without explicit permission from everyone. Twitter, Github, IRC, Discourse are ok as they are our usual channels.

1. Ecaterina Moraru (XWiki)
1. Elio Qoshi (Ura, Mozilla, Tor)
1. Jan-Christoph Borchardt (Nextcloud)
1. Victoria Bondarchuk (Valentina Project)
1. Jan Dittrich (Wikimedia)
1. Tobias Bernard (GNOME)
1. Charlie Kritschmar (Wikimedia)
1. Hanna Petruschat (Wikimedia)
1. Andreas Nilsson (Red Hat, GNOME)
1. Julian Sparber (Developer)
1. Sam Muirhead (Open source animation)
1. Simon Vansintjan (OpenFarm)
1. Alexander Bezzubov (Apache)
1. Johannes Landstorfer (IXDS)
1. Federico Sarchi (Data journalist)
1. Claudio Agosti (Developer & project manager), day 2
1. Heiko Tietze (LibreOffice), day 2
1. Brennan Novak (Transparency Toolkit), day 2

Schedule DAY 1 (Saturday)
* 11:45 – 12:30: Open Design Processes & best practices (Andreas & Jan D)
* 13:00 – 14:00: Lunch
* 14:10 – 15:00: Analog! Open source collaboration workshop. And: Teaching open source to designers (Sam)
* 15:05 – 15:50: Community design process. How do we keep designers happy. Burnout? (Elio & Simon)
* 16:15 – 16:45: Can UX research be open and distributed? (Victoria & Jan D)
* 16:50 – 17:30: Compare onboarding processes for designers across various projects (Simon)

Schedule DAY 2 (Sunday)
* 11:00 – 12:00: Design debt (Jan)
* 12:00 – 13:00:
* Website: Job board discussion continuation? Also copy to Discourse as more interactive platform?
* Workshop and Discussion: Education (Heiko)
* Identihub (Elio)
* 13:00 – 14:00: Lunch
* 14:10 – 14:50:
* 14:55 – 15:35:
* 15:35 – 15:45: bit longer break
* 15:45 – 16:25:
* 16:30 – 17:10:

Notes DAY 1 (Saturday)

Unsolicited Redesigns, Designs that change eveything
* Change all
* High cost & investment for both the developer and the designer
* Infeasable and will require multiple iterations
* Done as portfolio work
* Not collaborating - both from the developerr and the designer
* One solution is proposing something smaller
* Don’t discard it as a new perspective
* Documentation
* Give reasoning for design
* Time to implement
* Connecting new designers and enthusiastic designers to the right people split
* Are skinning / alternative designs / options / configurations ways of mitigating issues without being actual solutions?
* Designs involve making a decision.
* Process
* Document
* Discuss and give feedback
* Discuss whether it’s something that the product wants
* Contributing guidelines for designes
* Small design tasks
* teach the process / accomodate
* File an issue but add a design tag
* keep the relevance
* be descriptive
* cultural: both design & development are on teh same level.

Open Design Processes & best practices (Andreas & Jan D)
* Lot of cases where people show up at a project and present a mockup for how it should be better. Everyone acknowledges but you don’t get anywhere. Ultimately it isn’t done → Instead start with a need, a scenario.
* Features requests happen: feedback just go in circles and people don’t care
* It’s often unclear who is the decision maker or “Gatekeeper”
* Voting or convincing
* Classic designers make the mistake to make too big of a redesign, makes it impossible to break up into small parts and actually work on it.
* You need to write a specification of the design, not only make it a static mockup
* Make design a regular value
* Building trust between designers and developers
* Time frames - how much to spend on research, how much on mockups?
* Handover from designer to developer

Gate Keepers (Group 1)
* code maintainer
* ux reviews
* design owner is with a company often. (Business pressure for good design)
* the cases where in design driven communities
* if the developers works for the same company as the designers, a manager above both decides in the end, but hard to do in a community of volunteers
* in wikimedia - if a change is to happen, it needs to come from the community (community of writers, automation developers).
* there is a wishlist created by users
* voting on things
* at what point do you decide on a critical mass. If 80 people of one million says yes, is that a yes?
* afraid to create a shitstorm
* in GNOME, there is a design team. There is a larger vision. A lot of feedback from users, sometimes bad.
* when people are used to a thing. It’s hard to change
* important with trust. It’s build slowly. Have a relationship over a longer time.
* Designer X needs to prove himself/herself with design.
* Everybody thinks they can do design.
* You need to frame things in the value system that people already have. (Example: a developer wants more users, make a design and prove it gets more users)
* In GNOME, it worked to do usability test and prove that things were unusable in version 1, Moved towards ui-review and more usability thinking in version 2, Moved to design first in version 3
* People shifting from developers into a design role instead, they already have the trust
* Create a framework for making the design process less magic

Gate Keepers (Group 2)

* Benevolent Dictatorship
* Debatability
* FAQ + Vision
* Relative "What is best"
* Valued Skills
* encourage voicing sharing opinions and have principles to change them

Analog! Open source collaboration workshop. And: Teaching open source to designers (Sam)
-what worked

  • Very hands on and felt cool to take other people’s work and iterate on it.
  • lots of things to keep track of. Hard to learn.
  • was fun to think about it in a different way, especially with the »fixing issues«
  • got a high level understanding of the different aspects and tools of git
  • to see people working/collaborating/be in action showed the most valuable aspect of git which usually is just visible be comments in a thread. I think this is a very powerful aspect to newcomers
  • what didn’t
  • Did this work for me because was already familiar with how git works?
  • No instant gratification at the end of what we created together.
  • Very little time
  • I was very focused on the content which stopped me to understand the aspects of git in full detail
  • new ideas
  • simplification of some of the steps - licensing necessary? does it convolute the things to learn?
  • would be cool to actually use this to explain git or version control. Although it might be a bit offputting cause it’s so chaotic :wink:
  • I could see three different levels/versions for this workshop: 1. absolute beginners just work with the structure of git without heavy content – stick to the smiley here, don’t ask for content as this drags the focus of the actual task (understand github); 2. use the workshop to get actual input on a topic like barriers to Open Source Design (like you did with us). The focus then is not on how to use git anymore I think; 3. Include licenses and force people to actually work in the restrictions of the selected licenses.
  • have posters with short explanations what to do at each station. Use the actual github layout (as the real explanation or just as a reminder for later) to make the connection to each step on github

Community design process. How do we keep designers happy. Burnout? (Sam & Simon)
* If there’s someone interested in contributing design, how do you keep them interested?
* How do you create a community that is design first?
* How do you make sure those designers don’t fight an uphill battle against devs who have their own interest in mind (which is fair)?
* How do we make connections between designers and developers when it’s a relation that keeps on thriving.
* Go around and share experiences of where their work wasn’t appreciated
* Open Source design are the connectiors between open source projects and new designers. The job board is that gateway that helps to scale beond us. Bridges a gap.
* We get more people on the forum. A place where designers and developers meet.
* It’s often designers vs. designers. Is this really the gap? It could also be newcomers vs. senior members. Senior people are often developers, due to history.
* Better to talk about contributors, rather than “developers” and “designers”
* Some projects don’t want to use our infrastructure, but rather get hold of a designer, and then do the whole process on their infrastructure (as part of their regular workflow)
* It’s better if you have a support network from other designers on the forum.
* Move the job board discussion to tomorrow

Personal stories:
- For greeting people: A bot doing it or people doing it? It could be interesting to look into Wikipedia where there are strong discussions around that practice (currently: English being pro-bot, german being anti-bot)
- simon had a script to get resources eg code of conduct etc. someone had a tool to analyse how accessible/welcoming a project was to newcomers. But it was obviously automated - he felt appreciative that people were trying this, but didn’t like that it was obviously a bot that did so. “the first face I interact with shouldn’t be a robot”.
- look up the camel story online.
- elio was not appreciated: “i offered to design a new logo for a project, they reacted as if I was spamming them.”
- the process of offering design work is different to contributing code - with code you sometimes just submit a PR (jan-d: is that always taken? jan-b: No it is not taken)
- K-9 Email logo: they were convinced to change the logo, but they still haven’t accepted the PR

  • there is an (unwritten?) requirement that a designer is part of a project and its culture before their work will be accepted. (jan-d: being known = being trustworthy)
  • however, there are better or worse onboarding processes for os projects.
  • communities have their existing culture and even if a new idea is ‘well designed’ - you can’t just tell them their existing approach is wrong if they don’t know or trust you.
  • a good way to start is to file a lot of little issues. “After months of using, here is a problem I have, what do you think?” Getting to know people. ←look at
  • People like to be listened to, so doing some user research makes people happy.
  • kdelive has a small and active userbase. Logo was bad, lots of design proposals (with varying quality), made it an interative process on the forum going on for months, successful in the end.
  • Tobias gave a talk at GUADEC saying ‘hey you need better animations, that make more sense’ - a couple of months later the effects could be seen in applications.
  • Open Source projects seem to trust users more than designers. Best start from the perspective of a user and open issues about your experiences. Get involved slowly and don’t immediately suggest changing the logo. :wink:

The job board. We don’t have any
we don’t track what’s going well
we don’t have best practices for different personas
* If a developer needs something.
* Outreachy
* Hobby developer

Can UX research be open and distributed? (Victoria & Jan D)

  • Do you do UX Research?

    • Simon worked at a ux agency for 2 years and it was awful, no sharing info about process etc. managers had too much control, their clashes broke the process.
    • Jan B has some experience, mostly usability testing. the problem is time and priorities.
    • Hard to get buy in from the rest of the team. Helpful for the designer.
    • it can be hard to find volunteers - you need to find relevant users. for OS projects it can sometimes be hard to define their target group.
    • research done on Mailpile by SimplySecure - great work done for OSS. Not only testing single features, but wider questions
    • Andreas says he was surprised that user research was actually a lot more straightforward and easier than he was expecting. Because in his can the target group was quite general, he coul ask family & friends. the problem was the sample was mostly swedish people, and many interviewees who were his brothers!
  • Is it relevant for you?

  • Do you have tips/experience to share?

    • Jan B did research with uni design students – who organized the participants and conducted the tests, which was a great one-off investment - they learned from it, and Jan got results.
    • design systems - lots of work to maintain documentation
    • Andreas made sure to run the questions by the developer first, to help ensure that the results would be relevant to the project.
    • Jan did design resarch for Ubuntu. 12 tests on Shotwell. 2012 in London. There are people who are good at testing. You just need a test plan that the developers of the project buy in to. File an issue in the tracker for each issue you find.
    • It’s important to get the questions right. Making it super-scientific is less important.
    • 5 people will give you coverage of 80% of the issues. – Jakob Nielsen
    • evalica says the focus for user research should be newcomers - victoria say it can ask/answer many questions.
    • sometimes user research can also prevent a feature being built - if it is proven that it isn’t useful, this is a great outcome! time/money/frustration saved.
    • once you are past the ‘scratching your own itch’ stage, user research becomes even more important - you can’t just guess how users will interact with your project.
    • usefulness - does this solve a problem
    • one problem is that many projects started as that ‘scratch your own itch’ kind of project, and hen grew to have users, but the culture remains the same.
    • About Face by Alan Cooper - qualitative research. What kind of needs need to be solved. Figure out via interviews.
    • “How can I trust it if it’s 1000 opinions from 1000 users?”. “How can I trust it if it’s not 1000 users?”
    • User research is important in building empathy with the users of the product among the development team.
    • Bring the engineers to user testing sessions.
    • How to publish videos? How to respect privacy?
    • How useful are actually videos for the community? Maybe just the data is enough, because very few people will watch them all.
    • The beginners guide to User need finding - good book!
    • Coordinating low-cost usability testing in free & open source software projects
    • How to publish so that other contributors make sure to read the data. Not too short, but not too long? → open an issue for each problem

Compare onboarding processes for designers across various projects (Simon & Jan C)

  • Elio gives example from Mozilla: They have a repository where people can request designs and tag it with different design disciplines. LINK??? Also have a Telegram / IRC channel with 270 people but only ~3 are active.
  • Not necessarily an only-for-onboarding page:
  • Nextcloud: Has a design page Having that page and the design tag gives a lot of visibility to design. Talk to developer and teach them design. Starter issues are very important and useful to get new people involved.
  • XWiki has a separate tracker for designs, it’s often crosslinked to the issue tracker.
  • Wikimedia doesn’t really have a structure like that. Code is on Phabricator and only sometimes community members look into issues there.

Notes DAY 2 (Sunday)

How do you deal with making decisions in communities with many voices, mostly volunteers.

  • in wikipedia, everyone is very oppinionated, even if it doesn’t affect them, and if it’s a page that doesn’t have a page that not many people see.

  • community do pushback, and no good way to move forward.

  • Hackathon, random group of five people. Other computer science developer. Nobody could create a good project. Tried to figure out what to do. One guy gave really back feedback. A developer created a design a thing that would cover every single possible usecase possible.

  • Others tried to simplify the thing, to create something that was possible to present.

  • the guy left the group in the end, but everyone else was happy, and the team won the hackathon.

  • is it risky/ok to kick out one or two messy people in order for others to thrive?

  • someone toxic could still be a very productive contributor.

  • Where is the critical mass of people leaving a projecrt?

  • One contributor had a very rapid response time, everyone else was slower, it made that persons voice very dominant. Hard to wait for the others.

    • How do you handle different speeds in contributing, so one is not “demotivating” others to contribute (because somebody already took care of that)?
  • The wikimedia UX team. “Can you describe a situation where that was difficult for you?” got very good feedback out of that

  • One design expeirience. An existing community intergarting with an event. It was tricky to do design collaboration async.

  • the goal does not have to be consensus - but rather trying not to have anybody really unhappy with the process - when somebody is angry about something, try to recognise that and understand it
    sometimes you will not be able to convince everyone. and sometimes people criticise a project even though they are not actually users of that project (eg GNOME)

  • if there is a decision where they cannot find a concensus, they postpone smaller issues for later, so the process doesn’t get stopped

  • problems got solved because things can get tested, you get more data. Water under the bridge, and people get more time thinking about the problem.

  • When people know each other faces, it’s easier. Easier to discuss things in person, rather than on a thread.

  • Some communities have good ways to discussions on small details that don’t matter as much. “Great idea, but it doesn’t matter as much, so let’s discuss that separatley, so to waste one minute (one person) rather than eight minutes (eight people)”
    there are assumptions that are untested and untestable. eg. Many people say it’s bad if people make an article for their school band- it will lower the quality of wikipedia. But this is a cultural assumption which has never ben tested!
    There are still ways to collect useful data for testing without having to track users (creating privacy issues).
    participatory design does not mean that you need the community to do the actual design work. you can just get the perspective of the whole community, and then channel those perspectives into a
    design solution. Particpatory design also comes from a workers/citizens vs bosses/government history.
    *Libreoffice try to do surverys, quick polls. Good for the community, but bad for the product. The product would be better if there was one person that could point with the whole hand, but bad for the community.
    using the example of city planning, if a council wants to build a bus stop, they will seek input on the need for and the location of the bus stop. There is an understanding that the design of the bus stop itself will be left to the bus stop designers.
    there should be multiple channels for feedback and input to ensure diversity of views.
    is it really true that we do the best for everyone? can the community/participatory design process work?
    elementary OS is an example of more of a ‘benevolent dictator’ approach to open source design.

Free software design tool from the future
Devolop a free design software to get designers involved in free software (Who was first? The hen or the egg?) (Feel free to rewrite)

Everyone talks about their workflows and tools and how that could be improved.
Where is free software design tooling. How can it be improved?
Open source tooling, less interesting to talk about the Best Tool, but would be good to make a clone of a good existing tool (Invision/Sketch) would be so much better than anything we use now.

Workflow 1: Sketches, put them in some sort of digital tool with predefined components so he doesn’t need o set up his own library, grouping is terrible evrywhere, then do a prototype (Figma and balsamiq are ok)

Workflow2: before sketching, take notes of what’s needed. Sketching first, but sometimes skips that step. Figma, Sketch, Illustrator. Don’t use predefined components too much, set them up myself. Prototypes are tricky. Use Aftereffcts sometimes, the other tools are lacking. Incredible detail, means that you are incredible overwelmed.

Workflow 3:
* use the prototype tool to describe an idea. What you want acheve. Doesn’t matter too much about the tool.
* Balsamiq is works well. Also tried Justmind (great because of integration of requirements engineering), Axure More features, but less comfortable.
* Glade has some problems. It makes no sense to put two buttons above each other. The output is more useful for developers. Ancoring is important. Works better in other tools.
* Cooperation is an important aspect. Create wireframes together and collaborate on the output together. Pidoco is a great tool as well in comparison to balsamiq

Workflow 4: pretty similar to Workflow 1, is a great tool, bit buggy but it’s great for collaboration, inkscape

Workflow 5: prefer to modify the ui-files directly with a text editor.

Workflow 6:
sam uses git to track changes in SVGs and animation projects:

  • But gifs and reference images to be created manually so that I/ other people know what a particular project contains.
  • There is no visual diff tool.
  • there’s no clear way to structure the project to make parallel versions in different styles and languages stay up to date with each other.

Renderchan - tool for managing the dependencies of an animation project

Download just the project files - not the gigabytes of rendered PNGs. Then renderchan looks at the video project, finds its dependencies and renders all the animation files referenced by the project.
Any time you then run renderchan it checks to see if any animation files have changed, and renders new png sequences/videos from it. It also creates thumbnails/video previews so that you know what an animation project contains.

Project Elmyra - keep (hardware) product renderings updated with a blender plugin. Update the hardware designs? bam! the renderings on the website are automatically updated. Designers can easily make their onw product photos from the always-up-to-date renderings.

Workflow 7:

  • sketch by hand to be able to redraw quickly,
  • bring things into inkscape – mostly copy from earlier drafts,
  • draw little arrows between screens to illustrate behaviour,
  • export as png then put in on git, refer to different versions,
  • unsatisfied with posibility of interactions: have to write down everything, a lot of things have to be explained in detail which takes a lot of time

Workflow 8:
works with a software architect, also requires tools to explain flow
uses collaborative tools (UX Pin and others)
missing: a collaborative tool with version controls
versioning is a sensitive topic: how do people understand versioning?

see google docs: mark things and comment rather than describe it
look at cad software, e.g. fusion 360 to get an idea about histories. maybe you can have things that are applied to elements, e.g. flat design applied to all elements –> keep elements in place but remove flat design

Fill mockups with data is a problem
constraints in sketch are nice, aydding padding etc, but it breaks a lot of time
it would be great to move away from the bitmap way of doing things.
Not so much collaboration at the exact same time (accidently delete stuff or so) but bounce things back and forth is interesting
having propper commit messages (“I changed xy because of z”)

it is hard to just copy everything and then work on a copy if elements are linked or cloned
it would be good to have a glade-like abstraction (except good) which would cover 90% of cases, and then a visual design tool would be needed less.
the structural things (like in balsamic) should not have too many impedements built in as constraints.
it can be difficult to build in helpful constraints when so much of visual design is focused on being able to make quick direct changes.
if the goal is to make the UI toolkit as easy as possible, then why not let the user design their own UI?
is there really such a difference between customizability and design.
is there any reason why real-time online collaboration on design might not work?
andreas is less interested in real-time collaboration on design - even etherpad is annoying sometimes. but the abilitiy to bounce ideas back and forth and quickly iterate would be really valuable.
in a gdocs context, you don’t generally edit the same sentence at the same time. so there needs to be some way of ensuring that designers don’t clash and work on different things.
in gnome we started becoming more cautious with their commit messages, explaining the changes.

Ethics in UX
Look at, this:
ethnical design manifesto:
Terms of service summaries:
Engineering security:
Changing legislation against lobbyism: