1. The profs just want to "call" each other directly using the whiteboard
application, but this could get unwieldy if many people were involved.
Is it OK to have a rendezvous name similar to the way xchat works?
You are assuming that eventually there may be a requirement to have
more than two people using a whiteboard. This is a good
assumption!
An alternative way of having the Professors start the application is for them each to connect to a named whiteboard. This would extend to more than two participants. It's the way that you set up an n-way conference call on the telephone.
But the ordinary telephone call analogy can be extended to 3 or 4
people too -- just the way that 3-way calling works on the
'phone. The first two people connect, and then one of then
calls the third, and the other calls the fourth.
2. How are "sessions" to be named? An arbitrary named entity, like chat
rooms? A person, like Lotus Sametime Connect? Free choice?
Arbitrary strings will do for names.
3. What types of shapes need to be supported? Outlines only, or filled
shapes also? Colors? (Do we need to care?)
Outlines only, like a real whiteboard. Otto seems to want
color. I would advise against a design that made it impossible
to add filled shapes or color later, but I would not include them at
first.
4. Can a user "protect" stuff they drew from others' erasures?
No. Protection wouldn't really make sense, because one could in any
case draw over the "protected" object with a white rectangle.
5. Can you erase part of a shape, or is it all-or-nothing?
No, you can't erase part of a shape. But you can "reshape" a
shape, e.g., stretching a square into a rectangle.
6. Should the users see each others' cursors? Or should the public
cursors be their own entity, so that you have a pointer (or maybe some
other object) that you drag around?
User should see each other's pointers. And they should see each
other's pens when they are drawing or writing with them. If there is
some other notion of cursor that is necessary, I think that it should
be private, because it is not part of the whiteboard metaphor.
7. What limits should there be on whiteboard size?
Use a square arrangement of 9 screens (3 x 3). Start in the
middle; allow panning to the other eight screens. Actually, you might
start with a single screen, and expand to a mosaic of screens as an
enhancement.
8. Where is the whiteboard saved? Do the clients save their individual
copies, or does some server keep a repository? We believe the former is
better, since it lets users have control of the data, take it with them,
use it on a different instance of the whiteboard system, etc.
The Professors save their own whiteboards, just in the same way that
they save their own word-processor documents.
9. If the whiteboard is larger than anyone's screen can display, is a
screen dump really all that useful? So, is it OK to limit the whiteboard
to screen size or to segment them, so that you see one "panel" at a time,
and can then just print out all the panels one at a time?
I think that Paula will be dissatisfied with a screen dump after a
while, but it's also clear that printing is not a high priority
feature right now.
10. It is hard to see how a peer-to-peer distributed algorithm buys much in
this case. If users can save the state at any point, there is little
exposure to a server failure (especially if the client automatically saves
things as they appear). Are we missing something?
This isn't a question that the customers can answer; it's an
implementation decision. But, having said that, as your
instructor
I think that the advantages of a "serverless" architecture are
But I have not fully thought out the alternatives; a design with a central server might have other advantages.
11. Do we need to support only pairwise whiteboards, or will there be a
need for large numbers of people to interact over a single whiteboard?
Right now, you are asked to support only pairwise whiteboards.
But if you do a good job, I bet that you will find that your users
quickly ask for 3 or 4 way whiteboards, so your design should allow
for this. It need not, however, scale to 40 or 400 users: that is a
lecture theater, not a shared whiteboard.
12. We would like to know if the network (hardware) uses
Multicasting as its mode of communication (like Ethernet does). This
will help us identify the best design to fulfill the user requirements.
You are told that the application must run over a wide-area network.
So, some of the hardware may support Multicast, and other parts may
not. Also, the deployed hardware might change if one on the
professors changes office.
13. Should the effect of a particular operation which is being carried
out on an object (like changing the dimensions of a square) but not yet
complete (i.e. the user has not released the mouse button yet), be
visible to all other users of the white board ??
The visual feedback given to the user who is doing the reshaping need
not be presented to the other users. But it would probably be wise to
animate the redraw operation at the other users' computers, or else
they might not understand what has happened to a shape.