We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

An OSD Case Study

00:00

Formal Metadata

Title
An OSD Case Study
Subtitle
How we redesigned the FOSDEM video review interface
Alternative Title
Open Source Design in the trenches: a case study
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
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
Early in 2018 I responded to a call for help published in the Open Source Design jobs board (https://opensourcedesign.net/jobs/). It was from the maintainer of something called SReview (https://github.com/yoe/sreview), which happens to be the software FOSDEM uses to capture, post-process and publish the videos of all the talks at the conference. Over the past 10 months we redesigned the SReview interface in a user-centred, collaborative, iterative and open way. This talk explains how we went about it. Using a model of the "ideal" design process as a reference, we'll show where we deviated from it and why. The moral of the story? There is no best way of doing design. The best way of doing design is the way that suits your project. Early in 2018 I responded to a call for help published in the Open Source Design jobs board (https://opensourcedesign.net/jobs/). It was from the maintainer of something called SReview (https://github.com/yoe/sreview), which happens to be the software FOSDEM uses to capture, post-process and publish the videos of all the talks at the conference. SReview takes a rather ingenious approach to the problem of how to review presentation videos before publication. Instead of the small video team doing all the work, which would take ages, they crowdsource the task, by asking the speakers themselves to review their own presentations. Speakers get an early preview of the video - something they appreciate -, and the FOSDEM video team gets the job done faster. Everybody wins. There was only one small problem: the interface speakers had to use to review presentation videos was not working. Speakers kept making mistakes in the process, which caused a lot of extra work for the FOSDEM video team. Over the past 10 months we redesigned the interface in a user-centred, collaborative, iterative and open way. This talk explains how we went about it. Using a model of the "ideal" design process as a reference, we'll show where we deviated from it and why. The moral of the story? There is no best way of doing design. The best way of doing design is the way that suits your project.
Observational studyOpen sourceVideoconferencingInterface (computing)Interface (computing)Software maintenancePerspective (visual)Interface (computing)VideoconferencingMusical ensembleComputer animationJSON
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
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
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
Point cloudComputer animation
Transcript: English(auto-generated)
So, related to TOSDEM and how TOSDEM is done, I think it's very interesting. And please welcome our voice speaker, Chris.
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.
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.
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,
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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,
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.
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.
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.
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,
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...
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.
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,
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.
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,
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.
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.
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.
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,
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.
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,
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.
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.
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...
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.
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
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.
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
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?
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?
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
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,
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.
We could maybe use some system where you can file bugs more easily or something. We use GitHub issues, and that worked kind of.
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
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,
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,
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?
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.
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?
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,
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.
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.
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.
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,
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
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
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.
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,
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.
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
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.