Clay Shirky: no, *you* shut up!

(cross posted from designedforlearning)

(title nods at Clay’s 2006 talk)

Charlie Beckett hosted Clay Shirky at the LSE a couple of weeks ago, and the Podcast is now available for download – and well worth listening to.

I couldn’t make it to Clay’s talk, but luckily, due to the snow (remember the #uksnow?) some of his interviews were canceled and he generously found some time to have coffee with Niall Winters and me.

Not surprisingly, the conversation turned to design patterns. Clay reminded us of the work he did a few years ago on moderation patterns. Sadly, the original moderation patterns wiki is down. But yay for the waybackmachine, here’s an archived copy.

There’s more than 40 patterns there, dealing with issues of digital identity and managing social dynamics for collaboration / conversation platforms. You would think that at the rate of current technology development, most of these would be obsolete. At the time they where written, nobody had heard of opensocial or OpenId. Yet they are surprisingly relevant. The reason is, that they deal with the social aspects of technology, not with the code. And as fast as technology may change – human nature is reletively stable.

Example? login with email. Have you noticed how more and more sites let you use either a username or login? The rationale for this has nothing to do with technology. Asking us to remember a user name and password for more than seven sites, give or take one, is ignoring the structure of human memory. That may be changed by technology, but marginally.

Social dynamics are much more complex than we tend to realise, which is why most social software is autistic. Its not a fault of the programmers that facebook’s friends featrue looks like this. Anyone (well, any 20 year old male) who would be asked to model the concept of friendship would come up with something similar. What we need is a serious and prolonged attempt at capturing the design patterns for social / participatory media.

But the death of the moderation patterns wiki holds a warning. Sustaining such an effort is not easy. It required institutional, personal and collaborative commitment. That, in turn, relies on the ability to show a constant stream of valuable outputs. I don’t have an answer to that, but its definitely something we’re thinking of as the pattern language network project nears the end of its life.

As for the moderation patterns themeselves, we’re looking into the options for giving them a new home. By the way, my personal favorite is use email.

guest post from Martin Jones: sketches of a workshop

Martin Jones and Maisie Platts joined us at the digital identities workshop last week. Martin and Maisie are illustrators, and they came to help us add a visual dimension to our stories – those we collect, as well as our observations from the workshop process. Martin has sent me some notes, and I’ve asked his permission to publish them here as a guest post:

"Coffee was drunk standing up in groups in the foyer space, and online activities, texting etc took place sitting in the seminar room, where it was darker, and the rows of chairs made for a kind of anonimity"

My first observation, was that participants spontaneously occupied the two spaces available to them differently. Coffee was drunk standing up in groups in the foyer space, and online activities, texting etc took place sitting in the seminar room, where it was darker, and the rows of chairs made for a kind of anonymity. I think this observation was a result of a preconception of mine (screens as walls between real spaces) I didn’t manage to shake this preconception off all day, and it is reflected in a lot of the drawings.

As an artist, having groups of people who are cool with the idea of being drawn while they engage in a group activity was a great privilege. It picked up on a thread of work which I haven’t followed for quite some time – drawing crowds. I really enjoyed the challenge of working fast, and setting new challenges for myself along the way. i.e. sometimes drawing a scene that actually happened, sometimes drawing a scene that was being described, sometimes drawing a cartoon representation of the ideas being discussed.

sketches from the workshop.

The participants were very open to being drawn, and open to the idea that the process might be useful, even though I couldn’t come up with a short rational explanation of why it might be useful.

The fact that I joined in with the ‘draw three versions of yourself’ exercise meant that I thought of myself as part of the group I worked with first, although this was hard to sustain as my attention was divided with the drawing and moving to other groups.

"3 faces game of identity" game

I thought of myself as a ‘provoking’ presence, and also seized upon the work ‘lurker’ when it came up in one of the groups. I also drew Yishay and Steven as lurkers.

I think I came up with the idea of me being a provoking presence because I felt a slight frustration with the group for (as I saw it) resisting the idea of turning their contributions into anything that I would recognise as a story. They seemed much more interested in discussing the issues raised by the contributions in an open ended way. This I interpreted as evading the call to form a story because doing so would exclude all other ‘interesting’ avenues of discussion. I felt the call to form a story was the point of the workshop, not debating solutions. I didn’t express this directly, but attempted to ‘retell’ one of the contributions as a story such as one might see in a movie. This caused a slight pause among the participants, and they then returned to the discursive. No one picked this up by attempting to retell the story from their own imagination and experience, and I didn’t attempt this again (though I harboured the feeling that it would have been useful I had).

you can't be silent, there's no point in being there / why were they following me when I wasn't there? - Digital Identity Panic

I quite quickly started to imagine the workshop as an online community – potentially anyone could have walked in and joined in. People formed and reformed into little discussion groups. Everyone was very open with their opinions. I guess they were professional opinion-formers.

I was very taken with the idea of people only being partially or incompletely represented to each other online (it seemed as if there was a lot of desire to take control of this process, and a feeling of conflict that there was something wrong with the idea of controlling it – ie compromising what was good about the internet).

My drawings started to reflect this. I abandoned the idea that the drawing might represent the whole person, and concentrated only on single gestures, postures and groupings – along with representations of what was being said. I was conscious that sometimes my representations of what was being said was not necessarily true to the spirit of the speaker, but the slant of my listening. This added to my feeling of being a lurker.

The one exception to this was when one of the participants asked me to draw two situations their group had come up with to sum up the dilemma they were discussing (a pub and a sealed room). I felt very grateful to be asked to do something useful and achievable at this time of the day!

Lurking is important when engaging with new social platforms/services, especially when deciding what is a legitimate projection/use of identity. Space For Lurking

Martin Jones 12th Jan 09

Good advice from Balbir Barn

In November Harvey Mellar I had a long chat with Balbir Barn. Balbir has done a lot of work with JISC on process modelling, and is well versed in the design patterns paradigm.

The first thing Balbir noted was that we should be clear about the nature of our patterns: these are pedagogical patterns, and are quite different from what he expected as a software developer. This gave rise to an interesting observation. “Our” patterns are the same creatures as Alexander’s or the gang of four’s. They all –

describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice (Alexander et al, 1977, p.x)

The difference is that Alexander’s environment is the physical space around us, software developers’ environment is the internal workings and interfaces of the systems they build, and our environment is participatory, web-supported learning spaces. Hence the problems we solve are different, and consequently the patterns we identify. Yet they are strongly connected: pedagogical patterns provide invaluable capsules of knowledge for software developers, in that they highlight rich and crisply defined functional requirements. If I tell a software designer that, for a particular learning activity, I need to provide a narrative space with paper2.0 and video clips as objects to talk with, I’ve told her nothing about how to build the software (and indeed, its not my business to do that) but I gave her a pretty good idea of what I want it to do. Bottom line:

Pedagogical patterns serve as rich functional requirements for system design, and lead to a better choice of interface and software design patterns.

Next, we discussed what Balbir called the “meta-level description” of the patterns. This resonated strongly with the insights of Sally Fincher, Helen Sharp and other guests at our October meeting. Such a meta-model needs to provide two facilities:

• Semantic mapping / definition of the key concepts we use.
• Mapping of links and relationships between patterns, and between patterns and concepts.

For example, if we have patterns that refer to grading issued of skill-oriented learning in large classes of blended learning, then all these should be nodes in the map: “grading”, “skills”, “large class”, blended learning”. If the roles in such a context are learner, tutor, course leader, learning technologist, then these too should be defined and linked.

A meta-model / map does not need to take any specific form, but it should allow a representation of nodes of knowledge / concepts and links between them. This could be captured by a concept map, topic map, knowledge map, UML diagram, etc. Mind maps are problematic because they impose a strict hierarchy.

Mapping could be top-own or bottom-up. Working top-down would appear to be a more theoretically solid approach. However, it has two serious shortcomings:

• The sparseness of our content might result in a coverage of the map that is too thin to be meaningful.
• There may be many alternative and equally valid meta-models for describing the same domain. A top-down process will have a hard time differentiating them. A bottom-up process has one advantage – it is guaranteed to cover some significant concerns of some portion of the practitioner community.

To a large extent, this matches the approach we took at the learning patterns project, (see: Winters and Mor, 2008). There, we boot-strapped the pattern language by developing several typologies – structured glossaries of key concepts. These were continuously refined as we developed our cases and patterns. The patterns themselves were arranged in a tree-structure by their function and level of abstraction. Bottom line –

Provide two meta-level descriptions of the language: a semantic glossary of the lexicon and a functional map of the patterns IN THE LANGUAGE

Turning to the structure of the individual pattern, Balbir suggested that we encourege authors to clearly specify role and relationships in the solution descriptions. This should be a soft scaffolding, just like the recomendation to describe the problem as a tension between forces. It is likely to be a useful form for describing the solution, but we should not impose it.

Finally, we discussed the diagrams, or visual models to include in the patterns themselves. We all agreed that this was a fundamental element, yet at the same time we need to take care to avoid over-engineering. The diagrams need to provide enough freedom for the designer to apply her judgement and adapt the pattern to her specific context and specifications. In the case of the formative e-assessment group, Balbir recomended the use of sequence diagrams as a standard.

These recomendations where implemented in the next two workshops, but that’s for another post.

pattern browsers that make you go ahhh

I’ve recently come across these beautiful pattern browsers from Interface Design Team of the University of Applied Sciences Potsdam.

Of course, my immediate reaction was “I want one like this”. Its not surprising that an interface design / information visualisation group can come up with a better interface than our humble table. But there’s more to this than aesthetics. These browsers are functional. They are designed to help you find the pattern you need, when you need it. This makes me think about our quest for organising structures. Our primary criterion for choosing a structure should be functional. After all, isn’t that what pattern are all about? Providing a solution to a problem in context? This suggests that there isn’t a single-size map. Each domain of practice will have its set of contexts and problems, and the organisation of patterns for that domain should be driven by them.
Another question that emerges from these examples is: do we need fixed structures at all? Google made its fortune on the claim that where search is powerful enough, you don’t need structure. These patterns browsers allow you to search by specifying your needs. Although they don’t display any fixed structure, you can find the patterns that fits your problem in 3 clicks.

“language” attribute on patterns?

Our cases have a “group / workshop” attribute. This is because we collect them from various communities, and the participants in these communities want to quickly find their peer’s contributions. We didn’t have a similar attribute for patterns, thinking that the whole point of patterns is to promote generality and knowledge transfer. Now, that is still true, yet on the other hand we can see several distinguishable (if not distinct) languages emerging. Patterns for e-Assessment are a cluster apart from HCI patterns etc. After all, this is the pattern language network.
So, should we add a “language” attribute to patterns? Should it be single or multiple choice?

Studies or stories?

One of the issues that came up at the recent formative e-assessment workshops was the disparate interpretations of Case Study. This led to the production of our tutorial. But it also got me thinking, maybe we can do better by a change of name. If we talk of “case stories” or “case narratives”, would that clarify what we’re looking for?

An inconvenient thesis?

Christine Elizabeth Wania’s phd thesis questions the empirical evidence for the benefits of pattern languages in HCI:

For more than two decades much of the pattern language literature, within the field of Human Computer Interaction (HCI), has focused on the possible benefits pattern languages may provide, but there has been very little empirical work to support these claims. It has been suggested that interaction patterns or pattern languages in HCI may address some of the problems inherent in designing interactive systems by supporting reuse, capturing design knowledge, enabling the sharing of design knowledge, and facilitating communication among designers and users. This study examined the impact of a pattern language on the design of information retrieval interfaces, in terms of the quality of the interfaces and the time to design the interfaces. Participants created paper and pencil interfaces based on the given design task. Participants were exposed to either a pattern language, guidelines, or no structuring technique. There were no statistically significant differences between the three groups in terms of the quality of the interfaces and time to design the interfaces. The results of this study suggest that the value of pattern languages in HCI may not be in reuse, at the early stages of design, or in terms of the quality of the resulting designs, in domains familiar to designers. Although there was no apparent impact of the pattern language on the early stage designs, the results of a follow-up study suggest there is a significant correlation between the existence of patterns in commercial systems and the overall usability of those systems. Therefore, we suggest that we, as a community, very closely examine the current state of pattern languages in HCI before continuing to move forward. As a community, we need to shift our focus away from discussing the possible benefits of pattern languages and trying to build pattern collections. And instead, focus on trying to fully understand the value of pattern languages in HCI. In doing so, the HCI community, will then begin to see the benefits from all the great efforts in this area.

About time someone asked this question. I mean, I’ll swear by my favourite patterns and pattern languages, defend them as if they where my children flesh and blood, but do we have any evidence, in the scientific sense? In a way, this brings back the discussion on validity, resonance and aggregation. Yes, patterns work great for those who believe in them. But shouldn’t we aim higher?

Pattern Formats and Structures

I want to try to summarise some of the discussion that we have had about pattern formats and structures, so that we can make the necessary decisions to take us forward.

1. There is agreement that “Illustration” should be added as a standard field and that we should encourage use of visual representations, such as diagrams, more generally.
2. There seems to be a consensus that “Aim” should be changed to “Problem”. Because of some restrictive connotations of using this term which have been mentioned, we should provide supporting text and examples to indicate that this is meant in the sense of what issue the pattern resolves.
3. The question of the confidence rating for patterns has been raised. The view that this should reflect the level of confidence in the pattern as a pattern, and not just its level of development, seems to be generally agreed. Some further discussion is required to determine how this could be reflected in the form of usable guidelines.
4. There has been discussion about a range of detailed additional information in different categories which relate to the main parts of the pattern (Problem, Solution, Context), or to the pattern as a whole. Suggestions include subsections for rationale and evidence. The experience of the formats used by other pattern repositories will be useful to us, to help decide on a compromise between the requirements of precision and standardisation to aid pattern interchange, and flexibility and simplicity for users of the pattern network. A draft structure is available on the Planet Wiki, and can be the basis of further discussion. My general preference is for fairly broad categories, with a number of more detailed optional subcategories prompted by a set of guidelines and suggested questions, with examples to indicate how these can be applied.
5. How we deal with the formative stages of a pattern has been discussed. This is a pressing issue as it affects how people use the Planet platform, and any changes agreed need to be implemented soon as it would be difficult to change things retrospectively. There appears to be a consensus that the seed/proto patterns are not patterns, and thus must be distinguished from patterns – even ones categorised as having a low level of confidence attached to them – in some way. How this is then reflected in the pattern and platform structure still needs to be resolved. These are some of my thoughts on this. I will use the word “proto-pattern” for convenience, but what term we actually use needs to be agreed on.

The processes associated with creating a pattern, as against refining and seeking to increase the level of confidence in it, are obviously linked. However, especially when considering the initial stages of pattern creation, there are also significant differences. A simple way of looking at this question is to consider the components that make up a pattern, which we are currently discussing with regard to specifying the pattern format. In defining the problem, we need to understand what the forces are that need to be resolved. The solution both needs sufficient evidence from actual cases (a minimum of 3 according to the rule of thumb we have agreed on), as well as an understanding of what other patterns would be needed to provide a complete solution. The context specifies the conditions under which the pattern applies, but also connects it to other patterns at its own and higher levels. Therefore, even before we can even consider something to be a pattern, we have to look for other relevant cases and practice, look at the practice and theory of associated problem areas, and relate the prospective pattern to a wider conceptual framework. The questions raised and activities required at this stage thus will centre on resolving these issues. Of course these processes are also relevant when we reach the pattern stage, but while the processes associated with a pattern are primarily focused on its use to solve a particular problem, for a proto-pattern it is primarily focused on the formulation and development of the pattern and pattern language.

The distinction between proto-patterns and patterns should not be seen as a formal or linguistic one. Rather it reflects their different roles. Indeed, for a considerable part of the period of development of a proto-pattern, it may be uncertain whether it will progress to pattern status or not. It is potentially confusing to people using the Planet site, who may expect more from what are labelled as patterns, unless this distinction is made clear. At the same time, having a means of representing and developing even very rudimentary proto-pattern ideas is vital. Clarifying how we do this will be particularly important at the current juncture, where we are beginning to discuss with others how we interface with systems that may be the source of such ideas.

How would this affect our current framework? Obviously we should have some guidelines that explain the distinctions, but reflecting this in our systems and pattern formats requires careful thought. In practice, although we need to draw the distinction between proto-patterns and patterns, we also want to create a smooth transition between the two. If feasible, I would prefer a common format, with an interface that was effectively context sensitive, and presented different options and questions depending on the proto-pattern/pattern status indication. As an example, for a particular part of a proto-pattern, questions may prompt the user to look for examples where a proposed solution does not apply, to help establish the boundaries of context for the pattern. In the case of the pattern itself, this part would state what these boundaries were, and indicate relevant related patterns. There would need to be a process, perhaps using a simple checklist, that facilitated the transition from proto-pattern to pattern. Underlying this would be the simple criterion for deciding whether something should be given pattern status – namely: “Can it be used as a pattern?” Opinions on this issue would be particularly valuable, as we need to move to a decision very soon.

yongfook made me friendfeed

Here’s what I learnt from this presentation:

• Blogs are not what they used to be (ok, I knew that, but he has nice graphs).
• Lifestreams are the new blogs (ok, I knew that too, but he has some nice links and examples).
• When you post on slideshare, have a good joke on slide 1.

“Eureka!” Sketching exercise

One of the nice things that happened at the Singapore workshop was the introduction game we played.

Every one of us has these Eureka! moments; personal experiences were we learned something in a way that was etched into our memory. Positive, formative events of learning, the kind we wish to engender in the environments and activities we design.

To get people in the right mindset for the workshop we asked everyone to draw (scribble, sketch) one such moment. We distributed paper and markers, and instructed participants to tell the story of their Eureka! moment in images. They could use words as part of the drawing – in speech bubbles etc. – but not as a way of telling the story.

People stood up, showing their drawing, and we used that as a started for a discussion on design principles. We then hung the pictures on the walls, and handed out post-its for people to “tag” them with comments.

In fact, it was such a nice game, we thought maybe you’d want to play it too:

http://www.flickr.com/groups/eurekagame/