option to keep tasks in a single window instead of popups

[Dave Crossland]

It would be nice to add a 3rd vertical pane to the right hand side of the tags sidebar and workview, for the tasks themselves, and to have them in a reorderable list from which they can be added/detatched. Just like the way that Inkscape docked palettes work, or TiddlyWiki.

[fonji (fonji)]

About the single window instead of popups :
I thought that when you're reading a (sub-)task, clicking on one of its subtask shouldn't open a new window but "redirect" the current one.
Marking a task as done or dismissing it should "go back" or close when there's no previous page.
You could go to the previous and next tasks using browser-like buttons.
You should be able to configure this behavior (new windows mode vs limited windows mode), maybe via the "view" menu.

Maybe think of a browser-like behavior : clic = redirect, maj+clic = new window, options should be displayed in the right-click menu.
And in a second time, implement tabs ;)

[Lionel Dricot (ploum-deactivatedaccount)]

fonji > As I'm a fan of spatial behaviour, I really don't like this idea. For me one window = one task. But there's a lot to discuss there.

[fonji (fonji)]

I completely understand. That's why "default-opening" should be an option.

[Bertrand Rousseau (bertrand-rousseau)]

I also like this spatial paradigm for tasks. I understand the idea of
having a browsing-like or even tabbed UI, but I guess we should first
keep the UI as being spatial and not include too many options about UI
modifications. We certainly want to try different approaches for UI
interaction, but I don't think we will be able to try this any time
soon. Building a consistent UI with the spatial approach is already a
lot of work.

I'd say let's leave this bug as "New" in order to keep the discussion opened.

On Mon, Mar 9, 2009 at 11:50 AM, fonji <email address hidden> wrote:
> I completely understand. That's why "default-opening" should be an
> option.
>
> --
> option to keep tasks in a single window instead of popups
> https://bugs.launchpad.net/bugs/336604
> You received this bug notification because you are a member of Gtg
> developers, which is the registrant for gtg.
>
> Status in Getting Things Gnome!: New
>
> Bug description:
> It would be nice to add a 3rd vertical pane to the right hand side of the tags sidebar and workview, for the tasks themselves, and to have them in a reorderable list from which they can be added/detatched. Just like the way that Inkscape docked palettes work, or TiddlyWiki.
>

--
Bertrand Rousseau
Place communale 1, 1450 Chastre, Belgium
e-mail : <email address hidden>
tel : [phone]

[fonji (fonji)]

Fine for me.

[Duncan Lock (dunc)]

Before I found this bug, I submitted a blueprint for this feature:

https://blueprints.edge.launchpad.net/gtg/+spec/task-detail-pane

and made a mock-up (see blueprint or this comments attachment)

Needless to say, I think it's an excellent idea that would speed up workflow. I fully understand people talking about the 'spatial paradigm' but I don't agree, for several reasons:

1. GTG isn't spatial - at the moment, it doesn't remember where you put any of it's windows, so it's completely non-spatial. Obviously, this could be fixed in the future but for this to work it has to be absolutely 100% - if stuff moves between sessions, restarts and backup/restores then you break the metaphor and you might as well not bother. Making it 90% spatial - so that people rely on that feature - and then have it occasionally 'forget' and things move - that's worse that not doing it at all.

2. The 'spatial paradigm' is supposed to use human beings viso-spatial memory to allow users to remember where they've put things (like files) on a computer in the same way they do in the real world - by giving dimensionless virtual objects faux-physical dimensions. This has been shown to work reasonably well for small numbers of items, but breaks down very rapidly as the number of items rises and quickly becomes inferior to symbolic memory - remembering or finding things by name (or other data) rather than by position. See:

http://portal.acm.org/citation.cfm?doid=5401.5405

and references therein.

I find this to generally be true in my own use of Nautilus - I leave it in Icon View for little jobs and folders with small numbers of files - anything larger than about 15 items and I switch to List View or just use the command line.

Saying that it 'should be spatial' is all very well but you need to think clearly about why you think this - and what concrete benefits it will bring. For files and folders it works to a limited extent by aping real world paper files and folders. How would this apply to gtg tasks and why would doing it spatially be better than doing it symbolically?

[Dave Crossland (davelab6)]

