Good job overall - its very thorough - and you may actually be
able to get away with cutting some things out of the doc.
We think some rearranging would help the document to be more
readable. We can all sit down and talk about how you might go
about rearranging things on monday. You may be receiving some
further e-mail from Gregory about this doc.
Here is some specific feedback about the design doc:
1. A basic set of services is provided to all users of the Cyberguide:
Instead of saying a pre-scripted tour - how about a "self-guided"
tour. We don't want them to confused cyberguide with the walkman
audio approach to tour guiding. The user should be able to pick any
path - not having the choice made for them.
Also - on communication we want to communcate with other cyberguide users
*and* also communcate with remote machines - so maybe this should be a
separate point.
And another point you should add to the list of basic services is the
idea of cyberguide being "context-aware" for us this means position aware
now -- but could also span other changes in the environment such as
time and orientation. (did see the later paragraph about this stuff,
but you should mention it up front - since its pretty major to
cyberguide)
Again, downplay the pre-scripted tour thing, this is not a major focus
of cyberguide.
We like the idea of splitting the sets of functionality into four pieces
of functionality-- and then trying to personalize them, but we don't think
these work quite yet, you would just need to change a few things.
map to cartographer and info to librarian work well, but the tour
guide really seems to represent the intelligence of the system as it is
the link between the technology and the real world. -- so - just as a
real tour guide is aware of the surroundings because they are familar
to them, our electronic tour guide can sense things like position and
possibly orientation and time and other parts of the environment in the
general sense.
So what happened to personalizing the network? How about the communicator
or the messenger or something like that.
How about directly corrolating the usage scenario with the set of
functionality points you have here? How about moving the usage scenario
near the top of the doc, at the end of the intro. section. How about doing
something with multiple users?
Abstract Design:
I didn't see any metion of dynamic verses static information objects ....
both could have info. associated with them in the database.
The diagram looks nice, but seems kinda disconnected from the rest of
the document.
Map Segmentation:
Who gives the map its current position? This is the first time you've
talked of the "positioning system" in the document.
Info:
All this detail may not be needed - you may not need to define the
structure of a record in the info. db. Make sure things are open enough
so that we could use a web browser as the info. browser if desired.
Network:
So what is all this stuff about a cache? Does that belong in this type
of document?
Communicator:
True, we want to do e-mail and web browsing, but I think we'd also like
to do point-to-point stuff from one cyberguide unit to another - so this
would let us do stuff like "figure out where my friend Joe is in the
museum and what he's looking at" or "tell me friend to meet me somewhere
since I'm about ready for lunch and done with my tour." -- or figure out
where all the other people are to either avoid them, or join them, if they
are all looking at cool stuff.
Inter-Object Communication:
This part is really good - it talks about how the different modules relate
to one another. Do more of this.
Future Directions:
How about including all this stuff as part of the design? Then we can
pick what we are able to implement for each prototype.
Thats it for now.
- Gregory & Sue