Team Fred Cases
ShareWorks
Spring 08
CS 2340

Team Members
Donna Yoo (the bestest^infinity member) also known as the Pigeon Lady

Andrew Ho

Paul Plunkett (the bested member)

John Munro


M3 Domain Design Paul
M4 Application/Gui Design John
M5 Domain Implementation Paul
M6 Gui Implementation Donna
M7 UI Evaluation Andrew
M8 The Twist!!! Donna




M3 Domain Design

The goal of this milestone was to get the design of the domain model which is the back end code of the application.  We created our CRC cards for the main domain objects.  They said it didn't have to be perfect but needed to cover the main domain Objects.  Our initial CRC cards did not cover everything that we eventually implemented but the initial CRC cards were important later in the project to create the basis of the program and showed us what other classes and methods that we needed.

M3 Requirements


CRC cards:




M4 - Application/GUI Design

M4 Requirements

Although not required, it is recommended you have begun some implementation of basic Domain Model objects.



We should have put a lot more thought into the UML diagram. Our classes where poorly thought out and methods where not fully stubbed out.  This caused a lot of problems when we then went on to implementation and tried to split up the work between our group members.  Specifically, the server implementation needed to be researched more.  We also should have researched SmallTalk's parcel packages such as OpenTalk and FTP servers during design.  This would have given us a much better idea of what classes we actually needed to create ourselves.  I feel that our Sequence Diagrams where well thought out, but they would have had to change slightly with the changes to our classes. 

Class Diagram:



M5 Domain Implementation:

The goal of this milestone was to code what we designed in M3.

M5 Requirements


Criteria Breakdown:



What Worked
We got most of the client domain model working with user interaction with their own media files and libraries.

What Didn't Work
We got started on the server but didn't finish it in time to turn in.

What We Would Have Done Different
What would have helped us is better planning on how much time it would take to turn the design into actual code, it takes a long time.  It is best to give plenty of time to complete the project and to make sure you can get what you want working when you want it to work.



M6 Gui Implementation

The goals for this milestone was to implement the GUI (like the name of the milestone says).
-Make a GUI using VW painter
-Hook up the GUI to the domain code from M5

More specifically we needed to get our whole ShareWorks application working and fulfill these specific criteria


What Worked
Drawing the GUI was possibly the easiest part of the milestone since VW's drag and drop makes everything a snap. 
And we used the mockups from M4 to guide in the design of the GUI.
What we got working at the end of this milestone was the
Additional GUI features include


This is the Log In screen, which was fully functional.  If the user entered the wrong password they could not access their account.  When someone clicked new user another window would pop up and allow the user to create a new username and password.  If the username was already taken, then they would be prompted that that username was not available. Although we had thought about how to handle these exceptions earlier in the process, a lot of the exception handling was implemented within the application model because dialog boxes were used to inform the user, and there was not a lot of exception handling done within the domain code.

This is the main window with the File Management window.  Nothing spectacular, but once again, getting everything hooked up was a challange.  There are great examples on GUI lists and sliders which helped a lot.  
What Didn't Work
However, although we had planned to everything to look snazzy, making it work AND look snazzy was not a piece of cake.
Making the GUI work and hooking it up all our aspects and adaptors presented a lot of problems.
The first problem was trying to figure out how to hook up more than one windowSpec to one application model.  Since I couldn't figure this out (and wouldn't figure this out until much much later) I solved this problem by making one application model per window.  This, in theory, was a good solution to the problem, but then it presented another problem.  Because everything had a separate class I had no way to reference the same instance variables such as the instance of Client that I needed to get the currentUser.  I created a ridiculous (but functional) hack to solve this problem, and everything worked.  Yay!  So our Client was had pretty much all the functionally that it needed.
What didn't work at this point

This is our search/download screen, which unfortunately never got hooked up.  But imagine how it might have worked. 

What We Would Have Done Different
Looking back there are a lot of things we would have done differently.  Most importantly I would have used more of VW's resources.  Looking back, I wasted a lot of time trying to figure stuff out by tweaking code, when I should have just loaded an example parcel.  There are a lot of examples in that you can load in from the parcel manager and they are real working examples that work!  Looking at what the examples programs did and being able to look at their code helped to clarify a lot of things.  Obviously if I had known how to hook up more than one window to the same application model, there would never have been more than one or two application model and I wouldn't have had to solve the problem of accessing the same instance variable from two different classes.  Obviously if there had been more time, we would have implemented everything else that needed to be done.  Additionally, we didn't fully flush out the GUI design in M4, and if we had put more effort into not just the looks, but the implementation behind the design we would have been better off.  Somewhere within my application classes, I mixed up my aspects/adaptors with my objects, and so I could not save user information from the GUI.  I would have written my code more carefully (instead of trying to just get stuff to work) and kept track of all my instance variables.  Another reason we weren't able to get everything working was because we were behind on our Domain Implementation, and obviously you can't code the application model if you don't have a working domain model. 


