IS2470 Interactive System Design
IS2470 Interactive System Design
Spring 2003
Instructor: Peter Brusilovsky
*** Final Project ***
LZW Compression
April 22, 2003
Grant Friedline
Robert Frankeny
Thomas Sutcavage
CONTENTS
Client
Client/User Requirements
Background
Project Goal
Methodology
Task Analysis
User Goals
TASKS, ACTIONS, and WIDGETS
User Study
Interface Drafts and Prototypes
Heuristic Analysis
Online Documentation
Implementation
Original Implementation
Current Implementation
Meetings with Client
Final User Meeting
Limitations of the System
Future Enhancements
Group Contributions
Reference
Ten Usability Heuristics
Task 1 ENCODE
Task 2 DECODE
Screen shots
Prototype 3
Prototype 4
Client
Our client is Dr. Michael Spring, professor at University of Pittsburgh School of Information Science. He provided the topic and the core requirements of the LZW compression applet. The “users” for this applet will be current students of Dr. Spring classes and students in the Information Science program.
Dr. Spring teaches a course called “Document processing” which deals with compression and de-compression of documents and images, among other topics.
Client/User Requirements
Dr. Spring requested that this applet display to the user the compression and de-compression of an array of characters. The Encoding (AKA compression) shall display the character typed and the corresponding dictionary code saved. The Decoding (AKA decompression) stage shall show the code dictionary being processed and the resulting output.
Background
The LZW compression was originally programmed by Abraham Lempel and Jacob Ziv and was first published in in1977. Then in 1984, Terry Welch made a modification to code which became very popular and was dubbed LZW.
The basic concept of LZW compression is very simple. Most files wither text, databases, or images, have strings of data that repeats often. The LZW program creates an array to store part of each string. A dictionary is built to alias each group of elements in the string. When redundant patterns are read in, only the alias value is stored/sent. Here is an example from School of Computing Science, Simon Fraser University. The author looks at the string “ the ”. “With the spaces, the string takes 5 bytes, or 40 bits to encode. But what if we were to add the whole string to the list of characters after the last one, at 256. Then every time we came across " the ", we could send the code 256 instead of 32,116,104,101,32. This would take 9 bits instead of 40 (since 256 does not fit into 8 bits).” You can read more from this report at
Project Goal
The main goal of this project is to develop a Web-based, Java applet, interactive system that can be used by a student to learn the basic concepts of LZW compression. The system has been developed using java and JApplet and Swing. By using this applet, the user should be able to understand the basic concept of LZW compression.
Methodology
The applet has two main functions, Encode and De-code. The first section is the compress (or encode). The second section is de-compress (or decode).
Task Analysis
User Goals
The goal of building this applet is to demonstrate the LZW compression methods. This applet will allow the user to type in characters and the user will see how repeating combinations are handled.
TASKS, ACTIONS, and WIDGETS
As each letter is processed, the user will be able to examine the applet to see what is going on by looking at the picture of memory (a.k.a. dictionary), the output, and the explanation.
1. Start Applet
1.1 Load and run applet
1.1.1 Bring up web browser to our site
1.1.2 Read the instructions
1.1.3 Scroll down to see the applet
2. Compression
2.1 Select “Encoding”
2.1.2 Click on the toggle button until reads “Encoding”.
2.2Press the “START ENCODING” button to process the next character.
2.3Observe the dictionary entries and comments as each letter combination is added.
2.3.1 Return to step 2.2 until done. The “START ENCODING” button will gray out when there is nothing left to encode.
3. Decompression
3.1 The decoding function becomes active once the entire string was been encoded. Or you can click on the decompress toggle button until reads “Decode”.
3.2 Click “START DECODING’ until entire encoded string has been decoded.
4. Start over
4.1 To start over, press the “START OVER” button.
4.2 Start over will reset the active process, encoding or decoding.
User Study
Although Dr. Spring is our client, the intended users for this project are students of Information Science who do not fully understand LZW compression. Our main type of user study was doing interviews.
We interviewed 10 students questions which we felt would best provide heuristic feedback. The following questions were personally asked of the users.
The questions were as follows:
1) Do you understand what the applet is doing? y/n … if no, elaborate
(This question’s intent was to hint at the Heuristic of speaking the user’s language)
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.
2) Does it feel like any buttons are missing from fulfilling the goal? y/n … if yes, please elaborate
(This question’s intent was to hint at the Heuristic of simple and natural dialog)
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.
3) Are the comment descriptions that appear on the applet informative? y/n … if no, please elaborate
(This question’s intent was to hint at the Heuristic of feedback)
Yes (9 responses)
No (1 response)
The “no” response suggested that some animations be used.
4) At any point, do you become stuck as to what to do next? y/n … if yes, please elaborate
(This question’s intent was to hint at the Heuristic of error prevention)
Yes (3 response)
No (7 responses)
Of the “no” responses, some users were tempted to click inside the text fields that were used for visual purposes only.
These questions brought up some suggestions that are discussed below.
Interface Drafts and Prototypes
Example 1:
A functioning LZW applet was found online at
We liked the following features of this applet.
- The ability to type in any characters.
- The displaying of the code assigned to the “group” of characters.
- The simple design of the applet.
Prototype 1:
- As impressive as the ability to encode/decode a multitude of characters was,
the task at hand appeared impractical to design an educational tool to display an extensive dictionary. The process of encoding and decoding can be better shown using a smaller sample dictionary. Using a small dictionary provides clarity over functionality, which is desirable for our educational purposes for Prototype 1.
- For Prototype 1, a Decoding String field was added to the design to display the results of the decoding process. Also, a Clear Button and an Encoding/Decoding Toggle Button provided desirable options for Prototype 1.
Prototype 2:
- Prototype 2 incorporated comments displayed directly on the applet. These comments were associated to the tasks being currently carried out. The general purposes of these comments were to 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.
Prototype 3:
- A combination of a review seminar with Dr. Spring and a review of our user surveys combined to produce a few modifications for the third prototype. Dr. Spring suggested that we should read in a string instead of having the user input a manual string, and so this modification was made.
Prototype 4 (final):
- 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 been 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.
Heuristic Analysis
Heuristics tested in the user interviews included a) Speaking the User’s Language, b) Using Simple and Natural Dialogue, c) Providing Feedback and d) Error Prevention
The strongest of these Heuristics appeared to be Providing Feedback and Speaking the User’s Language, thanks in part to the comments that accent the current task that the system is performing.
The weaker of our Heuristics appeared to be Using Simple and Natural Dialogue (which appears to hint at the need for User Preferences) and Error Prevention (which could be greatly enhanced with exception handlers to block Users from modifying visual-only fields.
Our applet does its best to prevent errors, however, after reviewing some of the user interviews, it may be a significant upgrade to somehow mark the text fields that are only for viewing as a grayed-out color or some other color than white, to designate that boxes on screen are not for user input but only for data representation.
Online Documentation
The applet launches inside a webpage. Within the same webpage, clear, simple, and precise instructions are provided for the user. The applet is limited to a few actions, so extensive help or on-line documentation is not necessary.
Implementation
Original Implementation
The system is implemented using Java applet technology. The GUI interface is built with Java components such as JButtons and JTextAreas. The layout was done with a Box Layout design.
Current Implementation
As in the original implementation, the system is implemented using Java applet technology and the GUI interface is built with Java swing components.
Due to the constraints of applets, we discovered that our layout was extremely difficult to execute the desired location of buttons and fields on the applet. The layout used for this implementation was a Box Layout, but in future enhancements another Layout could be considered and may be a significant upgrade. Also, counters in the code seemed to be tricky. These problems could be overcome with more java experience, perhaps.
Meetings with Client
- Initial meeting with Dr. Spring April 7, 2003. Received details on what the applet should accomplish, background about LZW, and what the user should learn from using the applet,
- We presented the prototype 2 to Dr. Spring April 21, 2003. Dr. Spring ran through the system and said that he was impressed with our execution of the algorithm. However, Dr. Spring expressed that he could have given us some more requirements at the start to enhance the product. His feedback prompted the changes that are in prototype 3.
- Final meeting, see below.
Final User Meeting
Prototype 3 was presented to Dr. Spring April 22, 2003. He made the suggestions that are described in the Prototype 4 section of this document.
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.
Future Enhancements
Future versions of the applet could include animations along with comments concerning the system’s actions. Also, the ability to edit the original dictionary and or encode a string manually could be provided as options in a future prototype, along with user preferences in general. A display to indicate the ratio of compression would validate the process, but not add much to the user learning the theory.
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 HTML Help page
Reference
Ten Usability Heuristics
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.
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.
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. Any such information should be easy to search, focused on the user's task, list concrete steps to be carried out, and not be too large.
“I originally developed the heuristics for heuristic evaluation in collaboration with Rolf Molich in 1990 [Molich and Nielsen 1990; Nielsen and Molich 1990]. I since refined the heuristics based on a factor analysis of 249 usability problems [Nielsen 1994a] to derive a set of heuristics with maximum explanatory power, resulting in this revised set of heuristics” [Nielsen 1994b].
Task 1 ENCODE
Task 2 DECODE
Screen shots
Prototype 3
Prototype 4
1