What do end users want from reconfigurable radio ... - Semantic Scholar

What do end users want from reconfigurable radio terminals? Raquel Navarro-Prieto, Genevieve Conaty Motorola UK Research Lab, Jays Close, Viables Industrial Estate, RG22 4PD, Basingstoke, UK Tel: +44 1256 484037, email: [email protected]

ABSTRACT This paper presents results of a user study to investigate detailed end-user requirements for reconfigurable radio systems. 23 participants contributed to this user study in scenario-based interviews. These results focus upon the information and interactions that will be required for users to understand the ‘reconfiguration’ process, as well as their conception of the positive and negative implications of reconfigurable radio systems. I. INTRODUCTION Reconfigurable (software-defined) radio has been called the next major leap forward in mobile and wireless communications [1]. Experts in reconfigurable radio technology anticipate that it will offer future end users many advantages, including enhanced roaming capabilities and automatic selection of the most suitable network to meet his or her preferences [2]. These advantages, however, may come at the cost of increased complexity for end users of reconfigurable radio terminals. User research and careful design will be required to ensure that the user interaction and user interfaces for future reconfigurable radio terminals match the users’ expectations and meet their requirements. In order to meet these goals, the TRUST project (Transparently Reconfigurable Ubiquitous Terminals) has bolstered its technology and systems development with another body of work devoted to understanding user requirements for reconfigurable radio systems. The project has explored user needs not only for future end-users, but for network operators as well. This paper will address the later stages of our research, in which the goal was to define a set of enduser requirements for reconfigurable radio. In this paper we will focus on the requirements that we consider key to the concept of reconfigurability, along with more general requirements for future communications terminals. II. OUR RESEARCH A. Previous Research in TRUST Previous work in this part of the TRUST project reported on the initial user requirements for the lead user group [2]. The user data for the initial phases of the project was gathered using questionnaires, interviews, and scenario-based focus groups. These

investigations with users led to the identification of a set of possible scenarios of future users relying upon reconfigurable radio technology. This information formed the basis for the further development of the scenarios reported upon in [3]. In this scenario development work, four core user scenarios from the initial set were selected and expanded into full narratives. Each narrative was then broken into a “storyboard,” a step-by-step description of what the user and the system were doing in that particular scenario. These narratives and storyboards were used to generate lists of the end-user and operator issues associated with each step of the scenario. These end-user issues determined the focus of the user requirements research described in this paper. In addition, each scenario was implemented as an interactive presentation using Macromedia Director, so that these scenarios could be more easily and effectively portrayed to end users and other members of TRUST. B. Our User Study As stated above, the user research described in this paper was organised around the issues that emerged during the scenario development and analysis. Eight particular issues and the research questions associated with them were identified, namely mode switching, air interfaces, security, system resources, battery life, user profile, video, and group communication. In brief, these issues refer to the following concepts and questions: •

•

• •

Mode Switching refers to the process by which the terminal reconfigures to a new network mode. Should this process be completed automatically, or instead should it be done manually by the user? What will the user need to know in order to decide whether to switch to a new mode? Air Interfaces. For example, when the user needs to download a new air interface in order to enable their terminal to operate on a new type of network, should this download be done automatically or manually? Security refers to the security aspects of both the information and the software that is downloaded to the terminal. System Resources are those diverse system components that affect the performance of the terminal, such as the processing power and

• •

• •

storage space. What does the user need to know about these resources? Battery Life refers to the information that the user needs about the battery of their terminal. User Profile refers to the information that the terminal will ‘know’ about the user in order to customise the behaviour of the terminal for that user. Video refers to the use of video on the terminal, including streaming or downloading video from the network. Group Communication refers to situations in which a distributed group of users are communicating with each other. We were particularly interested in the use and management of multimedia as part of these communications.

The user research was planned with the goal of investigating the user expectations and requirements surrounding each of these issues, A paired-interview plan was drawn up in which each pair of users would see one scenario as an illustration of the concept of reconfigurable radio and another scenario as a focus for discussion. Each interview focused on two of these eight issues and included a paper-based information organisation task for one issue. A total of 12 interviews with 23 users were conducted. The users were professionals between the ages of 24 and 51 who were familiar with mobile communications and Internet technology. The study provided detailed information about user expectations related to these eight issues. An overview of the results of this study is presented in the next section. III. OVERVIEW OF THE RESULTS ABOUT RECONFIGURABILITY In this section we will summarise the main findings for the two issues that we consider intrinsic to reconfigurability: Mode Switching and Air Interfaces. Each of these activities supports a type of ‘reconfiguration’; mode switching refers to the transition between network modes, and air interfaces refers to the download of new air interface software to enable the terminal to operate on a new type of network. For this paper we have grouped the questions that were explored with users into two categories: A. Should the reconfiguration be automatic or should it be manual (driven by the user)? and B. What does the user need to know before, during, and after the reconfiguration?

