[JDEV] Jabber Client Design Tutorial
jens at mac.com
Mon Sep 24 12:27:57 CDT 2001
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
* 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
* 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 3547 bytes
Desc: not available
More information about the JDev