IT Today Catalog Auerbach Publications ITKnowledgebase IT Today Archives Book Proposal Guidelines IT Today Catalog Auerbach Publications ITKnowledgebase IT Today Archives Book Proposal Guidelines
IT Today is brought to you by Auerbach Publications

IT Performance Improvement



Networking and Telecommunications

Software Engineering

Project Management


Share This Article

Free Subscription to IT Today

Powered by VerticalResponse

Implementing and Developing Cloud Computing Applications
Secure and Resilient Software Development
Product Release Planning: Methods, Tools and Applications
Enterprise-Scale Agile Software Development
Mobile Web 2.0: Developing and Delivering Services to Mobile Devices
Cyber Security Essentials
Service Delivery Platforms: Developing and Deploying Converged Multimedia Services

Designing for Mobility: User Experience as a Design Driver

Janne Pekko Kaasalainen

As mentioned earlier, user experience is a concept separate from ease of use or usability. While a system can be easy to use, it does not guarantee a positive experience for the user. For one, a system with a single button in it can be extremely easy and intuitive to use for people, but unless it fills the expectations of what it should do, it can turn out to be a failure.

Similarly, we can create interfaces that present users with multiple simple questions to fulfill their task. However, splitting a complex task into small, simple parts may make a system easy to use, but can also make it inefficient. In extreme cases, it may make the system unsuitable for actual use despite being simple. We tried to study how far we could go in making users feel pleased and happy to use our system. As such, we could not rely on ease of use alone. Furthermore, this chapter does not deal much with usability, but with concepts dealing with the subjective and hedonistic aspects in the design process.

1.6.1 Laziness and Personal Time
One of the key concepts that seems to be easily forgotten in the hands of enthusiastic developers is that the actual end users may not consider the application being developed to be the most important thing in their lives. In fact, this is unlikely to be the case, especially when dealing in the consumer domain. Thus a conflict arises. On one hand, the developers are keen to invent functionality and features that seem to make the user's life easier, but come at the cost of learning. On the other hand, users may not know what the application does when they start to use it, and have limited motivation to see the benefits it might offer.

In general, if we look at the offerings from a consumer's point of view, the world is full of offerings. Naturally, some of these are more relevant than others, depending on the user's needs and the context he or she is in. Some of these needs are basic, such as the need of food and shelter, whereas some deal with more abstract wishes. However, all of the needs can be fulfilled in multiple ways and often by multiple vendors. The user needs to choose which offering he or she will take.

In this context, the offering will be an application. Regardless of the actual monetary price, users will always make an investment when they take an application into use. Economical value is the most direct example of this, but even if the piece of software is free, there will be at least an investment of time. This time consumption consists of several factors, such as

  • Finding out about the product and obtaining it
  • Taking the product into use and learning to use it
  • Using the product
  • Moving on from the product

It is often impossible to learn and study each and every alternative available before making a decision on which offering to choose. Furthermore, as people try to compare more alternatives, the time for each individual alternative decreases. As the number of options increases, the time to give each one a fair chance diminishes.

This chapter is not about marketing, and thus the question of finding the product lies outside the scope of this writing and much of my personal work as well. This does not make these aspects any less important, but speaking of these matters will be left to the marketing experts.

The second aspect after finding out about a product is the ability to put the product into use and learn how to use it, which is of great importance as well. Once the product is found, the user needs to put it into use to determine if it will fulfill his or her expectations. All obstacles users face will increase the pay-off expectations that the application needs to deliver for the exchange of the effort the user needs to spend to learn to use it. This naturally varies, depending on the application and the user. The requirements and needs for enjoyment and fun are quite different between, for example, media applications and banking software. In any case, if the user has given the application time and effort in learning how to use it, this trade-off should be acceptable in the continued use as well.

I've tried to avoid using concepts such as usability, as that is not the only factor (or, in some cases, even the main factor) that the user is looking for. While usability is often an integral part of the balance between time spent and the returns, other factors such as enjoyment can be equally important. These factors depend on the application or other product in question. As an example, a movie can be viewed during a two-hour long train ride. The same situation arises when the user decides how he would like to spend his time and whether the movie in question meets his expectations.

