[JDEV] Jabber Client Design Tutorial

[Jay Curry]

>> But, even if a user doesn't intent to log on multiple times simultaneously, a description 
of where they are currently logged in from is still useful.  Surely it is clear to a user that 
they are entering a description of what computer they are logging in from and when 
they look at another user in their roster they can see where they are logged in from?... 
even if they don't understand the concept of resources and how they interact.
>> 
>> If I gave a Jabber client to an inexperienced Jabber user and it said enter a 
description of where you are connecting from, they would enter "Home" or "Laptop" or 
something and then they would never have to worry about it again.
>> 
>> Julian (the other one)
>> 
>
>
>Well, in the few tests I did, whenever I asked for something like that, they would turn 
around and ask me if I meant their country or their city or what. However, this was most 
likely an issue of wording which deserves further investigation. Asking the user to enter a 
description of where they're connecting from doesn't solve very much since they still 
don't get a complete understanding of resources.
>
>

One way around all this would be a set of suggestions for reasonable resource strings. 
WinJabber does this with a pulldown. I have not tried entering my own in there as 
"Laptop" just about describes what I am working with at the time. 

If you are running a logging client, to capture your IM's that are not cached elsewhere, 
'Logging" seems reasonable to me. If it is important to you that people know whether 
you are at work (work), home (home), at a convention (peer.networking), or sitting in the 
middle of the lake pulling in walleyes (occupational.rehabilitation), you could select or 
create an appropriate  resource for that. You could even have a resource that would 
capture IMs and forward them to your text pager or digital cell phone with a resource 
name "pager". 

While a well written application should be intuitive, and not require the user to spend an 
inordinate amount of time looking up explanations for what is expected in different fields, 
sometimes it makes sense to provide redily available help or suggestions for each field 
as well.

For clients that perform services for you, either as avatars, such as a jabber callendar 
client which could im a pager client to remind either yourself or a peer that it was time 
for a meeting, or to pick up something for your aniversary before you got home, or a 
pager type client that is inbound only, it would make sense to have pre-defined 
resources that other clients would recognize, and treat appropriately.

In any case, a first time user is not going to know intuitively what some of the more 
arcane resource names mean. If they are using WinJabber, how likely is it that they will 
recognize that the resource "Marvin" could be an indication that the user of the "Marvin" 
jabber app (A fully skinable Jabber client for Windows written in Euphoria) decided not 
to enter a custom resource {presuming that 'Marvin" were the default resorce for that 
app, I don't know.} They might just think the user is having a particularly bad day with 
pains running up and down their left arm, and mistakenly try to cheer the user up.

Just some ideas. 

Others include using 'services' numbers or names for resources if they are specific to 
some service. 25:smtp for a mail service, 79:finger for a response about the user, (other 
than a vcard) 80:http for the users home page, or hot link of the day, or whatever., 
444:snpp for paging, 533:netwall for emergency broadcasts 555:whoami for a response 
based upon pulling down the vcard of the person contacting that resource, and the like. 
Resources for services available in clients could be shown either by service name, or 
number, and user clients could be designed to ignore those resources unless the user is in 
some advanced mode. I would suspect that properly written service clients would 
discard messages that were improperly formated, or log them to some sort of a syslog 
resource some place. 

A user "manager" client could be created as part of a user client, and it would look for 
resources for users that have agreed to notification both ways, and depending upon 
each user's paranoia index can either add those contacts to the local facilities, or make 
available similar resources to the other user. I think it could work something like a shared 
callendar where some events are not available to other users of the shared callendar, 
some are only "I am unavailable for this block of time" events (my peers do not need to 
know that I have to take my cat into the vet, but they probably shouldn't attempt to 
schedule a meeting for me while I am there.) And others are fully shared, "I will be 
involved in the annual review of all of your budgets today, do you really want me upset?"

Likewise I may want my pager available for co-workers and supervisors, but not for the 
jokers I quaf a few with every wednesday night.

-Rusty