Opened 9 years ago

Last modified 8 months ago

#8726 new enhancement

User selection of saved statuses for the quick/popular list

Reported by: royce Owned by:
Milestone: Component: pidgin (gtk)
Version: 2.5.5 Keywords: popular saved status


Searching for a way to manipulate the list of popular statuses, I found the enhancement requested in #301 and read in earnest MarkDoliner's link to Free software UI and The Question of Preferences.

I believe that an enhancement to address the root issue is worth the costs listed there.

Please forgive the length. This topic is more complex than it may appear. I've tried to organize this to optimize for programmer time.


Allow the user to populate the list of popular statuses themselves. This broadens the fundamental usefulness of saved statuses, removes a bottleneck to future usefulness of IM as a technology, and could optionally reduce code complexity.


For status, popularity != frecency

Frecency does not map well to IM statuses for the following reasons:

  • Frecency works well for an ever-expanding list (like URLs) because it facilitates deeper access. For status, however, there is a natural point at which saving a status is not necessary (because it's simply not used enough). This means that saved statuses naturally break into two subsets: common saved statuses for quick selection (the 'popular' list) and those used often enough to save, but not often enough to keep handy (the full saved list). Frecency is not as good as the user at predicting which statuses should go in which subset.
  • Since there is no mechanism to seek, autocomplete, filter or search popular statuses (as in Firefox), the user must visually inspect a limited, non-scrollable list. This eliminates a significant part of frecency's usefulness. (Note that I'm not arguing for adding these features; they are overkill and would clutter the UI).
  • The dynamic ordering makes it difficult for the user to find a particular status.
  • Infrequently used statuses, once used, end up in the list. This bumps the ones that the user does use frequently. In other words, the popular list now contains non-popular statuses. This violates POLA.

For all of these reasons, frecency may not be the optimal method for populating the 'popular' list.

Status is power

For casual users (for whom the default statuses are enough), the 'popular' list is not yet needed.

Once users start to customize their own statuses, they automatically recategorize themselves. They have overcome the saved status discoverability 'hump' ("Oh, I can save statuses?") and now have a vested interest in quickly accessing statuses that match a given context.

At this new usage level, the 'popular' list becomes very important. Populating the list using frecency data without allowing the power user to control the content leaves them in a kind of 'power user limbo': the user wants to use saved statuses for the purpose that they were designed for (ease of changing statuses), but they are subtly constrained in a way that contradicts that purpose.

In other words: the power of saved statuses lies in the predictability, repeatability and speed of their use.

Why this preference matters

Using the preference criteria in the article:

  1. Understand the root annoyance: In a nutshell, it is that our ability to dynamically express recurring availability, schedule and focus is throttled. IM is a perfect fit for this expression.

Many technical people are grasping desperately for solutions to preserve focus. My ability to stay focused, and to communicate with other members of my sysadmin and programming teams, depends on clear and ubiquitous communication of status.

Many users of Pidgin are probably willing to incur the cost of manually driving deeper into the GUI every time because it is worth it to be able to express these concepts - but there is a cumulative annoyance cost because it requires manual intervention and thinking. This can break my concentration and stride - with all of the associated costs that that implies.

Programmers reading this should know exactly what I'm talking about here. :-)

  1. Can the issue be sidestepped? No. The solutions I know of are "manually type the one you want, that's faster" (which would be an argument for getting rid of saved statuses entirely, which seems false) or "keeping driving deep into the GUI" - neither of which seem adequate - precisely because they require more effort and thought.
  1. Is the annoyance significant? Yes. Expressing status should happen as often as is useful, and should have the lowest cost possible to preserve flow.

The cost of each status change today is as follows:

  • Bring up the list.
  • Visually scan an unsorted popular status list to see if the one you need is in it. (If it is, you have saved the cost of driving deeper into the UI, making this check worth the time - but adding to the annoyance factor if you cannot.) Psychologically, there is another impact: a status that I used earlier today, but I only use once a week, is in the list.
  • If not found, select 'Saved statuses' instead.
  • Visually scan the list to find the one that you need. (I have imposed a naming convention that sorts, to minimize this cost).
  • Double-click it (or press 'Use' and 'Close').

If the list was simply user-selected, and naturally sorted:

  • Bring up the list.
  • Visually scan the sorted list.
  • Click the status that you want.

Because such a list is static (until you elect to change it), the user quickly learns where each item is - to the point that the application recedes into the background - a mark of good design.

Reduce the cost, and the usefulness of statuses can grow.

  1. Preference overload: This is largely a solved problem. Preferences less likely to need changing can be squirreled away using the common 'show advanced options' metaphor.
  1. Impact on maintainability: If frecency is simply dropped, this would automatically reduce complexity. :-)

Proposed solution

In the 'saved statuses' dialog, add a 'Show in popular' checklist column, which defaults to all greyed out. Activate them when an 'Allow me to choose which statuses are considered popular' is selected. Present them in the 'popular' list in the natural sort order.

This could be implemented in a couple of ways:

Option 1:

Drop the frecency concept entirely, and simply let the user decide as above. This reduces complexity, but might impact users.

Option 2:

Leave the existing frecency intact, disabling it when manual control is activated. This option lessens the impact on the existing user base - though I would argue that casual users of the 'popular' list wouldn't notice, and non-casual users would all benefit from the change.


I took the time to write this because I have a personal and professional business case for it, given the cumulative cost of diving into the GUI to make status changes. I also feel that increased user control of the 'popular' list unfetters IM to express more sophisticated status concepts, more fluidly, that can help people to focus and communicate.

I submit this idea for consideration. if the community finds it useful, I am willing to donate or to find volunteers interested in tackling it. My hope, of course, is that the case speaks for itself and inspires the people who best know the code. :-)

Change History (5)

comment:1 Changed 8 years ago by BoffinbraiN

Nice analysis. I agree with the suggestions. Just one pointer: 'frecency' isn't a word - I think you mean 'frequency'. :)

comment:2 follow-up: Changed 8 months ago by royce

  • Milestone set to 2.12.1

BoffinbraiN, thanks ... eight years later, I realized that I forgot to reply!

Note that I used 'frecency' on purpose; it's a combination of "frequency" and "recent" (Wikipedia article)

comment:3 in reply to: ↑ 2 Changed 8 months ago by BoffinbraiN

Replying to royce:

BoffinbraiN, thanks ... eight years later, I realized that I forgot to reply!

Note that I used 'frecency' on purpose; it's a combination of "frequency" and "recent" (Wikipedia article)

Epic 8-year revive! This thing now has a milestone? I look forward to seeing it.

comment:4 Changed 8 months ago by Robby

  • Milestone 2.12.1 deleted

Please don’t set the milestone. Or do you intend to submit a patch? :-)

comment:5 Changed 8 months ago by royce

Apologies - not sure how I set a milestone (or why I would have the power to do so, as an end user?)

Note: See TracTickets for help on using tickets.
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!