An important conclusion is that the reactions and the lack of attention toward an application is not necessarily a result of users' ignorance, but a failing with the application in offering appealing benefits that justify the investment of time and effort the user has given to your work.

In a similar vein, the user should not be forced to make choices that are irrelevant to him. This is even worse if he does not understand what is asked, which is often the case when taking something new into use. However, it remains debatable what these critical questions are. My personal opinion is that the user should not initially be asked any questions that do not deal with fundamental aspects of the system or to the user's own well-being. A bad example about the opposite can be found from the initial start-up process that many mobile phones put the user through, as they ask the user to specify time and date instead of defaulting to using network time (time and date that the mobile phone can retrieve from the mobile network). Such behavior does not cause user harm, and the cases where the result is correct ought to outweigh those where it is not. On the other hand, the example application (Nokia Image Exchange) is forced to ask permission from the user to use network connections, as making any assumption could lead to direct monetary harm. As it was the only question asked from the user and because network integration is an important part of the whole concept, the question was not considered to be too obtrusive.

1.6.2 Responsiveness and Speed
A crucial aspect of creating positive user experiences seems to be speed and responsiveness of the user interface. Naturally, being fast does not guarantee positive results. However mundane and uninteresting speed optimization might be for the development, it does seem to be one of the most important show stoppers if it is found to be inadequate.

Such factors are emphasized in a mobile environment where the user's attention span is short. Typical usage situations are short waiting periods, such as waiting for the bus to arrive or killing time while waiting for a friend on a street corner. Often, the surroundings also demand concentration and create additional cognitive load, as happens while walking along the street. Not only does the user need to pay attention to the mobile device, but also to the traffic that surrounds him. Thus, it is easy to see why speed plays an important role.

However, the system does not need to be extremely fast; it only needs to be fast enough to not make the user wait. This includes both the actual performance as well as latency. In short, the system should perform so well that the user does not need to wait unless it is absolutely unavoidable (Tognazzini 2008). Once this limit is reached, the benefits to user experience start to diminish.

1.6.3 Perception Equals Reality
Reality is a curious beast, and often overrated when it comes to offering experiences. Perhaps one of the most obvious examples, filmmaking, is based solely on creating an illusion that is immersive but not real. This is especially the case with computer animation, where everything visible is created for the purpose of the production. Furthermore, in many cases, what does not show in the final image can be omitted. To create an illusion, houses can have only the front walls, the rain can come from sprinklers, and altering object positions in depth can give a false impression of size and place.

Aside from the artificial illusions, there are many other occasions where reality gives way to perception. Even everyday concepts such as colors are result of perception, and not absolute truths. This can be observed by altering the background of a solid rectangle and noticing how the perceived color changes with different color combinations.

Illusions are actually what computers are based on, only we do not call it "magic" or "illusion" but "abstractions" (Dourish 2004). Computer systems operate on electrical signals, which in turn consist of electrons moving in conducting materials. However, abstraction after another has been built to hide the physics of the machine and been replaced with various libraries and blocks of code. Finally, the user is presented with an interface that is yet another abstraction. Thus, what truly happens inside electronic gadgets is a mystery to most of us.

In a similar fashion, abstraction levels can be increased to hide technical implementation to the extent that interfaces just seem to work. Applications can, and in my personal opinion should, guess what the user would do next and prepare for it. Furthermore, it is possible to take advantage of user behavior to do things that otherwise might seem impossible given the current technology. I'll describe two scenarios that are used by the Nokia Image Exchange imaging application that relate to the aspects of responsiveness and behavioral factors.

The first of these two examples deals with the speed of the Nokia Image Exchange S60 interface. Due to technical issues in early prototypes, the speed of rendering text was not sufficiently fast enough to smoothly resize and rotate the text. This was needed to support rotation of the screen between landscape and portrait modes. Such action created a delay that forced the user to wait before he could see the comments in the new aspect ratio, but this was masked by the means of simple animation. Comments were made to fade out just before the image would be rotated and fade back in after the rotation was done. This actually took more time than simply placing them onto the image as quickly as possible, but the constant motion and the perception that the application was doing something made the situation feel more pleasant.

