The BRIDGE Scenarios

Simple Scenario A: Harry Meets Sally

• 2002.10.25 Initial posting of scenario. (cmr)
• 2002.10.28 Adding notes on questions, added blockquote formatting. (pli)
• 2002.10.30 Added responses to Philip's notes, updated scenario. (cmr)

---

CMR (2002.10.30): There is a new idea in the scenario now. The idea is based on the probablility that the chat object will likely be used as Harry and Sally coordinate themselves to the same object of interest. This scenario now suggest putting some widgets on the chat object that facilitate chat particpants coming together or moving together. The selections will need to allow specification of what client to use, what object to go to, and/or simply joining with the other person.

---

CMR (2002.10.30): The scenario now runs to a conclusion. This seems doable based on our prior discussions below. Am I correct?

---

CMR (2002.10.25): The problem here is, how do they become aware of each other. Harry is logged in to the server, but Sally is not. Does she need to log in so they can see each other's presence in the User's list? Does she need to be onto the Java side to do this?

PLI (2002.10.28): Not necessarily. The current web representation of the user list just shows the ids of everybody logged on, though that could be extended. It would necessarily be somewhat lower fidelity than the Java version, and would also generally be slightly out-of-date because of the transactional nature of web pages.

CMR (2002.10.30): OK. Then I will assume they can at least see each other as being on the system.

---

CMR (2002.10.25): Next we need Sally to see Harry and to somehow know find out what page he is on, hopefully without a brute force search.

PLI (2002.10.28): Here's how this type of "who's where" synchronous awareness information currently works: When a UI for an object is presented, the client adds an entry to a per-user list indicating that the user is now looking at the object. The server detects this and adds entries to that same list for all of the other users who are currently viewing that object. The new user's entry is also added to the per-user list for each of the other users who are viewing the object. This approach represents a compromise between security, efficiency, and bandwidth concerns, explained in more detail here. This scenario suggests at least three enhancements:

1. Addition of support for updating these lists on web accesses in addition to full editor accesses. This is quite tractable, but some thought needs to be put into the details of handling the disconnected nature of the web client.
2. Addition of support for updating these lists (in a slightly different way) for "proximal" objects, where the definition of "proximal" needs to be determined.
3. Refinement of the current privacy controls, though the definition(s) of proximal that we decide on make take care of this.

CMR (2002.10.30): So the upshot is we know who is looking at which object(s). This is real time for a Java client (do we know if they closed the object?) and only as current as our knowledge of the last page sent to a browser client. For now, that seems good enough to me.
We will need to work on how to present this information. The UI details for showing who is "nearby" will take some thought. When we have a working prototype we can evaluate how well this works and what disconnects need to be solved with further refinement.

---

CMR (2002.10.25): The scenario ends when they are both in the full editor on the same page/line

PLI (2002.10.28): For the first pass, let's worry about getting them on the same object. We need to start thinking about a longer-term solution for handling finer-grained awareness information (like scrollbar positions) in a generic way, but that's probably beyond the scope of any near-term efforts.

CMR (2002.10.30): That's actually what I meant. If we can get them to the same object then they can negotiate through the chat client to get to the same view of the object. To do more will require stepping up the collaborative nature of the objects themselves. That would be an interesting effort, but not of immediate importance.

---

CMR (2002.10.25): Can the scenario work if one is on the full editor and one on the web editor? What about both using the web editor? Could they be aware of each other's presence and perhaps initiate chat?

PLI (2002.10.28): The most generic test is that if something requires pushing unrequested data to the user, it cannot be done in the web client (at least not in the current implementation). The only exception to this in the current set of tools is the chat tool, where (once manually opened in a web browser) the transcript is reloaded periodically. Two possible enhancements to the web client to handle this more gracefully would be:

1. Support for including a small chunk of javascript in the next page requested by a given user. This would allow the server to send a notification, possibly including a redirect to the full editor or a web-editable object, the next time the user requested an html page from the server. This is reasonably lightweight, but fails if the user doesn't make another request in a timeline manner.
2. Addition of a tiny, UI-less applet in each web request that would maintain a connection to the server and send redirects to the browser or invoke javascript. This would give us true "push" capability for notifications, but has a long list of drawbacks: applets can be unsupported/disabled in the browser, applets would generally reduce the stability of the web client, firewall issues, etc...

CMR (2002.10.30): These are all good things we should work on, but I don't regard them as vital just yet. I think a user can refresh the browser manually if there are issues of currency. User testing will probably prove me wrong on this point. I just want to know if it is possible for them to be aware of each other independent of the combination of client. Based on the discussions above, I think the answer is yes, if we can figure out how to distinguish system login vs "nearby" object vs "same" object. That's what I think we need to work on in the immediate future.

---