| |
|
|
|
|
|
|
|
|
By Ellen Isaacs This page last updated: July 18, 2000
Users can add to their bub lists anyone who has already registered with the service, as long as that bub approves their request. Once they add a bub to their list, that bub is known to them on any Hubbub device; they do not need to add them on each device. To add a bub, the user chooses "New Bub" from the File menu, shown on the TIMs page in in Figure D8a. This brings up the first screen in the add user series of screens, shown in Figure D16. The user types in as much as they can to identify the user, in this case the bub's name. The user clicks the Next button, and the "please wait" screen appears, shown in Figure D17, while the server looks up the bub being requested. The Hubbub logo animates to give the user something to look at. (If at any point in this process, the user clicks the Cancel button, the window disappears and the bub is not added to their list.) When the server finds the list of possible bubs, it displays them in the next screen, shown in Figure D18.
If the user provided a unique name, then the screen in Figure D18 is not shown and the user goes directly to the screen shown in Figure D19. If there is more than one possible match, then the user is presented with the email addresses, real names, and bub names of the bubs known to the server. The user chooses the bub they want to add and click the Next button. If they want to do another search at this point, they click the Back button, which takes them back to the first screen, shown in Figure D16 (skipping the Wait Screen). Once the user has selected a bub to add, they see the screen shown in Figure 4. This enables them to assign the bub to a group and to assign them preferences. The group defaults to the group from which the user launched the Add Bub window, although they can change it by pulling down the group menu, as shown in Figure D18. The other defaults are set as shown in Figure D19: allow text and sound messages, allow this bub to know when they go idle or active and from what device, and play sounds when this bub becomes active and idle. We set the permissions to the most social settings at first, mainly to enable people to learn the features of the system. However, if the user unchecks any of these settings for this bub, then those preferences "stick" so that they will be the default for the next bub to be added. If the user changes the group assignment, however, that does not stick. That default continues to be the group displayed when the user clicked the "Add Bub" item. When they click Next, they are shown the alert in Figure D21, explained below. When they click "Finished", the window disappears and the main Hubbub window switches to show the group to which the bub was just added, so that the user can confirm that the bub was tentatively added.
Hubbub uses a symmetric bub model, that is, anytime you add someone to your bub list, you are added to theirs. This is a security feature that keeps unidentified people from spamming. It also allows people to explicitly specify how much or little information they want to make available to others. The tradeoff is that it takes more time to add someone, because they have to approve the request, and they may not be on line at that point. (This is something we'll experiment with and may change if it causes too many problems or makes it too hard to get started.) If a user adds a bub, then that bub is added to the user's list in a pending state, namely in italics with an asterisk next to their name and no other information about them displayed. (If the user rests their cursor over such a name, the hint says "Awaiting bub's permission to be added.") It remains pending until the bub approves the add request. Meanwhile, the bub gets an alert asking if she wants to add the requester to her list, shown in Figure D22. If she accepts, then she is shown the Edit Bub screen shown in Figure D23, with the requester in the "Unfiled" group and the permissions set to allow text and sound messags, provide location and activity information, but with awareness alerts turned off. She can change the group or preferences. [Do we use the same saved permissions from initiating added bubs? Keep a separate set of permissions for "add request bubs" or keep a separate unchanging set of permissions for "add request bubs?" Need to know implementation tradeoffs.] When she clicks OK, the requester is added to her bub list, the window disappears, and the requester is sent a message saying that she has accepted. Again, the Hubbub window changes from the group it was displaying to show the group the new bub was added to. If she chooses Cancel on this window (Figure D23), she returns to the Add request window (Figure 7), allowing her to Decline or Accept again. If she declines the request, then the request alert window (in Figure D22) goes away. [If it's possible, this alert window should have no close box so the user can't close it without making a decision. If it must be there, then we need another window to pop up asking them to either Accept or Decline...]
On the requester's side, if the bub accepts, an alert appears telling him that the request was accepted, shown in Figure D24, the bub's name is no longer in italics and the asterisk is removed, and the information he is allowed to see becomes visible. If the bub declines, the requester gets a message notifying him that the bub declined the request, shown in Figure D25, and her name is removed from his bub list. If either party is not on line when the other is adding or responding to the request, the alerts appear the first time they become available on any device. During the period when the requester is waiting to find out if the bub will accept the request, he cannot send the bub any messages or get any awareness information about her.
|
