[JDEV] Chatting with the correct resource

[Daniel Chote]

This was one of the items ive always had an opinion on, since the very 
first day I started jabber development.. Ive tried 4 different 
approaches to this method now... And just from my point of view what im 
doing now is fairly efficient...  In the original Rival, i didnt really 
cater for resources, everything message was sent to a resource stripped 
jid.  Rival v2 was pretty much the same, but you "could" specify a jid 
if you wanted. Rival3 allowed you to view resources in your contact list 
if you wanted... if you started a chat session with someone, it would go 
to a recource stripped jid, but if you recieved a message from someone 
with a resource as the start to a chat session, i would send back to the 
jid with resource, so... if they got on another client at the same time 
and sent you a new message, it would create a new chat window based on 
the new jid...  In the new Rival's that im working on, i take a little 
more complex approach.  Each roster item in the list as a default 
resource value, which is generated by collating all the presence 
recieved from a user, and then ordering it based on <show/>... so.. if 
someone had 2 resources active, one away and one online... the online 
resource gets set as the default, if the presence changes, it resorts 
based on the best one...   So, when a chat session is started, it goes 
to the resource thats got the highest status..  Im however not looking 
at presence priority at this point (as most of the time its irrelevant 
or not recieved :P).

So thats how I do it in Rival... I dont feel this is something that 
_needs_ to be standardised across clients, mainly because of the 
different user experiences offered by having the selection.   *Not 
everyone likes the MSN experience*

-Dan

Bart van Bragt wrote:

> Mikael Hallendal wrote:
>
>>> So IMO in these cases it would be nice if there was some 'Client UI 
>>> design best practices'-guide :D
>>
>> The fact that you are sending over Jabber shouldn't enforce anything on
>> your UI. I think however that it's very important to have rules on how
>> to behave with other clients (these are called specifications).
>
>
> True, from a technical point of view :D
>
>
> Indeed, users won't switch to another client all that often but for me 
> it's kind of hard to help a friend that's using Exodus while I'm on 
> Psi. I have no clue how Exodus handles this resource priority stuff. 
> IMO the user should be able to predict what will happen to their 
> message when they use a Jabber client, regardless of the specific 
> client that they use. This is _really_ important from a usability 
> point of view. The resource problem is only a minor aspect of that. 
> IMO the installation/JID problem is a bigger problem. It's just 
> impossible to help someone with getting Jabber working without either 
> looking for documentation about the specific client (which doesn't 
> exist for 9 out of 10 clients ;)) or installing the client yourself.
>
> IMO it isn't that hard to just create a small convention about the 
> JID/Password form? If a particular client developer really feels that 
> they way he/she invented the wheel then he/she can do what they want 
> but if there is some kind of basic UI guideline then there will be at 
> least _some_ conformity in basic area's like filling in the initial 
> connect form. This will make it a LOT easier to get people to use 
> Jabber. If users are already confused at the first screen then we're 
> going to lose a LOT of users before they've even tried Jabber.
>
> Again: I'm talking about a guideline. At the moment clients devs are 
> (luckily!) looking at each other to see how (some) others do it. All 
> that would be needed is a small document that actually documents how 
> most client devs do these things. All this to create some conformity 
> in the basic UI elements. If devs want to expand on the basic elements 
> then more power to them ;)
>

-- 
Daniel Chote
Developer/Designer and typical drunk!
email/jabber: daniel at chote.net
blog: http://daniel.chote.com
website: http://www.chote.com