Some detailed points:

* You make the point that the client should integrate into the operating system's GUI, but then you show Mac-style flippy triangles for the group show/hide controls on a Windows client. For it to be Windows-like it should use the boxed "+" and "-" things that the generic Windows tree view uses.

I looked at that. The main problem was that I needed a three-phase icon (for when you get an event from someone in a collapsed group), and couldn't think of anything beyond the + and -. Also, to replicate the +/- style usually means showing the tree branches, which takes up horizontal room, resulting in wasted pixels.

* Your list of status states in Jabber is wrong. The default is called "Available", not "None". There is no "N/A", instead you mean "XA" ("extended away", and I have yet to see any coherent description of how this differs from regular "away".) Also, "invisible" is not currently supported by the Jabber server; if you manually set your presence to "unavailable" you stop receiving presence or messages. There's also an implicit "unknown" state for people whose presence you don't have a subscription to (presumably because they haven't approved your request yet.)

Noted. Thanks. The invisible issues has been covered on this list a few times, (although I can't find it in my archives for some reason) but the last answer I remember is that is was possible to do some type of invisible mode now. Is this wrong?

* You don't mention one issue that bugs me about current Jabber clients. The Jabber "resource name" is associated with a particular login. The best usage of this is to identify the location of the client, i.e. "work" or "laptop" or "home". For a non-PC client the type might be useful, like "cellphone" or "T900 pager". However, whenever I look at my buddy list it seems like most of the clients (gabber, winjab, etc.) just use the name of the client as the resource name. This is fairly useless -- usually I don't care what brand of desktop client they use. It is often useful to know whether they're at home, at work, in a cafe, whatever. IMHO the client, when first run, should ask the user to enter a resource name, and it should store that as a persistent preference. This type-in field should not default to the brand name of the client; it should be blank to encourage the user to type something meaningful.

Yes, the function of the resource should be clearly explained at the setup stage. It's a new concept in IM clients, so it does confuse new users. But is it useful to display the current resource on the client? Or is it ok to just have it in the settings?

* A related issue is how resources should be displayed in a client. If someone's online at two locations do they show up as two people, or as one person with two possible recipient addresses, or? Likewise, if someone has two known JIDs should they show up as separate people in the list or be coalesced into one?

I think each user should be displayed only once...and events should go to the resource with the highest priority by default, but it should be possible to send to resources with lower priority. But does this include offline resources? Should you be able to send messages to yourself at another resource?

* You might think about how the coming support for 'avatars' (pictures of users) can be integrated into Jabber user interfaces. Where should these be displayed? At what size? How do you configure yours? You want to give people a range of choices. A compact buddy list(tm) is efficient, but makes photos illegible. 64x64 photos look real pretty but take up a lot of room.

Yes - I've been giving it some thought.

In general I think your comments are useful, but they're not pushing the envelope. They merely reflect the current 'best' practices of commercial IM clients, which IMHO all suck. No one has really thought through the issues and tried to do something better; they're all just repeating AOL's and ICQ's mistakes.

Sucks why? "They all suck" is a little vague.

Michael.

Re: [JDEV] Jabber Client Design Tutorial

Reply via email to