Similar tricks are used elsewhere, such as in Apple's iPhone. When taking an image with the built-in camera, the iPhone needs a moment to save the sensor data into the memory and create the actual image file. This moment is masked by an animated shutter that hides the resulting delay. Situations such as these are not, in fact, much different from the reasoning behind loading icons and progress bars, but concentrate more on the hedonistic aspects instead of the utilitarian ones.

The second example takes advantage of behavioral aspects and typical usage patterns. One of the driving use cases for the imaging service was to allow users to move easily and view their images on their personal computers. In practice, this operation involves transferring data from their cameras to their computers, and is often, but not always, done manually with memory card readers, over Bluetooth or by uploading to image sharing sites such as Flickr. However, mobile cameras are often used to capture surprising events of everyday life, and are mobile by nature. In such circumstances, the photographer is not likely to immediately view his or her new images on any computer, even less on his or her own. Thus, it is possible to detect newly taken images and start transferring them to an image service or to a PC without user intervention.

When the user eventually sits before a computer screen and browses the images with a Web browser, he can already see the images he or she has taken. In reality, transferring large images via limited cellular connections takes time, but in the above scenario the perception is that there is no wasted time and effort. While the idea of creating illusions sounds alluring, the problem with abstractions comes when the illusions break for one reason or another (Dourish 2004).

The software can have programming errors or, in the case of networking applications, the network itself may be unusable or unavailable for unknown reasons. In fact, all sorts of reasons can cause the user to run into error situations. The more the number of layers, abstractions, and illusions, the higher the chance that some of them fail.

The errors themselves are not too big an issue. The real issue is that a carefully crafted illusion may have disconnected the user from the events that happens underneath the hood of the application. As a result, the reason for the error may be incomprehensible and may not make any sense. Some of these problems may be alleviated by careful explanations of the situation and ways to recover from it.

Furthermore, the error situations may not be solely technical, but also social. For example, it would be possible to create a communication system that would combine the usage of phone calls, e-mail, SMS, MMS, and IM. However, each of these has its own characteristics when it comes to how it is being used. An SMS is instant, but typically less urgent than a direct phone call. An e-mail is assumed to be delivered with delay, and can be more formal than an IM message.

For reasons such as these, there are occasions when it may be better to present the system state and functionality to the user without artificial abstractions. Such situations are likely to be heavily dependent on the exact system being built, and thus generalizations seem difficult to state.

1.6.4 On Physical Interaction and Simplicity
It is the people who will eventually use consumer services that we design and implement. As the system is ultimately a collection of logic rules that happen inside electronic devices, there will also be an interface between the machine and the person using it. However, interaction with this logic is a wider concept that what it might first seem to be.

Systems and products are not used in vacuum. In this case particularly, we can even generalize that the meaningful interaction actually happens between the people themselves or, at the very least, between a person and the surrounding world.

This happens since the images that are taken are taken for a purpose. This purpose can be a selfish act, where the image is taken and utilized by the same person. In other cases, the image is possibly shared between people, and thus the interaction occurs between them. Other examples also exist, but for the purposes of this chapter none of these scenarios take away the role of a human actor who acts in a physical world together with a physical world. In fact, even simplistic activities such as seeing can be tied to the act of doing. Further still, being and experiencing is integral part of even abstract activities such as thinking (Heidegger 1927).

Following this thought, if the experiences are caused and observed in relation to the physical world and if our ultimate motives of interaction do not deal with electronic devices, the interfaces should focus on aiding users to fulfill their goals. In the scope of this writing, these goals are social more often than dealing with the user and the physical world. For example, a user needs study we organized in Tokyo showed that, for many people interviewed, the motivation was not to capture beautiful images, but show others what they are doing, how their surroundings feel, and how they are thinking about their dear ones. Interaction design, thus, is about facilitating communication between users and, in some cases, the surrounding world itself. Before venturing onward, let us consider the hierarchy of interactions. The Oxford American Dictionary defines the verb "interact" as: [to] act in such a way as to have an effect on another; act reciprocally: all the stages in the process interact | the user interacts directly with the library.

Interacting, by definition, is not limited to human-to-human actions. I would argue that the reasons for interaction often come from social motivations. These motivations are carried out by interacting with the physical world and ultimately coming down to pressing buttons to make digital devices do things that we wish from them. In the case of digital artifacts, the human-to-machine interface is a needed abstraction to allow us to deliver messages contained in these artifacts to other people. Thus, and especially in the case of our imaging service, we had

  • Social motives that are carried out by…
  • Digital artifacts that are manipulated by…
  • Human-to-machine interfaces that consist of…
  • Physical interfaces with which the user controls possible…
  • Software interfaces of the device

