1. A Data Model to Help End Users Shape Effective Software
Chris Scaffidi, Mary Shaw, Brad Myers
Carnegie Mellon University
EUSES, Lincoln NE, Oct ‘06

2. Lesson learned this year: End users need a better data model.
Hurricane Katrina Interviews
Contextual Inquiry
Survey of End User Programmers
Topes:
Better Data Model
Improved Data Reuse
Improved Data Manipulation
Improved Data Validation
Overview of past, present, and future work

3. Existing data models have a number of shortcomings.
We performed three studies:
Contextual inquiry of administrative assistants
Survey of end user programmers’ feature usage
Interviews of people who created Hurricane Katrina sites
Key findings, respectively:
Web macro tools cannot do the data manipulation that would be required to automate admin assistants’ work.
End user programmers complained about data manipulation problems more than about software reliability!
Even the frameworks used by skilled programmers lack adequate built-in support for ensuring data quality.
Prior work: studies of programmers and their tools

4. The world is full of “user-level” data.
Examples:
Dates
Credit card numbers
Person names
Quantities of RAM
Product codes
Such data are…
“bigger” than floats and strings.
“smaller” than a database row.
typically domain-specific.
State names
US phone numbers
Bus route numbers
Dewey decimal numbers
Etc…
Prior work: studies of programmers and their tools

5. To be useful, representations of these data must meet certain requirements.
Extensibility
Different people use different data.
 Support creation of new data abstractions by end users.
Shareability
Different people sometimes use the same kinds of data.
 Help end users find & evaluate abstractions.
Flexibility
Data appear in many formats, with exceptions to every rule.
 Support multiple formats, and permit exceptions.
Present work: designing a better model

6. Our “topes” model meets those requirements.
A “tope” defined by a user would have two functions:
Estimating the likelihood that a string “isa” tope instance
Estimating the likelihood that two strings are “equivalent”
Other functions would convert from one tope to another.
Topes would be
Defined by users and/or system administrators
Shared as needed (under a meta-model)
Stored in repositories accessed by programming tools
Preliminary work suggests that an augmented context-free grammar would suffice for defining most topes.
Present work: designing a better model

7. We are collaborating within EUSES to lay the groundwork for future applications.
Web macros (with Cypher, Elbaum, and Koesnandar)
Our corpus of scenarios reveals requirements for tools…
Reformatting data
Triggering exception handlers
Spreadsheets (with Abraham and Erwig)
Preliminary discussions revealed several opportunities…
Finding duplicate values
Finding typos
Embedding topes in templates
Future work: improving data manipulation and validation

8. We are interested in additional applications and collaborations!
The menu of types in many end user programming tools:
Numbers
Strings
What if your users had a wider array of options?
Credit card numbers
Person names
Product codes
With a better data model, how could you help your users?
US phone numbers
Bus route numbers
The sky’s the limit…
Future work: improving data manipulation and validation