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.
Maybe I’m not understanding properly, but, was it supposed to be controversial?
“Simple” and “complex” at the same time, relative to different things.
I didn’t mind Apple’s removal of flags, because it didn’t affect me that much, and it is a new product that promises it will provide everything needed eventually, in its simplicity. But the “favourite” status is not equivalent in my use, and flagging lost its one key toggle.
By “perfect”, I mean any way with no rough edges. I tried to adopt a different workflow out of all the different approaches shared here, but even those don’t cover all the issues.
I’m not sure how they are going to solve these issues, but I’m sure they are working on those, as they already stated.
Nice! It’s kind of funny, because I based the note clean up script on one of my own that clears all flags. :-) At heart, it’s exactly like your updated script.
Interestingly, though, I was getting occasional invalid index errors when I was trying to assign “eachItem” directly, which is why I went with assigning it to another variable first and then iterating through that. It works fine when I only wanted to check completed or only wanted to check flagged status, but as soon as I put the AND condition in there, not so much.
AppleScript is actually able to set this particular property en masse. Here’s my full script with prompts and notifications:
(*
The following properties are used for script notifications.
*)
property scriptSuiteName : "Curt’s Scripts"
(*
Main entry point.
*)
try
set theResponse to display dialog "Really clear every flag in the OmniFocus database?" buttons {"Clear Flags", "Cancel"} default button "Cancel" cancel button "Cancel" with title "Clear Every Flag?" with icon caution
on error
return
end try
tell application "OmniFocus"
tell front document
set flagged of (every flattened task whose flagged is true) to false
end tell
end tell
my notify("Flags Cleared", "Flags cleared on all items in the database.")
(*
Uses Notification Center to display a notification message.
theTitle – a string giving the notification title
theDescription – a string describing the notification event
*)
on notify(theTitle, theDescription)
display notification theDescription with title scriptSuiteName subtitle theTitle
end notify
Slightly different than yours, in that it clears all the flags. I generally run it at end of day and reflag things in the morning.
Heh, so it just gets better and better. Thanks for the tip!
Seems in this variation the “will autosave” doesn’t even make that much of a performance difference – it seemed to matter more in my original script – made things significantly faster – but here even with every completed task flagged, I’m not noticing any significant different whether disabled or not.
tell application "OmniFocus"
tell default document
set flagged of (every flattened task whose completed is true and flagged is true) to
end tell
end tell
So on a semi-related note, now that I have your attention @curt :) …is there any chance of posted events ever showing up? I know there was some discussion back in 2008 about it, but I guess it was just never high enough on the priority list to make it in. Seems like being able to trigger an “on event” when a task is completed would be the ideal way to solve many of the edge cases like the ones discussed in this thread.
I’m afraid I can’t comment on future product plans.
Speaking just as a user and scripter, it’s a feature I would love to have. As you note, on-event triggers can be really powerful. They’re great in BBEdit!
