Inclusivity means listening to all voices — creating a beautiful polyphonic sound. Learn about Distinguished Professor Margaret Burnett’s mission to change the way software is designed to be more gender inclusive. Also, meet her former student Kyle Rector, now at University of Iowa, who designed software to help people with vision impairments learn yoga.
[MUSIC: Sicut cervus by Giovanni Pierluigi da Palestrina, sung by OSU Chamber Choir]
ROBERTSON Ahhh…so nice. That is the sound of four Oregon State music students who are helping me introduce the topic of diversity. What, you ask, does this choral piece by Palestrina have to do with diversity? Let’s listen again.
[MUSIC: Sicut cervus by Giovanni Pierluigi da Palestrina, sung by OSU Chamber Choir]
One voice, two, three voices, four. Each additional voice adds a layer of complexity and depth — the separate melodic lines complementing each other, creating a beautiful polyphonic sound. It wouldn’t be the same if all the voices were the same.
NARRATOR: From the College of Engineering at Oregon State University. This is Engineering Out Loud.
ROBERTSON: This season is on inclusivity in engineering. I think you might be surprised at some of our topics. We will be talking about the research here at Oregon State that is promoting inclusive design and accessibility, and our focus on creating a more equitable and diverse workforce.
[MUSIC: Sicut cervus by Giovanni Pierluigi da Palestrina, sung by OSU Chamber Choir]
To get some perspective on the importance of diversity in the workplace I talked to some people working in technology fields about why it is important for their companies. Here’s Brandon Greenley, an Oregon State alumnus who is now a general manager at Danaher Corporation, owned by Tektronix.
GREENLEY: Yeah there are so many angles I could take to answer that question because it has importance on so many different levels. But I would say from a product development standpoint ….because that's what I know and love the most as an engineer… but, when we develop products for our customers we are developing for a global environment and that global environment is very diverse in terms of their needs, their preferences and the things they are going to use our products to do.
ROBERTSON: Designing for a global market was mentioned by another alumnus, Nadia Payet, who is a software engineer for Google maps.
PAYET: A diverse workforce is a better work force. Diversity of backgrounds, diversity of opinions, of solutions that we can come up with. When I design something it's all in English because this is Google, programming is all in English but then I designed a product and then I'm like, ‘In French, this word … I don't know how are going to translate this, but it's not going to fit on this tiny phone, so we have to find a different way.’ And oftentimes it has to be pretty creative to fit really long words. German is our canonical example of really long words. We are, like, ‘How would this look in German?’ And if you don't have people who think about these things, think about these problems ahead of time, then they will happen in the product. And it leads to some sub-optimal experience.
ROBERTSON: I think we can all relate to sub-optimal experiences when it comes to software. Which leads me to my next guest, Margaret Burnett, a professor of computer science at Oregon State, whose research is about creating optimal experience for everyone who is using software.
[MUSIC: Sicut cervus by Giovanni Pierluigi da Palestrina, sung by OSU Chamber Choir]
Can you give me a little bit of your background, so how you got into computer science?
BURNETT: Okay, I was actually a math major when I went to college at Miami of Ohio and I minored in computer science. At the time actually there was only one university in the country where you could major in computer science so that was a really long time ago. And I graduated and got a job at Proctor and Gamble as the first woman software developer that they had ever hired in the Proctor and Gamble Ivorydale division, so that was kind of a glass ceiling that I helped to break.
ROBERTSON: That wasn’t the only glass ceiling Margaret has broken. After working in industry for a while she went back to get her Ph.D. from the University of Kansas and became the second woman to graduate from that university with a degree in computer science. She and Cherri Pancake were the first women to be hired as tenure-track professors in computer science at Oregon State. And just last spring she became the first female faculty member in the College of Engineering to be named a distinguished professor, which is the highest rank the university can bestow.
Wow, quite a few glass ceilings! But that’s not what we are going to focus on today. Margaret does research to improve the gender inclusiveness of software. But first we’ll start more generally with what her research area is about.
BURNETT: Generally I am interested in where people and computers come together, especially when the people are trying to problem solve with the help of the computer. So, examples are trying to make their budgets balance, or trying to make some sort of business decision with the help of some kind of software, or debugging. Anything that has to do with problem solving. And a lot of that turns out to be software development because that’s a heavy problem solving activity, but not all of it. So it's kind of a blend of what we call human computer interaction in the computer science field, and programming language research and software engineering.
ROBERTSON: So, in this area of human computer interaction what you have been focusing on lately are gender inclusiveness issues, and so can you tell me a little bit about that?
BURNETT: Yes, the gender inclusiveness issues that I'm looking at are actually gender inclusiveness of software itself. Lately, I guess, there has been a lot of news in the popular press about things like bias inside software. And so that's one of the things that I'm interested in too and that's where this gender inclusiveness comes up in my research is whether software itself is — especially software that is used for problem solving — whether, in fact, that has gender biases in it and whether those gender biases really matter. Executive summary: yes, they matter.
ROBERTSON: So, is your past related to any way to why you chose to work on gender inclusiveness?
BURNETT: Well, no, not really. You would think it might have been, but actually it wasn't. I was working on this blend of human computer interaction and software engineering that I was telling you about relating to people problem solving with computers, but I didn't have a gender inclusiveness angle to it. And then at some point one of my PhD students was getting ready to choose a topic, and she and I started brainstorming about something that she might be excited about. And so we kicked around a lot of ideas. And at that time, which was in about 2003ish, the community had started really talking a lot about the lack of women in computer science, and this was mostly being talked about at the education environment level. And so, my student — her name was Laura Beckwith — she and I said ‘Well, what about gender inclusiveness of software itself.’ And nobody had really thought about that before. And of course we were interested in it from a problem solving perspective not a, you know, pink versus blue or an aesthetics perspective — but is it going to be a level playing field to enable people to bring their different talents to problem solving. So Laura got very excited about it and so she just started reading from everything. She started reading from psychology, and from education and from computer gaming literature and feminist literature and the academic discipline of marketing, she was just reading everything. And these hypotheses about how that might play out in the way software is, just started dropping in her lap. And we took some of them into the lab to investigate whether they really did play out in software and, lo and behold, we kept getting these phenomenal piles of evidence and data about the lack of gender inclusiveness of a lot of software features. She ended up doing her dissertation on that work and as I said, it was really her work but by the time she left, she had me hooked.
ROBERTSON: So, normally we don't think about software being inclusive or exclusive can you explain how it is that software can be exclusive to a particular gender? What does that really mean?
BURNETT: Right, okay. Great question. So, let's get really concrete and think about tool tips. So, tool tips are those things that, when you are on a machine with a mouse like a laptop or a desktop, you hover over something and some little tiny bit of information comes up which you can read. So, tool tips are very nice information features for somebody who is doing what we call selective information processing. And in that style you get a tiny little bit of information like what you get in a tool tip and then you act upon it, knowing, that, of course, you don't have enough information, you might be wrong, but you are willing to try something. You might take one little action and then you might gather a little more information, say from another tool tip. Or you might say, ‘Oh that was a bad idea,’ and undo your way out of them and try some different thing. But it's characterized by a very tight iteration loop between gathering a tiny little bit of information and doing a tiny bit of action and evaluating whether you want to keep going down that path.Now, this style of information gathering is a style that is statistically favored by a lot more men than women and it's the style that most software supports, via things like tool tips.
On the other hand, a style that is favored by a lot more women than men is call the comprehensive style. And so in that style, somebody wants a lot more information before they start taking action and then they will take actions in sort of a batch. So, the iteration loop is much less tight, it's much more batchy. So, in that case this tool tip has a lot of disadvantages. First of all it had only a tiny bit of information. Second of all it disappears as soon as you move your mouse, and so you don't really have the presence of a lot of information at once.
But once somebody starts thinking about tool tips and ways to present information from these perspectives — the information processing style — then there are usually easy fixes. Like, so for example for a tool tip you could make it pinnable, which might mean you could pin it to the screen and then go get another tool tip and bring that up too and pin that to the screen. So you could be processing a lot of information at the same time and go back and forth and look at it as you started a series of actions.
Anyway, so, this is one way where even though the software didn't put the feature in thinking about gender, and even though it's not like all women are one way and all men are the other way, statistically a lot more women are on the one side of the processing information style and a lot more men are on the other side. And so if software can support both styles then it is going to not be uninclusive anymore. And furthermore it’s going to serve everybody who has this processing style regardless if they are male or female.
ROBERTSON: So, Margaret happily worked on these problems with her students, and had several published papers, until one day she got a wake-up call. Okay, it didn’t sound exactly like that. It came from someone in industry who had a huge problem with his software. His company produced software for a branch of medicine that is practiced by mostly females, and unfortunately females hated his software. He asked Margaret to help him.
BURNETT: And so, at that point I realized, ‘Gee, I don't really have anything to give him, do I?’ All I have is a lot of academic papers about lab studies we've done, but what this person needs is some practical method to be able to figure out what is it about our software that so many people are running into problems with. And what can we do to not have gender inclusiveness problems?” Because he didn't solve that, his company wasn't going to make it. So, that's when GenderMag was born. It's a method for people like that person who contacted me. It stands for Gender Inclusive Magnifier. And so, it’s a method for ordinary software developers, software managers, user experience people — anybody who has a hand in helping to create the software. It's a method that enables them to find gender inclusiveness problems with their own software.
ROBERTSON: So, although Margaret is a computer scientist, what GenderMag is NOT is a computer program that automatically finds gender inclusiveness problems. Instead, she has created four fictional people — you can think of them as characters from a novel. These kinds of fictional people are called “personas.” Each persona has a different personality which is a combination of five problem-solving facets. One of these facets she mentioned before — the information processing style. As you might remember, more females tend to prefer a comprehensive information gathering style. So, one these characters, named Abby, embodies that style along with some other problem-solving facets like risk aversion in technology. The other characters Tim, Patrick and Patricia have a different combination of facet values. Together, the four characters cover a spectrum of values each of the facets can have. I should mention that all these facets were derived from a large corpus of data. Next Margaret explains how someone can use the GenderMag method.
BURNETT: So, the software developer picks one of the personas. And so this is some slice of the population that they would like to address, that they feel like they need to know more about. So, let's say they pick Abby. And they take their software and they say, ‘Okay, I want to see how Abby would do at’ … let's say, for example, ‘adding a new recurring meeting to her calendar.’ And so they say, ‘Well, the first thing we would want Abby to do is to click on this button.’
And so now I've talked about two of these three components of GenderMag. I've talked about the personas, and I've talked about … they all have facets. The third thing that they have is this process. And so it's a set of predefined questions that you ask every step of the way as you try to figure out how Abby would go about this task. Or really whether she would succeed at the task. And so, you say, ‘Well, the first thing I want Abby to do is push this button.” And then you ask one of the questions on our list, which is ‘Will Abby even have that goal?’
And so you go back to the facets of the persona and really absorb what Abby's motivations might be, (that's the second one of our facets), what her information processing style might be, what her risk aversion might be, what her learning style with new technologies might be, and what her self-efficacy (which is her particular self confidence in how well she learns new technologies), what that might be. And they take those things into account and then they say, either yes, no, or maybe. Yes, she will have that sub-goal, no she will not have that sub-goal, or maybe, she might.
And in all three of those cases, or in whatever the cases are, they write down the reasons. So, they might say, ‘Abby is risk averse and the label on that button is down-right scary.’ It doesn't say, ‘Start a New Meeting.’ It says, ‘Maintain Permanent Settings.’ It’s like, she's not going to want to do that! That's sounds like a dangerous thing. And so they write down this reason. So, they have identified a gender-inclusiveness bug. It's usability, of course, it would affect lots of people, but the thing that makes in a gender-inclusiveness bug is that one of those five facets that the value that statistically aligns with more females than males is one that really triggered their decision. And having written down that bug then they decide how important it is to them to fix, and they also have some idea about how to go about fixing it. ‘Well, no wonder she is not pushing the button. Who would if they were risk averse? So, let's change the label on the button.’
So, that's how it works. They just go through the task—everything that Abby is supposed to be pushing, or clicking on, or gesturing, or typing, or whatever—and evaluate that and they will also evaluate whether or not Abby will know she is making progress after they do that.
ROBERTSON: And so, what has the experience been of the people who have been using GenderMag to evaluate their software?
BURNETT: It's been really encouraging. And so, we've found that people can start using it right away. At first they aren’t quite as good at it as they are, you know, 20 minutes down the road, or whatever. But they get it right away. Another great thing is they all seem to really understand that it's just not about gender stereotyping. So, it’s not about aesthetics, it's all about different problem solving styles, no matter what gender those things land in.
But the reason it is about gender is because of the fact so many of the problem-solving styles that are so far being overlooked by software are the ones that are favored by a lot more females than males.
The third thing is, they do find a lot of gender-inclusiveness issues in their software. And this is both good news and bad news. So, it's great news that they have such an easy time finding those issues using GenderMag. That’s wonderful. The bad news is they are finding so many of them, we are starting to learn just how pervasive this problem really is.
So, I did a field study last summer. And in that field study I had two software development teams from a government agency and one from an east coast software development company and one from a west coast software development company. And some of those people were developers, some were user experience people, some were managers, the whole gamut. None of them had any background in gender. And the combined total of how many gender inclusiveness issues that they found was one out of four of every feature they looked at -- 25%.
And this is horribly high. And this was them evaluating their own software. We weren't doing it. It was them. They are evaluating software that they created, they are supposed to love. And they are finding that many problems with it. So, that's the bad news. But the good news is once they find them, as I've mentioned, they have a pretty easy time figuring out how they can fix them, and so that gives them the ammunition they need.
Since the time I did that field study which has actually been published (you can read about that if you want to), I’ve done… I've worked with a lot of other teams. And so, the bad news there is that it actually is even worse than one out of four. When I put everything together that I have the data from on these teams working with GenderMag, the average is now up to one out of three. So, this is over, oh my goodness, at least 20 different software products ranging from early prototypes to software that is still in use after 10 years, and everything in between. Ranging from desktop to mobile to smart watch to you-name-it.
ROBERTSON: So, how flexible is GenderMag? Are people using it as you intended? Or are they figuring out other ways to use it?
BURNETT: Great question. This is my change-the-world project. And so, I don't really care if people use it exactly the way I invented it. What I really care about is that people find a way to use it in a way that works for what their company — their team — needs to make their software better.
So, it's turned out that people shape it all different ways. But at the very core of GenderMag are these five facets. And so long as they don't mess with the 5 facets, it turns out that GenderMag deconstructs really well. So you can use just the five facets and still make a lot of progress. Just be talking about things like information processing style among your software development team helps.
Some software development teams love personas. And so, it turns out you can use just the personas without the rest of the method because the personas encapsulate the facets. And so some teams do that and it works really well for them.
Other teams, they absolutely hate personas. That's fine. They can just use the questions with the facets. And get a lot of mileage that way. So, because of the fact that it's turned out to be so deconstructable, you can use bits and pieces of it and still get a lot of mileage.
ROBERTSON: What are your goals for GenderMag?
BURNETT: As I've mentioned, this is my change-the-world mission. And so I would like GenderMag to be used by everybody to figure out how to make their software more gender-inclusive and more inclusive in general. It's all downloadable, it's all free. I hope people try it out. I hope people will let me know how it goes for them because I'm still collecting data. We improve it about every 2-3 months, so they are welcome to download it as often as they want and it's freely available to everyone.
ROBERTSON: Inclusive design is one way that researchers in the College of Engineering are promoting diversity. Improving accessibility is another. The next story is about someone who is working on improving the lives of people who are blind or who have low vision.
RECTOR: My name is Kyle Rector and I’m an assistant professor in computer science at the University of Iowa.
ROBERTSON: So, you are probably wondering why I would be featuring someone from the University of Iowa. Kyle is actually a graduate of Oregon State University. She got her undergraduate here in both electrical and computer engineering and computer science before going on to get her PhD at University of Washington. During her time here, she was a student researcher with Margaret Burnett.
RECTOR: Yeah, I actually worked with her for four and a half years. I’m very lucky that I got to work with her. It was a research solicitation and it had to do with gender and technology. And so I was interested in learning more because I noticed there were so few females in my electrical engineering classes. And actually it was Margaret Burnett who convinced me and encouraged me to join computer science and also to go into research.
ROBERTSON: So, here’s the cool thing. Not only does Margaret’s research have a direct impact on improving software, but her students go out into the world and amplify those impacts. On top of everything else Margaret is an award winning mentor for undergraduate and graduate students. Kyle is just one example.
RECTOR: My area of research is in human-computer interaction, so similar to Margaret Burnett. But more specifically I’ve gone into accessibility, so trying to design technologies to help people with disabilities. And mostly I work with people who are blind or visually impaired.
ROBERTSON: Have you ever thought about how someone who is blind could learn yoga? Probably not. But Kyle did.
RECTOR: It’s called eyes-free yoga because there is no screen involved. So, the entire system is operated with your voice and also by listening to the audio and verbal cues.
EYES-FREE YOGA: Rotate your shoulders right. Rotate your shoulders right. Ding. Lean forward. Ding.
RECTOR: So, what I did is I built a system using the Microsoft Kinect, which, in case you don’t know what that is, that’s a depth camera. So, in other words you can place it on your mantel or a desk, or about 4 feet off the ground. And the idea is that this camera can assess your body posture. And so, with that information I can now give a very detailed verbal instructions for a yoga workout, but not just tell you what to do, but then I can assess your body in three dimensions and figure out if you are actually holding the posture properly or if there are things you can improve. And so then the system actually provides detailed verbal feedback so you can adjust your body. And this based on what you are currently doing. So, it is personalized and in real time.
EYES-FREE YOGA: Your core is good. Your legs are good. Your arms are good. Good job!
ROBERTSON: As you can hear the program also gives you positive feedback. Kyle did some testing to find out how her system with the feedback compared to a system that did not have feedback, like a blind yoga audio CD. It turned out the participants preferred having the feedback.
RECTOR: They really liked hearing how they were doing and not wondering that. Actually hearing some information that is concrete and understandable can make a difference. And then I converted that prototype into a full work-out system so now Eyes-Free Yoga has four full work-outs. All the standing yoga postures have custom feedback. And then I added some fun gamification techniques as well to try and persuade them to continue exercising.
ROBERTSON: Kyle’s system is available to download from her website which we will link to in the show notes for this episode. Or just search eyes-free yoga. And keep an eye on Kyle. She is looking to expand her research beyond yoga.
RECTOR: What about faster paced exercises like aerobics? Or maybe you don’t want to exercise inside of your house but out and about. How do you increase accessibility of gyms and running tracks and swimming pools and other spaces like that. So, that’s where I’m seeing myself going in the next several years.
Working in the field of accessibility it’s all about trying to make technology and aspects of quality of life more accessible to people with disabilities. There are even researchers focused on computer science education, so how do you make computer science more inclusive of people with disabilities, and just all sorts of different aspects: employment, recreation, connecting with others. I think it’s a great field to be in for the aspect of diversity.
ROBERTSON: That’s it, my friends. I hope this episode expanded your view of what engineering can do for society. Thanks much to the awesome Oregon State music students Emma Nissen, Blair Bowmer, Eldon Dela Cuz, and Jordan Mitts (I hope I said all your names right) who provided the music for this episode. And special thanks to Professor Steven Zielke, director of choral studies here at Oregon State. The music you are hearing would not have been possible without his help.
This episode was produced by me, Rachel Robertson, with additional editing by Miriah Reddington. Our intro music is “The Ether Bunny” by “Eyes Closed Audio” on Soundcloud and used with permission via a Creative Commons Attribution license. A final shout out to Eric Gleske who has been our patient and informative technical advisor.For more episodes visit engineeringoutloud.oregonstate.edu.