Section 17.3. Chameleon Interface Development
17.3. Chameleon Interface DevelopmentUser interfaces, like many other complex artifacts, are virtually impossible to create perfectly the first time. For this reason, a key element of good user interface design is iteration through the design, implementation, and evaluation phases. The Chameleon interface is currently on its third major version, after a paper prototype and a Visual Basic prototype. The paper prototype was evaluated with two different user studies, and the Visual Basic prototype with one study. Chameleon presents a new paradigm of application and file organizationrolesso the primary goal with our evaluations has been to determine, at a high level, whether Chameleon is easy enough to understand and convenient enough to operate that people would use it and, if not, how to improve the interface to make it usable. Toward that end, our experiments focus on the subjective impressions of participants, gathered by observing how they use the system and from questionnaires participants filled out after using the system. This section describes our goals for each iteration of the interface, how we evaluated each one, and what we learned. (An in-depth discussion of the user studies with the paper prototypes is given in our technical report.[11])
17.3.1. Study 1: Paper Prototype (Security in Context)We began the design of the Chameleon interface with sketches and storyboards on paper. The goal at this early stage was to determine what elements the interface needed for the user to interact with the security features of Chameleon, such as copying or moving files across roles. The sketches and storyboards served as vehicles for brainstorming how people might use Chameleon and how its security features might interact with nonsecurity tasks. In the next stage, we wanted to find out how people would react to the basic role idea of Chameleon, how easy the security features were to use, and how much impact they had on the realistic tasks. We also wanted to learn user preferences about two issues specific to the Chameleon interface: explicit versus implicit role switching and how to display desktop file icons. Explicit versus implicit role switching is an interesting issue because it is a tradeoff between security and usability. Explicit role switching means that if an application running in role A is active, and the user wants to use an application running in role B, role B must first be explicitly activated. With implicit role switching, the user can simply click on the application running in role B and automatically change role. Explicit role switching may have a security advantage because it is much less likely that users would accidentally change roles than with implicit switching. On the other hand, implicit role switching is much more convenient. We recruited 10 people from around our campus to use the paper prototype while we observed them and listened to their comments about what they found confusing, easy, difficult, helpful, etc. Participants also filled out a web-based questionnaire about their experiences using the prototype. Overall, participants were positive about the Chameleon interface, both verbally during and after the experiment and in the post-experiment questionnaire. For example, one section in the questionnaire asked participants to rate the security features of Chameleon with opposing word pairs on a scale of 1 to 9, as shown in Table 17-1.
Seven of the ten participants made positive comments, such as "I definitely would like it," and "[It is] easy to operate," and two expressed interest in finding out when the software would be ready. However, four made negative comments, such as "annoying for the lazy user who doesn't want to deal with the 'roles' each time they use the computer." The main concerns involved the convenience of transferring files across roles and of switching roles. Participants varied in their opinion of the likelihood of other people using Chameleon. Some participants thought that it was very similar to current interfaces and would be learned easily, while others thought it would not be easy for a computer novice or that only people who had been affected by malware would use it. Several participants commented that they would be very motivated to use our system because they had been affected by viruses or were concerned about being affected. Most participants did not think that the roles we used in the study were ideal. Of those who specified why, all said that they wanted fewer roles. One wanted only two roles: one for "files I absolutely knew were safe" and the other for "files that were suspect." Our observations of participants using the system and their comments about it confirmed our belief that a role-based desktop was workable. However, it also highlighted the importance of making the low-level interface mechanisms, such as menus, convenient. To determine the best mechanisms to use for role-related operations, we conducted a second user study. 17.3.2. Study 2: Paper Prototype (Security Mechanisms)During the first user study, we had observed that people were sensitive to how convenient the security operations were to perform. For the second study, we wanted to determine how people would prefer to perform key role-related operations. We gave each study participant a set of tasks with multiple methods that could be used to complete each task. We asked them to try each method and rank them. An abridged description of the tasks and methods is shown in the following list (note that participants were given more detailed instructions than are shown here). An * indicates the methods most preferred by participants.
Figure 17-5. Context menu for the Security Manager Figure 17-6. Context submenu for the Security Manager, from the "Clipboard option" For tasks with two or three methods, we balanced the method ordering across participants. This was not possible for task 4 because it has four methods, so we chose unique orders for the participants to be as different as possible. Upon completion of each task, the participants were asked to rank the methods by preference. As in the first study, participants filled out a web-based questionnaire at the end. Participants took 4570 minutes to complete the experiment. Participants in this study also generally liked the security features in Chameleon. The biggest concern participants expressed was that some operations have several steps. One participant was not worried about getting a virus and thought the roles were extra, unnecessary work. However, the other five participants were positive about the interface and said they would use it. One said, "I wish some of [your] designs...would be common practice among big leading software companies." In this study, participants ranked the interface methods for performing each task. We used these rankings to assign points to each method and summed them to determine the most preferred method for completing each task. Participants had strong preferences related to tasks 1 and 5, and fairly strong preferences related to task 6. However, preferences were less clear for tasks 2, 3, and 4. Some methods shared common interface mechanisms of clipboard use, context menus, drag-and-drop, and role-aware file dialog boxes. Overall, the strongest preference was against using the clipboard. The most common comment about specific mechanisms was that they liked drag-and-drop, although in the rankings this method is similar to other popular methods. 17.3.3. Study 3: Visual Basic PrototypeAs mentioned earlier, a concern we had with the Chameleon interface was how aware of roles users would be. Our ideas for making roles visible included graying out windows owned by inactive roles and animation; both methods are difficult to implement with paper prototypes. Also, it would be hard to learn about user awareness from a paper prototype because it is so visually different from the final software. For these reasons, we decided to move to a software prototype for this iteration. Based on what we learned from the studies with the paper prototype, we built a software mock-up in Visual Basic (see Figure 17-2). It was used to explore different interface alternatives, did not have any real security, and did not run real applications. It included several mock-up applications, based loosely on Microsoft Windows applications. In addition to observing how participants used the interface in general, we introduced a trick into the interface at a few points in order to test how aware of roles participants were. Specifically, at a few points during the study, participants saw a window that appeared to be in one role, but was actually in another (see Figure 17-7). The goal of this deception was to attempt to get participants to take actions that would be a security risk in a real system, such as entering a password into an untrusted application. Figure 17-7. A malicious application appears to be a text editor and tries to trick the user by drawing a fake window inside itself that looks as if it is in a different role As with the previous studies, participants were generally quite positive about using Chameleon. What was surprising was that very few of them noticed our trick (illustrated in Figure 17-7). We are not sure why this occurred, but we believe that our participants may not have done enough security-related operations, or that our feedback about the active role was not overt enough. More work on how to provide role awareness is needed. Ideas for feedback include:
|
EAN: 2147483647
Pages: 295