Creative Crossings workshop

Some of our ambitions were:

* Investigate transformative use of space and place
* Address gaps in infrastructure: access to standards, material frameworks and technology
* Instigate a triangular network: tried and trusted network practice
* Pursue research and practice, less engineering
* Explore relationships between media, gaming, locative, mobile, visual media

Anne Galloway has posted our collaborative summaries from the workshop and my full notes are here, until they can be put on the collective server.

The discussion is continuing, and the next informal meeting of participants is happening at ISEA 2004.

h3. Some pictures
!/images/creativecrossings01.jpg(Creative Crossings workshop: Graham Harwood and Michelle Kasprzak)!
!/images/creativecrossings02.jpg(Creative Crossings workshop: Jo Walsh and Gabe Sawhney)!
!/images/creativecrossings03.jpg(Creative Crossings workshop: Rachel Baker and Tapio Makela on the 19 bus)!
!/images/creativecrossings04.jpg(Creative Crossings workshop: Tapio Makela on the 19 bus)!
!/images/creativecrossings05.jpg(Creative Crossings workshop: Finnish Ambassador’s residence, Battersea)!
!/images/creativecrossings06.jpg(Creative Crossings workshop: Finnish Ambassador’s residence, Battersea)!
!/images/creativecrossings07.jpg(Creative Crossings workshop: Finnish Ambassador’s residence, Battersea)!
!/images/creativecrossings08.jpg(Creative Crossings workshop: Finnish Ambassador’s residence, Battersea)!
!/images/creativecrossings09.jpg(Creative Crossings workshop: Finnish Ambassador’s residence, Battersea)!

Urban GPS experience

It’s possible to use the “GPS Map 60c”:http://www.garmin.com/products/gpsmap60c/ in an old “Marimekko bag”:http://www.marimekko.fi in a mobile phone pocket just small enough that the aerial sticks out. In this way it can be placed in windows of buses or cars without it sliding around, and I can walk around without looking like a geek or getting mugged.

!/images/urbangps03.gif(Rendered trail of three months walking in Oslo)!

h3. Problems

In short, GPS doesn’t work well in dense urban environments like most European cities. This is from the perspective of a pedestrian confined to the pavements (sidewalks) and public transport. From a few experiences whilst being driven around, it seems to work well in a car, probably because of the clear sky area available in the middle of the road. Inclement weather and green trees also seem to be problematic.

In these last few months, attempting to record a good quality database of tracks to geo-locate my photographs, I must have looked really odd. Face in device, stopping on street corners, stopping in the middle of street crossings and scrambling to grab the front seat of the bus. Discovering that GPS doesn’t just passively work is a great disappointment and my dataset is clouded with gaps and anomalies.

h3. Some other observations

* Fast turns when using public transport or car result in wild deviations: re-aquiring satellites is the problem
* Need a road that aligns with at least 4 satellites to get an acceptable track, anything else and the errors can accumulate
* Glass buildings can result in ‘reflections’ of position, eg jumping to other locations due to reflected signals
* I sit on the outside or front of buses: to get a wider expanse of sky area: I am constantly aware of sky cover
* The relative position of satellites is beginning to have an effect on the side of the street that I walk on
* Walking in the middle of the street: had a couple of near misses with cars – the moving map is just too engaging
* I would like an explanation of the lost track calculations: this device seems to use the last-known bearing and velocity to guess new tracks when the signal fails. This is very unreliable and problematic as it fills the map with phantom trails
* The track can be more useful over time than the (base) map: it shows my personal space and personal routes, I know where I have been and can use it to retrace routes or places. Popular routes build up in blackness and thickness. Home area becomes an abstract scatter plot of routes, but it’s very familiar
* Stored waypoints are really useful for getting large, general bearings on location: zooming out and seeing a relationship to two known landmarks can be really useful in an unknown area

!/images/urbangps04.gif(Rendered trail of two weeks walking and public transport in London)!

!/images/urbangps01.jpg(GPS receiver resting on the top deck of the number 4 bus, London)!

!/images/urbangps02.jpg(GPS receiver in the window of a train, Oslo)!

Interaction design books

Posted on Mar 19, 2004 in Adaptive design, Interaction design, Reading

Pink = highly recommended!

Information Appliances and Beyond

