 So we're going to start, we'll have the graphic talk about the UX of UX. So yes, this is the UX of UX. It's a pretty meta topic, but it also is, actually this talk is very important to me because a couple of months back I realized that I actually completed five years with open source, primarily with design. This talk is mostly about what was my experience as a person who didn't know how to write code, as a person who just knew how to design a couple of few things. I mean, when I say I don't know how to write code, I say I didn't even know how to write proper semantic HTML. So I started from there and it's been five years. And this talk is about the behind the scenes of how I picked up. Who am I? I'm Raghu Nayir. I'm currently a master's student's interaction design. I am a huge open source fan. I was working on open source software before GitHub happened. There are things which are on Gatorious. So I've seen the transition happen from Gatorious to GitHub, Gatorious to GitHub, GitHub to GitHub, all sorts of things. Yes, a couple of things. I mean, it's story time five years back when I was starting out in design, a couple of things which happened to me which were so awesome, which if I think look back and I think about it, I won't have started with open source design if it didn't happen with me. So this talk is mostly about that part and my learnings from those things and what to avoid and what not to avoid. The first thing, yes, if you're working on an open source community, be welcoming. Now by being welcoming, I don't say, say hi, reply back to emails, you know, small talk, chat, chat, no, by being welcoming, I mean, do contributors maintain the spirit of the project? It's important. I mean, you've got to be welcoming for them. You've got to document your contribution guidelines. Contribution guidelines should actually include getting started, should actually include the code of conduct, style guide maybe, but even if a project is small, having these small, small, small things, either one of them or all of them makes the project extremely welcoming for a person who's kind of shy, doesn't like to write emails to people and is just looking out for the right thing. It worked out for me because this is something which happened. Using Viki effectively, Viki gives us an awesome option of adding Viki pages, which is kind of underused for a lot of open source projects, kind of overused for a lot of good open source projects and I kind of love that. So using Viki effectively made it super simple for new people coming in. Using tags. Now tags, a GitHub issue tracker has a feature called tagging. Yes, everyone probably here knows that. Now by tags, I see a lot of repositories use tags like UX, design, starter jobs. For me, my personal favorite was back in the day when I came across this. This primarily changed my outlook towards open source design and was the biggest factor how it got hooked into open source design. Junior jobs plus design. Junior jobs can be developers. Junior jobs can be for designers. Junior jobs can be for content people. Junior jobs can be for everyone. So you've got to subcategorize your junior jobs. Not just use junior jobs. Subcategorize them to smaller, smaller, even smaller categories so that the right person reaches the right place. This is the easiest way to get people on board when you're doing open source design. Onboarding. Onboarding was important. Now by onboarding, I mean software onboarding. So five years back or like maybe three years back or maybe even yesterday when I'm looking at a new open source, cool open source project and I really, really want to feel like I want to contribute to this. I mean this is awesome and I would like to contribute to it. Something like this happens with me. I've got to run some commands. I'm not a badass programmer so I'm just talking like a designer right now. You've got to start the node service. You've got to compile your CSS JavaScript and by the time it happens I'm like oh no man this is some error comes up and I just give up on it. This is the easiest way to get a person who's not a developer off-board from your project even before he has started. This happened with me with a lot of projects. This didn't happen with me a lot of projects as well so which is a big thumbs up. So reducing installation steps. The biggest example, the first thing which came to my mind when I was talking about reduction in installation steps and which everyone should need to learn from is actually the WordPress 500 install. I don't need to touch the code base. It's simple. Even the language, the content. Everything is simple. It's translated. It's like you can do this in any language. I mean you can think off. I know it's a big community but it's a simple install. It's like it's worth effort. I think this is something which has not changed in WordPress since like ever. I don't know. Yes one thing. So two years back when I was working with open source software something which happened to me and I came across this term called design objectivity. This is something which I use almost on a daily basis. Now this is like a kind of a debated topic. Design objectivity in other terms is also called as pixel fucking. Now yesterday I was preparing the slides. I was looking out for good definitions of what pixel fucking means. It took me a while but I kind of found this which was almost there. This is like someone in pixel fuck space paying attention to things like grain than the world effectiveness was shot. It was not coded by the design style. It is from the urban dictionary. So yes basically what happens in open source community and design being subjective everyone wants to be the designer. There are discussions which are very long and what happens in these discussions the best design solutions are kind of lost in the middle because everyone wants to put on their thoughts and every thought is kind of different from another. Good or bad. Dealing with design objectivity is actually a very important very very important issue right now. I had this discussion with a colleague of mine as well a couple of days back. We discussed like the way we did it. I mean the way the community I currently contribute to next lab does it is pretty awesome. So in case I'm absent and two people who have been contributing around say yes this works we lock it down. We do not take further ideas. We take ideas for v1. We take ideas for v2. So that's the easiest way to get a v1 out and that's the point. Getting a result is more important having a discussion having a super super long discussion. The other way to fix it is defining a design language. Now design language can be a visual style guide not as I'm playing out CSS here because CSS guidelines are like classes and all no I'm talking about design here. Or it can be a wiki of design thoughts that doesn't have to be no your buttons should have this much border radius. No, if I have a certain sense of UX and what I'm looking out for what my language sense is in the project if you're enough to say that you're almost there you're getting there with defining a design language. It's okay, it's fine. This is something which can also help out in reducing pixel fucking mess or design objectivity in your projects. The other thing which comes to me is feature requests. I co-maintain a repository which is a calendar application on top of next cloud and we get a fuckload of feature requests like every day probably five or something but there's a time and I'm busy I'm a student my other co-manager is also a student so how do we deal with so many of them? It's a simple logic we implement relevant requests unless all of them are relevant. It's very mad, I told you. So, good feature requests are to pull. Pulling is not a difficult thing to do. You don't need a forum for it. Now GitHub allows you to put a thumbs up or a thumbs down in the feature itself in the issue itself. So if you have people who actually request a feature and it's like I really talked about it actually becomes your V1. It's not my personal taste driving my features. It's the community which is driving my features. It's like if the community really wants it there will be a lot of people actually going for it. If there's a bug which is annoying a lot of users a lot of users will be putting their thumbs up on it. So this is a great way to figure out how which features or which bug fixes to fix. Design thinking Design thinking is actually one of the most neglectic topics. I'm sorry but that's how it is. We are engineers and it's very, very engineering driven. Now even I am turned out to be more of an engineer than a designer sadly. Yes, it's engineering driven. It still lacks. We are here already. We are here earlier. But we got to reach here. That's the difference we got to make. And to do that we got to we got to involve design since the start. Now involving design since the start can be done in a couple of ways. I know for a lot of people actually write articles not like articles like essays I say I need a feature. I mean I need this feature I need this enhancement and it can be done in this way. I see a lot of people writing paragraphs and all that. No. Just draw a simple wireframe and put it out there. It's easily debatable. A lot of wireframes and it's scientifically proven that images are ahead more than text does. So that's another way of looking at it. So that's pretty much how we do it. We put out wireframes we iterate over wireframes and we get the solution out. So involving design since the start we'll have the perfect solution or the perfect V1 at least all the time. So that's how it should be. If you all engineer it it's the easiest way to invest abusability. And which we see in a lot of softwares not even just open source even a lot of proprietary softwares we see over engineering when engineering is driving design not the other way around. We see a lot of over-engineered product we see a lot of features being implemented at the wrong place at the wrong time which could have halted and more important features should have brought in which could have been better if design was there since the start. If the design had not come in then it was the visual stage or like halfway through the process. No, design has to be in the start and I can like cry about it all the time get the design in since the start. So this is basically what I realized. So as a small recap of what we talked about yes being welcoming doesn't mean writing emails being welcoming means contributor guidelines style guides keep everything there there's a need of a lot of focus on onboarding because a lot of people leave because they could not get the software installed yeah don't fuck with pixels too much man it's allowing to reduce so many features then pull-off feature requests then you realize what's important what's not important and what can be what can be done first what can be done later on what's not a priority and involving design since the start which is probably the most important thing majority of the things we like to focus in open source design as well because we are a bunch of cool designers so yes I am Raku and I have time for Q&A any questions? For me even having a panel is not like a priority I have luckily in all the communities I've been to it has a very flexible panel like say for the month of October I have three people who are like contributing a lot to the project they are automatically a part of my panel so in case I am oh ok sure so like panel vision is like super flexible you know can you repeat the question we have a pretty strong getting started at this moment I maintain a smaller part of next cloud repositories we follow the next lot guidelines and we do have a style guide in the next lot Jan will talk about it it's not having a visual style guide even if you know the kind of content you would like to write on even that's enough sign in versus login I don't want sign in to be everywhere I would like login to be everywhere if you know your design language that's important consistency is important content is also something you just kind of look because ok this looks fine on this button so let's put this on it might just go inconsistent somewhere else so those things are smaller smaller things which can be taken care of sometimes it's important to you know to step back and say dude I'm doing this and it's going out for v1 whatever discussions happen now on it will go out for v2 I mean otherwise design doesn't move ahead sometimes it's more important to rule the v1 out than to discuss way too much about v1 and the easiest way to do that is you know getting people to agree on one and then moving on from that rather than over discussing it I mean moving on is like the most difficult part about design process you know v1 won't be like the most pixel perfect one but at least there's some improvement than what it was at v0 and that's more important so what I've been thinking about a lot is how can we sort of turn that around and think about problems because that's essentially what people care about users don't care about the coolest library to do whatever they care about sending a secure message to your friends sending a file or whatever so how could we basically not only involve you in the actual development but in the starting of the project so like the choice of actual the way I see it is every enhancement every enhancement which changes the experience in an ideal case scenario should come with at least a pen drawn wireframe I mean you don't need to be an artist to draw boxes and that's pretty much it pretty much what you need for v1 it's more easier to pen on your thoughts you just draw it you don't have to be an artist for it think about the libraries think about the user experience here this button is going to go this side it will be a better experience than to go on the other side you've got to document that part that's what I'm trying to say here drawing is important you don't have to do balsamic the choice of actual projects when you start a project in general how do you make that a new experience how do you build projects that are a good experience by default you know what I mean so no project will be this might be a very opinionative thing but no project will be default extremely UX friendly by default I mean unless you put a thought in the start itself I mean your v1 your always your iterated design will be better more UX friendly than the previous one you know what I'm saying maybe I'm doing a bad job for you my point is like you have certain projects that are clearly driven by user needs certain projects are clearly driven by development I see very few users like there's maybe elementary guys but other than that I have very few community projects that I can point to that are really driven by something that should work for average people and something that essentially has design it's very core in the actual inception of the project that's true and that's the design thinking that's true I can talk a lot about this with Ghost especially Ghost which is a blogging platform and it's super design thinking because a couple of people who formed the project are actually designers that's one really good example if you are looking for design thinking since the very start okay in a way I see what you mean I mean it's like a very commercial statement to say but having one designer on board in the very start is like the way to be at least one