We welcome everyone to join us in connecting with people to promote and improve open source design. We value learning and sharing freely through both our processes and results. Come and have a good time, exchange ideas, and solve problems with us. Chat about remote usability tests on a budget, or how one could involve an online community in the design process. We might also discuss the trade offs between various open source tools, or brainstorm some ideas to promote libre design projects to university students. The possibilities are endless!
Q: Do I need to be a programmer, designer, [some other role] to participate? A: No, interest in design and in sharing your process and results with others is enough.
Q: What does the “open source design” mean? A: It means that we aim to share process and results of our design projects for others to learn from and to build upon it. You can see it in contrast to a secretive, non-collaborative design process which often results in things that are not licensed in a way that others can reuse and build upon the work.
Q: Is this constrained to Mozilla products and services? A: No. Mozilla is involved (and donated the space!) but there are other projects on board, too. Everyone and everything is welcome!
Q: What do you mean by design? A: We mean it broadly, encompassing activities like need research, interaction design, graphic design and usability testing.
Looking forward to seeing you soon!
Link on meetup.com
Date & Location
- Date: Fr. 15th March 2017
- Time: 19:00 - 22:00 (UCT +1)
- Where: Mozilla Berlin Community Space - Haus 12, Voltastr. 5, 13355 Berlin, Berlin, Berlin
Notes taken on etherpad
Attendees: Jan D, Jan M, Peter, Heiko, Hernan, Charlie, Sam, Michael, Ettore, Amin, Tobias. Did I miss anybody?
Goals of this meeting:
- how can we build community for usability/design people to support each other?
- it doesn’t work so well to integrate design & usability ideas into traditional (code-centric) open source projects
- how can we create a more neutral field for non-code contributors to take part?
Jan Muehlig talked about his own experience of successes and failures in regards to bringing usability concepts into F/LOSS projects - many different research projects were undertaken (eg during the Season of Usability, though often efforts fell short when it came to developers actually implementing the lessons learned.
Stumbling blocks were often the code-centric culture of open source - a ‘contributor’ is someone who writes code - that is the traditional way into a community of trust and collaboraion. There was often no way in for UX or other non-code contributions.
Various hurdles were discussed - one interesting aspect of F/LOSS development is that there are many mechanisms to ‘add’ features… but none to ‘remove’ them! The idea that ‘the bigger the buffet, the better it must be’ prevails and leads to bloated, confusing, awkward jack-of-all-trades software.
Sam shared an example of successful community integration / transition from Kdenlive, the video editor he relies upon for work. For many years almost all of the code has come from only one developer, Jean-Baptiste Mardelle - and as you might expect, he burned out and almost left the project for good back in 2013. But in the last two years there has beeen a resurgence of enthusiasm and activity around Kdenlive, led by a small group of active users, design and documentation contributors, together with JBM and other programmers, focused around informal IRC chats called ‘Kdenlive Cafés’, in which technical and creative aspects of video editing are discussed, as well as use of the software, bugs and features, and the progress of Kdenlive as a community and project. ‘Bug squashing days’ were organised with different roles for different technical abilities, and strategies to bring in more developers were fleshed out. This helped form a sense of community and shared stewardship of the project, got it out of a rough patch from a development, and made clear to everybody what value there can be in non-code contributions. Obviously this is a special case because a sole-developer at the point of burnout creates a power vacuum which doesn’t exist in many other F/LOSS projects, but I think the not-entirely-technical Café can be a good way in for non-code contributors even within traditionally code-centric projects.
We talked a lot about user testing, and differences between the open and closed worlds. eg Amazon is constantly A/B testing, netflix too - gathering customer feedback all the time as well.
There’s a common myth that user testing is all or nothing - you either have a uni research team with proper lab methods, or not at all. But even flawed user prototyping (eg testing on your own team) can be useful in a way, even if it’s not optimal it’s better than nothing (as long as you acknowledge that it is flawed).
Jan D.: read on paper prototyping, discount usability testing or guerilla reserach if you are interested
A question was asked about the 2007 example of InGimp as a way to automate user testing:
Peter was working with Gimp at the time, so could offer some insight:
“ingimp was an interesting but flawed experiment. It didn’t work because you don’t understand the data. You don’t know what someone was thinking when they clicked there - was that long pause because they didn’t know what to do, or because they got a phone call? Quantative data without context isn’t much help.”
However, some group members advocated for using such quantitative data, but not as the only source used for development.
elementary, gnome, nextcloud as positive examples of design-inclusive communities. usually these are the newer projects.
We discussed more radical approaches… “ok, I have a stupid idea… what about a governance fork to force culture change?” maintaining the same codebase - with a different set of values. “I can make your idea even worse: parallel maintainership - code on one side, design and usability on the other, wiith consensus needed before a release.”
Ok, we need to have a meeting together with developers to talk about this topic. Try to understand difficulties on both sides and start something together.
We then split into 3 groups for more focused discussions:
What do we have? What are we missing?
- Justinmind is interesting but closed source
- Jan D. uses draw
- Is paying for tools ok?
- Pidoco for collaboration (closed source)
- Not the tool is the problem but that the format are not free
- Jitsi, Hangouts for the process
- Writing on an image of the screen while user testing (highlighting) may be a cool plugin for jitsi
- Extend etherpad
- Bugzilla “broke down” when UX Bugs were involved
How do we engage UX & design people with OS, and vice versa? How can we build a community around this idea?
- How can we counter fears of Designers
- Just take my designer
- I cant code
- How can we organize a community
- How can we define a common interest
- Projects-Centric? UX? Visual?
- Documenting Knowledge as a culture
- Best practices
- Build up experiences and skills
- Making it accessible
- Matching people with projects
- Incentivize being part of the community
- Learning and failures
- Code of Conduct for projects that want to collaborate with the community to protect the community
- Community activities
- Communicating the mission
- How do people get to know about us
- Need for funding, having a small hackathon etc.
Diversity on the “simple” level of “it is not just code” AND it may also be a step into the direction of “there are any different people / approaches to add to our projects”
- Elementery attracted people who were interested in BUILDING and DESIGN https://.twitter.com/elementary/status/842462739536719875
- …but maybe they have a core group of people, onboarding not very visible
- Gnome: Redshift had a well structured dialog between the design oriented community members with the developers
- JASP may be an example for another successful tool: they want to build a statistics application that can be used by beginners. One incentive is that they want to make an often overlooked branch of statistics, bayesian testing, more visible (and better taught). They are backed by unis, funding and statisticians interested in education. Jamovi is a more feature oriented branch,
- They documented best practices e.g. what they did if something could not be implemented in the GTK lib
- As a dev you get in contact with other peoples code; for designers it is very different; designers could do it differently
- Maybe templates for people to express theri ideas. Could be visual, resources etc.
- An dev can build upon libs by others. Can a designer build upon?
- A treasure trove for designers
How can we build and integrate a non-dev community? to recruit/onboard/make them happy.
- open usability: tackled universities
- usability professional association:
- take real issues to universities.
forum/exchange platform want to get out of cocoon, and widen his vision, and do design in a big process. where were they successful or didn’t succeed.
- how can we define a common interest?
- how can we organise the community?
- how can we make a successful onboarding process?
- how can we incentivise being part of the community? engage people
- how can we counter fears? identify them as well
- how can we build up and spread FOSS experiences and skills?
- how can we document UX knowledge?
- how can we match contributors with open source projects?
- Code of conduct for projects
- Permanent learning from projects including failures.
- How can we fund the community activities?
- communicating the open source ux movement. advertising. how do people know about us?