Steve Lam

SIMS 213

Second Interactive Prototype

At Bright Light Technologies, a start-up company based in San Francisco dedicated to fighting spam, there exists a set of tools used to view, catch, and implemented filters to aid in the battle against unsolicited or junk e-mail.

The people who perform these duties are a group of specially trained twenty-four hour operations staff. But, their expertise is not the only factor in the war against spam; the organization of these tools and the representations of the system are key to the efficiency and speed of the counter-measures taken to catch spam. The old interface did not do this. It contained many obstructions such as windows opening in obtrusive manners and abstract representations of the system. Therefore, a new interface was implemented.

The new interface represents the system graphically to the users, with the tools placed in relationship to one another. The windows open in defaulted non-obtrusive manners so that the staff can quickly view and write rules without having to work their way throughout the cluttered "desktop." And, the system double-checks with the user before performing any time or resource intensive tasks.

It was observed that the new interface contained certain new inconsistencies and usability problems during an evaluation. Therefore, changes were made to fine-tune the prototype.

The message window now has a button, which explicitly tells the user to press it if they are looking to write a rule or view details pertaining to the spam. The Alert page now lists the columns with properly labeled headers so that there is less confusion as to what the numbers mean. On the main interface, re-wording has been done to make the terminology less domain specific for novice users. The pending rules page now allow the user evaluating the rules to see who wrote the rules and choose which rules he or she wants to commit or delete. There were also changes done to the overall interface to make the wording and terminology more consistent. And, the controls in the main interface have been limited so that the users will not accidentally shut down the system with no way of getting back.

These changes were done based in the time allotted. There were still other problems users demonstrated when using the interface, but they either fell outside the domain of usability issues or were not possible to improve due the time constraints.

1. Rule activity is not the issue. Once it is committed, it is in the spam-wall. When the feedback says that the rule was successfully committed it is due to the spam-wall sending the information back. After that, if the rule does not catch incoming spam, it is due to the spam-wall, hence the need for the spam-wall acknowledgements.
2. The rule I.D. column has nothing to do with the rule being stored. The only reason for the rule I.D. column is to show if there is incoming spam and what past rule was written to catch it. The alert page is not a repository of rules. It is an up-to-the-minute page showing incoming spam.
3. Attack I.D. replaced the old terminology of Message I.D. at Bright Light. It was later found that messages could have the same bodies or the same headers, but they were not the same attack due to the time it sent the message out and location it was sent from.

10. The reason for the inconsistent terminology between Bright Light’s interface and other windowing systems is that we do not want the users to think that the rules are saved in "some" hard drive. They are actually stored or embedded in a wall waiting to catch spam.
11. The reason the system does not give a hint at writing a rule is because the rules are written in Regular Expressions. It is a language based in the UNIX environment. If there were any aids at writing a rule it would amount to a large help file of which the company already has on the company intranet.