Re: [Usability] Empathy is planning to make chats persistent - requires design changes
- From: Chandni Verma <chandniverma2112 gmail com>
- To: allanpday gmail com
- Cc: usability gnome org, telepathy lists freedesktop org
- Subject: Re: [Usability] Empathy is planning to make chats persistent - requires design changes
- Date: Mon, 11 Apr 2011 22:14:34 +0530
On 11 April 2011 14:16, Allan Day <allanpday gmail com>
It's this manual adding part that I'm unsure about. It would create
Chandni Verma wrote:
> Hi Allan,
> Thanks for looking into the issue.
> On 8 April 2011 18:43, Allan Day <allanpday gmail com
> 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
> > 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",
extra work for users who want to take advantage of the new feature, and
it would add complexity to the interface.
So maybe add all rooms there? (That's an honest question - would it
> 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"
> 0 0
> 0 1
> 1 0
> 1 (just for clubbing all favorite rooms together and maybe we can
> remove the main window "Room"
> menu altogether)
> 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.
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!
It's only a weakness in the context of a high numbers of tabs: it's the
> The general aim of this feature seems to be to minimise the
> 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
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 . 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.
] [Thread Prev