GNOME Bugzilla – Bug 669484
[design] New contact list view
Last modified: 2012-06-15 11:51:53 UTC
From https://bugzilla.gnome.org/show_bug.cgi?id=661713#c2 """ https://bugzilla.gnome.org/attachment.cgi?id=206259 Buddy list mockup Giving the existing Empathy UI more of a GNOME 3 look and feel would be a good way to get going with this. I think that the buddy list would be a great way to start, and would be beneficial to current Empathy users anyway. I've attached an initial redesign for the Empathy buddy list. Note that this does not address the menu bar or toolbar - the design is purely for the list. It does a few things: * Makes the contacts look consistent with GNOME Contacts * Clears out some visual noise (no repetition of 'Available', symbolic icons rather than detailed ones, etc) * Bigger avatar images, which makes it more expressive * Additional padding lets the content breathe """
I started working on a prototype widget to display contacts.. It needs to be benchmarked https://github.com/seiflotfy/gnome-prototypes/tree/master/empathy
Alexander started working on a new container widget we could use as well. So I think we have 2 options here: pick up Alexander's work or continue using GtkTreeView. Here are the info I received from Alexander: """ Yes, I started on one some time ago. Its basically a regular container, kinda vbox:ish, that also lets you sort and filter the children and have an optional separator between lines (used for the contacts between contacts with different initial letters). The idea is that you just put the whole thing in a scrolled window and shove ordinary widgets in it. I got it working pretty well in a basic mode, but things got more complicated when it came to keyboard navigation and focus handling/display, and I didn't have time to continue working on it. One problem was where keyboard naviation should be handled (child or container) and who should draw the focus and how. Things get kind of complicated wrt focus and keynav if the row contains "interactive" widgets like a button. Another problem was with the focus drawing. Ideally the child should be fully responsible for all the rendering of the row, as it and only it knows what to draw when the focus is not drawn. However, i wanted a widget where you can put anything into it, not a particular kind of "child of list view" widget type only, which made it more complicated. If you're interested in what I have (which is really just a proof of concept thing) I pushed it to the wip/sorted branch of gnome-contacts. """
New version proposed by Allan: http://dl.dropbox.com/u/5031519/empathy/contact-list.png
Created attachment 214258 [details] new mockups (In reply to comment #3) > New version proposed by Allan: > http://dl.dropbox.com/u/5031519/empathy/contact-list.png I've attached a new version of the mockups. Some notes about this... Returning to this design, it felt quite messy and difficult to read. The main job of the list is to help you find a contact; all the extra information on there was getting in the way of that. The new design is simpler and easier to read. I've made an effort to make it easy to scan the list of contact names without extraneous details getting in the way. The height of each row has also been decreased to show more contacts at once (the avatars are now 48x48px). One new idea here is to create a group of (say, ten) most recently used contacts, and to put that at the top of the list. This works on the assumption that most people frequently return to a small set of contacts. We could use more sophisticated heuristics to identify this set of contacts in the future. You'll notice that the new design doesn't include details of video/audio capabilities. I felt that this wasn't worth having in the list. You should be able to see if you can call a contact if you select it (see bug 676082), and I was never able to include the audio/video information without drowning out the most important information (the contact name and picture).
(In reply to comment #4) > One new idea here is to create a group of (say, ten) most recently used > contacts, and to put that at the top of the list. This works on the assumption > that most people frequently return to a small set of contacts. We could use > more sophisticated heuristics to identify this set of contacts in the future. I like this idea (that's something we have been considering doing since a while). Are those contacts still displayed below (as part of the 'normal' list) if we don't use groups? What about favorites contacts? Atm they provide two things: - Stick the contact to the top of the contact list: kinda redundant assuming your favorites contacts will probably be in the top used list anyway. - Displayed even if they are offline. Some people really this to quickly check the presence status of the contact. Maybe favorites and most-used could be merged together (contact is displayed on the top if he's in at least in one of those list) and so 'top contacts' would always be displayed, even when offline. > You'll notice that the new design doesn't include details of video/audio > capabilities. I felt that this wasn't worth having in the list. You should be > able to see if you can call a contact if you select it (see bug 676082), and I > was never able to include the audio/video information without drowning out the > most important information (the contact name and picture). Loosing that info makes me a bit sad but maybe that's for the best...
(In reply to comment #4) > The height of each row has also been decreased to show more contacts > at once (the avatars are now 48x48px). Could you please include the new height/width of the different part of the UI (as you did in http://bugzilla-attachments.gnome.org/attachment.cgi?id=206259 ) ?
(In reply to comment #4) > One new idea here is to create a group of (say, ten) most recently used > contacts, and to put that at the top of the list. This works on the assumption > that most people frequently return to a small set of contacts. We could use > more sophisticated heuristics to identify this set of contacts in the future. This is not new at all. Seif already implemented this: telepathy-logger tells zeitgeist about conversations/calls, and a folks backend already exposes that info in FolksIndividual ifaces. The idea is that a call-ui would sort contacts by most called, chat-ui by most conversations. I'm not sure if that got merged already though.
(In reply to comment #5) > (In reply to comment #4) > > One new idea here is to create a group of (say, ten) most recently used > > contacts, and to put that at the top of the list. This works on the assumption > > that most people frequently return to a small set of contacts. We could use > > more sophisticated heuristics to identify this set of contacts in the future. > > I like this idea (that's something we have been considering doing since a > while). Cool. :) > Are those contacts still displayed below (as part of the 'normal' list) if we > don't use groups? I think we should only show each contact once in the list. > What about favorites contacts? Atm they provide two things: > - Stick the contact to the top of the contact list: kinda redundant assuming > your favorites contacts will probably be in the top used list anyway. > - Displayed even if they are offline. Some people really this to quickly check > the presence status of the contact. > > Maybe favorites and most-used could be merged together (contact is displayed on > the top if he's in at least in one of those list) and so 'top contacts' would > always be displayed, even when offline. ... Yeah, not sure how this would work with manual favourites. Combining them seems reasonable for now.
Created attachment 214644 [details] contact list layout guidance Here's some guidance on layout.
(In reply to comment #7) > (In reply to comment #4) > > One new idea here is to create a group of (say, ten) most recently used > > contacts, and to put that at the top of the list. This works on the assumption > > that most people frequently return to a small set of contacts. We could use > > more sophisticated heuristics to identify this set of contacts in the future. > > This is not new at all. Seif already implemented this: telepathy-logger tells > zeitgeist about conversations/calls, and a folks backend already exposes that > info in FolksIndividual ifaces. > > The idea is that a call-ui would sort contacts by most called, chat-ui by most > conversations. > > I'm not sure if that got merged already though. For reference, this is bug #672709 for have the API in folks.
The API is done now and waiting to be merged. :D
Created attachment 214862 [details] screenshot Here is a screenshot of the current state of this widget. Does it match what you had in mind? TODO: - Fix the separator bug (some rows don't have the separator) - Lighter separators (blocked by bug #676567) - Move the $n most used contacts on top - Groups - Live search
(In reply to comment #12) > - Fix the separator bug (some rows don't have the separator) > - Groups > - Live search Those are now done. For the record my WIP branch is http://cgit.collabora.com/git/user/cassidy/empathy/log/?h=new-roster-669484 Run ./tests/interactive/test-empathy-roster-view (--offline) (--groups) to test it
(In reply to comment #12) > - Move the $n most used contacts on top done as well (need Folks master).
Pencil and Paper mockup: This is my vision for the future of contact lists. It provides the most information in the smallest space. I even think that the background of each of my "blocks" could be colors of statuses. So that all GREEN contact backgrounds would be available, all ORANGE would be busy, all RED would be away, and all GREY would be offline. http://imagebin.org/214604 IDK why it put it sideways, sorry about that.
The new roster view is now used in the 'empathy' binary instead of the old view. Testing welcome. I didn't add the favorites contacts to the top of the list but tbh I'd rather do it post merge as this branch is already pretty big.
My branch is pretty big so I splitted things a bit: - bug #677940 adds support of most popular contacts - bug #677947 implements the new roster view - bug #677948 is about using this new view in the 'empathy' process - bug #677949 to clean up the old contact list preferences
I opened a bunch of extra bugs about non merge blocker improvements: - bug #678083 : better popularity heuristic - bug #678091 : display favorite contacts - bug #678092 : DnD support
(In reply to comment #17) > My branch is pretty big so I splitted things a bit: > - bug #677940 adds support of most popular contacts > - bug #677947 implements the new roster view > - bug #677948 is about using this new view in the 'empathy' process > - bug #677949 to clean up the old contact list preferences All fixed, closing this bug. \o/ Thanks to everyone involved.