Active Messenger: Email Filtering and Mobile Delivery
Download 0.67 Mb.
|
- Navigate this page:
- 3.11Prioritization and categorization of email... and people
- 3.12What should stick out most on the status page: important messages or unread messages
- 3.13Category dependent read threshold level
- 3.14Sending to the first device
- 3.15Location modifies channel sequence
- 3.16Disabling message sending to SkyTel™
3.10Memory spanIf a user receives many messages, e.g., 100 a day, the memory span of Active Messenger is exactly one day. Older messages are overwritten and can't be accessed anymore. If the user is away for several weeks, this becomes a big problem. One solution would be to increase the amount of messages that the agent stores, as a file and in the message list. But this increases also the RAM needs of the program. Another solution would be to decrease the amount of messages that Active Messenger holds in memory. The “ignore list” at the very end of the user preference file serves this purpose. Active Messenger ignores all email from these addresses. However, only the hardware resources of the workstation it is running on limit the number of messages that the agent can keep in memory. 3.11Prioritization and categorization of email... and peopleAlthough categorization of email seems to be an organizational process, there are also psychological implications. The partner of an Active Messenger subscriber was very disappointed when he saw that he had to share “his” category, “superimportant,” with the best friend of the user. He probably felt that being her partner would be reason enough to be put in a special category on his own, or at least one with a higher importance than where the friends are in. 3.12What should stick out most on the status page: important messages or unread messages?There is no clear answer. Some users prefer the former, some the latter. Therefore, the user can specify the coloring. In the first case, the most important messages stick out visually because they are colored in bright red. In the second case, a message that is not red is very bright. The “brightness” of the message decreases proportionally to the probability that the user has read it. 3.13Category dependent read threshold levelA suggestion was that the “message read” threshold should be relative to a category: the more important the category, the higher the percentage has to be to mark the message read. However, Active Messenger may get opaque with this feature. It would be almost impossible to determine what the agent should have done. It is already difficult to detect “misbehavior” of the Active Messenger, and a flexible “read threshold” would probably make it even worse. 3.14Sending to the first deviceA user observed and reported the following behavior change: If a message from a group member arrives, a special auditory cue is played on her workstation. As specified in her preference file, such a message is sent to a pager after a few minutes. To avoid that, she reads the message immediately if she is at her desk. Therefore, this configuration seems to be an additional incentive to read such email messages immediately. The user is undecided about if this is a positive or negative behavior change. However, after this experience, she sets the initial delay higher, so that she has more time to reply until a message gets sent to the first device. After this event, additional changes were made to Active Messenger. Because one of the primary goals was not to send email to a pager if the user is active on the terminal, it was important to delay the sending to the first device by a few minutes to give the user time to read it. However, if the user is not logged into a computer, important messages are not sent to the pager instantaneously. The solution was to reduce the initial delay proportionally to the user's idle time. The longer the user is idle, the less the initial delay. If she is idle for more than 15 minutes, an arriving message gets sent to the first device immediately. The initial delay can be set relatively high, so that the user has enough time to read a message on the screen, without being stressed out by the agent. On the other hand, if she is away, a message is sent to the first device without any further delay. However, even this strategy can fail. One time, Activity Server went down, and Active Messenger didn't get any new location information. It was found out because all “locate” requests returned after 0 seconds, which is not possible. The user was irritated because Active Messenger forwarded all messages immediately to the first device, Canard, due to the fact that if the user is idle for more than 15 minutes, the first delay is reduced to zero minutes. Because “locate” didn't give any meaningful information back, Active Messenger assumed correctly that the user was not active. As a consequence, “locate” can be disabled in the preference file. However, it would be better if Active Messenger could detect a faulty server and ignore it as long as it is not functioning, perhaps even sending a warning to the user. 3.15Location modifies channel sequenceIn the current implementation of Active Messenger, the channel sequences are always the same. Location specific entries can reduce only the use of a certain device, but not modify the whole channel sequence for a category. However, if the user is out of town, she may want to change the forwarding rules for messages of a certain category, e.g., “important.” A possible solution would be to allow entries like “important = iridium, canard” in the location sections to modify the default channel sequence. However, this would make the behavior of Active Messenger less traceable. There is also another way of realizing this behavior. If the SkyTel™ status is “not receiving,” and therefore the channel is skipped, the agent sets the delay to the next channel to zero minutes. E.g., if the channel sequence is “canard, skytel, iridium (240),” and Skytel™ is skipped because sending is disabled, the message is sent immediately to Iridium™. Otherwise, if Skytel™ is active, Iridium™ likely won’t get used at all. It is like switching from Skytel™ to Iridium™, once Skytel™ is out of range. 3.16Disabling message sending to SkyTel™SkyTel™ claims that each message sent to a SkyWriter™ device will arrive eventually. However, our experience does not support that claim. Several times, messages that were sent to SkyTel™ did never arrive, even if the pager came back in range and was able to send messages. Because SkyTel™ messages are expensive, Active Messenger tries to minimize the sending. The first try was to stop sending messages if the last one didn't arrive, and start sending again when it arrives. However, because there are messages that never arrive, SkyTel™ can't be enabled anymore, unless the agent is restarted. The situation gets even worse if the user is away for a long time, and more than 100 messages have arrived since the last message was sent to SkyTel™. In this case, the agent is completely locked up and is not able to give the channel free again. This was unacceptable, so two features were built in to prevent a complete locking of SkyTel™. First, only if two messages in a row don't arrive, the sending is disabled. Second, if a message arrives from the pager, the channel is enabled again, regardless of its previous state. Another method could be implemented: It is possible that a SkyWriter™ device comes back in range and can send messages, but the central server does not register the hand set. In this case, sending a message to the device would make it register properly with the server, which in turn may resend all the messages that haven't been delivered yet. So if the sending of messages to SkyTel™ is disabled, the agent could send a few test messages to “wake up” a not properly registered hand set. Directory: ~stefanm ~stefanm -> Mit media Lab Stefan Marti mit media Lab running head: Active Messenger Download 0.67 Mb. Share with your friends:
|