Supporting social interaction with the – designing pervasive systems

Introduction The smartphone represents the current pinnacle of development, coupling the abilities of a phone with the additional functionalities of the PDA. In this convergence between phone and handheld computer, it is the phone that has the dominant genes – are generally closer in looks to phones than to the PDAs who functionality they have subsumed. This historical development has influenced how users tend to think of these devices, and the design of the handsets tends to reflect this. They are predominately devices, with additional computing power built in. This is clearly seen if one looks through current catalogues of phones – they range from almost only phone functionality all the way though to complex smartphones – whereas PDAs tend to be very similar; they have the same functionality, differing in computational power, but with broadly similar connectivity. With a smartphone, the primary purpose is communication, with the other functionality being a less critical consideration.

Compare this to PCs – originally developed from the larger computers that were pure calculating machines, PCs were initially desktop systems used for content creation and information storage, and it was only with the advent of the and browsers that they became stronger communication tools. Now highly capable at communication, offering systems as diverse as , web publishing, , voice over IP and so on, the combination of computing power and communication allow us to envisage pervasive environments in which we can interact with and exploit the advantages of digital systems. But it has been the advent of the smartphone that has allowed us to realize some of these visions.

If smartphones are to become successful components in pervasive systems, they must be able to support and enhance the uses that people want to put them to, and offer useful, effective functionality. Given the historical route through which smartphones have evolved, it would seem to be clear that they have to focus on supporting interaction and communication between people. In the pervasive environment, they exist in a social setting that focuses their domain on communication, and not on computation. We are not arguing that they should not undertake computation, or information storage, or other typically computing-related tasks – more that they are likely to best succeed if they do these things to augment what many see as their primary purpose, communication.

This perception has guided our research into the design of pervasive systems; smartphones currently offer us the most capable terminals for interfacing to a ubiquitous digital world, they are regarded as communication devices firstly and computers secondly, and so the systems we design and build will focus on augmenting and enhancing communication.

Our research has focused on how we can support social interaction and communication between people, since we believe that if smartphones and pervasive systems in general are to be useful and accepted, they must support these activities and enhance them. In all of our experiments, we have been keen to try and design new systems that support forms of interaction between people that are not otherwise so easy, or even possible, without the technology. This endows the systems with a degree of utility that drives their effectiveness, necessary for pervasive system usage to increase.

Social interactions Communication between people is a core feature of human life, and we have been interested in understanding how we can support this with smartphones and other pervasive technologies. We have been looking at a range of social interactions, and this paper describes the design of a number of systems each of which examines one approach to augmenting social communication.

We can produce a shorthand notation for these interactions, loosely based on the number of people involved. 1 represents an individual, N for a group, and ∞ for the world. We have looked at how we can support person-to-person communication, on an individual basis (1-1); person-to- group communication, in which individuals communicate with a group of others (1-N); within-group , in which a group of people share information together(N-N); and person-world (1-∞) and group-world (N-∞) communication, in which an individual or group communicates with the wider world. One of the reasons for considering all these styles of communication is to see whether we can support all these forms using the smartphone as the main user device – if we can, this collective result provides us with strong evidence that it is indeed a useful device for pervasive computing, allowing it to support a multitude of communication approaches. It is the collective effect that is important; the smartphone can hardly be said to be a truly pervasive device if it only supports one form of interaction.

We will describe the design and usage of each of these systems, and report on their acceptance or otherwise by the users, and then draw together the experiences to provide our conclusions.

If we compare the interactions we have considered, they form the table shown below – the entries in the table are the names of the systems we have developed, placed according to their instigator/recipient relationship. Since smartphones are predominantly personal devices, we would expect a bias towards individuals communicating with others (either singly or to groups or to the wider world), but we also have examples of smartphones being used to mediate group to group and group to the wider world communications. This is a feature of our focus on interaction being focused around communication, which in general requires a coherent desire to move information, and so is less likely to be instigated by an amorphous entity such as the outside world. Therefore, we see entries in all the spaces except for those instigated by the outside world – there are certainly applications in these domains, but they do not form part of our research focus.

Recepient Individual Group World Instigator Individual Bluedating IMMS SmartBlog BT communities Jokeswap, Chat Group BT share Shared space World

Bluedating (1-1) In designing an application to support interaction between individuals, we wanted to try to provide a system that would offer a new experience to people, or at least to provide them with an easier solution to an old problem. We decided to look at the features of the smartphone system, and to match them onto an interaction need that wasn’t well supported in conventional systems. The characteristics of smartphones are easily identified: they have acceptable screens with sufficient screen estate and resolution to show information (though nothing like that found in notebooks or PCs), some processing power, some memory, short-range free and (with a cost) long-range connections. Significantly, they are personal devices, with private information stores, almost always used by only one user. They are text and image compatible, and because of their size and battery life they offer permanent availability, attached to the user.

