1 / 29

LZW Compression

LZW Compression. Grant Friedline Robert Frankeny Thomas Sutcavage. 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.

michelle-briggs
Download Presentation

LZW Compression

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  12. User Study • Does it feel like any buttons are missing from fulfilling the goal? • No (7 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.

  13. User Study • Are the comment descriptions that appear on the applet informative? • Yes (9 responses) • No (1 response) • 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) • No (3 responses) • 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 • Showed level of compression • Did not show decode function

  16. Interface Drafts and Prototypes • Prototype 1 • impractical to design an educational tool to display an extensive dictionary • encoding and decoding can be better shown using a smaller sample dictionary • 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 • 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 • 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. • 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. • 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. • Consistency and standards • 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. • 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. • 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.

  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. • 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. • 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 • JTextAreas • Box Layout design

  26. Final User Meeting • Dr. Spring April 22, 2003 • impressed with our execution of the algorithm • 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 • Initial Prototype Coding • HTML page for Applet • Interview questions and corresponding heuristics • Robert Frankeny • User Study • Final Prototype Coding • HTML page for Applet • Thomas Sutcavage • Testing • Prepared PowerPoint Slides • Wrote Report • Help guide HTLM Help page

More Related