System metaphor for eLivingCampus

Our software engineering class is working to develop the “Living Campus Information Infrastructure” . We’re working towards a project proposal at the end of the first iteration, focussing at the moment on the business opportunity. While most groups moved quite quickly to an information system to support a garden (ie signs, irrigation systems), some are starting to see the bigger picture of computing’s potential to support a larger sustainability initiative.

One of the key tools in the first iteration is the system metaphor. Metaphors are used in language to enliven, to encourage interpretation and to provide a vehicle for understanding when either there are no direct terms for a concept or other explanataion is cumbersome. By understanding and experiencing one thing in terms of another we can provide a means of exploring a concept even before we’ve really come to terms with what it is we’re talking about.

In software development the system metaphor has been adopted as a core practice by the agile community. Kent Beck, author of Extreme Programming Explained defines a system metaphor as:

a story that everyone – customers, programmers, and managers – can tell about how the system works. p. 179.

Wake argues that we seek a system metaphor for several reasons:

Common Vision: To enable everyone to agree on how the system works. The metaphor suggests the key structure of how the problem and the solution are perceived. This can make it easier to understand what the system is, as well as what it could be.

Shared Vocabulary: The metaphor helps suggest a common system of names for objects and the relationships between them. This can become a jargon in the best sense: a powerful, specialized, shorthand vocabulary for experts. Naming something helps give you power over it.

Generativity: The analogies of a metaphor can suggest new ideas about the system (both problems and solutions). For example, the metaphor, “Customer service is an assembly line”. This suggests the idea of a problem being handed from group to group to be worked on, but it also raises the question, “What happens when the problem gets to the end of the line – does it just fall off?” This can bring out important issues that might otherwise lurk and fester.

Architecture: The metaphor shapes the system, by identifying key objects and suggesting aspects of their interfaces. It supports the static and dynamic object models of the system.

Another benefit is Generalisability. We can use the metaphor to move between developments: “Like the lettuce project, but with more of a greywater approach” is a real sentence used in developing a new project last year.

The metaphor should be stated in simple terms. As Ryan states: “The system is a bakery” jibes better than “The system interprets text as commands and executes them against builders that produce resultant objects and attach assorted decorators, sorting them via pipes and filters to the correct bins; the user can than browse and eat them as needed.”

Choosing a metaphor takes work. We think that the process of finding a metaphor is as useful as the metaphor itself. Jefferies (2001), in an evocative description of an agent-based information retrieval system describes “this program works like a hive of bees, going out for pollen and bringing it back to the hive”. Although Jefferies doesn’t describe them, it is likely that they tried other metaphors first. Perhaps “a vacuum cleaner sucking up all knowledge?…no there’s lots of them and anyway the information is structured – not just a big dustball, well perhaps a library? no, that is big and static, what we want is something that selectively collects information, like a fleet of recycling trucks…”.

In cases where no one can think of an appropriate metaphor (with or without vivid imagery), the approach is to develop a “naive metaphor”. This means that you describe the system more literally (a student management system would have student and enrolment objects etc). The disadvantage of this is that it isn’t really a metaphor – you won’t gain any deeper understanding or insights as it is rooted in what you already know.

Metaphors work best when you give them chance to work. As soon as you start slipping back to describing characteristics of computing things (security, login in, etc), try and lift your thinking back to a more abstract metaphor. One way to do this is to think about the metaphor on steroids – what would a super x look like? You have to be careful though, you have to more specific than a “magic x”.

So, what did the system metaphor process tell us about the LivingCampus?

The groups first developed metaphors for the whole project:

* Coffee cup good content, recyclable, logos, inspirational quote,

* Encyclopedia: stores information, index, pictures, summaries, searchable, updated regularly, accurate, online and hard copy

* Living organism: dynamic, inputs/outputs, conditions, intelligent, feeding ideas,

* A road map: information organised logically according to what you need to know at a glance but also can find find detail, legend and key structure, mobile, translates well to digital (mobile GPS etc), foldable (to highlight area of interest).

* CD rack: holds lots of information, can be sorted by user, expandable, information can be sampled,

Some of these metaphors turned out to be too close to computing. The encyclopedia and the CD rack, for example, didn’t really offer much new insight – they describe any generic computer system.

Perhaps because the Living Campus itself is not something the students had encountered before, we then switched tack, and thought about metaphors for the Living Campus itself. What are the characteristics of familiar businesses (or institutions or processes) that could be used to help think about the Living Campus – then, what are the information needs of those metaphors?

* Wartime propaganda: selectively positive, well organised, sense of urgency, targeted messages, constant broadcast

* Olympics: complex network, many different needs, instantaneous integration of results and other media, tailored for and by different markets, pride, competitive, sponsors at different levels, logos embedded throughout

* Marketing a company: logo, contact details, descriptions of customers, testimonials, showcases innovation, innovation needed in getting attention, case studies

* Country Calendar (long running NZ farming TV programme): relevance to farming but most of audience not farmers, educational mixed with entertainment, narrative, further information, sponsorship, house style

* Greenpeace: headline seeking but backed by evidence, moral high ground,

* Building development: plans, consents, “what is happening here?”, engineering modelling, artists’ impressions.

* Museum: mix education and entertainment, what’s on show, categories, must be correct (though note importance of user understandings), can be boring, wayfaring, mixed audiences, changeable, house style, interactive, helpful staff

* Art gallery: (museum +), layout, elitist, events, interpretive information, database, catalogue, collection, openings, storage,

* Zoo: feeding times, breeding programme, animal and visitor behaviour management, school trip bookings, gift shops, conservation, fund raising, weather, seasonal

* A&P show: community oriented society, supported by other societies, schools involved, competitions, community participation, outdoors (some exhibit halls), weather contingency, event, showcases community, animals and plants, business stalls, something for everyone, marketing, localised but regional and national structures, unique characters, interactive, committee structures,

We have always believed that the LivingCampus is a combination of a community garden, and interactive experience and a vibrant campus. Going through this metaphor process has helped us immensely in working out what this means. Thinking about the LivingCampus is a cross between an A&P show and a museum has highlighted many characteristics that we simply hadn’t thought of.      Another example of how computing thinking can have benefits for sustainability.

References

More about our approach to the system metaphor is in this chapter in the ADF wikibook.

Jefferies, R. (2001) What is eXtreme Programming http://www.xprogramming.com/xpmag/whatisxp.htm viewed 21/7/6
Wake, W. (2000) System Metaphor http://www.xp123.com/xplor/xp0004/index.shtml viewed 21/7/6
Wake, W. (2000) Proven system metaphors http://c2.com/cgi/wiki?ProvenSystemMetaphors viewed 21/7/6
http://knowgramming.com/