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

Team Oompa Loompa Cases

M1, Design 1

Our team was able to "gel" because we all knew each other from previous classes. We could communicate well without having to get to know each other. We could be honest and we weren't shy when discussing our ideas. Completing the assignment was easy because we all knew the design process from class lecture and we didn't have to explain it to each other.

A difficulty we had with M1 was our meeting with the TA. It had been a couple of weeks between when we completed our design and when we presented it to the TA. We were a little rusty about what we had done and our presentation was somewhat disorganized. We should have prepped ourselves by reviewing our design before the meeting so that we could clearly present our ideas to the TA without any confusion. Also, we could have labeled our CRC cards better to reduce confusion.

Because the roleplay requirement was not tied to a deliverable, we sort of ignored it. We regret this because we had to modify our original design after we thought it was set in stone. Roleplaying could have reduced the need to refactor our design later on.

M2, Design 2

Our team felt it was easy to add new CRC cards and scenarios because we had time to discuss them and we had some great input from our TA. We could easily make decisions about our design because of our knowledge obtained from class lecture. Also, we were able to easily identify the application and utility objects and create our UML class diagram because of the guidance we received from the TA.

We struggled with making good scenarios. Often, our scenarios weren't long enough. It's best to tell a descriptive story that is detailed about a certain use case.

One aspect of M2 that we could have completed quicker was the screen mockups. Instead of hand drawing then, we recommend using a drawing program like Paint or Photoshop to quickly create these. This way, if you want to make a small correction you can just edit the file, opposed to re-drawing your mockup. You can even create them in the VisualWorks GUI builder to get a head start on the next step, M3.

M3, Implementation 1

When performing the SUnit tests, it was particularly difficult to determine which classes needed to be tested because the backend and UI was mixed together rather than being separate. It was also difficult to implement SUnit because you need to have accessers and modifiers for all of the variables. We also had difficulty doing certain things in Smalltalk that we could have easily done in another language when tying the UI in with the backend. Loading and Saving XML was tricky but we eventually got it figured out. Unfortunately due to time constraints it is not properly working in our current implementation of the project however the backend support is there. The logic is completely stubbed out into code however the writeNode function for an object is behaving erratically.



M4, Implementation 2
The biggest problem with smalltalk was the lack of documentation for widgets. For example successfully pulling and setting values from TextEditor Fields proved to be a nightmare because nowhere in the documentation could we find instructions. Eventually we learned that we had to define any widget that we wanted to interact with. This was counter intuitive because many languages do not require this. Pulling out the selected Index from a listbox was also tricky and that was actually a hurdle that we did not have time to complete.


M5, UI Evaluation

One recommendation for M5 is to meet or talk to the group whose code you are evaluating. This is particularly helpful if the group relies on extra frameworks or a database to run the product. If you cannot meet with them in person, use an instant messaging program to get in touch with them to have them walk you through how to set up and run the program. When conducting your evaluation, make sure you are prepared with all the materials (tasks, heuristics, etc) for your evaluators or they will get angry and not want to help you.

When writing the recommendations to the other team, be polite and constructive. Don't just say THIS THING SUCKS! Suggest changes along with a REASON. If you can't back up your suggestion with a violated UI design rule or opinion, then the other team is not likely to take it seriously and implement it. Also, don't get too upset about the feedback you receive from the other team. None of us are truly UI "experts", so take it with a grain of salt.

Link to this Page