wanted to set-up their terminal so that on certain occasions they would have manual control over mode switching. Specifically, they would like to program the terminal to switch the control to the user if the change in mode implies a change in cost (especially if the individual user, rather than his or her employer, is paying the bill. The variables that may impact whether they want the mode switching to be seamless are: 1) whether they are using the terminal to complete a task at the moment, 2) what they are doing in the larger context of use (i.e. the terminal should perform an automatic mode switch while they are driving), 3) what the time will be to switch (if the users have time constraints, they may want to pay more and make the switch faster) and 4) whether the user likes getting involved in the inner workings of the terminal (some people may prefer to take control, other people might not). If the user is busy working with the terminal, the terminal could be set up to wait until he or she has finished the task and then prompt him or her with the need to change modes. In general, users would prefer not to be interrupted since they would like to continue with the task that they are doing. In the case that they are conducting a voice call, they wanted to be able to continue the call, and suggested that only the software required for the call gets download at this moment. In the case when an interruption is needed, they wanted the caller to be sent to voice mail in the meantime, and wanted the call to automatically reconnect after the download was complete and the terminal had reconfigured. At the very least, they want to have a ‘do not disturb’ button to postpone mode switching and allow them to finish their task. One option proposed by the participants is that the terminal could use the times when it knew that the user was not using it to reconfigure. If the interruption is necessary, the participants in the study suggested the option of being ‘entertained’ during the process (e.g. ‘background music’). In addition, some users were concerned that the reconfiguration seemed like a technical process that might be hard for them to understand. For example, several users weren’t sure why they would need to download new air interfaces and hoped that the terminal would be able to manage the connection to various types of network without help from them. In this case, the idea of seamless reconfiguration would be very appealing.

A. Should the reconfiguration be automatic or should it be manual (driven by the user)?

B. What does the user need to know before, during, and after the reconfiguration?

One of our main questions concerned whether users think that their terminal should switch to a new network mode automatically (seamlessly) or whether this process should be initiated by the user. In fact, the choice between seamless or user-controlled mode switching depends on a number of circumstances. The users

We were interested in what users are going to need to know in order to decide whether to reconfigure, what they need to know while the terminal is reconfiguring, and what they need to know afterwards.

1. What does the user need to know before reconfiguration? Users would need a notification that the reconfiguration was about to occur before the terminal reconfigures, especially if the download were not free or if it were going to interrupt the user’s task. If the users were going to need to select a new network, they would need a variety of information about • • • • • • • • • • •

Which other networks are available The compatibility between the network and the terminal The speed of the transition (how long is it going to take to switch?) The cost of the new network, including the cost of actual network use and the cost to download the software to switch to this network. Comparative cost and bit rate of two (or more) networks The image/video/speech quality available on the network (and the trade-off with cost) The coverage of the new network (when can I use that network?) The applications/services/functions available on a network (for a quick decision, services are thought to be the critical factor) Storage space needed for any new software Security information about network Quality of any new software

This list does not imply that all the users will need to have all this information; some of it will only be needed at certain times, and different users may have different needs for different type of information. In addition, if the download of the new air interface needed to be performed by the user rather than automatically by the terminal, the participants thought that the terminal should tell them precisely how to accomplish this task. 2. What does the user need to know during reconfiguration? During the reconfiguration process, users would need to know ‘what is happening,’ for instance, through a progress bar, a ‘signal bar’ or a ‘clock ticking away’ in the interface. Some participants mentioned using the user profile to define what type of feedback (vibration, flashing light, etc.) they should receive to let them know that the terminal is reconfiguring. Also, they would like to have an option to abort or pause the reconfiguration. They would also like to be able to perform other tasks that didn’t ‘need connectivity’ during the reconfiguration. For example, one participant said she would expect to be able to ‘write e-mail’ while the new air interface was being downloaded, but not to ‘send email.’ 3. What does reconfiguration?

the

user

need

to

know

after

