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]

So is it really so bad?

tiny-screen coding and literate programming

This issue came to mind because I’ve been considering what programming language support might be like for tiny screens (and I mean mobile phone not laptop!).  This was prompted by group discussions at the Mobile Design Dialogue conference last year² and at a bootcamp session at the Winter School on Interactive Technologies in Bangalore in February.

One of my first thoughts was that something akin to literate programming might provide a useful contribution as it allows details to be elided.  For example:

@{obtain email address from form variables}
if @{check email address valid}
then @{produce bad email error message}
else @{send email message}

The placeholders (such as “check email address valid”) are then defined separately.  In Knuth’s original WEB (and Harold Thimbleby’s cweb), all the definitions are in a single file, but in a phone-based environment this would be more like a hypertext — indeed reminiscent of the code browsers I worked on when I first came into computer science!

Using this form of named fragments would mean that one could have much smaller snippets of code on screen at any moment of time, basically substituting abstraction for scrolling, hence the reason for thinking this could be good for tiny-screen coding.

However, the semantics of these fragments in literate programming is textual inclusion, basically macro expansion.  Amongst other things this means effectively dynamic scoping; for example, the code “obtain email address from form variables” might define a variable “email” that is then used in “send email message “.

However, the dynamic scoping is quite limited as the code fragments were always (or maybe normally) only used in one place, that is they are merely a way of hiding code.  This is quite different from a piece of code that takes different meaning wherever you place it dependent on what variables it picks up.

scripts and templates

As I began to think about this I recalled early templating languages I developed for code generation from data types (somewhat similar to current web scripting languages).  In these I used abstractions that were partly like a procedure, but also, similar to literate programming, in that ‘parameters’ could be extracted from context if not given explicitly.  In the example earlier a ‘procedure’ like “check email address valid ” might have an explicit parameter  ‘email’, but this would be taken from the environment if it was not set explicitly.  This reflects the fact that in many situations there is an ‘obvious’ parameter, just as in day to day life you just say “post the letter”, not “post the letter that is on the hall table just where you will obviously find it as you go out and where I always put it”.

While this still seems a little heretical when implemented as part of a programming language (or at least templating script), in fact it is common at the meta-coding level of ‘includes’ found in most web scripting including JSP.  For example in PHP one might write:

<?php
foreach ( $messages as $message ) {
    include "format-message.php";
}
?>

The PHP code in the file ” format-message.php ” is effectively textually included inside the ‘foreach’ block and hence ‘$message’ would be available to it as a variable.  While the base language is largely lexically scoped, the includes effectively allow an alternative abstraction with dynamic binding.  Purists would might decry the above code, but few have not  used something similar at some point. Indeed the WordPress plugin system depends entirely on careful use of such constructs.

In my websites (e.g. hcibook.com/e3, snipit.org) I typically have a ‘top.php’ function that routes raw URLs to appropriate pages or scripts by use of ‘include’³.  Often this performs common start-up actions such as establishing database connections, reading Cookies, or parsing URL path information, and, of course, the results of all of this are then available as context for the included scripts.  Sometimes I wrap this in a single global variable $context, but not always (life is short, and the sensible time to code a website shorter!).

aggregate inheritance

In a HTML document, the font of a paragraph is set not by some form of object inheritance based on the class of the <p> tag, but instead on the smallest enclosing block that has an explicit font style.  The binding of fonts is in a sense static or even lexical as it is based on where in the document structure the text sits, but it is not about the lexical structure of the CSS, but of the HTML document to which it is applied.

Similarly, in a GUI a mouse click on a button will typically go through a hierarchy where the enclosing elements (screen panel, etc.) get ‘first dibs’ to filter or react to the event, eventually dribbling down to the button itself, and then sometimes back up again with the containers getting a chance to do some sort of ‘after the event’ processing.  Just like the font on the page, the meaning of ‘click on button’ cannot be found solely in the class structure of ‘JButton’, but in the dynamic location where it is found.

I don’t know a standard term for this, but I have always called it ‘aggregate inheritance‘ as elements inherit from the containers within which they are aggregated.

While lexical binding is about the structure of the code, normal dynamic binding is about the structure of the process (calling pattern) and aggregate inheritance is about the structure of the data.

the bad and the worse