Almost all smartphones support bluetooth communication, a wireless standard which offers local (10- 100m) connectivity for free. The bluetooth protocol allows for devices to discover each other, and to exchange data, with differing levels of input from the user, and it is often used to communicate between the phone and a bluetooth headset, allowing hands-free operation of the phone, or to exchange data between the phone and a user’s PC. However, our aim was to support 1-1 interaction, so we looked for opportunities to provide new forms of support for individuals. We decided to support dating.

The rationale behind this is clear. Fining new people to date is something that appears to be increasingly difficult, especially as electronic entertainment replaces social groupings, so that it becomes more and more difficult to identify people with similar interests. There is clearly, at least within some of the user groups we were working with, a need for supporting this. The technology maps onto this well: bluetooth requires that people be in close physical proximity, and can be configured to allow information exchange without user input. Because they are personal devices, they can contain personal and private information, and so they are a clear choice for selectively sharing this with other devices.

The system was designed to allow users to enter a profile of their interests and desires, and a profile of the partner they wish to meet. This information (and only this information) is then advertised over bluetooth. The other part of the application continually searches for other profiles over bluetooth; when one is found, it is compared to the desired profile. If the two profiles match up, then both users are informed (usually though vibrating the phone discreetly) that a potential match is very nearby. The rest is up to the users…..

This system is designed to utilize the local nature of the bluetooth protocol, alerting you to people nearly who are also looking for a date. This is quite different from the internet dating approaches which work on a similar profile system, but can identify a potential partner who is many kilometers away. This means that the users have to undergo a potentially embarrassing first date, when they first get to see their prospective partner – with a more localised system, people can see who they have been matched with and decide whether to pursue it or not. It also makes use of people’s familiarity with keeping personal information on their phone, rather than asking them to adopt a new piece of technology. And by utilizing systems they already possess, and increasing their functionality, we get much closer to the dreams of pervasive computing.

The Bluedating system, as it has been termed, has been trialled with a few users around the University. Finding sufficient lonely users who had smartphones to trial the Bluedating system proved difficult (more due to a lack of smartphones than a lack of lovelorn students). We provided the system to all who wanted it, and provided a questionnaire and informal interviews with those that took it up. Reactions were very positive, on the whole. Most users had initial reservations about using such systems, though they felt similar about online services, but the fact that the system alerted them subtly, giving them a chance to observe and interact (or not) made it much more acceptable. The low numbers of users working with the system with any degree of seriousness means we cannot, as yet, report any results of statistical significance, but the positive results made us consider further ways of extending this approach to try and target a wider audience.

Bluetooth Communities We redesigned the Bluedating system to be more generic. The system we developed aims to provide the framework that will be able to run and manage multiple Bluetooth services from within a single application. This framework will allow the device to act as both client and server by both offering services that can be discovered and connected to by remote devices whilst also providing the ability to search for services offered by other devices. The framework will provide the platform on to which additional packages can be added providing new user groups offering their own specific functionalities. This will allow the application to be easily extended through the addition of new groups without the need for modification to the core framework.

This was achieved by separating the application into three main layers. The bottom layer represents the core framework that provides the basic shared functionality required throughout the application and the platform onto which the rest of the application is built. The framework is designed to be completely independent of the sub-applications built on top of it. This allows new services to be added through the addition of new sub-applications without making any changes to the core framework itself. However, in order to integrate the new services into the rest of the application another layer is required. This integration layer sits between the framework layer and the top sub-application layer, and is comprised of a series of controller and processing classes. All of the modifications required to add a new service to the application are carried out within this integration layer.

Because of the short range nature of Bluetooth and the portability of mobile phones Bluetooth connections between mobile phones are usually ad hoc in nature and would therefore not be suitable for passing on critical information as its delivery could not be assured. However, in social situations where the transmission of information is less critical, Bluetooth-enabled mobile phones present an ideal way to pass on location and user specific information between devices. This meant that the problems of phones moving in and out of (Bluetooth) range of each other and the resulting unpredictable connections between devices is not such a critical factor in developing a Bluetooth application intended for use within a social context.