The exact order of items remains arguable, and the separation between physical device and the interface it contains is becoming hazy in some sectors (Buxton 2008). Interestingly though, the hierarchy described above also lends itself to highlight the concept of direct manipulation. In principle, it ought to happen that the higher in the hierarchy we can move the cognitive load of the user and the fewer abstractions there are between the user and his or her intent, the easier and more pleasant the system ought to feel. This naturally assumes positive outcomes that are not always guaranteed even in social environments.

To argue further for direct manipulation, let us have a look at the history of computers and computing as described by Paul Dourish (Dourish 2004). Computers started as mechanical devices that helped people compute. Due to various reasons, the mechanical implementation changed to electronic signaling, which allowed greater focus on the logic of the computing instead of the mechanical implementation aspects. A level of abstraction was taken off from the shoulders of the designers of such machines. Later on, the designs were adapted to use customizable wiring and subsequently started to utilize punch. This time, it was the electrical implementation that was taken off from the user's shoulders. The interaction further focused on the user and the task that he or she tried to accomplish.

The punch cards turned into command lines, which in turn developed into the graphical interfaces that are prevalent today. Interestingly, the development toward direct manipulation was also present, even to the extent of light pens that, however, did not gain traction. Instead of writing what the machine should do, joysticks allowed one to move the cursor on these graphical displays to select what should be done. Mice then turned this moving of a cursor into pointing. While the difference is subtle, it is meaningful; a moving cursor forces one to utilize an interface abstraction, whereas pointing deals directly with the object in question.

In the last few years, touch interfaces have been becoming increasingly common, especially after the commercialization of multi-touch. While neither of these technologies is particularly new, their acceptance and utilization in the consumer space is. Each can also be seen as a continuum toward directly manipulating digital artifacts. Basic touch technology accomplishes this simply by removing the task of operating a mouse and by multi-touch, allowing multiple pointing devices to be used (multiple fingers, for one).

Nokia Image Exchange had to operate in an existing environment and utilize existing platform and devices on top of which it was implemented. In practice, this meant that the physical devices were mostly fixed and could not be tampered with.

However, existing physical features could be taken advantage of when they did exist. For example, Nokia N95 multimedia computer included an accelerometer that was used to rotate the image according to the orientation in which the device was held. This effectively meant that users did not need to operate both physical and software interfaces and could concentrate on the physical.

Furthermore, the interaction paradigm focused on utilizing the joystick as an extension of the user's finger where possible. The joystick directions moved the focus from one element to another on the selected object, and pressing the joystick initiated features on top of the selection. Not only did this behavior simulate touching to some extent, it also allowed context-sensitive menus to be drawn based on what the user had selected. This in turn decreased the visual clutter on the interface, and was one of the carrying themes on user interface design.

However, this solution was still not as good as direct physical touching, but the latter was simply not possible with the given devices. The devices themselves were fixed, given the market situation and expected size of the audience.

1.6.5 Delivering More than Promised
It may seem self-evident, but good experiences are triggered by positive events. Thus, it is imperative that the positive events occur in the first place. Better still, experiencing positive surprises can be hoped to be more memorable and thus offer greater emotional impact. In practice, this can be accomplished by providing positive reactions over time.

These kinds of aims easily conflict with the most obvious marketing aims to some extent. To let people know about your product, service, or exhibition, it needs to be made interesting to the audience one way or another. An easy solution to this is to market why it is helpful or desirable to users. However, if all information about the product is revealed beforehand, surprises no longer occur.

In the case of Nokia Image Exchange, we deliberately left some of the features we considered fancy without a mention and avoided giving any direct hints on finding them. The most notable of these was automatic screen rotation that utilized an accelerometer in the targeted devices. When viewing images, the accelerometer animated the image rotation so that the image itself was always kept in closest 90-degree orientation (the top of the image pointing up). When the user physically rotated the phone, the image remained in the orientation and was fit to the screen if scaling was needed. As a result, we heard many joyful stories about positive surprises this feature had given to our test users.

