[igrok]

I sent in a bug report about this, but wanted to see if anyone else can confirm. In context view, select an action, right click on it, and choose "Duplicate". I get an error tone, and no duplicate. Switching to project view, the duplicate function works fine. Can anyone confirm?

[whpalmer4]

I see the same behavior. I wonder if it might be intentional, although I would suggest that the Duplicate command ought to be grayed out in the menu if using it doesn't make sense.

[igrok]

I suppose it could be intentional, and you're right that if so, the menu item should be greyed out. But why should duplicating an action be unavailable in context view but available in project view? I should be able to duplicate an action regardless of which view.

[Brian]

Checking the development database, the menu item being enabled is a bug. We have an issue filed on adding the ability to duplicate in context view, but there's a UI issue we have to figure out first.

OmniFocus thinks of projects as ordered lists of actions. In project view, once the user duplicates an action, we can stick it into the view and assume that they'll move it to the "right" place in the project, for whatever definition of "right" works for them. They're looking at the list when we insert something new into it.

When the user is looking at context view, though, the "right" reaction is a lot more ambiguous. They're not looking at the project when they make the duplicate. They're looking at an arbitrary collection of actions from one or more projects. If we decide for the user where to add it in the project and we pick wrong by whatever standards they're using, that makes them unhappy.

Do we yank them over to project view and ask them to file it right then and there? This has the smallest chance of ending up with it filed in the "wrong" place, but would be very disruptive to the workflow.

Do we stick it immediately following the item they duplicated in the project, and hope they catch any mis-filing in their next review? Stick it in the inbox until they clean up? Either would be less disruptive to the workflow, but increases the odds that the action won't be where the user expects it to be, which is often perceived as "wrong".

Filing a bug on the menu item being enabled, and adding a vote to the "figure out how we should handle this case" item, as well.

(If folks want to send feedback about this, feel free to post here, but please also send it in as email. Thanks!)

[Brian]

I'm going to remove the word "bug" from the title of this thread, since it may give folks skimming the forum the wrong impression.

[igrok]

I respectfully suggest you're quite overthinking this issue. There are only a couple of reasons to duplicate an item, and I think for all of them the idea is simply to save yourself from typing everything all over again. Thus, one duplicates the item, then makes whatever changes are required, such as due date, or where to file vis a vis project and/or context. Why would someone duplicate an item and then just leave it there? And why protect that person against such inaction, when there are good reasons to allow this mechanism, such as saving me from typing the whole thing all over again. Do we really need to be protected in this way?

And wouldn't your same logic apply to even allowing a user to create a new action in context view? As it is, when I'm in context view and create a new action, it automatically fills in the project with my default single-action project list. By your reasoning, that should be disabled too, because you don't know that that's really the project you want to put it in. But the case for duplication is actually easier, because you actually already have some information about the "new" dupicate, including the project from which it was spawned, so that it's far more likely that the duplicate will be properly placed in that project anyway. But at the least, it should be no worse off than a new action being placed in the default miscellany project. See what I mean? Unless you actually intended all actions to only be created while in project view. I can't believe I'm the only person that adds new actions while in context view. Sometimes, I go to my @phone context, and add in a bunch of calls I have to make, assigning them to various projects as I add them. I do the same in other contexts. So I can add a blank one (which gets assigned to my default miscellany project) but I can't duplicate one? That simply doesn't make any sense at all.

So instead, when in context view I find an action I want to duplicate, I should select it, switch to project view, duplicate it, add the context/project there or switch back to context view for doing so. Why? And this is supposedly to avoid "yanking" me around and "disrupting the workflow"? On the contrary, I find this over and over again, disrupting my workflow. Hmmm, maybe I'm just using this tool wrong.

For me, the great power of contexts and projects is that I can view AND enter new actions from wherever it makes more sense to do so. Sometimes I like context view for doing so, sometimes project view. For example, I have one context called @phone, and I have an action in there to call a client. In the note I have a call-in phone number and password, and a bunch of info I need to see before I make the call. So at the end of the call, it's been set that I have to make another call a few days later. I'm in context view. I'd like to duplicate the action, change the due date, and mark the one I just did as done. Yes, I could just change the due date on the action, but I like the record of having made the call, because I use these done actions as reminders for billing time.

