gtg-contributors team mailing list archive

[Bertrand Rousseau <bertrand.rousseau@xxxxxxxxx>]

On Mon, Jul 23, 2012 at 4:12 AM, Steve Scheel <nmu.sscheel@xxxxxxxxx> wrote:

> 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.
>

Hi Steve,

They are available in the bzr repo I mentionned in my mail. But I'm afraid
it's not going to be of any use to you: it is such in an early state that
you most probably won't be able to do anything with it... But if I happen
to work on it, I'll let you know!


>
> 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
>>
>>
>


-- 
Bertrand Rousseau