Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007
The Undecided Squeakers
The awesome foursome...
The final project is a Squeak "how to" / tour Guide. The purpose of the Guide is to help new Squeak users learn how to accomplish particular tasks in Squeak. It contains a simple help repository and an animated agent that blends 2D and 3D and can demonstrate how to perform tasks as well as supplying instructions to the user.
1. Start Early!
2. Consultation with your TA before any submissions is always a good thing to do. Demo what you have. The TA's are sharp enough to find any thing that you may overlook.
3. Attend class!!
4. There is more than 1 way to get a task accomplished. Make sure that you use the method which is most efficient. If you're planning to accomplish a complex task using a popular method, then you may want to check on the availability of a method that will make it much easier to code the complex task. For example:
In one of our classes called DemoEngine, we coded a method called, getBrowserWithNoSelectedCategory.
we used #whileTrue: while we could've used"browserSystemWindows do:"
See what i'm saying?
5. Group meetings are important. Even more important is attending these meetings.
6. There is very little documentation for squeak online. Try, make a mistake (or not?) and explore!. The code is all there
Milestone 1: Create a Help Repository
To develop a TaskInstructions class to contain the instructions for a particular task and a HelpRepository class to contain the set of instructions that your Guide will draw on.
The Design was given for this Milestone.
Not really hard, simple stuff like creating accessor/modifiers and some other simple methods like using and accessing collections.
This Milestone was individual and it was not bad. All of our group members got +90%. Bascially it was getting familiar with Squeak syntax, learn how to create classes, accessors/modifiers, how to use the different type of collections and so on. The one thing we learned from this Milestone was to comment our method and classes. Don't forget to put comments for each class by clickin in the "?" button of the browser which is to the right of the instance button. The other thing that amazed me was the different code that the people of our group got for simple methods. In Squeak there are a lot of ways of using collections, which is most of the cases is better/less code that using the standard that we are use to of while and for loops.
Code for M1
Milestone 2: Create a simple Guide
1. To form the group.
2. Choose two tasks to fill the repository.
3. To enter those instructions into the help repository. In other words to create a simple graphical user repository.
4. Start building the Guide which will provide users with an interface to the help repository and will eventually be able to demosntrate how to complete a particular task.
This was our first Milestone together. In our first meeting what we did was to decide on which tasks to fill the repository with, and to look through all the milestones. We only had one meeting for this milestone and this was bad becuase we couldn't agree on a design. And what happened was that we came with two completely different designs/implementation for this milestone. We turned in the one that was "bug-free". We got 100% in this milestone but after refining the scond design/implementation for this milestone we decided to keep the second one, the one we turned-in. The decision was made based on our TA advice that the second design was easier for modifications and more open for aggregation.
The milestone we turned-in was coded with some help of other CASES from previous semesters. We didn't really see the big picture in this milestone, so the first submission, even thoug we got 100% was not really clear inside the big picture, like how it would function with the other components. With more time we refined the second milestone and got something that we all agreed on.
Here are some screen shot of the two different projects we came with.
What we learned here was to have more meetings. Spend more time in thinking about the design and to communicate with your group members so you don't come up with two different projects.
Code for M2 Submission1
Code for M2 Submission2
Milestone 3: Design Everything
To plan, analyze and design the entire system.
This milestone required the design of the entire project by reading through subsequent milestones and coming up with a close estimation of how the final project would look. This was the first, and the last, non-coding related milestone. We were required to do a proper analysis of all the milestones and come up with a design which would be most efficient. We could however change the design as we delved further into subsequent milestones. A presentation session was offered as extra credit. We decided to opt for it and make a presentation of our design in class. I have to say that this was a good move, as we got suggestions from the instructor and other class members, which ofcourse helped us get towards our final goal.
This was a non-coding milestone. Here is the UML diagram for this milestone
There is no one way of designing anything. We came up with more than one design and eliminated some as we went along. Examples shown on the lecture slides were of great assistance. A good initial design is very very crucial, as it helps prevent future design related errors. Make sure that you spend a lot of time designing your projects. Its worth the trouble!
Milestone 4: Giving the Guide an interface.
1. Gain experience using 3D in Squeak.
2. Gain experience writing 2D and 3D animations in Squeak.
3. Gain additional experience building 2D GUIs
We were to design a 3D avataar, which was similar to an "Office Assistant" in terms of functionality and behavior. The avataar had to be programmed with the following functionality:
1. Move to a particular point on the screen.
2. Point to a particular screen position.
3. Look at a particular point on the screen.
4. Cause a 2D morph (e.g. a SystemWindow) to move around the screen with it.
Idle behaviors were to be programmed for the avataar as well. This meant that whenever the user was not interacting with the avataar/program, the avataar was to execute one of its idle behaviours.
In addition to the 3D avataar, a 2D interface with which the user would interact (like select topics, enter search topics, etc) was to be designed with the following functionality coded:
1. Allow the user to ask for all available help topics.
2. Allow the user to ask for help topics matching a set of keywords.
3. In both cases the guide should provide a list of the names and descriptions of appropriate instructions.
4. Allow the user to choose a particular topic.
5. The guide should walk the user through that help topic one step at a time.
We used the Wonderland class to create all our animations. We decided to use an avataar that already existed in Wonderland, the snowman.
Code that may be of importance here
Here is a snapshot of our final product for this milestone:
Ofcourse you may download our entire milestone from here:
There is a lot of functionality in the Wonderland class that could be explored. We highly recommend a thorough browsing of the entire class and all the methods it contains.
Milestone 5: Create a demonstration engine
The purpose was to create a demonstration engine which would basically help perform certain tasks such as showing menus, typing and selecting text, etc, inorder to draw the users attention to the UI elements. The goals were to:
1. Learn how to create 2D animations in Morphic.
2. Learn more about controlling Morphic interfaces programmatically.
We were to code functions that would help accomplish tasks like:
1. Opening and closing a menu
2. Showing halos
3. Interacting with a graphical element
e.g. clicking on a button, selecting a menu item, scrolling a scroll bar
4. Text typing
5. Text selection
6. GUI element selection
7. Moving windows
8. Resizing windows
These methods were then to be used in generating "scripts" which basically consisted of calling one or more of functions that did the above listed tasks. Each task to be accomplished had to be "scripted" in the above manner. We had to design this milestone keeping in mind that we would have to accomodate 5 additional tasks which were to be given by our instructor.
A change was made to the class diagram. Here is the updated version of the UML diagram:
Updated UML Diagram
Here is the code for this milestone:
Code for Milestone 5
The scripts that we wrote for this milestone can be found in the zip file. The functionality of the demonstration engine is basically represented through these scripts.
Once we coded the methods that handled the generic events, such as opening a menu, selecting and highlighting text, etc, the scripts were easy to code. It basically consisted of calling one or more of the functions in the demonstration engine to perform a particular task.
Milestone 6: Adding demonstrations to the Guide
1. Integerating smaller working parts to form a large complex systems.
2. To practice working with XML.
We were now to be able to show the users the list of all available help topics and if the user wanted a demonstration of how the task is to be accomplished, then they could have the avataar demonstrate it by selecting the appropriate step and clicking on the show me button. The help repository was to be extended so that text and demonstration instructions could be read from, and written to an XML file.
Here are a few snapshots demonstrating how the avataar performs certain tasks:
The avataar opening and selecting a menu item
The avataar opening a workspace, typing code and executing it
You might find the following code useful:
Code to Read In an XML File
Code for writing to an XML file
The XML part of this milestone was the only new thing. Making the avataar perform the tasks were all "scripted" using the methods in the demonstration engine.
Milestone 7: Expanding the Guide's functionality
1. Learn about free-form text parsing
2. Learn how to query the state of the Morphic interface
This milestone was about adding more functionality to the Guide. In addition to the 5 tasks that we could chose and code, we were assigned another 5 tasks by the instructor. For the previous milestone, we were not required to the actions of the user and didnt really have to keep a track of the previous and the next steps, but we had to do so for this milestone.
Since Milestone 2, we tried very hard to follow good object oriented programming and design paradigms. It has paid off in this milestone. Most tasks were straight forward to code; we simply wrote more scripts that used existing functions of our DemoEngine. Any problems were usually solved with simple fixes or changes. The only notable issue was the Scheduler in Alice Wonderland would stall when executing a "Compiler halt" command(in one of its animations). This can be fixed by forking off a separate thread to execute this command. Eg. [Transcrip show: 'hello'. Compiler halt] fork.
Using good OO programming/design will simplify a project and allow efficient team-oriented coding.
Link to this Page
- Cases last edited on 30 July 2011 at 2:33 am by r59h132.res.gatech.edu