4

I'm working on the Linkage Mechanism Designer and Simulator for the Mac. It's a mechanical design CAD program/app. I have a fully working version for Windows so I wanted to port it to the Mac and do things in an Apple-ish sort of way.

I have a shortcut key on Windows, the "A" key, that will add a connector to the currently selected link at a point near it's center. I've expanded that on the Mac so the connector is added at the location of the mouse pointer when the key is pressed. In an effort to be "complete", I have an edit menu item named "Add Connector" and it shows the "A" shortcut key.

The problem is that if the user is using the menu item and not the shortcut key, the mouse pointer is not over their document/mechanism and the menu should not do anything. it only works right when the mouse is over the document window.

My options are many:

  1. Disable the menu item only when the menu is visible. This will imply that the document is not in a state to accept a new connector so it's a bad idea.

  2. Show a message about how the key is the only way to use the menu item effectively. I would add a "don't show again" option to this message. I would beep from then on if they use the menu item.

  3. Remove the menu item and just detect the keypress. This violates the idea that all actions are represented by menu items. I like having the option in the menu.

  4. Just add the connector somewhere like in the center of the editor window or in the center of the selected link.

Any thoughts on how to handle this? So far, I'm inclined to show a message or just make a beep sound when the menu item is used directly.

Oh, and it's going to be an interesting challenge to actually detect if the menu was used vs. the shortcut key. I suspect that I will cheat and detect key-down events to catch the key before the menu item is even triggered. Then I can simply act on the menu item knowing that it can't get used except from the menu.

Thanks for the help.

1
  • Can you add a screenshot or wireframe, to make it easier to understand your issue?
    – Morco
    Commented Aug 13 at 6:01

2 Answers 2

4

Good question. I would say that just because an interaction is represented both by a mouse + keyboard stimulus and by a menu item doesn't mean that the two representations have to have the same behaviour.

When they select the menu item, have it enter "add connector state". In this state, the program should add a connector at the mouse position when they press A or when they click, without both being necessary (but obviously nothing prevents them from doing both at the same time either).

Let the state be exitable by Esc or perhaps an unrelated input, e.g. a right mouse click.

Make sure the state is easily noticed, e.g. by a different cursor and/or by greying out menu items except for Cancel, for instance.

It seems to me that this "detachment" of the initiation and completion of the action (1) is the best way to avoid the nonsensical situation of clicking a menu item that must interact with mouse position, (2) preserves most of the usual interaction's familiarity, allowing users who prefer one method or the other to learn/adapt to the other easily, and (3) is fairly well represented in typical programs that require this sort of interaction.

Incidentally, if you do implement the "add connector" state, you can merge the two interaction patterns a little more: the trigger for your standard interaction, the A key on its own, could be reimagined as a way of initiating the same state, where a simultaneous or subsequent mouse click or the release of A terminates the action and adds a connector. This also has the potential to build some cool things into the workflow, such as combinations or modifiers once the state is entered. (You could add an option to control whether A instantly adds a connector or enters the "add connector" state until release/click, or what have you.)

1

In editing programs, the order of action is as follows:

1 - Select the menu option

2 - The cursor changes to "place object", sometimes with a preview of the object to be placed (image, text, table, etc.)

3 - The user places the mouse pointer where the object must be placed

4 - Click to place the object

From there, there are keyboard options depending on the location to give to the object or how the object should flow in the document.

1
  • This is typical of many apps and programs but it violates the modeless style of the app I'm writing. The cursor does not change for any operation to avoid the user needing to somehow cancel or switch operations if they decide to not finish the operation they started. So far, this paradigm has suited the app very well. It is this one instance where there is an issue. it is worth considering violating my paradigm, but I would prefer not to for various reasons (like never having had to do it until now). The feedbacks is much appreciated. Commented Sep 4 at 7:12

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.