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

Christopher Octa

3rd Year Computer Science
Visualization, Education Technology & Database Management

The extra credit assignment is here... Octa's Extra Credit Assignment Page

Hobbies include anime, video games and playing music.

CoWeb Assignments

CoWeb Assignment 03

Extreme Programming
In pair programming, there are two roles: the driver and the navigator. The driver is actively typing and thinking about the methods they are creating and the navigator thinks how this method the driver is coding fits into the class. The roles flip from time to time. It's like a car scenario. The driver of the car focuses on the road he sees in front of him and the navigator thinks about the streets the driver is taking in correlation to the entire trip from start to destination.

The role of unit testing is to ensure that the programmers set solid goals to focus on rather than potentially be aloof in what it is they're trying to achieve. Before programming, unit tests are createdand the programmers strive to meet the passing of these tests. Also, a user story have special tests that function the same way as unit tests known as acceptance tests. These tests are derived from the story and are merely used to test expected results of the software. Completing all acceptance tests successfully completes a user story.

The maxim "you are not your user" means what it means. When considering designing interfaces for maximum usability, it is emphasized that the designer considers the user of the system. Sometimes common mistakes such as assuming too much may lead to a less usable system than originally predicted. By actively thinking that a user interface is going to be used by a user that is not the designer themselves, it encourages them to think more actively about the target user of the system and potentially make less mistakes in complicating the system too much. The designer assumes less and by not assuming himself, this leads to other small misleading assumptions like knowledge of the programming language, knowledge of experience using the computer, and knowledge in assuming certain task executions that appear novice to the designer but advanced for the user.

A mistake made by the user is characterized by the user incorrectly assuming a procedure they want to execute in the program and a slip made by the user is characterized by the user correctly assuming the procedure they want to execute but incorrectly execute this procedure. Mistakes can be removed by careful consideration of the users when designing the software, but slips can't be removed by design but rather can have negative feedback minimized.

Examples of natural mapping are found a lot especially in graphics design software. For example, the buttons that have a magnifying glass and a + or a - hint at the user that these buttons most likely zoom in and out on an image. A button with an image of a pencil hint that it is a tool for drawing on an image as if they were using a pencil. The same goes if this button had the image of a paint brush. If a user uses a software and can immediately correlate various features on a GUI to specific actions without trial and error, then the designer has achieved a good natural mapping of the buttons in the GUI.

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 execution is used to explain the gap between what the user wants to achieve and the steps required to achieve that goal. For good usability, designers would strive to minimize this gulf of execution as much as possible so that users think less and succeed more in their actions. If a person walked through an entire jungle spanning miles, surely the user may likely get lost at some point in this hike or get ambushed by ravaneous animals (unforseen obstructions). If this jungle spanned only a couple feet, then the person could probably sprint through this jungle without giving second thought to what they are doing and focus on the goal at hand (exiting the jungle). This jungle could be analogous to this gulf of execution.

The gulf of evaluation is the gap between how a user interprets a system to what the system actually does. The gulf is small if a user's perceived intepretation of the system closely matches what the system actually does. The same way goes for user interfaces and how functions of buttons are perceived versus their actual funtion. Having good natural mappings can help decrease this gulf of evaluation, the gap between perceived versus actual. As a real world example, Norman points out in "The Design of Everyday Things" of a seat adjustment system in a Mercedes car has great natural mapping. The controls that adjust the seat are arranged to look like the seat itself and tilting parts of this control adjust the seat in a similar fashion (i.e. tilting the control that looks like the backrest of a seat back would tilt the seat back as well). For a system like this, the gulf of evaluation would be small as the user can look at this seat and be able to perceive how this seat adjustment system works with accuracy and within a short amount of time.

CoWeb Assignment 02

CRC Cards

Model View Controller

The MVC (model view controller) is a method of creating software. The biggest and most important point about MVC is flexibility. Let's take a popular video game for example, like World of Warcraft (WoW), and apply this MVC concept. The model would be represented by the internal game mechanics of WoW (calculations of everything and databases of items/monsters/etc). The view is what the user sees, a 3D rendering of the world. The controller is what the user has to interact with this video game. Whenever the user wants to move their character by keyboard clicks or mouse clicks, the view is updated rerendering itself to adjust what the user sees next. When a character buys an item from a merchant or auction house, the controller affects the model by accessing a function that essentially submits x amount of gold for an item, and in turn the model edits the database by subtracting the correct number of gold and edits the character database to insert this new item the character bought. At the same time, the model may send an update to the view on how much gold the character has left because the view may be displaying it on the screen. If the character enters a different zone or exits into the login screen, the view may affect the controller by disabling certain key bindings or allowing new ones.

In short, the controller may "alter" the model or view depending on the input, the view may "affect" the controller by accepting or deny certain input, and the model may "affect" the view by updating data that is linked to the view. Because of information hiding, one may be able to freely edit code from either the model, view, or controller without having to heavily make changes to the other two parts that weren't being targetted for editing. It is flexible in one sense that a user interface may be changed freely without worrying about breaking the insides of the model or a model can be altered in whatever way it wants to since the view displays whatever it gets from specific model functions like a database.

In the long run, it makes changing around features in software much easier. For the most part, UI design is something that is always changing, for example. If everything was scrambled into one module that handled everything, what happens when beta users aren't happy with the layout of a software? It would be a pain to track all the components in the UI and to rearrange them around or redesign the layout while making sure not to accidently break the mechanics it contains (data, calculations, etc).

CoWeb Assignment 01

Video Professor: Because reading is HARD.
This case provides a very useful introduction to Squeak in a very convenient form, streaming video demonstrations. The best way to aid in providing an easier understand to something new is through examples and demonstration. Audio/visual forms of these examples and demonstrations I find very much so easier and faster to comprehend than reading a book with instructions.

Index of Tutorials and Generally Cool Squeak Things
While not as vivid as the first case, this page provides a plethora of information organized into different categories such as examples or text tutorials. The page makes it easier to find other beginner information on Squeak primarily because another student has done the same thing going through and picking out the most useful links.

Mini Java-to-Squeak Tutorial
A good page showcasing how to jump from Java to Squeak with several of the more common syntax that may be used. Simply showing the Java way and the Squeak way. Since most students taking Squeak will probably be most familiar with Java prior to the course, this provides a smoother segway into some of the programming structures of Squeak.

The Squeak Wonderland Tutorial
While 3D graphics is outside of the scope of the course, the interactive tutorial allows the user to follow along by entering the same commands through the Squeak interface. It provides another way of getting the student familiar with Squeak because of simply performing in order to obtain a desired result as shown in the end of the tutorial. Popular teach yourself books use this method (i.e. Adobe in the Classroom) where a complex creation is obtained by the user by following along.blahblahblah
While it doesn't really teach anything, it showcases a final project running without the need of Squeak (through a video that recorded the animation project). I just thought it'd be more convenient to see final projects in video form than having to run it through the Squeak interface.

Link to this Page