Eric Bergman ed. One of the best interaction design books to date. With case-studies on various design problems from Palm OS usability to Nokia contextual design issues. Just enough detail and anecdotes to get a good sense of design process.
amazon.co.uk / amazon.com

The Humane Interface

Jef Raskin. An absolutely essential book for anyone developing an interactive product. Raskin explains some excellent ideas for usable interfaces that are better suited to large file systems and the internet.
amazon.co.uk / amazon.com

Designing Visual Interfaces

Kevin Mullet, Darrell Sano. A useful book with plenty of visual examples on how to simplify and enhance desktop interfaces.
amazon.co.uk / amazon.com

Dust or Magic: Secrets of Successful Multimedia Design

Bob Hughes. Somehow forgotten, this book gives a great overview for successfully designing rich multimedia interfaces.
amazon.co.uk / amazon.com

Reinventing the Wheel

Jessica Helfand. Plotting the history and design of information wheels, those interactive tools that can tell you the cooking time of an egg to the blast radius of a nuclear bomb.
amazon.co.uk / amazon.com

The Art of Human-Computer Interface Design

Brenda Laurel ed. A collection of dated (early 80s) essays that begin to see interface as a design discipline. Complex and theoretical.
amazon.co.uk / amazon.com

Designing the User Interface

Ben Shneiderman. Really thorough book, concentrating heavily on software interface design from a programming perspective.
amazon.co.uk / amazon.com

Bringing Design to Software

Terry Winograd. A dialogue around the design process in software development.
amazon.co.uk / amazon.com

Plans and Situated Actions

Lucy A. Suchman. A new approach to interaction design using new social science models.
amazon.co.uk / amazon.com

GUI Bloopers

Jeff Johnson. A lighthearted book highlighting common interface mistakes.
amazon.co.uk / amazon.com

The Inmates Are Running the Asylum

Alan Cooper. Really good ideas to solve common interface design issues. Cooper shows that the biggest problem in interaction design is that it is controlled by the developers and programmers, and advocates the need for interaction designers at every level of software production.
amazon.co.uk / amazon.com

Apple Human Interface Guidelines: The Apple Desktop Interface

Apple Computer. The original guidelines for developing MacOS GUI interfaces. The version for MacOS X can be downloaded from apple.
amazon.co.uk / amazon.com

Adaptive design books

Posted on Mar 17, 2004 in Adaptive design, Interaction design, Reading, Research, Social

Notes on the Synthesis of Form

Christopher Alexander.
amazon.co.uk / amazon.com

The Nature of Order

Christopher Alexander.
amazon.com

The Oregon Experiment

Christopher Alexander.
amazon.co.uk / amazon.com

A Pattern Language

Christopher Alexander, Sara Ishikawa, Murray Silverstein.
amazon.co.uk / amazon.com

The Timeless Way of Building

Christopher Alexander.
amazon.co.uk / amazon.com

How Buildings Learn

Stewart Brand.
amazon.co.uk / amazon.com

Turtles, Termites, and Traffic Jams

Mitchel Resnick.
amazon.co.uk / amazon.com

Emergence: The Connected Lives of Ants, Brains, Cities, and Software

Steven Johnson.
amazon.co.uk / amazon.com

The Tipping Point

Malcolm Gladwell.
amazon.co.uk / amazon.com

Small Pieces Loosely Joined: A Unified Theory of the Web

David Weinberger.
amazon.co.uk / amazon.com

Smart Mobs: The Next Social Revolution

Howard Rheingold.
amazon.co.uk / amazon.com

The Death and Life of Great American Cities

Jane Jacobs.
amazon.co.uk / amazon.com

Adventures in Modeling: Exploring Complex, Dynamic Systems with StarLogo

Vanessa Colella, Eric Klopfer, Mitchel Resnick.
amazon.co.uk / amazon.com

A New Kind of Science

Stephen Wolfram.
amazon.co.uk / amazon.com

The Control Revolution

Andrew L. Shapiro.
amazon.co.uk / amazon.com

Society of Mind

Marvin Minsky.
amazon.co.uk / amazon.com

The Electric Meme

Robert Aunger.
amazon.co.uk / amazon.com

Life on the Screen: Identity in the Age of the Internet