1.6.6 What Should a System Do?
As easy as it may sound, deciding what a system should do is not always self-evident before the system is built. It is well known that users often use systems differently than what the designers have planned. However, even in this case, the audience does fulfill some of their desires. To maximize user satisfaction, we might do better if we could know and optimize for the actual needs for the majority of users. While it may be difficult or even impossible to know the distributions and exact needs of a diverse audience due to the complexities of data gathering, it would be hard to justify not even trying to do so.

Somewhat simple methods do exist to help understand users better. Perhaps the easiest method is to review previous research work that describes the experiences of others that have worked in similar fields. Other methods are often utilized in design research as well. Furthermore, it is entirely possible to find representative users for interviewing and observing their current behavior to understand them better. It does not harm the team to start actively participating in the activities they are designing for. It should be noted, however, that even interviews and observations might not reveal future or latent needs.

1.6.7 Sketching Interaction
Sketching has multiple benefits when used in design. By sketching, one is forced to think about what one is doing. Furthermore, by the definition of sketching, what one creates is not the final outcome, and thus the sketch itself can provoke new ideas. Finally, sketching is cheap, and can easily be thrown away if found unsuitable (Buxton 2007).

Unfortunately, sketching interactive systems is not quite as easy as working with static drawings. By definition, interactive systems change over time, by the system's users. In other than the simplest cases, the interaction forms a non-linear structure of actions in which users somehow navigate.

Further complexities often arise from technical limitations. When considering the user experience of the final product, it seems fair to say that it is dependent on the implementation. Thus, the design aspects and the technology together form an embodiment. This causes issues in approximating what the final system should feel like. While it is possible to create simple demonstrations of the ideal case, these can hinder the final outcome by being too finished and inflexible to adapt to changes that almost necessarily arise in the production phase of the system. Despite this, a holistic view would be preferable from the beginning.

Acknowledging these imperfections, our interaction sketching was done in stages. An instrumental tool in the process was an interface diagram, which tried to map how the system would be capable of supporting the previously mentioned scenarios and would ensure that the resulting navigation hierarchy remained logical within the system (Figure 1.2).

Figure 1-2. Version of the mobile interface diagram between iterations.

Figure 1.2 shows a version of the mobile interface diagram between iterations. It approaches the interface synthesis in a manner that might not be the most commonly used. The lines that connect the various screen mock-ups describe actions that trigger the transitions. The mock-ups come at different levels, depending on the problems that they present. Some of the notes simply indicated missing screens and what functionality the screens should contain, whereas others were pixel-perfect visualizations of the screens. These were occasionally needed to ensure that the information can fit to the screen and that the screens remain easy to understand. This is in contrast to the rather common tradition of producing the interface diagrams as simple wireframes that leave the graphical visualization more uncertain.

Furthermore, some of the issues can be resolved at multiple levels. For example, visualizations can emphasize affordances that are mandated by the hardware but do not flow as well with the visual presentation as they would if the hardware could be redesigned.

Interface diagrams are not able to solve all the issues with experience sketching. By its very nature, the diagram is not interactive and it does not even try to explain what happens between the screens. Diagrams are not very efficient in modeling time.

We produced interactive prototypes to quickly estimate the feel of the software on the computer screen. These were not complete, and only concentrated on specific questions or mandated usage flows. This was mostly done to save time, as it was clear that the actual implementation would demand changes. The interaction allowed, however, better feedback from expert evaluations that were conducted with usability and design professionals to see if there would be obvious faults in the proposed interface.

1.6.8 Lowering the Barriers of Usage
If designing how something should work is not easy, then designing how something can work is even harder. While there are existing practices that deal with many aspects on how Web services work, few take advantage of mobile-specific matters. Some of these advantages deal directly with the issues outlined previously in regard to laziness.

To lower the effort needed to try out and test the imaging service, it would need to be easy to put into use. Putting a service into use usually starts with a registration process where the user creates credentials for himself and fills in basic information such as his e-mail address that can be utilized, for example, to recover lost passwords. Other typical information usually includes at least the username and password that can be utilized to log into the service. The password is typically filled in twice to make sure it is not mistyped. Additional techniques such as CAPTCHA can be used to make sure that a computer program is not filling in the information for spamming purposes.