The reasons for eschewing dynamic binding were partly about efficient compilation of block-structured languages, albeit now with complex object inheritance rules, dynamic binding seems tame!  The other reason was semantic as static (and especially lexical) binding allows a limited form of referential transparency, you can tell what a variable means and track the data flow — locality.

Clearly at one stage the jury was still out, indeed one of the innovations (I believe) in Algol 68 was the inclusion of dynamic binding and as late (sic) as 1986 papers were discussing ways of implementing dynamic binding⁴.  However, even Lisp eventually moved to making its default binding static.

Today all major languages use lexical binding — except they don’t.  In fact there are numerous workarounds, just like the tortured workarounds we use for GOTO-less code⁵.

Simple object inheritance is static, but only so long as no one changes the classes you inherit from!  Of course OO inheritance is itself often criticised, but is generally accepted as OK⁶.

In even simple code we also use global variables, which while static in scope certainly allow non-local effects.  These are again especially common in web scripting where context seems particularly important. In fact they are so ubiquitous that special language constructs may be used such as PHP’s ‘superglobals‘ or ‘define‘. On the client side also, Javascript code is often replete with globals.

Those using ‘proper’ languages may look down on slack web programming practices.  However, the popular singleton pattern or static Class variables (such as in the Java System class) are but globals by another name, and database access and the filesystem again access a large global name space.

But if the problem of dynamic binding is non-locality, surely the worst culprits are pointers and references.  Pure functional programming takes referential transparency seriously, is side effect free and so avoids updatable references and pointers.  However, few programmers, however pure, are willing to work totally under FP’s strictures⁷.

Non-locality of reference and effect seems, not just common but ubiquitous.  It is dangerous, but that is because it is powerful.  This is true of pointers, but equally of variable binding paradigms, the issue is how to ensure understanding and control of non-locality, not to forbid some kinds whilst allowing free reign to others.

context and pipelines

I’ve used the term ‘context’ several times.  In ubicomp and intelligent interfaces issues connected with context are critical in interpreting user activity.  Similarly, natural language processing and vision at first (many years ago), took a very pure layered approach with each level of processing giving its results to the next up in a pipeline: lexical to syntactic to semantic.  However, human interpretation is not so neatly layered⁸.  Both NLP and computer vision became a lot more successful when they allowed downwards paths from semantics back down to lower levels.

Compiler and language design took their form partly based on early models of language, indeed any cross-over between layers of processing was deemed problematic⁹.  Whilst AI seems to have moved on, programming language design does not; in language and the physical world we assume that terms take meaning from context, why not in programming?

using dynamic binding

Recently I was writing shortcodes in a WordPress plugin.  Shortcodes are tags in the text of a blog item that can be used as a form of extensible markup.  For example “[cite key=Dx09]” in the text might lookup and link to an entry in a bibliographic database¹⁰.  Some of the codes are stand alone, but some come in pairs [/code]

Being a typical hacker, I first of all created a generic helper plug-in (SimpleShortcodeHandler) that made it easy to do simple things like add a span or div with a specific class.  However, I was aware that I might want to add more complicated things like a BibTeX-style bibliography list:

