| |
|
|
|
|
|
|
|
|
By Ellen Isaacs This page last updated: January 27, 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.
The "please wait" screen appears while the server looks up the bub being requested. The icon appears to be spinning, to indicate that something is happening. When the server finds the list of possible bubs, it displays them in the next screen, shown in Figure P16.
Once the user has selected a bub to add, they see the screen shown in Figure P18. This enables them to assign them to a group and to assign preferences to this bub. The group defaults to the group from which they launched the Add Bub window, although they can change it by pulling down the group menu, as shown in Figure P19. The other defaults are set as shown in Figure P18: 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. The user can uncheck any of these settings for this bub or change the group assignment. When they tap Add, they are shown the alert in Figure P20, explained below. When they tap "OK," Hubbub returns to the main screen displaying 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 with an asterisk next to their name and no other information about them displayed. 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 P21. If she accepts, then she is shown the Edit Bub screen shown in Figure P22, 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. When she presses Done, the requester is added to her bub list, and the requester is sent a message saying that she has accepted. As always when adding a bub, this user then sees the main screen showing the group to which the new bub has been added ("Unfiled" if she doesn't change it.) If she chooses Cancel on this screen, she returns to the Add request screen, allowing her to Decline or Accept again. If she declines the request, then the request alert (in Figure P21) goes away and she returns to whatever screen she was on.
On the requester's side, if the bub accepts, an alert appears telling them that the request was accepted, shown in Figure P23, the asterisk is removed from the bub's name and the information she allowed becomes visible. If the bub declines, the requester gets a message notifying him that the bub declined the request, shown in Figure P24, 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 active 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.
|