Sherry Turkle.
amazon.co.uk / amazon.com

The Virtual Community

Howard Rheingold.
amazon.co.uk / amazon.com

Design for Community

Derek M. Powazek.
amazon.co.uk / amazon.com

Community Building on the Web

Amy Jo Kim.
amazon.co.uk / amazon.com

Online Communities

Jenny Preece.
amazon.co.uk / amazon.com

Design for television

David’s reference to 18 points as the minimum size equates to 18 pixels if you are coming from a web background.

On some iTV projects I have pushed the type down to 16 pixels, but be very careful about colours and contrast, and enquire about the production path to air: if the work is going to be transferred via DV tape, squeezed through an old composite link, or online-edited with high compression, then you might want to leave type as large as possible.

In some cases such as using white text on a red background you can add a very subtle black shadow to the type, which will help stop colour bleed and crawling effects. Even if you dislike drop-shadow effects, it will still look flat and lovely on a broadcast monitor.

Safe areas need to be taken with a pinch of salt. The default safe areas in most editing and compositing software date from years ago before the widespread use of modern, widescreen televisions.

Try extending the safe area for non-essential text in interactive projects, and consult broadcaster guidelines for their widescreen policies: many channels now broadcast in 14:9 to terrestrial boxes, and offer options to satellite and cable viewers.

The largest problem is that widescreen viewers often crop the top and bottom of the image by setting their TV to crop 4:3 to 16:9. Some cable/satellite companies remove the left and right of the image to crop 16:9 to 4:3 for non-widescreen viewers, leaving us only a tiny, safe rectangle in the centre of the image to work with.

Robert Bradbrook (maker of Home Road Movies) has a some technical but excellent information on designing graphics for 16:9 television and film formats, including a sample safe area.

There are also excellent documents on picture standards from the BBC.

But this is one thing I don’t understand: according to the BBC: “Additional [20 or 26 horizontal] pixels are not taken into account when calculating the aspect ratio, but without them images transferred between systems will not be the correct shape.” Can anyone confirm that this is the case for PAL images?

Design management books

Posted on Oct 13, 2003 in Adaptive design, Interaction design, Reading, Research

Mastering the Requirements Process

Suzanne Robertson, James Robertson.
amazon.co.uk / amazon.com

Software Requirements

Karl E. Wiegers.
amazon.co.uk / amazon.com

Collaborative Web Development

Jessica Burdman.
amazon.co.uk / amazon.com

Web Redesign: Workflow that Works

Kelly Goto, Emily Cotler.
amazon.co.uk / amazon.com

Rapid Application Development

Steve McConnell.
amazon.co.uk / amazon.com

Usability books

Posted on Aug 11, 2003 in Interaction design, Reading, Research, Usability

The Design of Everyday Things

Donald Norman.
amazon.co.uk / amazon.com

Things That Make Us Smart

Donald Norman.
amazon.co.uk / amazon.com

The Design of Sites: Patterns, Principles, and Processes for Crafting a Customer-Centered Web Experience

Douglas K. Van Duyne, James Landay, Jason I. Hong.
amazon.co.uk / amazon.com

User-Centred Web Design

John Cato.
amazon.co.uk / amazon.com

Contextual Design: A Customer-Centered Approach to Systems Designs

Hugh Beyer, Karen Holtzblatt.
amazon.co.uk / amazon.com

User and Task Analysis for Interface Design

Joann Hackos, Janice Redish.
amazon.co.uk / amazon.com

Shaping Web Usability: Interaction Design in Context

Albert N. Badre.
amazon.co.uk / amazon.com

Submit Now: Designing Persuasive Websites

Andrew Chak.
amazon.co.uk / amazon.com

Handheld Usability

Scott Weiss.
amazon.co.uk / amazon.com

Web Accessibility for People With Disabilities

Michael G. Paciello.
amazon.co.uk / amazon.com

Design by People for People: Essays on Usability

Russell Branaghan.
amazon.co.uk / amazon.com

Designing Web Usability

Jakob Nielsen.
amazon.co.uk / amazon.com

Usability Engineering

Jakob Neilsen.
amazon.co.uk / amazon.com

Web Site Usability

Jared M. Spool.
amazon.co.uk / amazon.com

Don’t Make Me Think!: A Common Sense Approach to Web Usability