When designing applications for mobile devices, in this case smartphones, there are a number of additional design considerations that need to be taken into account. The limited processing power and memory available means that there are more constraints on the kinds of applications that can be run and the things they can do when compared to applications developed for more powerful platforms such as PCs. In order to make the most efficient use of the available resources, the design of programs should be approached in a slightly different way to application design for other platforms where resource limitations are not so much of a factor. For example, to minimize the heap memory usage of a program, the creation of new objects should be kept to a minimum. One way to do this is to reduce the number of program classes and to reuse objects wherever possible. This approach does however conflict with the philosophy of object-orientated design which promotes the creation of separate classes to represent distinct things and deal with distinct operations. When designing mobile phone applications it is good practice to combine classes where appropriate to reduce the total number of classes and thereby reduce the number of objects created. The final size of the program is another important consideration. Mobile devices usually have a strictly limited storage capacity and so the size of the program should be kept to a minimum to use up as little of the available memory as possible. Smaller programs are also quicker to download, and this is a particularly significant factor if the application is to be distributed via a GSM or WAP network. The size of a program can be minimized in a number of ways; these include limiting the size of any resources used, such as icons or sound files, and compressing them wherever possible. Another recommended way to reduce the overall program size is to use an obfuscator, which removes all unnecessary information from the class files resulting in a smaller file size.

The design of the BTCommunities (as the system is called) user interface followed the style outlined in the Series 60 UI Style Guide v1.0[1] produced by Nokia. This document provides guidelines for the design of application user interfaces targeted at the Series 60 phone platform. These guidelines are used to establish a number of standard practices to make application interfaces intuitive, easy to use and to provide a level of consistency between different applications. This is achieved in a number of ways; one example is through the use of the left and right soft keys (the keys directly under the phone display that are dynamically labeled by text at the bottom left and right of the screen). Typically the left soft key should be used for positive commands such as confirm, options, save, select etc. The right soft key should be used for negative commands such as exit, cancel, back, close etc. BTCommunities provided a simple menu driven interface which allowed users to easily navigate through the application. In accordance with the design principles outlined in the Nokia guidelines, the menus were designed to be broad rather than deep so that users would not get lost in layers of sub-menus. Because a search could take a long time to complete, depending on the number of devices and services involved (a single device inquiry and service search typically takes around 11 seconds to complete), status screens showing activity were provided to the user, and they were also provided with a way to cancel the operation. To allow the user interface to remain responsive at all times, any lengthy or blocking operations were carried out in a separate thread from the main system thread and user interface threads. This prevented operations from hogging the system thread and causing the application to become unresponsive. This technique was used in a number of situations throughout the application such as searches and running services, both of which can be lengthy operations which could have caused the rest of the program, including the user interface, to freeze until they had completed.

One application built on top of this framework was JokeSwap, which allowed people to exchange jokes over bluetooth. If you had a joke in your joke store, the system would offer it up to other devices. Those detecting this offer would examine their jokestore to see if they already had the joke, would check your profile to see if it was the sort of joke you liked, and if so would accept it, and try to offer one back in exchange. This form of informal information exchange was focused on supporting local community building. Mutual information sharing is recognized as part of the glue that binds a community together, and hence the sharing of jokes and other informal information is an integral part of supporting social systems.

The Bluedating system was rebuilt on top of BTCommunities, and we also provided a Chat facility, much like Instant Messenger, but local. This chat system has had extensive use, especially by students in lectures, we have noticed. BT Share (N-N) The relative success of using bluetooth to support individuals led us to consider how we could extend the approach to allow groups to work together more effectively. We wanted to provide a system that focused on supporting groups of people working together, but still utilized the notions of localised connectivity. In addition, we wanted to take more advantage of the uses that we observed smartphones being put to. Many users were storing documents, data, videos and photographs on their phones, and sharing them with each other, and we wanted to create a system to enhance this sharing of information.

BT Share implements a peer-to-peer filesharing system, in which a user identifies a filestore on their phone as being public and open for sharing with the group, and then the system negotiates security protocols and locking mechanisms, allowing other authorized users to share any information that is laced in the public store. Documents can be edited and moved from person to person; music can be shared; information can be accessed, modified, and spread through the group, without any need for a centralized server or explicit communication between members. As they pass each other in everyday life, their phones exchange and share relevant information.

This system is very similar to the peer-to-peer systems such as Kazaa[2] common on PCs and the internet, in terms of architecture and usage. It offers a transparent sharing mechanism, which does not involve the user in complex dialogue, but simply allows them to work with shared documents and multimedia in a simple manner. Because it is based around the bluetooth protocol, it requires that people are nearby for information to be exchanged, and so it encourages them to interact face to face as well. Informal observation has showed us that the simple sharing mechanisms encourage users to make available images and content that they would otherwise not send explicitly to someone, and when these are picked up by a colleague it provides a topic of conversation and so encourages and enhances inter-personal communications. It therefore encourages and reinforces internal group relationships, thereby achieving our goal of supporting groups and their interactions. Shared Space (N-∞) The next system we designed was aimed at supporting wider group communication. We have noticed that, within the school, the social area outside the labs, where tables and chairs encourage people to sit and chat, and where coffee and drinks are available, the students congregate and share a lot of information, both related to work and to wider social interests as well.

