 But, okay, so this is gonna be a very informal talk because I didn't prepare slides and I thought, you know what, let's just talk and not make it like a big thing and also because I'm lazy. But that's all right. Let me give you a little bit of a whirlwind tour of my history with Fedora and its websites. I've been working with the Fedora project in some capacity since 2004. In that time since then, we've probably redone our main website six times, maybe. Sure, what's the question? Oh, sure, sure, sure. Oh, yeah, yeah, yeah. So let me start with my slug here. So my slug is I wanna talk about a project that I've been working on with both Mary and an intern who recently finished his internship, Eric, called Pattern Lab. So there's an upstream project called Pattern Lab, it's probably patternlab.org or something and the idea, how many people here have heard of atomic design? Yeah, okay, so it basically follows atomic design principles and gives you like a nice little framework to plug in your actual design patterns. So we've been trying to build that out based on Fedora Bootstrap, which Ryan has created just so that Fedora Bootstrap has a documentation to it and so it's usable both for designers and developers to figure out how do you make an application look Fedora, right? So back to my little whirlwind tour. So yeah, we've, as Fedora has changed its website and updated and built out our infrastructure and built out more applications, the whole practice of web application design has sort of evolved along with us. And one of the things, and I think that this is an issue with all open source projects generally or all community focused volunteer projects is you tend to have little islands and like, oh look, it's a new app and it has a completely different look and feel because they're using Ruby on Rails and Ruby on Rails comes with this thing and it looks like this and we'll just go with that or it takes hard work to make designs consistent and to get a look and feel that goes consistently and integrate different applications. Sure. It's mostly, well, so it has a bit, let me just show it to you, all right? Again, shout out questions, this is totally informal. I will caveat this with I really do not like upstream pattern labs look and feel at all. I really don't like it, but I haven't spent the time on it. I've been trying to just do the patterns first. So the first part and just as a quick overview of atomic design, atomic design basically looks at the different design elements of a web application and breaks them down in terms of their scope. So it's extremely tiny, I kind of need glasses and I still don't really see them. In the upper left you'll see the navigation sort of shows you the different categories or levels of I guess the hierarchy of the atomic design. So your first thing is atoms, right? So things that are atoms are sort of like really just basic HTML elements like, I'll go in here, a button. This is why I don't like the UI, hold on. Yeah, so things that are sort of at the atomic level, this is the smallest unit, like an atom, well, like an atom in 1940 something. You can't break it into sub parts, we won't talk about quarks. It's things like the brand colors. It's things like the fonts that we use and it's not showing the other ones, that's okay. The other things would be parts of forms, so like a form button. Basically like your standard HTML elements and maybe a few other things that you come up with, just the base components of design. Then you move up to the molecules and molecules are kind of compositions of your atoms. So here like instead of just a form button, you might have, this is a whole form. Let me see if I can't, yeah. This is an entire form and this form as a unit is a molecule design pattern. You're making a form, follow this pattern. Then you go up to organisms. So if anybody's familiar with Bootstrap, here's kind of a classic one is cards, right? Kind of like each Twitter message is a card. You have sort of the cap and the title and the, so these are organism patterns. And then you have templates. So these, for example, you have a blog index. You have, you have a form, that's probably a more complex form. You have a dashboard, right? So these are more patterns of things. And then you have actual pages, like a login page, or you have the about page. And these are things that occur over and over in websites. But you can kind of see how you start with the smallest unit and you go up. So it's sort of organizing your design patterns in terms of how substantial they are. And we really need to do that for Fedora. So that's sort of why Ryan has been working on Fedora Bootstrap and sort of the whole point of this exercise is to document it. So you can kind of see where we filled in some of this stuff. These are the Fedora brand colors. So it's sort of, I guess the point I was trying to get to is it's kind of part brand book a little bit. And then it's kind of part actual UI, you know, documentation. Exactly. So one of the ideas here is I'll take an organism that one of my interns worked on. Let me see. You know what it might not be, hold on. I'm going to go docs.paguer.org slash pattern lab. Here, let me just flash the URL if you want to take a look. I try to build it pretty frequently so that you can see the latest stuff. And I know that I put his things in there. And one of the vehicles that we're using to figure out what the pattern should be. And they're not all in Fedora Bootstrap. I think we need to upstream some of this stuff. But we're looking at sort of the UX design for Fedora Hubs to try to pull out some of those patterns. Like, for example, this, let me zoom in a bit. Like this left nav here. That's sort of a specific pattern, right? And then like over here, you have like the community rules box. You have the subscription bar and these different widgets. Those are actual patterns. And we should, the process that I've been following so far is trying to get to a base implementing an HTML and CSS as an example pattern. And then further down the process, I would like to upstream all that the CSS and HTML kind of stuff into Fedora Bootstrap so that anybody who can pull in Fedora Bootstrap can use any patterns in the pattern library. We haven't done that yet. So when you go to the Pigour Doc site, it's a little bit of a hack together mishmash right now. So don't look at it too closely. But let me see if I can find. Yeah. So these are examples of some patterns that Eric worked on this summer. And for every pattern, there's this little arrow that you might not even see. It's like in the far right. If you click on it, then it gives you a mustache and HTML to implement that. Where we're a little rough here is ideally all you would have to do is include the Fedora Bootstrap and then you could use this example code and it would just work. But right now that is not the case because we have not yet upstream the CSS. So what the Fedora Hubs is doing right now, which is very messy, is it's actually just taking the pattern lab CSS and including it to get these styles. But I want to break them out and properly upstream them into Fedora Bootstrap, which we could work on during the hackfest after this. That would be very, very cool. Yeah. Right. Right. So just for the purpose of the video, the question was is Fedora's infrastructure all already using Bootstrap and what do you do if a developer comes to you and they want to use something that's not compatible with Bootstrap, right? Really the only solution is to kind of lay down the law and say okay, this is the way we're going. But you know, with web development what I've kind of learned over the years is there's always a new shiny and we like to abandon things that we standardize on. Like the sad story there is when the Fedora Project site used 960.gs, which was a cool grid system for a while and then it wasn't cool anymore and we were kind of stuck with it. So we've kind of moved on to Bootstrap. We have a lot of legacy stuff that's not using it. We have a lot of legacy stuff that may be using Bootstrap but it's not using Fedora Bootstrap yet. So it's just, if you're a designer or a web-minded person, it's a really good way to help Fedora out is to help us convert these things over. Right. So what Ryan was saying is basically we kind of went Bootstrap because we do get stuff from upstream that's Bootstrap that we want to integrate kind of off the shelf and it also has a, it's a solid community, right? So if we want to get people to contribute and we say, well, we standardize on Bootstrap, we have a larger contributor pull to pull from just because it really has become a standard with all this stuff, you know, like there's SaaS and then there's SCSS and then there's less and it's like, you don't really know which one to pick and which one's going to win sometimes. So sometimes it's better to hang back but I think at this point Bootstrap is pretty safe to go with and if somebody wants to do something different, they kind of have to, they have to also take the cost of doing something non-standard. I mean, another thing that you could do that I don't know that Pattern Lab has built in if you were going to use Pattern Lab specifically but you could always have it sort of break out another tab and be like, well, if you're using Bootstrap, this is, you know, what you would use but if you're not using Bootstrap, if you're using some other system that has a trendy name you could just make another tab for that but it's more work on the designer too because then you have to do CSS for two separate systems and learn both systems but I mean, it is possible to do that and there's other Pattern Libraries like Pattern Fly, they do stuff that's, you know, standard CSS and then they'll do stuff for different frameworks, you know, so it's possible to handle that too if you really need to. Yeah, it's actually, so it's, again, it's like, you know, not complete, it's definitely a work in progress so my thought is right now we're just putting in the patterns and then once we have a decent set of patterns, we'll probably have a lot more documentation and framework around them because right now Pattern Lab just spits out and like I can show you the way that it does it. So there's just directories that show and I hope this is big enough I can make it bigger but there's just directories for each level and I know like the term, like the atoms, molecules, organisms, I mean, we could probably rename it too but that's like the standard atomic design terminology. Yeah, okay, so you're struggling with how just pattern libraries in general, how are you even supposed to make use of it? Yeah, right, right, so well, so my goal here and I may be misinformed, if anyone knows better, please let me know. My goal here is the Pattern Lab that we're doing for Fedora, I'm hoping would basically serve as a documentation or a how to guide using Fedora Bootstrap because right now to use Fedora Bootstrap, you have to know what exists, you have to know where the repo is, you have to include it in your project and then you have to kind of read through it to see what it gives you. Whereas with this, like the idea is, well, I wanna make something and I'm hoping we'll categorize them nicer so they're easier to browse but you know, I wanna make something that's a widget that has to do with events. So here's a nice little, it's all pre-designed for me, it has like the date and the time and blah, blah, blah and you can just go in and grab, all you would have to do is include Fedora Bootstrap in your HTML, so like in the header, you would do a CSS include and whatever, is there this JavaScript in it too, right? You just include Fedora Bootstrap in the header of your HTML and then you would just copy paste the example HTML, put it into your template or into your file, however you're doing it, whatever framework you're using and it's already pre-loaded, like you see how it has class, C, widget, meeting event, that would be in Fedora Bootstrap, so you don't have to worry about, oh, well, what's the class that I need to apply to this element to make it look like this? You just grab the sample HTML and then you just fill in the data, however you get the data from your app and it'll look the way it does in the example and the only thing you really had to do was include Fedora Bootstrap. So that's sort of how I envision it working, does that sound like something would work for you or do you still find that a little confusing? Right, so I mean it could be a matter of the usability of their actual pattern library, yeah, it's a little rough, I haven't used it as of late, like it's been a while since I've looked at it, but that is the general idea, it's sort of like I'm including this pattern library, I'm including this Fedora Bootstrap or pattern flyer, whatever, and then this is just supposed to serve as the documentation, how do you actually use it? You know, oh look, here's a goodie, I wanna use this, how do I actually use it? Copy paste, fill in the data, done. So that's like the main point. Why did I go with pattern fly? Or pattern lab? Yeah, right. So the question is if you're not a UX designer and you're looking at this and you wanna make a new widget, how do you make it so it has a good UX? You really need to talk to a UX designer. I mean the robots at this point can't replace a UX designer to step back and like Suzanne kinda walked through in her talk how you have to step back and do all this research to understand what is the user goal, what is the user's workflow, how do we figure out and prioritize what they need to do and you know, using the hierarchy of the design of the screen, the visual hierarchy, how do we promote different things and demote different things to make a smooth workflow for the user, those are all things that a UX designer needs to do. If it would be helpful, one thing we could put on the roadmap for this is to have a little paragraph that talks about why we designed it this way and I mean one goal that I have for these is and pattern fly does this and I do like how that they do this is they test each pattern that they have, they do usability testing to make sure that the goals of each design are being met by the actual user test data. So we could test them too and talk a little bit about the test results and talk about the strengths and weaknesses like this widget was designed, I'll use this as a specific example. The reason that this widget was designed the way it was is the number one thing, so whenever you have any kind of visual design, there is a hierarchy. I don't know if anybody's familiar with gestalt principles but it's things like, one of these things is not like the others so it stands out. So if you have like a list of red things and one is green, the green thing stands out or like this thing is big but everything else is small. The size, boldness if this is bold and that's not bold, the thing that's bold stands out. You can use gestalt principles to kind of set up a visual hierarchy so that when someone looks at something there's a certain order that they notice things. So the number one thing looking at this design team meeting widget that you notice, the number one thing is November 4th. The reason for that is that Fedora meetings, well first of all the context around this, in a different context this design might not make as much sense but in the context of Fedora meetings and team meetings in general they usually happen mostly on a weekly basis and not more often than that. So when you're thinking about units of time, the unit of time that's most relevant is the date because that team isn't gonna have multiple meetings in the same day so the actual time the meeting occurs at is less important than the date. The date needs to stand out because it's only once every week. Does that make sense? The second thing that stands out in the visual hierarchy arguably is the add to calendar. And that's so people, the idea is that you need to know the meeting's taken place. The second thing is that you might want a reminder for the meeting, you might want to add it into your own system so you get email alerts. So that's the second thing that when this design was created that was the decision that was made. The third thing is the name of the meeting design team meeting. It's third, even though it's sort of the whole point because the idea is in context but most likely this widget is gonna be on the design team hub so you already know you're talking about the design team so the name of the meeting isn't quite as important. You already have the context set by the surrounding page. The third thing in the hierarchy again arguably, oh the fourth thing, arguably is the time it's at or the channel that it's in. But those again, it's important information to know but it's not as key as like knowing what date it is because if the channel was the first thing that was the most important, okay I'm in the channel but the meeting's not happening because oh yeah it's not today. Also important to think about when you're looking at a design like this what isn't in there, right? Maybe the name of the person who's running the meeting is that so important? Probably not, I mean it's important but it's not so important that it needs to be bubbled up here. A lot of design is actually removing data like not showing the data making the decision because every time you present the user with a piece of data you're contributing to their overwhelm so you wanna really work hard to not overwhelm the user and only curate information and bubble it up to them in a way that's gonna make it most useful. So that's just like a quick rundown and that is certainly a paragraph that I could write for every design pattern we have in here we could write that out and then that would help a developer who maybe doesn't have the UX experience to evaluate well what is this widget good at? This widget is great for a context in which people know what the team is they know what the meetings are about. If you had a list view like we were talking about with Paul yesterday like if you had a view of all the Fedora meeting channels and all the meetings that were taking place in each channel this design might not be the best because you know what day it is what you really need to know is what the meeting is about in which case the name of the meeting should be the top of the hierarchy not the date. So you see those are sort of trade-offs that we can absolutely document with this. Does that answer the question? Does that make sense? So and these are things that we can all like if we have the you know Suzanne talked about assumptions right those are a lot of assumptions in there that this widget's on the design team page. If we list out those assumptions then we test based on those assumptions then we can see how effective a design that it is. But yeah, does this project I mean I know we have like five minutes left but does this project seem interesting? Does it seem like something we should be doing? Yeah, cool, cool. Yeah, so I will say because I see some technical folks in here I am not a really good user of Git it's my deep dark secret except it's not that secret because I pitch about it on Twitter all the time. So I actually forked this from Upstream Pattern Lab I want to say like eight or nine months ago and I haven't pulled from Upstream since then so I know I have a really painful merge coming up but if anybody has the fortitude to deal with my swearing at Git to help me through that process because I've never done it before that would be like something we could work on. Awesome. Okay, yeah, because we had the hack fest after this. Some other things that would be helpful. I guess I should have probably talked about for Fedora Hubs, I know it's in GitHub I would love to move it to GitLab or Pagora but we have a GitHub site Fedora Design Fedora Hubs and we've been using Sparkle Share to work with this but this is basically this GitHub site is where all the mock-ups are for Fedora Hubs. So this is where I had Eric was looking at he was working with, oh wait, I went back too far, Style Guide. So there's a directory in here called Style Guide and what I did is I went through all the different mock-ups and I pulled out individual widgets and I just put them in a single file so he could go through like widget by widget by widget and just implement it in Pattern Lab and you can kind of see where he left off in the list. So if anybody wanted to start implementing them in Pattern Lab, it's really easy, it really is. So I can show you up here. The tough part is figuring out for the pattern you're working on is it an atom, a molecule, an organism? Mostly we've been putting them in organisms because like a whole widget, it has forms inside it, it has buttons inside it, whatever. So most widgets we've been putting under organisms. I think ideally we'd probably rename organisms to widgets but not right now because I don't wanna break stuff but you just go into the directory once you make that decision and then you'll see there's like global cards, forms, lists, modal, section, text. I believe I made the modal section but for each one then you have an MD file which is marked down and you have mustache. So let me show you the easiest contribution you could ever make to an open source project. You just put the name of the pattern. This one is modal and then like the detailed name of the pattern, basic modal dialogue and that's all you need for that file and what that does is it shows up, let me see if I can pull it up here. The modal patterns are also interesting in that you have to click a button to trigger them so they're not in line on the page but whatever but what you write there shows up that's what's used for the header here and if you wanted to write a little bit of text like the explanatory text I was telling Saiyan that we could do, you can write it in that mark down file too. You could just put some little story here about the modal design, blah, blah, blah, blah, blah. Okay, so then the other component to making a pattern is doing the mustache and I'm not like, mustache is I think really just pseudocode. It's not like a language really, right? I mean just pseudocode. And I think the reason they call it mustache is because you can use the curly braces that look like mustache in them. Like you know, some data goes here. I think that's why they call it mustache. Oh, maybe. It's JSON like, oh. Well, I used examples that were in pattern lab and they didn't have them. What they had is like just, oh well you mean for the actual data input, right? Yeah. Yeah, yeah, yeah. Yeah, because they look like a mustache on its side. Yeah, so I think the only reason that it's called mustache is because of that and then you put whatever the data, yeah. Anyway, I found it confusing and intimidating like what's this new language, mustache? But no, it's not. It's just like pseudocode. Yeah, right, right. Yeah. Yeah, it's basically HTML kind of templated. Yeah, so you just open up the mustache file and you basically use the HTML elements that you mean to use and then you just add the classes from Fedora Bootstrap or the ones that you made up that you haven't upstreamed yet and that's really it and then pattern lab will put it into the section. So like I made a modal folder, so it made a modal section and then for each pattern, I think it does an alphabetic order off the file system, it just inserts that code that you put in there. So that's really all there is to it. So if you wanted to go through some of these files and like pull out the widgets and decide okay, I'm gonna do this widget, I'm gonna turn it into a pattern, it's really not difficult. So that's another way that, you know, if you wanted to contribute it to this during this hack fest, which is now just starting, you know, that's another thing that would be helpful. Another kind of bigger project that would probably be a little bit longer term, but if you wanna get started, if you're good with CSS, we need to take some of the pattern CSS and upstream it to Fedora Bootstrap. Ryan is here, he's the Fedora Bootstrap guru, so he's a good person to work with on that, but to get this stuff upstream so that we don't have it all stitched together in a hacky way in hubs, that would be very good. So, any other questions? Sure. Am I planning to bring the libraries and classes for? Yeah, so the idea is sort of hubs is kind of the guinea pig, like we're using hubs to come up with the patterns and document the patterns, and ideally I would like for them to be used across Fedora infrastructure, so you may have some other application in Fedora, but a pattern that came from hubs might be useful for your app. But yeah, we'd like all of the CSS that's in hubs to kind of be patternized and then upstream it to Fedora Bootstrap so that it's not even sitting in hubs, it's in Fedora Bootstrap. Does that make sense? Is that graphs? Oh, you mean graphs. Oh, hmm. I guess, yeah, we could be using, I think we have some things in Fedora infrastructure that use D3, right? Yeah, yeah. Oh, Pagore has like the little graphs. Yeah, so Conica, if you wanted to look into figuring out, well, where are we using graphs? Can we document them in Pattern Lab? Those would be perfect, because that's one section that isn't even in like the upstream templates that we got, because we do the Pagore contribution, like bar chart graph is one, the D3 things in Hyperkitty are another, and if you can think of other places that we could or should be using graphs, I think graphs is a great pattern area that we could be documenting so that we had consistent graphs across. I know we have some graph designs that one of the Fedora Hubs UX interns did a couple of years ago, but they haven't been implemented yet, so we could figure out how to implement them and do patterns for those too. So yeah, that's a really good area to work on if you were up for it. Cool. In Bootstrap. Oh, right, right, right. Yeah, so that's another thing is we could document the patterns you have in Fedora Bootstrap that are unique to Fedora Bootstrap, like the Masthead, yeah. So what app would you say has the most that needs to be upstreamed? Kind of figure out which one to standardize on and go with that. Sure, cool. Yeah, so there's a lot to work on, there's a lot to do, and the cool thing about all of it is none of it is really particularly hard. You just have to sit down and do it. So that's what we'll do now. So I guess we'll stop the recording. Cool, thanks everybody. I hope that made sense.