UNA KRAVETS Open Source Design: A Call to Arms | CascadiaFest 2015


>>Hello, everyone. Now that we’ve had a lesson
on how to say my name. This is me, I’m a designer, developer, illustrator, I do a bunch of things.
But one thing I really like seeing when I go to conferences is I really like seeing
people’s stories. So we’re going to have a little bit of with Una, I hope you’re ready,
and we’re also going to have some real talk. So I hope that’s okay with y’all as well.
Let’s talk about innovation. Historically innovation has come from three sources. So
the first is from large corporations, so we’ll think, like, the labs, when corporations have
enough money to pay to bring together a lot of people with great ideas, they can create
great technology and great products opinion. The second is through government funding.
So this is where we get things like the computer, and that’s when the government decides that
something is valuable enough for the people and we’re willing to spend some of our tax
money — and that’s the second way. And the last way is open source, and this talk is
about open source. And first we’re going to start talk about that first one. And the first
is corporations. We’re going to talk about this guy.
So do you all know who this is? He’s a little under ground, but don’t worry he’s up and
coming. Bill Gates. And Bill Gates cofounded Microsoft, which is the second highest growing
company to this day. And transitionally he’s known as this really
intelligent genius who just rows out of the ashes of his lines of Red Bull and created
the PC revolution. But that’s not true. There wasn’t Red Bull. So a little bit of back story.
So Bill Gates had a blessed life, his family was well off, and he got to go to lakeside
academy, which was this great prep school when he was 13 years old, and he did really
well there. And the unique thing about this school is they had a computer science program
for middle schoolers. And 1960, at a time when most universities didn’t have access
to a single computer terminal, and the reason why there was this mothers club that had a
scale and they bought computer time from GE, and they set it up. So there was this computer
club. This is a picture of gates and Paul Alan, who met there. And they started hacking
away and became obsessed with computer programming and really learning about it when it was starting
out. So they would sneak into the university, which was across the street. And through connection,
whenever they got kicked out of the lab, people understood that they had talent, so they ended
up getting paid to be the first bugger systems. So by the time that gates graduated high school,
he had over 10,which is the amount that you need to become an expert in the field.
And it’s cool if you think about it, it wasn’t the individual with. It was the community
that surrounded him. He’s in the bottom left-hand corner, boy.
So that’s exciting. It’s not the individual, it’s the people that around him that make
this possible. So isn’t that cool? Isn’t that exciting? Well, what if there were 20, 13-year-old
bodies who had that kind of access at that time. What if there were 20, 13 years who
came from all different backgrounds, different mind-sets, different histories, who had that
access. What if there were 200 or 2,000 of them? What kind of world would we live in?
How many Microsofts would there be? What kind of technology would we have?
Let’s talk about diversity for a second. We all know that diversity in tech is pretty
bad. But diversity in open source is really, really bad. Here’s a study that was done a
couple of years ago on diversity, on GitHub teams. And they surveyed 23,493 projects,
which is a lot. That’s a lot. They found that as expected they even said, 75.3 percent of
the products had no term diversity at all and any quarter in the entire existence of
that project — of the project period, that’s a lot.
They also found that there’s a small but significant positive effect on productivity when you have
that diversity. So it just shows us that the world we could have is much richer than the
world we have settled for. Because the world we settled for, it’s broken. The initiative
is a great opportunity that we have. Who here works on open source project? Do any of you?
Awesome. Who here uses open source? Okay. Better question.
Who here does not use open source project at all?
Okay. Good. I don’t see a single hand, which I know none of you are lying. It’s nice to
hear. So I love open source too, I use it all the
time, I’ve had great experiences with it, but open source is broken, and we have to
fix this. We can fix this. One of the things that I try to explain to
people in why we need design in this community is the story of the road. And the story of
the road is told as — it starts from I heard it when Google was doing the design founders
program. So you have the businessperson who says okay. We need to build a road. We need
to get from point A to point B. And then the businesspersons goes to a engineer and the
engineer says, yes, let’s build a road with this brand-new antistripping agent so that
interpretation to work on it for years and years, and it will be really sturdy for a
long time. And then the designer comes in and says those are all great ideas and let’s
also build this road along the coast so people can enjoy the ride for years and years to
come. And when you have this diversity, it creates better outcomes, as we can clearly
see here. Here’s another study that was done, and some
of the people are the first from the first study, but this is a different study, and
they looked at how diversity improves products. It improves productivity, and they found inconsistent
with diversity theory, men and women and more experienced people gives different perspectives
together, and that’s why it improves outcomes, so it’s really the perspectives that we’re
craving in the community. And it’s not just the gender diversity. Where are the designers
at? They work in tech, they work in the same products that we’re working in, yet you don’t
really find designers in the open source community at all.
So let’s look at why. There’s a designer. His name is Mike, and he gave a really creative
talk in San Francisco. And his talk was fuck you, pay me.
[Laughter] It’s something that designers have kind of
been bread with. Throughout design school they’re taught that you need to make someone
respect them and get paid for their time. So when you first introduce this idea, it’s,
like, why would I do that? They get knee-jerk reaction to doing free work. The second barrier
is what I like to call the museum effect. And this happens when you just don’t want
to break anything — it actually comes out of, like, empathy for something. It comes
out of respect, it’s such a beautiful picture and painting, I’m not going to take it off
the wall, I don’t want to break it, so I’m not going to touch it. And that’s why when
designers first enter this world, they don’t want to touch anything, they don’t want to
break your hard work. There’s little but different, and so it’s
the opposite of what happens when we have all these options and frameworks and I don’t
know where to get started. And you can have this paralysis when you don’t know where to
get started when you’re unfamiliar with the topic.
And then there’s the lovely, lovely design by committee. I don’t know if I have much
to say about that. It’s a terrible thing. So this last point is just not in a peripheral.
Currently it’s not an open source tool at all, but as a designer it’s something you
hear about in the foreign distance. So I wanted to fix this. We should do things about this.
So the first thing is we need to encourage a more open designer developer workflow, and
the second thing is that we have to foster, design participation in the open source community.
Once we have done that first thing. How we do the first fortunately. My answer to that
is GIT. And I think that’s a great tool — not just for versioning, but it’s a great design
tool to bring together, and oftentimes I’m, like, hey, we should use GIT for our project,
and the reaction is, like, oh, fuck, no. That’s just not me, that’s not my thing.
But anyway I wanted them to understand that GIT was our friend, it’s something they shouldn’t
be scared of. It’s not something that’s intimidating, it’s something that we can use and work with.
So I set up this gulp starter environment to just create kind of things that code pen
was bringing and put it into GitHub so that we can start working together, and I included
things, like, auto prefixer, I set up Sass so that they wouldn’t have to do that, put
up performance optimizations with images and browser sync, which is magical when something
automatically reloads. And all of this I do with my team is type gulp into the terminal.
So I set up the system. I convinced my team to let me use them as guinea pigs, and I was,
like, don’t worry I’ll be your safety net. So then we jumped into it. And this is the
first thing that happened. I’m sure we’re all very familiar with the screen. But if
you’re not used to using terminal, it looks like terrifying. There’s glaring warning signs
and errors and your terminal is yelling at you. It looks like you have a virus, but it
looks familiar if you’re not familiar. So this happens. And the way to work through
this is through a lot of positive reinforcement and encouragement. So we really want to celebrate
all the wins on my team, and I started working Ryan because Ryan was really open to trying
out code, and he was a designer that I worked with, I loved working with him.
So he says, yeah, successful pushed code by myself. I updated the readme. And that’s exciting.
What if we still have that reaction every time we updated a readme file and successfully
pushed it? I would love that. So of course gifts back, and we started celebrated every
win, and hashtagging every win, and this hashtag was born from another designer, Brittany,
from my team. And she sends me and Ryan at, like, 10:30 p.m. soon on an Sunday night,
so she screen shots — not even screen shots, she took a photo so that she can send it.
And she says I downloaded I starter again and added a Sass attribute. Hashtag little
wins, haha I’m freaking out. Okay. Bye. So then there’s just emojis, we’re celebrating,
we’re doing these things together. It’s exiting. And then here’s Ryan, taught another designer
GIT today, crazy to think I learned GIT just two weeks ago. This is what happens when you
don’t make as you see has been that somebody doesn’t want to learn your system and work
with you in this way. Two weeks after he had never touched terminal, he was teaching other
designers in the studio how to work with GIT, and that itself just showed many me that this
is really powerful. It’s this power of being excited and enticing people showing how passionate
you are about something. Telling a designer that they must learn to
code is making them defensive. That’s, like, oh, you need to learn how to do something.
They’ll come back with to 20 reasons why they knew. It’s really destructive, they’re being
forced by all these developers who are saying your job is not going to be useful if you
can’t give me code. So instead if you share your excitement about
that code and share your tools, it makes them curious. And when they become curious, they
come to you and ask you for help. They ask you to set up their environment, and that’s
when you can win. That’s when you can shape that person to be able to provide the assets
that you want. So we ended up using GitHub for our entire
design team when we did the IBM Watson design library, so we had our project management
on there, user research on there, we had our, like, user experience, visual designers, front-end
developers, all working together in this repo, and it was a great way to share assets and
have one common area that we could go to. So that’s how you encourage that more open
design workflow, but that was on my team. What about the in the greater open source
community? How do you foster design participation in
this open source community? Well, I thought of a couple of good open would
be. So it would be communication, accessibility, respect, and empathy. Let’s start with communication.
The first thing that you can do let somebody know that you want their help. And you can
do this by just creating things that are labeled design in open issues in GitHub. I’m seeing
this more and more, which makes me excited. And this way designers can go and search for
things that are open, open issues that are labeled design. They know where they can help.
And another idea that we’ve been toying with, I’m also part of the open design foundation,
is creating this repository where you can throw up projects, but only accept projects
that have a design section that contributing dot MD document. So it’s good to have a contributing
document so that they can contribute. And where they can contribute design. So what
you can do is you can add a project if and only if you have a design section. So that
way designers can go looking for designer help and where people maintaining projects
can put them up and look for designers. The third thing is really be clear when you’re
writing your issues. So one of my favorite issues of GitHub is this check box. And you
can just go and check off all of these steps that you do when you get there. And when you
look at all your issues as a whole, let’s see if I can zoom in here. You see this bar?
It’s a little blurry. But you can see if you checked them off, the percentage that you’re
done with the bar. So that’s a really nice project management tool that GitHub provides.
Also being clear about what your project is doing. So having a very robust readme with
images is great. What I like about this one is whenever they’re explaining what something
is inside the readme, they’re also highlighting in red, so you know exactly what they’re talking
about. Using a lot of winkling people in general
understand concepts when they’re matched with visuals than if it’s just lines of text. It’s
really easy to use images with GitHub, have you just to drag and drop. And this is a great
tool for designers as well. As you’re developing something, you can drag it in, you understand
why making decisions, and you have this context to talk about within an issue.
Next thing is accessibility, and I don’t mean in the sense, like, front-end developers use
accessibility can someone use my app, I mean can someone end up using it? And this is what
happens all the time. Like, you get on GitHub, you see a readme and it’s just like —
[Laughter] What does this mean? I mean I know what it
means. You probably know what it means, but someone who doesn’t know what NPM or gulp
is, gulp is when you drink something. It’s just a weird word in general.
I remember one time someone didn’t have any documentation and it was, oh, like, make sure
people know how to bundle, and the response I got was, well, we have a gem file, and that’s
why you can’t have nice things. And that got rejected.
And when I set up the gulp environment, I set up a documentation, and this might be
even more than you may need to do, but I wanted anyone who landed on this to understand every
single step without having someone to need explain it. So everything from changing directory
to what everything means, getting started, it was really robust in there. And I iterated
a lot on that. Whenever a single designer got stuck on any step, I asked them to write
it down for me, and I changed the readme several times so that it was a little bit more loose
every time. And next thing we discovered was a really
good idea when we did some iteration because there were all of these terms in this world,
and I know that you understand this. So having lexicon is normal a good idea, especially
when the same term can mean two different things to two different people. So here’s
what I define what things are, like pseudo, we think of second nature, but when you’re
starting out, you forget that it’s something you know off the bat. Sued he on, and CD,
and repo. So it’s good to have it for a common understanding.
And the last study I did, this comes with a disclaimer, though. This study I spent a
weekend doing because I was curious. I had a hypothesis that having visual assets within
a GitHub repo would increase the diversity of that team. I didn’t know what the correlation
was, I didn’t know if there was a correlation. But I thought it was interesting to start
with. So I had to get a sample repo, and all I had to do was this repo dot me, and I clicked
this random button, and so it would pop up a window with a random repository, and if
it had more than five contributors, I would click on the contribution list and pretty
much stalked a lot of people online. So I made this spreadsheet where I looked
at the repo, the contractors, and I tried to differentiate if they had a male persona
or female persona. And I looked at 900 contributors, 841 identified
as male, and when I looked at photos, they didn’t have a photo that was a certain gender,
and I looked at their name, and I’m not saying I’m a scientist at all. So 13 of those were
female, 76 percent I couldn’t tell. There were a couple of bottoms in there too. But
I knew that I was getting somewhere when I got these last two numbers. 12 percent of
projects had some gender diversity, which was really close to the number we saw earlier,
which was that 25 percent had some in any quarter in their entire existence. And then
the last one, 1.5 percent of contractors are female. So that mailbox matches almost exactly
a survey by the open sourced society they did a couple years ago on how many contractors
they are in open source female. And that was 1.4 percent. So I let that was a relatively
good resource. So of those 43 projects, I found 63 percent
of them had some website that was not in the readme file that was separate in them. I found
that 26 percent of the projects with gender diversity at all also had a website documentation
demo. This doesn’t really tell me much. This is up in the 5 percent baseline. But what
was really interesting is that 85 percent of the females contribute to projects that
had a website or documentation or demo. So 85 posteriors of the females found contributed,
those projects had some kind of for the documentation. And then 100 percent of the projects with
more than one contractor had a website or documentation or demo. So what does this tell
us? Does it tell us that it increases diversity or diversity increases documentation, I don’t
know about that. But hopefully we can continue these studies
and see. The one thing we can tell is that the documentation is important in general
for any kind of GitHub project or any GitHub. The last thing — not the last thing, the
next thing I want to look at is respect. And this is respect for design, respect for medians.
Design used to be the season you would sprinkle on for taste, and now it’s the flower you
need for the recipe. And we see a lot of this design going on later lately. So invest designers
going, oh, let me put a logo on it. They’re doing some real research, defining problems,
brainstorming, modeling, so these things — these things are development driven steps that designers
can get involved in, and it’s important to remember that that the designers aren’t just
there to make the logo for you, they’re there to work with you and make your project better.
And this quote comes from Steve Jobs who is famous for — like he is famous for not — it’s
saying, no, we have a standard and we’re not going to rise below it. He really respected
design. That was one of his staples. Design builds communities. It really does. So if
we look at this logo, we can all immediately know what it is. We’re here because there
was something that unified us. A logo is like a visual shorthand for a complex concept.
We have all of these logos on our projects, and when you see them, you can understand
the gist of what someone is talking about. There’s node, reactor — there’s so many logos
out there. But instead trying to explain to someone what this complex concept is that
your concept defines, you can use a logo as a shorthand.
Here’s a fun one. So leers my favorite issue of all time. It’s issue number 37 on IOJS.
So this is what happens when you have this free for all definition of terrible design
by committee. It’s a really good one that is just clustered. This is a cluster of people
submitting logo ideas. So I think it starts out pretty well. And people are really well
intention, and they have these ideas, they’re doing a little bit of conversation, I do speed
up. This is really long. But it really downgrades pretty quickly. Just people start trolling,
it gets really funny, so we can watch that for
a second. So, yeah.
[Laughter]>>The best is still to come. Trust me. There’s
people playing off JavaScript and then there’s, like, an eyeball, a sausage on a plate, and
there’s this guy. I was — [Laughter]
Yeah, I don’t know. So I was talking to somebody at lunch about
this, and he was wearing an IOJS T-shirt, and I was, like, oh, when did they decide
what the logo was going to be. And his answer was, oh, they didn’t. The but other than designed
this logo made T-shirts. [Laughter]
Always a good sign. So see how long this video is? We haven’t even gotten through half of
it. Like, what is this? Anyway issue number 37, it’s a really good
one. So this is what we did so the open source design account. We were actually collaborating
here, we weren’t just throwing things at a screen to be funny. We were building off of
each other’s ideas. And we were talking about what we liked about every iteration what we
didn’t like and just grew off of that. So this is a much better solution to that problem
when you have some kind of standards around what you’re looking for.
So a little less of a cluster here. There’s no gifts but got some legit work done. And
this kind of leads into the last point, which is having empathy for each other.
So empathy is a evolutionary tactic, that’s a fun fact for you. Empathy is what happens
when somebody gets sick, and we don’t decide to leave them at the last town and hunt and
move on, we take care of our family members that are sick. And that ends up strengthening
our genetic bonds, we cure that disease the next time we get it, we become more immune,
and that’s because we get empathy for each other. So have empathy for the people that
get open source projects. Open source is about people. There’s someone
handing out shirts here that says software is about people. And that’s so true. But open
source when you’re trying to convince someone to work on your team and your project, you
have to care about the people that are working on it with you. Have made taking their time
and you have to respect their time. And don’t be this guy. This is actually a cat which
is a great little thing that you should put on your slack channel when someone does this.
So there’s a great blog post about this where it’s just about the person that’s trying to
upstage each other. And two weekends ago I went to a conference in Nashville where Kate
gave this great talk about diversity. And one thing she mentioned about art culture
that I didn’t realize it was there until I reallied it was there. And what happens now
is a very toxic environment where people are trying to prove themselves as right. It’s
no longer being together, it’s about proving who is right. So this is creating some toxic
culture in our communities, and it can create a toxic culture in your project.
And
a great way to prevent this is having feedback guidelines. So I like to say ask, don’t tell.
The first thing you can say is why did you decide to use this function here instead of
saying this is stupid. Don’t do that. Without any explanation. Like, asking why instead
of making declarative statements is a much better approach.
Be specific. Like, when you’re calling the move function on this line, I think that you
should be doing this instead. Being specific, it definitely helps. Explain yourself. Like,
checking out this blog post or I would do something different. Like, this is what I
would do. Next point, offering solutions. Maybe try doing it another way. In that blog
post or other some explanation, there could be a solution in there. Avoiding hyperbole.
So trying not to say do this and no and don’t. Because these things makes somebody really
— kind of just crawl into themselves and not want to work on the project at all. It’s
something that — just makes them feel bad. So try to avoid those words. And last thing
are these emojis. I learn that we love emojis today, and they’re great. And when you add
a smiley face, even though you may not just that your words are coming off in a certain
manner, it makes the whole conversation come off a lot more level headed.
And one thing that when we worked on our logo it came out sole, he said I want everyone’s
opinion on our logo. This is our thing, it’s a community thing. Why our particular concept
is great, why it fails, et cetera. I want to make sure that everyone’s voice gets a
chance to be heard, but I also want a positive conclusion with this conversation. So having
that kind of mind-set going in is really important. So communication, accessibility, respect,
and empathy, and I’m a terrible person, but it makes this really cheesy acronym.
[Laughter] But really if you care about your project,
then you care about having a diverse set of opinions working on it. And you’ll want to
do these things. So please think about this when you’re working in open source. Even working
in your own teams in your own work environments. I just want to say thank you for having me.
[clapping]

Leave a Reply

Your email address will not be published. Required fields are marked *