[bibliography format=APA"]
[bibitem key="Dx09 "] A. Dix (2009).
    What's wrong with dynamic binding? [/bibitem]
[bibitem key="Dy68"] Dykstra, E. (1968).
    GoTo … [/bibitem]
[/bibliography]

The behaviour of the '[bibitem]' codes would clearly need to depend on the format of the bibliography, but the normal shortcode extension mechanism means (as in all good programming!) the code to process each shortcode is in isolation applied to its own text.  As a simple addition, the SimpleShortcodeHandler class keeps a stack of enclosing shortcodes in a post so that the handler for 'bibitem' can query the stack for the most recent enclosing 'bibliography' tag.  That is, I added a workaround for dynamic binding in the program code to enable aggregate inheritance in the blog post.

In fact, the way WordPress processes shortcodes means that the code for 'bibitem' is called within a call to the expansion code for 'bibliography', however, there are intervening calls to WordPress' internal functions, so one cannot simply pass in context information as an additional parameter.

Similar but more complex issues arise when dealing with sessions in web applications, AJAX programming, or other asynchronous remote procedure calls, all of which are basically an extreme case of program  inversion as found following structure clash in old Jackson Structured Programming, or more generally in co-routine-based coding.

adding dynamic binding to the language

There seem to be two forms of dynamic binding that are commonly used.

The first is shallow dynamic binding, for things like the literate programming and PHP includes.  Here the dynamic binding is almost a form of implicit parameter passing, a convenient shortcut for writing code like:

function do_some_work_to_x(x) { . . . }
// . . . later in the code
x = 3;
do_some_work_to_x(x);

The expanded code may update variables as well as use their values, but that is then like passing variables by reference.

When using PHP includes that are doing work (e.g. web page templates, as opposed to declaring functions) I usually add a comment block at the top saying what variables it expects to find in its environment.  There is no reason why this should not be made more explicit, whether hand written, or generated by a programming environment.

The second form is deep dynamic binding as in the shortcode stack described above, and indeed in many forms of meta-level programming where there is aggregate inheritance on a data structure.  In these examples, the dynamic binding is to variables that are connected to a module or similar namespace, but where the scoping of the namespace is not the call structure.

In the shortcode example, this simply was a means to pass information up and down to related functions, 'skipping' other 'foreign' functions on the way.

However, in other cases there may be a more complex pattern of scoping the context. A simple example would be for having variable 'constants' in a mathematical function class:

module Math {
  context { precision = 0.0001; base = 10; }
  sqrt(x) {
      y = 1;
      while ( abs(y*y-x)> precision )
          y = (y+x/y)/2;
      return y;
  }
}

Then in the calling code something like:

Math.push_context;
Math.precision=0.1;
z = sqrt(2);
Math.pop_context;

To some extent this form of deep context is relatively easy to manage through coding patterns, but the ubiquity in transactional, asynchronous and co-routine programming, suggests deeper infrastructure support would be useful.

in short

In dealing with the lack of good mechanisms for dynamic binding, programmers are often forced into workarounds that are worse than if there were a simple way to do it in the language.  The non-locality problems of dynamic binding are also present in other accepted programming constructs such as pointers.  On the other hand, there are many contexts, especially in web programming, where forms of dynamic binding lead to neater, more comprehensible, and hence more robust and maintainable code. Dynamic programming can be dangerous and the overall approach of the past 20 years has been to hope it will go away. However, its ubiquity and utility suggests that including support for safe and appropriate dynamic binding in tools, frameworks or languages (and the three can be conflated) may be a better approach for the future.

1. Strangely also the days when major advances in substance seemed to be more important than minor advances in nomenclature [back]
2. Recently Ken Banks, Matt Jones and Gary Marsden who proposed the MDD discussion are amongst the partners in a new project ‘mobility‘, which is planning to work on mobile-based programming tools. [back]
3. Similar to the pattern proposed by Joseph Scott in “PHP URL Routing (PUR)“ [back]
4. e.g. Gantenbein, R. E. and Jones, D. W. 1986. Dynamic binding of separately compiled objects under program control. In Proceedings of the 1986 ACM Fourteenth Annual Conference on Computer Science (Cincinnati, Ohio, United States). CSC ’86. ACM, New York, NY, 287-292. DOI= http://doi.acm.org/10.1145/324634.325436 [back]
5. The argument for avoiding where possible GOTOs was of course clearly made by Dijkstra in “Go To Statement Considered Harmful” (Communications of the ACM, Vol. 11, No. 3, March 1968, pp. 147-148). However, see the example of an LR parser in David Tribble‘s commentary on Dijkstra’s paper.  The parser would typically be coded now-a-days using a number of state variables, obfuscating the meaning far more than the controlled use of GOTO. [back]
6. Oddly, whilst inheritance is deemed OK, for some reason mix-ins are avoided in Java and indeed most modern OO languages.  This seems to be due to some of the semantic quagmire of multiple-inheritance, but mix-ins can be made semantically innocuous and would be so useful!  To some extent Aspect-Oriented Programming has some of the feel of mix-ins, and can be used to solve some similar problems; however it too brings issues of locality and transparency. [back]
7. Although Google’s MapReduce shows functional programming can be very powerful.  Having worked with FP people for many years, I find much of my own code has an FP feel. [back]
8. In particular, semantic levels of processing ‘pass down’ context to lower levels so that they ‘know what to expect’ and so can disambiguate stimuli.  To some extent we see and hear what we expect, hence various forms of optical illusion. [back]
9. For example, in K&R C, the expression: “kind (*fun)();” is syntactically ambiguous unless you know whether ‘kind’ is a user defined type. This rare cross-over between syntax and semantics was seen as a weakness in the language. [back]
10. I’m writing plugin’s to help write the TouchIT book [back]

As you can guess a number of problems ensued, some easily fixable, some demonstrating why effective interaction design is not trivial and apparently good choices can lead to disaster.

There is a common thread.  Most usability is focused on the time we are actively using a system – yes obvious – however, most of the problems I faced were about the extended use of the system, the way individual periods of use link together.  Issues of long-term interaction have been an interest of mine for many years¹ and have recently come to the fore in work with Haliyana, Corina and others on social networking sites and the nature of ‘extended episodic experience’.  However, there is relatively little in the research literature or practical guidelines on such extended interaction, so problems are perhaps to be expected.

First the good bit – the Creative ‘Suite’  includes various individual Adobe products and there are several variants Design/Web, Standard/Premium, however there is a great page comparing them all … I was able to choose which version I needed, go to the academic purchase page, and then send a link to the research administrator at Lancaster so she could order it.  So far so good, 10 out of 10 for Adobe …

To purchase as an academic you quite reasonably have to send proof of academic status.  In the past a letter from the dept. on headed paper was deemed sufficient, but now they ask for a photo ID.  I am still not sure why this is need, I wasn’t going in in person, so how could a photo ID help?  My only photo ID is my passport and with security issues and identity theft constantly in the news, I was reluctant to send a fax of that (do US homeland security know that Adobe, a US company, are demanding this and thus weakening border controls?).

After double checking all the information and FAQs in the site, I decided to contact customer support …

Phase 1 customer support

The site had a “contact us” page and under “Customer service online”, there is an option “Open new case/incident”:

… not exactly everyday language, but I guessed this meant “send us a message” and proceeded. After a few more steps, I got to the enquiry web form and asked whether there was an alternative, or if I sent fax of the passport whether I could blot out the passport number and submitted the form.

Problem 1: The confirmation page did not say what would happen next.  In fact they send an email when the query is answered, but as I did not know that, so I had to periodically check the site during the rest of the day and the following morning.

Lesson 1: Interactions often include ‘breaks’, when things happen over a longer period.  When there is a ‘beak’ in interaction, explain the process.

Lesson 1 can be seen as a long-term equivalent of standard usability principles to offer feedback, or in Nielsen’s Heuristics “Visibility of system status”, but this design advice is normally taken to refer to immediate interactions and what has already happened, not about what will happen in the longer term.  Even principles of ‘predictability’ are normally phrased in knowing what I can do to the system and how it will respond to my actions, but not formulated clearly for when the system takes autonomous action.

In terms of status-event analysis, they quite correctly gave me an generated an interaction event for me (the mail arriving) to notify me of the change of status of my ‘case’.  It was just that the hadn’t explained that is what they were going to do.

Anyway the next day the email arrived …

Problem 2: The mail’s subject was “Your customer support case has been closed”.  Within the mail there was no indication that the enquiry had actually been answered (it had), nor a link to the the location on the site to view the ‘case’ (I had to login and navigate to it by hand), just a general link to the customer ‘support’ portal and a survey to convey my satisfaction with the service (!).

Lesson 2.1: The email is part of the interaction. So apply ‘normal’ interaction design principles, such as Nielsen’s “speak the users’ language” – in this case “case has been closed” does not convey that it has been dealt with, but sounds more like it has been ignored.

Lesson 2.2: Give clear information in the email – don’t demand a visit to the site. The eventual response to my ‘case’ on the web site was entirely textual, so why not simply include it in the email?  In fact, the email included a PDF attachment, that started off identical to the email body and so I assumed was a copy of the same information … but turned out to have the response in it.  So they had given the information, just not told me they had!

Lesson 2.3: Except where there is a security risk – give direct links not generic ones. The email could easily have included a direct link to my ‘case’ on the web site, instead I had to navigate to it.  Furthermore the link could have included an authentication key so that I wouldn’t have to look up my Adobe user name and password (I of course needed to create a web site login in order to do a query).

In fact there are sometimes genuine security reasons for sometimes NOT doing this.  One is if you are uncertain of the security of the email system or recipient address, but in this case Adobe are happy to send login details by email, so clearly trust the recipient. Another is to avoid establishing user behaviours that are vulnerable to ‘fishing’ attacks.  In fact I get annoyed when banks send me emails with direct links to their site (some still do!), rather than asking you to visit the site and navigate, if users get used to navigating using email links then entering login credentials this is an easy way for malicious emails to harvest personal details. Again in this case Adobe had other URLs in the email, so this was not their reason.  However, if they had been …

Lesson 2.4: If you are worried about security of the channel, give clear instructions on how to navigate the site instead of a link.

Lesson 2.5: If you wish to avoid behaviour liable to fishing, do not include direct links to your site in emails.  However, do give the user a fast-access reference number to cut-and-paste into the site once they have navigated to the site manually.

Lesson 2.6: As a more general lesson understand security and privacy risks.  Often systems demand security procedures that are unnecessary (forcing me to re-authenticate), but omit the ones that are really important (making me send a fax of my passport).

Eventually I re-navigate the Adobe site and find the details of my ‘case’ (which was also in the PDF in the email if I had realised).

Problem 3: The ‘answer’ to my query was a few sections cut-and-pasted from the academic purchase FAQ … which I had already read before making the enquiry.  In particular it did not answer my specific question even to say “no”.

Lesson 3.1: The FAQ sections could easily have been identified automatically the day before. If there is going to be  delay in human response, where possible offer an immediate automatic response. If this includes a means to say whether this has answered the query, then human response may not be needed (saving money!) or at least take into account what the user already knows.

Lesson 3.2: For human interactions – read what the user has said. Seems like basic customer service … This is a training issue for human operators, but reminds us that:

Lesson 3.3: People are part of the system too.

Lesson 3.4: Do not ‘close down’ an interaction until the user says they are satisfied. Again basic customer service, but whereas 3.2 is a human training issue, this is about the design of the information system: the user needs some way to say whether or not the answer is sufficient.  In this case, the only way to re-open the case is to ring a full-cost telephone support line.

Phase 2 customer feedback survey

As I mentioned, the email also had a link to a web survey:

In an effort to constantly improve service to our customers, we would be very
interested in hearing from you regarding our performance.  Would you be so
kind to take a few minutes to complete our survey?   If so, please click here:

Yes I did want to give Adobe feedback on their customer service! So I clicked the link and was taken to a personalised web survey.  I say ‘personalised’ in that the link included a reference to the customer support case number, but thereafter the form was completely standard  and had numerous multi-choice questions completely irrelevant to an academic order.  I lost count of the pages, each with dozens of tick boxes, I think around 10, but may have been more … and certainly felt like more.  Only on the last page was there a free-text area where I could say what was the real problem. I only persevered because I was already so frustrated … and was more so by the time I got to the end of the survey.

Problem 4: Lengthy and largely irrelevant feedback form.

Lesson 4.1: Adapt surveys to the user, don’t expect the user to adapt to the survey! The ‘case’ originated in the education part of the web site, the selections I made when creating the ‘case’ narrowed this down further to a purchasing enquiry; it would be so easy to remove many of the questions based on this. Actually if the form had even said in text “if your support query was about X, please answer …” I could then have known what to skip!

Lesson 4.2: Make surveys easy for the user to complete: limit length and offer fast paths. If a student came to me with a questionnaire or survey that long I would tell them to think again.  If you want someone to complete a form it has to be easy to do so – by all means have longer sections so long as the user can skip them and get to the core issues. I guess cynically making customer surveys difficult may reduce the number of recorded complaints

Phase 3 the order arrives

Back to the story: the customer support answer told me no more than I knew before, but I decided to risk faxing the passport (with the passport number obscured) as my photo ID, and (after some additional phone calls by the research administrator at Lancaster!), the order was placed and accepted.

When I got back home on Friday, the box from Adobe was waiting

I opened the plastic shrink-wrap … and only then noticed that on the box it said “Windows”

I had sent the research adminstrator a link to the product, so had I accidentally sent a link to the Windows version rather than the Mac one?  Or was there a point later in the purchasing dialogue where she had had to say which OS was required and not realised I used a Mac?

I went back to my mail to her and clicked the link:

The “Platform” field clearly says “Mac”, but it is actually a selection field:

It seemed odd that the default value was “Mac” … why not “CHOOSE A PLATFORM”, I wondered if it was remembering a previous selection I had made, so tried the URL in Safari … and it looked the same.

… then I realised!

The web form was being ‘intelligent’ and had detected that I was on a Mac and so set the field to “Mac”.  I then sent the URL to the research administrator and on her Windows machine it will have defaulted to “Windows”.  She quite sensibly assumed that the URL I sent her was for the product I wanted and ordered it.

In fact offering smart defaults is  good web design advice, so what went wrong here?

Problem 5: What I saw and what the research administrator saw were different, leading to ordering the wrong product.

Lesson 5.1: Defaults are also dangerous. If there are defaults the user will probably agree to them without realising there was a choice.  We are talking about a £600 product here, that is a lot of room for error.  For very costly decisions, this may mean not having defaults and forcing the user to choose, but maybe making it easy to choose the default (e.g. putting default at top of a menu).

Lesson 5.2: If we decide the advantages of the default outweigh the disadvantages then we need to make defaulted information obvious (e.g. highlight, special colour) and possibly warn the user (one of those annoying “did you really mean” dialogue boxes! … but hey for £600 may be worth it).  In the case of an e-commerce system we could even track this through the system and keep inferred information highlighted (unless explicitly confirmed) all the way through to the final order form. Leading to …

Lesson 5.3: Retain provenance.  Automatic defaults are relatively simple ‘intelligence’, but as more forms of intelligent interaction emerge it will become more and more important to retain the provenance of information – what came explicitly from the user, what was inferred and how.  Neither current database systems nor emerging semantic web infrastructure make this easy to achieve internally, so new information architectures are essential.  Even if we retain this information, we do not yet fully understand the interaction and presentation mechanisms needed for effective user interaction with inferred information, as this story demonstrates!

Lesson 5.4: The URL is part of the interaction².  I mailed a URL believing it would be interpreted the same everywhere, but in fact its meaning was relative to context.  This can be problematic even for ‘obviously’ personalised pages like a Facebook home page which always comes out as your own home page, so looks different.  However, it is essential when someone might want to bookmark, or mail the link.

This last point has always been one of the problems with framed sites and is getting more problematic with AJAX.  Ideally when dynamic content changes on the web page the URL should change to reflect it.  I had mistakenly thought this impossible without forcing a page reload, until I noticed that the multimap site does this.

The map location at the end of the URL changes as you move around the map.  It took me still longer to work out that this is accomplished because changing the part of the URL after the hash (sometimes called the ‘fragment’ and accessed in Javascript via location.hash) does not force a page reload.

If this is too complicated then it is relatively easy to use Javascript to update some sort of “use this link” or “link to this page” both for frame-based sites or those using web form elements or even AJAX. In fact, multimap does this as well!

Lesson 5.5: When you have dynamic page content update the URL or provide a “link to this page” URL.

Extended interaction

Some of these problems should have been picked up by normal usability testing. It is reasonable to expect problems with individual web sites or low-budget sites of small companies or charities.  However, large corporate sites like Adobe or central government have large budgets and a major impact on many people.  It amazes and appals me how often even the simplest things are done so sloppily.

However, as mentioned at the beginning, many of the problems and lessons above are about extended interaction: multiple visits to the site, emails between the site and the customer, and emails between individuals.  None of my interactions with the site were unusual or complex, and yet there seems to be a systematic lack of comprehension of this longer-term picture of usability.

As noted also at the beginning, this is partly because there is scant design advice on such interactions.  Norman has discussed “activity centred design“, but he still focuses on the multiple interactions within a single session with an application.  Activity theory takes a broader and longer-term view, but tends to focus more on the social and organisational context whereas the story here shows there is also a need for detailed interaction design advice.  The work I mentioned with Haliyana and Corina has been about the experiential aspects of extended interaction, but the problems on the Adobe were largely at a functional level (I never got so far as appreciating an ‘experience’ except a bad one!). So there is clearly much more work to be done here … any budding PhD students looking for a topic?

However, as with many things, once one thinks about the issue, some strategies for effective design start to become obvious.

So as a last lesson:

Overall Lesson: Think about extended interaction.

1. My earliest substantive work on long-term interaction was papers at HCI 1992 and 1994 on”Pace and interaction” and “Que sera sera – The problem of the future perfect in open and cooperative systems“, mostly focused on communication and work flows.  The best summative work on this strand is in a 1998  journal paper “Interaction in the Large” and a more recent book chapter “Trigger Analysis – understanding broken tasks“ [back]
2. This is of course hardly new, although neither address the particular problems here, see Nielsen’s “URL as UI” and James Gardner’s “Best Practice for Good URL Structures” for expostions of the general principle. Many sites still violate even simple design advice like W3C’s “Cool URIs don’t change“.  For example, even the BCS’ eWIC series of electronic proceedings, have URLs of the form “www.bcs.org/server.php?show=nav.10270“; it is hard to believe that “show=nav.10270″ will persist beyond the next web site upgrade [back]

I felt a little like a teenager complete with T-shirt and iPod dropped into Jurassic Park arguments that I thought had been put to bed in the 1980s suddenly resurfacing – how do you explain this white thing that makes sounds from its earphones to a caveman wearing skins?

However, I also felt a certain sympathy as I often wonder about computer science as a whole; indeed it has its own arguments in the 1960s and ’70s as to whether it was a ‘discipline’ as opposed to just an application domain for maths or electronics, or just a tool for business. Maybe one of the clinchers was the theoretical foundations of computing in the work of Church and Turing … but strangely enough at Lancaster the closest to this, the course on algorithmic complexity, is taught by a HCI person!

One of my worries in computing is that these theoretical foundations are still weak, there is black hole in the theoretical centre of computer science¹. However, these theoretical issues were certainly not what was bothering my colleague. To answer his challenge and my own worries about the discipline we really need to know – what is computing?

Fundamentals: algorithmics and systemics

One way to ‘carve up’ computing is in terms of algorithmics and systemics².

Algorithmics – the way computational devices behave individually and largely internally to achieve particular input/output behaviours.

Systemics – the way computational devices fit together in systems with their environments, in order to achieve external purposes.

When a computer scientist thinks of the ‘core’ of computing, it is the algorithmic side that springs most readily to mind and this is certainly the principle focus of more theoretical computer science. However, when Peter Denning suggests seven categories for fundamental principles of computing: computation, communication, coordination, recollection, automation, evaluation and design; it is notable that only two, computation and recollection, fall relatively soundly under algorithmics³.

Indeed, the topics and sub-disciplines of computing address different aspects of both algorithmics and systemics. Some topics are almost entirely about algorithmics: programming languages (theory and practice), compilation, data structures and algorithms, and algorithmic complexity. Other topics, notably software engineering and human-computer interaction are focused most strongly on systemics. Most topics incorporate aspects of both: for example most courses on databases consider both the context in which databases work and the way in which they connect to code (systemics), but also the data structures and algorithms used to achieve this behaviour (algorithmics); and in my own HCI courses I cover both the more external human design issues and algorithmic and architectural issues of interactive systems⁴.

So, while issues of systemics underlie the majority of modern computer science, it is still algorithmics alone that comprises our caricature of the subject. Systemics is like the Cinderella of the discipline who does all the work but gets none of the limelight.

Taking systemics seriously

Apart from being the grist for bar table discussions of computing does this matter?

It certainly seems to influence what we regard as basics of computing for first year computing students.

When I was in previous departments that had both ‘computer science’ and business computing students, the former were taught Java and the later Visual Basic. VB was regarded as a somewhat Noddy language in particular as it was poor in data structures and so less suitable for fundamentals of real programming such as arrays and iteration (interestingly both fine in VB!). What interested me was that students doing VB started out with event-based programming as the ‘easy’ way into programming with VB is to construct a GUI using visual tools and then add behaviours. In contrast, for those doing Java this would have been an ‘advanced’ topic they did when they eventually got on to GUI programming, or maybe never.

Event-based programming is core when you think systemics – that the computer program you are writing is part of a larger whole, but seems peripheral to a more narrow algorithmic focus. Of course, it is not just graphical user interfaces where event-based programming is core, bur also any sort of distributed, networked or embedded programming and not least web computing both at the server-end with transactional code and now at the client-end also with AJAX. Absolutely central to so many aspects of computing but often an ‘optional extra’ in our teaching

At a theoretical level Wegner has been vocal in advocating that an adequate account of theoretical computing has to take into account interaction with the environment.⁵ Personally, I don’t buy all his arguments, but the crucial message is clearly true: computational devices do not simply take an input and produce (eventually) an output, bur are in fact processes involving their own state and interacting with their environment: input and output are in fact sequences not singular occurrences⁶.

Systemics also forces you to take seriously embodied computation both in the theoretical sense that I have considered myself⁷ and also in the practical sense that computational devices are physically in the world as well as interacting with it and so we need to take this into account. For example, issues of power consumption were central to the One Laptop per Child project as they are in ubiquitous and mobile computing.

With the exceptions of space and time complexity algorithmics focuses us on functional properties whereas systemics connects more closely to non-functional properties. Interestingly all the problems I cited in my recent blog ‘”I just wanted to print a file” are about systemics

1. This demands a discussion of its own, but the basic problem is that while Church and Turing gave us understanding of disembodied computation, we still do not have clear understanding of generic computation when embodied in devices in general only particular architectures. [back]
2. Perhaps I am still being too narrow in this distinction. Arguably there ought to be a heading pragmatics: how we understand and manage the processes external to the computational system, those that give rise to it (e.g. requirements), and those that sustain it (e.g. maintenance, testing, documentation). However, for the time being I’ll lump these under the systemic label. [back]
3. The principles are listed at Denning, P. J. 2007. Computing is a natural science. Comm. ACM 50, 7 (Jul. 2007), 13-18. DOI= http://doi.acm.org/10.1145/1272516.1272529. They are part of Denning’s programme to develop “Great Principles of Computing“. [back]
4. In fact, Lancaster Computing prides itself on its systems orientation and this is reflected in areas of expertise that are strongly focused on systemics: networking, distributed systems, software engineering, HCI, embedded systems. [back]
5. Wegner, P. 1997. Why interaction is more powerful than algorithms. Comm. ACM 40, 5 (May. 1997), 80-91. DOI= http://doi.acm.org/10.1145/253769.253801, see also Peter Wegner’s home page and Dina Goldin’s papers on Interactive Computation [back]
6. In Wegner and Goldin’s work IO are strictly sequences, not time series – they assume synchronised stepwise processing. As an aside it is interesting to think more widely about time in computing. Time is taken into account in various areas notably algorithmic complexity and (naturally) real-time computing. However, the central notion of computability in Church and Turing ignores time so long as it is finite. [back]
7. See “matterealities and the physical embodiment of code” and my notes on embodied computation. [back]

I was pointed to a blog entry about a presentation that the blog said was “Simply the best presentation I’VE EVER SEEN!“. I was intrigued and and followed this to the Identity2.0 site and in particular a page about a keynote at OSCON 2005.

The entry about the talk mentioned ‘Identity2.0′ and ‘digital identity’ so guessed this was something to do with single logins (like MS passport) or open authentication, which has long been an open issue (with many ‘solutions’ but so far little success). However, was this person and this site talking about one of these such as plain open authentication, or something deeper.

Well it is fine for the page about the talk not to say clearly, it is written within the context of the Indetity2.0 site, so I looked for an ‘about’ link or something like that … nothing I stripped the url back to plain identity2.0.com and of course simply got to a stabdard blog front page (I guess rather like this one), with the latest news, but nothing to gove over context or background.

In fact by chasing yet more links to other sites, by half guessing from various abstracts, blog entries, etc. I managed to pick out half a story about what this was about … but why so hard?

This reminds me of the problem I recorded a month or so back when trying to find last week’s (as opposed to yesterday’s) news. Really easy to find the latest item or even the hotest item, but really bad at getting to the background that gives context and turns buzz words into meaning.

At the risk of sounding like a codger at a cafe table, the same is true of much software documentation. If you have seen the software grow and develop over the years it makes sense, but to students trying to make sense of Java packages, AJAX, Mac/Windows APIs, it is like fumbling in the dark. Good signpoosting at every street corner, but no roadmaps.

In all these cases there are real questions we want to ask, this is not like meandering around Flickr or YouTube, travelling just for the journey. However definitive statements (I’ll not say answers) give way to half-overheard conversations in a coffee shop.

It is often said that experts know more and more about less and less untul eventually they know everything about nothing. It seems we are turning into a generation who know less and less about more and more until we know nothing about everthing – omingnorance rules.