First, the participants reported the importance of knowing that the process has been completed, with some notification such as an audio beep. Second, they would like to receive instructions about how to use the new network, if necessary. This information would be important if the reconfiguration would impact the user (in terms of security, functionality, cost, etc.). The participants emphasised the importance of presenting which services are available at any given time very explicitly in the interface. Finally, the participants emphasised that downloading a new air interface should not alter the ‘core functions’ in the terminal. After the reconfiguration they would want their ability to use these core functions to remain the same. IV. GENERAL REQUIREMENTS The previous section has focused upon specific topics for reconfigurability. We also investigated more general issues about how users expect to use future reconfigurable radio terminals. We have grouped these results into three groups: users’ concerns and related suggestions, ideas for possible negative implications of such systems, and ideas for possible positive implications. A. Concerns (and suggestions). These were issues that the participants thought would cause problems for users if they were handled poorly in the design of the system. In some cases, participants made suggestions that would address their own concerns, or that might improve the utility and usability of the system in general; these have been included in this section. B. Possible Negative Implications. Unlike concerns, these issues are very likely to create problems for future users of reconfigurable radio, and will be difficult to mitigate with good design. C. Possible Positive Implications. These are positive observations about how the capabilities of reconfigurable radio will help users or better support their tasks. A. Concerns (and suggestions) This section reviews the main concerns raised by the users and some of their suggested ways to address these concerns. 1. Complexity and information overload Participants noticed that reconfigurability might require them to handle a great deal of information. They mentioned repeatedly, ‘If it's complicated, nobody is going to use it.’ Some of the mechanisms that users suggested to cope with this complexity were (1) using the user profile to make automatic decisions (for example, which network to switch to), (2) allowing

people to use the terminal as normal and have it learn from their behaviour how they need it to operate (sophisticated adaptive profiling), (3) intelligently filtering the information that is presented to users, (4) tailoring the presentation of information based on the user profile and environment, (5) employing good interface design, and (6) ‘protecting’ the users from information coming into the terminal from the outside world (e.g. location-based advertisements). In addition, they thought that there should be multiple routes to perform the same functions (for example, using a user interface ‘wizard’ to set up a user profile as well as putting information into the profile via the user’s personal phone book of contact details). 2. ‘Out of the box’ usability Participants were concerned that unless the terminal can be used ‘out of the box,’ users won’t be able to eventually learn about the more complicated capabilities of reconfigurable radio. For example, some participants thought the terminal should be supplied with a ‘default’ user profile or ‘wizard’ interface style to enable novices to use it more easily. 3. Size and associated system and interface constraints Several participants asked how big the terminals were expected to be. Many of the participants carried both a mobile phone and a PDA with them most of the time, and wanted to make sure that the reconfigurable terminal would be at least that portable, if not more so. They suggested that ‘it should be no bigger [than a PalmPilot or Psion],’ and worried that a terminal with the display capabilities described would be ‘too bulky.’ In addition to the sheer physical size of the terminal, the participants were also concerned about the difficulty of inputting and displaying information on a small terminal. Some participants thought that the screen of a handheld terminal would be too small for some functions. They also had a variety of suggestions to make input easier, including voice recognition, predictive text entry, interface shortcuts to a ‘soft’ keyboard, a modular physical keyboard, and a touchscreen that could be used with the fingers rather than a stylus. Finally, some participants weren’t sure about the storage capacity of a small terminal. They wanted to be able to store a lot of video information on the terminal, for example, and worried that this would require ‘a massive amount of memory.’ One participant pointed out ‘that this may not be a problem in [several] years.’ 4. Physical design for multifunction terminals The participants also wanted to ascertain whether the physical design of the reconfigurable terminal would enable it to be used for the many tasks shown in the scenarios. For example, they wanted to know that they would be able to look at the display of the terminal at

the same time as they were speaking into it, as in the group communication scenario. 5. Integration with other terminals/systems and centralisation of information The participants wanted the reconfigurable terminal to be able to interoperate seamlessly with their other devices (such as their PCs), without their having to worry about data formats or other issues. In addition, they thought that all of the information needed to run the terminal should be stored ‘somewhere else,’ so that they could use their particular user profile no matter which terminal they were using, and would have a backup of their information in case the terminal were stolen. The participants also suggested that the integration between their personal devices should also extend to the variety of intranets that they might need to access; the terminal should allow them to do whatever intranetrelated tasks they can do at work when they are not at work, for example. 6. Network issues – coverage, speed, Quality of Service, etc. Network problems such as poor signal strength and drop-outs were among the main annoyances that the participants reported about their current mobile phones. All participants hoped that reconfigurable radio systems might solve these problems, but were concerned that their irritation would only increase if these issues were not addressed. For example, some participants suggested that ‘you need to be connected all the time.’ They also wanted to be able to receive and transmit information across the networks quickly. Finally, they wanted to be assured of decent speech and video quality. 7. Costs and billing The participants were worried about the overall costs of running the system, and especially about keeping control of those costs. They made fine distinctions about whether they were paying for the terminal to be ‘always connected,’ in which case the terminal could download information before it was requested based on prior use of the terminal, versus paying for each download as a separate transaction. They anticipated that the terminal might be quite expensive (‘scary’) to run. They were also perplexed by the billing for a reconfigurable system; if you are using a wide and ever-changing variety of networks, ‘who sends you the bill?’ B. Posible Negative Implications This section discusses potential negative implications that the participants foresaw for reconfigurable radio systems. In terms of impact on the individual, participants thought that they might become too reliant on such an information-rich terminal; they made the analogy to the ‘alert system in your diary’ that makes you lazy because