In short, when I come across an action that needs duplication, I shouldn't have to switch to any specific view to duplicate it. I certainly shouldn't have to copy the action, create a fresh action, paste in the action info, go back to the original and copy the note, go back to the new action, paste in the note, assign a category, and assign dates. I'd think that's what a duplicate command is actually for.

Just my two cents.

Mark

[curt.clifton]

What might work nicely for me is if duplicate in context mode popped up a populated QuickEntry window. Now I'm free to change as much information as I like with minimal workflow disruption--just an Enter key press if OF guessed all the information correctly. If, instead, I want the action dumped into my inbox, then I can just tab and delete a couple of times and hit enter to dump the new action for processing later.

[Brian]

Originally Posted by igrok

As it is, when I'm in context view and create a new action, it automatically fills in the project with my default single-action project list. By your reasoning, that should be disabled too, because you don't know that that's really the project you want to put it in.

It's "safe" to fill in that cell because the user can see what we've done and edit it before hitting clean up.

The thinking behind the current behavior of duplicate has to do with making assumptions about something that is not visible in context view at all - the ranking/ordering of one action relative to the peers in the project.

It sounds like that factor - what position an action occupies in a project - does not matter much in your workflow; I assure you it matters for other folks. In a sequential project, there is a very real difference between "insert it just beneath the one that it's duplicating" and "insert it at the bottom of the project". Depending on what the customer intended, I could make a case for either behavior being appropriate... some percentage of the time.

I understand that the current behavior frustrates you, and I'm not asserting that it's the ideal. It's definitely a safe assumption that what the customer intended to do when they hit Duplicate was not "nothing". Curt's suggestion doesn't resolve the ordering issue, but would be an improvement for you at least.

We have a feature request open on changing this; your suggestions to the dev team are welcome. Note that the solution must work in sequential projects, parallel projects where order doesn't matter, parallel projects where order indicates priority, and single-action lists. Plus a couple more organization systems that I would never imagine but one of our customers did. :-)

Originally Posted by igrok

I certainly shouldn't have to copy the action, create a fresh action, paste in the action info, go back to the original and copy the note, go back to the new action, paste in the note, assign a category, and assign dates.

With the action selected, you can copy and both the item and the note will be copied; no need to make multiple trips back and forth. Command-option-R shows the action you just copied in Planning mode. Paste and edit to taste. Command-option-R again and you're back in Context mode, with the action you just added selected.

I doubt you'll find that ideal, but it should save you several steps vs. the workflow you described.

[igrok]

Thanks, Brian, for your comments. I see where you're coming from.

I tried a few things:

Project view:
Duplicating, it seems that it always duplicates into the project as an action immediately following the one that it duplicated from, whether it's a sequential or parallel project.
If you add a new action, it goes to the bottom of the project, and gets assigned the default context for that project, or if the default is set to none, then it gets no context at all. Either way, though, you can still "see" the context for the item, assuming that column is showing, so you can just click on the context and choose the correct one.

Context view:
Duplicating doesn't work
Adding a new action gets assigned to the misc project, though I couldn't figure out the algorithm for its placement therein. You can see the assigned project so a click and choose will assign the one you want. But doesn't that make an assumption too, that you want to put it in the misc project, and that you'll change that project if you want to?

I guess I don't see why duplicating should be handled any differently than adding a new action in context view, since it's really just that -- adding a new action -- but with some info already filled out. You could just have it assign to the misc project, or even the inbox, awaiting prioritization.

Or perhaps the best way to handle it would be to actually have two commands available as a submenu -- duplicate > beneath current action in project, and duplicate > to bottom of project. Maybe a third for duplicate to inbox? That way it requires further action to file it.

My point is only that for the person who needs to duplicate in a project and put it in its proper order in that project, project view would be the logical place for duplicating. But if you see an action in context view, you should be able to duplicate it, just like you can add a new action.

Curt's suggestion is a good one, though you're right that it doesn't address the ordering issue.

I also tried copy/paste for a selected action. Works fine for project view, but the paste doesn't work in context view. I suppose it's the same issue as the duplicate command.

Just a few thoughts, and I hope they prove useful somehow. Thanks again for even entertaining some ideas.

Mark