I’ve been so busy lately that I haven’t even had time to post notice that I have a new article published in ALT-N. I’ve been having conversations on and off with Rob Abel about ways to ensure that educational technology standards (and, of course, the educational technologies themselves) are more effectively informed by our developing understanding of best practices in online teaching and learning. More recently, I’ve been having somewhat similar conversations with Seb Schmoller, except in the context of ALT rather than IMS. Coincidentally, Seb sent me an issue of ALT-J that talks about the use of pattern languages to make sure that accepted best practices in online learning are more effectively informed by various cognitive and learning theories, and vice versa. (Longtime readers know that I have a fondness for notion of pattern languages and have even created a category on my blog about applying the concept to education.) As I read the article, it occurred to me that use cases serve a similar bridging function between software users/practitioners and software developers. If you could form a bridge between a pattern language of educational best practices and a body of use cases that describe how software could support those best practices, then you might really have something. Hence, the article.
As usual, Stephen Downes as a few nits to pick.
To begin with, he complains about the use of the word “praxis,” which he describes as “just the word ‘practice’ with an attitude.” It’s true that “praxis” is often incorrectly understood as and used interchangeably with “practice,” which is why I usually avoid using it. I chose to use it this time for two reasons. First, the authors of the article on pattern languages used it, so if I chose not to use it I would be creating an inconsistency in language which I would have to take significant word count to explain. More importantly, though, they had used it correctly. Praxis, properly understood, refers to the set of best practices that is empirically derived from practice (as opposed to being the practice itself). It is a kind of experiential-derived theory and is meant to be contrasted to more classical scientific theory. So principles of physics are theory while principles of engineering are (generally) praxis. Or, in this context, principles of education derived from cognitive psychology are theory while principles of education derived from teaching experience are praxis.
His other complaint is…well…I’m not sure what it is. He writes,
I’m uneasy with this – it’s hard to articulate why, exactly – but I don’t think software should be designed to ‘do things’ so much as it should be designed to ‘create capacity’. I know that’s not a very clear distinction. But it’s like the difference between ‘process’ and ‘creation’.
He’s right about one thing. It’s not a very clear distinction. In fact, I have no idea what he’s talking about. The only thing I can think of regarding “creating capacity” is Don Norman’s concept of affordances. But affordances are entirely consistent with use cases. In fact, use cases are an excellent (and commonly used) way to ensure that your software is designed to “create capacity” in the way that users want.
So I guess I’m still in the dark. If Stephen (or anyone else) wants to couch his criticism in concrete terms that are consistent with the…um…praxis of user-centered software design, then I’ll be happy to respond further.