 This is a huge stage. Only halfway there. OK, so this is my first slide, and it kind of tripped out the tech people because it looked broken. But I want to talk about big design troubles in open source. Oh, yeah, here, big. This is the biggest word I put on a screen, by the way, ever. Design troubles open source. All right, and that's the face I make a lot when I'm designing. And I wanted to talk about why and how we can improve that. I'm Michael R. Stead. I work at Automatic. And most of the projects I work on happen to be open source, and I've contributed quite a bit to open source projects throughout the years. So I love it. It's a great community. There's great people. And I've learned a ton of things on all sorts of subjects across the years. Most of what I did at first was a bunch of CSS things. I was one slide behind on my screen. And then I started getting into some bigger projects. I jumped into WordPress a little bit. And it wasn't necessarily out of passion, which I'll talk about later, but it then evolved into a passion. And now I work on Jetpack and Calypso, which is the React-based interface for WordPress.com. And let's see. I have just a little bit of experience behind me on this. Let's see here. So I want to talk about onboarding designers to start. That's where open source projects usually have a rough time. It starts when a designer gets a little curious. They have an itch. And they discover a project that helps them with that. But they find they have the skills necessary to improve the project for other people. But it's usually a project built by developers, by developers, and just four developers hoping to solve a project or a problem. So if they join the project finally, they have to get past these preconceived notions. And I want to talk about those first. First of all, open source is code. This is usually what my screen happens to look like. And a lot of the time, open source projects are really code-based. But they could all use design in any sense on tickets, sketches, wireframes, any level of design. So it doesn't have to be just code. Another preconception is that open source projects are very difficult. That's not true. There's a lot of really, really cool projects, really new projects, that if you're jumping in early, it's really easy to get started. They have no rules. The world's your oyster on those projects. But some of the more established projects have just tons of commits. And even this Gutenberg, which we've been talking about all week, it's already at 1,700 commits with 32 contributors. It's already kind of a pretty popular established project. So it may be a little intimidating to start. Fortunately, this one's rather easy. And that open source is slow. And that is largely driven by the fact that it's hard for people to convince developers out of the blue to switch what they're doing and work on their cool design thing. But open source is actually really fast. This is just a bunch of active tickets from the last couple of days. And they tend to open and close really quickly. People are solving things so quickly. It's just a matter of convincing people to work on your project. So it can move pretty quickly with the right group and after making a few friends. And some of the rougher parts of the project are caused directly because they're developer-led. The tools are for the developers. And I want to start with, basically, the tools allow the developers to have control over the project. They're really comfortable with these tools, and they use them all the time. These aren't tools people outside of the developer realm are used to. So terminal is a scary thing. And it's the primary tool for building projects. There are some GUIs for building SAS and some other things like that. CodeKit's a good one. But most of the tools, you've got to open up terminal and understand some basic terminal language. Then there's the communication tools. These are pretty rough in some communities. They tend to be like IRC track. Chromium uses some crazy bug tracker that I've never seen before, but it's really kind of scary-looking. And then there's collaboration tools like, again, Slack and IRC are really pretty good. IRC has a bunch of web portals. Slack is very friendly and has emoji support, which I love. But my recommendation is to use modern tools with wider reach. So instead of sticking to your old tools because you like them, look at where designers are. Or look where other people are collaborating that aren't developers and find something that's a little more useful. GitHub isn't ideal. It's not perfect. But that's where a lot of people, a lot of designers, are contributing because they've done a good job working with the interface to help collaboration along. With WordPress specifically, we do almost all of our feature projects on GitHub now. And I think that's a good telling sign. When we're on GitHub, they get all these contributors out of nowhere. They move really quickly. People are creating and busting through issues really quickly. It may not scale for WordPress, but it's working really well for our projects themselves. Then once we merge those projects back in, we see a huge drop-off in those contributors continuing to work on those projects. And partially, the projects are moved in, but there's usually a lot of issues remaining. My next recommendation for onboarding is to make the projects really accessible. So again, I'm going to promote GitHub because that's where a lot of people are. That's where a lot of code is happening. But there's also new, cooler ones, like Glitch is this app sort of collaboration project that all sorts of really experimental things are popping up from artists, from developers, from just all sorts of cool ends of the job spectrum. And provide design tools. We do an OK job of that. We've got templates. We've got some wireframing tools, prototyping. We could do a little bit better with, but we're working on it. And testing. This is a really big one. It's so easy to test. And we've now got a testing group. They're leading the way. They're helping out in any way they can to get these new projects tested, which makes just better design. And then design docs. As you just saw in the last talk, design docs are really important. And I think a project having a pretty comprehensive set showing that there's design thinking is important for recruiting, especially design talent, because they'll see that there's design thinking. They're focused on improving the project. They've got some idea of where they're going. And they're providing tools for the designers across the board to be on the same page. This, we have some really rough starts to it, but nothing comprehensive. But I'd like to move on to retention a little bit. Retention is where our biggest problem is. It's not necessarily recruiting, especially with designers. The biggest reason, I think, is time commitment. It's a huge amount of time to contribute to design on a project of any scale. You've got to do a little bit of research to understand the problem. You've got to come up with a solution to that problem. You've got to test out that solution a couple of times, wireframe, whatever it is, work with people to convince them to implement that problem. And that's if everything goes perfectly. We need to do a much better job respecting people's time in this. With development, it appears easy to jump in, fix a bug, and jump out. With design, that's not really so clear. You might jump in to fix something and spend a week in a rabbit hole of bugs to just fix one border. So I don't have a great suggestion for this, other than more companies could donate some time, some designer time, whether that's partially funding a designer to work on a project, or just fully fund. Like, we've got several full-time developers. We've got several full-time committers paid for by other companies to work on core, work on the community. And it shows their leaders in the community, they're always around. They've accomplished some of the hard tasks that aren't accomplishable in a short amount of time. Right now, there are, I think, the most designers we've ever had on core. We've got two or three people, no, I think four now working full-time on specific projects. But they're all focused on their corner of the woods. Two of them are working on Gutenberg. One is working on a customization, Mel, and I don't know where the other one is. Another thing that scares people away is community pushback. This happens in every open-source community. Some are worse than others. Some communities are not very welcome to newcomers. They expect you to know the rules. They expect you to know history you may not know. And quite often, read the manual, RTFM, is the response you'll get when you post something unexpectedly. Even when you post a design that's really complete or fully thought out, you'll still get a lot of pushback. We often encourage our designers, when we're first onboarding them to do a smaller bug, like fix a button color or something like that. Now, one of the problems with that is that it's really easy for anyone that's not a designer to also understand that problem. And that ends up in everyone chiming in because they all have their own ideas, how that button color should be. That's called bike shedding. And it's a huge time sink. Basically, there's no clear winner on that one. If you're new to a project, who's to say you have the right answer over all these strangers or people that may have been around telling you you're wrong or that their idea might be better, that's a really quick way to chase someone away. Now, these are my favorite ones. These are where I get caught up on. And just about every ticket I do. And I've got a good idea of why. It's partially because WordPress is 14 years old, which is awesome. I've never worked on a project that's old because it keeps getting older. So the technical limitations involve technical debt, design debt. They've been designed over 14 years. And a lot of stuff has been forgotten, not iterated on. Whoever implement them is no longer around. And it's hard to always know the history of that. So you get these unexpected requirements that no one even mentions even before something's merged in. For example, if you change this button at all, you would never know that if you made the color slightly different that you would have to meet accessibility guidelines. You would have to understand the implications of how it might look in another language or at a different size, how it wraps. Even if it's just a color change and you commit it, which I've done, you might get a ping a week later that says, well, hey, you did this here. But what about the color schemes? So you go, OK, well, where's the CSS for the color schemes? Turns out it's SAS. There's a build process involved. You have to figure out what grunt and terminal and all that stuff is, and you're gone. That's one of the faces I make when I run into this. Now, Mel mentioned, when I was talking to her, that retaining contributors is more important than perfection. And I think that's one of the most brilliant insights I've heard when it comes to contributing. We need contributors to stay around. Even if they're submitting imperfect things, let's help them, let's grow them, let's keep them excited and involved. They're there for a really, really good reason. And we want to keep them. So provide loads of feedback, but make sure it's encouraging. Be patient with them. Don't tell them to read the manual. Tell them, hey, we do this for this reason. What do you think about trying this? Here's more information on it. That kind of thing. Don't just link them and dump them. And constructive feedback is really important. Give them feedback right away. And this goes to not just design. Anyone who's commenting, if something sits too long, it's really kind of demotivating. So someone posts a proposal. They've got some code in there. Let's get in as quick as possible. Core is really good about that. Very few tickets sit for too long, unless they're super difficult or way out of scope. For example, if I posted a ticket like WorkPress should have an editor like Medium, that may not stick around for very long. But someone could be really nice about it and say, hey, we're working on this other thing called Gutenberg. It's really nice. Please come on over and check it out. It's not Medium. It's going to be way better than Medium. That kind of thing. And there's no one to make decisions for you. You've got to help them make the decision and understand when decisions are kind of handed down from team leads for historical reasons or something. Like, don't just say no. Say, we can't do this because the API limits us from doing it right now and we're working on it. That kind of a thing. And constantly do your part to keep them involved. If they've disappeared off the face of the planet, and this goes for any contributor, ping them, say hi. You don't have to convince them to contribute. But just the fact that you're seeing how they're doing, they might have a life thing come up. They may really want to get back on the project. This happens all the time. And most of all, be a mentor. So when someone new comes in and they see talent or excitement, like we have young people all the time come in. I think there was a 12-year-old who was helping Adam last year fix the REST API, which was pretty cool. But they helped mentor this person just along, even though this person was correcting their code. I think that's how Nason got pretty far as he had a lot of help when he learned quick. But these are just like recruiting and on-boarding, recruiting and retention problems. Those, I think, can boost our numbers and help distribute design a little more evenly across WordPress. But there's a few more pretty big design troubles. And I think the biggest elephant that came up over the last few days is design leadership. Right now, we have kind of a big gap there. We've got leadership on specific focuses and projects. But there's no one guiding where WordPress could go. There's no one organizing style guides or how components can work together across the board, thinking holistically about the product. We are doing better with this as we've gotten more designers, more people are communicating with each other. But currently, there's no team leads that are just telling people what we should be doing or where we're going. But that's not a problem. That means that's a huge opportunity for new designers to come in, new talent, and help guide the process themselves. Like, it's a democracy, essentially. The longer you're around, the more you're familiar with the project, and the more weight your words will have when you try to swing one direction or another or convince us that maybe we don't need menu groups or that widgets shouldn't exist because they should just be in something like Gutenberg, that kind of stuff. And I will just cover that. Design vision, because there's no one with this super clear vision of where things are going, which I think is kind of a myth most of the time. It just comes from whoever's working on a project. This can be really good and sometimes it's really clear. Like Gutenberg, you can already see the vision in that video of where it could go, how it can influence themes and plugins. But it's not always super clear, like what happens with custom post types, that kind of thing. And design consistency. This is a pretty big problem on old projects because they're often designed by like 100 people over 10 years, and it shows. So the comments section might be super different than how you manage pages, that kind of stuff. There's no one really heading a project to rearrange that or fix that. So I think that's a common open source project or open source problem that kind of plagues some projects. A lot of bits get left behind as they are no longer the new thing. They no longer have developers who are interested in working on it. And it's hard for designers with limited amount of time to go and redesign 10 sections that work on mobile. They've tested them. They dramatically changed users' experiences. That's a big deal, and it's very difficult to do. So that's why over time, things get a little rough. And our design process is slowly improving. Right now, it's a little open-ended, but I think Gutenberg again is a really good example of how the design process can be in the open. They're showing their steps. They're keeping people along for the ride. They're not just showing up at the end going, here's, I hope you like this. They're asking for opinions and they're showing every step of the way how they can make a great product. Now, I'm pretty optimistic about the future of open source and about WordPress itself, specifically WordPress because we have a huge year right now. We have Gutenberg working pretty amazingly for how quickly it's been put together. We have a customizer focus, a customization focus, I'm sorry. We have folks like John Mehta spreading the open source word on his networks. We have the REST APIs now in, so we can do all sorts of really cool design stuff this year. And we even have a developer and design co-lead on some stuff. Now, I wanna make it even more design-y for everyone. So I want you all, if you're a designer or not, to start thinking about design, getting to design thinking. And I think some of the other speakers talked about this a little bit, but it has nothing to do with form. It's not how pretty things look. I don't care if you use blue or green, that kind of stuff. It's entirely about function. It's the product itself. It's how a thing works. That's what we're trying to get at. We're trying to make something that works really well for the people that use it. And so that starts with some empathy. You have to talk to a lot of people. You have to use the product yourself. You have to try all these things. If you're building a blogging platform, blog, build sites, try to break it, do all sorts of things with it, and not just one site, like 10 sites. And that, again, takes time, but it's worth it. It's how you build empathy. Just the other day, I was trying out a product that's established. And running through a flow, it was actually Jetpack. I was running through a sign-up flow. And I think on the 10th different variation I did, I ran into something that was kind of frustrating for me as a designer. Could be frustrating for users because they don't really know what it means. But it wasn't really a huge blocker, but it was something that we immediately made an effort to make better, because we caught it. That's super important that we do that. And again, don't think in features. That's an old mindset. That's how you accumulate settings. It's also how weird things like menu grouping happens when someone comes along and says, well, we wanna use this menu over here and over here. Instead of just saying, okay, let's do that. Let's do this and make this feature a thing. You gotta stop and say why. Who's this helping? Is this gonna be more confusing in the end of the day? That kind of stuff. And that's all in flows. That's thinking about how to, a user needs to have a menu in three places. That doesn't necessarily mean they have to have a group that uses the same thing in a confusing context. They could just mirror some things or add some quick flows that work really well, which simplifies as menus. It makes it so that newer users, newer site creators, businesses can work with this without building a menu and getting confused as to why it's not showing up somewhere. So I'm just reaching out, help us design some stuff. It doesn't have to be WordPress, though I recommend it, but there's lots of projects out there. A lot of them are beginning and the earlier you get in, the more exciting it is. You have some sway, you'll learn a lot. You'll learn some code even. You'll learn terminal. It won't be super scary after a while and you'll be able to improve yourself as a designer because you'll get really, really familiar with the medium. So thank you. Now, ask me whatever you want. I don't know how much time we have. We've got a bit of time. We've got a bit of time. This is your chance to quiz one of the core team, any questions you have about design, about the process that gets us to design. Please take your chance now. We've got the usual situation with the lights down at the front. Do we have any questions? Who's got first? We have a question coming in from Don Bellow. I'm Matt. I'm from Poland and I have a question. How did you start? Like, how did you get involved with working for automatic? Did you get... I got really mad at WordPress one day. Yeah, and how did you get already like a portfolio or ready-made projects? How did it work? So I'd already done some playing on GitHub and some open source or web projects. I'd done a lot of web work and freelance work which is why I got mad at WordPress. I found a really blatant bug, got really mad at it and was like, I'm gonna fix WordPress. And it turns out that's harder than I thought. How's that going? But I jumped in, I had lots of opinions and then the leads and the core developers dropped in and said, hey, you know, I mean I wasn't cursing or anything but they were like, calm down. I mean, we know you're excited. Why don't we tackle this one issue at a time? Let's break this up into manageable things. It's okay. So that's how I got started in WordPress. I jumped in on a project called CEUX which was content editor, user experience or something like that. Essentially it was Gutenberg way ahead of its time. It was a blocks interface that let us do a lot of cool things that I was mad about. So I listened, I learned a lot. Mel happened to be leading that project which was kind of a good and a bad thing. Like I was like, is there anything I could do to help? And she's like so on it with design. She was like, nah, I got this. So I just kind of sat back and did some helpful mockups, made some smaller decisions along with it. And then when we realized it maybe wasn't gonna work or wasn't ready to work in scope of technical limitations, it was kind of pushed aside. But there is a cool plugin out there that you can still mess with it a little bit. Mike, can I ask, you kind of wear two hats then. So you have a role in the open source.org side. You also have a role on the Jetpack side. How do those two roles differ if at all? Okay, so I think the type of open source projects dramatically differ. So WordPress.org is entirely run by the community. Like it's built by the community. It's a very community-centric project. Jetpack is built primarily by Automatic. It's paying a lot of people to work and improve it. That said, we get plenty of community contributions. And we listen and work with the community on many things. We're often adding nifty secret tools and things to help out people in the community on specific sites. We have great support. So it's still a community project and anyone can contribute to it, but it's guided by a specific entity mostly. We have a question down below again. Thank you. Can we try again down here? Yes. Hi, Michael. I'd like you to know what you think about the current usage data and user data that we have on WordPress. And I'd like to know if, do you think, sorry, do you think we have enough to take well-informed decision about design and even more with such new projects coming up? Shouldn't we invest time and energy to build better usage data? Yeah, so to answer, those are two questions. One, do we have enough data to make informed design decisions? And two, can we have better data, right? Okay, so the first one, yeah, we do have enough user feedback or usability feedback to make design decisions. Some of it is coming from places like WordPress.com. Some of it are coming from other sources. We do a lot of research, but a lot of it just comes from talking with users, documenting the problems they have, figuring out who's using our stuff. We still don't have, like, like I don't know who's using WordPress. Like it's the top 20, it was top 25 million sites for 28% or something like that. I have no idea how many sites there are that are WordPress and active. I think that's the best guess we have is probably in the plugin directory or somewhere in one of those stats. We do have pretty good stats on active plugins and what plugins are used so we can make some deductions there. For example, I believe the top 100 plugins on the plugin directory, topmost active, are account for about 90 plus percent of plugins installed. We know that on average, people have six plugins installed in active. The top, I think, six of the plugins in the plugin directory account for a pretty large portion of that percentage as well. So we can make some good deductions as to who's using it, as for why and what they're looking for. So we can make some pretty good design decisions for things like where we put a button or a publishing flow. That's harder to do because we don't have a beta program or anything quite like that. We've made steps towards that. Like we do have a beta channel. You can be in them plugins if you're on a developer version. We have made projects a little more visible but we do a lot of usability tests early and often. So with Gutenberg, we're already testing it. We've tested the prototypes. We're testing how it is right now and every time we test it, it only takes a couple of people to figure out where things are broken or inform our design decisions as to where we can maybe even prove. So I think we have a lot of data. It could definitely improve. I think it's a matter of exposing that data in a better way is primarily the problem. It takes a lot of legwork currently. Mike, there has been some discussion about having WordPress sites phone home to deliver clearer, more granular data. What's your position on that? What's the core team's position on that? I don't know what the core team's position on. I'm not speaking for the core team. I think it's a kind of controversial topic and I don't know enough. I think it potentially, I think it scares a lot of people for privacy concern reasons. It could definitely be something that we opt people into or give them the option for, kind of like when you're signing up for a browser and asks you, hey, can I gather usability data? And you say no, because you're paranoid like me. Yeah, I don't know. I don't know what the best answer to that is because it's a complicated technological question. It could expose a lot of data publicly on accident if it's all going to WordPress.org or one of those servers. So I don't know enough about it. I would love to have that data for sure. I'll let you off the hook for now. We have another question down here. Hi. What inspires you to improve design or what places do you look for and trends? Are you looking at, in terms of publishing platforms like Squarespace is, I know Gutenberg's coming in. So I guess that's a two-part question and one is what actually inspires you to do the design in a good way and also trends. Okay, so that's a good question. Where do I find inspiration and am I looking at trends? So yes, I'm looking at trends to help. I'm looking at a lot of places for trends. Like when we look at editors for Gutenberg, for example, we looked at like a gazillion editors and where they're going. But then we were like, well, how are the editors supposed to look if we had like the perfect editor in five years from now? And I think those are kind of influenced by sci-fi movies a little bit, books. Like I read a lot of books and I think that's the best place you can get inspiration. Like how would this work an ideal situation and how can we get there? You don't have to design and build something at that endpoint right away. You can iterate towards that. So I think I was watching somebody use like a tablet. Oh, it was the latest Apple, whatever, developer conference or something where he was like swiping around and doing all this minority report stuff. I think that was probably influenced by a minority report indirectly, but it was very, very futuristic, very cool. And I think what we're trying to do is look to the future as opposed to what's trending now. So if flat design was really, really trending, we didn't decide, oh, we need to do flat design because it's trending. We decided we needed to improve our interface, design language across the board. Here's the best we can do for now. We think it's a little bit more future proof than some of the stuff we were doing before, that kind of thing. We also think about the future in almost every decision rather than making this cooler for now. Like how is this gonna last? How is this gonna hold up over time? So that's a lot of what we take into consideration, yeah. Cool. And I'm gonna take one more question and this is the last question of World Camp Europe 2017. Make it a good one. Okay. Thank you, Michael. As a designer, I'm interested in the tools you usually use. I would like to know specifically what you use for wire framing, prototyping, designing, and then testing. Okay, so this is a really ephemeral question. Okay, cool, yeah. I can list them off, but it's a very ephemeral question because they change all the time, right? There's different tool every day. So let's start at the beginning, wire framing. I still use a lot of sketches. It might be on a device, might be on a sketchbook, might be in the app sketch. I use the app sketch for quite a lot of things. We use all sorts of different sets of software for prototyping right now in Visions, one of the most used ones at the company. But we can also do things like, we also do keynote lockups and things like that that are a little faster to build sometimes. Let's see, what was the testing? Oh, I mean, testing could be as simple as just sitting down with a buddy who's not super familiar with what you're working on and just having them do a couple of things. You'll find out really quickly whether your design patterns are messed up. And sometimes you're designing something that's living within something else that might be a blocker. But we also use, I think we've used usability tests, testing in the past. We used various screen recorders, quick time even. We'll record people and their actions. When we are doing usability tests, we often have a very clear script so it's repeatable and we have people read their thoughts out loud, which is really helpful. When they're confused or looking for something, we know exactly what they're trying to do. Fantastic. Folks, can we give it up please? One last time for Mike Astad.