Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007
Questions about Fall 2003 Milestone 6
Got questions about Fall 2003 Milestone 6? Ask 'em here.
"Users should be able to choose, for any particular step in the
instructions, whether they want to perform the step themselves or have
the Guide demonstrate it (Note: for this milestone you can presume
users have correctly followed any previous steps at any point in the
Ok, so the user should be able to perform the step themselves, so in
this case we just show the user the step and that's it? I don't see
that we need to do any kind of checking, like checking if the user
performed a step correctly right?
And the note that is on the quoted paragraph above is just referring
that for now our demonstrations should work only when the user clicks
step by step starting from step 1 correct? And in M7 we will need to
check for dependencies, (ie. check if step 1 and 2 were shown before
showing step 3).
For any step in the instructions either the user should be able to do it him/herself, or the user should be able to tell the system to do it. You don't need to do any checking for this milestone; you can presume that the user will any complete any steps (s)he takes on correctly.
What should we do for example: we have a step that opens a browser by
opening a world menu, then the open subemenu, and the clicking
in 'browser (b)', but we have a user who doesn't really have anything
else to do than breaking our program, so he decides to close the open
menu really quick before the avatar clicked on the 'browser (b)' item.
Well our program as it is right now, will not do things correctly if
Do we need to take care of this? Is it a requirement?
Thanks and sorry about all this posts, I just want to get things
clear before anything else.
You won't need to handle that for this milestone, but you will for milestone 7. For example, if Step 1 is Open the World Menu, Step 2 is open the Open submenu, and Step 3 is open the browser, you need to handle the case where the user (accidentally or otherwise) closes the Open submenu before Step 3.
We need to extend the functionality of our Guide to export and
import XML files with text and instructions for each step. Do we
need to only have messages in guide that take in a filename as a
param and export or import to that filename? Or do we also need to
expose this functionality to the user and allow them to export/import
the XML using the GUI as well?
It'd be nice to expose that functionality to the user in your GUI, but as the milestone is written all you strictly have to do is provide messages that take a filename and save or load as appropriate.
Do we need to change our previous save/load functionality from a file
so that it saves the demonstration also? Or just addind the XML stuff
will do it?
Your original load/save functionality is no longer necessary, so at this point you can either replace it with your XML load/save code or let the two exist side-by-side.
Should the XML parser/generator handle one XML file at a time or are
we going load/save to the single .xml file?
You should be able to save each pair of text / demonstration instructions to a different XML file.
But I assumed that the XML file contains all the necessary
information (data) to construct a Task Instruction not just pairs of
It does, but since that info may vary from team to team, at a minimum you need to have the text and demonstration instructions. So serializing a TaskInstructions instance might be valid for your team, depending on how you structured things.
We are sitting here working on the GUI to allow the user to create/edit tasks (like was required in M2). This includes the ability to enter annimation/post-condition code for each step of their task. However, looking over the M6/M7 .nfo files this does not seem to even be a requirement. Are we wasting our time (we are coming up with a simple but powerful scripting language and scripting interface to make everything easy on the user)? Drag 'N Drop!
It's not a requirement, but if your team supplies that functionality your lives will be a lot easier for M7 (where you have to add 5 more instructions for the tasks I'll provide).
Wow, I thought the whole point in the guide was for people to be able to add in their own Tasks, etc. (hence milestone 2 functionality). Well, no extra credit in this class, but I am having fun learning drag and drop - so I will continue.
I seriously considered it, but the primary focus of the Guide is to help novice users, who are a different set of users than the people who will be writing new instructions. The milestone 2 functionality was both to give you practice and to put in hooks that someone can expand later.
Is there an easy way to write out a BlockContext to a String, or something similar? The only way I can see to save a BlockContext is to save it to an ImageSegment (which I assume means the Squeak image itself, or some subset). There are a few places in our code that utilize BlockContext and friends, and we were thinking about trying to serialize it and the write it out into the XML. Our old fileOut code simply used a DataStream and did a putNext:self. This saved us from having to do any troublesome parsing. :) We were hoping to do something as easy via XML.
Have you tried serializing it as XML? I vaguely recalling lecturing about that...
Lex Spoon: someone recently posted a changeset to the Squeak mailing list that will decompile block contexts back into code. If the block is simple enough, you could then recompile the block after you reload. Alternatively, you can work out how to hack SmartRefStream, and you should be able to add saving of blocks to it.
Probably a better bet is to track both the blocks and the source code; when you are about to save, either (1) arrange for the blocks to get removed, or (2) have a message #objectToSave which returns a slightly different object from the original but which has no blocks. You might need an #objectFromSave method for restoring the object after a reload. This approach is pretty easy on the code and will let you avoid icky parsing. :)
Note that if you expect the project to last for a while, then automatic serializing objects is probably not the best approach. A file format that can last over time needs to be designed. DroidQuest uses object dumps when it saves levels, and there are bugs that have been left in because fixing them would require adding an instance variable, and adding an instance variable would make the objects no longer reload (using the particular serializer he's using). Anyway, it's a perfectly fine technique for this class, especially since it's worth learning about anyway....
Link to this Page