An OSD Case Study
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 |
| |
| Subtitle |
| |
| Alternative Title |
| |
| Title of Series | ||
| Number of Parts | 561 | |
| Author | ||
| License | CC Attribution 2.0 Belgium: 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/44452 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
FOSDEM 2019334 / 561
1
9
10
15
18
19
23
24
27
29
31
33
34
35
38
39
40
43
47
49
52
53
54
55
58
59
60
63
65
67
69
70
78
80
82
87
93
95
97
102
103
104
107
110
111
114
116
118
120
122
123
126
127
131
133
136
137
139
141
142
148
153
155
157
159
163
164
168
169
170
171
172
173
174
181
183
185
187
188
193
196
197
198
199
200
201
205
207
208
209
211
213
214
218
221
223
224
226
230
232
234
235
236
244
248
250
251
252
253
255
256
257
262
263
264
268
269
271
274
275
276
278
280
281
283
284
288
289
290
293
294
296
297
300
301
304
309
311
312
313
314
315
317
318
321
322
327
332
333
334
335
336
337
338
339
340
343
345
346
352
353
355
356
357
359
360
362
369
370
373
374
375
376
377
378
383
384
387
388
389
390
391
393
394
395
396
406
408
409
412
413
414
415
419
420
425
426
431
432
433
434
435
436
438
439
440
441
445
446
447
448
453
455
457
459
466
467
471
473
474
475
476
479
480
484
485
486
489
491
492
496
499
500
502
505
507
508
512
515
517
518
529
531
533
534
535
536
539
540
546
550
551
552
553
554
555
557
558
559
560
561
00:00
Observational studyOpen sourceVideoconferencingInterface (computing)Interface (computing)Software maintenancePerspective (visual)Interface (computing)VideoconferencingMusical ensembleComputer animationJSON
01:17
SharewarePerspective (visual)Strategy gameSeries (mathematics)Dependent and independent variablesMaxima and minimaOpen sourceTwin primeIterationVideoconferencingTrailSoftwareView (database)Software maintenanceFeedbackBitPhysical systemInterface (computing)Computer configurationMereologyOpen sourcePerspective (visual)User interfaceVideoconferencingOcean currentCuboidInternet forumAddition1 (number)Point (geometry)SoftwareCASE <Informatik>Selectivity (electronic)2 (number)NumberMathematicsData conversionProcess (computing)DatabaseEmailElectronic program guideComputerForm (programming)View (database)PrototypeSystem administratorRevision controlMultiplication signType theoryInformationIterationOnline chatDecision theoryRight angleExistence
10:49
Execution unitOnline helpInterior (topology)Electronic visual displayMenu (computing)View (database)EstimationConvex hullMereologyWeb pagePhysical systemDependent and independent variablesMultiplicationProcess (computing)Computer configurationSoftware testingSoftwareBitSoftware developerFeedbackInterface (computing)Social classMathematicsComputer hardwareUser interfaceTranslation (relic)CASE <Informatik>Software bugGoodness of fitHypermediaPoint (geometry)Mixed realityMathematical analysisCategory of beingFront and back endsOpen setContent (media)EmailQuicksortMultiplication signCodeRow (database)CuboidMusical ensembleStudent's t-testRight angle
20:20
EstimationPhysical systemGoodness of fitBitMathematicsPoint (geometry)Data conversionIterationMarkup languageMatching (graph theory)Sign (mathematics)Front and back endsNatural numberView (database)Process (computing)Right angleTotal S.A.Multiplication signLecture/ConferenceComputer animation
22:19
Point cloudComputer animation
Transcript: English(auto-generated)
00:07
So, related to TOSDEM and how TOSDEM is done, I think it's very interesting. And please welcome our voice speaker, Chris.
00:33
So the standard thing, and then Muldrum told me that he's going to be here. We were going to talk about it, but it might be much more interesting if he tells us things.
00:48
So this talk is going to be about the maintainer's perspective in engaging with open source design. So if you've ever spoken at TOSDEM, you have been asked to review the video of your own talk using this thing.
01:10
And over the past year, Walter and I have been working together to redesign this interface. So the purpose of this session is twofold. Here, about the time from the maintainer's perspective and to give you the chance to witness a semi-structured interview,
01:27
which is a qualitative research technique that you can use with your users or with your contributors to find out a little bit more about who they are and why they're using your software. To do one of these interviews, you need to prepare a discussion guide like this.
01:42
But the technique gives you a lot of freedom, so you don't have to go through all the questions. And you can give a lot of leeway to the interviewee to take the conversation where they want it to be. So that's what we're going to do today. Yeah? Is everybody happy with that? Cool. So this is the interview.
02:02
So Walter, at some point, you decided to call onto open source design. And you submitted this post over here to our jobs forum. So why did you decide to do that? Well, the issue that I wrote was a piece of software that was working quite well.
02:24
But I noticed that people were misunderstanding things. Because, I mean, I'm not a designer or user interface designer. And I made a few mistakes. And I was hoping to find somebody to help me. And then I found open source design. As it happens through another talk at Fosden 2016, which mentioned that open source design existed.
02:49
So I submitted a talk, a job there, just to see what we can do. And things went from there. And my original idea was that, well, things would just need to be tweaked a bit, because it's mostly there.
03:03
But that's not quite what happened, actually. Before we go into what happened, can you tell me a little bit, what were the things that people were getting confused about? What were the things that people were misunderstanding? So the things that people were misunderstanding and getting confused about was mostly things like
03:23
the original interface wanted you to use some JavaScript buttons, which would then update the form down below. And then you had to submit that form without making any changes. And some people misunderstood that. They were like, I clicked the buttons, so now everything is fine. And they chose the everything is fine option, which meant that all the changes they made were thrown away and not used.
03:44
Which is not very useful, of course. Those were the most extreme ones. A few other things was also with the audio options that was really not clear. People had to enter a number rather than to choose options, and that was a bit confusing too. So there were a few things like that that were very confusing for people, and that they misunderstood.
04:04
OK. So let's go back to what happened. So I replied to that post, right? Right, yeah. And what happened next? That's been a while. I think what happened was that we had a chat about what the system needs to do.
04:21
And I explained the background of how everything works a bit to you so that you had a good idea. And I showed you how the current review interface works. Well, the then current review interface worked. And then you went to work. Yeah. And you came back with the proposal. Yeah. And so you get any access to the system.
04:41
Right. And I came back with a proposal. I actually sent you these. I sent you two things. Do you remember what I sent you? Yeah. So the things you sent me was one was indeed a prototype, which was a web interface version. This one didn't actually work, but it showed how things were supposed to work.
05:01
And you also sent me a video with an explanation of how things needed to work. I mean, this is just a mockup, of course, of the video. The mockup was quite nice because it allowed me to interact with them and see what I thought was right. And then the video explained the idea behind it, I guess. Right.
05:22
Was that what you expected when you started working? It was absolutely not what I was expecting. This is a complete overhaul of the older interface. It's completely different. I have to say that it's much better than what it used to be, because what it used to be was everything. Whereas right now it's like a layered thing.
05:43
You really go through it step by step and that's really good. I thought, well, we'll just need to move things around a bit and that'll be fine. That's what I was expecting, but it's completely different. Did you freak out a little bit? Maybe for like two seconds. And I was like, well, yeah, it's better, so whatever.
06:05
So not really. No, not really. I didn't really freak out of that. I think it was a very brave decision of you to say, yeah, I'm going to follow what this crazy lady is telling me. Because as you say, it was a completely different approach to the design you had in place.
06:22
Yeah, it was indeed a completely different approach. But at that point, my aunt also said if you came up with something that was going to need too much work, I was probably going to say, well, I'm going to keep this in mind. And probably not for this for them, but for the next one.
06:42
But I got around to it. It was not that much work. It did mean that a few other things that I had planned for this edition have now had to be postponed. But that's fine. I mean, this is actually the most important part of the system, the review interface, because that's what other people need to work with. And to have that work much better means we don't have to use the administrator interface as much,
07:04
which is the other part that I wanted to update. So that's fine, right? It's not a problem. So I sent you this stuff. And what happened next? Do you remember the type of process we found? Yeah, so I looked at that. Like I said, it was different from what I was expecting.
07:23
I immediately saw a few things that looked like they could be problems, because the way the database is written, it had some issues that I couldn't directly implement or would require a lot of work that I thought I wouldn't have before FOSDEM.
07:41
And so we talked about that, and then we made a few compromises here and there. In one case, we said, let's try this, which then afterwards we decided, no, that's not a good idea. So we went back to the original one. In other cases, we actually kept it at the compromise that we did, that we came up with. So it was a bit of an iterative process where we improved.
08:02
You made changes upon my feedback, and then I gave you feedback again until we came up with something that we thought was fine, right? What about the tools that we used to communicate? We've used mostly email. You sent me an email with updates, and then I looked at what you prepared,
08:25
and I looked at your video, and I gave it some thought. And then a few days later, we would do a live video of... What was it again that we used? I'm not sure. One of those video chat...
08:42
Yeah, Jitsi is what we used, right, exactly. So we did some Jitsi session to talk about it, and it actually was a very good idea because if we had to do everything over email, it would have taken much longer. And doing it over Jitsi allowed us to interact a lot quicker, and that's actually good. So we went through a few iterations.
09:03
These are the notes that I made from one of our calls, by the way. And do you remember any disagreements? Any of the things we had to negotiate on? We negotiated mostly about the one thing that we ended up going back on,
09:21
which was the other brokenness thing. So maybe just a little bit of background. If the review system... It doesn't allow you to change everything in the video. Some things you can't change in a web interface. And for that system, the old interface had a... Well, we can't fix this with a text box that allows you to enter some freeform text.
09:42
And that would mark the talk as broken, and the administrator has to go in and see, okay, what's wrong and how can we fix it? The original interface kept that as part of the review. Like, we have to make changes, and that was just an extra thing. But then the targets get marked as broken,
10:01
and that makes it difficult to see that it was broken. So then we came up with three selections at the first, but then we tested the interface. Afterwards, that turned out to be a very bad idea, so we went back to the two option one. We'll see what happens there. Yeah, that's the other brokenness there.
10:20
So you mentioned something interesting in there. We tested it. Yes. Sorry, did I run it yet? We tested things. So you... Well, we... This is how we see video online. Okay, sorry. This is just information not by video. Nobody really cared. Sorry, I can't mute it.
10:40
It's fine. So, yeah, the way that worked was we asked for a few volunteers. I think we found five. Yes. Some of them had been speakers for them before, and others had not been, which I think is a good mix. And you changed the mock-up so that they would be relevant to that speaker.
11:00
Usually it was just to show the talk by that speaker. And then you sent them an email, and you asked them to pretend that that was actually a working interface. There were a few things that didn't actually work, but that was fine. And then they went through it, and you asked for feedback from them. You also recorded those sessions,
11:20
and I could review the recordings, which was actually very useful as well. And then you made some notes based on that that we couldn't then look at together and use that to improve the design even further. I'll just talk about content. Thank you. I'm not going to give you the mic, because I keep forgetting to repeat what you say.
11:42
No, no, no, it's okay. I think we're good. Sure. Thank you. When I was in college, we had some theoretical classes about the whole process. That's 20 years ago. I haven't actually done that in practice ever,
12:02
so it was really new for me. I had a very vague theoretical idea of how that works. It's ages ago, I don't really remember, so yeah, no, I haven't. And what do you think of the process? I think it worked quite well. Most of it was because the original design you came up with was a really good one.
12:20
If it hadn't been, then we would have... No, I think so. If it had been, it would have taken a bit longer and it would have been more complicated. But I think what you came up with originally was quite nice and then iterating over that and improving it further and further after seeing what's technically possible and what works with tests that we did with uses that actually worked well, I think.
12:41
This is the outcome of the testing session. There's a little bit of analysis. There are some categories on the left and then some notes relevant to each test. And then this is the suggested design changes. Do you remember any of the suggested changes It's been a while. I don't remember the...
13:01
Yeah, at some point we had... In the review page we showed how far down the process it was, which I thought was a very good thing. It looked really nice and it gave people a better understanding of how the system worked, I thought. But when we tested it, we found that it was actually confusing people.
13:21
Because that page... If you see all four options there, it would have been good, but you don't really only ever see the second option. And then it's why is that there? Do I still need to do something? It was confusing, so we removed that. I thought it looked really good, but if it's not functional, then it has to go. Yeah, yeah. These are some of the interesting things with this process. The things that you think are gonna work
13:41
then don't work at all. Right, exactly. Then I started writing the code, I think. I mean, I had expected to not need as much because I thought you weren't going to change that much. But since you basically overhauled the whole system, I really had to change quite some things in the backend.
14:05
And that took some time. And in fact, today, I noticed that there was a bug still in there. It's fixed now, but this morning's talks haven't been reviewed yet because I had to fix the bug first. But I implemented things and then there were a few minor things
14:21
that I still found that I asked some feedback from you. But you were quite busy by that time, so in some cases, I just invented things myself. I think it looks good still, though. I think this is one of the problems. I'm gonna ask you next what you like about the process and what would you change. And I think one of the problems we have is that I was a bit too busy, so I abandoned you a little bit at the end, didn't I?
14:41
I still have some things I need to say. It's fine, it's fine. I mean, yeah, you did indeed, but I mean, I understand. I mean, I can get busy too. It happened. It's not a big deal, right? Okay. And what is it that you liked about the process? Have you liked anything? Is there anything that you found particularly interesting?
15:01
Well, nothing in particular. I think it worked well. I think the iterative process is a good system. It works quite well. Working with mock-ups also allows me to understand what you're meaning, what we're talking about. It gives you something to deal with rather than some hypothetical scenario
15:20
that may or may not do something useful. So that's actually a good way of doing it. Of course, translating that mock-up into actual stuff that works with the rest of the entire system, that was some work still, but not that much because much of the mock-up was already, the JavaScript part of it was already written,
15:40
so thanks for that. So that was fairly reasonable. I think it worked quite well, and there's not much that I would change really. Is there any aspect that you think we could improve? Can't really come up with anything right now. It might be useful at some point.
16:04
We could maybe use some system where you can file bugs more easily or something. We use GitHub issues, and that worked kind of.
16:21
It might be useful to have a bit more structured, I think. That's about all. Also, I wouldn't know how we would make it more structured, so it's a bit complicated. But yeah, I think it worked definitely quite well, so I don't think there's as much we can change. You're giving another talk after these, right? Yeah, I'm giving another talk in the Open Media Dev Room
16:42
about the technical part of how it all works, the backend, how that works, so if anybody's interested, that should definitely go there. I think it's at 3. It might be at 3.30. I'll check out the talk. Better make sure not to miss it, right? But yeah, it's definitely, there's no talk there. So we have three minutes to go,
17:03
and do you people have any questions for others? And I just want to make a comment before questions. Let's be excellent to our speakers and not leave while we have question session. Let's listen to questions. Only three minutes, okay? Okay, thank you. Go ahead. I got one question regarding the process, but it says does it stop once everything is delivered,
17:21
or do you have also a way to improve the design with A to Z testing or the kind of stuff? Have we all seen back from a change? This I'll have to leave to you because some of the things you just asked, I don't know. Well, I think what he's asking really is what's gonna happen next, because we have a live testing of this interface going on in the next two days, right?
17:43
There is that, yes. Well, I'm currently, I'm definitely monitoring things and making sure that everything works well. If things go wrong, we do leave a contact, a way for people to contact us and say, hey, I don't understand how this is working. Actually, multiple ways.
18:01
If that, we do get some feedback from that. I'll definitely, and we'll see how we can improve that even further. I'm not going to make changes to the design for this year. I'll definitely keep that in mind and then use it for next year, but we're not gonna make live changes to the live interview, because I think that's a bad idea, right?
18:21
But other than that, I don't think we'll have quite as many issues as we had last year, and last year we had about 90% of people understanding how the system worked. So, it should be good. That is reassuring. If I understand correctly, you're using mostly rapid prototyping to test these interfaces,
18:41
although you did mention mock-ups, but I don't know if that translation. Mock-ups, prototyping, currency. Okay, but do you also see advances in many, before that, did you take from that, or just images, or is that usually a good example? Absolutely, yes.
19:00
What happened in this case is that we have a very contained design problem. So, you know, we didn't have to go through that many prior work or that much experimentation, because the problem was relatively simple, it was well understood, and it was very contained. Most of the times, design problems are not like that.
19:20
So, in those cases, definitely paper prototyping mock-ups drew all the hell out of it, before even bothering in prototyping it, as I did, definitely. This case was a little bit special in that sense.
19:46
Ask him a question that you understand what you can do. For example, if I am a developer of Microsoft, and I check the user interface by you, and you say, oh shit, from the beginning,
20:01
I say in this hardware system, not in the response that I would like to see at the very first, as you first responded. No. So, how do you make your mock-ups based on knowledge, what the underlying software can do, perhaps the design is bad
20:22
because the underlying system is bad, and you cannot do much more. No, that's actually a good point, but I think, from my point of view, it actually made me reconsider some things in a good way. And it's true that I had to rewrite
20:40
some of the backend, because it didn't match what we wanted to do, but I think it's an advantage, because if she would have limited herself to what the system could do, then we would not have come up with such a great design. Sure, sure.
21:02
So, first of all, we did have a conversation before I sat down to design, so I could understand a little bit of what was going on behind S-Review. Yeah, but it is my road to challenge that as well. So, I did, and he took up the challenge. So, you are going to be challenged by your designer, and I think that we need to live with that,
21:20
and we work together iteratively to balance that challenge and come up with something that was feasible. Right, right. The absolute very first one had a few things in there that were not workable, and we talked about it after the first iteration, and we worked that out, and we made a few improvements. I think we had three or four iterations in total.
21:40
So, yeah, definitely, I mean, if it's just the first one, and that's it, or the highway, that doesn't work. That's not what we did. We had a discussion about it first, then she made a mock-up, then we discussed that mock-up. Based on that, we made a few more changes. So, it's an iterative process, and that way it does work. I do agree, if you just make a design and you don't care at all
22:00
about the backend, that's problematic, but that's not what happened. That's definitely not what happened. Folks, we need to wrap up. We're out of time. Thank you very much for being here, and thank you. Thank you very much.
Recommendations
Series of 2 media
Series of 4 media