1. LZW Compression Grant Friedline Robert Frankeny Thomas Sutcavage

2. Client Dr. Michael Spring, professor at University of Pittsburgh School of Information Science The “users” for this applet will be current students of Dr. Spring classes and students in the Information Science program

3. Client / User Requirements Encoding (AKA compression) shall display the character typed and the corresponding dictionary code saved Decoding (AKA decompression) stage shall show the code dictionary being processed and the resulting output

4. Background LZW compression was originally programmed by Abraham Lempel and Jacob Ziv Terry Welch made modification 1984 which increased its usability Dictionary is built to alias each group of elements in the string

5. Project Goal Develop a Web-based, Java applet, that can be used by a student to learn the basic concepts of LZW compression

6. Task Analysis User Goals TASKS, ACTIONS, and WIDGETS 1. Start Applet 2. Compression 3. Decompression 4. Restarting

7. The LZW applet Demo Robert Frankeny www.sis.pitt.edu/~frankeny/LZW

8. Encoding

9. Decoding

10. User Study Main type of user study was doing interviews Interviewed 10 students questions which we felt would best provide heuristic feedback

11. User Study Do you understand what the applet is doing? Yes (8 responses) Yes (8 responses) No (2 responses) No (2 responses) The “no” responses were not sure where the original string to be decoded came from. After explanation that the original string was arbitrary, understanding for its purpose became less of an issue. The “no” responses were not sure where the original string to be decoded came from. After explanation that the original string was arbitrary, understanding for its purpose became less of an issue.

12. User Study Does it feel like any buttons are missing from fulfilling the goal? No (7 responses) No (7 responses) Yes (3 responses) Yes (3 responses) Of the “yes” responses, 2 inquired about the possibility of encoding a string manually. 1 inquired about a way to manually modify the original dictionary. Of the “yes” responses, 2 inquired about the possibility of encoding a string manually. 1 inquired about a way to manually modify the original dictionary.

13. User Study Are the comment descriptions that appear on the applet informative? Yes (9 responses) Yes (9 responses) No (1 response) No (1 response) The “no” response suggested that some animations be used. The “no” response suggested that some animations be used.

14. User Study At any point, do you become stuck as to what to do next? Yes (7 response) Yes (7 response) No (3 responses) No (3 responses) Of the “no” responses, some users were tempted to click inside the text fields that were used for visual purposes only. Of the “no” responses, some users were tempted to click inside the text fields that were used for visual purposes only.

15. Interface Drafts and Prototypes Example Applet available on the web for LZW Applet available on the web for LZW Showed level of compression Showed level of compression Did not show decode function Did not show decode function

16. Interface Drafts and Prototypes Prototype 1 impractical to design an educational tool to display an extensive dictionary impractical to design an educational tool to display an extensive dictionary encoding and decoding can be better shown using a smaller sample dictionary encoding and decoding can be better shown using a smaller sample dictionary Clear Button and an Encoding/Decoding Toggle Button provided desirable options Clear Button and an Encoding/Decoding Toggle Button provided desirable options

17. Interface Drafts and Prototypes Prototype 2 incorporated comments displayed directly on the applet incorporated comments displayed directly on the applet elaborate on the calculations being derived behind the scenes in an effort to convey the encoding/decoding method to the user in an interactive way elaborate on the calculations being derived behind the scenes in an effort to convey the encoding/decoding method to the user in an interactive way

18. Interface Drafts and Prototypes Prototype 3 review with Dr. Spring and a review of our user surveys combined to produce a few modifications for the final prototype review with Dr. Spring and a review of our user surveys combined to produce a few modifications for the final prototype Dr. Spring suggested that we should read in a string instead of having the user input a manual string Dr. Spring suggested that we should read in a string instead of having the user input a manual string

19. Interface Drafts and Prototypes Prototype 4 (final version) Following another meeting with Dr. Spring, the fourth prototype evolved. This version contains two dictionaries, one for encode, one for decode. This version moved from Box layout to border layout. The clear button has be replaced with a Start over button. The Start over button can be used to back up to see the prior process. The input is hard coded. This assures repeating character strings. It also prevents the user from entering an illegal character (this prototype has limited dictionary capabilities). The display boxes have been set to read-only. This was done because some users were temped to type in the display box.

20. Heuristic Analysis Speaking the User’s Language Using Simple and Natural Dialogue Providing Feedback Error Prevention

21. Heuristic Analysis strongest of these Heuristics appeared to be Providing Feedback and Speaking the User’s Language weaker of our Heuristics appeared to be Using Simple and Natural Dialogue

22. Heuristic Analysis by Jakob Nielsen Visibility of system status The system should always keep users informed about what is going on, through appropriate feedback within reasonable time. The system should always keep users informed about what is going on, through appropriate feedback within reasonable time. Match between system and the real world The system should speak the users' language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order. The system should speak the users' language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order. User control and freedom Users often choose system functions by mistake and will need a clearly marked "emergency exit" to leave the unwanted state without having to go through an extended dialogue. Support undo and redo. Users often choose system functions by mistake and will need a clearly marked "emergency exit" to leave the unwanted state without having to go through an extended dialogue. Support undo and redo. Consistency and standards Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions. Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions.

23. Heuristic Analysis Error prevention Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Recognition rather than recall Make objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate. Make objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate. Flexibility and efficiency of use Accelerators -- unseen by the novice user -- may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions. Accelerators -- unseen by the novice user -- may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions.

24. Heuristic Analysis Aesthetic and minimalist design Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility. Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility. Help users recognize, diagnose, and recover from errors Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution. Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution. Help and documentation Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation.

25. Implementation Java applet technology Java components JButtons JButtons JTextAreas JTextAreas Box Layout design Box Layout design

26. Final User Meeting Dr. Spring April 22, 2003 impressed with our execution of the algorithm impressed with our execution of the algorithm expressed that he could have given us some more requirements at the start to enhance the product expressed that he could have given us some more requirements at the start to enhance the product

27. Limitations of the System Due to time constraints we were unable to come up with code snippets to cover all of the possible issues. The input sting to be encoded is fixed. The dictionary is not customizable.

28. Future Enhancements animations along with comments concerning the system’s actions ability to edit the original dictionary and or encode a string manually user preferences

29. Group Contributions Grant Friedline Wrote Event Handler & Prototyping Wrote Event Handler & Prototyping Initial Prototype Coding Initial Prototype Coding HTML page for Applet HTML page for Applet Interview questions and corresponding heuristics Interview questions and corresponding heuristics Robert Frankeny User Study User Study Final Prototype Coding Final Prototype Coding HTML page for Applet HTML page for Applet Thomas Sutcavage Testing Testing Prepared PowerPoint Slides Prepared PowerPoint Slides Wrote Report Wrote Report Help guide HTLM Help page Help guide HTLM Help page