you don’t have to remember your own appointments. In addition, a complex terminal such as a reconfigurable radio would be ‘something else to learn,’ requiring them to learn something new if their terminal were to break or get lost. Finally, many users were worried about the possible health implications of heavy use of wireless terminals. The participants also saw some potential negative social implications. One of these was that early adopters of the terminals would become so ‘neurotic’ about using them (as did people ‘in the Eighties with the Filofax’) that other users will actually reject the technology or associate it only with a particular type of use. They were quite alarmed about the potential for privacy violations; one participant mentioned that future users will have ‘no excuses,’ because their employers and friends will know (or have the potential to know) where they are at all times. C. Possible Positive Implications Participants also identified a slew of possible positive implications of reconfigurable radio for future users. The participants were impressed by the idea that they would have one terminal that would provide many of the functions currently provided by their mobile phones, PDAs, desktop PCs, and laptops. Many of the participants also perceived that the terminal would ‘save time’ and ‘make life easier’ by giving them faster access to their own information and services, as well as making it easier to contact colleagues and friends. They liked the idea that they could keep PCs at home and at work and then use the terminal to transport information between them, or access the same central information store using the terminal of their choosing. The participants also liked the flexibility afforded by the system. Some participants pointed out that users won’t need to buy new terminals to get new functions. They liked the idea of video-based and group communications, both of which were seen to offer an ‘immense’ range of applications. Finally, the participants liked the idea of becoming more ‘contactable’ and less dependent on any one network. V. CONCLUSIONS Mode Switching and Air Interface Download. We discussed two types of ‘reconfiguration’ with participants. The first was switching from one network to another of the same type (‘mode switching’), while the other was downloading and installing an entirely new air interface (‘air interface download’). In both cases, the participants wanted to be able to choose between having this done automatically or manually, wanting the terminal to carry the task out automatically when the user is busy. If the process were manual rather than automatic, there was a wide variety of information required in order to select a new network or air interface, thus requiring settings in the user profile and good information design to reduce complexity. In general, users were reluctant to be interrupted by what

they perceived as technical tasks, and wanted some functionality to be available even during reconfiguration. They didn’t want the core functionality of the terminal to be altered by every reconfiguration. General Concerns about Reconfigurable Radio Systems. The participants’ biggest concerns about the general concept presented in the scenarios were the complexity and potential for information overload, the portability of the terminal, the input and display constraints on a small terminal, and the general ease of use, especially for novice users. Other concerns were integration with other terminals, centralisation of information, cost control, and network issues. Positive Implications of Reconfigurable Radio Systems. The idea of one terminal that could perform many of the functions that now require a phone, PDA, and PC was very pleasing to the participants. They thought that such terminals would add flexibility to their lives. They enjoyed the fact that they would not be dependent on one network and that they could obtain new functionality without having to obtain new terminals.

ACKNOWLEDGEMENTS This work has been performed in the framework of the IST project IST-1999-12070 TRUST, which is partly funded by the European Union. The authors would like to acknowledge the contributions of their colleagues from Siemens AG, France Télécom R&D, Centre Suisse d’Electronique et de Microtechnique S.A., King’s College London, Motorola Ltd., Panasonic European Laboratories GmbH, Robert Bosch GmbH, Telefonica Investigacion Y Desarrollo S.A. Unipersonal, Toshiba Research Europe Ltd., TTI Norte S.L., University of Bristol and University of Southampton. Special thanks to David Williams and Kate Cook for their contributions to the process described in this paper. REFERENCES [1]

M.A. Beach, J. Pereira, R.S. Swain, A.T. Munro, J.R. MacLeod, J.R., P. Dugenie, “Re-configurable Radio Systems and Networks,” in Proc. First Int. Conf. on 3G Mobile Communication Technologies (Conf. Publ. No. 471), London, England, 2000, pp. 321 –325.

[2] D. Williams, E. Ballesteros, C. Martínez, and E. Morata, “User Assessment: Reconfiguration Scenarios and Requirements.” Public Deliverable D2.1 from the TRUST Project (IST-1999-12070), 2000. [3] K. Cook, C. Martinez. Future Scenarios: Developing end user and operator requirements for software reconfigurable radio. IST Summit of Mobile Technologies, Barcelona, Spain, 2001, pp 147-152.