gtg-contributors team mailing list archive

[Paul Natsuo Kishimoto <mail@xxxxxxxxxxxxxxxxxxx>]

Hi,

  I'm going to try and address both Lionel & Bryce's comments at once.
Thanks to you both for your compliments!

On Tue, 2010-06-08 at 09:47 +0200, Lionel Dricot wrote: 
> On Mon, 07 Jun 2010 18:59:45 -0400, Paul Natsuo Kishimoto
> I completely agree with adding the  duration field (even if I believe it
> should not be displayed by default in the UI but, instead, should be part
> of a "Project Management" plugin). I personnaly don't like the priority
> field as I believe it clutters the UI for nearly no information and I
> really feel that it's there everywhere for historical purpose.

In trunk, the task display in the work view currently looks like this:

Make Sandwich  Use the leftover corned beef and pastrami from...

...where everything from "Use" onwards is the preview of the task text,
in greyed-out text. *If* the user chose to set a duration for the task,
it would look like this:

Make Sandwich (10 min.) Use the leftover corned beef and past...

...that's all. If no duration is set, it looks the same. If I've got 20
minutes to do some work before I go out for lunch, this helps me pick
from the available things in my Work View.

> What I'm sure is that we don't want the GTK UI to display the priority.
> That's something that was one of the basics of GTG when we started it.
> Don't mess with artificial priorities : it simply add workload on the user.
> The Now, Soon and Later just provide the required information. 

  Right, and I didn't mean to suggest that. In the GTK UI, at least, the
user would not see or directly edit the priority. But if the user
started dragging-and-dropping tasks into different orders in the Work
View or full view, then I think a priority would be the best way for GTG
to remember that information.

  What does everyone else think?

> Can't we just have optionnal custom fields, just like tags have ? Would
> that be enough ? Maybe it would not be a good idea as every UI will add
> it's own custom fields and we will end with no compatibility between UI.

  I think that arbitrary custom fields would just be abused.

> >      3. Remove the task ID field.
> 
> I think Luca is right here. Don't remove the ID field but make it
> universal (should be straightforward). He's already working on this.  But,
> indeed, the UUID should be removed.

OK, I'll leave this to Luca then. The key points are:
     1. One ID field, not two.
     2. An ID that is universally unique.

On Mon, 2010-06-07 at 23:14 -0700, Bryce Harrington wrote:
> Regarding the duration field, if we support that in gtg I was thinking
> we should also have a "default duration" that is assumed when not
> otherwise specified.  All of us probably have different ideas of how
> long a "task" is, but we're probably mostly consistent across our own
> tasks, so this would save having to specify durations on most tasks.
> 
> It's also interesting to think that, knowing the duration per task, and
> number of tasks, you could quite directly figure out when you have too
> many tasks scheduled on a given day.  Mmm, that could be handy...

  What we could do is this: in the UI, if the user selects multiple
tasks in the Task Browser, a tooltip or other text could say "At least X
hours" or similar. "At least" if some of the tasks have no duration set.

  I don't know about assuming a default duration. Personally, I write
tasks as things I think of as atomic, i.e. I do the task by habit once I
start it. Sometimes those are quick (Take out the garbage = 5 min.) and
sometimes long (Do laundry = >2 hours, interspersed with other stuff).

  Perhaps the UI could have a preferences checkbox and some dropdowns:
"[X] Assume tasks take [30] [minutes] to complete." By the act of
setting these, the user would acknowledge that GTG is estimating the
duration. I certainly wouldn't put this in the data model, tho.

-- 
Paul Kishimoto
MASc candidate (2010), Flight Systems & Control Group
University of Toronto Institute for Aerospace Studies (UTIAS)

http://paul.kishimoto.name — +19053029315

Attachment: signature.asc
Description: This is a digitally signed message part