Bug 183027 - unify UI for all messaging
Summary: unify UI for all messaging
Status: RESOLVED WONTFIX
Alias: None
Product: ECF
Classification: RT
Component: ecf.core (show other bugs)
Version: 1.0.2   Edit
Hardware: PC All
: P3 enhancement (vote)
Target Milestone: 1.1.0   Edit
Assignee: ecf.core-inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords: helpwanted
: 198110 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-04-18 14:39 EDT by Eugene Kuleshov CLA
Modified: 2014-05-09 12:38 EDT (History)
4 users (show)

See Also:


Attachments
One view to rule them all. (21.31 KB, image/gif)
2007-08-19 11:40 EDT, Remy Suen CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Eugene Kuleshov CLA 2007-04-18 14:39:34 EDT
Currently there are two views "Char Room" and "Group Collaboration" and in addition - popup windows are used for instant messages. 

It would be nice if all messaging user experience would be unified within one multi-instance view (i.e. similar to Search or Console views that can be cloned) that should also allow to detach windows (im or even irc/group).
Comment 1 Scott Lewis CLA 2007-07-19 03:05:35 EDT
Setting target milestone.
Comment 2 Scott Lewis CLA 2007-08-05 16:16:24 EDT
*** Bug 198110 has been marked as a duplicate of this bug. ***
Comment 3 Chris Aniszczyk CLA 2007-08-05 16:19:36 EDT
This is something that we will probably need to break up into little bugs as it's a bit complicated. Any ideas are welcome.
Comment 4 Remy Suen CLA 2007-08-19 11:40:15 EDT
Created attachment 76384 [details]
One view to rule them all.

Three chats for the CEOs by their window,
Seven for our bosses in their cubicles,
Nine for us all doing overtime,
One for the board in their dark boardroom
In the UI Platform where the Eclipse lie.
One View to rule them all, One View for chatting,
One View to bring them all and in the platform bind them.
In the UI Platform where the Eclipse lie.

To make things extensible, the idea here is that the section in red will be any subclass of Control. Of course, ECF will provide some standard subclasses to be used, but at the end of the day, this can be fully customized by adopters if need be. The layout that is being used here is StackLayout and the control will change based on the selection on the TreeViewer on the left.
Comment 5 Eugene Kuleshov CLA 2007-08-19 12:40:26 EDT
I think that idea with pluggable panel is the way to go (Outline, Search, Properties and History views all using it). Though widget on the left side may not be the optimal choice, unless there would be alternative options, i.e. dropdown like in Console or Search history, "clone view", and detach chat to a separate panel or even external window.
Comment 6 Chris Aniszczyk CLA 2007-08-19 13:48:44 EDT
How will this work for chat messages? If you have your contact list in the left panel... how do you know who is messaging you? 

In my opinion, I like the direction the left panel is taking as a replacement to the "contacts view" but to merge chatting and contact exploring in one view may be too much. An alternative is to expand the "messages/chat" view to be able to handle normal chats, IRC, etc...

