[sldev] Roadmap: 1.19.0 Viewer

[Matthew Dowd]

My few points:

i) some of the (IMHO) bad design decisions recently made in the current communicator UI were due to thinking of the communicator as a standalone messaging client - it isn't, it is an integral part of the SL viewer. That basic fact has consequences - the message UI has to fit within a different set of workflows; the message UI needs to be such that it doesn't get in the way of interacting with the 3D world. That a standalone messaging client may work differently is not really an issue since a standalone message client is not trying to be part of the 3D virtual environment.

ii) many regard passive mode as a feature which makes the SL communicator better than a typical messaging client - not worse. It has never occured to me to think of passive mode as "wierd" in SL, it seems quite natural. On the other hand, it seems odd that other messaging clients do not have something equivalent.

iii) many have built the way group IMs currently work into their workflow - removing functionality in this way will be seem as a deteriation of SL functionality not an improvement

iv) as others have said, the issue isn't really passive versus active but a UI one. I don't think anyone would have any real problem with the backend processes/protocol moving to the active model provided that
  a) you can auto-connect to selected group IM chats at logon
  b) you did not *have* to keep the group IM tab open in order to be and remain connected to a group IM chat - the idea expressed elsewhere have having a little icon in the group list ala the friends icons is a good one.

v) Assuming we get the UI acceptable, would moving to active mode mean the group limit could be increased? Instead (to keep db load down), the number of groups you could auto-subscribe to might be limited to 25?

vi) One of the issues with the communicate window at the moment is tab clutter. This results in the window taking up too much valuable screen estate and IMs being overlooked since the flashing tab to indicate a new message gets lost amongst all the other tabs! One solution, I've proposed is to stack the tabs vertically (http://jira.secondlife.com/browse/VWR-3265), which was generally well received although it was suggested this should be optional (and I've not had a chance to revisit this).

Matthew


________________________________
> Date: Wed, 9 Jan 2008 14:12:20 -0800
> From: kelly at lindenlab.com
> To: Anders at Arnholm.se
> Subject: Re: [sldev] Roadmap: 1.19.0 Viewer
> CC: sldev at lists.secondlife.com
> 
> Anders Arnholm wrote:
> Argent Stonecutter skrev:
> On 2008-01-09, at 12:11, Abh Serechai Belxjander wrote:
>   Voice is its own "subservice" thread and seperate server,
>   Why not the same using IRC as a backend for chat?
> 
> Jabber, please.
> 
> Jabber back end would be really great... and jabber login :-)
> 
> Even jabber does not support the 'passive listener' mode, where you auto join a channel you are 'interested in' when someone says something in the channel.  Even just typing that it seems bizarre that we have developed chat to a point where that makes sense.  It could of course be done with a client hack where you join the channel just don't draw the tab until you get an actual chat line (not a join/part message etc) for the channel/room/group.  Every dedicated chat system that I know of only has 2 modes: you are in the channel and can see the chat or you are not, and you won't see the chat.  The half way sort of interested but not really there until something interesting happens is *weird*.  I would very much like to see us move away from that model if possible.  Does anyone know any other chat system that behaves this way?
> 
> Disclaimer: The above is not a statement of intent or work - Jonathan is doing some good work on meeting more people's expectations than I would.  It is merely me expressing my desire that more of our system work in "industry standard" ways when at all possible.  Someone is going to read this and interpret it as "LL says they are going to do FOO" - and the fear of that happening has prevented me from discussing issues on this list in the past.  I'd like to get past that, so the disclaimer is now almost as large as the actual content of this message.
> 
> If we were to move to a 'standard' chat backend (woot! yes! I love that idea! jabber or whatever!) we should try pretty hard to have as few exceptions or special cases to how it works as possible.  In other words, I think we get a lot more out of using a standard chat system if we behave like a standard chat system than if we were to behave like our own special little chat system just using a standard backend.  Even though the latter case still has some value.
> 
>  - Kelly

_________________________________________________________________
Telly addicts unite!
http://www.searchgamesbox.com/tvtown.shtml