GTG's panel applet list is bad at managing large numbers of tasks

[Feathertail]

Binary package hint: gtg

CONTEXT

GTG has no apparent upper limit on the number of tasks you can log in it. It can function as an "everything basket" like Tomboy Notes, except only for things that you're planning on doing instead of remembering. In this sense, GTG is almost a bug-tracker for one's life.

PROBLEM

GTG's panel applet's task list (when it's working; see bug 548836 ) shows all of your tasks, including the ones that are filed for long-term. This makes it very un-useful if you have more than a few tasks logged in GTG.

EXPECTED BEHAVIOR

The task list will be more relevant to people with large numbers of tasks listed. See bug 591920 for one suggestion. Others might include letting you somehow filter by tag in the panel applet, or letting you use the main window to mark certain tasks for today's work.

ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: gtg 0.2.4-1ubuntu1
ProcVersionSignature: Ubuntu 2.6.32-22.36-generic 2.6.32.11+drm33.2
Uname: Linux 2.6.32-22-generic i686
Architecture: i386
Date: Wed Jun 9 16:32:07 2010
InstallationMedia: Ubuntu 10.04 LTS "Lucid Lynx" - Release i386 (20100429)
PackageArchitecture: all
ProcEnviron:
 LANG=en_US.utf8
 SHELL=/bin/bash
SourcePackage: gtg

[Bryce Harrington (bryce)]

On Wed, Jun 09, 2010 at 08:37:19PM -0000, Murrquan wrote:
> PROBLEM
>
> GTG's panel applet's task list (when it's working; see bug 548836 ) shows all of your tasks, including the ones that are filed for long-term. This makes it very un-useful if you have more than a few tasks logged in GTG.
>
> EXPECTED BEHAVIOR
>
> The task list will be more relevant to people with large numbers of tasks listed. See bug 591920 for one suggestion. Others might include letting you somehow filter by tag in the panel applet, or letting you use the main window to mark certain tasks for today's work.

I agree this is a big problem with the indicator.

I make heavy use of start dates on everything for organizing my tasks,
as Luca suggested on #591920 but still the gtg indicator is bigger than
my monitor (it's common for me to have 50+ tasks in my daily workview).

Obviously, for situations where the workview is excessively long like
this, there needs to be a way to constrain it in some fashion. It seems
to me that the indicator is most useful when displaying a shorter list,
say 20 or fewer items.

The question though is, what should this constraint look like? Some
suggest limiting it by tag. That is probably the easiest solution to
implement, although it implies we'd need some way in the indicator to
select which tag to sort against, and that seems like a tough problem;
people with so many tasks that they need to constrain the list may well
also have an excessive number of tags!

Here is one blue sky idea... What if the gtg browser kept track of the
"last selected tag" (or "last selected task's tag") and communicated
that to the indicator. Would that be too confusing? Or would it enable
the indicator to better keep track of whatever context the user is in?

[Luca Invernizzi (invernizzi)]

What you're saying is to show in the applet menu exactly the same list
of tasks that is visible in the taskbrowser
(if a user selects a tag/goes in the workview mode, both the Browser
and the applet show the new set of tasks).

It might be a little bit confusing, but it would be quite handy too.
It would even be quite trivial to implement.
 The too-many-tasks problem is not completely solved with this
approach though, and I don't see an easy solution to that.

My long term goal, when we implement searches and saved searches (or
"views", in SQL terms), was to show one of those in the applet.

[Bryce Harrington (bryce)]

On Thu, Jun 10, 2010 at 10:00:53PM -0000, Luca Invernizzi wrote:
> It might be a little bit confusing, but it would be quite handy too.
> It would even be quite trivial to implement.
> The too-many-tasks problem is not completely solved with this
> approach though, and I don't see an easy solution to that.
>
> My long term goal, when we implement searches and saved searches (or
> "views", in SQL terms), was to show one of those in the applet.

Yeah we've had some discussions on the list regarding prioritization
schemes. My guess is as new filtering/sorting/prioritizing systems
become available, the indicator can hook into whichever of those are
most appropriate.