SIMS 213

First Interactive Prototype

Problem and Solution Overview

The problem with the old interface is that the listing of the tools are placed in an abstract manner. They do not match the mental models of the user. Being in the form of a list, the user cannot perceive their relationship to one another. They do not show what integral role they play in the different modules of the overall system. The interface, also, does not allow proper feedback to the user. When the user does perform an action, it is performed in the background and the user may feel hesitant to the "unseen" processes. There is also no option for the user to cancel or "step back" in the initiation of a critical process of which may become time-consuming to correct. And, the windows open in obtrusive manners, making multi-tasking between windows a hassle.

Tasks

The following three scenarios represent typical processes all users may go through in every day encounters with the system.

• 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.
• 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.
• 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.

Differences Due to Low-Fi 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.

Storyboards of the Three Scenarios (Annotated)

    Refer to the Screen Dumps

Prototype Overview

Overview of the Implemented Interface
The implemented interface has a simpler graphical representation.  There was a minimal use of colors, and those modules that were not immediate to the functionality of the system were left out.  The message windows and detail windows now contain bi-directional links so the user can access the data "on-the-fly."  New double-checking procedures were implemented so the user can step back and correct his mistake without letting it go too far in the process.  Also, the placement of the various windows open in a non-obtrusive defaulted position on the desktop so the user will not have to "hunt" down the necessary tools.

Implementations Left Out

Certain objects and entities in the interface had to be sacrificed due to time-constraints and the need for further testing. The first was the animated "rules pending" icon. Coding for the animation dealt with more intensive programming tasks, and it is unsure if the users truly need an object that alerts them every time a rule is stored. They may become distracted and forfeit other more critical tasks that need to be handled in a higher priority. The BLOC (Bright Light Operations Center) manual was also left out. Since it was not an integral part of the interface and was only another pop-up window, I did not deem it necessary to code for such a mundane entity. Also left out, was the error checking of the rules’ syntax. This was not a major issue. If a rule was written in the wrong syntax, the system would not allow it to be stored. It would simply return the user back to the detail window and prompt him or her to write a valid one.

"Wizard of OZ" Techniques

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 spamwall 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.

Tools Utilized

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, the close button was not a "clickable" event for me to modify. I wanted to change the coding of the event so that my executable would properly unload without it running as an unseen process on top of the operating system. I had to maneuver around this by synthesizing a button of which the code was changeable to perform the task of quitting.

Screen Dumps

        Scenario 1
        Scenario 2
        Scenario 3

Description of How to Run the Interface and the Scenarios

Executing the Interface

Download the executable file named BLOC.exe to a chosen directory. It is only 76kb. After doing so, you can run the interface by double-clicking it.

You can type in anything for the Username field.

The Password is: steve

A crucial thing to remember is that you can do anything you want in the interface. You can close any of the windows in any manner you want, except for the main interface. The one which reads BLOC Tools at the top of the window and has the title: Bright Light Anti-Spam System. You must press the Exit button. After it prompts you, you can hit Yes or No. This is how you also exit the overall interface. If you do accidentally close this window by hitting the X button, the operating system will still see it as an ongoing process. Just hit CTRL+ALT+DEL. A window will pop up. Highlight BLOC and hit the End Task button. This will clear the process.

Running the Scenarios
 

• 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, the participant will write a rule on it and store it. You will begin this scenario by double clicking on the BLOC.exe icon. The login window will pop up and you enter in the correct fields. Then the main interface pops up. Find the Alert Window hypertext link and click on it. This will bring up the alert window. Click on the first Attack I.D. hypertext of which is 1000000. The message window will now pop up. From there, you can go back to the main interface and click on the correlating Details hypertext of which is 1000 or click the Details button from the message window. The detail window will now pop up. You can checkmark as many of the categories as you like and type in anything in the textbox or leave everything blank. Hit the Store button and the system will prompt you. Hit OK and exit the overall interface by hitting the Exit button on the main interface and answering Yes to the prompt.
• 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. You will begin this scenario by double clicking on the BLOC.exe icon. The Login window will pop up and you enter in the correct fields. Then the main interface pops up. Find the Alert Window hypertext link and click on it. This will bring up the alert window. Click on the first Attack I.D. hypertext of which is 1000000. The message window will now pop up. From there, you can go back to the main interface and click on the correlating Details hypertext of which is 1000 or click the Details button from the message window. The detail window will now pop up. Now go back to the main interface and find the Traceroute hypertext and click on it. The traceroute window will now pop up. Type anything in the text box or leave it blank and hit the Trace button. The results of the trace will show you where we began and where the spammer is located. Now go back to the detail window. You can checkmark as many of the categories as you like and type in anything in the textbox or leave everything blank. Hit the Store button and the system will prompt you. Hit OK and exit the overall interface by hitting the Exit button on the main interface and answering Yes to the prompt.
• 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. You will begin this scenario by double clicking on the BLOC.exe icon. The Login window will pop up and you enter in the correct fields. Then the main interface pops up. Find the Review Pending Rules hypertext and click on it. The rules pending window will now pop up with rules written in Regular Expressions. Now find the Alert Window hypertext link and click on it. This will bring up the alert window. Click on the first Attack I.D. hypertext of which is 1000000. The message window will now pop up. From there, you can go back to the main interface and click on the correlating Details hypertext of which is 1000 or click the Details button from the message window. The detail window will now pop up. You can checkmark as many of the categories as you like and type in anything in the textbox or leave everything blank. Hit the Store button and the system will prompt you. Hit OK. You can now go back to the rules pending window and hit the Commit button. The system will prompt you. Hit the Yes button. The system will prompt you again so hit the OK button. Now, exit the overall interface by hitting the Exit button on the main interface and answering Yes to the prompt.