OOPSLA - The End of Users
Notes from Mary Beth Rosson's keynote, The End of Users:
Traditionally, there is a distinction between the users and the software developers. The received view is that users convey their needs to software developers, who then develop an application that is delivered to the users.
This paradigm is changing. It is getting much more complex. For one, there are multiple users who are connected in various ways. This unpredictable usage context means that the requirements now include a fair amount customizations and appropriation.
This means that what a software developers need to be producing are components that can be mixed and matched, knowledge bases than can be queried, infrastructure and constructions kits.
Based on this premise, we need to thing of users as developers: "Developers of usages." At this point, Rosson showed example of use developments, including customizing styles in Word, using formulae in Excel, writing code in SPSS, and using Front Page to build simple, interactive web pages that use simple Access databases. When they work, they work, when they don't, there's not much you can do about it.
A user-developer is:
- comfortable with a diverse array of software and data sources.
- wants to pick and choose, configure and interconnect within this array.
- in support of emergent, often collaborative, ad hoc problems and tasks.
This provides a tremendous opportunity including economic benefits:
- Short-circuiting the software development cycle.
- Timely production of informal IT solutions.
As well as opportunities of personal growth:
- Promote feelings of control and creativity.
- Appropriation of IT to actual needs.
This however leads to systems developed by users who may not have the skill to do this kind of development. Examples of the possible extent of these errors is a Fannie Mae spreadsheet that contained a $1.2 billion error. Some reasons for concern include projections that show that by 2012, there will be 55 million business users of spreadsheets and databases. Other estimates that 90% of spreadsheets have errors. Other, less catastrophic errors may be possible. These include annoying errors such as web forms that don't work on a browser, over-active spam filters, Word styles that break formatting, and "research" findings based on faulty analyses.
So, who is responsible for the artifacts that these user developers create: Users say that they need better tools, that prevent them from making mistakes. To this, developers reply that users need to analyze, plan, test and debug the software they build. The answer is that both are correct.
On the one hand users have every right to want smarter tools to guide and enhance the artifacts being developed. These tools should evoke reflection, even a skepticism about a user's self-developed system. On the other hand, we need to promote a broad culture of quality assurance, including new standards of computing literacy.
Some of the challenges to building smarter tools include the invisibility of a lot of computation, as much of what users need to know is hidden from them by the user interface through wizards, dialog boxes and so on. This is desirable by the user, but means that when things go wrong, a user have no way of knowing this. The other challenge is the production paradox: when the users are doing something, they don't want to stop and learn how to do things better.
Possible approaches to tackling these challenges include the availing of interactive visualization, perhaps allowing the users to see the code that is generated for them and interact with it. Another is to build in testing and debugging tools that allow the users to reflect on what they're doing.
Examples of such smarter tools:
As for creating a quality assurance culture, the challenges include user's perspective that they just want to get things done, not learn how to do things. The other challenge is that there is a great variety in user's backgrounds, skill levels, and expectations about computation. Some ways these may be addressed include:
- Starting early in K-12 education.
- Universal access, by taking into account that people are different
- Communities of practice, which is about growing a community around this attitude.
Examples of projects attempting to build a quality assurance culture:
- Youngsters who learn by debugging, Rosson. (ongoing). This is also built around Alice and hopes to integrate Andy Ko's Whyline work, mentioned above.
- Debugging tools that appeal to Women, L. Beckwith (Oregon State University Phd, ongoing).
- Pair programming community simulations, Rosson.
- Sharing and reuse in a teacher community, Carrol, Rosson.
0 comments:
Post a Comment