I use flags as toggles to tell me whether an action requires attention or not. The flag can be temporary in that it is on only for a short time. It can be permanent in that it is on a deferred repeating group so that it “pops up” when the defer date is reached.
After the task is complete, I don’t care that a task is flagged or not. Once a task is complete, temporary or permanent has no meaning to me.
I insist, the state of completion and the state of flag to be completely independent of one another. You seem to want to make them co-dependent. In particular, you seem to want that COMPLETE = NOT FLAGGED always. I insist that this demand is unreasonable. Even if only defined by a preference setting, then then default should still be for completion state and flagged state to be independent of one another.
The slippery slope when multiple contexts aka tags are setup is that thereafter, someone will insist that OF must act to have COMPLETED = RED BALL TAG always.
It occurs to me that all of these edge cases would be easily solvable via Applescript if OmniFocus had added support for posted events, but sadly despite some discussions around it back in 2008 in the old forums, it doesn’t appear to have ever actually happened (at least I can’t find anything in the OmniFocus Applescript Dictionary indicating it’s there).
However, maybe that’s the feature we should really be requesting. If an event could fire off every time a task is completed, that would open up OmniFocus to all sorts of additional plug-ins and extensions, one of which could be to also UNflag the task (and another which could be to add a RED BALL tag :) ). I’d much rather see that then adding more preferences to account for edge cases such as @zdlo’s (no offence, but it is an edge case in the sense that in seven years of using OmniFocus, I don’t recall ever seeing any other suggestions for it :) ).
On the contrary, I think they should be independent. One might also need a completed item to have a flag (auto-completion of completed tasks shouldn’t prevent the user from being able to flag completed items). However, some of the flags we assign are only valid as long as the item is not completed.
I see your use case, but still, if you were using a tag instead, it would behave exactly the same; the item would disappear from your active items list once you completed it, and if it was repeated, it would repeat with the flag tag intact.
I would already vote for that, I guess, considering it wouldn’t cause performance issues or other problems, to have the ability to tailor OF to suit our individual needs with scripts.
However, about this case, whether it is an edge case or not, it obviously is not yet optimised to its ultimate elegance. I would expect it to have a different function than simply being another tag. Also, repeating tasks having or not having their flags intact, has been discussed many times before by many users. Sometimes we want them to repeat with their flags intact, sometimes we don’t.
Do you think an Applescript can differentiate between a completed task that was flagged at the time it was completed, and a task that was flagged after it was completed?
My counter would be that, those flags that have no meaning unless the item is not completed have no meaning even when the item is completed. Or, better said (as others here have stated) … out of sight, out of mind. Once the task is done, why continue to care whether its state is flagged or not? Why even bother? Do you go back and diligently count the number of completed tasks that have flags versus those that don’t? Do you make some post-mortem, weekly report based on this information? Does it affect or change how you move forward for the next period in your GTD world? Other than some vague “it is annoying” factor, I still do not have a good objective case on your part to address this critical question. What problem does your proposal solve that is objective not subjective?
It might behave the same. I sincerely and seriously doubt that it would be as easy to turn on and off as the current implementation.
Yes. That would be the real kicker. Fire off an event when a task is marked as complete. It might have to be task specific though. I can think of cases where I would want it to happen and cases where I would not want it to happen, all within the same Project let alone within all of my OF world view.
I would appreciate an option that when the defer date arrives an item would automatically become flagged, much like how Things automatically moves an item to the Today view and marks it as yellow when the scheduled date (the defer date for OF) arrives. Presently I have to manually flag items every morning when the defer dates arrives. Occasionally I miss one and therefore it doesn’t show up on my Today perspective, which requires an item to be flagged.
[quote=“FW2, post:38, topic:20498, full:true”]
I would appreciate an option that when the defer date arrives an item would automatically become flagged…[/quote]
Actually, if you’re manually flagging when the defer date arrives, there’s probably something that could be better optimized in your Today perspective.
Deferred items should normally be excluded from a perspective until the defer time has passed, regardless of whether they’re flagged or not. Assuming of course you’re filtering for available items, as opposed to remaining items in that perspective.
My entire workflow revolves around the use of flags and defer dates, and the only time I ever worry about flagging something manually is during my weekly review, usually when I’m also assigning the defer date. My tasks remain invisible in my “Hotlist” until such time as that defer date (in fact, the defer time) has passed. If I have a really busy day, I sometimes even defer things to a specific time of day, and I very frequently defer regular evening household tasks for after I finish work so that they don’t clutter up my list before I can do anything about them.
Further, in my case, I don’t match flags to defer dates exclusively either. I have a number of secondary contexts that rely on defer dates to control how often things repeat (e.g. household chores) that I don’t want in my Hotlist, as I only work on them when I’m in that particular context.
I can see reasons why you may want to include ALL flagged tasks in a perspective, regardless of their availability, and since you haven’t really explained your workflow I’m not sure if that’s the case. That said, however, automatically flagged tasks when the Defer Date passes would actually take away an important semantic meaning of the flag (or lack of a flag) for many people.
I think there’s an important reason why OmniFocus treats all of these states as separate and distinct – it provides the product with the flexibility to be a toolbox that can be configured in a myriad of different ways to suite different workflows. OmniFocus is more of a productivity environment in that sense, rather than a productivity app. Apps like Things define your workflow, whereas OmniFocus merely enables it.
I can’t see it creating any serious issues, although you’d obviously be restricted to enabling it on the desktop, which might be the weakest point in the link for many users. Not everybody uses OmniFocus for Mac, even primarily, and it might be unclear how events would be handled on the basis of the results of a sync, although I’m sure it could be dealt with.
It’s interesting to see the different viewpoints on things like this. I consider the fact that OmniFocus maintains semantic separation between a lot of properties and doesn’t make assumptions to be its greatest strength, and to me that’s a different form of elegance. While you still have to tailor your workflow to fit into it in some ways, I actually find it a lot less restrictive than most other systems I’ve used.
If it’s based on an event, it should absolutely be possible, since the idea would be to trigger the script at the moment of completion, at which point it would remove the flag. It wouldn’t be triggered otherwise. Similarly, if an event system were put into place, scripts could be triggered for any other set of task changes – including the addition and removal of a flag, and possibly even the passing of a defer date (as @FW2 requested).
Again, the only trick would be how to handle such events for sync operations, since the iOS versions of OmniFocus would not have these capabilities directly. I’d guess that the events would have to fire off based on state changes immediately after a sync occurred (e.g., if a task status changes from incomplete to complete during a sync, treat it as if the user locally clicked the “completed” button on the Mac side). I’m not a developer, so I have no idea what would be involved in doing this, however.
Some people here stated that they need to be able to see the flagged status even after the completion, because it has a use in their workflow,
Sometimes one might need to flag completed items to move them together, or copy them, duplicate them, etc.
Some repeating tasks are wished to be repeated with their flags intact, some are not.
So what I’m saying is, if a flag was an independent on/off state people could use for whatever purpose they want, it would work for everybody.
Of course, if you need to use flagging just like a tag, but with the additional comfort of being able to switch it on and off with a hotkey or a click or a touch, then I would suggest the auto-flagging function to be an option under preferences, as I did before. But I don’t understand why you would insist such function -that solves problems for many and gives extra usability to everyone including yourself- to not exist at all, for the sake of minimalism (because it would annoy you to know there is one more tick box in preferences), while you are practically reducing people’s real workflow problems to ““it is annoying” factor”, and refusing it to become a tag once tagging becomes available, even though that’s how you are using it, and it would not be the minimalistic solution if everyone was using it the way you did.
I agree, in that I don’t think OF should force users to follow a specific workflow over another unless it is obviously a more efficient implementation of GTD with no discussion about it. However, I would still expect each feature to be designed properly.
To me, the downside of OF is not the way it is intended to be, but its rough edges, and they are being smoothed out in time. For some functions, a user who even knows GTD well, tries them first, and then finds out that those functions do not work well with such use, and eventually, they find the one proper way of using those functions, that are not dictated by the app at all, even though there is only one way of using those properly. For this reason, many users, including myself, sometimes find themselves using a workaround instead of using the function the only way it works properly, which then, in return, creates demand from such users to complicate the app even further.
If things were simpler, there would be more ways of using the features. Comparable apps are not simpler; they just force users to use everything in one way, by complicating the app itself, which may or may not work the best for everyone.
The arguments about OF are usually about the restrictions, and contradictions.
For instance… Flags… User starts using flags to pick up items to do that day. Ooops! They keep having their flags! So, repeating items are going to appear again with their flags. Also, that means one cannot use flags to select a bunch of completed items to move or duplicate them, or to send to someone.
When I encounter such problem, I usually try to find a better way of utilising the function, by reading or even asking the forums about my problem. Sometimes I realise there is a more efficient way, so I happily change the way I use it. But when I see that everyone is using it differently without there being any one way of using it without problems, it appears to me as a feature that is still rough, waiting for its perfect shape to be given.
I saw users asking for a way to select items from different panels. I saw users asking for repeating tasks to sometimes not keep their flags. Why are they asking these? Shouldn’t they? Are they using OF wrong? Or is this flag feature something OF is missing that would cover all these?
I think my question would have been better stated … Why do YOU even bother? Why do YOU still want a preference to auto-unflag a completed task, when setting that preference to that state would disturb my workflow?
The answer is, because YOU have a different workflow than me. You want a preference specific to your workflow. I don’t care because it does not change my workflow. I do care if that preference suddenly changes the current default behavior. IOW, I don’t care that we get a preference to auto-unflag a completed task. I do not want that to ever be the default.
But … The flag state is independent of the completion state. You can set one or the other independently of what the other is. You can set one or the other in any order (flag then complete then unflag OR complete then flag OR uncomplete then flag then complete OR …). So, people can use a flag for whatever purpose they want. I might argue from this that, putting a state to auto-unflag a task when it is complete actually NARROWS the purpose of a flag state.
I agree, having a preference that allows the flag state to be tied to the completion state will make your workflow easier. I agree, having such a preference will allow … “it would work for everybody (you and me both)”. I disagree entirely that such a preference state is the same as saying we will then have “… a flag [will be] an independent on/off state”. Indeed, the minute we have a preference setting and someone turns it on (to make auto-unflag on completion true), the flag state becomes dependent on the completion state.
And we have not even asked the silly but rather blunt practical question … What happens when I make a mistake, accidentally mark a flagged task completed, and then mark it active again? Will your preference setting reversibly reset the flag again? Why not? Gosh darn it … why not! Or when? Or how will it “know” better?
Gee, do I see a can of worms coming with what you are proposing!!!
I have this with Applescript. It is an icon in my OF toolbar. OK, it is not on my iPad or iPhone. I don’t care. I recognize the limits and don’t do any such “heavy lifting” on those platforms.
I am not the one who labeled the workflow problems you are having as annoying. You did. I am using your words.
No. I only insist that flags as they currently are implemented in Omnifocus should never be removed as they are currently implemented. I do not care that tags are added in addition to flags. As I clearly noted, a flag and a tag are two different things in practice and in principle. To bounce your words back, if flags as they exist now would completely disappear because someone insists they are completely replaced by tags … “it (Omnifocus) would NOT work for everybody”.
Add tags. Don’t remove the flag as it is. The fact that I would not consider to use a tag as a flag can then remain my choice. The fact that you would want to use a tag as a flag can become your choice. It works for everybody.
Add a preference to auto-unflag on completion. Keep the default as OFF. The fact that I sometimes don’t care about the flag state of a task after completion and sometimes do care can remain as my choice. The fact that you always want a completed task to unflag itself can become your choice. It works for everybody.
I sense a general attitude of you taking things personal, but that would not be welcome, nor it would be answered at all, let alone with the same manner. I will simply continue as if either I made a mistake of sensing you taking things personal now, or you made a mistake thinking that I had done so previously.
I want to be able to use flags as a way of selecting different items to move, duplicate, copy, send to someone, etc, and I have repeating tasks too, some of which I would prefer to repeat with their flags, some of which I wouldn’t.
However, it wouldn’t matter even if I had no such use. I included your way of using it just as well. I updated my solution with every input, including yours, regardless of its relevance in my use case.
There is no YOU or I here, because this is an application used by many people, and anyone here who writes more than what they already asked for themselves, are usually writing to speak their minds, collaborating in possibly coming up with a solution that would work for everyone, in the best possible way.
We are not trying to convince anyone. There is no one to convince. Nobody is in charge here. I don’t think anyone would even want their hopes to be implemented blindly either, because we learn from each other, and changing something might affect us in a bad way later, if not thought out properly.
It is not independent if one cannot utilise it for both completed and active tasks. If a completed task keeps having its flag, then, giving a flag to a completed item would make it get mixed with tasks completed before, that had flags.
No, it wouldn’t. Completed items would still be able to have flags. It would only unflag the items in the moment of completion, not after. So it is not related to the “completion state”, but the action of completing them.
You hit command+z.
Please elaborate. I certainly wouldn’t want any unwanted side effects, but I fail to see the problems you are seeing unless you share them.
I was referring to your earlier explanation regarding why you would find a flag to be easier to use than a tag with the same functions. You said it would still have the benefit of being able to switch it with one action.
No. My words included several different reasons. I am not the one who reduced those to that.
I wasn’t implying a suggestion for flagging to be removed when tagging became available. I was pointing out the contradiction between asking a function not to even be in the preferences as an option for the sake of minimalism, and not showing the same minimalistic approach when it came to merging two similar functions into one to not lose one extra comfort. I had already acknowledged that comfort you didn’t want to lose, and I wasn’t suggesting it to be removed.
I was merely pointing out the fact that tags could be utilised for the same purpose as flags anyway, and therefore flags could then be utilised differently, if wanted, for an additional layer of purpose. This would not change anything for anyone, unless they chose to.
This is exactly what I was proposing. It appears that we already agree. Perhaps, there has been some misunderstanding.
[quote=“zdlo, post:44, topic:20498”]
It is not independent if one cannot utilise it for both completed and active tasks. If a completed task keeps having its flag, then, giving a flag to a completed item would make it get mixed with tasks completed before, that had flags.[/quote]
Okay, I think this one statement has given me an “aha” moment here in terms of how you view flags, and this may explain why several of us are having so much trouble fully understanding your point of view.
So what you’re basically saying is that you see a flag as something that supersedes a completed status, where I guess most use cases I’ve seen discussed for flags see it as quite the other way. I guess that’s (at least partly) what you mean by the flags as a “super state”?
In other words, a flag on a completed task has a different semantic meaning for you than a flag on an uncompleted task? Is that fair to say?
It seems like a more unique workflow model – that doesn’t mean it’s wrong by any stretch of the imagination – but in years of seeing how other people use OmniFocus, I don’t think it’s something I’ve ever really encountered, although of course I’m far from an expert in such matters. Nonetheless, it is an interesting way of looking at things.
For the purpose of simply picking a bunch of items out of all the available ones (I usually keep deferring the tasks that are left uncompleted from the day before, to the next day; a trick I learned from David Sparks), I flag them, and then check each one as I complete.
I also have to unflag each one as I complete them, so I can use flags for other purposes as well.
For instance, flagging can be utilised to select many items out of many different views, perspectives, projects, contexts, to copy and paste them somewhere, to duplicate them, to send them to someone, to move them, etc.
Repeating tasks are also making it a must for me to always unflag any item after completion.
Exactly, and because of the way I use flags, they don’t have to exist at the same time, and if they did, it would be easy to deal with.
Noted. My apology. I will step back to a less personal perspective.
I don’t run in to the problem as you do. I ignore flags on completed items. I can see how you view the problem. My side is, I and others want tasks to keep their flag state independently of whether they are completed or not.
Well, Omnifocus allows us to hide completed items so we don’t need to worry about flagged states being mixed.
Your “but” at the second phrase immediately negates the starting phrase. So, you say first a certain dependency does not exist, then you acknowledge that a different one does. To follow the example, when a completed item is automatically unflagged, absolutely no completed actions can ever have a flag. That is a dependency. In an independent world, flags can exist both on uncompleted or completed tasks.
Command-Z always now will always have to know whether the mistake was or was not flagged before it was marked completed. That is a complexity in the programming code. The side effect can be that code is not always right.
Flags can be turned on and off with a switch. Tags require a different UI input paradigm. They are not just “click in a circle” to turn on or off. The UI for a flag is by nature more complex than that for a flag. A YES/NO or ON/OFF input on a computer UI is far easier to program than an input to allow a text of any arbitrary length.
This shows, flags and tags are not “two similar functions” in practice. They are also not “two similar functions” in principle.
So, merging them is NOT a realistic perspective to take. This is not about minimalism.
An analogy … You can take a bus to work. You can ride a bicycle to work. These perform two similar functions … they get you to work. Let’s merge the bus and bicycle. They should both now ride either on the same interstate or alternatively on the same bike path. No more “separate traffic lanes”. That merges these two “similar functions”. It is the minimalist approach to traffic management.
We agree overall about what could be done. We disagree about the principles and practices behind it. At this point, the end result is that Omnifocus can become a product that we can both agree we can happily use in our own way. Let’s leave things at this.
Thanks for dialog. I apologize again for going a bit too defensive.
[quote=“zdlo, post:46, topic:20498”]
Repeating tasks are also making it a must for me to always unflag any item after completion.[/quote]
Yup, and in fairness I think there’s broader value to having that option, but again the same model doesn’t apply universally – some people may want repeating tasks to always be flagged, so that they come up again when they reach their repeat cycle (Defer Date), while others may prefer a hybrid approach, with some tasks being unflagged and some retaining their flag (which is obviously even harder to implement without adding yet-another-field to control this on a per-task basis, or moving flag states away from the purely binary).
While preferences are always nice, the problem for a developer like OmniFocus is at what point does the Preference panel begin to look like the cockpit of an old 747? Trying to address too many edge cases results in this kind of feature creep which makes the product harder to maintain and harder to figure out. For example, in this conversation alone we’ve already established that for this feature to function ideally there would likely need to be two or three new preference options: One for what happens to completed non-repeating tasks, one for what happens to completed repeating tasks, and then possible whether those conditions can be set on a per-task option. Then there’s the complexity of how projects should be handled in this scenario as well. From a development point of view, it can become a hornet’s nest, especially since this is far from the only different use case out there.
People always like to say, “It’s just an option, leave it off if you don’t want to use it” but the more options you put in the way, the steeper the learning curve as users try to figure out how to accomplish what they want. What was it Antoine de Saint-Exupéry said about perfection being achieved when there is nothing left to take away? :) I think most Mac developers try to follow that philosophy, which is why we don’t see preference panels in Mac apps that look like this: http://www.bulkrenameutility.co.uk/Shots/BRU_Main_Screen.gif
This is why I think a path to a more expandable plug-in approach is infinitely preferable to cluttering the UI with additional options like this. That said, I don’t work for Omni, and I’m not even that much of a developer, so I can’t speak to policies or actual feasibility or anything else beyond looking in as a long-time user from the outside. I do think this is why Omni requests that people send feedback and maintains an internal voting system to determine how popular features are – I have no doubt that if dozens or hundreds of people were looking for this, you’d eventually see it in OmniFocus in some form or another, but there are already issues with OmniFocus that many people appear to have been requesting for years that have yet to be addressed, so I think it’s fair to say that this particular setting is going to be somewhere FAR below that, unless I’ve somehow underestimated the importance of it or interest in it.
Of course, but that wouldn’t work if one tried to use flags to select a bunch of completed and uncompleted items to move/send/etc. Then they would get mixed up with the flags of the completed items from before. This would, of course, only affect someone who wanted to use flags for both of these purposes, but it would bring more function to those who are not using it that way at the moment, and it would not affect them if they chose not to activate it.
No. The idea is to unflag an item only if it is already flagged at the moment of completion. A completed item can be flagged, and it stays there. This might not work for everyone, but this was the suggestion. Otherwise, there would be no point in auto-unflagging completed items, if we were not able to flag completed items for other purposes later.
It should be, otherwise it wouldn’t be possible to implement anyway. I assumed it was. It would work if the application simply added an extra identification mark to the item at the moment of completion, stating whether it was flagged or not at the moment it was completed.
Again, I was not suggesting their merge. I was just pointing out how it would compare to the other minimalistic approach you suggested by not letting an option to exist in preferences:
I was just pointing out that your tolerance for clutter was as low as not letting an extra tick box to appear under preferences, whereas I was even understanding your need to keep having a special tag with a switch.
The function would be the same, even though the workflow would lose one or two steps in practicality. I acknowledged the importance of that practicality, and didn’t suggest the minimalistic approach Apple took when they merged flags with tags in Photos. I was even thinking that Omni could follow Apple’s lead, and merge them to go well with the rest of the Apple platform. I was suggesting that it would keep it alive no matter what, if they gave it an extra function, switchable under preferences. I was warning you that otherwise they might go ahead and kill the flag like Apple did.
I am still trying to figure out what would be the best way of utilising flags for my use, and I was also thinking maybe I could adopt a better way if there was a perfect way of using it that I was missing.
In practice, I guess we all have to see what Omni adds/changes in the next big update, and figure out hopefully a better way of using it, even if it works all fine already.
I have seen them posting about their intentions of implementing a way to select items from different lists, solving the problem of flags with repeating tasks, and also bringing multiple contexts/tags or whatever they end up choosing. These may all change the way we use OF, and maybe there won’t be any need to change anything about flags after the update, or maybe they will also do something about the flags to solve some of these problems. Let’s hope whatever they end up doing, they take care of all our problems and hopes, and make sure they don’t take things away and make it worse for some, without giving them at least a way of using it with the same efficiency.
To me it doesn’t matter if they implement this the way I suggested. What I care about is not even to have it work exactly my way. I can change my ways, I can adapt. I just want to have a perfect workflow. I don’t care how they achieve that. I was just thinking out loud, trying to figure out what could work.
At the moment, it is obvious that they are going to do something about at least some of these problems. I saw them already mentioning that they are working on bringing multiple contexts/flags, solving the problem with repeating tasks with flags, and also bringing a way of selecting items from more than one list. As long as they solve these without reducing the efficiency for anyone, it will be good.
I’m a software designer myself, and I know my suggestion is not ideal either. However, I am not working for Omni, and I am not designing a better GTD from ground up. I’m just trying to either find a better way to use what’s already designed, or come up with a small enough fix that they might implement.
Agreed. Can you see however where your discussion has so many hypotheticals that almost anyone could agree?
Agreed and modification so noted.
We can always make perfect hypothetical case studies where no problems arise. Your question was about problems. That involves reality, not hypotheticals. The “… application simply (in hypothetical space) added …” portion of your statement is far more complex in reality. To hint at the reality, recognize that a simple change as you suggest will very likely require a modification to the entire database of Omnifocus (so that tasks can carry an additional marker about whether they just did or did not have a flag cleared when they were marked as completed). In a nutshell this means, an new database of OF must be created that is no longer backward compatible with the existing code.
Did I say that I see a can of worms here? This is not a hypothetical can of worms; it is a real one.
A flag in OF is a different beast than a flag in Photos IMHO. I might applaud the move by Apple toward simplicity, since the equivalent function of a flag is kept by having a “favorites” on/off toggle. By comparison, I suspect that OmniGroup has a great deal of respect for the flag in OF. I also suspect that OG is not willing to dismiss it because it is so robustly successful in the GTD workflow (vis-a-vis Apple that is willing to implement changes as befits their world view). That said, your “warning” is worth stating.
The “perfect” way does not exist. Within the bounds of the current implementation of OF, a way that is best for you likely does exist. Specific to your workflow, it may involve a different approach to remove flags on completed items, e.g. via an Applescript.
Finally, as a “warning” or “prediction”, I suspect that OG will never add a preference setting to auto-unflag check items. I also suspect that OG will never drop flags when they introduce tags. If not never, at least not in my foreseeable remaining lifetime to use OF.
