Why UX and FOSS clash and what we can do about it
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 43 | |
| Author | ||
| License | CC Attribution 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/67115 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
FOSS Backstage 202432 / 43
8
11
00:00
Programmable read-only memorySystementwurfUser interfaceGraphics softwareLink (knot theory)CompilerPasswordFunction (mathematics)ConsistencyDirectory servicePattern languageRevision controlFreewareCollaborationismSoftwareEndliche ModelltheorieData structureBitExterior algebraStandard deviationHacker (term)Software industryOpen sourceMusical ensemblePoint (geometry)Process (computing)Computer programmingSoftware developerPhysical systemQuicksortConsistencyUser interfaceProjective planeParameter (computer programming)Functional (mathematics)Electronic mailing listForm (programming)Multiplication signFeedbackGoodness of fitUniverse (mathematics)StatisticsStudent's t-testSign (mathematics)Computer animationLecture/Conference
04:34
ConsistencyRule of inferencePhysical systemSoftware developerAdaptive behaviorMathematicsConsistencyPhysical systemUsabilityFunctional (mathematics)QuicksortComputer animation
05:00
ConsistencyView (database)Software developerCodeDistanceMathematical analysisSoftware developerMereologyOpen sourceComputer programView (database)DistanceCodeQuicksortTable (information)Sound effectRoutingLecture/Conference
06:15
View (database)UsabilityComputer networkSoftware developerData managementOffice <Programm>User interfaceInterface (computing)Self-organizationData modelHill differential equationExecution unitExpressionAdaptive behaviorUsabilityOffice suiteParameter (computer programming)Streaming mediaComputer architectureCodeSelf-organizationNeuroinformatikFormal languageHacker (term)SoftwareSoftware developerData managementQuicksortEndliche ModelltheorieConnected spacePoint (geometry)Suite (music)Computer fileInterface (computing)Physical lawAsynchronous Transfer ModeExpert systemSoftware architecturePhysical systemComputer animationLecture/Conference
08:18
Web pageData modelNormal (geometry)View (database)Game theoryCASE <Informatik>Default (computer science)Office suiteDifferent (Kate Ryan album)Endliche ModelltheorieQuicksortWebsiteRevision controlOpen sourceComputer programCollaborationismProgrammer (hardware)CodeLecture/Conference
09:31
Open sourceProjective planeData managementQuicksortSoftware developerScaling (geometry)AreaCollaborationismComputer programmingExpert systemShared memoryData structureOpen sourceContext awarenessTask (computing)Computer animation
10:48
Open sourceProjective planeSoftware developerQuicksortEndliche ModelltheorieBitKernel (computing)CASE <Informatik>Open sourceExpert systemAreaLecture/Conference
11:31
Open sourceCollaborationismEndliche ModelltheorieGoodness of fitCodeData managementCASE <Informatik>Self-organizationCollaborationismOpen sourceComputer animation
11:56
Self-organizationOpen sourceCollaborationismGame theoryQuicksortSlide ruleEndliche ModelltheorieSelf-organizationOverhead (computing)CollaborationismGame theoryComputing platformData managementMathematicsLecture/Conference
12:28
Digital filterQuicksortSoftware developerBlogGame theoryDependent and independent variablesGame theoryCodeFormal grammarQuicksortVisualization (computer graphics)Software developerMechanism designInclusion mapSingle-precision floating-point formatComputer programmingAreaObservational studySystem callComputer animation
13:23
Game theoryProgrammer (hardware)Open sourceInterface (computing)Point (geometry)Arithmetic meanGame theoryProgrammer (hardware)Operating systemQuicksortPhysical systemOpen sourceCodeBinary fileComputer fileForm (programming)Software developerInterface (computing)PrototypeAreaDrop (liquid)Lecture/Conference
15:12
Software developerCollaborationismGame theoryEndliche ModelltheorieDifferent (Kate Ryan album)Slide ruleQuicksortData structureAsynchronous Transfer ModeComputer animation
15:54
Formal grammarSoftware testingUsabilityGame theoryFeedbackQuicksortSoftware testingLattice (order)UsabilityDistanceFormal grammarKernel (computing)Group actionElectronic mailing listEmailLecture/Conference
16:52
Software testingUsabilityFormal grammarScripting languageElement (mathematics)CodePattern languageSoftware developerWeb-DesignerSource codeScripting languageGame theoryQuicksortMereologyComputer iconMedical imagingComputer animationLecture/Conference
17:52
Scale (map)CollaborationismSoftware testingFormal grammarComputer-generated imageryCross-site scriptingFeedbackDifferent (Kate Ryan album)Game theoryOpen sourceProjective planeLevel (video gaming)File systemScaling (geometry)Focus (optics)SoftwareQuicksortCollaborationismSoftware developerProgrammer (hardware)Information technology consultingGoodness of fitGroup actionMedical imagingOperator (mathematics)Limit (category theory)Computer animationLecture/Conference
20:47
Scale (map)Focus (optics)CollaborationismSoftware testingFormal grammarComputer-generated imageryFeedbackCross-site scriptingMachine visionMedical imagingDifferent (Kate Ryan album)Projective planeSoftwareSoftware testingOpen sourceSoftware developerGame theoryFeedbackView (database)Endliche ModelltheorieComputer animationLecture/Conference
21:39
Scale (map)Focus (optics)CollaborationismSoftware testingFormal grammarFeedbackComputer-generated imageryCross-site scriptingSoftwareEndliche ModelltheorieMusical ensembleComputer animationLecture/Conference
Transcript: English(auto-generated)
00:07
My talk title is Unlikely Collaborations, Conflicts in UX and Free Open Source Software Work. And we probably know about these conflicts or heard about that it's like not easy to have this collaboration.
00:22
And I want sort of to give it a bit of a structure to understand it better and thus to work through it and overcome it in a better way by understanding its sort of history and values a bit. So this means first what I want to do is to look back cause those conflicts go back a while.
00:43
I want to show some ways to structure those differences and bring them in a structure that enables us to think about them. And I will discuss some common ways to deal with those problems and models that enable collaboration as well as showing a less common model for how to collaborate together.
01:03
And at the end I will summarize everything again because that's good practice as well. So, as said, the problem is not new and my first example going like discussing that conflict goes back to a time when the labels of like UX and open source didn't exist yet.
01:26
They probably were called like software ergonomics and hacker culture or something like that. And the example I'm going to show is very old but the conflicts are surprisingly similar to today's conflicts and they show up in a very clear and nice form.
01:41
And so let's go back 40 years to 1981 and the document I'm going to show is called the trouble with Unix. The system design is elegant but the user interface is not. And it's written by a Mr. Don Norman who is a cognitive psychologist and would later become one of the best known proponents of UX design.
02:05
And he attributes the problems that users have with Unix and I guess that includes, for example, psychology students who would use the system for statistics because the system of Unix has been like widely used at universities at that time, for example.
02:21
And he says one trouble is that the programs don't give feedback. They are kind of silent. That makes them probably very well to combine with pipes or where one program talks to another program and from like a lot of programs you can build like your own processing pipelines.
02:44
That is one point. So they don't give user feedback and Unix is not consistent. And this is inconsistencies we partly still have. Norman lists all those commands like on the left side basically what the function is, what the feature is, and on the right side what the problem is in the sense like what is the command that calls it.
03:08
And there are like commands that are named like the function name. There are different ways to abbreviate these two letters, leave the vowels out and so on. And then you have grab whatever. It has a history.
03:21
But it's too long to explain why it's named grab here. And consistency, as we learned in the previous talk, is one of the ways that designers would refer most often in like making something easy to use. And Norman says like Unix doesn't a great job.
03:41
It's like all over the place with its like how it presents to the user. And if you are in any project like designers pleading for more consistency, it's a pretty common thing. So this is not the only thing why that article is great. Sort of famous person talking about Unix.
04:01
It's also great for another famous person to basically give a rebuttal inside the same article. And this is by Michael Lask, one of the developers of C and Unix. And the over 40 year old arguments from his side look also very familiar. So he's starting with saying there are historical reasons why Unix is that way.
04:21
Kind of implying, you know, if you would know the history, you would understand. And he's also arguing that the standardization would limit the free development of the system. And the alternative would be like a committee of bureaucrats, kind of that would sort of need to have consistent function names. And certainly nobody would want that.
04:43
And the diversity or incoherence and the ease of change to the system from the developers can only come as a package deal. So it got from the Unix side. Freedom of adaptation was this bureaucracy and from the psychologists that Donald Norman is. You get coherent design was sort of the incoherent meddling where everybody does something and it doesn't fit together.
05:03
So last part of that puzzle can't be found in that document, but I want to show two other documents briefly in a quotation, which is like, who is the user? Because that is on both open source developers and on UX designers' mind. So what is that imagined user like?
05:22
So I've got two world views and I again sort of pick out famous documents, not because they are the best analysis from the best people or whatever. They have had a lot of cultural influence. So in this document, the cathedral and the bazaar, which is sort of set to co-start an open source,
05:42
has this quote of like treating your users as co-developers is your least hassle route to rapid code improvements and effective debugging. So they are very close and they are also programmers. And you have from Donald Norman's book some years later, 88 design of everyday things.
06:00
Designers and also programmers are not typical users. So you have like the distance here. And you can put those two world views basically in a little table. You have what are the people concerned with. You have other programmers and it's to the inside and non-programmers to the outside for like the right side being UX, left side being FOSS.
06:21
And what do people typically push for? Adaptability, freedom, expression. And you have for the designers coherence and ease of use. It's not that this is all that people can think of. It's just like what they would emphasize usually in discussions according to their profession's values. And an interesting point that I need to include is also like
06:41
what do they not want to be like? And for designers, we already had that example. They don't want to be like people who only understand their own system, who are too deep into it and lost connection to the users. And for the devs, I don't have it. I need to reach out to, for example, the jargon file, a dictionary of early hacker language.
07:01
And there you have uneducated users. They are losers. Who is also the problem? The suits, the management. They also don't have a clue about computers. So they are a major annoyance. And so these are also creating then typical modes of development.
07:23
Basically, if you follow those values and where they can be practiced. So you got a loose coupling of potentially many developers versus networks and plain text tools and Linux and their whole plain text culture of pipes and Git and whatnot.
07:40
And you have corporations and management with tools, for example, like Microsoft Office and Adobe Creative Suite and all this like big corporate software. And so if you're interested in software architecture, you might be familiar with Conway's law, which is like that your organization's model will be reflected in your code's architecture
08:01
and we can sort of quip a bit and say that also applies to interfaces. So on one hand, you have like the plain text, Unix stream compatible command line tools with a lot of parameters easily combined with other things. And you have sort of the expertly crafted UI for the office worker
08:23
that provides defaults for the most common cases for people to solve their most common problems. So with these differences firmly established, how do we work together? And as we all know, probably it's difficult, but it's not impossible. Let's first start with one of those models,
08:44
which I called assimilation or more colloquially, let them learn Git. And that is the idea of like not to solve that conflict at all, but just dissolve the problem in telling one side that they should adapt to the other side. And open source culture being dominated by programmers,
09:02
the side to whom designers should adapt is the programmer side. So they should learn how an issue tracker work, do some PRs, learn Git, throw their graphics away and embrace plain text. And I'm not against learning all this. I consider myself an okay hobbyist programmer, but I think it's not a solution for actual collaboration.
09:23
And then you have sort of the model that is built along working in a company, but with open source code. And why does that work? Well, the company provides management and some structure and that management and common shared goal of the company
09:43
makes both developers and designers take some compromises. And in this context, a lot of methods have been developed and a lot of those methods can also work in smaller projects. Scott described some of those successes earlier and in the following talk we will also see
10:02
some of those methods and how they can play out. And this would be typically heuristic review, sorting like what are the five top problems, the biggest hurdles for new users. And I think this can work really well even without sort of adapting all the shenanigans of like management and company structure.
10:20
However, from its origin there's an unexpected commonality which I was surprised of that UX and open source share. Both the idea of sort of the open source bazaar of collaboration and experts in design solve a problem of scale. The programming side, like the FOSS side,
10:40
solves it by like basically assuming coherence and common understanding of development problems and the sort of original area where UX design was created assume sort of this working in a company with expert roles.
11:00
And this can work for some things really greatly looking at those projects and seeing how well they scale like looking at Microsoft or looking at the Linux kernel development and it's all very interesting and helpful in many cases but a lot of projects are not like big projects. So what the Linux kernel needs and what Microsoft does
11:20
or Google does might not be the things that help you as a small project. So let's put that a bit in a model. You have work at a corporation, you have open source development and work at a corporation seems to be really good at cross-professional collaboration mediated by management and open source seems to be really good at the self-organization around code and what both sides are kind of good at
11:43
is like producing big scale models in many cases. So you will have noticed one side doesn't have a label yet. So like no model is true but some of the models are useful so let's take that and see what sort of would be put
12:01
at the other side if we just follow that model. It would need collaboration, it would need self-organization but it can be small. Like people working together in small teams without sort of the overhead of large corporation and management. So what I want to look at as an inspiration would be hobbyist games.
12:25
Here we are looking at a platform called itch.io. There are a lot of games created by hobbyists, semi-professional and professional developers and you can find a lot of stuff there from barely polished to really great longer games.
12:43
And I don't have sort of formal studies on this area but it seems that a lot of those programs are created by single people or small teams and that usually creating such a game needs to include game mechanics and visual assets and not just programming.
13:03
So including this is like shared responsibility of the team like both what we would call design and code are both really important and I guess everyone is aware of that because people seem to produce really nice games here. And last but not least,
13:21
a large amount of those people seem to do it at least partly for fun. Like those games are sold but often for very small amounts like a dollar or something like that. So I guess very few people get rich with that which is nice because we are concerned with development and communities. I guess sort of the both sides that I introduced before
13:42
like the UX designer and the open source programmer in its prototypical form might be sort of a bit annoyed by that because it violates that you are not the user. No, those people are deeply involved in their own games but also they know that the user is not a programmer. Like you don't need to be a programmer to play any of those games to install them.
14:01
They usually come in a zip file. You just unpack it and then you can click an Excel or a bin and then start playing. So it's not assumed that you need to build them. And this makes it interesting I think for our communities you learn from them. Learning doesn't mean duplicating it saying like okay everyone should develop like it's a small hobbyist game.
14:22
That's not possible. It's not a drop-in replacement. And there are three points that I want to point out in this like area. Only some of those games are open source because their communities are also not focused on code per se. They would be like open game if there would be such an idea.
14:42
It wouldn't be focused on source itself. Obviously not all tools can be built on a small team. Yes, I know there are some sort of hobbyist operating systems but it's like very hard to build like an operating system that is widely used with like two people. And just because people care about how it looks and feels
15:03
and is to be used doesn't mean that all of those games have easy to use interfaces. So with these caveats I think I can emphasize that it shows the possibility of another mode of collaboration that isn't sort of going to either side.
15:22
We have widely different disciplines and volunteer communities. It's without a cooperation like structure mediating the collaboration. And that model comes with its own ways of working and the use of appropriate methods. Not just saying like the developers and games work this way and the designers and games work in another way
15:40
and then somehow it's put together. So you will have this callable. Sorry, that's the previous slide. That is the one. Okay, so you will have small team infrastructure. And one interesting thing about games, for example, is that only a few of them use Git.
16:01
Because Git is not really good at assets because it's so focused on the plain text Unix culture. So a lot of games still use SVN. Why? Because it can deal well with any other asset and you can check it out and it's easy to use for a lot of people. You might have a mailing list but maybe people just have a signal or WhatsApp chat group.
16:21
It needs to work for a small team. They don't have the idea of needing to be like the Linux kernel. Also, there are probably no formal usability tests or other sort of distance academia-like methods. But a lot of people will still give those games to others that don't know the game yet and collect feedback. Like in Berlin, I'm sometimes at a meeting of indie game developers
16:42
and a lot of phones are shared around to try out each other's games and to gather feedback. So you will also, even focusing on the code, get some interesting patterns of how that is structured. As I said, all those elements are important.
17:02
And you get those equally important layers instead of just saying like, yeah, there is sort of some UI slapped on top and some nice icons. But what is actually important is the source code behind it. No, that's not how games work. You have assets. You could say the look and feel. You have scripts for the behavior, like where do enemies go and how do they react.
17:20
And you have the engine that enables all this. So all those parts are really important, but there's no one part that is like, you know, the developers do the true work and then somebody else does something superficial on top. For a game, it all needs to work together. And that's like unlike old school web development where you have HTML, CSS, JavaScript,
17:42
and the images, for example. And that also points to an interesting thing. I think that this is a relatively diverse community. Also, like for many reasons, but also because there are different entryways for different interests and different people and there are a lot of sub-communities that exchange.
18:01
Limitations apply. They didn't solve capitalism. You still need to afford to work for fun. But there are a lot of different ways to get in those communities and be involved in games, and this like enables more different groups of people to collaborate together. So let's summarize that.
18:22
As promised. So I introduced the difficulties of collaboration between UX designers and open source developers and talked about that they are not new. They have a long history that goes back. And there are some fundamental differences that can be seen in those published texts that I've shown.
18:41
And questions of values, what a good open source developer or good designer is and what they should be like and what they should do are really important here and sometimes they really clash. And this is not only in that you could kind of say people, they should adapt a different mindset. First of all, even that is hard. And then, as I showed,
19:01
this is also in our infrastructure that we use. Like Git assumes plain text. If you put in images, you get sort of hiccups or you get a person saying, oh, but please use large file storage. But then it gets even more complicated, la-di-da. So working across those differences are hard. We looked at the method of basically eliminating the differences
19:21
and say, like, dear designer, please become a programmer who also happens to be good at design. And we looked at the pretty successful way of integrating some methods sort of that were pioneered by big companies and consultants in the 80s and then sort of codified
19:41
and used them on a small scale level in our projects. And we have precedent that this can work really well. Nevertheless, assuming that there are some other talks here that will introduce that, I wanted to talk about basically a third way, not about method import, but about that other community that seems to manage that well.
20:01
And this were my hobbyist game creations. Because I saw user focus there and the motivation to test your software, it's also volunteer-driven and done for fun. And it includes practices that might worry the hardcore open source developers or worry the hardcore UX designers. But as I experienced myself,
20:22
whenever sort of I'm browsing itch.io and other games there, it seems to produce fun software that is very often easy to use. And I enjoy that a lot. So what I want to suggest here, what we can think about, is like a focus on small scale collaboration when starting out.
20:40
Think about if you need to use the same tools as all the big projects. Maybe there's something small that you can adapt that eases your work as a small project. And think about infrastructure and tools that work well for different kinds of contributions. Like what if somebody comes with an image? What if somebody comes with a sketch?
21:00
What if you want to define a vision for your software that can't be put easily in an issue? And so on. This enables the infrastructure to be welcoming to people who are not open source developers and have not grown up in that culture. And you don't need necessarily formal testing even though as a UX designer and UX researcher
21:22
I really like formal testing and setting up like proper research. But what you need mainly is like plenty of use and feedback from non-programmers like those game design people who share their smartphones and try it out and get feedback from people who have never seen their game. And I think this is a really interesting model
21:41
and it's also a lot of fun to be in those meetings and try out this stuff. And I think this can be an inspiration for how we might create software together that is open, that is fun to create and fun to use for non-programmers. Thank you.