My Vision (the clarification)
There were a couple of good comments on my My Vision post (some on the post and otherwise) that I wanted to address.
First, I want to be clear that this is not the “Oslo” vision. Never has been, never will be. It is my personal vision. I have been working on it since before there was an “Oslo”. I will be working on it long after that codename fades from the collective memory. I do view “Oslo” as a step on the right path, otherwise I would not be working on it.
BTW: This reminds me of a passage in a book I read a long, long time ago: “I’m not following Tanis, I just happen to be traveling in the same direction“.
I often joke that I hope my mom, my wife, girls and I are still alive to see this vision come to being. I think it is going to take longer than I hope, but I am committed.
That said, I think people really underestimate the power of environments like Excel, Squeak, etc. to get us a long way toward the the broad goals I highlight. I am continually amazed at the ability of “non-programmers” to do amazing things in these sort of “live” environments with a (fairly) simple set of primitives.
Some of us in the moz dev lab have a similar vision too. We are experimenting with ways in which to get there with JavaScript. Fun times my friend!
dalmaer
24 Jan 09 at 08:38
> I am continually amazed at the ability of “non-programmers” to do amazing
> things in these sort of “live” environments with a (fairly) simple set of primitives.
We should ask ourselves, way more than we do, why we find this amazing.
I keep coming back to Eric von Hippel’s ideas about user innovation, and user innovation toolkits.
A snowboard is an example of a user innovation toolkit — a medium in which lead users can, and do, express their needs directly through modification.
A modern automobile, unlike its predecessor, is a counter-example.
We talk a lot about designing for simplicity, but not nearly enough about designing for user innovation.
Jon Udell
24 Jan 09 at 16:13
Jon’s snowboard example is a good one. The essence for me is that the ‘customizable’ thing provides two functions: (a) it provides a clear and tangible way to solve one problem very well and (b) allows user innovation to journey away from (a) in ways not originally anticipated.
Excel or snowboards come from the (a) ‘clear solution provider’ task/goal oriented tool angle, while we as developers often try to come at the problem from the ‘framework’ or generic angle to try and specialize/create a single useful tool from the tooling we lay down. Coming from that generic-> specialized direction is harder, although I agree the ’satisfaction try/change loop’ of having a true interactive environment helps get us there.
Put another way, domain specific customization may ironically be ‘domain specific’ in that you have to meet two needs of (a) being immediately useful for a task and (b) providing opportunity to customize in a natural way. Without concrete examples of useful things first then the modification points seem two overwhelming and esoteric.
David Ing
24 Jan 09 at 17:30
I think user innovation is important and obviously on the rise, not alone but as part of a larger story which includes developers’ enhanced leverage to specify behavior at their level. Some aspects of application behavior and appearance can be left to the end user, or certain groups of users, and some fit firmly in the realm of the software engineer. The trick is to decide which is which.
Jeff Atwood wrote an article last week about grocery stores off-loading some of their checkout work to the customers themselves (http://www.codinghorror.com/blog/archives/001215.html), which reminds me of this pattern of shifting a boundary that’s been in place for a while.
There’s a balance between the constraints a developer must add to prevent user error and lead them successfully through use cases, and the amount of configurability to allow the user before allowing the program to venture into untested and unproved states.
Software engineers are the ones who understand those issues, and that’s why we’ll always need them. End users want to focus on their core competencies.
Dan Vanderboom
29 Jan 09 at 20:46
“Software engineers are the ones who understand those issues, and that’s why we’ll always need them.”
Sure. But let’s need them in the highest and best way: To create user innovation toolkits. That’s a wildly hard problem. But here’s the payoff:
“One of Eric von Hippel’s punch lines is that 85% of all interesting innovations in all industries come not from the suppliers but from the users. What rational person today would give up the opportunity to do the vast majority of their innovation by restricting their users from accessing and becoming part of the design cycle?”
That’s Michael Tiemann, quoted here:
http://weblog.infoworld.com/udell/2005/10/13.html
“constraints a developer must add to prevent user error and lead them successfully through use cases”
In von Hippel’s GE Plastics example, the use case is that customers design their own plastics. The constraint enforced by the user innovation toolkit is that the plastics they design are guaranteed to be manufacturable by GE.
Jon Udell
5 Feb 09 at 15:25