Users can send each other Sound Instant Messages, which are short sounds that have meanings associated with them. (The sounds are currently being designed.) To send a SIM, the user taps the name of the person they wish to contact, and that person’s Bub screen appears. This page provides some information about this bub as shown, namely their full name, their Sound ID (which users can tap to play), and whatever awareness information is available. In addition, it shows the SIM icons. [Can we have a “Sounds turned off” indicator on this page when the person is muted or blocking sounds from this person?] To send this bub a SIM, the user taps the associated icon. When they do so, if the sound reaches the server (other person?), it plays back to this user so they know the sound was sent. [Does this mean it may not reach the bub even if this user hears it play back? Did we decide to require an acknowledgement or not?] When the user sends a sound, the recipient hears first the sender’s Sound ID followed by the SIM. (Note that this is the opposite of the awareness sounds, which play before the SID.) In addition, they see a visual alert of the message. Figure P5 shows what it looks like for Walendo when Nancy sends him the SIM “Ready?”. The alert in the header area alternates between the two images for five seconds. Note that Walendo could be on any screen in Hubbub and he would see this alert. [We need to Figure Pout if there are any exceptions to this.] Possibly for Version 2: If the user taps on the flashing alert, then they are taken to that bub’s screen so they can quickly reply to the SIM with a SIM.
Header area alternates between two images for 5 seconds. If the recipient happens to be mute, the visual alert still flashes but the sound does not play. In addition, an error sound plays on the sender’s device instead of the sound and the “Sounds turned off” text flashes off and on for [5] seconds. [Maybe we play a very short beep-type sound to tell them just that a message came in so they look at the screen, but don’t play the sound.] If the recipient is blocking all sounds from the sender, then they do not receive the visual alert or the sound. The sender sees the same “Sounds turned off” message flashing. There is no way for the sender to tell the difference between someone who always keeps their device muted and someone who is blocking their sounds. (Over time, we expect users to Figure Pout that the visual indicator still plays if they’re mute but not blocked, so they can have conversations even when one person wants to keep their device quiet. But there is plausible deniability if someone is blocking a bub when they don’t respond because it’s easy not to know about the sound if you’re not looking at the device.)
As mentioned in the next section, if a user tries to send a sound or text message to a bub who is offline, a window appears telling them that the bub is offline and asking if they want to send a message through email. See explanation in the TIMs section. In the case of trying to send a sound message, the text area would start out blank, since we can’t send sound messages through email.
Hubbub provides a log of the last 5 SIMs to arrive. This might be useful if theuser hears a sound but isn’t able to identify the sound and doesn’t look at the screen fast enough to see the flashing message. Or they may have muted Hubbub and had their attention elsewhere, but they can still find out the most recent messages to arrive. To see the log, users tap the “Last msgs” button from the main screen. [It would be nice if you could tap one of those items in the list to go to that person’s Bub page so you could easily respond without having to navigate your way to them. Let’s try to get this in if we can.]
We expect that people will want to create new SIMs once they get the hang of using the ones we provide. We are still working out our plans for supporting this activity.
Users can also send each other Text Instant Messages (TIMs), which are equivalent to the instant messages of such programs as AOL Instant Messenger, Yahoo Pager, ICQ, Excite PAL, etc. The difference is that the users can send these messages between wireless Palms or between computer desktops and Palms.
To initiate a text message, the user taps on the name of the person from the Hubbub main screen. To start an instant message, the user types a message into the text area at the bottom of the screen and taps “Send.” If the other person is accepting text messages from this person, the Text Message screen appears on the user’s screen.
Each time a user send a message, that message appears at the bottom of the scrolling area and the rest of the conversation scrolls up. The user’s comments are in regular type and the other person’s comments are in bold. The header of a TIM indicates the time at which the conversation was initiated, it does not update with each new contribution.
Users can also send Sound Instant Messages as part of their text messages.
To do so, they tap the menu button at the bottom left of the screen to bring up the SIM menu, as shown in Figure P8b. If the user has created their own sound messages, then those appear in the menu as well. When a user sends a sound message, the sound plays for both of them, and the icon for that message appears in-line in the text, on its own line followed by the label and preceded by the name of the sender (seen in P8a).
To save on memory, the TIM screen does not retain a history of all the messages in a given conversation. Instead, the last 100 messages (from either person) are available, but if the user tries to scroll back beyond that, the messages are no longer available. To end a conversation, the user taps the Done button. They are returned to the main screen, showing whatever group was last displayed.
When a user receives a text message, the incoming text message sound plays followed by the sound of the person sending the message. In addition, the text message window automatically displays on their screen except for a few cases. Namely, if they are already in a conversation with someone else, then the newly created conversation appears in the IM menu and the number next to the menu changes to reflect the new conversation, but the screen does not switch to the new message. To see the new conversation, the user pulls down the menu and switches to it. The other exception is when the user has a blocking popup on their screen. These appear when the user is in the middle of some action and needs to provide input to complete it, e.g. adding a user, changing the name of a group. In this situation, the sounds play when the message arrives, and as soon as the user closes the popup, the incoming message appears. [Might be better to give it something like two seconds so they can see that whatever they were doing took effect before being moved off. We’ll probably need to tweak this behavior, since it’s very annoying to have things happen when you’re in the middle of something else.] Each time the person sends a new message to an existing conversation, just the TIM sound plays (without the Sound ID of that person). [Maybe you hear the SID if you’re not looking at that window, or maybe SIDs only announce new conversations. We could also do something to show which message has unseen contributions, e.g. make that name in the menu bold, to help you Figure out which message to look at next.]
The TIM screen provides information about the other person’s focus and activity in their TIM window with this user. Specifically, an icon to the right of the bub’s name indicates which of three states they are in: (a) typing in this IM window, (b) viewing or has focus in this IM window but is not typing, and (c) not viewing (Palm) or does not have focus (desktop) in their window for this exchange. As the other person switches between different states, the icon updates to reflect this information. This TIM activity indicator enables people to coordinate their conversation, which is bound to be punctuated by pauses given the speed at which people can write on the Palm. Users can interpret whether the long pause is because the other person is composing a long response or because they’re busy doing something else, and then adjust accordingly.
Users can have more than one conversation active at once. The menu in the upper right shows that this user has three such conversations active. The number the the left to the menu also indicates the number of active IMs. (If there is only one active IM, however, no number appears, since a 1 is more likely to be confusing than helpful.) To switch among the conversations, the user taps the menu and selects another one. Alternatively, the user can put the current conversation “on hold” by tapping the “Hold” button, which brings the user back to the main screen but keeps this conversation “active.” (This is the equivalent of moving focus to another window in the desktop world.) Being active means that it still appears in the IM menu, the history of messages in that exchange (up to 100) is retained, the IM icon appears with the bub’s entry on the main screen (see the listing for Ellen), and the timestamp for the conversation continues to show the time the exchange began. (The icon next to the user’s name on the main window is the same icon used to indicate the bub’s activity in their TIM window and it updates on the main screen just as it does on that IM window.) In addition, if there are any active IMs, the main screen has an IM button at the bottom of the window, regardless of which group they’re looking at. Tapping that takes the user back to the IM window showing the last IM they were in. If there are no active IMs, this button does not appear. (This is intended to make it quicker to get back to an IM even if the user is not looking at the group that contains their current IM partner.)
When the user returns to the conversation, everything appears as it did before, with perhaps additional messages at the bottom if the bub has entered any. If the user wants to end the conversation, they tap the “Done” button on the IM window. (This is the equivalent of closing an IM window in the desktop world.) The conversation no longer appears in the menu and there is no way to “get back to it.” However, note that the other person may not have “closed” their end of the IM. If they send a new message, the recipient experiences that as a new conversation being started from that person, with a new initiation time and no history of previous messages.
If the user tries to send a text (or sound) message to someone who is offline, then a window pops up. Since the would only get the screen if they had already typed a message into the text field first, that message is provided in the text area so the user can either send it as is, or modify it and then send it by tapping the Send button. When it arrives in the recipient’s inbox, the Subject is “Hubbub message from {Bubname}.” Since the message must be short, the interface allows only 512 characters. If the user tries to write more, the character is not echoed and the interface beeps. [Note: if scrolling doesn’t come for free on this screen, then the message can be only as long as this interface allows, which is about 170 characters. We will not implement scrolling just for this window.] If the user taps Cancel, then they are returned to that Bub’s Bub screen.
:quality(80)/cloudfront-us-east-1.images.arcpublishing.com/semana/S7MKJWZ6CJEFJN5QLCVTZSIH4M.jpg "TELEGRAM ADDS CRYPTO TO ITS SERVICE")