It ought to be needless to mention that filling out this information with a mobile keypad or touch-screen is a time-consuming process. This is an even less delightful process given that the scenarios in which the mobile phone is used are often mobile. Time is possibly fragmented, and the person using the phone is likely not going to have long moments of time to begin with.

One of the research questions was to study how far one can go to provide pleasant user experiences, and the typical solutions were not found satisfactory. In the Western world, where mobile devices are in many cases personal devices, the process is also against the basic principles mentioned in Section 1.5. Filling in credentials is, eventually, redundant information that a personal device should know already. Of course, part of the blame lay on the handset makers themselves for not utilizing these aspects already.

In our case, it turned out to be possible to identify and establish a user account automatically, based on the information that can be derived from the communication network. Eventually, the needed input from the user was reduced to a single question (accompanied by explanatory text) at the initial start-up of the application: "Do you want to allow network connections?" This question was unavoidable for the time being, as it would lead to issues of cost. At the time of writing, there are no standard protocols available to detect whether or not network traffic generates costs to the end user. However, functionality that has been added later on has introduced a few more dialogs to the installation process.

A user account can, however, be created automatically if these network connections are allowed. The default user name is set to the user's phone number to allow easy access to the Web service, and it can later be changed to the user's liking. A default password is delivered to the mobile handset via SMS, and is set to be readable from the S60 client interface for as long as it remains unchanged. The main benefit of the system is that the service becomes usable via confirmation screens that require minimal user input. The registration system and its aspects dealing with user experience are further analyzed in an IMSA paper (Vartiainen et al. 2008). Further benefits of tying the user account to the user's phone number include the possibility to let the user change to new devices and have his account follow without any extra configuration steps. Phone numbers also benefit in scenarios where the user wants to share content with friends that are using the system.

Accessing the Web interface does prompt for more information at the initial login, but in no way demands it to be filled in. The user can continue the usage with the mobile-created credentials alone, and the functionality that depends on additional information such as e-mail simply remains disabled. Furthermore, the information is prompted only at the initial login, after which the user needs to specifically go to set it under Settings. It was hoped that this would annoy the user as little as possible, yet still indicate that the functionality exists.

To address the continued usage, it was also necessary to ease image management as much as possible. As one of the basic design drivers was the assumption of pervasive Internet connectivity, the mobile client also implemented automatic uploading and downloading of images to and from the user's private account.

When new images were put on the phone via the file system or by taking new photographs, the client detected them and uploaded the images to the server in the background, so as not to disturb the user from what he was doing. Similarly, if images were uploaded to the server via a Web browser, they were transferred to the user's mobile phone automatically to create an illusion of a central storage space.

1.6.9 Issues of Joy
A large part of designing for experiences is to make sure that there is as little as possible that makes the experience negative, but concentrating mainly on minimizing these issues easily neglects the positive aspects. Taking this thought to the extreme, it might even lead to a situation where the system has nothing wrong with it, but it is still lacking the qualities that would give its users gratification.

Earlier studies as well as the ones conducted for this design work indicated several possibilities for enjoyment. Images themselves can be emotionally loaded, mediating feelings from one person to another. They are often shared with people close to each other and thus having an already existing emotional bond. Sharing can happen either physically in the same place or via transferring the images to the recipients. A user can be the one sharing the image or receiving it.

To address this, the first phase of the implementation tried to make publishing images as easy as possible. Sharing was implemented later on, and is now available in the published versions of S60 and S40 clients. However, the earlier tests simulated the sharing scenarios to some extent, due to the limited number of users within the system. The actual sharing was implemented later, and it took the advantage of the user's existing social network in the form of the address book.

Instead of creating new contacts, the system maps existing contacts to those in the user's phone book and allows direct sharing to the ones that are already users. For the rest, other methods of sharing existed. The Web interface allows sharing links to images, while the mobile application connects to both Short Message Service (SMS) and Multimedia Messaging Service (MMS) features provided by the platform.

Additionally, the user's joy can come from passing time while, for example, commuting. Images that are viewed in such situations do not necessarily need to be one's own, even if that seems to be a common habit with the interviewed people. An alternative can be the exploration of other interesting images.

