gtg-contributors team mailing list archive

[Steve Scheel <nmu.sscheel@xxxxxxxxx>]

Hi Bertrand,

I'd love to get a look at your early mockup of the task editor if you don't
mind sending it my way, and I can try to get it to start heading that
direction in terms of the GUI.

I really like the idea of the workview giving a look at the task at a
glance. These mockups look great and just make me look forward to being
able to see the entire program upgraded to GTK3!

On Sun, Jul 22, 2012 at 5:54 PM, Bertrand Rousseau <
bertrand.rousseau@xxxxxxxxx> wrote:

>
> 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
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~gtg-contributors
> Post to     : gtg-contributors@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~gtg-contributors
> More help   : https://help.launchpad.net/ListHelp
>
>