 All right, cool. Thank you. I will now set press play. Excellent. Hello, my tiny crowd in a huge room. Thank you for coming. My name is Suzanne Hillman. Mo is mostly here for moral support, but she also will be able to answer questions that maybe I won't be able to answer. This talk is about the original Fedora Hubs piece of the Fedora Hubs project that you may have already seen presentations on earlier in the conference. I did the UX for most of the process as part of Outreachy with Mo as my mentor. And I am not going to go to the overview. So the overall idea of this talk is, all right, we have to start out with some information, otherwise you basically can't do anything, but then from there you've gotta figure out what else do we need to know, and how do we figure that out? So in this case, we're gonna find out what do we know in terms of the background of the project, of the context, of the constraints, things like that, and what are the goals of this project, of this UX design process? If you don't have any goals, you're not gonna get anywhere. Even if you start doing research, you're not gonna know how to interpret it. So you gotta have goals. The next thing was, okay, what do we need to learn in order to get further with this process? What do people already do? Whether there's somebody in the community that we have, whether there are competitors, I think my entire slide is not actually visible. Maybe I'm missing, I think something is missing, but that's fine. Anyway, so what do they do? We need to know that so we know what kinds of things we can do to make things easier, what kinds of things are already being done that might be useful, that might be really terrible ideas. That's the kind of thing you wanna figure out in this section. And then once you've got a bunch of information, what do you do with it? So you gotta figure out how to summarize it, how to understand what it means, and generally you wanna have somebody else to bounce ideas off of, to discuss it so that you've got multiple perspectives, sorry, microphone, multiple perspectives on the idea as you have more ideas and more thoughts on the process. Trying to do UX alone is generally a terrible idea. It's really hard to do and in most cases you don't have enough information. So that's kind of what the analysis part is. I think the part that I can't currently see for some reason is the okay, what do you do with the information you have analyzed? What do you do now? And in general, what that means is, all right, I know that we wanna go into this particular subsection of what it is we figured out. And with that information, start making some sample beginning designs, have some feedback on those designs, whether it's from somebody else in your UX group, whether it's developers you talk to or eventually with the usability testing with your actual users. So that's the kind of stuff you end up doing and then I'm gonna be saying, you can ask questions and things like that. I'm not sure why this slide is missing part of itself, but that's fine. So the next thing I wanna talk about is the general idea of how the UX process works. So as I was sort of saying earlier, you've got a lot of research. You've got a lot of research to figure out what are you starting out with? What do you know now? You got to research what people are doing that you may not already know and then you gotta figure out what the information you get means. Now you might find that when you're analyzing your data, if you have more time, you say, wait, this seems a little weird or confusing. Maybe I should go back and do a little more research. But it's why it's a two-way street. Similarly, you might say, okay, my analysis says, this is the best way to go with my design. Great, let's go make some designs. Something seems a little off here. Maybe we need to look a little closer and find other things. You don't know yet. So it's always gonna be in this circle. You tend to do research analysis design, but you might jump around. Like, once you've got a design, you might say, great, this is our first iteration. Or we're gonna publish this and then you're gonna have people say, hey, this is hard or this is really cool or this is missing. If it's gone into production and you haven't found that in testing, then you're like, okay, more research is needed. So you gotta do all those things, part of your process. First question, as I was saying earlier, what do we already know? This is a lovely visual design of a possible, oh, sorry, no, this actually, this is the original ticket in Paguar about what I was going to end up doing. That is what I started with, exactly. I started with this ticket and from that ticket I needed to say, okay, let's read what this says, let's figure out what they're actually trying to do here. Cause like it's sort of hard to say whether what somebody's asking for is actually what they need. So I needed to take a look at that and just figure out what they're asking for, figure out what the problem actually is and then go from there with some other people to figure out, okay, how do I potentially approach this? And that's why the next thing you do is what do we need to learn in order to be able to actually do what that ticket asked for? Because in general, you have constraints. You have to have constraints. If you have no constraints, you can't do work. People sometimes say, hey, constraints are bad cause then you get stuck in things, yeah, but how else do you know what your boundaries are? So you figure out what is the project I'm working on? What are its constraints? What do other sites do? What are their constraints? What are they trying to figure out? Just figure out that kind of things, in this case, around things like events and meetups because the goal of the ticket that was probably hard to read that I should have told you about then was to make it possible to have local Fedora meetups and local events and maybe integrate with other events locally that aren't specifically Fedora, we could be a presence at. That was a general idea of that ticket. So the question is, okay, what does that mean? What do we mean by local events? What do we mean by finding people nearby? What does that actually mean? Until then I went and looked at, you end up looking at other sites and in this case, go, no, no, go. That was weird. So the first thing I needed to know cause I was new to hubs was what does hubs do? What are its underlying programming language constraints? What does it have for a general structure for my design process? What does hubs do? Why is it doing it? What are we not sure about yet? Cause it was also still in process so it wasn't finished. And with the, what does it do now? What are we assuming? Because while it can be, it's fine to make assumptions but you need to know what the assumptions are. Because if you don't know what they are, then you might end up having it bite you in the butt later. You'd be like, oh, wait, I assumed that this group of people was relevant where it might have been a bigger group. So you have to look at your assumptions if you can find them. You can't always find them. You have to look at them if you can find them and say, okay, this might be part of what we have to look at in our research. Cause you wanna look at your assumptions and you wanna look at the questions you have to ask. That's about the defining of project scope. The next question as I was saying earlier is what everybody else do? Which sites do we pick? Why do you pick them? That's your competitive analysis. Finally, what do people do right now? How are they organizing events? How are they finding people to go? How is it handled right now? And what is the most painful part of it? That's called a contextual inquiry. So the problem with this is, it's where did HUBs go? So fascinating. For some reason it decided it wanted to be animated. We found it, it's back, we're good. So for the HUBs, the point of HUBs is that it has, as you might guess, lots of HUBs or groups. And the ticket, and people had already thought that what would make the most sense is, regional HUBs or groups were a type of HUB. It's not like we're doing something crazy and different on HUBs. It's still part of the underlying infrastructure of HUBs. The idea behind Fedora HUBs, for those who may or may not have watched the earlier talks, is that you're trying to get a place where you can see what's going on across Fedora projects that you are part of and your teams, as well as what is showing up in your own stuff. Like there's a whole lot of information in FedMessage. So it's good to have it organized in some way. That's a large part of what HUBs does. It has widgets along the sides and then it's got the mainstream along the middle. If you didn't watch any of the other talks, I'm sorry, I'm not going to go any further detail than that. So for regional HUBs specifically, as you can see up here is a particular kind of HUB. And the context is one particular location in the world rather than a team or a project, a place. And within that place, okay, how do we help people become more involved in local meetups, local events, maybe hackathons if you can find them, different spaces that are for working on open source projects, whatever it is that you might have locally to you. How do we make it easier to find those and plan those and otherwise just be involved locally? That's the general idea behind regional HUBs. And then, you should go. No, no, you should go. I'm guessing it was trying to animate things and I just didn't remove the animation. That's all I can guess. But so this is what I actually meant earlier when I was talking about the visual design of the sample HUBs, a sample regional HUBs might look like. So you've got the title, you've got a brief description and then you've got a bunch of things that are happening in that group. And that's sort of the general idea of how it might look once it becomes real because this is very much pattern after other HUBs in Fedora, HUBs, too many words. Got it. So that's more or less what it looks like. If you would be interested in doing design work for Fedora HUBs, most of them want to talk to you. But this is sort of the kind of thing you might be expecting to be working with. So when I did the competitive analysis to figure out, okay, what are people doing now? We did a bunch of low-cos because they were very much like the idea of regional HUBs. They're basically AOK, local group, local community, local group, that's what it was. So it was like, okay, they're very similar. I want to see what they're doing, why they're doing it, how much of that I can also use. I also wanted to look at Meetup because Meetups are really, really well-known Meetup-based interface. I didn't want to only use those two because it wasn't enough things to use for comparisons. So I went and looked for some idea of, you know what I don't have one of? I don't have one of those. Can I have one of those? Because we have letters. And I'm sort of in the middle of one of those. So on the back of the page where you've got a nice table, we have letters to try and help you follow where we are in the, basically on the back of this page is a table where I attempted to give summaries of the various steps you might take in a user experience case study like we're doing here. And so what I just noticed is that I was talking about the A, the upper, this is left, upper left coordinate where it talks about, okay, research, new product in this space. And so I'm talking about the, yes, the first bullet point where I'm talking about competitive analysis. Oops, be back in front of this. And so the point of this was, okay, get a general idea of these websites. Find the parts that are relevant to us. Okay, what do they do around events? What do they do around meetups? How do they communicate within people on the site? Or don't they, some of them didn't. How do they support the ability to suggest a meetup or create your own meetup? Or whatever it is you might wanna do around events and meetups. Just to get an idea of the overall structure and ideas like some places were like, I don't want it to be a very easy thing for anybody to talk on. I want them to only meet in person. And City of Socializer was very much in that vein. They were very little discussion online. It was basically impossible to do. But they had a lot of go out and do things together. And that was sort of the point of their site. Whereas BigTent, oh, I found those two on a useful meetup event-based things search. So BigTent was just a site that seemed to be focused on making it really, really, really easy to create groups and events. So the creation process was great. But trying to read some of the sites was like, I don't know what I'm looking at. Cause there was no real structure. They weren't really thinking about the end user who wanted to actually find a meetup event. So there were lots of different aspects to each of these things. And I used a spreadsheet as you might expect to just sort them out and figure out what's going on. So with that information, I was able to say, okay, this is what's going on right now. What does that mean when I want to talk to our current users? And so the main question is, what are the each categories of things that they wanted to do? Events, meetups, et cetera, and how do they organize it and all that? So what kinds of questions do I want to ask? I want to know what people for Dora right now are doing relating to planning events, finding events, attending events, finding people to help out with events, all kinds of things around events, and whatever else they thought was relevant along those lines. And so we found ambassadors because ambassadors often plan events, but not always. And we were trying to include all of the regions, just cause I expected that things would vary depending upon region. So we have people as you can see, some of whom were actually in the room, who were on this list who I went and interviewed using remote interviewing tools. So the main goal there, right sorry, so I just told you more or less what we found, what we looked for. What we found was actually fairly extensive and detailed, so trying to summarize it might be a little difficult, but overall the major problem seemed to be there wasn't really any underlying structure already existing in a consistent location of people to use to organize, plan, find, et cetera, events in people. So that seemed to be one of the major issues. There was just not anywhere to do it, so you couldn't find information. Then that's the kind of things I sort of found while I was looking at my interviews, and then the question was okay, we know this, what do we want to do with this? What do we want to do with all the details that I collected? As I say, a lot of data, what does it mean? So myself and Mo and Matt Miller, I'm like, I'm pretty sure it's Miller, but now I can't remember, met up to discuss what it was that I found. I had done a reasonable amount of summarizing, so we just discussed combinations of what it was that I found, what it was that Fedora was already thinking around these various topics and doing around these various topics, and some ideas as to how we might maybe address these things. So we had a lot of information flying everywhere, and after that session was done, we were like, all right, so what are the questions we have to, what are the problems we might want to solve? We're not going to solve all of them. You can't solve all of them. We'll need to organize them and figure out which ones were relevant. So I made a big list of problems, and Mo and I went ahead and did something called affinity mapping, where you take, in this case, a bunch of problems that are on sticky notes, and you sort them. Now sorting them sort of just happens, like it's not going to be the same patterns you used when you first started analyzing your data and summarizing it. It's going to be between the two of you, or however many of you there are, where do we think there's logic to the sorting? And then once you've got things sort of settled out in the sorting, you might want to label them, just so it's easier to refer to the pieces. In this case, we ended up with six different general categories. And so from there, we're like, all right, we know where the categories are, but which ones do we focus on? At that point, we say, okay, we need to prioritize these things. Best way to do that is to make a grid, and just in this case, go by how many people are affected by it, and how bad the effect is. And so we discussed back and forth what we thought for each of the groups, which ones made the most sense in terms of what, who were affected by it, and how bad it was if they were affected by it, ended up with a couple of things in the most important section to look into further. We ended up with that, we just dove deep. We found out that one of the two highest priority things ended up being not well enough, not concrete enough. It was too nebulous to address right then. So we're like, okay, we'll keep this in mind as important, but we're not gonna actually do anything with it for the most part now. And for the other one, the local resources, resources scaling and finding and scalability, which is pretty much what I said earlier, finding things and figuring out how to do things with them, we went into a really deep dive on that, and said, okay, given that we wanna look into this, let's look at each of the sticky notes that we had in there, AKA each of the problems that were in there, and just investigate them further, figure out what we think these things mean, what they might mean in terms of actually implementing them or what they'll affect, that kind of thing. So that's how we got the first ideas of what we might wanna translate into a design, because in general, most of the things you wanna discuss in here are gonna be fairly visual things you're talking about in words. So trying to put them into a design structure, it makes it easier to talk about and understand, and it means you can say, hey, this is what I think is true. And somebody else might be like, oh, that's nothing like what I was thinking about. Wait a minute. And then you have something to compare against to say, hey, okay, so what do we actually mean by what we're saying? Where are we differing, and what are we similar on? And we can just use that visual illustration of it to adjust appropriately. So it's really important to translate your understanding as into a visual representation so that you actually end up on the same page. Right, now translating into design. So as I was saying, we were like, okay, so what do we do with this information? During our brainstorming session, we said, all right, we need to know what is our main goal with this particular category? What's our goal? We want anybody trying to find information that's local to them about Fedora to use hubs to find it, basically. I mean, it's longer than that out there, but that's the basic idea. And so, okay, what does that mean? What is the way we can tell that's happening? If people are looking at hubs to find the information they need for local resources, as a matter of course, if that's where they go, we did what we needed to do. That's pretty much the success measure. And so, in order to do that, we said, all right, from what we were seeing, we need to have lists of information that can be searched and sorted about people, Fedora members, events, as I was saying earlier, and although we didn't get to this part, a master list of regional hubs. You can find hubs related to what you want to do or be where you are or whatever. And so from there, I'm gonna go into a particular mock-up set because otherwise it's gonna be way too long. So in this case, I went into a really important part of this entire concept is locations. If you don't know where an event or a person is, there's no way you can make regional hubs work. It's just not gonna happen. You need to know where they are and where everything else is. So this is a very early mock-up of my attempt to figure out how to get people to either confirm or provide their location information to hubs. As you can see, it's fairly sketchy. There's a bit of uncertainty in a bunch of questions, but that's kind of what you do. You don't start with a perfect thing. You can't, it's not gonna work and it's easier to adjust things with feedback if they're very basic mock-up type stuff. So that was my first one. And then I was talking to Moe and she was like, hey, maybe you don't want to be doing these certain things that I was doing because they were sort of confusing. And then after a little bit of more discussion, we ended up with the one on the right. Making sure it was right on both screens. With the one on the right, where it's no longer about things you can click to go away. It's just nice little boxes that are structured prettily. And that's the kind of change you might see. You go from this, which is sort of weird looking, and this is a little better and that one looks more structured and easier to use. So that's the kind of thing you see as you get feedback and discussion and all that kind of thing. Obviously the one that's now is even better than this, but so then we ran into this problem. Locations are really complicated, especially when you're talking about international locations. Sometimes they're states, sometimes there's provinces, sometimes there's nothing, sometimes there's other things I can't remember the name of right now. There are so many possible things between a city and a street. So you can't easily just make a solution that will succeed for an entire international stage, at least not easily. So in our case, we're like, okay, we need to go address this. And so we had a long discussion, so long, it was good, but a long discussion. And we're like, all right, so what do we actually need to know? Do we care about street addresses? Honestly, no, not really because we're talking about near each other, which can mean a city or maybe even a county. I mean, it doesn't need to be to the level of street addresses. So we just said, okay, we're not gonna ask that. We don't need it. No privacy issue by not having it. Good, we can get rid of that. How about the weirdness between a city and a street or a city and a country? Like, how do we handle that? We're not sure, oh hey, we can put it on a map. And people can just know by looking at the map what the name of the state or province or whatever it is that they're actually in is. They don't need to type it in. If the utility uses GPS, it'll figure it out and show you this. If you don't, there are other ways we handle this. We did a bunch of ways to try and handle that, but that's the kind of idea behind it. We just completely changed the interface to ask people where they are. And then the question was, all right, what does the developer think of this all? Because of course, you don't wanna say, hey, make this thing and then have it impossible to make. You gotta talk to your developers. Interestingly, locations came up again in a different way. So in this problem, the question the developer had was okay, but how is the hubs going to be able to handle suggesting that people who are, we were thinking about having people who were near each other after a certain number of people near each other suggesting that a hub, a regional hub should be created. And he's like, I don't know how we would even do that. Like, I don't understand the concept enough. We didn't go into it in detail then, but that's one of the things that needs to be addressed again later because it's a potential significant issue. Without being able to suggest hubs, it suddenly gets a lot more complicated to make regional hubs. So then the question after we got the feedback from the developer is, okay, we need to test this out on users, because you always want to test it out on users. No users, you don't have any idea what's going on. So users are good. But the way to do that, you have to plan it out. In my case, we needed to plan out the session based on the kinds of things that I had in my mockups which I turned into prototypes. Okay, what can you actually do on the screen, right? If you don't know, you can't make a task. But once you know what the possibilities are, you say, okay, I can do these things on these different prototypes. Which ones are most important right now? Use that same little grid thing from earlier and figure out how to prioritize them and then figure out which particular pieces and which tasks that you come up with you actually need to know now. In this case, I was having a little bit of a hard time freezing things, which I'm always great at. And so I sent her a task for one of my prototypes, again, with the locations. And she's like, all right, this is a better way to put it, to make it easier for your user to actually know what you're asking them to do. So you will often need to adjust how you're phrasing, just so it's less confusing to your user. And then, after I did a bunch of usability sessions, we had some interesting, so this is one of the prototypes that I used. And in this one, the question was, okay, I have no idea if I know any of these people. I can't tell by looking at the screen. If the question, we were talking about, was going to Berlin and trying to find somebody to talk to and visit it while you're there and you don't know who you know already, that can be really hard to do. Like, well, who do I know? Who do I want to hang out with? Or, who would be fabulously interested in meeting up somebody they don't already know? Can't tell that either. So there were some major issues with, okay, how do I select somebody from this screen? And that's the kind of things I found out as part of the usability session, is just like really important stuff that I had not thought about at all. And that's the kind of thing you might find out in your own usability sessions. I have forgotten to continue updating you with letters, I'm sorry. And so there, we got to the point of doing usability sessions, looking at the data I found and doing a little bit of analysis. Unfortunately, we actually ended right then. And so the questions now are, okay, what do we do with this information? Do we do a little more research? Do we start doing some updating, probably updating the designs with the information I found and then more usability maybe. But the question is, what are we doing with what I have? And the answer is probably all three of those things. More research, more design, and more other things that I have forgotten because my brain isn't working. Analysis, that thing, analysis. So that's the kind of thing that we would go from here. I'm not sure yet which direction we'd go because we sort of stalled out because, A, our reach ended and B, hubs is still in process. So that's how far I got with that project and I talked really fast. But thank you. If anybody wants to help out in general with hubs or with design, hubs is obviously up there if you wanna reach, go to it. My portfolio relating to Fedora Hubs is a link on the front page of the handout I gave. We actually have a little bit of time left so I didn't do too badly. Does anybody have questions? Yes? Yes? Yes. We were building it on top of, the ticket was specifically about adding two Fedora Hubs, the ability to have local stuff. So we were trying to leverage it into the existing Fedora Hubs so Fedora Hubs itself is in process. So I'm not sure if I answered your question because I'm not sure how directly, yes? We did also, I mean, so the way that the design works is when you sign up for a Fedora account in the FAST system, we actually do have a way to store a user's GPS coordinates. So some of the map location stuff that is in the design is based on storing the coordinates there. So we would use that data store that's been in place for years in FAST. So we did use existing infrastructure where it existed and a lot of the new stuff is just because it didn't exist. One of the interesting things I found out when I was trying to figure out the location stuff is FAST asks you for your longitude and latitude and not your address because locations are so annoying. So anyway, more questions? Yes? I'm sorry, why'd you want to know? So the question was if we're talking about events or people, in my particular case, the stuff that I showed you was mostly people, but it's both. I just didn't have time to cover everything. Yes? And I do want to point out, Suzanne's portfolio link is on the handout. She wrote a series of excellent blog posts sort of walking through the design as she went through it and those are really great narratives that really dive a lot deeper into each aspect she talked about today that goes both into the design and the design process. The blog posts are separate from my portfolio, but there are links within the portfolio and there is also a link to my blog on the main page of that site. Anyone else? Did I go too fast? Go ahead. I'm sorry, what is the question? Know about them? So that was a good question because we had a hard time with it ourselves. We are probably not initially going to try to figure out events that are not in Fedora because finding them and pulling them in is hard. We are going to be trying to integrate stuff that is integratable, but mostly we're thinking that people will be creating the events in hubs and that will automatically propagate it throughout hubs. Cause, yeah, that's a very good question. Anyone else? Okay. Well, thank you very much for coming and for having questions.