[standards-jig] Groups in the Roster
mass at akuma.org
Sat Mar 16 00:41:08 UTC 2002
Ragavan S wrote:
>> I've been thinking of rosters a bit lately too. Is there really a
>> need for
>> more roster levels like that. I'm trying to think of the average
>> user of IM
>> and can't see them needing to have sub-groups... Just having different
>> groups is enough to organize their contacts. I'd think that
>> subgroups would
>> only confuse people. So my question would be, is this something that
>> be better or worse from a useability standpoint?
> From a pure usability standpoint, people (as in the average computer
> user) are pretty used to seeing tree-like structures on a GUI (Windows
> Explorer, for example). Even the buddy lists in most IMs resemble
> trees (though only one level deep). While I do agree that the average
> user may not have a need for sub-groups, I do see the use for this.
> One example, lets say you have devices as buddies. You may want to
> group each device (router, firewall etc)seperately and then within
> each device group, you may have geographic groupings(Americas,
> Asia/Pac etc) etc. So, I guess having the flexibility to have multiple
> levels is a good thing to have. While a simple IM aimed at the average
> user may only implement one level, the other sophisticated IMs will
> have the option of going to any levels.
There has been talk of this in the past - instead of having the current
'roster' structure, you could have a pure subscription list, and a
different structure representing the user representation of things (lets
call it an address book for right now).
This address book need not contain all items with subscriptions, or
require subscriptions to all things contained. It could even contain
things which are outside the scope of Jabber, such as web site
bookmarks. The needs here haven't been quite defined, but this would
obviously allow for more options and even for different representations
of address-book-type things for specialized applications.
It would change and break a ton of things though, more revolutionary
than evolutionary. Something to toss on the JabberNG fire.
>> useful scenario for this is a "work" roster and a "friends" roster.
>> your presence to these groups will often be different (typically
>> In other words, when you're available for work, you're usually not
>> for friends, while you may always be available for family...
You might also want to be available only for a subset of people on
different devices or locations - if you are on your cellphone, you are
only known to a subset of people - on a different network, even fewer
people. This is definately a different concept technically from roster
management, but might be represented closely within a UI.
More information about the Standards