gtg-contributors team mailing list archive

[Bertrand Rousseau <bertrand.rousseau@xxxxxxxxx>]

For the record, I'm pasting below the remarks I received from Izidor when
asking him feedback about those mockups sooner.


On Sun, Jul 22, 2012 at 2:13 AM, Izidor Matušov <izidor.matusov@xxxxxxxxx>wrote:

> Hi Bertrand,
>
> Those mockups look amazing! GTG in GNOME 3.x version will be awesome!
>
> What I see in your mockups is a idea for special modes.
>   * Organizer - manage tasks and their start/due dates & assignee
>   * Planning - long term planing, instead of looking in diary look there
> to find out what's going on
>   * WorkView - don't care about tasks, just process them
>

Yes, that's the idea I wanted to try out. But anyway, at first we will
probably only stick to the organizer view only.


> This idea appeals to me. The mockup for workview is simply awesome. What's
> the purpose of the combobox on top of the list? Are there tags to select
> subtask list? (@gtg, @school, @job, etc?)
>

For me the way to use this work view would be the following: you organize
and sort your task in the organizer  view, and once you decided to get
things done, you switch to the work view. There, you pick the specific tag
using the combobox that fits your context (@home, @work, ...) or the
particular tasks you want to work on (@project_mayhem, ...) and then you
process you list of task. Displaying the selected task on the right of the
list provides a sense of electing a task on which you decide to act upon.


> This WorkView mode is really clean and asks to process tasks linearly.
> (That's good thing, because it eliminates all planning and I should be in
> mode for executing) However, the task should be editable right in the
> "preview" pane. You can write down notes while executing a task and get rid
> of Tomboy/vim/gedit :) Editor could be simplified, e.g. no fields for
> start/due date (just brainstorming) or it could be a full editor.
>

My mind isn't clear about the task viewer/editor. I need to tinker on this.
I already have a (unfinished) mockup with a partial task editor.


> Mark as Done / dismiss buttons have a clear purpose - process this task.
> However, I feel that their position is not "right". I don't know why but
> they don't look natural down there. (I have no idea where they should be
> placed)
>

I would be interested if you get clearer ideas on that. Personally I liked
the fact that they are displayed below the task, it shows them as it were
decisions to take about the task. Something which, in my view, reflect the
fact that you should act on this task or decide not to do it.

I'm, of course, open to suggestions.

On the other side, many people fought war on modes in the ancient editors.
> Modes are hard to understand for people. Think about how many people don't
> get the concept of WorkView when they are accidentally in it. We need to be
> really careful about that.
>

Yes, I know, modes are tricky. Most applications (software or others)
should avoid unnecessary modes. However, "work view", as a features and
independantly of those mockups, is *defined* as a mode (a mode in which you
only see actionnable task), so it's pretty much unavoidable here. So what I
wanted to do here is make it clearer that "work view" is a different mode
by showing the user that when you switch to work view, GTG looks and could
therefore also behaves differently.

You put Active/Closed tasks in tag bar. The problem is they can't behave as
> normal tags. You usually select a tag to filter tasks, to get just a subset
> of shown tasks. However, Active tasks look like default "filter" to me
> although they are not selected. It might create inconsistency and lead to a
> hidden mode Active/Closed tasks. I would say we should have a checkbox to
> show closed tasks directly in the treeview or have a special mode for
> reviewing closed tasks. What have I done then and then? (But it feels like
> too many modes...)
>

Navigation in GTG is a tricky issue. We have a 2D space so far: task state
and tags, and we try to put it in a single navigation widget, this leads to
this kind of issue. We might want to have a dedicated discussion on that
aspect because it has important consequences, especially if we'll include
another navigation space in the future like folders (inbox, archives,
etc.), which would be very useful in collaborative environment which
require some kind of dedicated task workflow (received/acknowledged,
processed, done/archived).


> Somebody has criticized us for showing user important information in the
> titlebar already. Titlebar is hidden when the window is maximized => no
> information about shown Tasks.
>

All information are displayed in the UI: the tasks being show (selected
item in the taskbar), the number of them, ... Maybe it could also be
displayed in the navigation bar, but there's not much space left.


> An idea for Quick Add feature: When the user triggers new task action,
> we show a simple line edit, where she can write. After confirming the task
> by <enter>, the new task is added, but the line edit widget stays there
> waiting for another task. If the user presses <tab> or <shift>+<tab>, she
> can switch between indentation levels. With the query format (tags:,
> start:, due:), she can enter all parameters but notes to a task. (Those are
> added later in the convenient editor)
>
> I am not sure how hard/easy would be that to implement, but it would
> preserve Quick Add feature and add ability to enter structured tasks
> quickly. (and make GTG perfect tool for brainstorming)
>

Ok. The question is: should it be included in GTG or be a separate and
desktop-wise accessible widget that you can summon at all time? (like gnome
do or else).


> I can't wait to have GTG ported in GTK3 to start working on the redesign
> of GTG. But first release GTG 0.3 and I have to finish my Collaborative GTG
> GSoC.
>

Me too. Please note that I want to take the evolutionary road anyway: I
think we should integrate the new design by including one element at a time
only, this will be easier and provide more time to get things right.
However, it's also worth (necessary, even) taking a shot at where we want
to go ;-)

-- 
Bertrand Rousseau