Much of the durable information in that area tends to be collected on the notice boards surrounding the area, and we wanted to find more effective ways of supporting this sharing and exchange of public information, using mobile and smartphone technology. This contrasts with the BT Share system which focused on within-group information.

We designed a system that allowed any user to post messages to a shared space, which was projected into the café area. This space is a digital space but has a clear expression in its projection into the public space, providing a central locus around which interaction was expected to occur, and allowing users without smartphones or other devices to still be able to view the information and hence included in the interactions. Messages could be posted from any mobile device, and could be text or images. Based on a client-server architecture, the clients – smartphones, PDAs and laptops – could communicate either via SMS, MMS or 802.11 technologies, and send text and images to the server. The server, written in Java, collated these messages into one display image, which was then projected. Users can also view the shared space on the internet, possible on some smartphones as well as on desktop PCs, and can also see a textual view of the messages (without the location semantics) via a WML interface for less powerful smartphones. Posts to the shared space are via bluetooth or 802.11b/g technologies (using SOAP[3] and http protocols, but the details are not critical), allowing people to interact via a publicly shared space even when not physically co- located.

One of the features we noticed on the noticeboards was that the physical placement of materials had meaning: common topics tended to be clustered together, and comments on notices could be attached to the notices themselves. There is clearly semantics in the placing of information; where it goes is important, and so we reflected this in the system we produced, allowing people to place their postings in specific locations. However, the initial implementation of the system simply broke the display space into a grid and allowed the user to indicate which grid square their note should be placed in, a coarse and inflexible approach, and the user feedback was that this was inadequate. The next design should allow for fine- grained placement of notes and messages. However, one of the other issues we began to encounter was that, with anyone allowed to post messages, the display space available was soon overwhelmed with material, with small groups of users sharing information that many others were not interested in. Also, in addition to putting up new material they also wanted to comment on major postings. Some were interested in news, some on school gossip, some on sports results. We decided to create an alternative shared space, public but with a personal perspective; we focused on addressing the issues of clutter in the space as a priority, and on personalised views on small devices. Rather than providing a digital version of an existing solution, we wanted to take the good features of the conventional approach and provide an enhanced user experience by using the digital technology in an imaginative manner.

For the second approach, we used a peer-to-peer architecture, with each device in the system forming a node in the distributed digital space. Each node held the same information, and when new information was created, it was distributed between the nodes, each one passing on messages to the next (via SOAP and http protocols). This removed the need for any central server, and allowed people to view the space even when not physically located near it. Each of the messages was analyzed as it was posted via the client: this enabled us to provide summaries of the messages. A simple algorithm was adopted: each message had common words removed, with the remainder subject to a word frequency count. We then picked the most common words and identified a sentence or significant sentence fragment that contained all these words – or came as close to this as possible – and used that as the summarization. Whilst simplistic, our informal evaluations show that in the vast majority of cases, enough of the essence of a story is captured in this way. We also used Bayesian statistics to classify messages into different categories and user interests, allowing the user to develop a personal profile of the sorts of messages they most liked to see.

Two forms of display were provided: one public view utilized the projector into the communal space, and presented a news-oriented view of the data with summaries of main stories appearing on the display. Users were able to comment on particular stories; that a story had comments was flagged, and these were visible when the whole story was looked at. Personal views on the shared data presented the same material, but this time ordered by user preference (based on the Bayesian analysis). Therefore, some users would see news material as a priority, just as on the public display, whereas others may see the sports first and then the gossip. Depending on the client, more or less information would be shown. A laptop would see all the contents of the most recent messages, with the older ones summarized, whereas the smartphone client would see summaries only until the user chose to drill down into a story to read more or to comment. We also used the Bayesian filter to remove spam automatically, and extended the system by allowing the most active messages (those commented on or read in detail most often) to remain near the top of the pile, rather than being overtaken by new postings.

We also fed the system with information from newsgroups and other digital sources, providing a shared repository of material. The intention was that this would provide the raw material for gossip andsocial exchange, even if the users contributed nothing initially themselves. We termed these items the ‘coffee- room’ or ‘water-cooler’ items – the initial seeds for informal conversations that would usually take place in these locations.

Information would only remain active in the space if people viewed it, and commented on it; uninteresting or stale material would quickly disappear off the displays, and people enjoyed the shared and dynamic nature of the space. Observational studies showed us that it was used for different sorts of information exchange than the notice board that spawned the idea – rather than longer-term notices, information moved through the system over the course of a couple of days, with a few items having greater longevity as they provoked comment after comment. The system became something of a cross between a bulletin board and instant messaging, but because we limited the uploading of comments or new items to nodes only when they were in the coffee area or its close vicinity, rather than from anywhere, a community feel remained.

