The user in the cultures of UX design and open source
Dittrich, Jan
Collaborations between open source projects and designers are difficult. Instead of focussing on a lack of tools or skills, I want to show that the difficulties are also rooted in different views on what makes a "good" user and a desireable mode of collaboration. Open Source projects, prototypically, focus on the developer/user who scratches an own itch and coordinates in an stigmergic, bazaar-like way, while design usually focusses on expertise in designing for others and a plan/execution model instead. While no easy fix can resolve these differences, I want to suggest some ways to ease communication for developers and designers.
 Hello, first time. My name is Yann Ditte. And in this talk, I want to talk with you about the user and the cultures of UX design and open source. Design and open source projects seems sometimes pretty hard. And different reasons for that have been suggested that maybe designers should learn more good or that the tools are lacking for designers and so on. And I think those are all very valid reasons. But I think we should also look at the differences in cultures. There might be different values and different practices that people are used to doing. I'm going in with a closer reading of two seminal texts of those disciplines. And the first of them I took as example for open source development and open source projects is Eric Raymond's The Cathedral and the Bazaar. And for UX design, I took a text that I think many would say sort of the seminal text of UX design, which is Donald Norman's The Design of Everyday Things. And in those texts, both talk about users. And I think it would be very interesting to juxtapose those two and look at sort of their different conceptions there. And I think the most striking thing in the Cathedral and the Bazaars is that the user and the creator are the same person. And this starts at the very first idea that is conveyed about the user and the creator. Every good work of software starts by scratching the developer's personal itch. This is like the first principle that Eric S. Raymond puts forth here. Developer sees a problem that they themselves perceive and they go to solve that problem for themselves first and foremost. And this is what, according to Eric S. Raymond, every good work of software starts with. But this theme also continues. There will grow a community ideally around that open source project. And this then continues this topic that the users of that software should be treated as co-developers as the best and most efficient way to improve your program. Code improvement and effective debugging are called here as the major concerns that are connected with that. So your project is growing, treat users as co-developers. So here you have user and creator as ideally the same person creating for their own need and use and in attracting other similar people who are also co-developers slash co-users. And now we will look into the seminal text of UX design that I picked here standing for this discipline of UX design. And this is the design of everyday things by Donald Norman. And here you see very clearly that user and creator must be different. And Donald Norman suggests there is a difference and creators often become expert with the device, but they might not become experts with the task because this is what the users are doing. So you have like a strong difference here, like your creators, experts with the device with the technology and users being experts in the tasks that should be done. And that this goes into the organization of the whole project and that like teams of creators need a vocal advocate for the people who will ultimately use the interface. Norman says they tend to simplify their own lives rather than catering towards the specific needs of the users in the situation of usage for which they are experts as we learned in the previous slide. And the only way to find out if your product works is to test the designs on users, people that are similar to the eventual purchaser of the product as possible. So you should find people who are similar to those people who will use the product in the end and try prototypes and ideas with them in order to have this counter checks towards making your own life easier or being too much of an expert with the device already and not seeing anymore what is important here. So this is like a topic that is repeated in Norman's works but also in works of other usability and UX thinkers that user and creator must be different and that you shouldn't have the idea that you're as omniscient to say that you know what users want. You need to check that you need to be suspicious here. Using user and creator is bad. Different expertises in those roles is good. So here we have those in contrast. You have the idea that in the cathedral and the bazaar users are ideally the same person they creating for their own need and use they scratch down on it and they will attract other similar people and in the design of everyday things you have different expertises between user and creator who have different interests as you saw and people tend to make their own lives easier rather than the users. And creators does need to learn what helps users by empirical methods. They need to do the research. And this also assumes a certain context in which the product is created which is for the cathedral and the bazaar a community of like-minded user and creators who can collaborate and who can code. And in the design of everyday things probably assumes an organisation with somewhat of a division of labour and that organisation being dedicated to creating products that are probably bought at some point. Those are very different contexts. So some things that might seem obvious for one side might seem weird for the other. So just building a feature that seems interesting might be great according to the ideas that are put forth in the cathedral and the bazaar but for UX designers might seem somewhat strange or problematic. And testing with users before building anything, trying that slowly out instead of just coding and seeing if it works for you might be a problematic idea towards a developer in an open source project at least if you follow the cathedral and the bazaar ideas here. It's like probably not that much fun. You need some resources to get those users and you don't have this user creator in unity. And you see that also in how UIs look. And I think the best UI if I may put forth so far an open source project might actually be the command line. In the ideas how people should work together this might be a really good UI for that work because you can for example add a parameter or code another program from the command line without cluttering the user interface. It's really good. You can have a lot of options in a rather minimal UI that isn't clattered by all those functions. And you also have a lot of possibilities. Adding parameters, calling other programs on Unity can also pipe that gives you a lot of freedom to develop for the command line and have your interface there. So it's easy to modularize but as many designers will tell you it's really hard for users but because you don't see what you can do and this is the advantage for modular development because what you can't see can't clutter the interface but it also makes it hard for beginners. So looking at an idealized UI maybe from the view of UX designer as a suggestion look at applications like some Mac applications or here I think sort of elementary OS is like a good embodiment of that idea. They are hard to modularize but they are very good for beginners. So if one coherent UI it works like you know like it's based on standards there's few experimentation it's rather coherent and adding a button would be like quite a political thing that needs to discuss through and through. It's like not very flexible there is one coherent concept. So this clashes quite a bit with that idea of like-minded users scratching their itches and adding by that to the project. So a curious thing like what is modular about user interfaces, graphical user interface icons and so like a lot of open source design and some projects is like redesigning icons and people do a really good job here. I think those icon sets from LibreOffice are pretty great but one reason why that is also so popular among designers in open source projects this is one of a few things where not of a lot of code made by other people needs to be changed but this is a modular aspect about interfaces that can be swapped out easily. So this is very attractive in the sense to work on that does. One thing that would be pretty interesting I think would be boundary objects like things that both disciplines can work on and with together and I think there are some that are quite well suited for the work of open source development and designers and I think that would help with some small wins here. And the first thing I want to suggest is having like an interface guideline for your project. Those are rather elaborate documents in which there are suggestions of when to use which UI element when you design interface. They were pretty popular in the 90s for a good reason because UX design as a role wasn't as widespread then and they are I think really good. Like the main thing would be picking one for your project just take care that they really give like specific advice. Particularly the Windows ones are good I think in specific advice. Here's a screenshot from the Win32 guidelines. So they clearly show here like what a balloon popup should be used for and what not and what different parts it has. And it's like very clear even if you are not a designer you can understand when you should use it and why not. So interface guidelines. Don't write them yourself just pick one again slight constraint of your creativity but it's really useful also as a coordination mechanism and they often lead to really good interfaces. They are written by really clever people who have thought out this stuff. Design systems are a bit more on the technical side basically UI elements and how you combine them and in contrast to user interface guidelines there are rather popular web projects that have a stronger variety of UI elements and particularly of visual styles. And there are some systems like Storybook that bridge really well to the written code. Here you see your design system I worked on for our donation page. It's like just a little design system it's not super elaborate. You see here like on the left are the single elements with the spacing and some advice is then in the comments and on the right is a page assembled from those elements. So you have a lot of like basically like Lego bricks how you can combine them in that final design and not every time like sort of you call it designer or new. You have your bricks already ready made. The third and final one would be extendable UIs which is a coherent mechanism for UI extension and an API. So you see like there's an UI concern and then there's also like a programming reflection of that because one big problem is like when you are flexible when you add stuff it often makes a mess out of that program that's like things added on top and on top and on top and it's really hard to keep that under control. Also you don't want to shout at people as I know that function is not really worth like building in for a lot of users just don't do it so a better way is maybe having that as an extension. If the extension is really really popular you could like still make that an official part. Firefox and Chrome do that really well. You have for example this part in the upper right hand corner where like projects can have their icons and if you click them you get sort of a mini that view they control but they can't mess with the rest of your UI. Pretty good. I think one little problem here is those pop-ups sometimes look a bit messy because everybody does their own style of that. What might be better if you already give them a kind of design system for those extensions. Here's the Jmovi statistics application that already gives you like useful for statistics UI elements for your extensions and those extensions usually look pretty good. Visual Studio Code is pretty good at that. You have like on the left hand side the sidebar where applications can put things into. Those are I think pretty nice projects. As for the Recap even though they have quite a part of shared history there are rather different views of what a user is and should be and how to work with them among UX designers and among open source developers. Even the open source culture as put forth at least by the Cathedral and the Bazaar you have like this experimenting user creator and a community similar to them and in UX design read from the design of everyday things you have this idea of designing for others and finding out what others need by empirical research. My suggestion rather than trying to change one or the other and going into like some sort of educating them look at what shared objects could help the collaboration. I think interface guidelines are really great. Pick one that gives you very clear advice and go with that and if you really really need to you can sort of write your own addition to a common interface guideline here. You can go with design systems particularly if it's more about a bigger web page doing rather similar things but not giving usually as much as advice so interface guidelines are more sort of text and advice oriented design systems is like really those Lego building brick model and create APIs for things that change the UI and extensions for people to try out stuff without messing with the whole UI and getting into fights what should be in there or not because that both keeps the UI coherent and clean like the UX design is wanted and it also gives people space to experiment like it's very important in many open source projects. Thank you. Thank you.
 Hello, first time.  My name is Yann Ditte.  And in this talk, I want to talk with you about the user and the cultures of UX design  and open source.  Design and open source projects seems sometimes pretty hard.  And different reasons for that have been suggested that maybe designers should learn more good  or that the tools are lacking for designers and so on.  And I think those are all very valid reasons.  But I think we should also look at the differences in cultures.  There might be different values and different practices that people are used to doing.  I'm going in with a closer reading of two seminal texts of those disciplines.  And the first of them I took as example for open source development and open source projects  is Eric Raymond's The Cathedral and the Bazaar.  And for UX design, I took a text that I think many would say sort of the seminal text of  UX design, which is Donald Norman's The Design of Everyday Things.  And in those texts, both talk about users.  And I think it would be very interesting to juxtapose those two and look at sort of their  different conceptions there.  And I think the most striking thing in the Cathedral and the Bazaars is that the user  and the creator are the same person.  And this starts at the very first idea that is conveyed about the user and the creator.  Every good work of software starts by scratching the developer's personal itch.  This is like the first principle that Eric S. Raymond puts forth here.  Developer sees a problem that they themselves perceive and they go to solve that problem  for themselves first and foremost.  And this is what, according to Eric S. Raymond, every good work of software starts with.  But this theme also continues.  There will grow a community ideally around that open source project.  And this then continues this topic that the users of that software should be treated as  co-developers as the best and most efficient way to improve your program.  Code improvement and effective debugging are called here as the major concerns that are  connected with that.  So your project is growing, treat users as co-developers.  So here you have user and creator as ideally the same person creating for their own need  and use and in attracting other similar people who are also co-developers slash co-users.  And now we will look into the seminal text of UX design that I picked here standing for  this discipline of UX design.  And this is the design of everyday things by Donald Norman.  And here you see very clearly that user and creator must be different.  And Donald Norman suggests there is a difference and creators often become expert with the  device, but they might not become experts with the task because this is what the users  are doing.  So you have like a strong difference here, like your creators, experts with the device  with the technology and users being experts in the tasks that should be done.  And that this goes into the organization of the whole project and that like teams of creators  need a vocal advocate for the people who will ultimately use the interface.  Norman says they tend to simplify their own lives rather than catering towards the specific  needs of the users in the situation of usage for which they are experts as we learned in  the previous slide.  And the only way to find out if your product works is to test the designs on users, people  that are similar to the eventual purchaser of the product as possible.  So you should find people who are similar to those people who will use the product in  the end and try prototypes and ideas with them in order to have this counter checks  towards making your own life easier or being too much of an expert with the device already  and not seeing anymore what is important here.  So this is like a topic that is repeated in Norman's works but also in works of other  usability and UX thinkers that user and creator must be different and that you shouldn't have  the idea that you're as omniscient to say that you know what users want.  You need to check that you need to be suspicious here.  Using user and creator is bad.  Different expertises in those roles is good.  So here we have those in contrast.  You have the idea that in the cathedral and the bazaar users are ideally the same person  they creating for their own need and use they scratch down on it and they will attract  other similar people and in the design of everyday things you have different expertises  between user and creator who have different interests as you saw and people tend to make  their own lives easier rather than the users.  And creators does need to learn what helps users by empirical methods.  They need to do the research.  And this also assumes a certain context in which the product is created which is for  the cathedral and the bazaar a community of like-minded user and creators who can collaborate  and who can code.  And in the design of everyday things probably assumes an organisation with somewhat of a  division of labour and that organisation being dedicated to creating products that are probably  bought at some point.  Those are very different contexts.  So some things that might seem obvious for one side might seem weird for the other.  So just building a feature that seems interesting might be great according to the ideas that  are put forth in the cathedral and the bazaar but for UX designers might seem somewhat strange  or problematic.  And testing with users before building anything, trying that slowly out instead of just coding  and seeing if it works for you might be a problematic idea towards a developer in an  open source project at least if you follow the cathedral and the bazaar ideas here.  It's like probably not that much fun.  You need some resources to get those users and you don't have this user creator in unity.  And you see that also in how UIs look.  And I think the best UI if I may put forth so far an open source project might actually  be the command line.  In the ideas how people should work together this might be a really good UI for that work  because you can for example add a parameter or code another program from the command line  without cluttering the user interface.  It's really good.  You can have a lot of options in a rather minimal UI that isn't clattered by all those  functions.  And you also have a lot of possibilities.  Adding parameters, calling other programs on Unity can also pipe that gives you a lot  of freedom to develop for the command line and have your interface there.  So it's easy to modularize but as many designers will tell you it's really hard for users  but because you don't see what you can do and this is the advantage for modular development  because what you can't see can't clutter the interface but it also makes it hard for beginners.  So looking at an idealized UI maybe from the view of UX designer as a suggestion look  at applications like some Mac applications or here I think sort of elementary OS is like  a good embodiment of that idea.  They are hard to modularize but they are very good for beginners.  So if one coherent UI it works like you know like it's based on standards there's few  experimentation it's rather coherent and adding a button would be like quite a political thing  that needs to discuss through and through.  It's like not very flexible there is one coherent concept.  So this clashes quite a bit with that idea of like-minded users scratching their itches  and adding by that to the project.  So a curious thing like what is modular about user interfaces, graphical user interface  icons and so like a lot of open source design and some projects is like redesigning icons  and people do a really good job here.  I think those icon sets from LibreOffice are pretty great but one reason why that is also  so popular among designers in open source projects this is one of a few things where  not of a lot of code made by other people needs to be changed but this is a modular aspect  about interfaces that can be swapped out easily.  So this is very attractive in the sense to work on that does.  One thing that would be pretty interesting I think would be boundary objects like things  that both disciplines can work on and with together and I think there are some that are  quite well suited for the work of open source development and designers and I think that  would help with some small wins here.  And the first thing I want to suggest is having like an interface guideline for your project.  Those are rather elaborate documents in which there are suggestions of when to use which  UI element when you design interface.  They were pretty popular in the 90s for a good reason because UX design as a role wasn't  as widespread then and they are I think really good.  Like the main thing would be picking one for your project just take care that they really  give like specific advice.  Particularly the Windows ones are good I think in specific advice.  Here's a screenshot from the Win32 guidelines.  So they clearly show here like what a balloon popup should be used for and what not and  what different parts it has.  And it's like very clear even if you are not a designer you can understand when you should  use it and why not.  So interface guidelines.  Don't write them yourself just pick one again slight constraint of your creativity but it's  really useful also as a coordination mechanism and they often lead to really good interfaces.  They are written by really clever people who have thought out this stuff.  Design systems are a bit more on the technical side basically UI elements and how you combine  them and in contrast to user interface guidelines there are rather popular web projects that  have a stronger variety of UI elements and particularly of visual styles.  And there are some systems like Storybook that bridge really well to the written code.  Here you see your design system I worked on for our donation page.  It's like just a little design system it's not super elaborate.  You see here like on the left are the single elements with the spacing and some advice  is then in the comments and on the right is a page assembled from those elements.  So you have a lot of like basically like Lego bricks how you can combine them in that final  design and not every time like sort of you call it designer or new.  You have your bricks already ready made.  The third and final one would be extendable UIs which is a coherent mechanism for UI extension  and an API.  So you see like there's an UI concern and then there's also like a programming reflection  of that because one big problem is like when you are flexible when you add stuff it often  makes a mess out of that program that's like things added on top and on top and on top and  it's really hard to keep that under control.  Also you don't want to shout at people as I know that function is not really worth like  building in for a lot of users just don't do it so a better way is maybe having that  as an extension.  If the extension is really really popular you could like still make that an official  part.  Firefox and Chrome do that really well.  You have for example this part in the upper right hand corner where like projects can  have their icons and if you click them you get sort of a mini that view they control  but they can't mess with the rest of your UI.  Pretty good.  I think one little problem here is those pop-ups sometimes look a bit messy because everybody  does their own style of that.  What might be better if you already give them a kind of design system for those extensions.  Here's the Jmovi statistics application that already gives you like useful for statistics  UI elements for your extensions and those extensions usually look pretty good.  Visual Studio Code is pretty good at that.  You have like on the left hand side the sidebar where applications can put things into.  Those are I think pretty nice projects.  As for the Recap even though they have quite a part of shared history there are rather  different views of what a user is and should be and how to work with them among UX designers  and among open source developers.  Even the open source culture as put forth at least by the Cathedral and the Bazaar you  have like this experimenting user creator and a community similar to them and in UX  design read from the design of everyday things you have this idea of designing for others  and finding out what others need by empirical research.  My suggestion rather than trying to change one or the other and going into like some  sort of educating them look at what shared objects could help the collaboration.  I think interface guidelines are really great.  Pick one that gives you very clear advice and go with that and if you really really  need to you can sort of write your own addition to a common interface guideline here.  You can go with design systems particularly if it's more about a bigger web page doing  rather similar things but not giving usually as much as advice so interface guidelines  are more sort of text and advice oriented design systems is like really those Lego building  brick model and create APIs for things that change the UI and extensions for people to  try out stuff without messing with the whole UI and getting into fights what should be  in there or not because that both keeps the UI coherent and clean like the UX design is  wanted and it also gives people space to experiment like it's very important in many open source  projects.  Thank you.  Thank you.
