So is it as if it had never been?  I there anything left behind?  There are a few sheets of Magic Whiteboard on the walls, that I left so that those visiting the Rural Centre in the coming weeks can see something of what we were doing, and there are used teabags and fish-and-chip boxes in the bin, but few traces.

We trod lightly, like the agriculture of the island, where Corncrake and orchid live alongside sheep and cattle.

Some may have heard me talk about the way design is like a Spaghetti Western. In the beginning of the film Clint Eastwood walks into the town, and at the end walks away.  He does not stay, happily ever after, with a girl on his arm, but leaves almost as if nothing had ever happened.

But while he, like the designer, ultimately leaves, things are not the same.  The Carson brothers who had the town in fear for years lie dead in their ranch at the edge of town, the sharp tang of gunfire still in the air and the buzz of flies slowly growing over the elsewise silent bodies.  The crooked major, who had been in the pocket of the Carson brothers, is strapped over a mule heading across the desert towards Mexico, and not a few wooden rails and water buts need to be repaired.  The job of the designer is not to stay, but to leave, but leave change: intervention more than invention.

But the deepest changes are not those visible in the bullet-pocked saloon door, but in the people.  The drunk who used to sit all day at the bar, has discovered that he is not just a drunk, but he is a man, and the barmaid, who used to stand behind the bar has discovered that she is not just a barmaid, but she is a woman.

This is true of the artefacts we create and leave behind as designers, but much more so of the events, which come and go through our lives.  It is not so much the material traces they leave in the environment, but the changes in ourselves.

I know that, as the plane and ferry left with those last participants, a little of myself left with them, and I know many, probably all, felt a little of themselves left behind on Tiree.  This is partly abut the island itself; indeed I know one participant was already planning a family holiday here and another was looking at Tiree houses for sale on RightMove!  But it was also the intensity of five, sometimes relaxed, sometimes frenetic, days together.

So what did we do?

There was no programme of twenty minute talks, no keynotes or demo, indeed no plan nor schedule at all, unusual in our diary-obsessed, deadline-driven world.

Well, we talked.  Not at a podium with microphone and Powerpoint slides, but while sitting around tables, while walking on the beach, and while standing looking up at Tilly, the community wind turbine, the deep sound of her swinging blades resonating in our bones.  And we continued to talk as the sun fell and the overwhelmingly many stars came out , we talked while eating, while drinking and while playing (not so expertly) darts.

We met people from the island those who came to the open evening on Saturday, or popped in during the days, and some at the Harvest Service on Sunday.  We met Mark who told us about the future plans for Tiree Broadband, Jane at PaperWorks who made everything happen, Fiona and others at the Lodge who provided our meals, and many more. Indeed, many thanks to all those on the island who in various ways helped or made those at TTW feel welcome.

We also wrote.  We wrote on sheets of paper, notes and diagrams, and filled in TAPT forms for Clare who was attempting unpack our experiences of peace and calmness in the hope of designing computer systems that aid rather than assault our solitude.  Three large Magic Whiteboard sheets were entitled “I make because …”, “I make with …”, “I make …” and were filled with comments.  And, in these days of measurable objectives, I know that at least a grant proposal, book chapter and paper were written during the long weekend; and the comments on the whiteboards and experiences of the event will be used to create a methodological reflection of the role of making in research which we’ll put into Interfaces and the TTW web site.

We moved.  Walking, throwing darts, washing dishes, and I think all heavily gesturing with our hands while taking.  And became more aware of those movements during Layda’s warm-up improvisation exercises when we mirrored one another’s movements, before using our bodies in RePlay to investigate issues of creativity and act out the internal architecture of Magnus’ planned digital literature system.