Steve Krug.
amazon.co.uk / amazon.com

Game design books

Posted on Apr 11, 2003 in Experience design, Interaction design, Play, Reading, Research

Rules of Play : Game Design Fundamentals

Katie Salen, Eric Zimmerman.
amazon.co.uk / amazon.com

Game Design

Bob Bates.
amazon.co.uk / amazon.com

Andrew Rollings and Ernest Adams on Game Design

Andrew Rollings, Ernest Adams.
amazon.co.uk / amazon.com

Game Architecture and Design

Andrew Rollings, Dave Morris.
amazon.co.uk / amazon.com

Game On

Lucien King.
amazon.co.uk / amazon.com

RE:Play

Liz Faber.
amazon.co.uk / amazon.com

Electronic Plastic

Jaro Gielens, Robert Klanten.
amazon.co.uk / amazon.com

Trigger Happy

Steven Poole.
amazon.co.uk / amazon.com

Technical books

Posted on Dec 14, 2002 in Interaction design, Reading, Research, Technology

Designing with Web Standards

Jeffrey Zeldman.
amazon.co.uk / amazon.com

Taking Your Talent to the Web

Jeffrey Zeldman. A fantastic how-to book for designers looking to get involved in web publishing and design. Takes the reader through writing, usability, architecture and technical tips.
amazon.co.uk / amazon.com

Eric Meyer on CSS: Mastering the Language of Web Design

Eric Meyer. One of the leading proponents and practitioners of css on the web explains his ideas and techniques.
amazon.co.uk / amazon.com

Cascading Style Sheets: Separating Content from Presentation

Owen Briggs, Steve Champeon, Eric Costello, Matt Patterson
amazon.co.uk / amazon.com

Cascading Style Sheets: Designing for the Web

Håkon Wium Lie. The inventor of CSS1 explains advanced w3c standard site design techniques.
amazon.co.uk / amazon.com

Database Design for Mere Mortals

Michael J. Hernandez. High level design guidelines for designing relational databases, covering categories, fields, relationships and the end-user.
amazon.co.uk / amazon.com

Building Accessible Websites

Joe Clark. Valuable work on the techniques for improving the accessibility of online media.
amazon.co.uk / amazon.com / website

Interaction and narrative workshop

Posted on Feb 11, 2002 in Conferences, Film, Interaction design, Narrative, Television

This lecture covers some specific ideas that are aimed at traditional designers or filmmakers that want to make narratives involving user/audience interaction.

It was first given at Channel 4 in London, to filmmakers on the digital animation Mesh Scheme.

Mobile interaction design case study

Pollen Mobile develops location-based services for the consumer and business markets. Mamjam is their first product: a location based, social entertainment service based on Short Messaging Service (SMS) messages. It enables people in the same venue to chat with each other by sending text messages from their mobile phones. Mamjam interface: user match screen 1 Mamjam interface: user match screen 2

h2. Brief

Pollen approached us with a very broad intention to use SMS to drive social interaction and entertainment in new ways.

We initially developed three quirky ideas based on playground games, internet chat, and community storytelling that we presented as the basis for discovering business goals and user-needs.

After our initial brainstorm, we initiated a more rigorous user-centred, interaction design process that is detailed in this case-study.

h2. Handsets & Networks

We found several pivotal issues we needed to resolve: SMS has extremely limited functions; with few opportunities to create rich, engaging, extended interactions.

h3. Handsets

Mobile phone handsets provide no navigation between multiple messages, no indication of user status or location, and have no practical means of viewing session history. Users are accustomed to using SMS for quick functional communication, and extended contact with friends. They certainly do not rely on messages for any kind of complex interaction.

Every transaction between user and server on a mobile phone is a sessionless operation. Each message contains only the time it was sent, the number it was sent from and the content of the message [1].

Unlike http systems, the server cannot rely on location and session information being stored in the message address. This is complex from a user experience perspective because people are used to responses exhibited by systems that do carry session information and behave quite differently [2].

h3. Networks

SMS messages are managed by the networks with cells, each cell carries messages particular to that region. Cells are notoriously unreliable, and we found that it was common for messages to hang in the system for over ten minutes. This presented some serious problems. Satisfying communications rely on a high level of continuity, and the timing between messages is a critical indicator of the emotional state of your chatting partner.

