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

Justin Clark

Hey, I believe I'm a fifth year CS's been so long it's hard to remember now. I had been in the ECE department earlier in my career, and that's why I'm so far behind now. I am most interested in the Systems aspect of CS, in spite of the fact that it seems the least popular at the moment. Now, onto to the assignment.

Extra Credit

I chose to do the assignment where I had to choose three useful articles from either Don Norman's or Jacob Nielsen's site and summarize and describe why they are useful. You can find the links as well as their descriptions below.

Top Ten Mistakes in Web Design

This article explains several common mistakes that web designers make when designing websites. The first few mistakes include poor search engine designs – where search engines make searches too literal, without offering suggestions for misspellings. Small fonts, links that don't change colors, pop-up windows, PDF files, and open-in-new-window browsing also offer confusion for the user and lead to poor usability in a website. The bottom line appears to be design a website that is consistent with most other websites with good, but succinct, information in a logical order without changing formats frequently. Usability in websites is important to any computer science student, because websites are inevitable when creating a product and marketing it to a consumer. Website design can also follow into program design, especially when considering formatting, like fonts, colors, text size, and readability.

Usability 101: Fundamentals and Definition

As the title of the article suggests, it defines usability, gives a few examples of how to test for usability, and explains why usability is important to a company. What is most important is testing usability. Programmers and designers need a small group of users to observe while using a particular program or website and take notes on how easily each user navigates the product. Then a designer can make changes wherever difficulties emerge and make a better product. Usability is important to programmers, especially when using object-oriented design, to make programs that are marketable to consumers. A program that is difficult to use is a program that will not sell well. The article outlines the importance of usability and fairly easy ways to test and design with the user in mind.

Usability is Not a Luxury

Norman and Nielson explain the importance of usability in consumer-driven websites in this article. They performed an experiment for finding an inkjet printer, only to find that Epson, Canon, and HP's websites were incredibly difficult to use, instead opting to purchase from Amazon. They explain that 90% of websites today have extremely poor usability, and people go back to the same websites over and over again because they know they work. A website needs to be easily navigable within the first few seconds of looking at the home page. The most important parts, like products available, pricing, and some information about each product should be accessible within the first viewing of the site. Because users can so easily switch to a different website when looking for information or making purchases, a website needs to be flawless in ease of use and design. This is important for computer science students because they need to know how to make websites usable. The article also offers a simple self-test for a student to perform to really see how poorly-designed most websites are, even those that are selling a product with a highly-recognizable brand, say HP.

CoWeb Assignment 3:

Extreme Programming (1 point)

Describe in detail how pair programming is done. What is the role of pair programming in extreme programming?

Pair progamming is a programming technique where two programmers work on the same code at the same time. The two roles have the titles of navigator and driver. The driver is the one that is sitting at the driver's seat so-to-speak. This driver is the one that sits at the workstation and physically types in the code. The other programmer (the navigator) aides the driver by looking up questions in the API, thinking about the logic being coded, or watching for mistakes made by the driver.

What is the role of unit testing in extreme programming?

Unit testing in extreme programming is quite different from regular programming. In extreme programming, the unit tests are actually written before the code. They make sure that certain parts of the program aren't broken during refactoring, the stage where source code is cleaned up to fix problems.

History of OO (1 point)

What was the first object-oriented language? What two elements, kept separate in structured programming, did it combine?

The first objected-oriented language was called Simula I. It combined procedures and data into objects.

Name three contributions to computing that were made at the learning research group at Xerox PARC?

Three contributions to computing made at Xerox PARC include WYSIWYG, ethernet, and the graphical user interface.

Usability (1 point)

Don Norman provides a simple framework for explaining the interaction between people and the physical world. As part of that framework, he identifies two “gulfs”: the gulf of evaluation and the gulf of execution. Describe these and provide an example of each gulf in a situation of a user interacting with a computer application.

The gulf of evaluation is the gap between a user's goals and the means for the user to execute those goals. The gulf of evaulation is the he difference between how the system is perceived and what it can actually do. An example of the gulf of evaluation is when a user desires to open a new tab in a web browser, but finds no means of opening one (I'm looking at you Safari!...the hidden option in preferences). As an example of gulf of evluation, consider a user primarily experienced in using Firefox who must start to use Microsoft's Internet Explorer. Perhaps the user believes that it's possible to open tabs or add extensions, but eventually finds that Internet Explorer is completely incapable of doing these tasks.