Integrating Situated Interaction with Mobile Awareness (1-N) We now turn our attention to supporting one to many interactions. A common problem for many learning organisations is the lack of any formal means to contact staff members rapidly without the disclosure of potentially personal information, such as mobile phone numbers. One ‘traditional’ method of interaction existing between staff and students involves the sticking of notes on office doors. A lecturer wanting to leave messages on their office doors from a remote location often requires the help of another member of staff, such as a receptionist, who might put up a note on their behalf. This method has worked for a long while, but there are intrinsic issues relating to a lack of security and privacy, and the practical problems of notes falling off doors or the lack of timeliness in posting the note.

To address these issues, a system has been designed and implemented that utilises mobile and other technologies to provide an increased level of interaction between staff and students. The primary focus was on creating a system based on the concept of ‘situated interaction’[4] in an attempt to bridge the gap that currently exists between the learner and the instructor, and to allow an increased degree of mobility and remote accessibility necessary for modern learning situations.

The system, named IMMS (Intelligent Multimedia Messaging System[5]), involves the placement of a number of display units situated on the office doors of various members of staff in the department, acting as information and messaging terminals for students. These units were iPaq’s or similar smartphone devices. Members of staff may write a message and have a picture displayed on the unit; the content displayed on the units is set by the owner of the unit via a remote access web based management system. For staff users who do not have the time or opportunity to sit down at a computer and log in to the management system, an SMS based system is available, allowing users to update their display unit content by sending a text message from their mobile phone or smartphone to the IMMS server. This may be of significant use to staff members who have a great many department based commitments, but are frequently away from the department for whatever reason. For example, the staff member can update the display to inform scheduled visitors that they will be late because they are stuck in traffic.

Student members of the department are not only able to view the image and textual message set by the owner of the unit, but are also able to send messages to the owner via the display unit interface. A student calling in to see a lecturer and finding an empty office may use the web based interface on the display unit to compose a short message and mark it urgent or non-urgent. In the case of an urgent message being composed by a department member, IMMS will either send the message via text message to the owner’s mobile phone or store the message in the management system for display next time the IMMS user logs into the system. The routing of the messages sent via the display unit depends on the configuration settings prescribed in the personal profile of the user. This intelligent routing of messages extends similar work on situated door displays by Cheverst et al[6], which had non-intelligent SMS notification.

The web-based components of the system offer configuration and message management, and also allow remote access to the information presented on the screen, allowing users on the internet to look up the status of lecturers without having to go to their door.

The system was evaluated against its design goals, meeting the main criteria for providing easy to use, current, accessible information on the door, for providing a means to manage messages from the student to the lecturer via web and/or SMS, and for the lecturer to be able to remotely manage and update the information displayed. The system was evaluated with the help of 6 students (2 computer science students with English as a first language, 2 studying computer science whose first language was not English, and 2 non-computing students, representing a cross-section of potential users). They were interviewed by questionnaire, and asked to score the system on a scale from 0 (bad) to 10 (good) the look and usability of the interface (9.33, s.d. 0.67), the content and appropriateness of the display (7.83, s.d. 0.94), and the usefulness and functionality (9.00, s.d. 0.42) of the system. With only one instantiation of the system and only six evaluations, it is not sensible to draw broad conclusions from the data, but the results indicate that all users saw value in the system, and it clearly met our goals in trying to provide a pervasive and appropriate approach for students and staff to communicate with each other.

Mobile blogging (1-∞) The next system we considered was to support one to the world interactions, and chose to investigate mobile blogging. To understand this more clearly, we need to investigate the background to blogging in general and mobile blogging in particular.

The rise of the mobile internet is a recent phenomena, where not only is internet access made easy from smartphones and other mobile devices, but also integration and coordination with internet applications is made possible through web services and other remote APIs. In addition, mobile devices in general, smartphones in particular, have expanded beyond their communication origins to the stage where they are accomplished photo and video creation tools, able to provide immediate images and text wherever the user happens to be. Coupling this with the rise of blogging, the ability to do multimedia blogging from a mobile device soon grabbed the attention of phone users. Blogging is the process of publishing a personal diary or a journal online; the resulted weblogs, for short, are simple layouts of personal posts ordered in chronological order. The main reason for the fast spread of the blogging phenomena is that it doesn’t require any prior knowledge or expertise of web development. With few clicks any internet user can create and manage their own personal web page online.

