Variable states by buddy

Not sure how much list cross-over there is, but the TidBITS Talk 
mailing list has been discussing a rather interesting proposal for 
changes to iChat states, proposed by Adam Engst. Much of what has been 
discussed is totally pertinent to Fire as well.

Read the whole thread here: 
<http://emperor.tidbits.com/[email protected]@.3c44fb7c>

Many of the suggested features are impossible given current 
client/server limitations, but one of them struck me as incredibly 
useful once the discussion got underway. (I'm the bald guy in the 
message thread, if you're wondering.)

> * Available/Busy. The problem with iChat's Available state is that it 
> doesn't let you set the privacy options at the same time; they're 
> available only in the Preferences window, aren't easily changed, and 
> aren't sufficiently specific. When you're available to chat, you're 
> really saying, "I'm available to chat with the following people." That 
> might be all people, anyone in your Buddy List, anyone in a specific 
> group in your Buddy List, a single person, or absolutely no one. So, 
> when you choose Available, you should also be able to choose, either 
> via hierarchical menus or a second pop-up menu, the set of people for 
> whom you're actually available. Those people would see your state as 
> Available; everyone else would see it as Busy and would receive an 
> automated response if they try to initiate a chat.
>
> This approach to Available/Busy is key, I think, since it lets you 
> represent your willingness to chat in any way. It lets you be 
> available to anyone if you're happy to chat with anyone who knows your 
> screen name. If you're open to chatting but want to avoid messages 
> from random unknown people, limiting it to your Buddy List makes 
> sense. If you're working hard on a project with a group or with an 
> individual, you can ensure that no one else can interrupt you. And if 
> you're concentrating hard and will swear at anyone who interrupts, you 
> can eliminate all disruptions while still being able to contact 
> others.
>
> The automatic response capability is also important, since it lets you 
> explain why you're not accepting incoming messages, either because 
> you're too busy or because you're actually away from the computer.

After a bit of thought, I came up with this idea on how to implement 
this change:

> A very simple way to implement this sort of change would be at the 
> client side. Rather than have your state change visibly for other 
> users (ideal, yes, but unsupported by current protocols), you could 
> simply change your state to "Busy" or leave it as available. However, 
> at the client end, you would specify users to whom you are 
> available/busy/whatever.
>
> When an incoming message comes from an acceptable buddy, you would 
> receive the message as normal. However, when a blacklisted 
> (greylisted?) buddy IMs you, they would get an auto reply (something 
> like "Sorry, I'm busy right now, but I did get your message. I'll get 
> back to you when I have more time."), and their message would be 
> queued. (Perhaps with a visual notification -- e.g. a number of "held" 
> messages next to their buddy icon.)
>
> Then, if you have free time, you could view those pending messages, 
> reply to them, whatever you like.
>
> Granted, the use of visual states would add a lot, but a simple form 
> of whitelisting desirable messages and "taking a message" for less 
> desireable ones makes a great deal of sense.
>
> As I think on it, setting a state of "Busy" at these times of 
> selective availability makes a great deal of sense. A busy state 
> conveys that you are not free to just shoot the breeze, but that you 
> are at the computer and available for important messages. A bit of 
> education for your buddies would be required, but that's about it.

What do the rest of you think? Is the ability to set yourself 
selectively online worthwhile? Would it be handy to let unwanted 
messages just queue up somehow for later review?

I think this sort of feature could be terribly useful for some people, 
and might really break some new ground for Fire if implemented in a 
later release. I'm not sure how much code it would require, but it's 
mostly just working off of current technologies.

--Nik