Plan Like Einstein
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 | 38 | |
| 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/66695 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
FOSS Backstage 20238 / 38
7
8
11
23
27
31
33
00:00
Source codeGoodness of fitOpen sourceDifferent (Kate Ryan album)Focus (optics)Design of experimentsSoftware maintenanceType theoryLatent heatDecision theoryProjective planeMultiplication signBitMusical ensembleComputer animation
01:42
Software repositoryOpen sourceProjective planeSoftware developerQuicksortCASE <Informatik>Complex (psychology)Execution unitUtility softwareInternationalization and localizationLibrary (computing)Software testingType theoryOnline helpGroup action
03:09
Projective planeOpen sourcePosition operatorComputer iconPoint (geometry)1 (number)Data conversionData managementCore dumpPlanningFocus (optics)Drag (physics)CASE <Informatik>CurvatureCategory of beingMeeting/InterviewComputer animation
05:21
DampingCommitment schemeKernel (computing)BitPlanningGame controllerQuicksortWordSoftware repositoryCentralizer and normalizerOnline helpMultiplication signParameter (computer programming)Data conversionInternetworkingArithmetic meanBoolean algebraRight angleType theoryPoint (geometry)Open sourceEndliche ModelltheorieRandomizationComputer animation
08:00
Programmer (hardware)DataflowSoftware testingEndliche ModelltheorieMathematicsSoftwareComputer animation
08:29
Projective planeContext awarenessSeries (mathematics)SoftwareMathematicsMereologyConstraint (mathematics)Visualization (computer graphics)BitCASE <Informatik>Entropie <Informationstheorie>Fundamental theorem of algebraMultiplication signForcing (mathematics)Right anglePoint (geometry)HypermediaNeuroinformatikProgrammer (hardware)Open sourceVideo gamePlanningCodeArithmetic meanView (database)WritingLogical constantComputer animation
11:33
WordFile formatView (database)Table (information)Computer fileWeb pageMenu (computing)Monster groupOperator (mathematics)Computer iconScaling (geometry)Computer fileMultiplication signTask (computing)Software repositoryData conversionSheaf (mathematics)Formal languageWhiteboardLevel (video gaming)Point (geometry)Prandtl numberCodeBitSeries (mathematics)Type theoryComputer programmingMereologyProduct (business)Grand Unified TheoryState observerElectronic mailing listLimit (category theory)Different (Kate Ryan album)Right angleInternationalization and localizationData managementSlide ruleOnline helpObservational studyCategory of beingFocus (optics)Statement (computer science)Constraint (mathematics)Group actionLibrary (computing)Order (biology)Projective planeMathematicsDirection (geometry)Division (mathematics)AreaContext awarenessRange (statistics)Client (computing)Food energySoftware maintenanceQuicksortComputer animation
19:45
Gamma functionTerm (mathematics)BitSoftware testingDecision theoryPressureSeries (mathematics)Projective planeLibrary (computing)Level (video gaming)Musical ensembleMathematical analysisMeta elementHeuristicUsabilityResonatorBuildingMachine visionType theoryCore dumpRight anglePerformance appraisalData conversionMultiplication signSoftware maintenancePrototypeWhiteboardPoint (geometry)Archaeological field surveyOpen sourceFigurate numberSoftwareMappingMereologySoftware developerProduct (business)Code refactoringAddress spaceEmailEquivalence relationFood energyScheduling (computing)Coordinate systemMathematicsArithmetic meanCohesion (computer science)FrustrationSoftware bugUML
27:38
Source codeComputer animation
Transcript: English(auto-generated)
00:02
Thanks very much for having me. I so wished I could have been in Berlin this time, but here I am in sunny California at 6.30 in the morning. And, but I hope to be able to talk with you folks afterwards. So please feel free to ask questions. This is actually my,
00:22
this is actually my third talk at FOSFAC. The first one was done in 21, where I talked about the tension between user experience designers and maintainers, trying to articulate what the problem was. Last year, 22, I had a follow-up about UX tools
00:41
and specifically talking about how maintainers could attract and keep UX designers in their projects. And today I want to move differently because we, as a technology community, we get so focused and fixed on our tools for good reason, that we're just trying to figure out how to be more productive,
01:01
what we can do to kind of make things going forward. Because at its heart, open source tends to be a very loose collective of individuals. But UX is a little bit different. It's not something that is really done by a solo cowboy. It really is more of a team and talking about how we move towards
01:20
that precious consensus that we all want so much in open source communities. So the idea here is to kind of have a different type of talk where we don't focus on the specific tips and tricks for you to do great UX, but something which I just feel it needs to be discussed more, which is our culture, how we build that culture and how we actually make decisions as a community.
01:43
So I have to be very careful, of course, because open source is extremely diverse with individual repos of one person, with repos of thousands of contributors. And on top of all that, what open source is trying to tackle has changed over the years, right?
02:01
It initially was very much libraries and utilities and developer tools. And now it's branched into much more, in many cases, consumer facing things, obviously not for all of them, it's a small group. But as these projects have moved and become, some of these projects has moved
02:21
and have become more consumer focused, they're actually sprouting all sorts of complexity and things that a repo needs to deal with, accessibility, internationalization, unit tests, automated testing, in some cases, legal and marketing, and of course, UX. So what I'm talking about doesn't really apply to just UX.
02:41
It really is about just bigger projects in general and how they need to manage this complexity. It's not enough for one person to say, yeah, I got it, just let me know. We'll take care of it in the comments type of thing or in the issues. And so projects are becoming, I think, more complicated and that requires more work. Now, this doesn't necessarily mean
03:01
that every, of course, project repo needs UX help. I totally get that. And that's why I wanna bring that diversity up because if there's one thing I've learned, speaking at FOSS back in these years, is that talking about UX best practices is unbelievably tricky. It's important that I am not here
03:23
to tell you exactly what to do. I'm here just to talk about what has been done and to have a conversation about this. So this is more me just saying, well, what is there and what can we talk about? So effectively, my point was to say
03:41
that UX is actually doing very well in open source. And I really wanted to focus on the positives because so often when we talk about open source and user experience, people just tend to wanna flat, you know, drag on open source to see how bad UX is. And I guess we have some pretty well-deserved black eyes
04:01
in some cases, but what I wanna focus here is on the things that are going well. So I talked to a lot of these communities, you know, Audacity and Elementary OS and Pen Pot and Krita and Endless OS and many of these other icons behind you of these projects. And they're all considered more or less to be doing good UX.
04:20
You may not agree with all of them, but they're working on it, they're trying. And I thought it was helpful to go to the people that are actually doing UX work in open source and see what's up. So I interviewed all of these people, took a lot of notes, talked to them. And what was really fascinating is even though, by the way, I wanna make sure I make a point here, these are for well-established, well-funded projects.
04:41
And so I appreciate that not every project fits into this category, but the goal here isn't to say, you must be like these projects, the point is to say, what are these projects doing? What is it about that maybe smaller projects could steal? So that's what I wanna do. I started with the ones that are doing fairly interesting UX and say, what can we learn from it? And the key thing that I pulled away from all of them
05:02
and I asked them about this and they all agreed was about planning. Planning seems to be the core skill that they were working on and how they wanted to kind of manage UX. I thought that was a very interesting discovery and it was worth talking about. And that leads me to my quote,
05:23
which is, this is the Albert Einstein quote for this whole talk. If I had an hour to solve a problem, I'd spend 55 minutes thinking about the problem and five minutes thinking about solutions. And I think that's really fascinating because it applies not only to community-based thinking, but individual-based thinking.
05:43
Because it's, when you talk, especially when I'm on Mastodon, for example, when I would talk about things like this, let's just say there's a very active community out there that really likes to kind of question and challenge almost everything. And so when I was talking about planning and in the classic cathedral
06:00
and the bizarre sense of the word, a lot of people think that planning is a dirty word. It feels like any type of planning is the cathedral and we want a much more bizarre-like situation where things are bottom-up and individuals kind of contributing randomly. And the point I guess I want to say here
06:22
is that planning is not a dirty word. It doesn't have to mean bureaucratic, centralized, cathedral-like control. It's really more of a float and not a Boolean. And so I feel like we need to have a more nuanced conversation about what planning is and how it's being done.
06:45
And besides, the argument I would make though, is let's just take PRs as it's a general issue. Is every PR posted to every repo automatically accepted? Of course not. There's all sorts of famous drama
07:02
about who's got commit rights and whether things go in or not. PRs are rejected all the time. I mean, that in many ways is planning, right? Even Linus and his control over the Linux kernel is famous in the benevolent dictator model. There is clearly planning going on in open source.
07:24
So to say there is not planning or there's not some type of control is kind of missing the micro planning that is going on. So I think it's helpful for us to say, no, we are doing planning. It's not centralized, but it can be kind of discussed and talked about more. So why am I going on about all this so much?
07:42
Because I've experienced this myself. What is the most common advice a UX designer is given when they want to contribute to a repo? Well, the first bit of advice of course is to lurk a little bit, which is good, just to learn a little bit about it. But the next thing that I've been told this, I swear a dozen times is, oh, just push a small PR.
08:03
Right? And that is actually probably very good advice for a programmer or a dev, because that's the flow of what the whole Git model is. Download the software, do the build,
08:21
make a small change, compile it, test it, and then do a commit. So it's not an unreasonable thing to do, but I would argue it's really not great for UX things. And why is that? Well, for the first reason is any UX person that I think has tried this will tell you,
08:40
right, it's usually rejected. It's not a means of success. And why is it rejected? For very simple, basic social reasons, right? You don't have the full context. You don't understand the technical constraints necessarily of the project or the historical culture of what's been going on. And so unfortunately what this does
09:02
is it makes designers look arrogant. Another comment I hear all the time on social media is that UX designers are arrogant. And I mean, yeah, there are some arrogant UX designers, but frankly there's a lot of arrogant programmers too. I mean, there's plenty of arrogance to go around, but I'm saying that designers aren't specifically arrogant.
09:23
They're more likely, I think if you were to be more generous, is to say they're naive, right? Lurking is not the same thing as onboarding, right? People can lurk a little bit, but they can't necessarily absorb 20 years of history or culture. So some changes are made that probably don't make sense.
09:41
And to me, that's part of the issue is that UX designers want to help, but they just sometimes just don't have the full context to figure out what to do. So this is what I mean by design by PR. A lot of projects have a fairly simple view of UX. They consider it to be a series of visual tweaks.
10:02
And the only way they really want to move UX forward is by a lot of individual PRs. And of course, in that case, if I can quote Cathedral of the Bazaar, it's a series of unrelated itches. People want specific things fixed and they're going to go ahead and just do individual PRs. And the problem with that approach is that it's not coordinated.
10:21
And that can lead to what I would call a UX tech debt. And that's not really good for a project. And it just causes lots of issues down the road. Now there's this great quote from Ellen Ullman who wrote, this is one of her more recent works, Life in Code. We build our computers the way we build our cities
10:43
over time without a plan on top of ruins. There's this little poetry in that, but I love that sentiment because it applies to all of the engineering, right? This doesn't apply just to software. And it certainly doesn't apply only to open source because this clearly affects any software being written.
11:01
And as someone who has worked in commercial software, we see this all the time, this whole issue of tech debt, how we move things along. And all I'm saying is it is the fundamental force of entropy in software for us to increment ourselves to death. And this is true for everybody, not open source.
11:21
And I just want us to acknowledge that. That is the constant force that we're fighting to take these small incremental things and then make sense of them. And whether it's in a UX or it's in tech debt, it's something that we just need to tackle at some point. And the design by PR approach tends to create monsters like this, just one more icon, one more menu item.
11:41
And then you just get this whole, just massive collection of just stuff, which of course the experienced operator will know how to handle, right? But it's not easy for more beginning people. So what I learned from these companies and talking to them were three different things at various levels of timescale.
12:01
On the very, very short range thinking, there's building a better onboarding UX kind of approach. The second one, and then the much more difficult one is building a better UX culture. And the third one and the final one is about more strategic UX and project divisions. I wanna take each one of these in order as techniques to discuss how to do this.
12:21
I'll go through each one. Onboarding UX, do better than lurking. So the most obvious thing to do is to have contributor guidelines. And I actually talked about this in my previous talk last year, so I won't go into too much detail. But I think most repos have figured out that having contributor guidelines is a good idea.
12:40
And if you don't have one, I strongly recommend you do. They're not hard to make and they really take care of a lot of simple onboarding questions. But literally in your guidelines to say, we want UX help, or we want internationalization help, or we want accessibility help, whatever help you want, just put it in there. Just that sentence is awesome
13:01
because it means that people that are doing UX know that they're welcome and that they need something to say, please start here. And little things like how to post, hashtags to use, documentations to read, documents to read. These are better than lurking because it tells them specifically, do this, then this, then this. And it kind of gets people all talking the same language.
13:23
So you avoid PRs that just make obvious mistakes. Another one that's a little bit more work, but honestly is just a simple text push, is to have a few starting tasks because it really helps people to know what they should be working on next. And it's because it's really valuable
13:43
for people to say, oh, there's interest in this section. Now, of course, what you have to do is you have to monitor those hashtags. I mean, creating guidelines is not kind of a fire and forget kind of thing because it's a part of your culture. So if you have these hashtags, monitor those hashtags.
14:00
Get out, when the issues start, you have to engage with them. So it's not necessarily, it's simple, but it's not free. You have to actually do a little follow-up on that. But what I'm trying to pull together here is this magic of attention. Contributors can go to any repo they want to. There's lots of things to do. And if they know there's a certain amount of intensity,
14:21
like, oh, here's how I can start. Here's particular issues that you're interested in. People want to contribute and they want their change to land. We've all had our PRs rejected and that hurts. So we're like, well, listen, if they really want help in this area, they likely will accept it, especially if I have the culture and the context.
14:41
This is a very powerful way to actually motivate contributions because people know that they're wanted and they know that the change they're working on is wanted. I've even heard people talk about the fact in some of these repos I was talking to that very unpopular things like code cleanup and so forth is actually well-motivated and part of a bigger picture
15:04
that people will do these grunt tasks a little bit more if they know that it's really needed. So that's the whole general idea about onboarding is just help people get started. The second category, building a UX culture, is multiple points. I'm gonna go through a couple of slides on that one,
15:21
which is to say, move the discussion upstream, avoid design by PR and have a lot more work upfront. And this means effectively non-code-based discussions. There's a well-known phrase in the UX product management world that weeks of programming saved us days of critical thinking. And I think this is true across the board
15:42
that just jumping into code something only to find out it doesn't work is a waste of everyone's time. And so having more upstream conversations about constraints and issues and future directions will allow people to kind of focus their energies on things that just makes a lot more sense. So what does that actually mean?
16:01
Well, actually it's start with asking for what you want. If anybody who's been in therapy knows, that's one of the first things that you have to do in a relationship is make sure you ask for what you want and talk to people. It's your project, right? You don't need to wait for UX people to come to you and foist something upon you.
16:21
You can ask for UX things yourself. And this is extremely motivational. Back to my previous point about onboarding, if you're asking for something, people know their change will land. And it means that you get UX and UX designers want projects that ask for UX kinds of things. But you'll get so much more if you understand UX a bit.
16:43
You don't need to be a UX master. But as I mentioned in my first talk two years ago, 90% of the things that UX designers asked for is icons. And that gets old really quick. Not that icons aren't important, but there's so much more that a project can do than just icons.
17:02
So understanding that you can do a UX audit, a user study, a focus group, a motion study. These are all things that establish vocabulary and framing that makes your discussions as a culture so much easier to do. It short circuits so many conversations and it raises the level of conversation.
17:21
But let me give you an example of a UX audit. Sometimes people are really worried about that. A UX audit is basically someone with experience comes in and just does a study and they just use your product and they just give you a whole series of observations and recommendations. I've described this to some people and they are just aghast. Like what, some random person just tells me what to do? It's like, no, first of all, it's a professional
17:44
and it's basically talking about their experience and it's a series of recommendations. So you don't, and you don't have to listen to any of them, but it provides a document that goes into the community that everyone can talk about. And if they make 10 recommendations, you can just do two of them.
18:00
But it's a technique to talk about UX at a higher level of granularity that then your team can absorb and take advantage of. So these are lots of things that are enriching the conversation. Documentation, everybody hates documentation. It just seems like it's so much work to do. But to me, documentation is a way
18:21
of having the conversation once or a lot less often and in a shared way. So the obvious way to talk about documentation is constraints. What libraries you're using, what limitations do you have on file sizes or icon types or just all sorts of things that are built into your program.
18:42
UX is all about managing constraints. And so it's really important that the UX designers know those constraints so they can work around them. So don't be shy, especially if you have a constraint that you're like a little embarrassed about, that you feel really shouldn't be there. Talk about it, get it out there so that people can work around it.
19:01
Goals versus non-goals is another one. There's a really good one, by the way, I've linked here on Federite, which is a Mastodon list manager client. In their onboarding, they have a little bulleted list. This is what we're trying to do. This is what we're not trying to do. That's a bold statement to make. It takes a little bit of guts to make sure you're really clear what you're doing and what you're not doing.
19:22
And that's really powerful because it's short-circuits conversations. I had a UX colleague who posted an issue, a feature request at Federite, and the maintainer was like, oh, thanks for the help, lovely idea, but as you'll see in our non-goals section, we're not gonna be going in that direction. And he was like, cool, okay, great, thanks.
19:42
It's really powerful for you to short-circuit conversations to kind of just say, hey, we're going here, we're not going here. And the last comment here was documenting your decisions. Whenever you do make a big decision, have effectively an issues or a minutes type document, they just push a simple text fix. On March 14th, we just kind of made these decisions.
20:02
And this does two things. One, it's really powerful for onboarding. When someone comes to your project, they can kind of just see how you got there. It's a much faster way for people to come up to speed with what you've done. But most importantly, it pressure tests that decision. It's very common for people to document their decision
20:21
and have someone say, no, no, no, we didn't agree with that, no, you got it all wrong. And you know what? That's a great thing because you're going to discover that problem, right? If you are not in agreement, it will come to haunt you later. So by documenting and getting it out there and resolving it, you're actually short circuiting
20:41
the thousands of discussions and emails you're going to have in the very near future. So it's a very powerful thing to do. So the last thing I guess I want to talk about though, is a really fascinating thing I saw with Pen Pot. Pen Pot is the Figma open source equivalent
21:02
and they have a two to one ratio of developers to designers. And this is outrageous. It's amazing. And it's not even being done in commercial software. And it's such a bold experiment that we need to talk about it because it mentions how much they are investing in UX as part of their culture
21:21
by bringing people onto the team. And when I asked them, what are you doing with all those UX designers? Tongue in cheek, because I knew what the answer was. This is part of the answer that they gave back to us. They gave back to me, which is it's so powerful for discovery. They can do interviews, surveys, researching and benchmarking. They can do definition where they do wireframing,
21:41
prototyping and design critiques. They can do so much more to have time for evaluation, doing usability tests, heuristic analysis, bug hunting sessions. And it's really critical that none of these activities produce PRs, right? But they vastly improve the culture and team cohesion because now everybody has this rich vocabulary,
22:03
these rich understandings that allows them to say, oh, well, we don't want to do that. Or it's really clear, this is the core problem that the user is having. This is what we have to be working on. And, oh, this is an awful lot of work technically, but this is such an important user pain point. It's worth it for us to back up and make this change.
22:21
So part of what UX is, is about making these trade-offs and understanding why it's worth it and why it's worth the energy. Nothing is more frustrating as a UX designer to find a deep problem in a project and to have the maintainer kind of go, not a problem for me. Well, it's just like, no, it's not a problem for you.
22:41
You're the maintainer, you built it, but it's probably much more difficult for other people. And how do you have that conversation? And again, if you're building a small tool for three or four people, then that approach is probably fine. But it's about having this rich conversation of who the user is, what is their problem and why you need to be fixing it.
23:02
So UX, the key thing is UX is a team sport, building culture is a proactive effort and it's all about driving consensus, which is one of the core principles of open source is to be consensus driven. So the irony is that by having a little bit of planning, which feels like you're being a cathedral, you actually are driving significantly more consensus,
23:21
which is more bizarre like. So that tension is a very important thing to talk about. So the third and longer term point is to stop building on ruins. How do you handle tech debt and UX tech debt? So much more like documentation, but more in a longer term is to create a roadmap.
23:42
And roadmaps are a pain in the ass because you'll build one and six months later it's wrong and that makes you look bad and it's frustrating. But you know what? The exercise of creating the roadmap is what drives a lot of things. So yes, get people together, have a conversation, figure out what's important, argue a lot,
24:03
because if you don't argue now, you will argue more later. And so busting out a roadmap is a very powerful way for your team to get on board as to what you're gonna prioritize and then it's specifically called in UX types of things. And so obviously so much of what I'm talking about here applies to much more than UX.
24:21
I'm just saying that UX really benefits from it. The other thing is when we have talked about things like accessibility or various low-level technologies that have to get fixed, I've heard comments from some maintainers that say, well, we'll never get people to do that. People don't want to do crap grunt work like that.
24:41
But I'm gonna go back to my previous point that attention is your superpower. If people know that in eight months you're gonna do this really cool thing, but for the next four months you're gonna have to do this really crap work, it's much more motivational to do that. If people see the end goal, they will do more what people are calling grunt work
25:02
because it's building towards the right thing. People don't hate grunt work. They hate grunt work that goes nowhere. That's what people really don't want. And I specifically wanna call out what Metascore is doing. This is a project that's run by Tantacruel and they did a roadmap. They had a whole series of UX problems
25:22
that were really critical for them to fix. They had so much tech debt that they realized they couldn't do the majority of them. So they made this very painful decision, right? They did, they took 14 months out of their schedule and shipped almost no features and did a huge refactoring of the product
25:40
so that they could then get to the right, to the right level of the libraries they were using, got rid of a lot of crap so that they could actually build really interesting features that they wanted. I put the no gif there because I know a lot of projects just can't imagine doing nothing for 14 months. And that's fine. It's entirely up to you.
26:00
Like I said, I'm not trying to dictate anything here. I'm just trying to say, these are the things that these projects are doing and they should be talked about a little bit. And so I thought it was fascinating. Much like Pen Pot, you know, taking this two to one ratio, what that extreme means and how that works, how, what would your project look like if you took like 14 months to refactor your product
26:22
and not do any major issue releases, but hopefully then we're much faster afterwards. Interesting conversation. So in summary, how do these successful projects support UX? And I talked about three particular things. The short-term onboarding, make it simple for people to quickly grok
26:40
what you're doing and why. A whole series of things, mostly around documentation to kind of build your UX culture so that people kind of know what you're doing and why. And this longer term strategic UX and project vision. So the key thing I find that gets the most resonance is that because open source tends to be
27:01
at least poetically more of a solo sport where individuals can go off and just do whatever they want to and then magically show up with a PR. UX doesn't really work like that. It's more of a team sports and you really need to kind of back up, make decisions upstream and have a little bit more of this documentation and coordination so that your team can kind of reach that consensus.
27:22
It's a much more powerful way of working and you'll attract a lot more UX designers to do that. So thanks very much. I think we have a few more minutes for questions and I have both my Mastodon address and my email if anybody wants to talk to me or reach out to me afterwards. Thank you.
Recommendations
Series of 13 media