the_user_in_the_cultures_of_ux_design_and_open_source_0_1031.png the_user_in_the_cultures_of_ux_design_and_open_source_1032_1391.png the_user_in_the_cultures_of_ux_design_and_open_source_1392_2111.png the_user_in_the_cultures_of_ux_design_and_open_source_2112_5591.png the_user_in_the_cultures_of_ux_design_and_open_source_5592_7571.png the_user_in_the_cultures_of_ux_design_and_open_source_7572_7799.png the_user_in_the_cultures_of_ux_design_and_open_source_7800_9407.png the_user_in_the_cultures_of_ux_design_and_open_source_9408_15719.png the_user_in_the_cultures_of_ux_design_and_open_source_15720_17111.png the_user_in_the_cultures_of_ux_design_and_open_source_17112_20279.png the_user_in_the_cultures_of_ux_design_and_open_source_20280_21911.png the_user_in_the_cultures_of_ux_design_and_open_source_21912_22151.png the_user_in_the_cultures_of_ux_design_and_open_source_22152_25682.png
Hello, first time. My name is Yann Ditte. And in this talk, I want to talk with you about the user and the cultures of UX design and open source. Design and open source projects seems sometimes pretty hard. And different reasons for that have been suggested that maybe designers should learn more good or that the tools are lacking for designers and so on. And I think those are all very valid reasons. But I think we should also look at the differences in cultures. There might be different values and different practices that people are used to doing. I'm going in with a closer reading of two seminal texts of those disciplines. And the first of them I took as example for open source development and open source projects is Eric Raymond's The Cathedral and the Bazaar. And for UX design, I took a text that I think many would say sort of the seminal text of UX design, which is Donald Norman's The Design of Everyday Things. And in those texts, both talk about users. And I think it would be very interesting to juxtapose those two and look at sort of their different conceptions there. And I think the most striking thing in the Cathedral and the Bazaars is that the user and the creator are the same person. And this starts at the very first idea that is conveyed about the user and the creator. Every good work of software starts by scratching the developer's personal itch. This is like the first principle that Eric S. Raymond puts forth here. Developer sees a problem that they themselves perceive and they go to solve that problem for themselves first and foremost. And this is what, according to Eric S. Raymond, every good work of software starts with. But this theme also continues. There will grow a community ideally around that open source project. And this then continues this topic that the users of that software should be treated as co-developers as the best and most efficient way to improve your program. Code improvement and effective debugging are called here as the major concerns that are connected with that. So your project is growing, treat users as co-developers. So here you have user and creator as ideally the same person creating for their own need and use and in attracting other similar people who are also co-developers slash co-users. And now we will look into the seminal text of UX design that I picked here standing for this discipline of UX design. And this is the design of everyday things by Donald Norman. And here you see very clearly that user and creator must be different. And Donald Norman suggests there is a difference and creators often become expert with the device, but they might not become experts with the task because this is what the users are doing. So you have like a strong difference here, like your creators, experts with the device with the technology and users being experts in the tasks that should be done. And that this goes into the organization of the whole project and that like teams of creators need a vocal advocate for the people who will ultimately use the interface. Norman says they tend to simplify their own lives rather than catering towards the specific needs of the users in the situation of usage for which they are experts as we learned in the previous slide. And the only way to find out if your product works is to test the designs on users, people that are similar to the eventual purchaser of the product as possible. So you should find people who are similar to those people who will use the product in the end and try prototypes and ideas with them in order to have this counter checks towards making your own life easier or being too much of an expert with the device already and not seeing anymore what is important here. So this is like a topic that is repeated in Norman's works but also in works of other usability and UX thinkers that user and creator must be different and that you shouldn't have the idea that you're as omniscient to say that you know what users want. You need to check that you need to be suspicious here. Using user and creator is bad. Different expertises in those roles is good. So here we have those in contrast. You have the idea that in the cathedral and the bazaar users are ideally the same person they creating for their own need and use they scratch down on it and they will attract other similar people and in the design of everyday things you have different expertises between user and creator who have different interests as you saw and people tend to make their own lives easier rather than the users. And creators does need to learn what helps users by empirical methods. They need to do the research. And this also assumes a certain context in which the product is created which is for the cathedral and the bazaar a community of like-minded user and creators who can collaborate and who can code. And in the design of everyday things probably assumes an organisation with somewhat of a division of labour and that organisation being dedicated to creating products that are probably bought at some point. Those are very different contexts. So some things that might seem obvious for one side might seem weird for the other. So just building a feature that seems interesting might be great according to the ideas that are put forth in the cathedral and the bazaar but for UX designers might seem somewhat strange or problematic. And testing with users before building anything, trying that slowly out instead of just coding and seeing if it works for you might be a problematic idea towards a developer in an open source project at least if you follow the cathedral and the bazaar ideas here. It's like probably not that much fun. You need some resources to get those users and you don't have this user creator in unity. And you see that also in how UIs look. And I think the best UI if I may put forth so far an open source project might actually be the command line. In the ideas how people should work together this might be a really good UI for that work because you can for example add a parameter or code another program from the command line without cluttering the user interface. It's really good. You can have a lot of options in a rather minimal UI that isn't clattered by all those functions. And you also have a lot of possibilities. Adding parameters, calling other programs on Unity can also pipe that gives you a lot of freedom to develop for the command line and have your interface there. So it's easy to modularize but as many designers will tell you it's really hard for users but because you don't see what you can do and this is the advantage for modular development because what you can't see can't clutter the interface but it also makes it hard for beginners. So looking at an idealized UI maybe from the view of UX designer as a suggestion look at applications like some Mac applications or here I think sort of elementary OS is like a good embodiment of that idea. They are hard to modularize but they are very good for beginners. So if one coherent UI it works like you know like it's based on standards there's few experimentation it's rather coherent and adding a button would be like quite a political thing that needs to discuss through and through. It's like not very flexible there is one coherent concept. So this clashes quite a bit with that idea of like-minded users scratching their itches and adding by that to the project. So a curious thing like what is modular about user interfaces, graphical user interface icons and so like a lot of open source design and some projects is like redesigning icons and people do a really good job here. I think those icon sets from LibreOffice are pretty great but one reason why that is also so popular among designers in open source projects this is one of a few things where not of a lot of code made by other people needs to be changed but this is a modular aspect about interfaces that can be swapped out easily. So this is very attractive in the sense to work on that does. One thing that would be pretty interesting I think would be boundary objects like things that both disciplines can work on and with together and I think there are some that are quite well suited for the work of open source development and designers and I think that would help with some small wins here. And the first thing I want to suggest is having like an interface guideline for your project. Those are rather elaborate documents in which there are suggestions of when to use which UI element when you design interface. They were pretty popular in the 90s for a good reason because UX design as a role wasn't as widespread then and they are I think really good. Like the main thing would be picking one for your project just take care that they really give like specific advice. Particularly the Windows ones are good I think in specific advice. Here's a screenshot from the Win32 guidelines. So they clearly show here like what a balloon popup should be used for and what not and what different parts it has. And it's like very clear even if you are not a designer you can understand when you should use it and why not. So interface guidelines. Don't write them yourself just pick one again slight constraint of your creativity but it's really useful also as a coordination mechanism and they often lead to really good interfaces. They are written by really clever people who have thought out this stuff. Design systems are a bit more on the technical side basically UI elements and how you combine them and in contrast to user interface guidelines there are rather popular web projects that have a stronger variety of UI elements and particularly of visual styles. And there are some systems like Storybook that bridge really well to the written code. Here you see your design system I worked on for our donation page. It's like just a little design system it's not super elaborate. You see here like on the left are the single elements with the spacing and some advice is then in the comments and on the right is a page assembled from those elements. So you have a lot of like basically like Lego bricks how you can combine them in that final design and not every time like sort of you call it designer or new. You have your bricks already ready made. The third and final one would be extendable UIs which is a coherent mechanism for UI extension and an API. So you see like there's an UI concern and then there's also like a programming reflection of that because one big problem is like when you are flexible when you add stuff it often makes a mess out of that program that's like things added on top and on top and on top and it's really hard to keep that under control. Also you don't want to shout at people as I know that function is not really worth like building in for a lot of users just don't do it so a better way is maybe having that as an extension. If the extension is really really popular you could like still make that an official part. Firefox and Chrome do that really well. You have for example this part in the upper right hand corner where like projects can have their icons and if you click them you get sort of a mini that view they control but they can't mess with the rest of your UI. Pretty good. I think one little problem here is those pop-ups sometimes look a bit messy because everybody does their own style of that. What might be better if you already give them a kind of design system for those extensions. Here's the Jmovi statistics application that already gives you like useful for statistics UI elements for your extensions and those extensions usually look pretty good. Visual Studio Code is pretty good at that. You have like on the left hand side the sidebar where applications can put things into. Those are I think pretty nice projects. As for the Recap even though they have quite a part of shared history there are rather different views of what a user is and should be and how to work with them among UX designers and among open source developers. Even the open source culture as put forth at least by the Cathedral and the Bazaar you have like this experimenting user creator and a community similar to them and in UX design read from the design of everyday things you have this idea of designing for others and finding out what others need by empirical research. My suggestion rather than trying to change one or the other and going into like some sort of educating them look at what shared objects could help the collaboration. I think interface guidelines are really great. Pick one that gives you very clear advice and go with that and if you really really need to you can sort of write your own addition to a common interface guideline here. You can go with design systems particularly if it's more about a bigger web page doing rather similar things but not giving usually as much as advice so interface guidelines are more sort of text and advice oriented design systems is like really those Lego building brick model and create APIs for things that change the UI and extensions for people to try out stuff without messing with the whole UI and getting into fights what should be in there or not because that both keeps the UI coherent and clean like the UX design is wanted and it also gives people space to experiment like it's very important in many open source projects. Thank you. Thank you.
more good or that the tools are lacking for attracting other similar people who are also have different expertises between user and of open source design and some projects is like thing I want to suggest is having like an in the comments and on the right is a page there are rather different views of what a user UX designers and among open source developers. idea of designing for others and finding out what