This led to the need to optimize image browsing as much as possible, as well as to concentrate on the image content itself. Images, by default, were shown in full screen. The access to one's own images was made as fast as possible, while still providing visible options for more complex features. Image browsing itself was made almost as fast as possible.

Finally, it is not unfathomable that some part of the pleasure comes from the interface itself. While it was unlikely that this would be the major driver for this system, various niceties were implemented to delight the user or at least make sure that the interface would not get in the way of his browsing the images.

Examples of this in Nokia Image Exchange are the transitions between the views and the persistence of images. For example, the main menu shows the latest taken or viewed image in the background, with semi-transparent menus layered on top of it. Some browsing speed is sacrificed to make the images swipe in and off the screen, making the system more fluid. Images were zoomed to move between single images and image grids. Automatic screen rotation on devices that had accelerometers was also an instance where the joy was combined with functionality.

1.6.10 Issues of Trust
Elemental aspect of making an acceptable system is to make it reasonably trustworthy. The need of trust depends naturally on the service itself; for example, the needs for banks are quite different from instant messengers. This becomes more understandable if we consider the nature of interaction people perform with these entities. Banks, as an example, deal with money and personal savings that have direct and possibly dire consequences to people's lives if anything goes wrong.

In the case of instant messengers, the biggest threats are about the usage with a possibility of eavesdropping. Major losses are likely to be related to finding a new service, as very little personal data is stored in instant messaging systems. Imaging services such as the one presented here lie somewhere in between. While it holds personal data that is potentially very private and certainly personal, the loss of data is not likely to be as devastating as losing one's bank account.

Costs are a factor in the current mobile ecosystem. At the time of writing, mobile data plans are not usually guaranteed to be sold together with the service contract. Furthermore, data is often charged by the amount of traffic, which leads to the urge to minimize the data traffic and its cost. The design was based on the assumption of flat-fee data plans, and thus the system presented here provided minimal support for more fine-grained monitoring of data traffic. Some corner cases are notable, however.

While roaming, the application does stop from making data connections, as roaming charges for data can be prohibiting. It is to be noted that this behavior is by design, and thus efforts should be made to communicate the behavior clearly to new users. If this was omitted, the lack of trust in the system would be a real threat to the usage.

Another concern of trust comes from the automatic uploading of images to the service. Nokia Image Exchange tries to keep the user's image collection in synchronization with the server at all times by uploading all taken images to the user's private account. It is understandable that the acceptance relies heavily on trust, and that not all people will be willing to give their data to external parties. For example, such worries are quickly raised in companies whose employees take images to document their sketches from whiteboards. Again, this behavior is by design, and needs to be communicated clearly to avoid loss of trust.

Being a research prototype also introduced an aspect that could not be downplayed-the imaging service was, from the start, planned to eventually go live and public. However, it was a prototype with limited resources, and could give no guarantees of existence for a long period of time. Even technical failures could be damaging to the service, which operated on a relatively low budget.

Nokia Image Exchange's two-way connection to personal computers was designed to allow both uploading and downloading images to and from the service. While the uploading itself was a crude means to allow people to have images from sources other than their mobile to be transferred to the service and to their handsets, downloading was implemented to make it easy to get one's images from the service if the project would run into issues.

The Web interface contains options to download all images belonging to the given user in a zip package or to limit the downloading to the images that have not yet been downloaded. These options were a balance of implementation effort, ethical demands, as well as usability issues.

Some ethical issues were clear. It was simply unimaginable to not offer a way for users to retrieve their images if the system was to be shut down. This was even more critical due to the technicalities that operated under the cover. Namely, the S60 client stored original images onto the Web service and was only required to have scaled-down versions of the images on it for quick viewing. Were the service to go down, the originals could be lost for good. This was simply not acceptable from the team's ethical point of view.

On the other hand, the full implementation of the image packaging and downloading could easily lead to a complex user interface that offered very little benefit for the user if all went well, and was taxing compared to resources available. There was need for a simple solution that would still guarantee safety. Furthermore, this solution should not be overly demanding for the servers that might have thousands of users.

Finally, the downloading system could not be taxing for users if the need for it should arise, or if users would start to use it for their own purposes. Our solution was to create a page that offered users two options to create a zip package of the images they had on their user accounts. The first, and default, option was to only package and download images that they had not yet downloaded. The second option was to create a package of all the images. The last workaround allowed users to simply save the images one by one while viewing them. Together, it was hoped that these options would be sufficient for users, given the prevailing restrictions.

