This is an interesting collection of videos and background materials on End-User Development — situations when end users design and develop software for their own use. If you’re old enough, you would remember BASIC and HyperCard — tools that let anyone develop simple games and applications. A great example is “Spelunking” game totally developed in HyperCard (these guys when on to develop “Myst”!). I’ve made a few games like this myself. And of course FileMaker is another system that allows application development by the end users — we have one for time tracking. There have been many many others, and unfortunately, many of them are now gone.

The discussion on what happens when end users develop for themselves is fascinating. Most times, these users are experts in their own fields and are not software developers (some have no and some have little formal training). Thus there are cultural differences between “real” programmers and end users that take up programming to achieve their own goals, often because they can’t find what they need out in the world. These end-user designed products have strengths and they also have many weakness. In particular, these products are tightly focused on the needs of those that developed them and they are the products of the programming skills that these people have (or lack of those skills).

As an educator, I often point out that being a teacher is not the same as being a curriculum developer — the latter requires a different skill set. When the burden of curriculum development is placed on the shoulders of teachers, the results are very spotty. And the teachers don’t have the time to develop curriculum — teaching is a full time job. I’m bringing up teaching and curriculum development because there’s a parallel here between product developers (particularly software) and curriculum developers, and end-users and teachers. [Teachers have also been known to develop software.] After the product is finished, a professional product development team works hard to keep it up to date and up to standards, releasing updates, plugging up security holes, etc. End-users tend not to have time for up keep. The product works for them on their system, and that’s all they really need.

End users also tend not to document their code: “If it was hard to write, it should be hard to understand.” That was a saying when I first started to program back in the early eighties. Mostly, though, it’s about lack of interest in documentation — “I know what I did, I don’t need to explain it to others, it’s for my use only.” Such attitudes are common and lead to short product shelf life.

But the beauty of end-user development is that their products are usually great at the thing they do and they are very tightly targeted to their users and their environment of use. Commercial products have to be more general, end-user products are all about customization — products for one.

I wish we had more great, easy-to-use tools so that many people can take control of their environments by designing for themselves. Andy diSessa, my dissertation advisor at UC Berkeley, developed BOXER — a system that allowed end-user development. It was a great educational toy.

Interestingly enough, WordPress can probably be considered another end-user development system…

I could go on and on this topic, but instead, I’ll introduce you to Interaction-Design.org materials on this subject. Enjoy!

To watch the rest of the free videos and to read the chapter on end-user development, please visit here.