540 likes | 719 Vues
Gender HCI and Programming Tools. Margaret Burnett Oregon State University September 2010. Software Features: The only means of human-computer communication. Q : Could p roblem-solving features in programming tools better serve males AND Females ? A:
E N D
Gender HCI and Programming Tools Margaret BurnettOregon State University September 2010
Software Features: The only means of human-computer communication • Q: Could problem-solving features in programming tools better serve males AND Females? • A: • 5 years’ data (spreadsheets) suggests yes. • Last spring, we collected different data, which suggest yes too. • Today’s talk: • Where are the gender differences? • What feature mismatches do they point to? • 4 feature changes that make tools more responsive to the M/F differences we identified.
Why care about gender differences? • 1. Ignorance unwitting barriers. • 2. Studying a population segment to help everyone. • Curb cuts.
Ashley • Graphic design? • The software used: • Flash • Web programming • Hmmm, … art. • Why? • Problem solving style, learning style, confidence, information processing style, … ?
The scope: • Software development (end users to professionals). • Studies of spreadsheet users (lab 2004-9). • Recently expanded to: • A tech support users survey (2008). • Professional devs survey (2005). • Professional devs using Visual Studio, lab videos (2009). • Visual Studio Express hobbyist developers survey (2008). • Hobbyist developers field interviews (2007). • Powershellscripters: lab videos (2008). • End users debugging intelligent programs (2008-2010). • End users working with mashups (2010). The studies:
Research questions • Gender differences in tools supporting software development: • Confidence with the software tools • Feature usage • Tinkering with the tools • Strategies • How: • Triangulate across multiple populations and software development situations.
theories hypotheses prototype results Research paradigm Derive Evaluate Refine, test,understand Redesign
Spreadsheet users 250F/250M • 10+ lab studies • in which participants did spreadsheet debugging tasks. • About 500 participants in all (equal F, M). • Experienced spreadsheet users. • Equal number of males and females. • Excel and our own spreadsheet prototype. • Statistical studies and qualitative ones.
Feature interest 250F/250M • Task: Find and fix errors in formulas. Activity Profiles Male Female
Potential tie to self-efficacy • A form of self-confidence: • W.r.t. a specific task. • A general theory. • Predictive of: • Willingness to try, perseverance, … • Literature: • Females low computer self-efficacy.
Features + self-efficacy 250F/250M • Type familiar: formula edits. • Type taught: √, . • Type untaught: X.
Results: Confidence and features 250F/250M • Self-efficacy as a predictor of effective use: • F lower computer self-efficacy than M. • F: self-efficacy mattered to willingness to use debugging features. (Not so for M).
Interest in new features 250F/250M • Try the features? • Time to first usage: • Use the features? • Genuine engagement: Time-to-first UnT. T. Fam.
Their goal: Find and fixbugs 250F/250M No difference Difference
A self-fulfilling prophecy 250F/250M • Females lower self-efficacy • Females self-efficacy feature usage. • Not true of males. • Females less likely to accept features • Opinion: too long to learn. • But: no difference in learning! • Using features helps! • Not using features ties one hand behind their backs. • Formula editing is the only way to introduce new bugs • so doing this increases probability of introducing bugs.
Tinkering with features 250F/250M • Males: • Tinkered more. • Sometimes they went crazy. • When did so “pausefully”, it helped. • When went crazy, it hurt. • Playful experimentation • Females: • Tinkered less. • But when did, did so “pausefully”. • Pauses important? • Education literature: pauses improve critical thinking • Our results: pauses predictive of … • Understanding • Effective use of these features Tinkering“harder” Tinkering“easier”
“… So 0 to 100 [is the guard I’m entering], ok. Ok, hmm… So, it doesn’t like the -5 [...]. They can get a 0, which gets rid of the angry red circle.” Motivation to use features 250F/250M
“The first thing I’m going to do is go through and check the guards for everything, just to make sure none of the entered values are above or below any of the ranges specified. So, homework 1—actually, I’m going to put guards on everything because I feel like it. I don’t even know if this is really necessary, but it’s fun.” Motivation to use features 250F/250M (continuing from above): “…ok, so it doesn’t like my guard apparently. Ok, ah ha! The reason I couldn’t get the guard for the sum to be correct is because the sum formula is wrong.”
Possible root of feature diffs:Debugging strategies 2:0F/250M • Dataflow • Testing • Code Inspection • Specification Checking • Color Following • To-do Listing • Fixing Formulas • Spatial
So, where are we? • Have seen: • Confidence • Features: • Usage, Tinkering, Attitudes • Strategies Howwidespread? Beyond spreadsheets
Users of tech support 32F/77M • Admins, UX/Design/Techwriters/etc, PMs, Devs. • 32 F, 77 M. • Statistics: non-parametric ANCOVA (rank transformations) to account for: • gender imbalance, gender diffs in technical jobs, gender diffs in years experience, indivdiffs in age.
Confidence and features 32F/77M • Users of tech support:“I’m an expert user” • A rough “feature” count (listed apps) pink
Exploring/tinkering features 32F/77M • Stay with familiar features: • Fiddle with new ones: pink
Feature attitudes: Are these users telling us … ? 32F/77M • Males: A love affair with exploring technology? • Play with it. • Explore it. • Tinker with it. • Doesn’t matter if it has to do with their jobs. • Females: Confidence, risk, motivations→To let me do my tasks/jobs well? • Admins: to do admin work. • UX, designers: to do UX work, design. • PMs: to do PM work. • Devs: to develop software, not fiddle with the environment. • If so, what is one feature they should feel differently about?
Wizards 32F/77M pink blue blue
A different population:Hobbyist Developers 112F/2367M for first time or casual • People who program because they choose to. • Hobbyist users of Visual Studio Express (survey). • 112 F, 2367 M. • Stats: Rank-transformed, ANOVA • Why not ANCOVA: no signif diff in backgrounds.
Hobbyists and wizards 112F/2367M • Hobbyists whose top 3 wishlist picks were “more wizards”:
Hobbyists and features wishlist 112F/2367M Features ProportionRanking Feature in Top 3
Wait! F’s were only 5% of users.Who cares? 112F/2367M • Don’t care: • Just serve existing users. • Do care: • This 5% is just current F hobbyist users. • How to attract more? • Maybe if we knew more about their motivations and attitudes...
Hobbyists’ motivations, attitudes:exploring technology/features 2F/4M • Ethnographic study: hobbyists • 3 beginners (1F, 2M), 3 intermediates (1F, 2M). • Ethnographers concluded VS/Express better fit to intermediates (M/F) than beginners (F). “Lisa”: Non-programmer.Technology: results-focused. Uncomfortable upgrading familiar programs to new versions. “Michael”: Non-programmer.Technology: very enthusiastic.Why: learn programming. “Alison”: Intermediate programmer.Technology: “care about the code”.Why: joy of learning programming. “VS intimidating … all kinds of stuff on first page.” “Sam”: Intermediate programmer.Technology: risk taker, tinkerer.Why: run a web business. “Lew”: Intermediate programmer.Self-proclaimed “geek”.Wants technology to be a tool, not an end in itself.
But, what aboutProfessional Devs? 23F/134M • C, C++, C# developers (survey): • 23 F, 134 M. • Statistical analysis: rank transforms, ANCOVA to account for: • gender imbalance, gender diffs in years experience, indivdiffs in age. • Devs working in Visual Studio, new APIs (lab videos): • 2 F, 2 M. • Qualitative analysis: • Coded their strategies. 2F/2M
Features: Devs • F devs: Visual Studio is the one! pink
Professional DevsBeta-Testing 96F/144M • Prefer wizards • Exploring tech ✔ • Only learn required ✔ • Piloting new tech ✔ • Using workarounds ✔ • Upgrading software ✔ • Prefer established
Changes that can reduce barriers • Still emergent, but … • … empirical evidence suggests 10 ways to make tools more effective for men and women: • 1. Wizards. • Evidence: the studies I just presented. • 2. Nuanced judgments. • Evidence: spreadsheet studies. • 3. Addictive tinkering dissuaders. • Evidence: spreadsheet studies. • 4. Strategy help. • Evidence: spreadsheet studies.
2. Nuanced judgments (revealed by F) • When asking for judgments, eg on correctness. • Before: • The change: • The effect: • Significantly reduced differences in how males vs. females utilized the tools. • Everyone used them, helped both M and F. Left-click
3. Addictive tinkering dissuaders (revealed by M) • When task is problem-solving, interactive features with feedback, don’t want addictive tinkering. • To solve, make cost of a tinker just a little higher. • Before: 1 click: • After: 2 clicks: • Effect: • Stopped M excessive tinkers, didn’t hurt F. click click click
4. Strategy help • “Active users” • Focus on Doing (not on Learning). • Cost of learning/doing vs. benefits. • A prior study: • 30% of what M/F wanted to know was strategy. • More than twice as many comments on strategy as on features. • Before: help on features. • The change: • 1-minute video snippets • ...and equivalent hypertext... • integrating features with strategy. • The effect: • F used more features, • Everyone liked system better.
Lab Results: 3 changes together: M/F Differences in Feature Usage • TF tinkered more with the features • TF used more than CF. • Because of “maybe marks”? (TF > TM).
Lab Results: 3 changes together: M/F Differences in Feature Usage • Gender differences in usage: gone. • Females: tinkering up. • Males: tinkering down.
Lab Results (cont):M/F Differences in Self-Efficacy • TF vs. CF: Self-efficacy decreased less. • TF vs. CF: Judged their performance more accurately (Bugs Fixed better predictor of Post SE). • Triangulated with post-sessionquestionnaire answers.
Lab Results (cont): Attitudes Information (+) All (+)
The Big Picture And Ashley’s Picture
Back to Ashley… • M/F differences • Self-efficacy, motivation, problem-solving styles, information processing, etc. • No one male or female completely fits the M/F statistical patterns. • Designing for bothgenders benefits everyone.
Conclusions • More than a dozen studies • Involving more than 3500 people • Across populations ranging from end users to professional programmers • Across numerous domains: • spreadsheets, scripting, VB, mashups, debugging intelligent software. • These differences are • Real and • Pervasive across populations. • Solution: taking down barriers • Changing the features can make a difference • and doing so helps everyone. Tinkering “easy” Tinkering “harder”
Thanks to… • Andy Begel, Chris Bogart, JJ Cadiz, Rob DeLine, UmerFarooq, Stephen Giff, Jonathan Grudin, Monty Hammontree, Jofish Kaye,Cory Kissinger, Andy Ko, Todd Kulesza, Joey Lawrance, Scott Moffat,VidyaRajaram, Martin Robillard, Jacqueline Russell • Laura Beckwith, Alan Blackwell, Jill Cao, ThippayaChintakovid, Curt Cook, Mary Czerwinski, Scott Fleming, ValentinaGrigoreanu, ShamsiIqbal,Vaish Narayanan, Thomas Park, Kyle Rector, ShraddhaSorte, NeerajaSubrahmaniyan, Gina Venolia, Susan Wiedenbeck • The Gender HCI collaborators:
Resources • The EUSES Consortium site • An overview of Gender HCI work, • and our papers, • and others’ papers. http://eusesconsortium.org/gender/ Coming soon ... NCWIT Promising Practices Announcement