Mamjam’s service is location based: users are in contact with other users in the same area. However the existing (second generation) handsets cannot determine location, and although locations are triangulated by the network, this information is not publicly available. The location thus had to be manually provided by the user; in a way that then could be usefully interpreted by the server.

Researching and developing a reliable language for users to identify their location became central to the interaction design problem.

Many competing SMS services are currently internet-based: requiring a signup for services from a web site, rather than directly from handsets.

h3. Modes

A system like this could conceivably be built without the use of modes [3]. From the users perspective a modeless system could be overly complex and exhausting: every message must somehow include exact commands and instructions for the server. But a modeless system is very attractive from a technical perspective: the server is more likely to correctly interpret instructions.

h2. Process

h3. Requirements

We consulted with Pollen and selected SMS users to draw up several personas and scenarios. This included contextual enquiry, business goals and user-requirements gathering. We identified the following requirements:

* Users must be able to join the service immediately, not just from a website prior to use.
* The service should accommodate both new and returning users.
* Users are likely to be exposed to the service through all sorts of channels, and therefore signing up should accommodate all points of entry.
* The structure should be designed to accommodate expansion of the service.
* The basic structure of the handshake should carry to other SMS systems Pollen may choose to develop.

h3. First Iteration

The initial interaction architecture outlines our first intentions for the system. (For legal reasons we can’t include the full size diagram.)

mamjam interaction design version 1

The system works in a similar way to internet based chat rooms, connecting users who are ‘online’ at the same time, with the extra dimension that they are in the same physical place. Mamjam supports private, one-to-one communications only: users can’t shout to groups or broadcast messages. Once a user has found a chatting partner the system simply directs the text traffic between them until one party decides to pursue some one else, or signs off.

This structure required users to enter a lot of information about themselves before they could initiate contact with one another. We felt this was valuable in order to reduce the interaction load while chatting. This also resulted from a (perhaps misguided) adherence to the ‘internet chat room’ model.

This system was implemented on Pollen’s test servers, and we organised user-testing sessions. This revealed several problems:

The sign up process was off putting. Users motivation for this product is for entertainment and social contact: they weren’t happy to tolerate a lengthy sign-up process. This architecture required four messages for a new user to sign up. In some cases the user would be spending the equivalent of a 10 minute voice-call before they had connected with someone to chat. It was clear that the service needed to offer a quick method of signing up, perhaps at the expense of more advanced features.

In trying to optimise the system for both new and advanced users; signing up for the first time required a different interaction process from signing up for a second time. There were also several different methods of identifying your location to anticipate every possible user-interaction. There were thus four or five possible entry points into the system. This caused more modal problems than anybody anticipated; the SMS server had to process language and match patterns in an almost infinite realm of possibilities.

h3. Second Iteration

It became clear that the three biggest problems for the social interaction process were:

* Aligning the systems perception of user-context with actual user-context.
* Ensuring users have an accurate perception of the system state.
* Maintaining a rich connection between users, allowing them to interpret and react to one another accurately.

This discrepancy between user perception and system perception can be referred to as ‘slippage’. Slippage is most problematic during the initial handshake when the user is most insecure about their request and about the system itself.

Text messages to and from SMS servers rarely arrive as punctually as they seem to in normal use. This meant it was possible for one of two users, both having agreed to start chatting, to reject the other on the basis that they had failed to reply to their confirmation. In fact the rejected user had replied with confirmation, but their message had been delayed. The message would then arrive with the first user who had since moved to a new part of the interaction process. Their reply could potentially interrupt another process or get lost in the system, confusing and infuriating both users. Serious slippage!

We also found, as predicted, that users did not read back through their old messages. Some phones have a very limited capacity for storing messages and no phone facilitates simple navigation of previous messages, so the current message was the only one through which we could usefully rely upon for users to react to.

mamjam interaction design version 2

The second interaction architecture was developed with the problems described above in mind. Some changes have been made to the system since, mostly around modal issues, and the commands through which users communicate with the server. Although there are still issues regarding slippage, the second iteration makes this much less of a problem. The system is basically modeless, except for the first transaction. All users (new and existing) enter the system in the same way, new users are chatting within two messages, and existing users are potentially chatting after their first message.

