elearning2.0

Graham notes, in his blog, a point that came up while we were chatting on the phone this morning:

...there is a world of difference between someone sitting down to develop use cases when this is the thing they are doing i.e. installing, testing, using, a service or a piece of software as the task in itself - and using the services and applications as one small part of their everyday working life.

This is a surprisingly important point, and one which is surprisingly hard to get across. I hope we can illuminate the issue with further discussion - and some examples - over the next months.

I replied at length in his blog, and not being one to use prose once-only, I paste most of it below as well :o) ... see the extended text for this entry.

This is a much more important issue than it sounds, because by enabling casual, connected gestures of content-creation, systems like API-enabled weblogging and del.icio.us bookmarking let us share context to at least some extent. If it isn't *really* easy to post in the context of what I'm doing now - if I cannot make lots of tiny content-connecting/creating/categorising gestures without stopping what I'm doing - the good systems effects that we see in del.icio.us for instance will not emerge.

Extended text for this entry:

Cheers Graham - it is good knowing there's almost always someone else slaving at a computer early on a Saturday morning :o) But seriously, some of my 'best' ideas have come during the phone chats Graham and I sometimes indulge in of a lonesome Sunday morning.

The point Graham brings out needs to be made forcefully and exemplified vividly I think. A lot of people seem to miss this point. In our busy world of knowledge work, few of us ever get to be sole and full-time users of one computer system, doing one kind of task. Our work is spread across different systems, applications, processes and purposes.

Good computer systems should make it very quick and easy to 'pop in', 'out' or 'over' to them while doing other work in other contexts and systems. They should let me keep doing things my way, even if for a few minutes I will be sending things their way.

That's why I hate 'repositories', Big Standards and closed content-management systems - they are designed as if the only thing I ever do is post content to that particular portal or repository. By the time I've forgotten my password for them a couple times, I just stop using them. In fact, as Graham noted in our chat this morning, the number of different places where we post content is increasing all the time - Graham's joomla and elgg blogs as well as this one, for instance.

And that's also why I love the simple APIs of the modern web. It's so easy to pop over to ecto to make a post regardless what 'place' the post is going to -- provided that the 'place' talks one of the weblogging APIs so ecto can remember where it is for me and I can forget about its peculiar user interfaces.

This is a much more important issue than it sounds, because by enabling casual, connected gestures of content-creation, systems like API-enabled weblogging and del.icio.us bookmarking let us share context to at least some extent. If it isn't *really* easy to post in the context of what I'm doing now - if I cannot make lots of tiny content-connecting/creating/categorising gestures without stopping what I'm doing - the good systems effects that we see in del.icio.us for instance will not emerge.

And it is only when we try to drive these systems in that way that the tricky little use-cases of future elearning start to become evident. For instance, posting a few links to del.icio.us does not illustrate anything at all about the system that del.icio.us users have created... to 'get' the effects you have to try to drive the connections in context.

Which brings me to the trivial but interesting little use-case I was describing to Graham which got this started :o) See this post in the KNotations blog (where my techie writing is supposed to happen) for a description of a little script we've written that helps co-ordinate multiple del.icio.us accounts, so that multiple users can contribute to project bookmarks. So we now have 4 new project del.icio.us accounts, each contributed to by multiple users, each of whom thereby contributes to multiple accounts. See for instance the EGCRF tag cloud or the opendock project on del.icio.us.

It's not the co-ordinating-accounts script that represents the hard work to get to that point; it was the process of getting project colleagues engaged in social bookmarking, and nurturing this to the point where interesting resources emerge. And without that kind of real-world work, the requirements for these little co-ordinating bridges would not be evident.

This is a really trivial example which I hope begins to illustrate the point. I have a lot of notions about further work that ought to be done in this direction, if only I wasn't simultaneously doing so many other things :o)