Steve Lam

SIMS 213

Final Project Write-Up

At Bright Light Technologies, a startup company located in San Francisco that is dedicated to fighting Spam (junk e-mail), there exists a set of tools of which is used by Spam Control Engineers. These tools are used to view, catch, and aid in counter-measures used in the war against Spam. But, like all tools, their organization within an environment is key to making a user’s work much more efficient and effective. At times, the browsers used to view and trace the Spam have hindered the performance of these users. If we use the "desktop metaphor" as inspiration for a description, the screen may sometimes appear to be a cluttered desk, with making the search for a window or Spam-fighting utensil a hassle.

A facility which needs to update filters against Spam needs to be highly efficient in terms of time and resources. Since each attack may arbitrarily occur at any given moment with varied durations, it is essential for the user(s) to be organized and well-prepared in quickly updating the anti-Spam filters. To achieve this goal of organization and efficiency, an interface that conforms to the organizational schemes of the user must be developed. This would be the placement of anti-Spam tools and Spam-viewers within an environment easily accessible to the user – or in this case the Spam Control Engineer.

The general proposed solutions for the new interface are the following:

• Allow the user to see the overall system as a "top-down" configuration (Allow users to view the system as a whole rather than piece by piece so they perceive the "whole picture.").
• Bulletproof the interface from a user’s "would-be" mistakes. Allow for error checking and confirmation before the performing of resource and time intensive actions. These would include the confirmations of rule propagation – the sending of a filter to the spam-wall. And, also performing rule deletion, and the retrieving of the whole database for examination.

