This document explains the thought processes that led me to decide on this potential PhD topic. Please comment 🙂
Some weeks ago I came across a special topic in the ACM (Sutcliffe & Mahandjiev, 2004) about end user development. It reminded me of a whole area of software I have not been involved in: end user development in general and programming by demonstration (Curry, 1978) in particular . I believe that the current development environments we have are crude and equivalent to scratching our likenesses onto cave walls.
I then set about thinking about who “end users” are and what kind of “development” they might want to do. I was reminded of my friend Bill who owns his own small business and employed me to write an Access database for him. Bill is very intelligent and diligent but he was unable to create this, ostensibly simple, database application himself. So, I set about thinking how I could solve the problem for people like Bill. In short, how can I make it so people like Bill don’t need people like me?
To give end-users autonomy to create and maintain their own, well designed databases / data centric applications.
To investigate, design and implement a system for end user database development.
The most difficult part of any PhD. These are some that I think would be worthwhile pursuing:
- What does a database look like?
End user studies to explore their mental models of databases
- Can end users effectively use existing tools to create their own databases / data centric applications?
Expertise tension? (Beringer, 2004)
- To what extent, if any, do users / professionals have difficulty creating flexible, normalised databases?
Over the next year, I plan to write a number of “internal” papers. Not directly publishable except to my department and other mentors. The goals of these papers are two-fold:
- Convince the academic community that my ideas have merit
- Break the research thesis up into smaller more attainable theses which combine to make the whole
- Define and contrast: “database”, “data-centric application”, “Transaction Processing System”, “ERP”, “DSS”
- Does it matter? : “The interface is the system”
- Silver (definition of DSS versus TPS)
- ERDs are a bad user interface for database development.
Too Fregan & abstract (Smith, 2001)
Wand & Weber (Wand, Storey, & Weber, 1999
â€œgulfsâ€ (Norman, 1988)
- End users , even trained professionals need help creating flexible, normalised schemas.
Experiments on IS graduates?
Intelligent agents, Programming By Demonstration, expert systems etc
- Transaction processing Systems suffer from a lack of attention by the End User Development / Programming by Demonstration.
I haven’t read these references as well as I should have, but at least they form a starting point for ideas.
- Beringer, J. (2004). Reducing Expertise Tension. Communications of the ACM, 47(9), 39-40.
- Curry, G. (1978). Programming by Abstract Demonstration. Unpublished PhD, University of Washington Seattle.
- Norman, D. (1988). The Design of Everyday Things. New York: Doubleday Publishing.
- Smith, D. (2001). Novice Programming Comes of Age. In H. Lieberman (Ed.), Your Wish Is My Command: Programming by Example (pp. pp. 351-369). San Francisco: Morgan-Kaufmann.
- Stamen, J. P. (1993). Structuring Databases for Analysis. IEEE Spectrum, 55-58.
- Sutcliffe, A., & Mahandjiev, N. (2004). End-User Development. Communications of the ACM, 47(9), 31-32.
- Wand, Y., Storey, V., & Weber, R. (1999). An ontological analysis of the relationship construct in conceptual modeling. ACM Transactions on Database Systems, 24(4), 494 – 528.