[Pidgin] #8726: User selection of saved statuses for the quick/popular list

[Pidgin]

#8726: User selection of saved statuses for the quick/popular list
-----------------------+----------------------------------------------------
     Reporter:  royce  |        Type:  enhancement         
       Status:  new    |   Component:  pidgin (gtk)        
      Version:  2.5.5  |    Keywords:  popular saved status
Launchpad_bug:         |  
-----------------------+----------------------------------------------------
 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 [http://www106.pair.com/rhp/free-software-ui.html 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.

 = Summary =

 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.

 = Reasoning =

 == 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
 [http://en.wikipedia.org/wiki/Principle_of_least_astonishment 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.
 :-)

 2. '''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.

 3. '''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.

 4. '''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.

 5.  '''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.


 == Conclusion ==

 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. :-)

-- 
Ticket URL: <http://developer.pidgin.im/ticket/8726>
Pidgin <http://pidgin.im>
Pidgin