I really like the mockup and would find that more intuitive. Spatial metaphor just doesn't make sense for tasks to me; they are found through text (titles, searching tags) and not their placement.

[Bertrand Rousseau (bertrand-rousseau)]

Well, thank you for your instructive and constructive post here. The
paper you reference seems interesting even tough I could not access
the full version since I don't have a full access account on ACM, only
a web account. I agree with you that spatial paradigm should not be a
reason in itself and should be motivated. I also agree with the fact
that efficiency with spatial organization degrades with an increasing
number of resources.

However, GTG is currently using a symbolic browsing behaviour since
task browsing is possible through a list. In future versions, this
list will even maybe be sorted by using other abstract information,
like tags, specific time period (today, this next, sometimes), etc.
This behaviour is here to stay.

The only spatial resources in GTG would then be the task windows. As
it is sound reasonable for me to suppose that only a few of them will
be displayed simultaneously, implementing a fully spatial paradigm for
them seems right in regard with the problem you mention. If I must
display, say, three task windows simultaneously, the spatial approach
would work and be useful since each of them would then also be
additionally characterized by its position.

Nevertheless, I do understand the desire to have a 1-window approach
as it allows not to loose focus by switching alternatively between a
task window and a list window. And using more windows sometimes does
not ease focusing. However I am not convinced that the 3 vertical
panes view would be the most practical approach since much of the
space is then lost for displaying useless information when you focus
on the content of the task. Not to mention the fact that it requires a
large screen.

Lionel and me already discussed possibilities of including more
task-related information directly in the list of tasks. On the demand
of the user (for instance, when an user selects a task), additional
content could be displayed below its title. First attempts were not
successful, and we decided to postpone this until we find something
consistent and practical. Right now the partially spatial approach for
tasks works reasonably well, so we'll stick to it and make it 100%
spatial.

As such, I'll mark this bug as wontfix, since we don't have time right
now to make experiments on those aspects of the UI. If you, however,
have additional ideas about this, feel free to add other mockups or
even patches to this bug, since it any modifications will pop it back
under our eyes.

On Tue, Mar 10, 2009 at 5:15 PM, Duncan Lock <email address hidden> wrote:
> Before I found this bug, I submitted a blueprint for this feature:
>
> https://blueprints.edge.launchpad.net/gtg/+spec/task-detail-pane
>
> and made a mock-up (see blueprint or this comments attachment)
>
> Needless to say, I think it's an excellent idea that would speed up
> workflow. I fully understand people talking about the 'spatial paradigm'
> but I don't agree, for several reasons:
>
> 1. GTG isn't spatial - at the moment, it doesn't remember where you put
> any of it's windows, so it's completely non-spatial. Obviously, this
> could be fixed in the future but for this to work it has to be
> absolutely 100% - if stuff moves between sessio...

[Lionel Dricot (ploum-deactivatedaccount)]

The problem I see with the mockup is that you cannot open multiple tasks.

Anyway, if I find the time to do it, I might implement the proposed mockup
as an hidden feature (juste like notes) so people can play with it. I
don't commit to that, I'm just thinking about it.