1.6.11 Compromises on Mobile Client
Preliminary designs and concepts are rarely perfect, as is the case with many other methods of formalization as well. For one, documentation is very rarely unambiguous. The reasons for these imperfections are many, but often the mere complexity of the project at hand is so vast that fully understanding it from all aspects becomes extremely difficult if not impossible. Thus, it essentially comes down to the fact that people need to deal with imperfect plans for whatever they are doing. When, not if, surprises occur, compromises are often needed to adjust the plans to what is feasible.

As an example, the S60 client offered a menu entry "Latest" which allowed browsing the latest images in the service. While it would have been possible to do the updating in the background, quick calculations can be used to demonstrate the issues:

P = Number of users in the system
I = Number of published images, average per user per time unit
T = Total number of image transfers
T = (P * I ) * (P +1)

This basically tells us that the average number of images is sent to every person within the system. If we now imagine that the system has 10,000 users, each publishing an image per day, the total number of transfers would be of this scale:

T = 10,000 *1* (10,001) = 100,010,000

Being optimistic, 10,000 users is a pessimistic figure, as the hopes for user count are much higher. Similarly, however, a published image per day per user is an optimistic estimate. Finally, the calculation did not take into account traffic generated by other activities.

Due to this reason, the estimation should be treated as an approximation that at best should give an idea about scale, but not exact figures. Nonetheless, we can see that a simple functionality that would keep the public images up to date all the time soon starts to push technical boundaries. The number of image transfers grows exponentially with the user count, and with a mere user base of 10,000 the transfers would already hit 100 million per day. One hundred thousand users would already result in 10 billion image transfers per day.

In this light, the compromise of making the user wait for a brief moment while the newly published images were downloaded was a necessity. This was aided by the fact that the Internet, for one, has taught people to wait. Further optimization was also done to make the wait time as short as possible. The sizes of the downloaded images are reduced at the server end, and they are downloaded in batches of multiple images to lessen the impact of network latency if they were to be transferred separately. As a result, a modern 3G mobile connection could theoretically be able to support downloading and viewing 15 images per second, albeit with a moderate hit on the wait time the user needs to tolerate at the beginning of the browsing session.

In practice, though, such numbers are not likely to be reached in most situations; in others, the delay can even be much longer. Finally, the already downloaded images were cached onto the phone to lessen the need of bandwidth and, much later on, make it possible to introduce offline features such as access to a vast image collection even when there is no network coverage at all.

Other discussed option was "virtually latest," where the images would not be required to be the absolute latest, but instead a collection that was update at specific intervals. This, however, could result in situations where new content would not be seen even if it were available. As one of the major functions of the application was identified to be killing time, this trade-off was not acceptable.

In contrast, however, the dynamics do change when people are sharing images with their friends. The number of image transfers goes down dramatically when approximately following the pattern below:

P = Number of users in the system
F = Average number of friends per user
I = Number of published images, average per user per time unit
T = Total number of image transfers
T = (P * F ) *1

Whereas the last calculation showed exponential growth based on the number of users, this pattern is actually linear. Thus, for 10,000 users each having eight friends on average, the number of image transfers is

T = 10,000 * 8 *1 = 80,000

This is obviously a lot less than a hundred million transactions mentioned in the previous example. Previous disclaimers to the formula apply to this one as well, but the growth of the transactions as user count increases becomes evident.

This made it feasible to share images, as well as the accompanying metadata, instantly to users' friends as well as to receive new images automatically from these friends. While not yet implemented, the team needed to develop underlying technology for purposes such as this one. The exact technical functionality is beyond the scope of this chapter, but in principle it allows clients to retrieve images in a few seconds after they are made available to the user and to have the latest information from one's friends pre-loaded to allow immediate access.

About the Author

Mobile Web 2.0: Developing and Delivering Services to Mobile Devices
From Janne Pekko Kaasalainen, "Designing for Mobility," in Mobile Web 2.0: Developing and Delivering Services to Mobile Devices edited by Syed A. Ahson and Mohammad Ilyas.

© Copyright 2011 Auerbach Publications