CoWeb Assignment 2:

Tracing Code (1 point)

The following Smalltalk statements are written in a Squeak Workspace. In order from top to bottom, you execute each statement with Alt-p to print its result. Next to each statement, write the result.

1 + 2 * 3 – 4 factorial

a := #(1 2 3 4 5)
#(1 2 3 4 5)

a select: [:i | i odd]
#(1 3 5)

b := a
#(1 3 5)

a := a reversed
#(5 4 3 2 1)

b collect: [:i | i * i]
#(1 4 9 16 25)

a perform: #at: withArguments: #(4)

Message Passing (1 point)

Smalltalk is built on a few uniform design principles. One of these is that computation happens through message passing: An object gets sent a message (perhaps with some arguments) and returns an object. Even traditional control structures (while loops, for loops, if/then/else) are implemented through message passing. For each of the control structures below, translate the Java code into Smalltalk. For each part, indicate what is the object, what is the message, and what are the arguments.

while loop

while (aBooleanTest)
   // do stuff

[aBooleanTest] whileTrue:
  ["do stuff"].

Object: aBooleanTest
Message: whileTrue
Arguments: do stuff...or whatever is inside the brackets following the colon

for loop


for (i = 1; i = 10; i++)
   // do stuff

1 to 10 do:
	[ :i |
            "do stuff"

Object: 1
Message: to, do
Arguments: 10 and the do stuff...or whatever is inside the brackets


if (aBooleanTest)
{   // do stuff
{   // do stuff

         "do Stuff"
         "do Stuff"

Object: aBooleanTest
Message: ifTrue, ifFalse
Arguments: the "do Stuff" parts...or whatever is inside the brackets

Below here are my Case summaries for CoWeb Assignment 1:

Bumblebee TunaThis site lists some great tips on how to get starting working on a large project in Squeak. Some of the tips they suggest are like giving up on DVS if you cannot get it to work out. They also thoroughly recommend the use of change sets for all changes to the repository. They mention the numerous problems they ran into by merely uploading the .st files to the repository and making changes to them. They also discuss the merits of using a clean, updated image of Squeak. They also give several more common sense ideas, such as meeting frequently and taking the planned schedule seriously. They also describe in great detail the disadvantages of having a very poor documented API with which to work.

Team 2 + 2 = 4

This link is to the Team 2 + 2 = 4 Cases. For the most part this site lists some redundant tips on how to form a group, and work together. However, I found their tips regarding the design phase of their project quite interesting. One good suggestion they had was to make the CRC cards and scenarios before starting their UML diagram. They found that after creating good CRC cards and scenarios, drawing the UML diagram was a breeze. To sum up this portion of their case: first start desigining your scenarios, then begin designing your CRC cards around the scenarios. Lastly, they suggest completing the design phase as a group as opposed to assigning parts of the project to group members and having them complete them on their own.

Some progress using CVS with Squeak (or: Standing on the Shoulders of Bears)

This case mainly describes way to use CVS and some of the problems the group ran into along the way. They also have some tips on using the "explore morph" feature of Squeak, and how to perform task using the command line instead of the mouse. They also describe some problems they ran into using CVS, such as different team members using different operating systems, and problems using merge with Squeak and Windows. They also list solutions to most of the CVS problems they ran into. Another example problem they had was that if a subclass was submitted before a superclass, then the subclass would have a superclass of nil. They solved the problem by submitting all code twice, and this action seemed to fix the problem for them.

The REAL A-Team Case Page

This one has some great tips on most things non-technical. It has some great tips on how to find group members, assigning tasks to each member, frequency of meetings, working on code as a group, and how to handle school holidays (true this is much less helpful for this semester, but it still has its merits). They also preach the benefits of using change sets for managing files (I've seen this on several other cases). They even lists some great pages in the book to familiarize yourself with them. Probably my favorite section from any site was on this one. They were one of only a few sites that discussed out ability to reuse old code from past semester. They also went on to warn that this wasn't always the best practice, and that oftentimes it is much easier to reimplement your own code. Although not a particularly surprising idea, I was glad to see it at least once.

How to make good CRC cards and Scenarios

Although rather short, this site lists some great tips on making good CRC cards and scenarios. They start out showing how a CRC card should not be done, and go through each of the errors in the card and describe exactly what's wrong. They also go over some general good tips on making CRC cards, such as being more specific and using terminalogy that the user can understand. While this link is rather short, I also believe it has a really direct explanation.

Links to this Page