> Well, thank you for your instructive and constructive post here. The
> paper you reference seems interesting even tough I could not access
> the full version since I don't have a full access account on ACM, only
> a web account. I agree with you that spatial paradigm should not be a
> reason in itself and should be motivated. I also agree with the fact
> that efficiency with spatial organization degrades with an increasing
> number of resources.
>
> However, GTG is currently using a symbolic browsing behaviour since
> task browsing is possible through a list. In future versions, this
> list will even maybe be sorted by using other abstract information,
> like tags, specific time period (today, this next, sometimes), etc.
> This behaviour is here to stay.
>
> The only spatial resources in GTG would then be the task windows. As
> it is sound reasonable for me to suppose that only a few of them will
> be displayed simultaneously, implementing a fully spatial paradigm for
> them seems right in regard with the problem you mention. If I must
> display, say, three task windows simultaneously, the spatial approach
> would work and be useful since each of them would then also be
> additionally characterized by its position.
>
> Nevertheless, I do understand the desire to have a 1-window approach
> as it allows not to loose focus by switching alternatively between a
> task window and a list window. And using more windows sometimes does
> not ease focusing. However I am not convinced that the 3 vertical
> panes view would be the most practical approach since much of the
> space is then lost for displaying useless information when you focus
> on the content of the task. Not to mention the fact that it requires a
> large screen.
>
> Lionel and me already discussed possibilities of including more
> task-related information directly in the list of tasks. On the demand
> of the user (for instance, when an user selects a task), additional
> content could be displayed below its title. First attempts were not
> successful, and we decided to postpone this until we find something
> consistent and practical. Right now the partially spatial approach for
> tasks works reasonably well, so we'll stick to it and make it 100%
> spatial.
>
> As such, I'll mark this bug as wontfix, since we don't have time right
> now to make experiments on those aspects of the UI. If you, however,
> have additional ideas about this, feel free to add other mockups or
> even patches to this bug, since it any modifications will pop it back
> under our eyes.
>
> On Tue, Mar 10, 2009 at 5:15 PM, Duncan Lock <email address hidden> wrote:
>> Before I found this bug, I submitted a blueprint for this feature:
>>
>> https://blueprints.edge.launchpad.net/gtg/+spec/task-detail-pane
>>
>> and made a mock-up (see blueprint or this comments attachment)
>>
>> Needless to say, I think it's an excellent idea that would speed up
>> workflow....

[Dave Crossland (davelab6)]

I think email programs with 3 panes allow double clicking entries on the 2nd
pane to pop them up as (spatial) new windows, while single clicking opens
them in the 3rd pane. This is because mostly one is dealing with
projects/emails one at a time. And the 3 panes can be 3 cols as in the
mockup for wide screens (and most new screens on laptops and desktops seems
to have a widescreen ratio) but also split in 2 cols and the rhs col split
into 2 rows. This is the default thunderbird layout I think :) and it is
useful for small screens :)

Regards, Dave

On 11 Mar 2009, 8:35 AM, "Lionel Dricot" <email address hidden> wrote:

The problem I see with the mockup is that you cannot open multiple
tasks.

Anyway, if I find the time to do it, I might implement the proposed mockup
as an hidden feature (juste like notes) so people can play with it. I
don't commit to that, I'm just thinking about it.

> Well, thank you for your instructive and constructive post here. The >
paper you reference seems ...
>> Â

>> http://launchpadlibrarian.net/23724531/gtg_task_detail_pane_mockup.png >>
>> -- >> option to keep...
> You received this bug notification because you are subscribed to gtg.

> -- option to keep tasks in a single window instead of popups
https://bugs.launchpad.net/bugs/336...

[Lionel Dricot (ploum-deactivatedaccount)]

> I think email programs with 3 panes allow double clicking entries on the
> 2nd
> pane to pop them up as (spatial) new windows, while single clicking opens
> them in the 3rd pane. This is because mostly one is dealing with
> projects/emails one at a time. And the 3 panes can be 3 cols as in the
> mockup for wide screens (and most new screens on laptops and desktops
> seems

This is not possible for GTG because it's an editing window (unlike mail
reader which only have read-only windows) and it would mean having two
editing windows opened at the same time for the same task, something we
explicitely want to avoid in GTG.

[Dave Crossland (davelab6)]

2009/3/11 Lionel Dricot <email address hidden>:
>> I think email programs with 3 panes allow double clicking entries on the
>> 2nd
>> pane to pop them up as (spatial) new windows, while single clicking opens
>> them in the 3rd pane. This is because mostly one is dealing with
>> projects/emails one at a time. And the 3 panes can be 3 cols as in the
>> mockup for wide screens (and most new screens on laptops and desktops
>> seems
>
> This is not possible for GTG because it's an editing window (unlike mail
> reader which only have read-only windows) and it would mean having two
> editing windows opened at the same time for the same task, something we
> explicitely want to avoid in GTG.

Sure, so the text in the 3rd pane would be editable. I see no problem
with that :)

[fonji (fonji)]

Well you'll have the same task opened and editable in the third pane and in an optional new window...
Which is confusing.

I agree with Lionel Dricot, you should have at max one editing display per task.

[Dave Crossland (davelab6)]

If they are always synced, I don't see how its confusing many tools have
'duplicate window' features, inkscape and emacs ones I use daily :)

