Hi Dwight So to get clear "AS=" stands for "Action Status=", with possible values of. A - Active W - Waiting S - Someday L - Later
> E. I believe that when you say "tag" you are talking about the > field known to MLO as "context", is that correct? Yes. Great minds... :) Re F. - use of Flags, and inheritance, I agree that there exceptions and that sometimes when creating a new action within a project you MAY want a different Action Status, but I see that as being very rare. In those cases it is important that there should be a way of doing this correction. On the face of it Flags would seem to be the best workaround... but in practice I found it EXTREMELY irritating to have to keep setting flags for every single new item. I agree your cleanup would work in principle, but I don't quite have the patience as I would want things to be ready to go/in the correct place almost immediately I enter them. I can see that adding new User Defined Fields would be take a certain amount of work for MLO developers. So I am now wondering if we could request a new setting in MLO's Options to make Flags inherit from either the parent task (or the currently selected task)? Interestingly enough, the application ToDoList gives you a tick list showing the *full list of task fields* so that the user can choose which fields do and which do not inherit their values from the parent task. Maybe we could suggest that instead / as well?? Any takers? (or should I start another thread for this?) J On 7 September 2016 at 14:49, Dwight Arthur <m...@dwightarthur.us> wrote: > Hi, John. > > A. Fire=>Field. Yes, Cupertino effect. > > B. AS=The typo, AS values for you would be A, W, S, L. Or anything else > you chose. > > C. When thinking about this I had identified a disadvantage identified as > "can't edit with multiselect" but I forgot to include it in the writeup. > It turns out to be the one that can't be tolerated. > > D. I agree with you that Folders provides a good implementation of Area of > Life, so in subsequent discussions I'd like to focus on Action List Status. > > E. I believe that when you say "tag" you are talking about the field known > to MLO as "context", is that correct? If so, I totally agree with your > assessment of the disadvantages of using this field for Action. > > F. I believe that Flags would be the closest fit for Action, because you > can use hotkeys, they work with multiselect, and they work like radio > buttons in that setting a value clears any previous value. The difficulties > that you describe all seem to fall under inheritance. The thing about > inheritance is that sometimes one wants it and sometimes one doesn't. For > example, if you change a project from Someday to Active but some branches > of the project are Later and a few tasks are Waiting, you would have to > defeat the inheritance. > > Workaround: create tasks without paying attention to Action List Status. > Create a view called Action List Status Cleanup showing non-folder > uncompleted items that have no flag, sorted by modified date/time, most > recent first. Find a clump of tasks that all need the same Action, > multiselect them (Windows, select first item, then shift's elect last item > and set the appropriate flag) > > I'd like to reaffirm that I would support creation of User Defined Fields, > but that a full implementation including numeric and date fields and > changes to sorting, grouping, advanced filters and, as Pottster mentioned, > database and sync changes, adds up to a long and expensive development > effort. > > On September 7, 2016 5:35:57 AM "John . Smith" <ship...@gmail.com> wrote: > >> Hi Dwight >> >> > code a statement in the Notes fire >> I take it you mean Notes field, yes? :) >> >> In which case this is sounds remarkably ingenious and I confess that I've >> not yet tried that particular workaround. >> >> I think I get the principle which is to burn usual text strings into the >> Notes field that one can then use to filter on in dedicated views, using >> Advanced filtering, yes? >> >> For completeness okay I get that >> "AL=P" would mean "AreaOfLife=Personal" >> But please can you explain what these strings would mean in your example: >> "AS=A" >> "AS=T" >> "AS=S" >> >> To recap the main task data fields I want to create (or simulate) would >> be *Area of Life* and "*actionable status*" (with GTD-like list values >> like: Active, Waiting, Someday-Maybe, Later ) >> >> But wait I have problems with your approach. >> >> What do I do when I want to move an entire project (consisting of say 10 >> or 20 tasks, and maybe even 2 or 3 sub-projects) from actionable status of >> "Active" to "Someday-Maybe" and then on to "Later". >> >> Problems: >> >> 1. MLO does not let you edit multiple Notes fields at once. (life is too >> short to manually edit each of 20 tasks in a project - nightmare!) >> >> 2. And even if MLO could, I may want to use some Notes fields to actually >> store notes (!) and i would not want them to be over-written. (Out of >> desperation I could live with it but definitely not idea.) >> >> 3. When quickly adding a task to a project, I don't really want to have >> to add all your manual tagging(s?), it should really default in, by >> inheriting its value either its parent task from the task currently >> immediately above it in the current view (both methods would work OK) >> >> >> The two obvious workarounds that I tried for controlling Area of Life and >> "actionable status" were >> A) Folders and B) Tags, both of which can be made to in effect "inherit". >> >> A task's "Area of Life" is unlikely to change, and I can certainly live >> with just one Area of Life per project/task. >> >> As suggested by other users Folders did work quite well for Area of life. >> >> The difficulty was then how do I move projects/tasks between "actionable >> status" values? >> I didn't want to further clutter up my Tags which I was already using for >> Context as well as some other aspects, so I tried putting them into sub >> folders as well (i.e. within Area of Life folders). Given the large number >> of tasks that I have (400+) this proved to be a nightmare with lots of >> clicks and scrolling required just to move between values of say "Active" >> and "Someday". Worse because I use position as some sort of informal >> relative priority between the different stuff, when physically moving stuff >> between folders, the original position is inevitably lost. >> >> Then I tried using Flags for actionable status. At least they can have >> hotkeys. But when adding a few tasks into say "Someday", it was a real pain >> to have to remember to flag each new task with the "Someday" flag. [ASIDE: >> If flags could be set to inherit life would be easier.] >> Also it was a slight pain when wanting to change status of an entire >> project to remember to manually select the entire project and all it's >> tasks before changing it's status flag. >> >> Then I tried using Tags for actionable status. At least they can be set >> to inherit and they have hotkeys. But I found the cluttering up of with my >> 'genuine' tags to be quite irritating. For one thing the tags appear to >> care which order they are edited in. And so the more tags you have per task >> (and I might have say 2 or 3 real tags & contexts) the more messy it gets >> in the view column as the action status could be in any one of 3 or 4 >> positions, and this means that it's pretty hard to see what it is that you >> are looking at! >> [ASIDE: If tags could be made to show up in alphabetic short order life >> would be easier.] >> >> >> All in all it's pretty clear that what is needed is a field for each of >> Area of Life and actionable status, and they need to default in some >> sensible way. But for anyone with a large number of tasks, none of the >> workarounds I have yet come across are viable. >> >> J >> >> >> >> >> On Wednesday, September 7, 2016 at 1:16:28 AM UTC+1, Dwight Arthur wrote: >>> >>> Hi, John. I would like to see User Defined Fields (UDF) in MLO. In fact, >>> I would like it so much (if it were done correctly<see footnote 1>) that it >>> would probably rise to about number seven on my wishlist. >>> -Dwight >>> >>> *Footnote 1: doing it correctly.* I would not use what you described, >>> as it's within the range of what I can do with workarounds. <see foornote >>> 2>. In order to be worthwhile to me four more things would be needed: >>> (a) in addition to plain text and select from user-defined list, I would >>> want numeric value, and date/time as available data types. >>> (b) I would want to know that creation an a new UDF, changes to the >>> content of a UDF, and changes to the definition/validation of a UDF would >>> be propagated to all platforms via sync >>> (c) I would want to be able to test any UDF in an advanced filtter, with >>> the available tests appropriate to the declared datatype of the UDF >>> (d) I would want to be able to use any UDF as a paraneter for sorting >>> and grouping. >>> >>> *Footnote 2: workaround. *John, with the large number of workarounds >>> you have tested, it's probable that you have already tested the one I would >>> use. I wonder, could you point me to a thread where you have described >>> "horrible" consequences? It would be to code a statement in the Notes fire, >>> for example AreaOfLife=Personal (or to reduce typing, AL=P). You could then >>> build custom views showing active personal tasks "((Notes contains AL=P) >>> and (AS=A))" and you could easily activate someday tasks by overtypoing >>> AS=S with AS=T. There are multiple drawbacks of this approach versus a UDF >>> feature, including >>> (a) Have to remember the coding >>> (b) Responsible to catch and correct own typos >>> (c) A dedicated field would be a little easier/faster to edit >>> (d) these fields unavailable for sorting/grouping >>> (e) numeric (greater than, less than) and date (two weeks before now) >>> filters wont work >>> In my view none of these drawbacks deserves the term "horrible". >>> -Dwight >>> >>> >>> >>> -- >> 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 mylifeorganized+unsubscr...@googlegroups.com. >> To post to this group, send email to mylifeorganized@googlegroups.com. >> Visit this group at https://groups.google.com/group/mylifeorganized. >> To view this discussion on the web visit https://groups.google.com/d/ >> msgid/mylifeorganized/f12b5875-91f9-4c3a-8065- >> 8eddd9c3aec9%40googlegroups.com >> <https://groups.google.com/d/msgid/mylifeorganized/f12b5875-91f9-4c3a-8065-8eddd9c3aec9%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > -- > 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/aHvLaU7lGuE/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > mylifeorganized+unsubscr...@googlegroups.com. > To post to this group, send email to mylifeorganized@googlegroups.com. > Visit this group at https://groups.google.com/group/mylifeorganized. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/mylifeorganized/15704e94d08.2828.e3899142e96de3f9352600768bcafa > f9%40dwightarthur.us > <https://groups.google.com/d/msgid/mylifeorganized/15704e94d08.2828.e3899142e96de3f9352600768bcafaf9%40dwightarthur.us?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- 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 mylifeorganized+unsubscr...@googlegroups.com. To post to this group, send email to mylifeorganized@googlegroups.com. Visit this group at https://groups.google.com/group/mylifeorganized. To view this discussion on the web visit https://groups.google.com/d/msgid/mylifeorganized/CA%2BrSdyqthqx8usa8d9A8xNmccZCciWW%2BdkKHLnna3%3D%2BDQy94vg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
