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.
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.
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. )
General Code of Conduct http://opensourcedesign.net/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.
Attendees
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:
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)
FEEDBACK PLEASE!
-what worked
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. disqourse.opensourcedesign.org
* 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
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?
Is it relevant for you?
Do you have tips/experience to share?
Compare onboarding processes for designers across various projects (Simon & Jan C)
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.
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 https://balsamiq.com/ is works well. Also tried Justmind https://www.justinmind.com/ (great because of integration of requirements engineering), Axure https://www.axure.com/. 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 https://pidoco.com/ is a great tool as well in comparison to balsamiq
Workflow 4: pretty similar to Workflow 1, drow.io 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: https://gitlab.com/cameralibre/FragDenStaat-Animation
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:
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 https://ind.ie/ethical-design/, this:
ethnical design manifesto: https://copenhagenletter.org/
Terms of service summaries: https://tosdr.org/
Engineering security: https://www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf
Changing legislation against lobbyism: https://en.wikipedia.org/wiki/Lawrence_Lessig