Re: [MLO] Multiproject task
Lisa Stroyan
All tasks in a project have to be subtasks. With the goal setting you have a choice of week, month, year. But, you could use contexts for this feature and set up a context for the project and then tasks can have multiple contexts. I use a prefix in front of my contexts so that I can have the meaning different types of information. For example, "@" for traditional contexts, and "!" For projects.
Hi All,is there a way I can assign a task to multiple projects or goals?Thank youD--
You received this message because you are subscribed to the Google Groups "MyLifeOrganized" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mylifeorganiz...@googlegroups.com.
To post to this group, send email to mylifeo...@googlegroups.com.
Visit this group at http://groups.google.com/group/mylifeorganized?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
m...@grantsmiths.org
If you want to have a task that’s aligned with multiple “areas of responsibility” or “strategic objectives” it’s best to use contexts as Lisa has outlined. If there’s some reason that you need to organize your work as projects, and you have a task that aligns with more than one, it won’t be easy as each task can have only one immediate parent. The best I can suggest is to put the task in question into some other folder and then declare explicit dependencies, so that the shared task does not become active until its prerequisites in both project are satisfied, and when the shared task completes subsequent tasks in both projects will be activated.
-Dwight
robisme (Olivier R)
daniel sekera
Lisa Stroyan
DanD
Having a task reside in more than one folder is clearly useful, as distributed project management systems like Wrike show.
In Wrike, the organization is very simple: folders and tasks. A task can be added to as many folders as necessary. Tens of thousands of Wrike users use this feature.
Coming up with specific examples is a bad idea, because examples could be attacked in one way or another. Therefore, I'm going to just reiterate that many users of other systems love this feature, and MLO users have asked for it as well - see http://mlo.uservoice.com/forums/9235-general/suggestions/3916349-create-links-for-a-task-in-multiple-folders
trs...@gmail.com
First case, I have a folder Purchasing, with sub folders for several different stores / types of stores. Some times an item I need could be purchased at more than one store, so I add it to multiple stores. When purchased, I mark it done in that store folder, only later to have to mark it done again in other folders when I come across it shopping in that other store / checking my list in that folder. Yes I know I could put everything in one folder and do it with contexts but this is just simpler. Also, I don't want to mess up my nice, short contexts list with a bunch of different stores. In fact, the whole branch purchasing is greyed out so as not to come up in To-Do List view. Basically, I just look in whatever folder when I am at that particular store, in order to "check my list."
Second case, sometimes tasks can fall under multiple branches. Say the next action in a given task is to research some topic. So I have "research x" as a subtask, or step, in some folder / project. But like purchasing, I have another greyed out folder called Research. I throw all kinds of things in here that I need to read up on, and every night I check the folder, pull out a topic, and read about it on my tablet before bed. Again, I just want to keep these things separate and out of the ToDo list, in a separate folder and not arse up my contexts by creating an @Research context.
Those are just my workflows, but I'm sure other people may have different ones. I hope my examples are not "attacked." lol And the great things about MLO are it's power and flexibility. To the point of being almost overwhelming for new users at first.
Well, I dunno how difficult that would be to implement, but I put my votes in at the uservoice suggestion linked in the post above mine. Maybe if it's not too hard to implement, I might get lucky ahead of some of the more popular suggestions. lol If anyone else agrees with me, please cast your votes over there. I'll include the link again here since this is a mail group and people might not see the previous post (I replied to a post 2 above mine): http://mlo.uservoice.com/forums/9235-general/suggestions/3916349-create-links-for-a-task-in-multiple-folders
TRS-80
Lisa Stroyan, mailto: ...@gmail.com
Dwight Arthur
Hi TRS (are you referencing the Radio Shack computer?)
I hope you don’t think I’m attacking your examples but I’d like to describe what I do with similar (but not quite the same) situation.
Your “Purchasing” situation sounds very familiar. I have a “shopping” folder that is, I think, pretty similar. There are three hardware stores that I go to frequently: a small neighborhood store that I try to patronize to help it stay in business, a gigantic branch of a national chain that has low prices matched by low quality, and a different store that’s in the nearby big city that I use when I’m there. I have a “hardware store” folder that contains three store-specific folders. If I need something that is available at only one of the stores, I put it in the store-specific folder; if it’s likely to be available at multiple stores I put it in the “hardware store” folder. When I arrive at a hardware store I check the store-specific folder and then go up a level to see tasks in the parent folder. It’s a little extra work to check two folders but not enough to bother me. If it were an issue I would create a view that for each store that would show the tasks in the store-specific folder plus the hardware folder. When something gets bought, one click completes the task and it’s gone.
Your Research folder sounds a lot like my +ReadIt context. When I have time Ibring up a ReadIt view that shows stuff with the +ReadIt context, ordered by priority followed by date of last modification, oldest first. Most of the tasks in the +ReadIt context also have one or more additional contexts, such as “@HorizonGrant”. I understand that you want to avoid arseing (arsing?) up your contacts by doing something like this. Sorry, but I don’t follow. Could you give an example of how doing this would cause an issue regarding your contexts? Is there something you want to do that would stop working or that would require extra steps?
Just as an aside, you could create a @research context that would be closed all day and all night but open just around bedtime – might make things easier to manage, or maybe not.
-Dwight
Visit this group at http://groups.google.com/group/mylifeorganized.
To view this discussion on the web visit https://groups.google.com/d/msgid/mylifeorganized/0b59c68d-ddb2-412a-b347-a08ffa467d1d%40googlegroups.com.
TRS-80
Yes it is a reference to the venerable TRS-80, the beloved machine on which I first wrote a program in BASIC in about third grade, and thusly began a life long interest in computers. :)
And no, not felt as attacks at all, I am always open to discussion, if workarounds can be found then more code does not need to be added to the product, and all things being equal, simple is always better (Occam's Razor, etc.). And or/perhaps my own process/method could be changed, sometimes another perspective is good in that regard, these are the purposes of forums. :) I suppose that comment by me was a bit of a good natured jab at the previous gentleman who said specific examples may be attacked. I disagree with that view, and instead find them illustrative, facilitating communication and further discussion...
On to the subject at hand...
In my purchasing case, the 2 different stores would not be in a related category as you describe. I have some folders which are types of stores (i.e., "hardware store") instead of specific stores. Although I think I may implement your idea of sub folders within a category, for some certain store-specific items. Great idea!
But my example would be more like "motor oil" which could be purchased at "auto parts store" or "wal mart" which are two completely disparate types of store. So I think in this case, this functionality may still be distinct and necessary? But welcome to other opinions of course...
And perhaps I need to revisit the idea of a "@ReadIt" or "@Research" context. As that would solve that particular issue rather nicely. In fact, I could continue to use my "Research" folder, and just set the context for the folder to "@Research" which would then automatically assign that context to any tasks added to the folder as subtasks. I wonder how that would shake out wrt rankings and priorities when converting the treed view over to the ToDo view? I guess each research task would then take it's priority from it's parent project folder / branch. Which would be even better actually to what I do now. Therefore I think I will try that. Problem solved perhaps? :)
By "arsing it up" I just meant "adding another context." I just thoroughly went through my MLO recently, and cleaned up a lot of things, including eliminating a lot of unnecessary contexts. But I suppose adding one more back in (particularly if very useful) would not be so bad.
As far as custom views in ToDo, that is also where some of this may fall down. You see, I do most of my bedtime reading on my Android tablet, and unfortunately the Android client is lagging quite far behind the PC (and even iOS) clients, especially wrt custom views.
I would like to take this opportunity to urge Andrey/devs to give a little more love to the Android version! :) I have bought MLO Pro for PC, I have been an MLO Cloud subscriber for a couple years now, and would happily buy the Pro Android client, as well as upgrade to new version 4 for PC, if there was more/better support for custom views in the Android client (hint, hint, wink, wink :) )!
TRS-80
You received this message because you are subscribed to a topic in the Google Groups "MyLifeOrganized" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/mylifeorganized/fuZe8JIvmic/unsubscribe.
To unsubscribe from this group and all its topics, send an email to mylifeorganiz...@googlegroups.com.
To post to this group, send email to mylifeo...@googlegroups.com.
Visit this group at http://groups.google.com/group/mylifeorganized.
To view this discussion on the web visit https://groups.google.com/d/msgid/mylifeorganized/042301cf340c%248c3773d0%24a4a65b70%24%40dwightarthur.us.
Joel Azaria
Hey trsx.
I hope you don't take my reply as an 'attack' as I'm not writing it as one.
However I think you're having a hard time because you are in fact, "doing it wrong"
What I mean is, the genius of a system like MLO is that you NEVER HAVE TO enter something in two places/duplicate. In fact one might argue that it violates the principle of a system like this to do so. In my view of MLO and GTD, contexts ( and context nesting) is/are precisely the key/tool to your problem. BECAUSE they empower a single entry in my outline to automagically show up on the right one or two (or 5, 8, 50!) lists and never ever worry about checking it off in two places.
So I hope you take this in e constructive manner I'm sharing it, but unless you have some very good, determinate reason, I have to suggest you to reexamine your usage of contexts and why you would want look to not use them for this function.
I would add also, I do EXACTLY what you do for shopping and errands (single items, multiple stores/distributors,) with a small multitude of locations, and all via contexts and it works great.
Jm2c.
.
Visit this group at http://groups.google.com/group/mylifeorganized.
To view this discussion on the web visit https://groups.google.com/d/msgid/mylifeorganized/0b59c68d-ddb2-412a-b347-a08ffa467d1d%40googlegroups.com.
Dwight Arthur
As others have mentioned, this kind of thing is well handled through context hierarchies, where you would describe Walmart (a terrible place that keeps its employees in poverty and provides mass murders with weapons) with a context @walmart which includes +AutoParts, +ClothingMen, +ClothingWomen etc.
Then, an active by context view filtered to show @Walmart would show your motor oil which has context +AutoParts, but if you bought the motor oil at @PepBoys which also includes +AutoParts you would click it once and it would be gone from all the stores whose contexts include +AutoParts.
I *do* believe that there is some missing functionality here, which is location inheritance. I would like to create a context !Target which includes all of the contents for the various merchandise categories and then a context for @TargetSpringfield and one for @TargetNewtown with each store-specific context tied to a location. Then, when I walk into the Springfield Target I would like the phone to throw an alarm telling me to get motor oil. Unfortunately, proximity alarms only work for tasks actually coded to the context that has a specified location and does not accommodate inherited contexts.
-Dwight
Mlo betazoid on Android sgn2
Mlo betazoid on Android sgn2
robisme (Olivier R)
Dwight Arthur
I agree that the current context display is hard to follow. But an outline-based display requires hierarchical data.
In mlo you can easily create three contexts, call them A, B and C, where:
A includes B
B includes C
C includes A
You can't show that in an outline.
I have to admit that I cannot imagine a use case where non-hierarchical contexts would be useful. Does anyone care about this? If not, then MLO would be easier to understand if contexts were hierarchical and were displayed in an outline.
-Dwight
Mlo betazoid on Android sgn2