Where should pasted objects in a drawing application be placed?

by TheCloudlessSky   Last Updated January 20, 2018 17:16 PM

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:

  • MS Paint always pastes to the top right corner of where you've scrolled to.
  • Photoshop/GIMP pastes to the center of where you've scrolled to/your selection.
  • Paint.NET seems to paste on top of the copied area when zoomed out. But, when the pasted area is not visible, it tries to position it near the copied area.
  • Some applications paste "offset" from the original location. Multiple repeated pastes continuously offset.
  • MS Word pastes offset the original shape and scrolls you back which is very annoying
  • We have an internal application that always pastes to where the mouse is.

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:

  1. Paste to the center of where you've scrolled.
  2. Paste to the top/right corner of where you've scrolled.
  3. Paste to where the original shapes were copied (but also where you've scrolled).
  4. Paste to where ever the mouse is. I'm against this one because I believe that's what the context menu paste is useful for. Also, what do you do if your mouse is off screen? The first time the users paste, it may or may not be obvious as to why the pasted objects appeared where they did.

Before writing multiple implementations and testing them on our users, I figured I'd ask the community for some thoughts on these choices.



Answers 4


You can follow the cancellation process to reduce your options:

  • MS Word is not a drawing application, so ignore whatever it does.
  • MS Paint is not really a serious drawing application. Can ignore it too.
  • Paint.NET, I have not heard of this one before, so can't comment.
  • Photoshop/GIMP are players with big stakes in the game.
  • The offsetting is an additional feature and should not be mixed with the initial placement.

So, now, you're left with these options:

  • Paste to the center of the screen
  • Or, paste where the mouse it

And some side options:

  • Pasting in place should be an additional functionality ('Paste in place')
  • So should, paste offsetting

Now, I would argue for center over on mouse:

  • If you're not using the mouse to paste, chances are the cursor is somewhere other than the destination location. Making the 'center' choice quite good. Another scenario: You copy some element from one sheet, navigate to destination sheet and use paste, chances are your cursor will be on the sheet tab rather than the intended location.

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.

rk.
rk.
June 24, 2013 14:38 PM

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?!?

LindaCamillo
LindaCamillo
June 24, 2013 14:39 PM

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.

obelia
obelia
June 26, 2013 03:50 AM

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.

If the source object is visible

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 not visible

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.

Chris Calo
Chris Calo
June 27, 2013 20:44 PM

Related Questions


"Cut and Paste" in a tree structure

Updated February 13, 2018 09:16 AM



Keyboard shortcuts and navigation in complex widget

Updated April 28, 2015 21:07 PM