I don't think we can come up with a "swiss army knife" type of solution for everything here.
Comment 7 Eugene Kuleshov CLA 2007-08-19 14:58:15 EDT
(In reply to comment #6)
> In my opinion, I like the direction the left panel is taking as a replacement
> to the "contacts view" but to merge chatting and contact exploring in one view
> may be too much. 

Great point. That navigation closely resembles contacts view. 

> An alternative is to expand the "messages/chat" view to be
> able to handle normal chats, IRC, etc...
> I don't think we can come up with a "swiss army knife" type of solution for
> everything here.

Chris, the main idea is to have single view placeholder for all chats, in order to unify the current variety.
Comment 8 Remy Suen CLA 2007-08-19 15:06:01 EDT
(In reply to comment #5)
> Though widget on the left side may
> not be the optimal choice, unless there would be alternative options, i.e.
> dropdown like in Console or Search history, "clone view", and detach chat to a
> separate panel or even external window.

The chatting window presented on the right hand side is intended to be detachable. At the moment, I just reparent it to a new Shell and then let it go. I have not explored the clone/new view bit because I haven't quite wrapped my head around it.

(In reply to comment #6)
> How will this work for chat messages? If you have your contact list in the left
> panel... how do you know who is messaging you?
> 
> In my opinion, I like the direction the left panel is taking as a replacement
> to the "contacts view" but to merge chatting and contact exploring in one view
> may be too much. An alternative is to expand the "messages/chat" view to be
> able to handle normal chats, IRC, etc...

Let me make this clear. When I was designing this, I did _not_ intend the contact list to show up here. You see remy.suen@gmail.com but that is an IM conversation with myself and _not_ an account. I don't understand what you mean by liking the direction that it's replacing it but then to say merging the two may be too much. o.O

(In reply to comment #7)
> Chris, the main idea is to have single view placeholder for all chats, in order
> to unify the current variety.

Exactly. Let me reiterate this one more time. This view is intended to house _all_ conversations related to the presence API, which includes both chat and regular IM conversations.

This view is in the works to satisfy this bug. This bug is a request to unify the UI for all messaging. This is what this view is supposed to do and nothing more. The 'Contacts' view is _not_ meant to merge with this view.
Comment 9 Chris Aniszczyk CLA 2007-08-19 15:37:52 EDT
oh ok, cool... I misunderstood!

+1!
Comment 10 Eugene Kuleshov CLA 2007-08-19 15:44:05 EDT
(In reply to comment #8)
> Let me make this clear. When I was designing this, I did _not_ intend the
> contact list to show up here. You see remy.suen@gmail.com but that is an IM
> conversation with myself and _not_ an account. I don't understand what you mean
> by liking the direction that it's replacing it but then to say merging the two
> may be too much. o.O

I somehow agree to Chris, that showing conversations like that is an unnecessary duplication of the contact list. That can be replaced with making contact list to act as a master view (perhaps with a help of quick filter for active conversations and maybe some additional decoration) and chat view as linked details view.
Comment 11 Scott Lewis CLA 2007-08-19 16:19:10 EDT
> 
> Exactly. Let me reiterate this one more time. This view is intended to house
> _all_ conversations related to the presence API, which includes both chat and
> regular IM conversations.

With an IM conversation (two participants), would the participant's list (on the right of this screen shot) have a single member...gone altogether...or something else?

How would multiple instances interact...i.e. if multiple IM and chat sessions are ongoing, what will happen when a message is received (i.e. notification) for IM and/or a chat room?

Can/could similar design also be used to present info about other types of conversations (e.g. phone and/or conference calls)?

Perhaps this should just be referred to as a 'conversation view'

Comment 12 Remy Suen CLA 2007-08-19 18:46:09 EDT
(In reply to comment #10)
> I somehow agree to Chris, that showing conversations like that is an
> unnecessary duplication of the contact list. That can be replaced with making
> contact list to act as a master view (perhaps with a help of quick filter for
> active conversations and maybe some additional decoration) and chat view as
> linked details view.

I'm assuming you're talking about pluggable thing you brought up in comment #5 like the 'Outline' view? Would this imply that I'll always have to have my 'Contacts' view up to engage in a conversation or have I been mistaken? Alternatively if we had the drop down like the 'Console' view, we could still switch convos, though the notification of messages may get a little iffy. I'm open to suggestions.

(In reply to comment #11)
> With an IM conversation (two participants), would the participant's list (on
> the right of this screen shot) have a single member...gone altogether...or
> something else?

Whatever you want. Write your own subclass of Control and throw it in there, that's entirely up to the implementor. At the moment I ported some of the code from MessagesView over.

> How would multiple instances interact...i.e. if multiple IM and chat sessions
> are ongoing, what will happen when a message is received (i.e. notification)
> for IM and/or a chat room?

The current intent is for the left Tree widget's labels to be the notifier (via changing colours or whatever).

> Can/could similar design also be used to present info about other types of
> conversations (e.g. phone and/or conference calls)?

As above, throw your own subclass of Control in it. 

> Perhaps this should just be referred to as a 'conversation view'

It can be named whatever. I am only writing the code.
Comment 13 Scott Lewis CLA 2014-05-09 12:38:49 EDT
Resolving as wontfix as resources not available for continued work.  If committer and/or contributor resources become available, then please reopen.