[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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 3547 bytes
Desc: not available
URL: <https://www.jabber.org/jdev/attachments/20010924/1ffdf8ac/attachment-0002.bin>