Ability to allocate someday items to a project and view them in project/task view
When planning projects there are of course a few actions that need to be filed as "someday / maybe", it would be good create a someday item from the project/task view, and for that item to keep its relationship to the parent project. Then during the weekly review the option of making the someday task active can be taken in context of the overall project status.
Comments are currently closed for this discussion. You can start a new one.
Support Staff 2 Posted by Christiane Magee on 14 Jul, 2010 08:28 PM
Hi Deekod... we were talking about this the other day. I'm putting this up for suggestion.
3 Posted by Proximo on 15 Jul, 2010 05:51 PM
I usually move entire projects or single task to Someday, but I don't really designate a project task as someday if it belongs to the Project.
If the task is part of the Project, that means the project can't be finished without this task being completed.
Someday task are things that would be nice to do one day but are not actionable. If it's not actionable, it should not belong as part of a Project, unless the Project itself is a Someday project.
Maybe it's just me but it's not clear to me why I would put a Project task in the Someday list. If it's required by the Project, it must be actionable.
4 Posted by Lasares on 16 Jul, 2010 12:27 PM
@Proximo : at first, I was thinking exactly like you on this matter but Deekod had me rethink the matter. Using your example from another thread, say
I have this project :
1. Clean car
- Buy bucket
- Buy Sponge
- Buy washing materials
- Pick up garden hose from brothers house
- wash the car
Wouldn't it make sense to add a task like "polish car" as a Someday task to
this project, if i think I may or may not do it while I am at it ?
5 Posted by Proximo on 16 Jul, 2010 01:19 PM
@Lasares,
Actually.... No
Why would I ever have a Project I could not finish but yet, I completed all the Actionable items that is required.
I would make a new Project or Actionable Task called "Polish Car" and make it a Someday/Maybe because it's something I would like to do, but not sure if I would get to it and if I did not get to it, it's not a big deal.
I have to decide what "Doing" looks like and if I wanted to accomplish a Project, I would need to clearly identify what it would take to get it done. Having a Someday task associated with it would not be necessary for THIS Project to be completed but by having the Someday task in the Project, I could not close it out once all Actionable task where complete.
Now I have a Project that has all actionable task completed but I still can't close it out because I associated a Someday task to it that I may never get too. Why would I force this Project to stay open for a Someday task.
Maybe it's just me, but I would either make the Someday task it's own Actionable Task or a new Project if it has more than one step. I would complete the Project of washing the car and close it out and during my weekly reviews, if I feel I am truly ready to Polish the car, I would move the Someday Task/Project into an Actionable list such as Next or Projects.
6 Posted by martin.tyler on 16 Jul, 2010 01:35 PM
This kind of issue is where nested projects can help... in GTD Proximo is right, the 'optional' task is really not part of that project since a project as a well defined outcome. However, it's related so creating another project in a flat list of projects can result in a long unorganised list of projects
7 Posted by Proximo on 16 Jul, 2010 01:39 PM
I think nested projects would be a nice feature.
Even with a nested project, I would not add any Non-Actionable task to it because it has the same issue as the parent project. I could never finish a nested Project that had a Someday task and therefore the parent Project would not be complete either.
I am no rocket surgeon but I simply think the idea of having Someday task associated with an Active Project or Sub-Project is not a good thing.
8 Posted by martin.tyler on 16 Jul, 2010 01:46 PM
I was thinking more along the lines of having a 'Car' project folder, with two projects in it.. one active and one in someday
I think with nested projects, most people would use the parent folders as project categories or long lived ongoing projects.. so it allows the actual projects to be well defined and finishable
9 Posted by Proximo on 16 Jul, 2010 02:05 PM
Never thought about it that way.
I guess it could be used in different ways.
I prefer to simply have sub-projects that live inside a parent project. This way I can just focus on completing all actionable task and close out the project.
But you could also do what you describe which would probably work just fine. I guess it's a matter of user preference and habits. :-)
10 Posted by martin.tyler on 16 Jul, 2010 02:09 PM
Also depends on what kind of things your projects are probably - and it's hard to say how you will actually use it until we get the feature :)
Support Staff 11 Posted by Elbert McLaughlin on 16 Jul, 2010 02:18 PM
Ha! Re: post (4), This is what I was trying to get at when I asked "what's with non-actionable tasks in projects" in the ux thread (and got smacked down! thankyouverymuch). I should have been more clear vis-a-vis someday vs sequential at the time. Anyhoo, glad we're having the discussion over here.
We're leaning towards allowing someday/maybe tasks in projects. (don't use 'em if you don't like 'em). I'd wager that about 90% of my projects have tasks that I would classify as "would be nice to accomplish but not critical to deem project as completed" ... and while I might create a separate (sub?) project for these items, that would mean instantly doubling the number of projects into Project Name X and Project Name X Someday. Not very manageable from a software UI angle, imho.
Re: post (8) - yes yes yes yes yes... please tell me that this will solve most people's problems! It's a bit self serving in that containers (folders) for grouping multiple projects is waaaay easier to implement than nested projects (which would have due date, tag inheritance, other cascading meta-data headaches).
I already fake this by pre-fixing projects with a common word to denote that several projects are part of a larger objective.
12 Posted by martin.tyler on 16 Jul, 2010 02:29 PM
@Elbert - could you describe the difference you see between folders and nested projects?
They could both mean the same thing - but I am assuming you mean the following..
Folders - clicking on a folder would simply show the projects within that folder, as a list of project names - as you get when you click on the root node 'Projects' as it is now
Nested - clicking on a parent node would show you all the tasks in all the projects below - (recursively if you have multiple levels) - in a view a bit like the current next list (with project tasks turned on)
If that is how you see it, then 'folders' is useful and a good first step - but 'nested' is still what i am after. Its like being able to focus at whatever level you want.
Support Staff 13 Posted by Elbert McLaughlin on 16 Jul, 2010 02:45 PM
@martin.tyler - Yeah, I'm trying to cheat. :-) Think iTunes and playlists... you can have an infinite number of playlists, and you can create folders to group your playlists, but you can't have playlists within playlists. Still, it's a nice option to at least be able to collapse several playlists under one heading.
OK, the analogy breaks down in that with a playlist you can have a Track show up in multiple playlists (which is not what we want) but you get the idea. Perhaps Outlook folders is a better example...
Support Staff 14 Posted by Elbert McLaughlin on 16 Jul, 2010 02:52 PM
it would be easy to implement folders such that clicking on the folder in the left nav would show all of the projects and tasks inside, grouped by project in the main window area. Perhaps being able to drag tasks between the projects (up/down) would be feasible too.
The thing i'm loathe to tackle is having a master due date on the "folder" or having nested folders. It's doable, just a real pita to implement -- and perhaps a distraction from other pressing Nirvana concerns...
15 Posted by Lasares on 16 Jul, 2010 03:11 PM
@Proximo : I tought that would be your way to handle the "maybe polish car" question. This is more in accordance with pure GTD, I guess, and also just plain rigourous thinking, I'd say.
However, I am not always as rigourous as I could (should?) be and I like to be able to allow for my sloppiness... and still get a system that works. This is why (if I was given the ability) I would put the "polish the car" task in the project and (maybe) tag it with Someday. Then, on the weekly review, when I see that all other tasks (all really actionable tasks) are completed, except this one, I would have to make a decision : either 1. I keep the project alive and then make "polish car" a Next action, or 2. I delete the task and close the project, or 3. I get "polish the car" out of the project and leave it as a Someday task and close the project.
I am not saying this is the best way. I am just saying in some (usually much larger projects) that could be pretty useful. But then, just being able to view ONLY actionnable tasks in Next (especially with a Projects grouping option) could be a perfectly acceptable substitute.
16 Posted by Proximo on 16 Jul, 2010 09:53 PM
Let me back up here.
The important thing is for you to do what works best for you. I believe user preferences for things like this is perfectly fine. Just keep it clean and simple.
Many times I share the way I do things but this may not be the best way for you to do it. What is best for you, only you would know. I still tweak some of my habits when I find I could be doing it better or if I don't get the results I wanted.
As for nested project vs. folders.
I have no problems with the folders concept. You could create a Project folder that has two or more projects related to it. This should be simple enough to understand and work with.
However, I have some projects that require a smaller project to be completed to move it forward. This sub-project is sequential and must be completed before other actionable task below it. I am not sure how I would do this with folders only. I don't want to have a task in a Project that says, look at "x" project in parent folder to move forward.
This falls back to the idea of sequential and parallel activities. The folder concept makes perfect sense for parallel projects, but what about sequential?
17 Posted by convexcube on 17 Jul, 2010 12:33 AM
I would suggest that instead of folders specifically for projects, there could be a contexts category in the left navi (collapsable with a disclosure triangle). This would also address later discussions in this other thread regarding contexts & tags: http://help.nirvanahq.com/discussions/questions/156-adding-tags-to-...
To use the example in this thread, The 'Clean car' project would be assigned (drag & drop) to this context, as well a the task 'polish car' that is located in someday providing a single list for the 'car' context (resource). Of course tags could still be applied to filter down further.
This would lead to a more flexible approach that encompasses both projects and tasks while leaving them in their actionable/Inactionable state, and gives scope for people to use it to organise projects and create sub-area like functionality.
18 Posted by martin.tyler on 17 Jul, 2010 07:16 AM
@Proximo
You have hit on another aspect there, sub projects..
Folders (including clicking on a parent and getting a recursive view of all tasks) are really for organisation and focus.
..but if you have dependencies like you mention, i see that as a sub project, and best visualised as an indented set of tasks inside the main project
19 Posted by Lasse on 09 Aug, 2010 11:52 PM
@Elbert
I would be perfectly happy with just folders. I used Bonsai on my palm for a few years and got tired of all these indented lists. I get that they can be really helpful but I think folders would be a great start.
20 Posted by afunix on 10 Aug, 2010 11:19 AM
I don't know if it will be useful to move subtasks to "someday", but it's really annoing that I cannot move subtask to "next" folder!
David McLaughlin closed this discussion on 04 Feb, 2011 01:10 PM.