After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 670125 - Use tags instead of groups
Use tags instead of groups
Status: RESOLVED OBSOLETE
Product: empathy
Classification: Core
Component: General
unspecified
Other Linux
: Normal normal
: ---
Assigned To: empathy-maint
empathy-maint
Depends on:
Blocks:
 
 
Reported: 2012-02-15 09:58 UTC by Allan Day
Modified: 2018-05-22 15:21 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Allan Day 2012-02-15 09:58:56 UTC
The current buddy list design (bug 669484) largely reproduces the existing contact grouping design - mutually exclusive groups of contacts that are accessed using expanders. While this is useful functionality for some cases, it has some limitations:

 1. Manual grouping sucks (because it is hard work)

 2. Groups can't overlap - not very useful if you are friends with some people at work, or if you want to organise your contacts into subgroups

 3. You can't search for groups

A tag-based approach could help with these issues. Tags could be automatically generated for common characteristics - networks, email domains, G+ circles, etc. Tags could also be searched for and the method for displaying a single tag/group would be more direct than with expanders.

If we were to go for this approach I'd want to have a UI where it is possible to multi-select contacts in order to tag them.

Thoughts?
Comment 1 Guillaume Desmottes 2012-02-15 10:11:15 UTC
(In reply to comment #0)
> The current buddy list design (bug 669484) largely reproduces the existing
> contact grouping design - mutually exclusive groups of contacts that are
> accessed using expanders. While this is useful functionality for some cases, it
> has some limitations:
> 
>  1. Manual grouping sucks (because it is hard work)

Agreed.

>  2. Groups can't overlap - not very useful if you are friends with some people
> at work, or if you want to organise your contacts into subgroups

Actually it's not that true. XMPP allow you to have the same contact in more than one group, which is why the "set to group" UI in Empathy is a list of check boxes.

>  3. You can't search for groups

This could easily be hooked in our current live search implementation: if contact is in the group being searched then consider it as matching.

But why would you do such search? I can't think of any use case where would you search for a group rather than a person.

> A tag-based approach could help with these issues. Tags could be automatically
> generated for common characteristics - networks, email domains, G+ circles,
> etc. Tags could also be searched for and the method for displaying a single
> tag/group would be more direct than with expanders.

How would you represent such tags in the contact list?

I think we should first try to answer these 2 questions:
a) Are Empathy users really using groups?
b) If they are, how and why are they using them?

From my experience a) is definitely a 'yes', but more and more people are asking for a way to hide them (which has been added in 3.4 with a secret gsettings key).

b) is more tricky one. I personnally use groups to categorize contacts ('Work', 'FOSS', 'University', 'Family') but it's mainly because I'm use to do it and like to keep things organized. In pratice I don't use them that much as they are always all expanded.
Comment 2 Allan Day 2012-02-15 11:01:57 UTC
(In reply to comment #1)
> (In reply to comment #0)
...
> >  2. Groups can't overlap - not very useful if you are friends with some people
> > at work, or if you want to organise your contacts into subgroups
> 
> Actually it's not that true. XMPP allow you to have the same contact in more
> than one group, which is why the "set to group" UI in Empathy is a list of
> check boxes.

But the current UI means that you end up with the same contact appearing in the list more than once.

> >  3. You can't search for groups
> 
> This could easily be hooked in our current live search implementation: if
> contact is in the group being searched then consider it as matching.
> 
> But why would you do such search? ...

Because it is keyboard-based and fast. It might also be useful for combining filters and searches. You can find 'someone called Andrew who I know from work' with the current approach, but it does require that you search for Andrew and then collapse non-work groups, which is a bit of a hassle.

...
> How would you represent such tags in the contact list?

You wouldn't need them in the list. You would search for a tag and any matches would be displayed in the results.

> I think we should first try to answer these 2 questions:
> a) Are Empathy users really using groups?
> b) If they are, how and why are they using them?
> 
> From my experience a) is definitely a 'yes', but more and more people are
> asking for a way to hide them (which has been added in 3.4 with a secret
> gsettings key).

Totally agree that groups should be invisible if you don't use them.

> b) is more tricky one. I personnally use groups to categorize contacts ('Work',
> 'FOSS', 'University', 'Family') but it's mainly because I'm use to do it and
> like to keep things organized. In pratice I don't use them that much as they
> are always all expanded.

I think that groups are mostly useful if you have a very large number of contacts. There are two cases that seem particularly relevant here:

1. Organisational contexts - you interact with lots of people at work and need a way to get a grip on who does what. Since you work on projects involving different people, it is useful to be able to see the IM status of the people who you are working with at any one time.

2. Social networking - you have 2000 friends of Facebook and you use Facebook chat to interact with a small circle of close friends.

Incorporating a list of recent conversations would somewhat address the second case.
Comment 3 GNOME Infrastructure Team 2018-05-22 15:21:21 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/empathy/issues/500.