We are creating a drawing application where users can add shapes to a canvas. They can cut/copy/paste via keyboard shortcut or context menu. For the context menu, it's pretty clear that the pasted objects appear at the context menu's click point. However, the keyboard shortcut has caused this discussion in our team.
There doesn't seem any sort of standard for pasting objects in drawing applications:
We don't want to do what MS Word does and scroll you back to the original pasted area. It is terrible UX. Therefore, our options seem to be:
Before writing multiple implementations and testing them on our users, I figured I'd ask the community for some thoughts on these choices.
You can follow the cancellation process to reduce your options:
So, now, you're left with these options:
And some side options:
Now, I would argue for center over on mouse:
All this said, it never hurts to gather a couple users from each expertise group and do some testing. The test itself should not take that long and it will give you conclusive evidence for your use case rather than relying on someone else's decision.
I think your #3 is the strongest choice, because it makes the position of the new element relative to an object that is guaranteed to be persistent, no matter what else is going on in the user's environment.
I had a much longer response drafted and ended up deleting most of it because all of the other options are dependent on user behavior. In an interrupt-heavy job, managing multiple monitors, there are too many things that take focus away from the task at hand (meeting reminders, modals in other tabs), making those targets easy to lose. I do so much of my work in a web browser now.
Making a study of the user's environment would be a very enlightening thing. For example, I'm drawing and suddenly get a Google Hangout invitation. Where the bleep is my cursor now?!?
Another option is to have it "stuck" to the mouse pointer, to be placed by a mouse click, released at the point of mouse-up. This is somewhat unusual but has the advantage of speed since the step of grabbing (mouse down drag) is avoided, the new object comes "pre-grabbed" and ready to place.
But generally I'd stick with a more conventional behavior. Initial placement in one of the top corners, or the center of the viewport is straighforward enough. Personally, I tend to look to the top left corner when pasting in a drawing program.
In my opinion, the most important consideration is that the person at the keyboard should know the paste happened. And other than playing a sound, really the only way to do this is to make sure the pasted object is visible. The hard part is defining what "visible" means.
Well, if the source object is currently visible, then I would paste the new object right on top of or, optionally, at some small offset to the source object. You could argue that right on top of the source object makes it difficult to see the new, pasted object, so an offset helps with that. However, some people prefer the precision of knowing that the pasted object ends up in exactly the same position, so using motion to communicate the paste happened can help with that.
If the source object is no longer in view, then I would say paste it smack in the middle of the view. The harder question is how many pixels means "visible". Certainly, if only a 1×9px area is in view, I would say that's not visible enough. Where you draw that line is up to you.
(If you must paste out of view, then I would scroll the newly-pasted object into view.)
As a side note, you might also consider implementing a duplicate command (⌘+D perhaps), which is just a single step for copy and paste.