On Mon, Jul 23, 2012 at 4:12 AM, Steve Scheel <[email protected]> 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 < > [email protected]> 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 <[email protected] >> > 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 : [email protected] >> Unsubscribe : https://launchpad.net/~gtg-contributors >> More help : https://help.launchpad.net/ListHelp >> >> > -- Bertrand Rousseau
_______________________________________________ Mailing list: https://launchpad.net/~gtg-contributors Post to : [email protected] Unsubscribe : https://launchpad.net/~gtg-contributors More help : https://help.launchpad.net/ListHelp