Multimedia publishing increased the appeal of blogging and created new specialized species of blogging like audio blogging and photo blogging. One of the attractive features of blogs is that it encourages a stream-of-consciousness style of reflection and writing; the immediacy and ease of publishing encourages users to commit immediate comments and ideas without long reflection. Blogging allows bloggers (people that ) to share their personal experiences rapidly and easily with their friends and other readers. Mobile blogging makes this even more immediate: instead of waiting to get home or to an internet cafe, users can immediately share their experiences. And given that we tend to like pictures and photographs, the ability to post multimedia content makes a mobile blogging client much more useful. A client mobile blogging tool could be the best shortcut between a and their weblog if it overcomes the issues faced by mobile applications; for example, unreliable and interrupted network signals; limited interface capabilities; limited processing power.

One of the characteristics of our increased connectivity is that, because it is possible for us never to be out of contact, people tend to assume that we will never be out of contact, and thus there is an increased pressure on us to be more communicative. Most of us have been running late for a meeting: it is now considered only polite to call up on your mobile to let people know you are late – there is an expectation that we should know what is happening all the time. Being late is acceptable, not letting people know you’re going to be late is not. Indeed, Nokia has recently added a presence feature into their latest phones, allowing the user to indicate their status and activity to other (selected) users, making it easier to provide this background information. The increased pressure on us to communicate is likely to be one of the characteristics driving the uptake of blogging.

Blogging systems are sophisticated engines that automate the whole process of blogging to make it a seamless process for all users. How complicated they are depends on the flexibility level they provide to bloggers. The most famous blogging system used is Movable Type[7]. Movable type gives total flexibility to users, not only in managing their blogs but also in changing their appearance and the functionalities. Most important of all, it allows embedding media objects that brought it to the top of the list of blogging systems. Blogger was the earliest blogging system[8] used but it doesn’t support media objects or categories, which explains why many users migrated to Movable Type. Blogging systems are designed to be able to interact with various client terminals to administrate the blogging process. A successful blogging system is the one that efficiently encapsulates all its functionalities in an application package interface API that can be gracefully extended by various clients.

Mobile blogging background Other researchers and companies have developed blog client applications. Mobile blogging started through sending email or SMS posts from a mobile device to a server. The server prepares the corresponding remote procedure calls for the received messages and redirects them to a blogging system. It is a three-step process but was a convenient if humble start for mobile blogging. In the same way, multimedia mobile blogging started through sending MMS or email from the phone. But the fact that the publishing process requires a mediator server that deals with the specific formats of the messages and then redirects them to the publishing system complicates what was supposed to be an easy process. Moreover, this server driven approach doesn’t give users the ability to edit or manage their blog posts or to provide any offline capabilities. Existing blogging clients are missing some important options as tradeoffs for other features in their clients. For example, Azure[9], which is a Java-based blogging client, prioritized targeting a wide set of smartphones over interface usability. Consequently, it was not possible for Azure to provide multimedia publishing. On the other hand, Nokia’s LifeBlog application[10] focused on providing a slick interface with some interesting photo editing and synchronization options on a subset of Nokia phones. However, LifeBlog doesn’t support instant online publishing; instead, it creates a local diary or gallery of annotated photos on the user’s PC which can then be uploaded – not much use if you are away from the PC for a long period of time. It only supports multimedia sharing through MMS messages or email from the phone. Azure and LifeBlog have achieved some success, but we believed them to be too inflexible and not to meet the user’s needs.

Standard approach to mobile blogging, showing 3 stage process.

SmartBlog design We undertook some user interviews in order to understand what we needed to provide. Six users (a small sample, but sufficient to identify key attributes) were interviewed via a web-based questionnaire, from the UK, the Middle East, and the US. All were active bloggers. They all (100%) felt that a decent mobile blogging system should be more than a way of just publishing cameraphone images on a website –blogs are fairly immediate and so need revising more often than finished, crafted websites hence editing and management abilities are important. They also all saw value in being able to utilize the multimedia capabilities of their phones and make their blogs more interesting to their readers. They also all felt that current approaches, involving uploading photos to a PC, manipulating them to a suitable size, and then uploading them to their blog was too fiddly. However, 4 of the 6 (67%) were concerned with the potential costs of multimedia blogging.

We therefore designed and implemented a client that targets the Symbian-based smartphone series. This series of phones have multimedia capabilities that increase the value of a blogging client for its users, and we can maximize our integration with these services on the Symbian platform. SmartBlog, the system we created, provides an easy remote management tool for weblogs since it is designed to communicate with several blogging accounts at the same time. Moreover, these accounts can be powered by heterogeneous blogging systems and the system is responsible for handling any inconsistencies. SmartBlog offers all the regular blogging options for retrieving, categorizing, publishing and editing blog posts. In addition, SmartBlog provides automated multimedia publishing. The system recognizes the type of multimedia attached, and generates the corresponding HTML needed to include the file. If the file is not audio, image or video, it will be uploaded and linked to from the post, whilst the multimedia files are included inline.

