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