Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007
CoWeb Assignment 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?
In a cognitive walkthrough evaluation, the idea is to isolate certain tasks that a piece of software should be able to perform and to go through how a user would perform that action step-by-step. At each step, you then identify things that could go wrong which in theory will eliminate most of the chances for user error. Observing users, on the other hand, evaluates the usability of an interface by actually allowing users to interact with a piece of software and witnessing first hand which facets of that interface are easy to figure out and which could be improved.
Obviously, one strong point of using a cognitive walkthrough evaluation would be that it has the potential to make the performance of certain tasks "idiot proof." Rather than having to consult a manual to figure out how to use your program, an interface that has been thoroughly examined under a cognitive walkthrough evaluation should (in theory) be so natural that a user can go right into the program and be able to figure it out naturally. Not having to learn the system beforehand has the effect of both saving time and frustration of trying to understand the system before actually seeing it. Because this method focuses on one task at a time, however, it can be tedious trying to run this evaluation for every situation, and there's also the possibility that you may overlook a situation that turns out to be fairly important.
The main strong point of observing users is that it saves you the trouble of having to guess which usability issues are the most important to resolve. By observing users who have never seen the software before, you can get a general idea of how the average user might interact with the program. You might even become aware of a problem that you didn't even know existed. This method also allows you to gather real data on which usability issues came up most often and, thus, which should be the highest priority for redesign. On the other hand, there could be issues with the subjects you choose to test the usability. If you only tested the program with students familiar with programming, for example, it could cause you to overlook a more significant issue that could affect a greater percentage of the potential user base.
Deciding when to use one over the other can be tricky. If you have a good idea of which tasks will be the most important and most frequently performed, a cognitive walkthrough can help you streamline these tasks exclusively. If you're not really sure which areas need improving and you're looking to get a fresh perspective, observing users will normally make it pretty obvious which areas of an interface need to be worked on.
Language Features (2 Points)
Squeak is perhaps the least well documented programming language you will ever use; however, Smalltalk and the Morphic GUI compensate for this by being pokable (easy to explore). There are many language features and tools for exploring Squeak. For four of these, name them, describe how you use them, and explain why they are useful.
Probably the most important tool in Squeak is the System Browser. Squeak, unlike Java, doesn't really have any kind of API. This means that it can be confusing to find out exactly what classes and messages already exist within the environment and how to use them correctly. The System Browser is pretty much Squeak's version of an API. Not only can this help you find out what messages are implemented for any class in the Squeak library, but you can view and even edit the source code from the System Browser if you so desire. Instance variables, messages and their parameters, and comments are all easily viewable and editable, making the System Browser even more useful than a simple API after you've gained a little experience with it.
Even after viewing the source code for a class, you may see a method called somewhere that doesn't exist within the class itself. Depending on which class you're looking at, it could take a significant amount of time to look through all the parent classes to find out which class the method was inherited from and how it works. This is where the Method Finder can come in handy. Not only can you search by the name of the message you're looking for, but you can search based on certain arguments or the senders/receivers of a message. Essentially, this tool can save you both the time and frustration which could come from having to look for a method by hand.
Another useful tool within the Squeak environment is the Transcript. Everyone who has programmed before has used text output at some point to help them debug code. In C you may have used
printf statements, in Java you probably played with
System.out.println to fix a bug or two, and in Squeak you can use the Transcript in pretty much the same way. In Squeak, the command you'll probably use the most for this type of debugging is
Transcript showThe main way this would be used in debugging would be to check the values of various instance variables at different states in the execution of a block of code. When code is behaving in an unexpected way it can be difficult to track down exactly where the problem is occuring. By comparing the actual values of certain variables to their expected values, the time spent fixing a bad loop incorrect initialization can be greatly reduced.
Finally, the Inspect and Explore tools can be another indispensable tool when first learning Squeak. The main way I used these tools was to actually learn how morphs are created and how their appearances are manipulated based on which variables I changed. It provided an easy way to find out how to do things like change the color of a morph without first having to learn the exact syntax to do it in code. Being able to view all the instance variables helped me understand how coordinates were stored and how to properly extract or input new values for these and pretty much any other instance variable in the morph. because this information is all displayed graphically, the Inspect and Explore tools can also be used in a debugging strategy similar to how the Transcript is used.
CoWeb Assignment 2
Using Monticello To Manage Squeak Code
As we began thinking about how we would go about creating our Animation Studio for this class, Team Dirty Packets ran across the problem of how we could work on code together without creating unnecessary complexity by having to load in .st files or change sets every time someone altered the code. We knew about CVS and were looking for something that we could learn just as easily that had a lot of the same functionality. This search lead us to settling on Monticello.
Step 1: Creating a repository
Though Monticello supports multiple types of repositories, the first one that we got to work (and the one I will be referring to primarily) is the HTTP repository. For this, we had all of our group members create an account at http://www.squeaksource.com. Once this was done, one member registered a project which conveniently comes with a repository hosted by SqueakSource. The createor of the repository then went into the project administration options and added the rest of the team members as developers of the project. NOTE: There was an occasion or two where SqueakSource's servers went down and we were not able to retrieve or submit our code through the repository. This downtime, however, was generally infrequent and never lasted long enough to seriously slow down our progress.
Step 2: Accessing your new repository through Monticello
Once you've got your repository somewhere out there, you'll probably want to access it from Squeak and get some code in there or something. To do this, you'll want to start by choosing the "Open" option in the World Menu. From there, find the "Monticello Browser option and click that. You should see something come up that looks like this:
As you can see, Monticello does not yet know about your repository, so you've got to tell it where to find it and how to access it. This can be done by clicking the "+Repository" button in this window. Now you'll see something like this:
In this window (Figure 2), you'll notice three fields that need to be filled in. If you've been added to the project through SqueakSource, you can find the location of the repository by simply logging into SqueakSource and clicking the name of the project on the left hand side of the screen. Under the "Registration" heading you can see the URL which corresponds to your team's repository for that project. The user and password fields are simply the username and password you use to log in to SqueakSource.
If you did this all correctly your Monticello Browser should look something like this now:
Step 3: Managing code with your new Monticello repository
Now that Monticello knows about your sweet repository, you can actually get into it and look around, merge code, or add or save a new version of a package. First, however, you should make sure that the info you gave Squeak is correct. If you select your repository in the right pane of the window from Figure 3 and click the "Open" button you should see something like this:
If this is a brand new repository, you may not see anything in this window, but it should still come up. If you encounter some weird Squeak error, odds are that either you've given Monticello some wrong information about the repository or that SqueakSource is down. If you can access the SqueakSource site, check the information that you gave Monticello, otherwise wait until SqueakSource is back up (usually around 15 minutes at the most).
If you actually have code you want to add to a fresh repository, you'll want to go back to the window in Figure 3 and use the +Package button to add whatever packages you need to. Once you've got all the packages you want, you and your group members will be able to load, merge, and save new versions of these packages. For loading and merging, you'll be dealing with the window in Figure 4. Loading a version of a package will overwrite whatever version you have in your workspace with the version you choose from the repostitory. Merging your code with a version of a package will allow you to keep anything you've changed in your version while still ensuring that you're keeping up with the latest version of the package. For saving a new version, you'll want to go back out to the window in Figure 3. Simply select the package you want to create a new version of and click the "Save" button. You'll be prompted to enter a comment which can be useful if you need to rollback or to give you an idea of whether or not you think you need to merge or not later on.
You should now be able to use Monticello to manage your code for your Squeak project. There are more functionalities that Monticello offers for management, but I've gone over the basic ones that will allow you to at least work with your teammates without having to figure out your own way of managing/versioning your code.
CoWeb Assignment 1
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 |
In this line the temporary variables "data" and "onlyPositiveNumbers" are created to be used later.
data := OrderedCollection withAll: #(1 2 3 -4 -5 'error' 6 -7 999 2).
Here, data now refers to an OrderedCollection containing the values 1, 2, 3, -4, -5, 'error', 6, -7, 999, and 2.
As an array, data would look like this: [1, 2, 3, -4, -5, 'error', 6, -7, 999, 2]
onlyPositiveNumbers := [:i | (i isKindOf: Number) and: [i positive]].
Next, onlyPositiveNumbers is designated as a block of code which will be able to extract only the positive numbers from data, excluding anything that is not a number or is negative.
data := data select: onlyPositiveNumbers.
In this line, the positive numbers from data are selected, and the variable "data" is reassigned to point to an OrderedCollection containing only these values.
Data now looks something like this: [1, 2, 3, 6, 999, 2]
data := data copyUpTo: 999. "not including"
This line selects the values from data up to, but not including 999, and the variable "data" once again now points to a new OrderedCollection with the correct values.
Finally, data reaches it's final form: [1, 2, 3, 6]
Transcript show: data average
The remaining elements in data are now averaged and this average (which happens to be 3.25) is printed to the Transcript. LATE EDIT: As I was told today, this average is incorrect. The correct average should be 3. I should learn to add sometime >_>
Implement a method in Squeak that will give you the nth Fibonacci number. For both 0 and 1, the Fibonacci number equals 1. From then on, the next in the series is simply the sum of the previous two in the series (1, 1, 2, 3, 5, 8, 13, 21, 34, 55, etc.). Return an error when applicable. Your code should be based on good OO-style and be an efficient algorithm.
"Returns the nth number of the Fibonacci sequence"
(n < 0) ifTrue: [self error: 'Invalid input. Please enter a positive argument.'].
(n = 0) ifTrue: [^1].
(n = 1) ifTrue: [^1].
(n > 1) ifTrue: [^((self fib: (n - 2)) + (self fib: (n - 1)))].
Links to this Page