gtg-user team mailing list archive

[Bertrand Rousseau <bertrand.rousseau@xxxxxxxxx>]

On Tue, Nov 24, 2009 at 11:55 AM, Lionel Dricot <ploum@xxxxxxxxx> wrote:

>
> On Tue, 24 Nov 2009 11:26:45 +0100, Bertrand Rousseau
> <bertrand.rousseau@xxxxxxxxx> wrote:
> > I think that we might need some extra thinking about that "Closed task
> > pane"
> > in the future. First, it's not turned on by default, but still we
> largely
> > assume it's there. Shouldn't we do something about it? Who's using the
> > closed task pane? For what? In my view, the closed task pane is mainly a
> > convenience for:
> >
> >  - Viewing what you just closed/dismissed, as a feedback on what your
> >  recent
> > activities were
> >  - Undoing a recent task (I personally never brought back any task that
> was
> > not one of the last three tasks I just closed)
> >
> > Besides that, I agree we can say "Active tasks are filtered by tags, so
> > logically, why isn't the closed task pane?" Right, but what use case
> does
> > this cover? Is it interesting to filter those? In the view of my
> personal
> > use cases, it isn't. I would be interested to know if this behavior
> would
> > actually bring for some of you an easier interaction with GTG, and why.
>
> For my personal usecase, I sometime want to see everything I've done so
> far in a given project (tag for me).
>
>
Interesting, that makes perfect sense.


> It also happens that I want to know the date at which a particular task
> was done. I use tag filtering to make the search easier.
>
>
Here I wonder if some kind of search/querying feature wouldn't help better.

Personally I'm concerned about the fact that the closed task pane is not
really convenient to track down/recover specific tasks. It's tiny (in UI
space), flat, and has a large number of item.

I agree that we should have more discussions about the closed tasks pane.
> For example, I think we should only display the last XXX days in it.
>
>
Yeah, definitely. But then it would become 'Recently closed task', and we
would need a complimentary UI object to perform the previous use case (as
the considered time span might not be large enough)


>
> >
> > In some way, I have the intuition that this closed task pane is a kind
> of
> > mixed-interactions-which-use-is-not-well-defined object, and a
> discussion
> > like this one could maybe clarify its sense, in a user interaction
> > perspective (or UX, since it seems it's the new hypish way of referring
> to
> > this field).
>
> For my usecase, the scope is really clear. It's an object which serves
> different purposes :
>
> 1) undoing recent actions (where "recent" might sometimes be a few weeks)
> 2) feedback to see what I've done (and also to see that I've not done
> anything for days). This is both immediate feedback and mid-term feedback.
> 3) Record of my history.
>
>
> This is, in my mind, well defined. I agree that we might imagine using 3
> different tools for those 3 different purposes but there's nothing wrong,
> by itself, to have one tool fulfilling 3 purposes.
>
>
It's normal that it's clear for you, since all people made up their personal
behavior model about how an object work, most of the times based on how we
think it's working. I do exactly the same. And there is no problem with the
fact that a single tool serves several purposes (I never advocated 1 tool  =
1 purpose). What I'm asking here is: "what purposes would anybody expect the
closed tasks pane to fulfill based on how it presents itself?". That's why
I'm interested in collecting use cases here.

<general consideration>

Since I'm a developer, I know how things I code could/should behave, and I
also made my mind on how I'd like it to work. But my perception of the tool
evolved so that now I have a hard time to step back from my previous
decisions and see it as it presents itself with no previous experience
(hence the interest of getting feedback), and deduce how I expect it to
work/what I could do with that. I'm also no more debating the righteousness
of simply having the need for a closed task pane: my mind says "it's there,
so let's keep it".

I get the intuition that, we now assume that the closed task pane is there,
and thus we should enhance it to serve other purpose/better serve existing
purpose. My point is: this is ok and a perfectly receivable idea, but let's
keep attention on the fact that we might also need sometimes to do some
round table on what the needs are before deciding to evolve an object to
another level of functionality, and re-evaluate the relevancy on some of our
UI object. Because requiring changes means also new use cases/evolving
needs, that may have not been taken into consideration when we first decided
to include a particular UI object. Sometimes it could actually mean that we
wrongly percevied the situation in the first place, and that some other
designs could help better. That's even more important as GTG is very young,
and we're still building experience on the different possible use cases.

Please note that this is a general remark I'm making here, as I'm
particularly sensible on the methodology we apply to design GTG. I'm
perfectly aware that those extended considerations are *far too convoluted*
for the case we treat here: deciding on how the closed task pan should be
filtered by tags or not. It's just that it made sense for me to speak about
that as well (as mail generally only talk about specific problems and not
methodology issues, it's kind of the only time/place I can do this). Please
cope with me.

</general consideration>


> We might think about enabling it by default because the immediate feedback
> would help people to understand the difference between delete/done/dismiss.
> It will also help understand that marking a parent as done also marks the
> children as done.
>
>
I agree, there is some lack of feedback here, definitely.


> >
> >>
> >> 2) Non-workable tags are not displayed when in the workview mode.
> >>
> >> This also could make sense. But, personally, I often want to see a
> >> specific tag (call it "someday") and apply the workview on it. In GTG
> >> 0.1.2, the tasks tagged as "@someday" are not displayed in the workview
> >> of
> >> all tasks but, if you select @someday, you will have a workview applied
> >> to
> >> that specific tag only. I liked that behaviour and I don't know why and
> >> when it was changed.
> >>
> >
> > Don't know either, but I'm pretty sure it wasn't done willingly.
> Although I
> > agree it's nice to get this kind information, I'm a bit confused here,
> > since
> > it means that GTG workview mode would actually be defined differently
> > depending on what tag you selected. (and what is you unselect it? The
> tag
> > disappears from the list? Even more confusing...).
> >
> > A solution (maybe): non-workable tags (btw we should rephrase this)
> could
> > be
> > still displayed as grayed in the tag list when workview is enabled.
> Their
> > tasks would then not appear in the main list by default, but if you
> select
> > them explicitly, you could see them.
>
> Maybe I was not clear but this is exactly what I proposed and what is the
> behaviour of 0.1.2 so I don't really understand your discussion here ;-)
>
>
I thought non-workable tags were not displayed at all. So they were
displayed before? I don't use the workview, so I don't exactly know what
behavior to expect from it.


>
> Lionel
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~gtg-user<https://launchpad.net/%7Egtg-user>
> Post to     : gtg-user@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~gtg-user<https://launchpad.net/%7Egtg-user>
> More help   : https://help.launchpad.net/ListHelp
>



-- 
Bertrand Rousseau