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

When Lobsters Attack Cases

M1

M1 Requirements:

What worked?

What didn't work?

Creating CRC cards correctly proved to be difficult, specifically:

What should have been done differently?

M2

M2 Requirements:

What worked?

What didn't work?

What should have been done differently?

M3

M3 Requirements:

What worked?
By the arrival of the M3, we had thoroughly sketched out our domain classes. Our model for representing a "project"
as a very simple structure compromising pretty much of data holders which would strictly follow good O-O design. Outside
of this, our design was a bit more ambiguous, but pretty solid.
We were easily able to brainstorm some decent UI design that would be very simple,but easy to navigate and robust enough to cover all the functionality a user would need in creating a project. The core of our UI design was to crfeate a multiwindow application that would open and close windows as they were needed, much like Visualworks. This way we could afford to make very simple, intuitive displays with colorful graphics, because any window never had too many input fields that the user had to decipher. To access more complicated functions, a user would open dialogue windows that would request the required additional information. Futhermore, a multiwindow display allows a user to deal with several project aspects simultaneously. A user can, for example, edit two crc cards at once, while also editing the scenario that will later test those cards. This allows a much greateer degree of flexibility for brainstorming and jotting down several loose ideas, which is usually what project planning is all about


What didn't? and how could we have done things differently
Being confident in your data models and UI design is, however, not enough. They're the easy part. We came into this stage of the project with very little experience coding smalltalk. Soduku HW1 won't teach anything, except that you probably don't now anything about smalltalk. Take this lesson to heart. So, far in advance of the deadline of this part of the project, sit down with a few online tuturials and become very familiar with how to get things to work in this language.
If your unfortunate enough to be the one woring on the GUI aspect of your project, you'll need to learn a lot about how smalltalk's listener/contorller tools work (i.e. update/changed messages and the like). This is essential to making a good MVC design. SmallTalk has some very good and neat stuff for gui controllers. Choose which ones will work for your application design and implement them from the beginning. DO NOT HACK THIS PART OUT. Frustrated with smalltalk and faced with the impending deadline, I did this. I won't tell you what I did, but it was pretty disgusting. Try not to tackle this part alone either. This is disproportionally large compared to the other parts of the final project. Have at least two people working on the controllers and gui, both who know what they are doing and have the most time. It will be impossible for another to jump in afterwards to help. Both people should start very early on learning and planning. When you need to get to coding, you will fare much better than us. PLEASE START EARLY ON M3!!!


M4

M4 Requirements

What worked?

What didn't work?

What should have been done differently?

M5

M5 Requirements:

What worked?
We decided not to use heuristic evaluation, because we felt our sample size would have been too small. We ruled out
think out loud, because we didn't know how the program worked and felt we wouldn't be able to take accurate notes of a user's
reactions.
What didn't?

What should have been done differently?

Link to this Page