Compartmentalize or modularize certain tools of which the user finds the most essential. So that, the user is able to multi-task when a background process has been initiated (e.g. testing a rule and being able to view a new piece of Spam without first waiting for the rule to be finished testing.

The following three scenarios represented the tasks I used during the design process.

1. The user logs in and looks at the alert page and selects a message. He will view this message and determine if it is spam. It is, so the participant will write a rule on it and store it.
2. The user logs in and after viewing the message cannot determine if it is spam or not. He, therefore, brings up the detail window and is still not able to make a decision. He will finally perform a traceroute and decide that it is spam. After doing so, he will write a rule and store it.
3. The user will log in and check the rules pending window first for rules waiting to be reviewed. He sees the new rules and determines if they are valid. While he is still evaluating it he may want to look at other messages at the same time, so he brings up a message window. He now goes back to the rules window and decides that it is a valid rule and commits it.

The following tasks were modified for the final interface, but were only changed slightly.

1. The user is to look at the alert page and select a message. He is to view this message and determines if it is spam. If it is, the participant will write a rule and store it. During this task, I observed the process by which the user utilized the separate windows instead of having to navigate back and forth.
2. The participant, after viewing the message, cannot determine if it is spam or not. He cannot, therefore, he performs a traceroute. If the traceroute tool reveals a path consistent with, he will write a rule and store it. Here, I observed how the user could efficiently bring up other tools quickly without having to do a long search on the interface.
3. After the participant logs in, he checks the rules pending window first. Since the committing of the rules takes several minutes, the user will choose to look at other messages. During this procedure, I observed what other tasks the user anticipated in performing when the system was performing another process.

The reason these tasks were chosen was because these were the most common scenarios the employees performed. Also, they were the ones that utilized the most resources and caused the most problems initially before the UI was implemented.

Please see the web page for the annotated ones. Since the font was white with a black background on the web page, the annotation did not show up in the print out because it gave the screenshots a white background.

Much of the changes were due to the low fidelity testing. The low-fidelity testing process yielded new models for the interface as well as pruned some of the initial suggestions. Although the user did find the usability to be enhanced by graphical representations, they did not want it to be represented as graphically intensive as was initially planned.

They suggested that the colors and the complex structure distracted their work habits. Therefore, the new interface shows a simplified version of the system and the colors were toned down. In the initial prototype, the users also wanted bi-directional accessibility from the message window to the detail window. They did not want to constantly go back to the main interface just to bring up the message window or the detail window. So, the new interface was implemented with links going both ways. Finally, the users wanted the system to double-check a time-intensive process before proceeding. Therefore, message windows prompting the user for assurance were added.

The pilot usability test did not yield any changes, but it did give some surprising results in the philosophy of UI design in general. It seems that since this interface was specifically tailored for people who have extensive experience with anti-spamming and system administrators, the vocabulary and changes suggested by the heuristic evaluators actually confused the participants more, than helped them.

The major changes leading to the final interface were the following:

• The graphical representation was simplified.
• Bi-directional links were added.
• Double-checking prompts towards the user for intensive tasks were implemented.
• The vocabulary was changed back to the user’s language. In this case, a more technical vocabulary.

Of the three evaluation techniques, the low-fi testing and the pilot usability test were the most valuable in the design of this UI.

The low-fi testing allowed me to see what changes needed to be made without having to perform intensive implementation tasks which were to be changed anyway. It also gave me the flexibility to control the UI physically without the constraints of the computer. I could directly perform and manipulate the actions of the interface during the test to yield faster results and target the variables I was measuring. If I were to do this on a machine, the testing would have been much more arduous. This way, I could control how the UI would perform and concentrate on usability and not on technical implementations.

The pilot usability test showed me that even though the regular population or "laymen" prefer certain entities and actions in their UI, (vocabulary, manipulation techniques, default locations for windows) the expert may actually prefer something that fit his or her schema of doing things. And, in this case, the people I was designing for preferred the technical vocabulary because it conveyed the situation better for them.

Therefore, I chose these two techniques, low fidelity prototyping and pilot usability test, as the most valuable due to the ease in changes of design, and a better evaluation of the UI from the people you are actually designing for.

The final UI has a main interface of which the whole anti-spamming system is graphically represented. Each of the links within the main interface, when clicked on, opens a new window containing the appropriate tool. Therefore, tasks and processes would not be interrupted because a new process or tool has taken over the previous entity within the same window. Other, functions added were the bi-directional links from the detail window to the message window so that a user would not have to go back to the alert window just to access the message. Finally, before performing a crucial process, such as, shutting down or committing a rule, the act of approving someone’s filter, the system will double-check and warn the user before commencing the operation.

The system has very low functionality, in that, it does not really receive spam. The data is hard coded and it is only a representation of what would be in the system if it were active. The engine used to write the filters also has very low functionality. It was not given full functionality because it would have required the implementation of a compiler-like system, and this fell out of the domain of usability.

After logging in with the password ‘steve’, you will be presented with the main interface. Each link is associated with a certain tool and if you click on it, the tools will open up in its own defaulted position on the desktop. This would prevent the windows from obstructing each other and also eradicate the user’s need of moving the windows to appropriate places. When you click on the alert link, the alert page opens. From here, you can click on the detail link or the message link to open up those windows. Whichever one you click, you will notice that the window contains a bi-directional link to the other window so that it will not be necessary to go back to the alert page.

Other miscellaneous functions to this interface also include the double-checking of crucial operations when you click on the store button, commit button, delete button, or exit.

As you can see the interface contains very low functionality, but the key thing it has represented was the ease of use and cleanliness of representation (i.e. windows are modularized and the desktop is not cluttered).

If there were no time constraints, a better knowledge of the tool I used to implement the prototype, and more resources (more man-power), I would have been able to implemented these other features:

• Implemented or tied the new interface with a Regular Expressions engine to allow for the checking of syntactic validity of rules.
• Tied the interface with an existing database of spam, so that there would be more realistic content and a better representation of the content.
• Used animation so that the users can have constant feedback from the system. This would reassure the users that the system is up, or alert the users if an event has changed the state of the system (i.e. a rule has been stored and is waiting to be approved by another user.

There were numerous things that were forged to give the user a "feel" for the actual functional interface. The probe statistics results, traceroute results, alert daemon, and spam-wall acknowledgements were forged. When the user does initiate these tasks, they at least provide feedback to the user’s desired processes. Utilizing this fashion, the user will know what to expect in the final product. Also, these dummy data provide good useful feedback for further analyzation of the user’s reaction and how they want the data to be represented in the final interface.

For the purposes of doing an aesthetic interface of little functionality, I was aided by the Visual BASIC development environment.

How the tools helped: The tools were a large aid because they allowed for the philosophy of "what you see is what you get", this method allowed me to quickly attain the results I needed. At the same time, since a physical graphical representation was clearer, debugging was of little concern. The environment allowed me to view my project as a collective whole with relationships and as an overall working system.

How the tools did not help: What the tools did not provide was the ability for me to simulate time. The main purpose of this parameter was to also simulate the real-time processes it took for a procedure to execute, thereby, giving the user a more realistic feel for the interface.

Problems with the tools: The problem perceived by me, was that there was not very much freedom in the creation of windows and forms. I was not able to fine-tune the settings as to allow for an ideal size and shape of the window. Also, for the purposes of animation, it seems that many of the results are unexpected and you need a certain amount of experience before taking on this task.