Suburban Birmingham- Designing Accessible Cultural History using Multi-touch Tables

The Suburban Birmingham project aimed to allow the exploration of a collection of resources originally presented through a website on a touch table. In this paper we will explore some of the issues illustrated by this project involving the manipulation and sharing of resources on multi-user applications in public spaces, including ownership, affordances, and managing and interpreting gestures in different contexts.


INTRODUCTION
The AHRC-funded "Suburban Birmingham" project is a collection of images and essays concerning the suburbs of Birmingham between 1880 and 1960.While the content is available through a website (http://www.suburbanbirmingham.org.uk)The follow-on "Hands On" project aimed to make it accessible through a multi-touch application to be deployed on a 52" touch screen to be placed in the Cadbury Research Library display area at University of Birmingham, in Birmingham Central Library, and in the new 'Birmingham History Galleries' at Birmingham Museums and Art Gallery.Developing this application highlighted some of the issues of presenting content to a broad, nonspecialist audience through a multi-user, multitouch interface in a casual setting.We discuss some of these problems and some novel approaches towards solving them.This paper presents a design-oriented case study, exploring the potential solutions to identified issues in this area.

RELATED WORK
The use of technologies, especially mobile and multi-touch, to present and engage users in museum and gallery content is not new.Reported work in this field can often focus on the technological infrastructure (Oppermann & Specht 1999;Lonsdale et al. 2004;Kusunoki et al. 2002;Grinter et al. 2002) or the user experience in the museum (Zancanaro et al. 2003;Hsi 2003;Hsi 2002), and there has been seminal work on multitouch in this space too, e.g.Hornecker highlights the issues of real users interacting with such devices in their natural netting, and discusses the design challenges arising from this (Hornecker 2008).
Our work takes a similar approach, exploring the design space around natural interactions with content, but we motivate it from the design perpsective, not from a field study like Hornecker.

THE HANDS-ON PROJECT
The Hands-On project extends the existing Suburban Birmingham collection onto the touch screen.The resources consisted of tuples of high resolution images and accompanying text descriptions, grouped under 6 subheadings with 20 content pairs each.This project was a design and development brief, and so we were restricted to utilising the existing content, and were unable to create any additional materials.The application was developed using Microsoft's WPF framework, and was designed to be placed in a museum setting for general public use.The concept was one of walk-up and use, so no instructions were to be provided to users.
Thus the fundamental principle is to utilise natural gestures and build on people's intuition as to how to use the display.It must also respond appropriately to multi-touch and multiple users, and needs to work in the museum setting.

DESIGN
The approach taken to design was not the usual user-centred or participatory design approach.Whilst these may well have developed some interesting concepts, we were constrained to developing the interface with minimal interaction with potential users.The design team consisted of a graphic designer, a developer used to multi-touch and interactive systems design and development, with previous museum experience, a representative from the museum and digital cultural learning sector, and an HCI specialist/designer.An expert design approach was taken, with concepts sketched and developed, discussed, debated and refined by the team, and then demonstrated at intermediate meetings with stakeholders, predominately museum and content specialists.This allowed for a reasonably broad exploration of the space with minimal time drift, though we would have liked to be able to trial more concepts with users along the way.The fundamental design concept that the project is based on is a scatterview.Scatterviews are essentially content containers that allow individual items to be dragged, rotated, flicked, and manipulated or arranged in the same sort of way one might arrange a set of Polaroid pictures on a tabletop.Unusually for multi-touch applications, the Suburban Birmingham project was heavily themed, giving it a unique look and feel that reflected the nature of the content.Although this made the application much more visually engaging, it also raised some usability issues as we shall see later.The issues illustrated by this project can be grouped under 3 main headings: navigation, usability and affordances, and ownership and sharing with multiple independent users.We will also briefly discuss some issues arising from the public space context in which the application will be used.

Navigation
A first challenge is how to make a relatively large number of resources or content items quickly accessible without using a more traditional approach to navigation, which is less useful in this context partly because the content has a rather flat structure.The interaction metaphors and affordances that multi-touch interfaces support are not a good match for applications or domains requiring navigation in the same sense as websites; the use of a large multi-touch interface does not lend itself well to reproducing regular websites-rather, it suggests a different metaphor for interaction and navigation closer to arranging items on a desk.In this context, we need to provide a way for users to browse the content in some sort of structured way without filling the screen with an overwhelming choice of content items.Essentially, we took the decision to use much of the screen estate to provide some insights into the potential content inside the many themes, in a strongly visual manner, and tried to design a metaphor that would encourage people to try and interact with the surface.
Our approach was to provide a single point of entry to allow the user to choose one of the 6 themes from a central hub or wheel.Each theme has a compact, easily interpreted circular gallery containing thumbnails of each of the images in that theme.Each thumbnail serves as a link to the full sized image, which in turn contains a link to the accompanying text.This wheel is designed to be read from any angle, and uses subtle colour coding cures that are continued through each of the themes.The colour palette was chosen to be restful, of related but distinct hues, and aimed to create a feeling of age and nostalgia through the use of the sepia-related tones.Rather than using icons for the areas, more concrete images were used.This is because we are not expecting multiple return use of the system where faster recognition of areas would be beneficial -instead we are focussing on creating a visual experience that draws the user in through intriguing excerpts of images and glimpses into the underlying material.This central initial wheel is shown in Figure 1.Touching one of the slices of the pie highlights it, and dragging it creates a circular gallery for that theme.petals in the 'flower' is a tab that serves to both display the name of the gallery theme and also allow it to be moved around (see Figure 2).This is important because we need to be able to distinguish between drag gestures intended to select some content, and gestures intended to move the gallery as a whole.Selecting a thumbnail initially causes it to become larger and more prominent, as shown on the right side of Figure 2.This also brings up an arrow cue to indicate that the item can be dragged out of the gallery.It is worth noting that once an item is selected from the gallery it is not removed -it is still available for another user to select.As the user moves their finger around the circular gallery, the card under their finger is slid out slightly, made larger, and the surrounding cards moved slightly to one sidethese set of animations collectively make for a dynamic but spatially constrained visualisation of the underlying content, and is attractive and playful, encouraging the user to simply move their finger around on the flower to see the effect and to preview the content.Encouraging this playing with the interface was one of the driving features of the design and implementation, since we want people to engage with it without encouragement or instruction.

Image Viewer
Images can be dragged out of the gallery and dropped onto the scatterview, where they are replaced with an image viewer.Once a thumbnail has been dragged from the gallery and dropped on the scatterview, we open an image viewer control (Figure 3) to allow the user to explore the image in more detail.
Multiple images can be open at any time, allowing users to compare content, and allowing multiple users to use the screen at once.Image viewers can be rotated to any angle and resized, using the gestures now common on multi-touch mobile devices -two fingers placed on the surface and then rotated turns the underlying content much as if it were a piece of paper on the surface; two points pinched together shrinks the image viewer, and two touch points moved apart expands it.

Text Viewer
From the image viewer control, users can use the 'Read more' button to bring up the text offering historical information about the image.This text is displayed in a text viewer as shown in Figure 4.
The text viewer allows users to scroll through the text by either dragging the text itself up or down, or by using the slider or buttons to the right.

Figure 4: Text viewer control
Using these three controls the user can quickly and easily select content and manage what would otherwise be a daunting amount of choice.

Ownership and sharing
As the application is to be deployed in a public space, we want to support use by unrelated or noncollaborating individuals.For instance, two solo visitors should be able to use it at the same time in relative independence.This means they should both have access to all the resources at the same time, and one should not be able to 'hog' the application at the expense of the other.To this end we limited the size to which items can be scaled, to prevent users filling the whole screen with single items.However this introduced new modes of operation and usability issues (particularly with viewing large images) that we will expand on in the next section.
At the same time we want users to have some sort of ownership of their experience, and the items of content they are currently viewing.The tabletop metaphor implicitly employed by a multi-touch application supports this to a certain extent, as there is an element of the extension of personal space involved that people will normally respect.At the same time, there is nothing to stop a user reaching over and interacting with content that 'belongs' to another user.However, this is not so much a weakness as a different facet of the table's strengths.The point of using one is partly to get away from a traditional, session-based experience: One way we tried to reduce conflict without prohibiting this form of collaboration was to allow more than one instance of a given piece of content to be available on the surface: selecting and exploring an item of content did not lock that or remove it from the flower-based index.
We also need to make sure that key resources such as the home hub are visible and available at all times, without violating good design practice by (for example) having elements that move without the users' influence.Our approach here was to keep the central hub always on top, fixed in the centre of the screen.Visually this was sometimes suboptimal, as material tended to have to be arranged around this, but it did tend to facilitate the use of one side or the other of it, and so leave space for new users to walk up to and be able to use.Obviously there are other factors to considerthere is a natural reluctance for users to start interacting with the screen if somebody else is stood in front of it, although this would perhaps change with the size of the screen -the larger it is, the more inclined people might be to begin interacting with it.

'Walk up Usability'
The target users will be casual, and will likely have a range of previous exposure to this kind of technology and interaction.We needed to try and ensure that the operation of the application is as simple and intuitive as possible, and no training is needed-people should be able to simply walk up and start using it.To aid this, we limited gestures to a very small subset: dragging, pinching and zooming, and tapping.Anyone who has used a smartphone will find these familiar, and anyone who has not should find them easy to pick up.
In addition, we wanted the table to continue to work when children were playing with it, and so we designed the selection actions to be relatively specific -selecting and then dragging a slice from the centre, or touching and extracting a petal from the flower -or card from a pack, depending on the metaphor you prefer -required that the selection and then the drag had to be made without lifting the finger, and that the item had to be moved far enough out to 'extract' it -insufficient movement saw it glide back to its previous position.This means that, in general usage, children running their fingers around on the surface do not send it into paroxysms of animated activity: some elements may be activated, but in general it responds well to random activations.

Pan zoom functionality
To stop users 'hogging' the display by zooming an image in to a very large size we limited the point to which the image viewer control could be scaled.However, we still needed the user to be able to zoom the image in to its highest level of resolution.
To get around this we developed a novel custom control to allow users to pan and zoom within the image viewer, while still being able to move it around the scatterview.The control displays a bordered image with a tab containing some buttons underneath.The control is moved and scaled the same way as regular scatterview items, by dragging and pinching-zooming gestures.The controls bar does not scale with the image and remains anchored at the bottom right of the image.However, as we did not want a user to be able to fill the whole screen with a zoomed image, we limited the maximum size of the host scatterview item.When the zoom reaches this limit, the control stops getting larger but zoom continues within it.The zoom is centred on the manipulation origin.
However, we now have two conflicting requirements: We want users to be able to move the viewer around while the image is zoomed in, but also to be able to pan the image -that is, move it within the 'window' provided by the scatterview item.Both of these use the same dragging gesture, so we need some way of determining which behaviour is appropriate for a particular gesturethat is, whether to move the whole viewer or pan the image within it.
The image takes up the vast majority of space in the control, with the border and control tab taking up only a small part.Gestures on these elements could still be used to move the control, with gestures on the image used to pan.However they are too small for this to be practical.Another option would be to have a wider tab, perhaps with some visual cue such as texture to indicate a dragging affordance.This we felt to be quite visually intrusive because it takes up a lot of space when the control is not in pan-zoom mode.The same is true for simply having thicker borders.Another approach we considered was to change these properties dynamically -introducing a wider border or tab when needed -but this is not good user experience design practice and would influence things outside of the control's borders.
Our final approach was to add some semitransparent bars on the inside of the control, effectively extending the left and right borders inwards over the image and thus increasing the area the user has available to drag the whole control by.The bars appear when the control reaches its maximum size and switches to panzoom mode.When the image is scaled back down to this maximum size the control switches back to regular mode, the bars disappear, and the whole control scales as before.(There is also a minimum size for the image, mainly to ensure that its width does not become less than the width of the controls bar.) Figure 5 shows the image viewer in pan zoom mode, with the drag bars visible to the sides.
It was also important to make sure that the same functionality is available to all users, including those who may perhaps be unable to pinch and zoom owing to a lack of manual dexterity, or who are unfamiliar with the gestures required.To this end zoom buttons were included on the controls bar, as well as close and email buttons.These buttons zoom in steps, and zoom is carried out in the centre of the image window; that is, the centre of the visible part of the image.
In pan-zoom mode we also set a limit on the extent to which the images could be zoomed, to prevent pixelation occurring.We also allowed two instances of the same image to be displayed to allow comparison between images at different levels of zoom.If the user tries to open a third instance, one of the existing ones is highlighted.

Affordances and visual cues
To support 'walk-up usability' we included some visual cues to indicate affordances-for example, a textured surface on elements to indicate that they could be dragged, as shown in Figure 6.
Button symbols were kept as universal as possiblefor example, close, email, zoom in and out, and information.The email button was specifically required by the curators of the material -they wanted to encourage additional interaction with the material through email post-visit, and so this allows the visitor to send a copy of the image their email account, as touching it opens an on-screen keyboard (part of which is shown in Figure 6.) Button symbols were kept as universal as possiblefor example, close, email, zoom in and out, and information.
The email button was specifically required by the curators of the material -they wanted to encourage additional interaction with the material through email post-visit, and so this allows the visitor to to send a copy of the image their email account, as touching it opens an on-screen keyboard (part of which is shown in Figure 6.)

MUSEUM CONSIDERATIONS
As the application is to be deployed in a museum we had to consider some additional behaviour, to ensure that users would be encouraged to interact with it in the first place, and to ensure that it was ready to use for the next users.We cannot expect that users will close all of the items they have open when they have finished -more likely they will simply walk away and leave it.We took two related approaches to this problem.All of the elements on screen apart from the home hub fade out over a period of two minutes.If they are touched during this time they return to full opacity.If they reach zero opacity they are removed from the scatterview.This is partly to manage performance and partly to keep down the number of items on the screen.If this number reaches a preset limit, the bottom-most item is removed for each new one that is added.

Reset timer
At the same time, a timer tracks period of inactivity.
If no interactions at all have occurred in 2 minutes, a dialog appears asking the user if they want to continue, with a 20 second countdown.If they do not respond all the items are removed and the application returns to its starting state.If they do respond the timer is reset.

Screensaver
If the application is unused for a few minutes a screensaver begins, which shows the home hub and a simple graphic asking the user to 'touch to begin'.
These simple housekeeping tasks are essential for the system to continue to function in the varied conditions of museum interaction.We cannot be sure whether visitors will watch others using the display and learn that way, or will be alone and need subtle direction and encouragement to explore, or will be part of a group wanting to share and compare information: the display has to be in an accessible understandable state when they walk up to it, and should encourage exploration, collaboration and comparison.
Figure 7 shows am image of the final display, used by two users both on the same side of the screen.

DISCUSSION
Ideally we would have undertaken a full evaluation of the system with many users, but both time constraints and a concern about artificial metrics of usability that actually demonstrate nothing useful meant that this did not happen.This is therefore presented as a design case study.
Through observing users playing with the interface, we can conclude that the gentle animations are very effective in delivering an interface that encourages exploration, and it is aesthetically pleasing.The flower approach with the petals appears to work exceptionally well, providing both the ability to quickly scan the content and briefly preview it, as well as acting as a clear selection mechanism for n-depth engagement.Users had no issues with the gestures to be used, though slightly older ones tended to use the buttons for zooming, in some cases.The housekeeping ensures that it returns to a suitable state for museum use.Aspects of the design can no doubt be improved, but we intend to observe the display in situ and discuss it with users before refining it further.The table has not yet been installed in the final museum setting, and so we have not had the opportunity to evaluate how well it supports collaboration and suchlike, and this is will be the subject of further work.
On reflection, we find that the mixture of 'expert' design, with input from both graphic and HCI experts, coupled with feedback from domain experts on a regular basis, seemed to work well.It provided a mixture of necessary requirements (e.g.email, QR codes, and housekeeping) with innovation and creativity (e.g. the animated flower) which we do not expect would have come from a strongly user-centred approach.

Development of the Suburban Birmingham: Hands
On multi-touch solution was funded by using AHRC follow-up funding for the AHRC project Suburban Birmingham: Spaces andPlaces, 1880-1960.All graphics designed by Brigitte Winsor (www.brigittewinsor.com)

Figure 1 :Figure 2 :Figure 3 :
Figure 1: Initial navigation element, showing the six areas of content.4.1.1.Circular GalleryA gallery that shows each image like a petal in a flower accesses each of the 6 themes.One of the

Figure 5 :
Figure 5: Image viewer in pan-zoom mode.The drag bars are shown as the greyer overlays to the left and right of the image.

Figure 7 :
Figure 7: The Suburban Birmingham Hands On interface