SmartBlog utilizes http protocols, and so communicates as a browser does; therefore, any type of internet connectivity makes it work. For example, the phone can connect for free through Bluetooth or PCSuite USB connection. Alternatively, a GPRS or Dialup connection can be used, for the prevailing ISP charge. For local networks, we use bluetooth or 802.11 – this offers a free, fast, and wireless connection. GPRS has established itself as a convenient and relatively cheap way of being always connected from a mobile device when not in a Bluetooth-enabled area. The system has been designed so that the active objects involved guarantee successful termination of transactions because they keep retrying until the file transfer is completed. This design approach resolves any unreliability or speed issues with GPRS, especially relevant in case of weak signal strength.

Figure 2. SmartBlog Architecture – dotted lines separate are different threads of processing

The SmartBlog architecture is shown in Figure 2. The UIQ GUI represents the application as seen by the user, and the dotted lines in the diagram show the different threads of processing. This multi-threaded approach allows the smartphone to continue to be used as a mobile phone without compromising its behaviour or performance.

Evaluation On the smartphone itself, performance is key: with processors typically running at 150 MHz or less, the least amount of processing could cause a noticeable amount of delay in the performance of the phone. All the while, the phone should be available to respond to functionalities of higher priority, like receiving a phone call. On the whole, the on-device performance of SmartBlog is impressively fast. However, there is a notable shortcoming in performance in the Base64 media encoding functionality. The process takes a considerable amount of time that could cause inconvenience for the user. The average time for a reasonably sized picture to be encoded is 90-120 seconds, which is slow compared to the average time needed to publish a post to a weblog which is in total around 50 seconds for large sized images. What compensates for such a drawback in performance is that the Base64 media encoder runs in the same thread as the XML encoder; and so doesn’t block other working threads or phone functionalities. Table 1 shows the average time for publishing a new post according to the size of the media file attached. These calculations were recorded with Bluetooth connectivity.

Attached media file size Total posting time 89 Kb 50 secs 68 Kb 45 secs 47 Kb 38 secs 37 Kb 32 secs 26 Kb 21 secs Table 1. A table showing the time for publishing a new post depending on the size of the media file attached.

Reliability One goal of any wireless application is to provide the feeling of stability and performance normally expected by users. Mobile applications are responsible for building a layer that conceals the known problems of wireless connections; for example, degradation or loss of signal when the user goes out a network covered area or in an area with high interference. Even in areas with weak signals, the application should guarantee the successful completion of transactions. The SmartBlog system uses active objects to keep trying till the transaction is finished - the http request handler doesn’t resend the whole dataset in case of signal loss, it simply continues from where it was stopped. Therefore, the application doesn’t resend the whole post, but from where it was last interrupted. Such a mechanism works perfectly with GPRS standards because in areas with weak network signals, the blogging transaction can easily take longer, but it will finish successfully and with no extra cost since the data transferred is the same. How integrated the mobile application is with its corresponding online presence depends on the flexibility of the application’s XMLRPC and the scope of supported functionalities. It is up to the developer of the online publishing system to allow full or partial integration with their application; SmartBlog offers up full integration if the online publisher allows it.

Figure 3. Three examples of user input dialogs: Settings; Create Posts; and Import Accounts

An additional advantage in favor of SmartBlog as a mobile blogging client is that the multimedia produced from the phone can be customized to fit the limit imposed by publishing systems. The normal size of a picture is far too large for most blogging systems (and for most websites or email messages as well). Discussions with users who posted images on their websites revealed that many would typically use an image editing program to drastically reduce their image sizes and qualities, retaining their acceptability for the web medium whilst dramatically reducing download times. Since SmartBlog is a mobile blogging client, designed for the purpose of publishing images, we designed it so that it would reduce the images captured to sensible sizes (all customizable) for internet display, thereby saving on connection time when publishing and download time for the users’ viewing.

