1 / 23

From EUP to EUSE: What We’ve Learned

From EUP to EUSE: What We’ve Learned. Margaret Burnett Oregon State University. End-User Software Engineering: Beyond EUP. Today, end users can create programs. e.g., macros by demo, spreadsheets, email filtering rules,web authoring tools, graphical languages... But what happens next?

ervin
Download Presentation

From EUP to EUSE: What We’ve Learned

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. From EUP to EUSE:What We’ve Learned Margaret BurnettOregon State University

  2. End-User Software Engineering: Beyond EUP • Today, end users can create programs. • e.g., macros by demo, spreadsheets, email filtering rules,web authoring tools, graphical languages... • But what happens next? • Usually, bugs <many citations here>. • Compounded by overconfidence. • How to help solve this: learning from the end users. - 2 -

  3. End-User Software Engineering (cont) • What is EUSE? • Takes into account all of the software lifecycle. • Not just “create new programs”. • Requirements, design, programming, debugging, testing, maintenace, reuse, … - 3 -

  4. Interest in EUSE • Recent events • International media interest:NSF press release, ACM TechNews, CNN.com, CBS.com, PC Magazine, IEEE Software editorial… • CHI’04/05/07/08 SIGs, ICSE’05 workshop, CHI’06 workshop, many papers at recent CHIs, ICSEs, and VL/HCCs, ... • Here at ICSE’08 • This workshop, EUSE keynote! - 4 -

  5. What We’ve Learned about EUSE from End Users

  6. Organization of this Topic • Spreadsheet debugging • and testing and code inspection • In light of gender differences • Unwitting end-user programmers • “Witting” end-user programmers • How tools can be more natural for end-user programmers - 6 -

  7. Spreadsheet Debugging • Bishop/McDaid, Burnett et al., McDaid et al. • Via code inspection • Code inspection matters in debugging and spreadsheet debugging • to both males & females, but especially to females - 7 -

  8. Eight End-User Spreadsheet Debugging Strategies • Dataflow • Testing • Code Inspection • Specification Checking • Color Following • To-do Listing • Fixing Formulas • Spatial 8 - 8 -

  9. Code Inspection • Recommended by spreadsheet auditors. • Why females particularly like it: possibly information processing: • Comprehensive vs. heuristic processing. • In our studies, end-user programmers usually start with code insp, then move on to testing and other approaches if needed. - 9 -

  10. Code Inspection by EUPs • Business professionals outperformed business students at debugging. • Inspecting more cells led to more errors corrected. • Inspections focused more on top and left in groups, in bottom-line cells, and in formulas producing numeric outputs. - 10 -

  11. What Else We Know about Male & Female Spreadsheet EUPs • For females: self-efficacy matters in spreadsheet auditing feature usage. • Not so for males. • Males tinker with new features more. • For males, this is sometimes good, sometimes not. • For females, tinkering is always good, but they don’t do it enough. - 11 -

  12. What Else We Know about Spreadsheet EUPs (cont.) • WYSIWYT Testing (Burnett/Rothermel) is achievable and useful for EUPs, especially males. • McDaid et al. also showing some success with spreadsheet testing. - 12 -

  13. Unwitting vs. Witting Software Development • Costabile et al., Borggrafe et al., Brandt et al. • A spectrum of end-user involvement in software. - 13 -

  14. Unwitting Software Developers (cont.) • Eg, “meta-design” (Fisher et al., Costabile et al., Borggrafe et al.) • Designing/modeling, and/or working hand-in-hand with professional developers. • Eg, “Tailoring”: Some do not realize that they are doing software development. • Costabile et al. report this with medical domain experts • Petre/Blackwell report this with children game players. • Task-motivated (not programming-motivated), goal-directed, learning incrementally as they go. - 14 -

  15. “Witting” EUPs • Segal’s study: • Scientists who explicitly program, but don’t view their software as an outcome or an asset. • Software not valued, not tested, not documented, not shared. • Clarke and Brandt et al. call EUP developers (and others) like this “opportunistic”. - 15 -

  16. Opportunistic Programming • 5 characteristics (Brandt et al.) • 1. Easier to build from scratch than to understand code libraries. • Happy to use tools new to them, if map well to their task. (Maybe more so with the males?) • 2. When do reuse, use copy/paste. • 3. Process very iterative, debug/edit tightly interwoven. • 4. Code impermanent. • 5. Debugging challenges: less sophistication, multiple languages. - 16 -

  17. Improving EUPs’ Abilities in Software Development • Teaching Software Engineering to EUPs (Umarji et al.) • Bioinformatics developers don’t do software engineering (agrees with Segal’s findings). • They do share. They don’t like to “hand off” outside their domain. • Could benefit from education in QA, documentation, reuse. - 17 -

  18. Related Theories and Support • Relates to Attention Investment (Blackwell) • Cost/benefit/risk. • Relates to Minimalist Learning Theory (Carroll/Rosson) • Paradox of “Active User”. • Strategies to support: • Domain-specific languages/closeness of mapping. • Surprise/Explain/Reward (Wilson/Burnett, …) • Connectts Curiosity to Minimalist Learning to Attention Investment. - 18 -

  19. Helping Tools Be More “Natural” • “Natural” end-user software engineering (Myers et al.) • Approaches/tools based on how end users think. • How do they debug? (led to Whyline) • Studies of people debugging: mostly they ask “why” and “why not”. • Help inform Whyline debugging tool: • for Alice (novices), for Word behavior (EUs), • and now for Java (bringing what learned about EUPs back to professional devs. - 19 -

  20. Natural end-user software engr. (cont.) • How Do UI Designers Design? • They iterate on appearance (no problem) and behaviors (big problem). • Complex, diverse behavior. • They build software prototypes to communicate design decisions. • Poorly supported by current tools. - 20 -

  21. Natural end-user software engr. (cont.) • Studies of professional developers too. • Can reveal insights into emerging issues that will affect EUPs soon too. • E.g., studies of API usability, program comprehension. - 21 -

  22. Conclusion: What we’ve learned • End-user programmers • Are not usually “baby” professional programmers, but do struggle with SE issues. • And have unique problems, different motivations, different langs/tools, gender diffs relevant to EUSE… • EUP studies provide critical info for tools. • And also can reveal new insights that open new avenues for supporting professional devs too. • And sometimes vice versa (apply with caution!) - 22 -

  23. Question • What else do we know about end users that hasn’t come out yet? - 23 -

More Related