We directly encountered the chill of wind and warmth of sunshine, the cattle and sheep, often on the roads as well as in the fields.  We saw on maps the pattern of settlement on the island and on display boards the wools from different breeds on the island. Some of us went to the local historical centre, An Iodhlann [[ http://www.aniodhlann.org.uk/ ]], to see artefacts, documents and displays of the island in times past, from breadbasket of the west of Scotland to wartime airbase.

We slept.  I in my own bed, some in the Lodge, some in the B&B round the corner, Matjaz and Klem in a camper van and Magnus – brave heart – in a tent amongst the sand dunes.  Occasionally some took a break and dozed in the chairs at the Rural Centre or even nodded off over a good dinner (was that me?).

We showed things we had brought with us, including Magnus’ tangle of wires and circuit boards that almost worked, myself a small pack of FireFly units (enough to play with I hope in a future Tech Wave), Layda’s various pieces she had made in previous tech-arts workshops, Steve’s musical instrument combining Android phone and cardboard foil tube, and Alessio’s impressively modified table lamp.

And we made.  We do after all describe this as a making event!  Helen and Claire explored the limits of ZigBee wireless signals.  Several people contributed to an audio experience using proximity sensors and Arduino boards, and Steve’s CogWork Chip: Lego and electronics, maybe the world’s first mechanical random-signal generator.  Descriptions of many of these and other aspects of the event will appear in due course on the TTW site and participants’ blogs.

But it was a remark that Graham made as he was waiting in the ferry queue that is most telling.  It was not the doing that was central, the making, even the talking, but the fact that he didn’t have to do anything at all.  It was the lack of a plan that made space to fill with doing, or not to do so.

Is that the heart?  We need time and space for non-doing, or maybe even un-doing, unwinding tangles of self as well as wire.

There will be another Tiree Tech Wave in March/April, do come to share in some more not doing then.

Who was there:

• Alessio Malizia – across the seas from Madrid, blurring the boundaries between information, light and space
• Helen  Pritchard – artist, student of innovation and interested in cows
• Claire  Andrews – roller girl and researching the design of assistive products
• Clare  Hooper – investigating creativity, innovation and a sprinkling of SemWeb
• Magnus  Lawrie – artist, tent-dweller and researcher of digital humanities
• Steve Gill – designer, daredevil and (when he can get me to make time) co-authoring book on physicality TouchIT
• Graham Dean – ex-computer science lecturer, ex-businessman, and current student and auto-ethnographer of maker-culture
• Steve Foreshaw - builder, artist, magician and explorer of alien artefacts
• Matjaz Kljun – researcher of personal information and olive oil maker
• Layda Gongora – artist, curator, studying improvisation, meditation and wild hair
• Alan Dix – me

The shortness is a boon that I wish many writers would follow (including me). As with so many single issue books (e.g. Blink), there is s slight tendency to over-sell the main argument, but this is forgiveable in a short delightful book, in a way that it isn’t in 350 pages of less graceful prose.

I know I have a tendency, which can be confusing or annoying, to give, paradoxically for fear of misunderstanding, the caveat before the main point. Still, despite knowing this, in the early chapters I did find myself occasionally bristling at Maeda’s occasional overstatement (although in accordance with simplicity, never hyperbole).

One that particularly caught my eye was Maeda’s contrast of the MIT engineer’s RFTM (Read The F*cking Manual) with the “designer’s approach” to:

marry function with form to create intuitive experiences that we understand immediately.

Although in principle I agree with the overall spirit, and am constantly chided by Fiona for not reading instructions³, the misguided idea that everything ought to ‘pick up and use’ has bedeviled HCI and user interface design for at least the past 20 years. Indeed this is the core misconception about Heidegger’s hammer example that I argued against in a previous post “Struggling with Heidegger“. In my own reading notes, my comment is “simple or simplistic!” … and I meant here the statement not the resulting interfaces, although it could apply to both.

It has always been hard to get well written documentation, and the combination of single page ‘getting started’ guides with web-based help, which often disappears when the web site organisation changes, is an abrogation of responsibility by many designers. Not that I am good at this myself. Good documentation is hard work. It used to be the coders who failed to produce documentation, but now the designers also fall into this trap of laziness, which might be euphemistically labelled ‘simplicity’⁴.

Personally, I have found that the discipline of documenting (in the few times I have observed it!) is in fact a great driver of simple design. Indeed I recall a colleague, maybe Harold Thimbleby⁵, once suggested that documentation ought to be written before any code is written, precisely to ensure simple use.

Some years ago I was reading a manual (for a Unix workstation, so quite a few years ago!) that described a potentially disastrous shortcoming of a the disk sync command (which could have corrupted the disk). Helpfully the manual page included a suggestion of how to wrap sync in scripts that prevented the problem. This seemed to add insult to injury; they knew there was a serious problem, they knew how to fix it … and they didn’t do it. Of course, the reason is that manuals are written by technical writers after the code is frozen.

In contrast, I was recently documenting an experimental API⁶ so that a colleague could use it. As I wrote the documentation I found parts hard to explain. “It would be easier to change the code”, I thought, so I did so. The API, whilst still experimental, is now a lot cleaner and simpler.

Coming back to Maena after a somewhat long digression (what was that about simplicity and brevity?). While I prickled slightly at a few statements, in fact he very clearly says that the first few concrete ‘laws’ are the simpler (and if taken in their own simplistic), the later laws are far more nuanced and suggest deeper principles. This includes law 5 “differences: simplicity and complexity need each other”, which suggest that one should strive for a dynamic between simplicity and complexity. This echoes the emphasis on texture I often advocate when talking with students; whether in writing, presenting or in experience design it is often the changes in voice, visual appearance, or style which give life.

the simplest interface?

I wasn’t convinced by Maeda’s early claim that simple designs were simpler and cheaper to construct.  Possibly true for physical prodcuts, but rarely so for digital interfaces, where more effort is typically needed in code to create simpler user interfaces.  However, again this was something that was revisited later, especially in the context of more computationally active systems (“law 8, in simplicity we trust”), where he contrasts “how much do you need to know about a system?” with “how much does the system know about you?”.  The former is the case of more traditional passive systems, whereas more ‘intelligent’ systems such as Amazon recommendations (or even Facebook news feed) favour the latter.  This is very similar to the principles for incidental and low-intention interaction that I have discussed in the past⁷.

Finally “The Laws of Simplicity” is beautifully designed in itself.  It includes  many gems not least those arising from Maeda’s roots in Japanese design culture, including aichaku, the “sense of attachment one can feel for an artefact” (p.69) and omakase meaning “I leave it to you”, which asks the sushi chef to create a meal especially for you (p.76).  I am perhaps too much of a controller to feel totally comfortable with the latter, but Maeda’s book certainly inspires the former.

1. In fact there are 108 pages in the main text, but 9 of these are full page ‘law/chapter’ frontispieces, so 99 real pages.  However, if you include the 8 page introduction that gives 107 … so even the 100 page cap is perhaps a more subtle concept than a strict count. [back]
2. See his full 10 laws of simplicity at lawsofsimplicity.com [back]
3. My guess is that the MIT engineers didn’t read the manuals either. [back]
4. Apple is a great — read poor — example here as it relies on keen technofreaks to tell others about the various hidden ways to do things — I guess creating a Gnostic air to the devices. [back]
5. Certainly Harold was a great proponent of ‘live’ documentation, both Knuth’s literate programming and also documentation that incorporated calculated input and output, rather like dexy, which I reported after last autumn’s Web Art/Science camp. [back]
6. In fairness, the API had been thrown together in haste for my own use. [back]
7. See ‘incidental interaction” and HCI book chapter 18. [back]

Dhaval’s thesis “Designing for Awareness: An Experience-focused HCI Perspective”¹ is well worth a read with ethnographic studies of academics (!) and designers at work; and also technical interventions in both situations: Panorama a public screen photo-montage-style display and CAM a way to tag and discuss physical objects.

While reading the thesis I also realised that ‘awareness’  is one of those slippery words, that has a slightly technical meaning in CSCW, and one you sort of understand by example and diffusion, but is surprisingly hard to pin down. Dhaval does not have a precise definition and neither do I: the HCI textbook says “generally having some feeling for what other people are doing or have been doing” – hardly precise!  I have some half-formed thoughts on this, but will leave them for another post.

I first knew Dhaval when he was doing his MSc at Lancaster in 2001/2002.  He has always been dedicated to pursuing an academic career and it is wonderful 10 years on to see this come to fruition.  There have been a lot of barriers on the way and so this is a testament to Dhaval’s strength of character as well as intellectual attainment.

1. Dhaval Vyas (2011). Designing for Awareness: An Experience-focused HCI Perspective. University of Twente. download thesis (PDF 4.9Mb). DOI: 10.3990/1.9789036531351 (not yet resolving). [back]

Well now is your chance …

Come to Tiree Tech Wave in March to make, talk and play at the wind-ripping edge of digital technology.

Every year Tiree hosts the Wave Classic, a key international wind surfing event.  Those of us at the edge of the digital wave do not risk cold seas and bodily injury, but there is something of the same thrill as we explore the limits of code, circuit boards and social computation.

The cutting edge of wind-surfing boards is now high technology, but typically made by artisan craftsfolk, themselves often surfers.  Similarly hardware platforms such as Arduino, mobile apps for iPhone and Android, and web mashups enabled by public APIs and linked data are all enabling a new maker culture, challenging the hegemony of global corporations.

The Western Celtic fringes were one of the oases of knowledge and learning during the ‘dark ages’.  There is something about the empty horizon that helped the hermit to focus on God and inspired a flowering of decorative book-making, even in the face of battering storms of winter and Viking attacks of summer; a starkness that gave scholars time to think in peace between danger-fraught travel to other centres of learning across Europe.

Nowadays regular Flybe flights and Calmac ferries reduce the risk of Viking attacks whilst travelling to the isles, broadband Internet and satellite TV invade the hermit cell, and double glazing and central heating mollify the elements.  Yet there is still a rawness that helps focus the mind, a slightly more tenuous connection to the global infrastructure that fosters a spirit of self-reliance and independence.

Over a long weekend 17 – 21 March (TBC), we plan what I hope will be a semi-regular event.  A time to step out, albeit momentarily, from a target-driven world, to experiment and play with hardware and software, to discuss the issues of our new digital maker culture, what we know and what we seek to understand, and above all to make things together.

This is all about technology and people: the physical device that sits in our hands, the data.gov.uk mashup that tells us about local crime, the new challenges to personal privacy and society and the nation state.

Bring your soldering iron, and Arduino boards, your laptop and API specs, your half-written theses and semi-formed ideas, your favourite book or even well-loved eReader (!).  The format will be informal, with lots of time to work hands-on together; however, there will be the opportunity for short talks/demos/how-to-do-it sessions.  Also, if there is demand, I’d  be happy to do some more semi-formal tutorial sessions and maybe others would too (Arduino making, linked data).

Currently we have no idea whether there will be three or three hundred people interested, but aiming for something like 15 – 30 participants.  We’ll keep costs down, probably around £70 for meeting rooms, lunches, etc. over the five days, but will confirm that and more details shortly.

Follow on Twitter at @tireetechwave and the website will be at tireetechwave.com. However, it is still ‘under development’, so don’t be surprised at the odd glich over the next couple of weeks as we sort out details.

If you are interested in coming or want to know more mail me or Graham Dean

hammers

I should explain that problems with the hammer example are not my current struggles with Heidegger!  For the hammer it is just that Heidegger’s ‘ready at hand’ is often confused with ‘walk up and use’.  In  Heidegger ready-at-hand refers to the way one is focused on the nail, or wood to be joined, not the hammer itself:

“The work to be produced is the “towards which” of such things as the hammer, the plane, and the needle” (Being and Time¹, p.70/99)

To be ‘ready to hand’ like this typically requires familiarity with the equipment (another big Heidegger word!), and is very different from the way a cash machine or tourist information systems should be in some ways accessible independent of prior knowledge (or at least only generic knowledge and skills).

My especial annoyance with the hammer example stems from the fact that my father was a carpenter and I reckon it took me around 10 years to learn how to use a hammer properly²!  Even holding it properly is not obvious, look at the picture.

There is a hand sized depression in the middle.  If you have read Norman’s POET you will think, “ah yes perceptual affordance’, and grasp it like this:

But no that is not the way to hold it!  If try to use it like this you end up using the strength of your arm to knock in the nail and not the weight of the hammer.

Give it to a child, surely the ultimate test of ‘walk up and use’, and they often grasp the head like this.

In fact this is quite sensible for a child as a ‘proper’ grip would put too much strain on their wrist.  Recall  Gibson’s definition of affordance was relational³, about the ecological fit between the object and the potential actions, and the actions depends on who is doing the acting.  For a small child with weaker arms the hammer probably only affords use at all with this grip.

In fact the ‘proper’ grip is to hold it quite near the end where you can use the maximum swing of the hammer to make most use of the weight of the hammer and its angular momentum:

Anyway, I think maybe Heidegger knew this even if many who quote him don’t!

Heidegger

OK, so its alright me complaining about other people mis-using Heidegger, but I am in the middle of writing one of the chapters for TouchIT and so need to make sure I don’t get it wrong myself … and there my struggles begin.  I need to write about ready-to-hand and present-to-hand.   I thought I understood them, but always it has been from secondary sources and as I sat with Being and Time in one hand, my Oxford Companion to Philosophy in another and various other books in my teeth … I began to doubt.

First of all what I thought the distinction was:

• ready at hand — when you are using the tool and it is invisible to you, you just focus on the work to be done with it
• present at hand — when there is some sort of breakdown, the hammer head is loose or you don’t have the right tool to hand and so start to focus on the tools themsleves rather than on the job at hand

Scanning the internet this is certainly what others think, for example blog posts at 251 philosophy and Matt Webb at Berg⁴.  Koschmann, Kuutti and Hickman produced an excellent comparison of breakdown in Heidegger, Leont’ev and Dewey⁵, and from this it looks as though the above distinction maybe comes Dreyfus summary of Heidegger — but again I don’t have a copy of Dreyfus’ “Being-in-the-World“, so not certain.

Now this is an important distinction, and one that Heidegger certainly makes.  The first part is very clearly what Heidegger means by ready-to-hand:

“The peculiarity of what is proximally to hand is that, in its readiness-to-hand, it must, as it were, withdraw … that with which we concern ourselves primarily is the work …” (B&T, p.69/99)

The second point Heidegger also makes at length distinguishing at least three kinds of breakdown situation.  It just seems a lot less clear whether ‘present-at-hand’ is really the right term for it.  Certainly the ‘present-at-hand’ quality of an artefact becomes foregrounded during breakdown:

“Pure presence at hand announces itself in such equipment, but only to withdraw to the readiness-in-hand with which one concerns oneself — that is to say, of the sort of thing we find when we put it back into repair.” (B&T, p.73/103)

But the preceeding sentance says

“it shows itself as an equipmental Thing which looks so and so, and which, in its readiness-to-hand as looking that way, has constantly been present-at-hand too.” (B&T, p.73/103)

That is present-at-hand is not so much in contrast to ready-at-hand, but in a sense ‘there all along’; the difference is that during breakdown the presence-at-hand becomes foregrounded. Indeed when ‘present-at-hand’ is first introduced Heidegger appears to be using it as a binary distinction between Dasein, (human) entities that exist and ponder their existence, and other entities such as a table, rock or tree (p. 42/67).  The contrast is not so much between ready-to-hand and present-to-hand, but between ready-to-hand and ‘just present-at-hand’ (p.71/101) or ‘Being-just-present-at-hand-and-no-more’ (p.73/103). For Heidegger to seems not so much that ‘ready-to-hand’ stands in in opposition to ‘present-to-hand’; it is just more significant.

To put this in context, traditional philosophy had focused exclusively on the more categorically defined aspects of things as they are in the world (‘existentia’/present-at-hand), whilst ignoring the primary way they are encountered by us (Dasein, real knowing existence) as ready-to-hand, invisible in their purposefulness.  Heidegger seeks to redress this.

“If we look at Things just ‘theoretically’, we can get along without understanding readiness-to-hand.” (B&T p.69/98)

Heidegger wants to avoid the speculation of previous science and philosophy. Although it is not a Heidegger word, I use ‘speculation’ here with all of its connotations, pondering at a distance, but without commitment, or like spectators at a sports stadium looking in at something distant and other.  In contrast, ready-to-hand suggests commitment, being actively ‘in the world’ and even when Heidegger talks about those moments when an entity ceases to be ready-to-hand and is seen as present-to-hand, he uses the term circumspection — a casting of the eye around, so that the Dasein, the person, is in the centre.

So present-at-hand is simply the mode of being of the entities that are not Dasein (aware of their own existence), but our primary mode of experience of them and thus in a sense the essence of their real existence is when they are ready-to-hand.  I note Roderick Munday’s useful “Glossary of Terms in Being and Time” highlights just this broader sense of present-at-hand.

Maybe the confusion arises because Heidegger’s concern is phenomenological and so when an artefact is ready-to-hand and its presence-to-hand ‘withdraws’, in a sense it is no longer present-to-hand as this is no longer a phenomenon; and yet he also seems to hold a foot in realism and so in another sense it is still present-to-hand.  In discussing this tension between realism and idealism in Heidegger, Stepanich⁶ distinguishes present-at-hand and ready-to-hand, from presence-to-hand and readiness-to-hand — however no-one else does this so maybe that is a little too subtle!

To end this section (almost) with Heidegger’s words, a key statement, often quoted, seems to say precisely what I have argued above, or maybe precisely the opposite:

“Yet only by reason of something present-at-hand ‘is there’ anything ready-to-hand.  Does it follow, however, granting this thesis for the nonce, that readiness-to-hand is ontologically founded upon presence-at-hand?” (B&T, p.71/101)

What sort of philosopher makes a key point through a rhetorical question?

So, for TouchIT, maybe my safest course is to follow the example of the Oxford Companion to Philosophy, which describes ready-to-hand, but circumspectly never mentions present-to-hand at all?

and anyway what’s wrong with …

On a last note there is another confusion, or maybe mistaken attitude, that seems to be common when referring to ready-to-hand.  Heidegger’s concern was in ontology, understanding the nature of being, and so he asserted the ontological primacy of the ready-to-hand, especially in light of the previous dominant concerns of philosophy.  However, in HCI, where we are interested not in the philosophical question, but the pragmatic one of utility, usability, and experience, Heidegger is often misapplied as a kind of fetishism of engagement, as if everything should be ready-to-hand all the time.

Of course for many purposes this is correct, as I type I do not want to be aware of the keys I press, not even of the pages of the book that I turn.

Yet there is also a merit in breaking this engagement, to encourage reflection and indeed the circumspection that Heidegger discusses.  Indeed Gaver et al.’s focus on ambiguity in design⁷ is often just to encourage that reflection and questioning, bringing things to the foreground that were once background.

Furthermore as HCI practitioners and academics we need to both take seriously the ready-to-hand-ness of effective design, but also (just as Heidegger is doing) actually look at the ready-to-hand-ness of things seeing them and their use not taking them for granted.  I constantly strive to find ways to become aware of the mundane, and offer students tools for estrangement to look at the world askance⁸.

“To lay bare what is  just present-at-hand and no more, cognition must first penetrate beyond what is ready-to-hand in our concern.” (B&T, p.71/101)

This ability to step out and be aware of what we are doing is precisely the quality that Schon recognises as being critical for the ‘Reflective Practioner‘.  Indeed, my practical advice on using the hammer in the footnotes below comes precisely through reflection on hammering, and breakdowns in hammering, not through the times when the hammer was ready-to-hand..

Heidegger is indeed right that our primary existence is being in the world, not abstractly viewing it from afar.  And yet, sometimes also, just as Heidegger himself did as he pondered and wrote about these issues, one of our crowning glories as human beings is precisely that we are able also in a sense to step outside ourselves and look in wonder.

1. In common with much of the literature the page references to Being and Time are all of the form p.70/99 where the first number refers to the page numbers in the original German (which I have not read!) and the second number to the page in Macquarrie and Robinson’s translation of Being and Time published by Blackwell. [back]
2. Practical hammering – a few tips: The key thing is to focus on making sure the face of the hammer is perpendicular to the nail, if there is a slight angle the nail will bend.  For thin oval wire nails, if one does bend do not knock the nail back upright, most likely it will simply bend again and just snap.  Instead, simply hit the head of the nail while still bent, but keeping the hammer face perpendicular to the nail not the hole.  So long as the nail has cut any depth of hole it will simply follow its own path and straighten of its own accord. [back]
3. James Gibson. The Ecological Approach to Visual Perception [back]
4. Matt Webb’s post appears to be quoting Paul Dourish’ “Where the Action Is”, but I must have lent my copy to someone, so not sure of this is really what Paul thinks. [back]
5. Koschmann, T., Kuutti, K. & Hickman, L. (1998). The Concept of Breakdown in Heidegger, Leont’ev, and Dewey and Its Implications for Education. Mind, Culture, and Activity, 5(1), 25-41. doi:10.1207/s15327884mca0501_3 [back]
6. Lambert Stepanich. “Heidegger: Between Idealism and Realism“, The Harvard Review of Philosophy, Vol 1. Spring 1991. [back]
7. Bill Gaver, Jacob Beaver, and Steve Benford, 2003. Ambiguity as a resource for design. CHI ’03. [back]
8. see previous posts on “mirrors and estrangement” and “the ordinary and the normal“ [back]

I mentioned ‘Project Phoenix’ in my last previous post, and this was it – getting vfridge up and running again.

Ten years ago I was part of a dot.com company aQtive¹ with Russell Beale, Andy Wood and others.  Just before it folded in the aftermath of the dot.com crash, aQtive spawned a small spin-off vfridge.com.  The virtual fridge was a social networking web site before the term existed, and while vfridge the company went the way of most dot.coms, for some time after I kept the vfridge web site running on Fiona’s servers until it gradually ‘decayed’ partly due to Javascript/DOM changes and partly due to Java’s interactions with mysql becoming unstable (note very, very old Java code!).  But it is now back online

The core idea of vfridge is placing small notes, photos and ‘magnets’ in a shareable web area that can be moved around and arranged like you might with notes held by magnets to a fridge door.

Underlying vfridge was what we called the websharer vision, which looked towards a web of user-generated content.  Now this is passé, but at the time  was directly counter to accepted wisdom and looking back seem prescient – remember this was written in 1999:

Although everyone isn’t a web developer, it is likely that soon everyone will become an Internet communicator — email, PC-voice-comms, bulletin boards, etc. For some this will be via a PC, for others using a web-phone, set-top box or Internet-enabled games console.
…

The web/Internet is not just a medium for publishing, but a potential shared place.

Everyone may be a web sharer — not a publisher of formal public ‘content’, but personal or semi-private sharing of informal ‘bits and pieces’ with family, friends, local community and virtual communities such as fan clubs.

This is not just a future for the cognoscenti, but for anyone who chats in the pub or wants to show granny in Scunthorpe the baby’s first photos.

Just over a year ago I thought it would be good to write a retrospective about vfridge in the light of the social networking revolution.  We did a poster “Designing a virtual fridge” about vfridge years ago at a Computers and Fun workshop, but have never written at length abut its design and development.  In particular it would be good to analyse the reasons, technical, social and commercial, why it did not ‘take off’ the time.  However, it is hard to do write about it without good screen shots, and could I find any? (Although now I have)  So I thought it would be good to revive it and now you can try it out again. I started with a few days effort last year at Christmas and Easter time (leisure activity), but now over the last week have at last used the fact that I have half my time unpaid and so free for my own activities … and it is done

The original vfridge was implemented using Java Servlets, but I have rebuilt it in PHP.  While the original development took over a year (starting down in Coornwall while on holiday watching the solar eclipse), this re-build took about 10 days effort, although of course with no design decisions needed.  The reason it took so much development back then is one of the things I want to consider when I write the retrospective.

As far as possible the actual behaviour and design is exactly as it was back in 2000 … and yes it does feel clunky, with lots of refreshing (remember no AJAX or web2.0 in those days) and of course loads of frames!  In fact there is a little cleverness that allowed some client-end processing pre-AJAX².    Also the new implementation uses the same templates as the original one, although the expansion engine had to be rewritten in PHP.  In fact this template engine was one of our most re-used bits of Java code, although now of course many alternatives.  Maybe I will return to a discussion of that in another post.

I have even resurrected the old mobile interface.  Yes there were WAP phones even in 2000, albeit with tiny green and black screens.  I still recall the excitement I felt the first time I entered a note on the phone and saw it appear on a web page   However, this was one place I had to extensively edit the page templates as nothing seems to process WML anymore, so the WML had to be converted to plain-text-ish HTML, as close as possible to those old phones!  Looks rather odd on the iPhone :-/

So, if you were one of those who had an account back in 2000 (Panos Markopoulos used it to share his baby photos ), then everything is still there just as you left it!

If not, then you can register now and play.

1. The old aQtive website is still viewable at aqtive.org, but don’t try to install onCue, it was developed in the days of Windows NT. [back]
2. One trick used the fact that you can get Javascript to pre-load images.  When the front-end Javascript code wanted to send information back to the server it preloaded an image URL that was really just to activate a back-end script.  The frames  used a change-propagation system, so that only those frames that were dependent on particular user actions were refreshed.  All of this is preserved in the current system, peek at the Javascript on the pages.    Maybe I’ll write about the details of these another time. [back]

ways of knowing

The central message is about the value of reflection in professional action (as the name would suggest), but throughout Schön also emphasises the incredible artistry of professional practice, mirroring similar comments about craftsmanship in Sennett’s “The Craftsman” (see post “Total Quality, Total Reward and Total Commitment“). Schön describes three main levels of professional knowing:

• knowing in action — The day to day artistry exhibited in the performance of professional activity, not necessarily captured in rules, formulae or explicit knowledge, but constantly worked out in action and often drawing on rich background of past experiences.
• reflection in action — The examination, analysis and experimentation needed during the process addressing singular situations; often making the criteria and knowledge of action explicit and moreover often shifting from problem solution to problem formulation. This is revealed especially in the expert-novice situations that Schön uses to illustrate the book.
• reflection on action — The far rarer, and hence less well exemplified and discussed, post-hoc examination of the professional activity and process, allowing one to question and refine one’s means for bearing experience and knowledge to bear during action.

However, Schön is himself engaged in a higher level of reflection, examining the nature of reflection itself. Indeed late in the books, he discusses the potential for an “action science” alongside rich examinations of vignettes of professional activity.

Personally, this takes me back to the time in 1995 when I needed to give a lecture on “research methods” in a computer science setting and so first found myself having to reflect on my own methods and effectively becoming a researcher about research.

teaching the ineffable — ideals and reality

Artistry can be seen as mysterious and ineffable. In my own work, I have found myself addressing a variety of areas, including creativity, writing, debugging and reflection itself, that are often regarded as unlearnable or at least unteachable, only attainable through innate gift or apprenticeship. In each, I have sought to use a combination of personal reflection, available literature, and analysis to understand at least some aspects of the ‘art’, and then turn these into practical advice or methods¹. This is not to take away the skill and artfulness of expert performance, but to find props and scaffolding to enable the novice to achieve and grow.

Schön likewise does not stop at describing and analysing vignettes of professional artfulness in action, but notes the blockages to more successful professional activity and offers potential ways forward. In particular, he analyses some of the blocks to reflection in action, often about face-saving and political games. He also advocates a potential form of professional relationship with clients, the “reflective contract”, where the practitioner is much more open about problems, ambiguities and uncertainties, opening up the process of professional action to the client and inviting the client’s own expertise and knowledge into the process. This reminds me very much of the goals of participatory design.

Such practices maybe need radical cultural shifts in organisations and disciplines not just individual practitioner–client relationships. In a world of litigation it is often better for a client to remain in ignorance and trust to the professional indemnity insurance of the expert! Even in academia papers that admit the limitations and problems with a technique are likely to be reviewed more harshly than those that extol their own benefits.

science and practice

While the central practical message is about the positive role of reflection in professional practice, in fact this is set within a broader context in which the book a whole is an apologetic for the value of professional practice against positivist, rationalist views, which try to make practice simply the application of science and academic knowledge.

Reading it at a time when UK government policy has for several years been pushing for vocational pre-18 training to be treated on a par with academic A’ levels, it would appear that Schön was simply a man out of his time. However, as this quest for ‘equivalence’ has also led to the virtual death of more vocational post-18 training being replaced by university degrees for everything, maybe Schön would not be so happy².

Writing in 1980, Schön was reacting to the perceived devaluation of professional artistry, and places himself as an advocate. However, reading it in hindsight thirty years later in an academia where the term ‘positivism’ is derogatory, and distrust in science is at least as strong as distrust in professionals, I wonder if this dualism between academia and practice is what needs to be challenged. Schön discusses the way reflective practice can help practitioners come outside the ‘frame’ within which they have conceived a situation and thus have fresh eyes. For Schön, his own frame is the implicit acceptance of the dualism.

Paradoxically, in his actual actions, Schön is breaking this frame. In his reflection upon the nature of professional practice, he is precisely lifting aspects of this into the realm of more academic analysis. Indeed he speaks of the potential for “action science” (p. 319). So in his own terms, as a professional whose subject is professional activity, he exhibits in his knowledge-in-action a nuancing of the academic-practice dualism, which is missing in his reflection-on-action!

One particular passage caught this tension perfectly. Schön is discussing the problem of demystifying professions and cites Illich’s critique of technical expertise as a form of social control. Schön then says:

“Paradoxically, it is not uncommon to discover that the very same students of the professions who hunger for the “hard” technical skills which they believe will assure then of jobs in established institutions also espouse the radical vision of demystifcation.” (p. 289)

The term ‘paradoxically’ should surely prompt reflection on the implicit judgements behind the statement. As someone coming from a technical background, it seems hardly surprising that the ‘hard’ technical skills (which I take to mean, engineering, management science, etc.) are demystifying. Even if the language of mathematics in an engineering book may take some learning, the whole point is that one can take up a textbook and learn necessary knowledge from there, not wait for mastery to grow over years of experience. This aspect of science is radical, and sometimes breeds resistance; indeed Newton deliberately cast his Principia Mathematica in geometry not algebra for fear the undeserving would understand it.

At its best, in human–computer interaction, we do see a constructive dialogue between HCI academia and interaction design practice, where academic knowledge both contributes to professional practice and learns from it. Mainly this is applied to the artefacts we produce and the people who use them, but perhaps less to the process of design itself.

Similarly in my own first discipline, mathematics, the basic equations and knowledge of more applied mathematics are learnt early and studied in depth. This universal knowledge is applied repeatedly and I would hope artfully, in the singular situations of professional practice. For example, in my own practice I recall using functions of complex numbers in modelling electrostatically-charged agricultural sprays. However, whilst the subject matter of the mathematics is codified explicitly, the process of applying this knowledge in professional practice is not usually itself studied as part of mathematical training; instead assumed to be something one picks up over time — still mysterious.

Although it is not the way he would phrase it, Schön’s work demystifies and systemises aspects of professional practice, by effectively bringing some of the artistry under the academic lens. This codification of the ineffable seems a laudable goal and science at its best. If seen as replacing professional experience it is clearly misguided, but so long as the codified knowledge of engineering, science and indeed HCI is seen as partial, and limited it becomes valuable. Codified ‘hard’ technical knowledge and rules may de-skill parts of professional practice, but also enables professions to grow by offering generic or universal knowledge that can be applied artfully to the particular.

artful application

I have also been reading “Calum’s Road” about a crofter on the little island of Raasay off the coast of Skye, who built by hand, pick and barrow a 2 mile road across Raasay, over a period of 10 years. Calum built his road, a work of artistry and graft, based neither on a university course, nor on a long period of professional experience, but instead using the codified knowledge in a civil engineering book on road construction³.

1. See my pages about “research and innovation“, “writing as third-order experience“, “externalisation– how writing changes thinking“, and “why examples are hard“. I keep meaning to turn my debugging lectures into notes or a short book … someday. [back]
2. Certainly the Car Gilleard, the CEO of the Association of Graduate Recruiters in the UK is not enamoured at the idea of university degrees as the only career path: see The Big Issue Scotland, no 776, March 15-21, 2010, p.9 [back]
3. Thomas Aitken, “Road Making and Maintenance”, London, 1900 [back]

Earlier today Fiona @lovefibre was using the MAC OS Time Machine to retrieve an old version of a file (let’s call it “fisfile.doc”).  She wanted to extract a part that she knew she had deleted in order to use in the current version.  Of course the file you are retrieving has the same name as the current file, and the default is to overwrite the current version; that is a simple backup restore.  However, you can ask Time Machine to retain both versions; at which point you end up with two files called, for example, “fisfile.doc” and “fisfile-original.doc”.  In this case ‘original’ means ‘the most recent version’ and the unlabelled one is the old version you have just restored.  This was not  too confusing, but personally I would have been tempted to call the restored file something like “fisfile-2010-01-17-10-33.doc”, in particular because one wonders what will happen if you try to restore several copies of the same file to work on, for example, to work out when an error slipped into a document.

OK, just an single incident, but only a few minutes later I had another example of problematic naming.

I picked up mail and found I had an email notification from Lancaster University accounts department.  The email included the BACS remittance advice for recent expenses as a PDF attachment.  However, while they send emails like this every month or so, the attachment always has the same name “lu_remittance_advice_1234567.pdf” (where ’1234567′ is my ‘supplier ID’ on the Lancaster finance system).  As I saved it I remembered to change the name to “lu_remittance_advice_1234567_150210.pdf” to record the date as otherwise, if I did not rename, each remittance would have overwritten the previous one.  Note this is a finance systems and these documents could be important for tax purposes (in order to prove the payment was for expenses) and there is only an electronic remittance.  That is the use of the same name makes it likely that employees — and presumably also corporate suppliers — will accidentally delete critical records.

Those of you who have run any sort of small conference or workshop (or those who remember running a large one in the days before conference management systems) will have undoubtedly received numerous submission entitled “paper.doc” or “confname.doc” (where ‘confname’ is the name of your conference).  And yes, shame on me, I have done the same myself.  When I am editing the files myself or exchanging it with co-authors I will almost always call it something like “confname-v7.doc”.  However, when I submit it I (try to remember to) rename it to “dix-confname.doc”.  (And how many of you forget to add some sort of version number or date to the end of the filename when you exchange it with colleagues?)

Now while it is forgiveable for a person to make these kinds of mistake, it seems inexcusable when an automated system does it.  For example, a number of publishers sites will call every paper you download “fulltext.pdf”.

So, if you are designing a system that generates file names, please, pretty please:

1. make it readable — a person needs to look at the file name and make sense of it.
2. make it unique — add a date or unique id, perhaps page range for a journal

So rather than the web site of the “International Journal of Good Naming” calling the download “fulltext.pdf”, instead call it “IJGN-2010v3p012-Dix-Naming.pdf”

Suitable naming can also help in searching.  If you have several chapters calling them “chap01.doc”,”chap02.doc”, etc. (rather than “chap1.doc”,”chap2.doc”), so that in an alphabetic listing “chap09.doc” comes before “chap10.doc”.   And Andy Wood taught me to always format dates in file names  in reverse order “file-20100217″ (rather than “file-17022010.doc”), so that alphabetic order is date order¹.  I must admit (sorry Andy!) that I more often use UK order (e.g. “lu_remittance_advice_1234567_150210.pdf” as the remittance dated 15th Feb 2010) as I find it easier to read.

When file names escaped the 8+3 formats and became any length, really descriptive names  became possible and I’ve known people who could not manage folders/directories on teh machine, but instead created incredibly expressive naming schemes in “My Documents”, which effectively reinvent the hierarchical naming.  With the ‘flat’ filing of tags in Flickr and Gmail, similar complex strategies emerged.

Real names of people and places also vary on context. Saying “Nigel” is sufficient to uniquely express who I’m talking about in Lancaster Computing, but not for any reader of this who doesn’t know the department.

Again, something to think about in automated systems.

After many years using my trusted paper to do list, I have tried again an electronic system ‘The Hit List‘.  This allows to do ‘tasks’ to have sub-tasks and sub-sub-tasks, etc.  So, if I am reviewing papers for EICS I can have a sub-task for each paper and for each paper  sub-sub-tasks “read”, “write comments”, “upload comments”.

Unfortunately on the ‘Today’ panel, for things I have to do now, I simply get a list saying “read”, “read”, “read”.  While the sub-sub-task name “read” is sufficient in the context of the task and sub-task it belonged to, it is very ambiguous on its own.  Very quickly I learnt to explicitly include the full details on every sub-task!

Getting this right is a far more complicated to automate.  Helping Fiona on a system where there was a structure of items and sub-items, we allowed the user to explicitly give an alternate name to use ‘out of context’, but otherwise used a default rule.  The rule simply checked if the sub-item name started off similarly to the item name (for example, if the user had already entered a descriptive name such as “EICS paper 123″) and if so used that, but otherwise prefixed the item name to make it unique. This of course only works if the individual names are not too long and there is lots of screen space; hence allowing the user the option to explicitly enter a display name if the default did not work.

Naming is tough and there will always be ambiguity and confusion.  However, with a little thought when we design systems, we can make it a lot bettter.

1. You might wonder why not rely on the file system’s date for the file.  However, for various reasons file dates often become confusing: date of creation, update, or download, especially for folders. So while the file system date is “date it was changed on this machine”, the file name date may be “date it pertains to”, for example the date of the BACS payment in the remittance advice, not the date of the email. [back]

I  pick up just a few of the threads from those visits, looking particularly and the way ‘place’ transforms over time, the way signage addresses itself, and the different kinds of flow in populated space.  At B&Q especially I was fascinated by the back of the store, the place that gets ignored and yet which was critical for services and the actual delivery of goods.

I can’t recall why (five years ago now!), but the talk slides only tenuously connect to the text of the notes, I think maybe because I was touching on too many issues in the brief notes.

Devices are clearly everywhere, but the connections between them seem infrequent and poor.

Why is ubiquitous technology still so … well un-ubiquitous?

Why bother

One reason for lack of connectivity, is that for each production and purchase decision there is little need for it.  It is possible to wire up your whole home with sensors as Andy Stanford-Clark‘s twittering house demonstrates.  But for most people why put sensors in your home unless they are for something?  Why bother to buy things unless they give you value now? Home security, central hearing control, warning you when your fuel is running low — these are reasons for sensors, but in general we tend to buy things that do things for us, not things that might possibly plug together to do something interesting. This is maybe even more true of the new generation of digital natives, brought up with single function toys, and even Lego in  pre-determined models rather than generic kits.

Of course, we do buy things with sensors, the electric kettle has a temperature sensor, the TV knows what channel is tuned — but these are single purpose.  Even SCART connections for TV/DVD/satellite boxes are pretty limited unless the devices expect to be chained.  For the manufacturer, why bother to make stand-alone devices connectible; it will cost more in terms of a wireless chip, not to mention complex interfaces to manage privacy.  Even software rarely takes this step to make itself easy to interconnect — despite the mash-culture of Web2.0.  The barcode reader app on the iPhone is a rare exception; here the cost was relatively low and purely in  software (up front cost, but no cost per ‘device’), and yet even this is rare to see.  Once there are hardware costs even generic devices such as phones only include sensors for which they can see an immediate use: for ecxample, despite the presence of GPS and compass in the iPhone, the new iPad, with sightly different expected uses, has neither.  For physical devices, connectivity may come when individual devices require external interfaces, maybe to manage complex installations or monitoring via mini-webservers for less cost than dedicated displays, just as with most home routers.  Then the hardware cost of connectivity has a purpose for the dedicated device, and the additional cost of genericity is software only.

What’s there

It is interesting to look back at Mark Weiser‘s original vision of ubiquitous computing.  It is less connected than Adam’s ‘everywhere’, but equally rooted in research prototypes and potential, and yet has certainly come to pass as computation is certainly ‘ubiquitous’ in many ways.  Like others, I have always been struck by the disconnect between the opening words of Weiser’s The Computer for the 21st Century “The most profound technologies are those that disappear” and the rest of the paper, which focused on displays the visible face of computation.  But, with the exception of miniature MP3 players,  it is precisely these visible displays that are part of our lives.

Weiser classified displays into tabs, pads and boards, with associated scales (inch, foot, yard), and indeed the size of displays is crucial to their uses¹.  However, it is perhaps better to look at Wesier’s definitons of where and how these are used: tabs are ‘on things’ microwaves, some TV remotes, and old mobile phones (the kind that were primarily for telephoning people!), pads are held and carried and while decidely smaller than an foot, the iPhone and similar smartphones are clearly in this category, and finally boards are in the environment, stuck on walls (digital photo frames) and furniture (Microsoft surface).  All can be seen in many homes and offices, although the latter have perhaps had least impact so far,  laregly because of costs of production (foreseen by Wesier), but are clearly coming on stream.

The crucial thing is that all of these displays do something for us.  They are ubiquitous because they are not invisible.

How to use them

Adam’s book describes the profoundly different user experience of ‘everywhere’ interactions (pp:27-39), rather than being task-driven by the user, in situations such as such as automatic room lights “the system precedes the user“, “Whether or not you walk into the room in pursuance of a particular aim or goal, the system’s reaction to your arrival is probably tangential to that goal.“.  This what I have previosly called ‘incidental interaction‘, interactions not driven by the user’s immediate intentions, but by the system’s actions for the user.

Somewhat strangely the discussion in ‘Everywhere’ then turns to Bellotti et al’s “Making sense of sensing systems: five questions for designers and researchers“, which summarises some of the key issues of pervasive systems dating back to the 1984 Phone Slave project², such as knowing how to address a system that has no keyboard and knowing whether it is attending.  These are really important issues, but are about intentional use, getting the system, albeit embedded in the environment, to do something that the user has decided. At a more device level,  Abricht Schimdt‘s concept of implicit interaction³ is also in this area, making the interaction to achieve some purpose as natural and invisible as possible using sensors such as accelerometers. This is now common in devices such as the iPhone, but is still essentially about intentional interaction — again getting the device to do something.

In contrast, we seem to still have little understanding of the user experience of incidental interactions, where the system spontaneously does things for or to us, and they are still rare in the home and office, a few specific devices such as automatic lights, doors and central heating controllers, with little sign of widespread connectivity.  The main exceptions seem to be at a very large scale, Amazon book recommendations or traffic management systems.

The latter is perhaps an interesting comment on ubiquity as, for the ordinary user, the display is simply a red light.

1. see recent papers with Corina Sas “Mobile Personal Devices meet Situated Public Displays: Synergies and Opportunities” and with Lucia Terrenghi and Aaron Quigley “A taxonomy for and analysis of multi-person-display ecosystems“, which extend this size classification to larger and smaller displays. [back]
2. See “Phone Slave: A Graphical Telecommunications Interface” and YouTube video, although it was the longer envusonment video, that raised the user interaction design questions. [back]
3. Schmidt, A. Implicit Human Computer Interaction Through Context. Personal Technologies, 4(2&3), Springer-Verlag, 191–199, 2000 [back]