During the application testing, SmartBlog proved to work extremely well within the scope of smartphone capabilities. SmartBlog makes the phenomena of blogging even more interesting and fun, and promotes the usage of the multimedia capabilities of smartphone. We found that many users did not use their cameraphones because of the poor quality (if they were going to print them out, or view them on the phone’s relatively small, low resolution screen, but when given the ability to instantly post their pictures and form their own gallery of special events online, they are more than encouraged to use them. SmartBlog also makes it possible to share voice notes or small sized video clips online for memories and for friends.

The results reported are based on the feedback of six users who participated in testing SmartBlog. The feedback was taken through an online questionnaire and few of the users were able to discuss the application in person. According to the feedback results, all users already had a blog before they participated in testing and almost all of them are regular bloggers. Also, all users showed interest in the idea of publishing multimedia from their phones to their blogs. None of the users reported problems in installing the application or in using its interface. Even though most of the users had problems setting up bluetooth connectivity, most of them (66.7%) reported that bluetooth was their favorite. Getting bluetooth to work correctly is known to cause some problems regarding connecting to the correct port seen by Nokia’s PC Suite router, but because bluetooth provides a free and fast connection to the internet, it’s not surprising that users were prepared to resolve the issues. When asked about further additions to the application, some users suggested to have the following extra options: checking new comments, editing categories and automated synchronization. However, editing categories and checking new comments are not made possible through any publishing system remote interface - we can only get and set categories but not edit them. This is an integration issue that should be taken in consideration by the developers of remote interface packages of online applications; we would like to see total flexibility allowed for remote clients to fully manipulate online applications. All users reported that it was easier for them to post multimedia from SmartBlog than from the provided online administration module. Moreover, all of them were satisfied with the performance especially because it didn’t block any other phone functionalities.

Looking to the future, SmartBlog presents a preliminary attempt to interact with wikis in the same way it communicates with blogs. Wikis are a successful emerging internet application that allows the simple creation of web content, supports remote collaboration and multiple users, and allows free (or controlled) editing of all its content. The systems interacts with wikis using the Blogger API[11] functionalities which are very limited compared to full wiki capabilities. However, with the appearance of more stable and powerful remote packages for wikis, the system could be easily extended to introduce the first complete mobile wiki.

Conclusion

Notes Pervasive systems must be useful – need to support and augment interaction by people, both by making current styles of interaction easier and by offering new approaches that are useful.

Multifunctional devices help in that they allow us to choose between a variety of different media and communication channels, but are only good if they work well in each (c.f. success of the iPod).

Expectation of such devices is also that because we can be more in contact, we should be more in contact, and hence there is a pressure to provide information about what is happening – can we assist this?

Look at person-person close range (bluedating, btcommunities, peer-to-peer filesharing) , person to group situated interaction via office door, and group to group (public space), and person to world. Draw individual lessons and overall lessons.

Advantages of smartphones: acceptable screens, some processing power, short-range free and long-range (costs) connection, personal devices, private information stores, text and image compatible, permanent availability and reception of data even if not answered.

Historically, phones were voice communication devices, and so focus is still on facilitating communication – unlike PCs which also are about content creation, editing, information access. But increase of photo and video is moving towards this type of content creation on smartphone devices.

Acknowledgements Thanks are due to the students and colleagues who assisted in the design, build and evaluation of the concepts and applications described here: Nick Stoppard, Fatma Elsyedd Mohammed, Matthew Jones, and Nickolas Pitsioras, and to the many unknown but invaluable users and students who participated in trials.

References [1] Nokia, "Series 60 UI Style Guide v1.0," Nokia, 2003. [2] S. Networks, "Kazaa." [3] W3C, "SOAP Version 1.2 Part 1: Messaging Framework http://www.w3.org/TR/soap12-part1/," M. Gudgin, M. Hadley, N. Mendelson, J.-J. Moreau, and H. F. Nielsen, Eds.: W3C, 2003. [4] N. A. Streitz, C. Röcker, T. Prante, R. Stenzel, and D. van Alphen, "Situated Interaction with Ambient Information: Facilitating Awareness and Communication in Ubiquitous Work Environments," in Tenth International Conference on Human-Computer Interaction (HCI International 2003), 2003. [5] R. Beale and M. Jones, "Integrating Situated Interaction with Mobile Awareness," in Proceedings of MLEARN, E. Murelli, G. Da Bormida, and C. Alborghetti, Eds. Odescalchi Castle, Lake Bracciano, Rome, Italy: CRATOS, 2004. [6] K. Cheverst, D. Fitton, A. Dix, and M. Rouncefield, "Exploring situated interaction with ubiquitous office door display," in Proceedings of the international workshop on 'situated interaction' at CSCW'02, 2002. [7] M. Type, "http://www.movabletype.org/," 2004. [8] Google, "http://www.blogger.com/." [9] M. Gratton, "Azure: http://web.vee.net/projects/azure/," 2004. [10] Nokia, "LifeBlog: http://www.nokia.com/nokia/0,1522,,00.html?orig=/lifeblog," 2003. [11] E. Williams, "Blogger API http://www.blogger.com/developers/api/1_docs/," Blogger, 2001.