Design

This post was written in response to danah boyd’s post, “Facebook and Techcrunch: the costs of technological determinism and configuring users.” danah focused on recent (and not so recent) attempts by social network sites like Facebook to regulate how individuals relate to others when using their service. I noticed that danah’s argument—expressing a consistent point of view, whose development you can trace in her writing—reinforces the criticisms I made of the Spock service last December.

Today I'm attending Adaptive Path's UX Week in Washington DC.  Kevin Brooks from Motorola Labs gave an interesting presentation on storytelling.  The comment I enjoyed most was about silence being the "space of creativity".  Brooks encouraged listeners to accept silence and to let creativity spark and unfold without trying to change it's course by influencing the silence. 

When I was in college, we spent one session of my foundation design class talking exploring the concept of negative space -- this is the visual equivalent of silence.  And I think it's a concept that technologists and web designers often forget.  So often we get caught up in maximizing the available real estate (a web page or the ten minutes we have to present to a committee) to deliver a story that we ignore the incredible value of silence.  By building applications that use more negative spaces (silence) we could really improve our user experience -- because we would be giving them a space to create and collaborate with us to develop the story.

Most discussions of games in education focus on their utility as course components.  Educators rarely take a step back to look at gaming as a design discipline.  Taken together, game design and instructional design might perhaps both be considered sub-fields of engagement design - the design of engaging structured experiences.  The scope of engagement design would include interface design, graphic design, maybe even advertising and merchandizing... theme park design...  and theoretically each of these fields could cross-pollinate the others.  But for now I'm just going to look at one classic work in game design that offers an interesting framework for instructional design.

In _Rules of Play_, Katie Salen and Eric Zimmerman introduce an analytical framework for thinking about game design that could be transposed to the instructional design field, supporting the creation of better courses revealing a new way of thinking about instructional design that could be used to make courses more engaging.  They suggest three cognitive schemas for understanding games:

This is a response-to-a-response-to-a-post: my response to Kyle Johnson's comments on Jon Udell's post about the tacit dimension of tech support.

Jon (and Kyle) argue there are 2 kinds of tacit knowledge relevant to IT support: knowing how to do stuff; knowing where to find stuff. They argue that preferences for one over the other contribute to misunderstanding and poor communication between users and helpdesk staff.

But if you're trying to understand how users work, how people function, this doesn't really get to the nub of the problem. From the point of view of the non-expert or novice user, these two species of tacit knowledge (the knowing-how, and the knowing-where) amount to exactly the same thing.

Jon writes, humorously and sympathetically, about what it's like to provide computer support for his "non-geek" wife. From her perspective, he's an IT God, whereas from his perspective, he just knows where to look...

But "knowing where to look" is itself inherently procedural.

"IT expertise", like any form of expertise, involves intricate sets and combinations of situated actions, physical and mental. It also involves tacit understanding of the potential and limits that are attached to procedures: including the possible responses that a system might make to user interventions. Novice users lack this. That's why they are so terrified that if they touch something, they'll break it.

Dealing with a particular computing problem is not just a matter of tacitly knowing some content: in this example, knowing to look at a particular website, go to a particular search engine, or use a particular search term. All of these elements form part of a tacit understanding of procedure. Call it workflow, if you prefer.
<?xml:namespace prefix = o />
Lucy Suchman's Plans and Situated Actions: The problem of human-machine communication gives a better way to understand these issues. Based on her time at PARC, back in the eighties, Suchman's research shows that IT helpdesks and manuals usually fail to assist users because they work on the principle that users' interactions with a system are, or should be, strongly "planned" or "intentional".

The problem is that explaining a problem (or a process) in a step-by-step, one-at-a-time manner doesn't help novice users act like experts. It merely provides a prescribed framework for action that is diametrically opposed to the ways that people, experts included, actually work. Do as I say, not as I do...

So, OSPI 2005. I could talk about the weather: hot and humid. Or the numbers: 145 people, 8 countries, 2 days. Or the people: including Darren Cambridge (George Mason U), Chris Coppola and Janice Smith (r-smart), Jeff Haywood (U of Edinburgh) and Susan Kahn (IUPUI). So...what's next, what's new...?

With OSPI 2.0 unveiled, we learned that its future is now pretty much bound up with that of Sakai. This is not just a question of architecture and admin underpinnings, it's also to do with the way the project will be managed in future. Word is, the OSPI board may disappear altogether; the project may be managed via an Apache-style foundation. This could be a real turning point for the OSP development. For the moment, I'm reserving overall judgment as to the costs/benefits of this apparent convergence. I do have questions about the financing aspect, and I also wonder how OSPI plans to balance "collaborative" development with development that is driven by lead institutional partners.

Most interesting "user" development, from my perspective, is the portfolio matrix tool - looks great, and is flexible enough to support a range of activities. IUPUI has invested time/energy in developing a pedagogy of "matrix thinking", drawing on Stanford's Helen Chen's work on "folio thinking". This is something to watch.

Some immediate thoughts/reactions:

1. We need to think hard about what constitutes "success" for the open source development model. More obviously: does "success" mean simply that we held the conference, and the people came? Or that the OSP is financed sustainably, develops in a coherent way, and is being used by multiple institutions in 3 years' time?
2. We need to keep the diversity. OSPI 2005 attracted academic teaching staff, educational technologists, faculty liaison, software developers, and vendors. This diversity is a major strength of the OSPI community. I have to say it stands in marked contrast to the Sakai conference - held in the same venue, immediately prior to OSPI 2005 - which is much more developer-centric. To this end, I floated the idea of starting up an evaluation group as a way of keeping faculty involved and making sure the OSP fits their diverse needs. This may be coordinated through EPICC (European Portfolio Initiatives Coordination Committee) - watch this space for details.
3. We need less architectural change, and more tools. This one kind of follows on from the second point. If you're showing a faculty member a VLE/CMS, it's hard for them to see the benefits of an "empty box": they want tools and content. But unless we slow down the number of releases and the number of major changes to the "plumbing", in Brad Wheeler's phrase, we'll never get to the tool-making stage. (I believe this point applies regardless of whether we conceive of e-portfolios as a "tool", a "practice", or a "community").