[Telepathy] [Usability] Empathy is planning to make chats persistent - requires design changes

[Chandni Verma]

On 11 April 2011 14:16, Allan Day <allanpday at gmail.com> wrote:

> Chandni Verma wrote:
> > Hi Allan,
> >
> > Thanks for looking into the issue.
> >
> > On 8 April 2011 18:43, Allan Day <allanpday at gmail.com> wrote:
> >         Hey Chandni,
> >
> >
> >         Chandni Verma wrote:
> >         > The Usability Team,
> >         >
> >         > Empathy is planning to make chats persistent so that closing
> >         a chat
> >         > window does not affect the connectivity of the user to the
> >         chat-room.
> >         > In order to accomplish this, we need to make some
> >         non-trivial design
> >         > decisions which require your creative input before embarking
> >         upon on
> >         > it.
> >         >
> >         > Bug link: https://bugzilla.gnome.org/show_bug.cgi?id=599184
> >         >
> >         > Related bugs having ready branches:
> >         > https://bugzilla.gnome.org/show_bug.cgi?id=643295
> >         > https://bugzilla.gnome.org/show_bug.cgi?id=643755
> >         >
> >         > Related bug closed as redundant:
> >         > https://bugzilla.gnome.org/show_bug.cgi?id=601162
> >
> >
> >         A key question here is how rooms get added to the contact
> >         list. Getting
> >         the user to manually add them isn't a great solution, since
> >         it's labour
> >         intensive and potentially lacks discoverability.
> >
> > I had in mind that whenever a user connects to a chatroom and marks it
> > as "Persistent",
>
> It's this manual adding part that I'm unsure about. It would create
> extra work for users who want to take advantage of the new feature, and
> it would add complexity to the interface.


> > the chatroom will be added, in a "Rooms" special group holding MUC
> > rooms in the contacts roster and the room will be removed from the
> > group as soon as the channel is explicitly closed (chat is left/parted
> > or the full chat window is closed not just a tab[?]) except when the
> > room is marked as favorite in which case it will stay in the "Rooms"
> > group even when disconnected.
> >
> > So basically there are two binary variables for deciding when rooms
> > get shown in the contact list:
> >
> > Favorite                 Persistent               Shown in "Rooms"
> > group
> >     0                              0
> > 0
> >     0                              1
> > 1
> >     1                              0
> > 1 (just for clubbing all favorite rooms together and maybe we can
> > remove the main window "Room"
> >
> > menu altogether)
> >     1                              1
> > 1
> >
> >
> > So now if the user wants to make chats persistent (keeping in mind
> > there may be some who don't want to use this functionality) he just
> > needs to mark it as "Persistent" and the room will stay connected and
> > displayed on the contact list until explicitly left. If he wants the
> > chatroom to stay in the contact list even after explicitly leaving the
> > room, he additionally needs to mark it as "Favorite". These should be
> > easy one click CheckMenuItem in the respective chat windows and even
> > on the menu popped up when right-clicking the room in contact roster
> > so this should be discoverable also.
> >
> >
> >         On the other hand,
> >         adding all rooms to the list risks swamping it with chat
> >         rooms, so that
> >         it is hard to see actual contacts.
> >
> >         Is this something that has been thought about?
> >
> > This shouldn't be a problem when we have a separate "Rooms" group
> > which will be storing all currently connected and favorite rooms.
>
> So maybe add all rooms there? (That's an honest question - would it
> work?)
>


Yes, why not, we can have this feature made compulsory by default for all
chats but I liked your mock-up for all the reasons!




>
> >         The general aim of this feature seems to be to minimise the
> >         scalability
> >         limitations of tabs, as encountered by heavy muc users. If
> >         that is the
> >         case, there might be other (potentially more radical)
> >         approaches that
> >         could solve the problem more effectively. A conversation view
> >         might be
> >         one such possibility.
> >
> > I think, the inability to close chatroom windows is a weakness of
> > Empathy
>
> It's only a weakness in the context of a high numbers of tabs: it's the
> design of the rest of the application that is leading to the need/desire
> to close the window.
>
> I've been playing around with some ideas for a conversation-based chat
> interface [1]. Maybe not that useful, but it shows how you could have a
> chat program which avoids the need for opening and closing chats in
> windows or tabs. It's more of a browser.
>

As a user I liked what you showed!
The interface very much resembles that of XChat IRC and we actually never
feel like closing individual IRC channels there until we really want to
leave the rooms. The only difference is that in XChat we are allowed to
close the conversation window without leaving the chats and it being the
main window of the application, rests in and can be revoked from the system
tray (but that's ignorable).

So yes, I think, we can have this design for a single chat window with a
scrollable tree-view on the left pane holding all chats, private MUCs and
chatrooms (again in a separate "Rooms" group to keep them organized)
scratching off the need for persistent chats.

Just a little change I would suggest, for rooms, in case of members being
shown as icons on the top, we should have another scrollable tree-view for
holding them on the right end of the chat window as those numbers could get
quite large!

Now here's some major redesigning required. Thanks for your suggestions
Allan!





>
> > specially when users are used to having other applications like Pidgin
> > allowing them to close the windows without leaving the rooms. I expect
> > this feature to be optional though!
> > If there are scalability limitations for tabs, then that's a bug which
> > needs to be addressed irrespective of whether this feature gets
> > implemented or not!
> >
> > PS: Other Empathy developers' views on this are very much requested.
>
> Best,
>
> Allan
>
> [1]
>
> http://gitorious.org/gnome-design/gnome-design/blobs/master/mockups/empathy/conversation-view.png
>
> --
> Blog: http://afaikblog.wordpress.com/
> IRC: aday on irc.gnome.org
>
> Regards,
Chandni
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/telepathy/attachments/20110411/db6d9828/attachment-0001.htm>