Re: [JDEV] Jabber Client Design Tutorial

[Jens Alfke]

I think it's great that someone is paying attention to UI design, but I doubt that this document is going to be too useful. My impression is that developers who really care about good UI will tend to already know the things you're pointing out (they will steal ideas from the commercial clients, or actually do user testing, or think creatively about how to solve UI problems), while the majority(?) of developers for whom UI is an unpleasant chore will simply hack together something ugly that does the job. (At the risk of starting a flame war, in my experience nearly all Unix programmers tend to fall into the latter category.) No design document like yours will really reach the people who don't care about UI.

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.

* 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.)

* 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.

* 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?

* 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.

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.

--Jens