Regards, Dave

On 11 Mar 2009, 10:55 AM, "fonji" <email address hidden> wrote:

Well you'll have the same task opened and editable in the third pane and in
an optional new window...
Which is confusing.

I agree with Lionel Dricot, you should have at max one editing display
per task.

-- option to keep tasks in a single window instead of popups
https://bugs.launchpad.net/bugs/33660...

[Duncan Lock (dunc)]

Yeah, as I said in the original blueprint, double clicking on a task would
just do what it does now - open it in a new window. I think that people can
easily cope with having multiple editing windows open - after all, only one
of them will have focus at any one time and window managers generally make
it pretty clear which one that is. It's generally not a good idea to assume
that your users are dumb - assume that they're smart but very busy. I think
that having single click access to task details in a sidebar would
streamline the workflow for busy people.

I would envisage the task details sidebar being optional, just like the tags
sidebar currently is. That way users could choose whether they wanted to
show it or not. If it wasn't displayed - which could well be the default, if
you like - then things would work exactly as they do now.

This leads two usage scenarios which I'm not sure would overlap much - the
current one: double click, open many windows and the new one: single click,
only one window. I would guess that these scenarios would probably be mostly
exclusive - people would either fall into one or the other pattern. If
that's the case, then mostly people actually won't have multiple editing
windows visible anyway - they'll probably either just use the details
sidebar, or just use the current setup, without much of both going on. Like
you said though - this is probably something that you're only going to find
out by trying it and then (somehow) measuring if you really want to know.
There's a fascinating blog series from the guys who rebuilt the MS Office
2007 UI from the ground up which shows why they made the decisions that they
did. It also covers the amount of instrumentation data that they collected
about how people actually use their software. It's worth a read for it's own
sake but it's a really interesting look into user and data driven UI design:
http://blogs.msdn.com/jensenh/pages/table-of-contents.aspx

Also, yes the mockup I made is kinda wide but as people have mentioned, I
have an (increasingly common) widescreen monitor. It doesn't have to be wide
though - I didn't resize anything much, but it could be made quite a bit
narrower and still be perfectly functional. You could also put the details
pane somewhere else - below the task list for example, if wideness is a
concern.

Cheers,
Dunc

2009/3/11 Dave Crossland <email address hidden>

> If they are always synced, I don't see how its confusing many tools have
> 'duplicate window' features, inkscape and emacs ones I use daily :)
>
> Regards, Dave
>
> On 11 Mar 2009, 10:55 AM, "fonji" <email address hidden> wrote:
>
> Well you'll have the same task opened and editable in the third pane and in
> an optional new window...
> Which is confusing.
>
> I agree with Lionel Dricot, you should have at max one editing display
> per task.
>
> -- option to keep tasks in a single window instead of popups
> https://bugs.launchpad.net/bugs/33660...
>
> --
> option to keep tasks in a single window instead of popups
> https://bugs.launchpad.net/bugs/336604
> You received this bug notification because you are a direct subscriber
> of the bug.
>
>

[kokoshmusun (saribay-adil)]

I strongly desire this feature (as shown in the mock up). I find it very slow to deal with pop-up windows. I strongly hope that it can be made possible as an option, so the user can prefer a pop-up or a pane approach.

[Bryce Harrington (bryce)]

On Sun, Jan 31, 2010 at 09:02:54PM -0000, kokoshmusun wrote:
> I strongly desire this feature (as shown in the mock up). I find it very
> slow to deal with pop-up windows. I strongly hope that it can be made
> possible as an option, so the user can prefer a pop-up or a pane
> approach.

I've been kicking around a thought along these lines, let me air it:

The closed task pane area becomes a 'notebook' widget. By default it is
not displayed, but the user can select from the View menu, preferences,
or plugins to display panes here. The panes are inserted into the
notebook window. If two or more panes are enabled (let's say the
"closed tasks" pane and the "task editor" pane), then tabs are shown
along the bottom of the screen for the user to look through. (If only
one pane is enabled, no tabs are shown and the tab area is hidden - so
it could look pretty much just like it does now.)

In addition to a closed tasks pane, and a task editor window, it could
include panes for metrics/graphs, export plugins could put their
exported text into a text view, and so on.