M7 User Interface Evaluation

The M7 milestone was abit of a challenge for project teams because each group was required to perform a usability evaluation on another team's prototype, and then report their findings to said team.

Our team received the prototype and GUI screenshots from Team ‘Insert Team Name Here’, and we sent our GUI screenshots to Team Jay to evaluate. After evaluations were finished and turned in to the professor, teams also received a report on their evaluation to write a rebuttal.


Checklist of Things to Complete

  1. (10 points) Clearly identify the team whose prototype you evaluated and provide a one-page description of your evaluation plan and the rationale behind the plan, i.e., why you chose to conduct that evaluation on this prototype.
  2. (30 points) Results of execution of usability plan, providing clearly documented printed evidence that you conducted the evaluation plan correctly. For instance, this includes the actual raw data sheets and evaluator notes in addition to the synthesized data.
  3. (30 points) 3-page usability report highlighting the three top concerns arising from the usability evaluation. The report should identify clearly what each usability concern is and the evidence you have to support this problem being a real problem that should be corrected by the design team. One copy of this part of the report goes to Bob, and one copy should be given to the team you evaluated.
  1. 3-page rebuttal of the usability report submitted to your project team. Be careful not to get defensive in this report (resist refuting that the findings of the evaluation team are incorrect). Make a clear argument for how you would address each usability concern. Assess whether the object-oriented design you developed for your prototype made it any easier to address these usability concerns.


What Worked

This milestone wasn’t particularly difficult at first, as our team chose to perform individual heuristic evaluations. There was some difficulty in finding a particular set of heuristics to evaluate, though we settled on going through the ten basic heuristics rather than filling out a very lengthy, detailed evaluation that wasn’t entirely applicable to the prototypes. After each team member finished their heuristic evaluation, the results and observations were compiled into the report with little difficulty, and promptly submitted to the professor and other team. We also received the evaluation report from Team Jay on our prototype, which we wrote a simple rebuttal for.

 

What Didn’t Work

The biggest problem in this milestone was that our prototype from M6 wasn’t fully functional, and thus we only had GUI mock-ups to submit for their evaluation. I had hoped to mitigate this problem by providing a detailed walkthrough of each screenshot, though ultimately our GUI turned out to look much different than what we had created in the mock-ups.


What Could Have Been Done Differently

I imagine that having a more functional prototype from M6 would’ve helped greatly, though a team has to acknowledge that the product of their work may ultimately end up looking much different than what had been first intended. Also, I wasn’t able to perform as thorough of an heuristic evaluation as I’d hoped due to problems in opening the other team’s prototype, which could’ve been handled better if I’d communicated with the other team more meticulously.




M8 Web Front End
For M8, the oh-so-dreaded TWIST, we had to put a web front end on our ShareWorks application. 

These are the criteria out website had to have:


What Worked
Well, the twist was actually really pretty easy.  For once, everything worked.  I think the reason that everything worked out well was because we had a good domain design and implementation.  We ended up just writing one method within the Client class (which was a toString method), and basically everything everything worked like it should.  Making dynamic pages wasn't difficult and at this point, coding in SmallTalk was no huge challenge.


This is a screen shot of our functional dynamic webpage.  A user could add files to their library, make a new library, and save all this information. 

What Didn't Work
Our design, although not perfect, was satisfactory for the twist to come together quite fast. It would have been nice to give the site a more professional look and feel, but under the time restraints we did all that was necessary.  We used the OpenTalk parcels to run our web server off of.  It was very simple to configure and edit.  The only real problem we had was getting the pages to update after code changes.  For what ever reason, the .ssp files (html files with SmallTalk imbedded within) would not refresh with new code unless the server the entire SmallTalk client and thus server was restarted.  Once we got it showing changes though, everything went pretty smoothly.

What We Would Have Done Different
I don't think there is much that we would have done differently on this milestone.  Because our domain classes were pretty well designed, coded and separate from the application stuff, it was easy to put a web front end on our ShareWorks application. 


What We Learned Through Our Experiences (so that you don't end up like us)
Team Fred says: