#1389
- Created on2013-01-22 21:49
- Reported by
- StatusMigrated
- PriorityNormal (3)
- Assigned to-
- Milestone
- Plan Level-
- Due Date-
Deleting a context should not delete all associated actions
Steps to reproduce:
The names do not matter here. Just using them to make it easier to cross-reference things.
Actual result:
Action NewAction is deleted. This is incredibly frustrating. I have been adjusting my contexts lately, and I have lost dozens of actions due to this behavior. I realize that there is a dialog warning about this, but dialogs are almost always ignored (see habituation) and, regardless, I cannot imagine the value of this feature possibly overcoming the damage it can cause.
In Getting Things Done, contexts and actions exist independently. Contexts do not contain actions, they group actions. Deleting actions because I deleted the context is like throwing away my clothes because I wanted to throw out the suitcase.
Expected result:
Most importantly, NewAction should not be deleted under any circumstance other than manual deletion.
What specifically should happen to NewAction is a harder question. My vote is for updating NewAction to have some kind of default context, like "uncategorized". But there are many other approaches that could work here, as long as NewAction is not deleted.
The names do not matter here. Just using them to make it easier to cross-reference things.
- Create a new context called NewContext
- Create a new project called NewProject
- Create an action in that project called NewAction
- Delete the context NewContext
Actual result:
Action NewAction is deleted. This is incredibly frustrating. I have been adjusting my contexts lately, and I have lost dozens of actions due to this behavior. I realize that there is a dialog warning about this, but dialogs are almost always ignored (see habituation) and, regardless, I cannot imagine the value of this feature possibly overcoming the damage it can cause.
In Getting Things Done, contexts and actions exist independently. Contexts do not contain actions, they group actions. Deleting actions because I deleted the context is like throwing away my clothes because I wanted to throw out the suitcase.
Expected result:
Most importantly, NewAction should not be deleted under any circumstance other than manual deletion.
What specifically should happen to NewAction is a harder question. My vote is for updating NewAction to have some kind of default context, like "uncategorized". But there are many other approaches that could work here, as long as NewAction is not deleted.
Leave a comment
I appreciate you taking the time to report the change you would like to see made. Clearly, this has caused you some difficulty. While this seems simple and straight forward from the outside, it would be a fairly big change. While would agree that life is too full of pop up boxes, i can assure you that the few in tracks are general important and should not be ignored. You won't get much sympathy from the devs when you are ignoring there efforts to keep you from doing things you might regret :)
Top do this, You'd have to write a process to change all the existing actions into this default context. Also, you'd need to write a means to set the default context in the preferences as well. Some might push back on the change not being GTD compliant. The idea is supposed to be that projects come and go but contexts are pretty stable. Personally, I have had the same 7 or so contexts for a couple years now.
While I am not saying that this can't or won't happen, if it does it will be some time. In the meantime, try using tags or projects to organize things in these dynamic terms. They may be better suited for the job.
Top do this, You'd have to write a process to change all the existing actions into this default context. Also, you'd need to write a means to set the default context in the preferences as well. Some might push back on the change not being GTD compliant. The idea is supposed to be that projects come and go but contexts are pretty stable. Personally, I have had the same 7 or so contexts for a couple years now.
While I am not saying that this can't or won't happen, if it does it will be some time. In the meantime, try using tags or projects to organize things in these dynamic terms. They may be better suited for the job.
on 2013-01-27 17:23 *
By exeightysa
"You won't get much sympathy from the devs when you are ignoring there efforts to keep you from doing things you might regret :)"
I am not ignoring the warning. The human mind is ignoring the warning. With all due respect, if you do not understand this you do not understand usability.
A former Mozilla software developer wrote a wonderful introduction to software usability that touches on this.
"An action taken based on a reasonable assumption or out of habit often results in broken trains of thought, wasted time, and lost work. This is called 'user error', but it isn’t. It is programmer or designer error. When a user makes a mistake, don’t blame the user. Ask how the software misled them. Then fix it."
In fact, the former creative lead of Firefox wrote an articled called Never Use a Warning When you Mean Undo to address this topic in particular. Please read it before you decide not to change the behavior here.
I am not ignoring the warning. The human mind is ignoring the warning. With all due respect, if you do not understand this you do not understand usability.
A former Mozilla software developer wrote a wonderful introduction to software usability that touches on this.
"An action taken based on a reasonable assumption or out of habit often results in broken trains of thought, wasted time, and lost work. This is called 'user error', but it isn’t. It is programmer or designer error. When a user makes a mistake, don’t blame the user. Ask how the software misled them. Then fix it."
In fact, the former creative lead of Firefox wrote an articled called Never Use a Warning When you Mean Undo to address this topic in particular. Please read it before you decide not to change the behavior here.
on 2013-01-27 17:41 *
By zoombody
Priority changed from High (2) to Normal (3)
Status changed from Invalid to New
Priority changed from High (2) to Normal (3)
Status changed from Invalid to New
@maddentim and @lrbalt, I disagree and I'm reopening this ticket because I think it's worthy of discussion. The fact that confirmation dialogs don't work well is quite firmly established; it's something you hit the first week of an intro course in UX design. Good UIs make destructive actions either very hard to complete or very easy to undo, and currently this is neither.
One option would be to not allow contexts containing actions to be deleted. The user would have to manually delete the actions before deleting the context. (This could also be limited to only incomplete actions.)
Another option is, as @exeightysa proposed, to revert the actions to a default context. I'm not a big fan of this idea because a "default context" doesn't map to any real world concept.
A third option is to revert the actions to having no context. (This would actually be generally useful to have, because it would permit actions to be brain-dumped into Tracks without first having to decide on the appropriate context for each one.)
One option would be to not allow contexts containing actions to be deleted. The user would have to manually delete the actions before deleting the context. (This could also be limited to only incomplete actions.)
Another option is, as @exeightysa proposed, to revert the actions to a default context. I'm not a big fan of this idea because a "default context" doesn't map to any real world concept.
A third option is to revert the actions to having no context. (This would actually be generally useful to have, because it would permit actions to be brain-dumped into Tracks without first having to decide on the appropriate context for each one.)
on 2013-01-27 18:51 *
By exeightysa
Thanks for sharing your thoughts, Dan.
You make a good point that a default context would not make much sense. Another option (not sure what you feel about this) is to provide a really convenient undo feature, like Gmail does. Not sure it would fit with the rest of the app, though.
You make a good point that a default context would not make much sense. Another option (not sure what you feel about this) is to provide a really convenient undo feature, like Gmail does. Not sure it would fit with the rest of the app, though.
ok, if we introduce an inbox concept, we could move the active todos to the inbox and delete the completed actions.
I'd prefer btw to introduce a "closed" state (or something like that) so you can close a context without deleting it. This way the stats are preserved and you are able to reopen a context in the future.
I'd prefer btw to introduce a "closed" state (or something like that) so you can close a context without deleting it. This way the stats are preserved and you are able to reopen a context in the future.
@exeightysa Excuse me? The human mind ignored it? Way to take responsibility for your actions.
I am not against different solution from the current design. I agree that it is a bit draconian to just delete them, but I don't believe that have next actions without a context is in keeping the GTD principles.
What is the typical use case for regular deletion of contexts? I am serious. I think it is helpful to define what we expect people to do in the app and design around those cases. For me my only use case for deleting a context is I made it by accident and I want to delete it. There is typically only one todo associated with that errant context.
What other use cases do people see that we want to support?
I think "closed" is a good idea. A simple solution might be just to state that the context can't be deleted until all active todos in context are moved or completed?
I am not against different solution from the current design. I agree that it is a bit draconian to just delete them, but I don't believe that have next actions without a context is in keeping the GTD principles.
What is the typical use case for regular deletion of contexts? I am serious. I think it is helpful to define what we expect people to do in the app and design around those cases. For me my only use case for deleting a context is I made it by accident and I want to delete it. There is typically only one todo associated with that errant context.
What other use cases do people see that we want to support?
I think "closed" is a good idea. A simple solution might be just to state that the context can't be deleted until all active todos in context are moved or completed?
on 2013-01-28 14:25 *
By exeightysa
"@exeightysa Excuse me? The human mind ignored it? Way to take responsibility for your actions."
You are making yourself look silly. If you read even one book about software usability you would realize how oblivious you sound.
You are making yourself look silly. If you read even one book about software usability you would realize how oblivious you sound.
Please keep it civil, guys.
@lrbalt you are referencing #645 and I think that's a good idea. Keep in mind, however, that if "close context" is a completely separate function from "delete context" then it won't really address this issue. Any new "close context" function will need to be implemented in such a way that it takes the place of "delete context" (or precedes it).
FYI here's how OmniFocus addresses this (quoted from the manual):
"If there’s a context you don’t intend to use anymore, such as the office for a job you left, or a person who transferred to a different department, you can drop it. All of your old actions that were assigned to it stay assigned to it, but the context doesn’t appear in your Remaining contexts sidebar. Any remaining actions still assigned to a dropped context become unavailable and move to the No Context group of the context mode sidebar."
@lrbalt you are referencing #645 and I think that's a good idea. Keep in mind, however, that if "close context" is a completely separate function from "delete context" then it won't really address this issue. Any new "close context" function will need to be implemented in such a way that it takes the place of "delete context" (or precedes it).
FYI here's how OmniFocus addresses this (quoted from the manual):
"If there’s a context you don’t intend to use anymore, such as the office for a job you left, or a person who transferred to a different department, you can drop it. All of your old actions that were assigned to it stay assigned to it, but the context doesn’t appear in your Remaining contexts sidebar. Any remaining actions still assigned to a dropped context become unavailable and move to the No Context group of the context mode sidebar."
Guys, for every ticket there no "perfect or correct way". One persons' usability is another persons problem. But I think inconsistency is even worse. I'd like to keep Tracks working consistently! Currently we use warning dialogs and changing that could be considered, but needs to be done integral, not local for deleting context only. I will not merge patches / pull request if we do not try to keep things consistent, i.e. deleting projects, recurring todos, etc.
@zoombody, you are right, a done state should be for use cases where you don't need a context anymore. I have a @clientA context, but my assignment with them is completed which renders the context unusable. But maybe I will start a new assignment with the same client, so I'd like to be able to reopen it. Also the use case you reference from the OmniFocus manual is a very valid one. I have several hidden context that should actually be closed.
Deleting should be for mistakes or if you really want to delete the actions / completed actions in a context. You probably won't be using it often.
In both situations (closing, deleting) the user should think about the active todos in that context. Currently we use the warning to remind the user to think about it. I don't mind moving all active todos to a "inbox"-context or a "No Context"-context.
@zoombody, you are right, a done state should be for use cases where you don't need a context anymore. I have a @clientA context, but my assignment with them is completed which renders the context unusable. But maybe I will start a new assignment with the same client, so I'd like to be able to reopen it. Also the use case you reference from the OmniFocus manual is a very valid one. I have several hidden context that should actually be closed.
Deleting should be for mistakes or if you really want to delete the actions / completed actions in a context. You probably won't be using it often.
In both situations (closing, deleting) the user should think about the active todos in that context. Currently we use the warning to remind the user to think about it. I don't mind moving all active todos to a "inbox"-context or a "No Context"-context.
Civil it shall be. I do not dispute that the current process is undesirable. I just get a little bugged when I hear people complain that they repeatedly ignored a sign and bad outcomes continued to occurr. You would not be able to ignore a one way street sign and then tell the cop that you see too many and just ignored it! (at least not in my town)
Anyhow, it is not the popup that is the problem, but rather we don't have a method to deal with the orphaned actions that would be left without a context.
My thought is to replace the javascript popup with an overlay screen like recurring todos have. This screen would state that there are the context to be deleted has todos in it and give you the option to:
Anyhow, it is not the popup that is the problem, but rather we don't have a method to deal with the orphaned actions that would be left without a context.
My thought is to replace the javascript popup with an overlay screen like recurring todos have. This screen would state that there are the context to be deleted has todos in it and give you the option to:
- move them to a different existing context
- move them to a new context with a textfield to enter the new context
- go to the context page to view them?
- or just delete them?
Migrated to GitHub issue #1389