4

I'm working on scientific software. The users are engineers and physicists, not consumers.

It's a non-web, Windows app. The client is Java Swing.

It has an Edit menu with the usual clipboard actions on it: Copy and Paste. These are rarely used on text, however. Mostly they are for pasting some scientific object like a physics continuum from one part of a physics simulation to another. (That's why Cut is rarely supported.)

These Copy and Paste actions also appear on our Context Menus. (I mean menus that pop up when you right-click an object.)

Our Context Menus are sometimes long. They have many menu items, sometimes more than 10.

In some cases, we know that the Copy and Paste actions are very rarely performed.

I am considering removing the Copy and Paste menu items from a Context Menu if and only if we have reason to believe that those Copy and Paste actions are rarely performed. They would still be available via the Edit menu and keyboard shortcuts.

My reasoning is that they clutter up the menus. Shouldn't a Context Menu support actions that a user is likely to perform in a specific context?

On the other hand, I want the software to be consistent, both internally and with a user's expectations based on other Windows software.

Colleague A says We must support copy and paste on the Context Menus. These appear ubiquitously across Windows software like Word, Powerpoint, Firefox...

Colleague B says We must declutter our Context Menus. Specialized apps like Photoshop don't support every common Windows UI feature...

What should I do?

Improve this question
1
  • Are they often selecting text or right clicking into an input field? Copy/paste shouldn't show up unless they're valid actions, which limits the clutter
    – Zelda
    Commented Nov 28, 2012 at 15:55

6 Answers 6

Reset to default
7

Do you have any 'casual' users? People who will be using the software intermittently (say once every few weeks or months)? Because I'm of the belief that power users can deal with user interface inconsistencies a lot better than casual users, so I'd say it's more acceptable to remove those options if everyone is using it every day.

Now I still don't like removing a system-standard item like copy/paste, so I have to wonder if the real problem isn't that you've got too much OTHER stuff on that context menu. A context menu is supposed to be just for the top few most common operations - it's not supposed to have every possible thing on it. How did they get so big? Can you push back on the other operations in any way?

Improve this answer
2
  • Yes, we do have infrequent users, and I'm sure you're right that other items should come off those menus. But in this case there are probably no other items that are used less often than Copy and Paste. On a context menu does the system-standard outweigh the frequency of usage?
    – Grushenkaman
    Commented Nov 28, 2012 at 14:32
  • @Grushenkaman - It's a hard one, but in my mind it does. If you really can't drop any of the other context items, then perhaps you want to drop copy/paste from ALL of your context menus. That would be slightly inconsistent with normal Windows UI, but at least it would be internally consistent, and copy/paste can still be accessed by the system-standard control-c/control-v.
    – Michael Kohne
    Commented Nov 28, 2012 at 18:15
2

My suggestion is this: Leave the UI uncluttered omitting the context menu items as a default, but empower your users with the option to add them through a setting. Yes, this breaks (old) convention, but I think it’s about time. I can’t imagine Windows 8 apps nor Office 2013 showing a cluttered UI like the way we saw Word in 2003.

Improve this answer
5
  • 3
    I think you would be better served by picking one way or the other, and NOT giving them a setting. You may get it right or you may get it wrong, but putting in a setting just punts on the question, rather than solving it. You should solve this, not throw up your hands and walk away. Putting in the setting also gives you one more set of code paths you have to test when you go to release. Don't do it.
    – Michael Kohne
    Commented Nov 27, 2012 at 21:35
  • 2
    Code is never an issue when it comes to UX. Either you make a great UI and empower users or you don't. Let developers worry on code and you can focus on design!
    – Benny Skogberg
    Commented Nov 27, 2012 at 21:49
  • 1
    The best of both worlds! This is tempting, but I'm concerned that adding preference settings complicates a user's experience with the software somewhere else. I'm afraid people searching for some other setting will end up having to navigate around the customize my menus setting. In principle I embrace Code is never an issue when it comes to UX. In practice our resources are limited and introducing complexity is dangerous.
    – Grushenkaman
    Commented Nov 28, 2012 at 14:26
  • @BennySkogberg - I'm going to disagree with you here. First off, adding preference settings complicates the total UI, and makes it harder for the users overall. One setting is a minute increment in complexity, but they do add up, and a setting like this makes it harder for users to look over each other's shoulders at their machines, because the UI changes machine to machine. Second, 'let the developers worry about code' is a recipe for disaster. It's fine to take on development complexity for the sake of better UI, but 'code is never an issue' is asking for bad things to happen.
    – Michael Kohne
    Commented Nov 28, 2012 at 18:19
  • @MichaelKohne Being a Sharepoint developer myself, I know what bad code does - make no mistake about that. However, a simple setting on a menu strip is not that hard to accomlish, and well hidden for users who don't care. But since every user is different, it's in our interest to make the UI fit for the most of our users. So I am dead serious when I say let developers worry about code and empower your users.
    – Benny Skogberg
    Commented Nov 28, 2012 at 18:26
1

Ideally, you would try it out and see how it fares. If you can tell from logs that it is not used, it is probably safe to remove it. We asked ourselves that question in our product, but figured out that most users (experts) would know and want to use the shortcuts.

Improve this answer
1

Background: I have no experience in UX, however I consider myself a pretty heavy poweruser of most software, and enjoy the concept of UX helping make things better!

I personally would prefer just leaving them out entirely on menu's they make little sense for. Considering your user is very likely to be highly knowledgeable of computers (by career), I Imagine that a very large portion will know ctrl-x and ctrl-v. I would make sure to offer an option to replace them on the menus, perhaps in a preferences menu or something, however by default, I would prefer to be able to access the much more used options faster!

Improve this answer
1

We have come up against this problem as well (we also have similar target markets as you). Our solution was to add the common Windows actions (Cut, Copy, Paste, Edit, Delete) as icons only, next to one another on one line.

This compacts the context menu heavily, but still allows access to common functions. If a common action is not supported, it does not appear in the context menu.

e.g.,

[Action 1 icon] Action 1
[Action 2 icon] Action 2

[Action 3 icon] Action 3
[Action 4 icon] Action 4

[Cut icon] [Copy icon] [Paste icon] [Edit icon] [Delete icon]

Improve this answer
1
  • I'm not convinced that this is an answer to the question, because it looks like a comment. Could you rephrase the answer to look more like an anwer?
    – Benny Skogberg
    Commented Nov 28, 2012 at 7:14
0

'My reasoning is that they clutter up the menus. Shouldn't a Context Menu support actions that a user is likely to perform in a specific context?'

The appearance of two well-known, well-understood, system-wide menu items is not likely to affect performance when interacting with a context menu. In other words, they do not add clutter.

Assuming the Copy and Paste items appear in exactly the same location in all context menus, it is unlikely that they interfere with searching for items in the context menu. The users will learn the location of Copy and Paste then stop looking at that location when their task does not include Copy or Paste. Putting them at the bottom or top of the menu will help your users learn the rule and ignore the items when they are not needed.

Another problem with omitting Copy and Paste from some but not all menus is you will draw attention to an unimportant part of the UI. A context menu is a standard UI element in a Windows application. A context menu is not the place to be clever with your UI. It should be a place for a simple interaction. Anybody that uses Windows software regularly will notice the absence of Copy and Paste in a context menu. After noticing the absence of those items, they will try to figure out the rule governing the appearance of the items. Although engineers like figuring out the rules for system behavior, do you want them spending time learning the rule for your context menu or spending time doing their engineering work?

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.