Search for: All records

Inclusive design appears rarely, if at all, in most undergraduate computer science (CS) curricula. As a result, many CS students graduate without knowing how to apply inclusive design to the software they build, and go on to careers that perpetuate the proliferation of software that excludes communities of users. Our panel of CS faculty will explain how we have been working to address this problem. For the past several years, we have been integrating bits of inclusive design in multiple courses in CS undergraduate programs, which has had very positive impacts on students' ratings of their instructors, students' ratings of the education climate, and students' retention. The panel's content will be mostly concrete examples of how we are doing this so that attendees can leave with an in-the-trenches understanding of what this looks like for CS faculty across specialization areas and classes. We 

Motivations:Recent research has emerged on generally how to improve AI products’ Human-AI Interaction (HAI) User Experience (UX), but relatively little is known about HAI-UX inclusivity. For example, what kinds of users are supported, and who are left out? What product changes would make it more inclusive? Objectives:To help fill this gap, we present an approach to measuring what kinds of diverse users an AI product leaves out and how to act upon that knowledge. To bring actionability to the results, the approach focuses on users’ problem-solving diversity. Thus, our specific objectives were: (1) to show how the measure can reveal which participants with diverse problem-solving styles were left behind in a set of AI products; and (2) to relate participants’ problem-solving diversity to their demographic diversity, specifically gender and age. Methods:We performed 18 experiments, discarding two that failed manipulation checks. Each experiment was a 2x2 factorial experiment with online participants, comparing two AI products: one deliberately violating one of 18 HAI guideline and the other applying the same guideline. For our first objective, we used our measure to analyze how much each AI product gained/lost HAI-UX inclusivity compared to its counterpart, where inclusivity meant supportiveness to participants with particular problem-solving styles. For our second objective, we analyzed how participants’ problem-solving styles aligned with their gender identities and ages. Results & Implications:Participants’ diverse problem-solving styles revealed six types of inclusivity results: (1) the AI products that followed an HAI guideline were almost always more inclusive across diversity of problem-solving styles than the products that did not follow that guideline—but “who” got most of the inclusivity varied widely by guideline and by problem-solving style; (2) when an AI product had risk implications, four variables’ values varied in tandem: participants’ feelings of control, their (lack of) suspicion, their trust in the product, and their certainty while using the product; (3) the more control an AI product offered users, the more inclusive it was; (4) whether an AI product was learning from “my” data or other people’s affected how inclusive that product was; (5) participants’ problem-solving styles skewed differently by gender and age group; and (6) almost all of the results suggested actions that HAI practitioners could take to improve their products’ inclusivity further. Together, these results suggest that a key to improving the demographic inclusivity of an AI product (e.g., across a wide range of genders, ages, etc.) can often be obtained by improving the product’s support of diverse problem-solving styles. 

What if “regular” CS faculty each taught elements of inclusive design in “regular” CS courses across an undergraduate curriculum? Would it affect the CS program's climate and inclusiveness to diverse students? Would it improve retention? Would students learn less CS? Would they actually learn any inclusive design? To answer these questions, we conducted a year-long Action Research investigation, in which 13 CS faculty integrated elements of inclusive design into 44 CS/IT offerings across a 4-year curriculum. The 613 affected students’ educational work products, grades, and/or climate questionnaire responses revealed significant improvements in students’ course outcomes (higher course grades and fewer course fails/incompletes/withdrawals), especially for marginalized groups; revealed that most students did learn and apply inclusive design concepts to their CS activities; and revealed that inclusion and teamwork in the courses significantly improved. These results suggest a new pathway for significantly improving students’ retention, their knowledge and usage of inclusive design, and their experiences across CS education—for marginalized groups and for all students. 

The tools and infrastructure used in tech, including Open Source Software (OSS), can embed “inclusivity bugs”— features that disproportionately disadvantage particular groups of contributors. To see whether OSS developers have existing practices to ward off such bugs, we surveyed 266 OSS developers. Our results show that a majority (77%) of developers do not use any inclusivity practices, and 92% of respondents cited a lack of concrete resources to enable them to do so. To help fill this gap, this paper introduces AID, a tool that automates the GenderMag method to systematically find gender-inclusivity bugs in software. We then present the results of the tool's evaluation on 20 GitHub projects. The tool achieved precision of 0.69, recall of 0.92, an F-measure of 0.79 and even captured some inclusivity bugs that human GenderMag teams missed. 

How should empirical researchers conduct controlled, remote “lab” studies in the uncontrolled, noisy conditions of each participant's own home? Volatility in participant home environments, hardware, internet connection, and surrounding distractions takes the “controlled” out of controlled studies. This paper recounts our in-the-trenches mitigations for designing and conducting two complex controlled studies under COVID, in which participants, from home, interactively localized faults in an AI system. The studies with our COVID-era mitigations in 5 categories-Privacy/Security, Data Collection, Control, Technology Issues, Payment-ultimately produced crisp results beyond what we thought possible under such uncontrolled circumstances. 

Motivation: Although CS Education researchers and practitioners have found ways to improve CS classroom inclusivity, few researchers have considered inclusivity of online CS education. We are interested in two such improvements in online CS education—besides being inclusive to each other, online CS students also need to be able to create inclusive technology. Objectives: We have begun developing a new approach that we term “embedded inclusive design” to address both of these goals. The essence of the approach is to integrate elements of inclusive design education into mainstream CS coursework. This paper presents three curricular interventions we have developed in this approach and empirically investigates their efficacy in online CS post-baccalaureate education. Our research questions were: How do these three curricular interventions affect (RQ1) the climate among online CS students and (RQ2) how online CS students honor the diversity of their users in the tech they create? Method: To answer these research questions, we implemented the curricular interventions in four asynchronous online CS classes across two CS courses within Oregon State University’s Ecampus and conducted an action research study to investigate the impacts. Results: Online CS students who experienced these interventions reported feeling more included in the major than they had before, reported positive impacts on their team dynamics, increased their interest in accommodating diverse users, and created more inclusive technology designs than they had before. Discussion: These results provide encouraging evidence that embedding elements of inclusive design into mainstream CS coursework, via the interventions presented here, can increase both online CS students’ inclusivity toward one another and the inclusivity of the technology these future CS practitioners create.