View this PageEdit this PageAttachments to this PageHistory of this PageHomeRecent ChangesSearch the SwikiHelp Guide
Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007

Aaron St.Clair

Coweb Assignement 3:

Usability (2 Points)
You've learned about three usability evaluation techniques in this class: heuristic evaluation, cognitive walkthrough, and observing users. Compare and contrast two of these. What are the strengths of each approach? What are the weaknesses? When are they appropriate to use? Why would you choose one over the other?

Heuristic evaluation of a program involves an independent evaluation team judging an interface using a set of heuristics as a guide. Any usability bugs found by the evaluators are recorded and described. The evaluation team then meets and organizes their list of bugs, assigning each a severity rating based on how frequency, impact, persistence, and market impact of the bug. This list of bugs is then given back to the design team as recommendations for revision. Observing users is another technique for evaluating an interface. The general method for this type of evaluation is to observe someone who is not familiar with the project interacting with the system. Generally, it is also beneficial to record the user's thought process as they interact with the system by either having them talk aloud as they use the interface, or by recording their actions somehow and asking them to describe their thoughts at a later time.

User observation is probably one of the best evaluation techniques for a system because it involves real users from the target audience using and evaluating the program. This provides the designers with useful feed back from the end-users themselves. Unfortunately, this requires finding people from the target audience willing to sit down and actually test the interface and recording their thought processes and expectations of the interface as accurately as possible without influencing them in anyway, which could be difficult since most people do not describe their actions aloud during normal use. For these reasons a heuristic evaluation may be the next best thing for finding bugs. Given a large enough team of evaluators, most bugs will indeed be found and although the feedback may not be as useful as that of members of the target audience, it is generally easier to conduct a heuristic evaluation than user observation. Furthermore, since the evaluators record their own thoughts it would be more difficult to influence their thinking than it would to influence a user while observing them. The heuristic evaluation is limited however in that it can only be as good as the heuristics that are being used. If insufficient heuristics are used to evaluate the interface bugs could slip through the cracks. This could also happen if the evaluators are not thorough in their evaluation.

In summary, a user observation evaluation would be most appropriate when a fully-working prototype and users from the target audience are available and the evaluators are careful to conduct the observation in such a way as to record a user's thought processes without influencing them. If the feedback from an actual user is desired, possibly because the target audience is a specific group (say children for example), user observation is really the only way to judge the interface from a user's point of view. A heuristic evaluation, on the other hand, provides useful feedback in the form of a bug list and could be used to find most bugs relatively quickly and easily assuming a good set of heuristics is used and the evaluators are thorough. The severity rating assigned by the evaluation team might is also an added benefit when choosing this evaluation technique.

Design Patterns (2 Points)
(Part A) Besides its name, name three characteristics commonly used to describe design patterns. For each characteristic, describe what it is and why it is useful? (Part B) Observer, Adaptor, and Factory are three design patterns described in this class. For two of these three, briefly describe them using the characteristics you chose.

Besides their name, design patterns are also described by three other characteristics:


Coweb Assignment 2:

The Debugger

The debugger is a useful tool that allows you to easily trace execution of a program and find sources of errors. To use the debugger click debug in the pink system window that opens when an error occurs. You can also halt execution and open a debugger anywhere in your program by including the line:
self halt

Uploaded Image: debugger.jpg

The debugger allows you to view and edit the code of your program during execution. You can step through line by line and see how the state of current variables in scope change to find bugs in your code. The value of any class or temp variable can be viewed by clicking on it in the bottom list. For class objects that don't show useful information you can also right-click on a variable and inspect its contents.

The debugger also has a few useful tools that let you see exactly what your code is doing line by line:

Coweb Assignment 1:

Tracing Code (1 point):
The following code solves the rainfall problem, which you may have seen in previous CS classes. For each line, describe what the Smalltalk code does. Be as specific as possible. In particular, what is data at the various points in the code?

| data onlyPositiveNumbers |

This line declares two temporary or method variables named data and onlyPositiveNumbers. At this point they are unitialized.

data := OrderedCollection withAll: #(1 2 3 -4 -5 'error' 6 -7 999 2).

This line creates a new OrderedCollection object that contains a list of values and assigns this to the variable data. At this point data contains an OrderedCollection with the values 1, 2, 3, -4, -5, 'error', 6, -7, 999, and 2. Note that the OrderedCollection does not sort the data numerically but behaves similar to an array in that the order of the objects in the collection is preserved (ie. 1 is the first element in this case, -4 is the fourth element, etc.).

onlyPositiveNumbers := [:i | (i isKindOf: Number) and: [i positive]].

This code snippet contains a block that given an object will return true if and only if i is a Number and i is positive. This block is then assigned to the variable onlyPositiveNumbers. Thus we can now use onlyPositiveNumbers as if it were a block, this allows us to send it a value by sending the message value followed by an object and it will return a Boolean based on whether the object is a number and if it is positive.

data := data select: onlyPositiveNumbers.

This line of code sends the select message to the OrderedCollection object, data, and passes the Block object, onlyPositiveNumbers. This method then iterates over all values in the OrderedCollection and removes all values for which onlyPositiveNumbers evaluates to false. Data now contains only positive numbers.

data := data copyUpTo: 999. "not including"

This line of code removes all data elements greater than or equal to 999 by sending itself the copyUpTo message, which returns an OrderedCollection with all elements less than 999 (in this case). Data now contains positive numbers less than 999.

Transcript show: data average

This line of code prints the average of the remaining values in the OrderedCollection data to the transcript.

Writing Code (1 point)
fib: anInteger
((anInteger isKindOf: Integer) and: [anInteger >= 0]) ifFalse: [^self error: 'Invalid input'].
((anInteger = 1) or: [anInteger = 0]) ifTrue: [^1]
	ifFalse: [ ^((self fib: (anInteger - 1)) + (self fib: (anInteger - 2)))].

Uploaded Image: debugger.jpg

Links to this Page