For an overview of the commands and interactions possible with the system look at the Mamjam How To and Advanced Features.

h2. In Use

Mamjam is now fully operational, spinning off other services based on the basic interaction architectures we designed for the initial chat service.

h3. Extended Services

In a recent, typical promotion, at the Mood Bar in Carlisle, Mamjam sent a message to people who had Mamjamed there, offering them a discounted drink if they showed their mobile at the bar. The conversion rate from message sent to offer redeemed was 30%.

h3. Building relationships, Community and Storytelling

Having heard that a large number of people were texting their ex-partners late at night; under the influence, Mamjam sent a message asking for their own dating disasters. 13% of people responded with their own story by SMS; 50% of those responding within the first hour.

These users were not given incentives like promotional offers, the call to action was not a simple generic mechanic like reply YES or NO; it was much more involved. Users were required to read and understand the message received, then conceive and craft a response to fit into 160 characters. Yet the response was high and the quality of response excellent.

h3. Stimulating usage

By reminding BT users of a free messaging offer, the objectives are to stimulate Mamjaming outside of the locations in which they first Mamjamed.

p(quote). Message: Spice up your text life for FREE! Mamjam is still FREE to receive for BT users. To chat now just reply with mamjam and your location eg MAMJAM LONDON.

7% of the database of BT users read the message, and then decided to log on to Mamjam. Between them on that day they sent 3,400 chat messages.

h3. Some usage statistics

* First time Mamjam users begin chatting by sending only 2 SMS messages.
* Users are matched with someone within 120 seconds of logging onto the service for the first time.
* The average Mamjam user sends and receives 24 SMS messages per session.
* The top 10% of users send 60 SMS per month and generate an additional 72 outbound messages. Generating an additional 18 for the network operators.
* The top 50% of users send 20 SMS per month and generate an additional 24 outbound messages, generating 6.30 of revenue for the network operator.
* Repeat usage: 30% of daily users are repeat users.

h2. Conclusions

We think that the best solution to this particular service has been found, given the limitations detailed above.

There are obvious and not-so-obvious limitations to SMS communications. The most notable limitations are the handsets continuing to rely on short messaging rather than a more advanced chat service, and the network operators inability to develop services and platforms outside of their own internal structures.

This research and product development has generated a lot of further ideas for asynchronous communication structures, and communication solutions for packet switched networks for mobile devices.

h2. Footnotes

[1] Some phones support greater functionality than others, Mamjam needed to support a broad demographic so only the most bottom-line functionality was available to us.

When sending a message from a server it can be set to “Flash” mode, causing the message to open in the users phone immediately. Some cells also support a “broadcast to cell” function, whereby a single message can be sent to all phones within that cell. This function is expensive and only available to phones on a given network. back

[2] Information transferred with HTTP is also sessionless, but browsers and servers are afforded with functionality to help them overcome modal issues, like cookies, history bars and links for example. There are other interface restrictions to consider regarding the manipulation of text like the absence of cutting and pasting for example. back

[3] The most comprehensive discussion of modes I have come across is in The Humane Interface by Jef Raskin , pp37. back

h2. References and Links

At the time of writing the Mamjam numbers are 82888 (BT/Vodafone) or 07970 158 158 (all other networks). Just send any text message to sign up and test it for yourself.

* Mamjam website
* Pollen Mobile
* Mamjam reviewed at The Guardian
* Jef Raskin ,”Modes 3-2″ The Humane Interface , 2000, pp37.

h2. Professional Credits

h3. Interaction design

Jack Schulze Adi Nachman Timo Arnall

h3. Technical Architecture

John Gillespie

h3. Information Design

Jack Schulze

Honeysphere collaborative storytelling platform

Posted on Feb 1, 2000 in Art, Interaction design, Media, Narrative, Social, Television

In 1999 a team of six (including myself and “Jack Schulze”:http://www.jackschulze.co.uk) won the London Institute Award for Innovation for a collaboration around narrative and interactive television. We researched existing web-based projects dealing with community, gaming, multi-user space, and interactive narrative.

The project aquired an extensive archive of research material and proposed a number of design patterns that could be used for future development of collaborative television software.

We presented our findings to the public at the Berlin Film Festival in February 2000.

Load More