[JDEV] Jabber Client Design Tutorial

[Darren McVean]

I think the concept of this document is fantastic and extremely important.
Whilst a lot of us involved in Jabber might not be particularly interested
in UI's, it is probably more important to Jabber's success in the short term
than the server. I say this only because it's very frustrating and
disappointing to see supposedly "informed" tech writers slag off Jabber
because of a client app they downloaded and couldn't figure. TechTV, gave
jabber a 1 star. They didn't even mention the server, cause to the end user
it doesn't mean anything.

No need to preach here, cause we're all believers. But if we can start to
foster some UI "what ifs" discussions (maybe here, maybe not) and start to
think from the end users point of view, whether they be students, parents,
newbie's, business, etc, then when asshole's like TechTV do a review they
will see a number of clients that get their little brains thinking. Sorry,
but I couldn't believe it when I saw Jabber get a one star and other useless
crap out there get 5's. 

I'm going to start working on some designs for clients to get some comments
from everyone. Anything that gets us thinking about the end user and how
they use Jabber is a good thing.

Keep up the great work guys.

cheers,
Darren

 





 

-----Original Message-----
From: Julian Missig [mailto:julian at jabber.org]
Sent: Monday, September 24, 2001 6:57 PM
To: jdev at jabber.org
Subject: Re: [JDEV] Jabber Client Design Tutorial


First off, I don't believe in the idea of having similar-looking Jabber 
clients. It would be nice to have a defacto client for each OS which 
looks and acts similarly, but beyond that, I want creativity to shine. I 
want to see different approaches at IM, not 20 VB clients for windows 
which look and act *exactly the same* - what's the point in that?

Replies within.

Jens Alfke wrote:

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


Actually, latest jabberd does support invisible.


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


According to all statistics I can get ahold of and from various small user
tests - people do *not* easily understand the concept of a resource unless
they specifically intend to be logged in multiple times - and *most* users
never use that feature of Jabber. Therefore, 'Gabber' is the default
resource to reduce confusion - if the user doesn't understand it, they don't
have to become frustrated trying to figure out what is going on. They can
live happily without know what a resource is. That's the entire point of the
MacOS HI guideline which states that options are nice, but you *must* *have*
*good* *defaults*.


If in the future the majority of users need to understand the concept of 
a resource, I'll gladly remove the default, but the point of UI is to 
reduce the amount of information a user must learn and retain.

I need sleep



Julian
-- 
email: julian at jabber.org
jabber:julian at jabber.org

_______________________________________________
jdev mailing list
jdev at jabber.org
http://mailman.jabber.org/listinfo/jdev