Inconsistent use of mouse button down and button up events

[Scoox]

(Foreword: I wouldn't say this is a bug, but I wouldn't say it's a feature, nor a feature request.)

In Fusion 360 some GUI controls respond to mouse button down while others respond to mouse button up:

• Items in the Sketch Palette expand/collapse on button up
• Toolbar menus open/close on button down
• Design tree nodes expand/collapse on button up (on the small triangle to the left of each node that has children)
• The Save, Undo and Redo buttons respond to button up.
• The File menu opens/closes on button down.
• Selecting geometry, features, bodies, etc works on button up (this makes sense as such items can also be dragged)

In theory, the logic should be: "Draggable items should respond to the button up event, non-draggable items should respond to the button down event." The advantage of the button down is immediacy: things happen as soon as the button is pressed.

Unfortunately, this logic is not applied consistently throughout Fusion 360's UI. For example:

• Items in the Sketch Palette are not draggable and yet expand/collapse on button up (should react to button down)
• The File menu at the top expands/collapses on button down (as it should be ), but the Undo button right next to it responds to button up (should also respond to button down!).
• Design tree nodes are expanded/collapsed by clicking the black triangle to the left of each node. Yes, tree nodes are draggable, but the actual expand/collapse action is accomplished by clicking on a specific dedicated part of the node (the black triangle). In fact, nodes cannot be dragged by the black triangle, therefore the black triangle should react to mouse button down, but that is not the case ATM.

So, in summary, ideally everything should respond to the mouse button down event except the following:

1) Geometry

2) Toolbar buttons (more on this one below)

About toolbar buttons they don't really need to be draggable the whole time. Once the user sets up their toolbar and get used to the order of the buttons, there is no real need for the buttons to be draggable the whole time. In fact, once the toolbar is perfectly configured to the users liking, it would make more sense to be able to lock it, so as to prevent accidentally dragging buttons or, worse yet, dragging buttons off the toolbar which results in the button being removed from the toolbar, requiring users to manually pin the button again (this has happened many times to me). Since the only reason to respond to button up is that the target can also be dragged, it follows that the buttons of a locked toolbar should react to the button down event directly. This, in turn, would create a more immediate UI experience where things happen as soon as the mouse button is pressed, not after it's released.

Please comment, thanks.

[Phil.E]

@Scoox

Thanks for the feedback. I have never even considered any of this. I know our designers have, however. I'll pass this on to them for their consideration.

When I read your list of button up/down conditions I did a test. Using Win10 + Outlook, I found an analog to each item you described and found the behavior in Outlook to be consistent with the Fusion 360 UI. I'm pretty sure we designed the Fusion UI with some sort of experience/guidelines to help us.

So, out of curiosity, and because we may have missed something, can you provide an example of a similar product I can compare Fusion 360 with that uses your suggested rules? I'd like to try it out and see how it feels. Maybe you have a point!

Regarding buttons on the toolbar. They are always going to be draggable. We want you to re-order them and even customize your toolbar as needed for any task. I do this regularly. Some projects need Sketch Spline over and over. Then I won't use Sketch Spline for a month. I remove it from my toolbar and add it when needed. I've never accidentally dragged one off, but I suppose that's possible.

Have you discovered the Toolbox? Press S and a Toolbox appears. You can also customize that. Perhaps it will provide a better experience for you.

Thanks for the feedback and please let me know if you have more questions.

Regards,

[Scoox]

Hi, sorry about the late reply. Thinking about this, there are two ways too look at it. I think the way the designers thought about it was "UI controls that trigger a command fire on button up, all others on button down". That's why, for example, the Save button (triggers a command) works on button up, as do all toolbar buttons. Conversely, opening a menu does not trigger a command, so it opens on button down. I've just checked other applications and Indeed this logic seems to be quite ubiquitous.

HOWEVER, there are two places where this logic is not applied in Fusion 360:

1) The navigation cube menu (opens on mouse up, while all other menus open on mouse down):

2) Expandable items such as browser nodes and nodes in the Sketch Palette, which of course don't trigger any commands. Maybe I'm used to the way things work in Windows Explorer's tree view, please take a look if you are on Windows. It feels rather nice when tree nodes expand instantly upon clicking. If these nodes could be dragged by the small triangle, then of course button up would make sense, but that's not the case.

The cool thing about command-triggering UI controls that respond to button-up is that the user gets a chance to change their mind: if they click the wrong UI control by accident, they can simply drag away from it and then release the button over a 'safe' area. If the user is just opening a menu, there is no risk, since opening a menu won't trigger anything. The same logic would therefore apply to expanding/collapsing tree nodes.

At the same time, the benefit of menus and other UI elements that don't trigger any commands responding to button-down is faster navigation. For example, the user may click a menu, and before releasing the mouse they could already start moving the mouse towards the next sub-menu target, rather than first releasing the button and then starting to move. It's basically a nice ergonomic touch.

I hope that makes sense. I realise this is only a nitpick.

[Scoox]

Forgot to mention that, indeed, I'm aware of the 'S' toolbar, very handy indeed. I actually use a floating toolbar solution that replaces the Windows Start menu, effectively giving me a floating start menu. This is handy on my multi-display set-up as the menu pops up right by the mouse pointer, instead of me having to motion back and forth between the various places and the start menu button, or the taskbar pinned items.

I wish Fusion 360's the 'S' toolbar were more customizable though, at the moment it's just a dispassionate one-dimensional array of buttons. Without separators (as seen in some web browsers for separating bookmarks into logical groups), it's only useful as long as only a few commands are pinned there, pin more than 10 buttons and it gets pretty unwieldy. But such thoughts belong in the Idea Station.

[Phil.E]

Thanks for the clarity and details. That helps.

I poked around at the viewcube and you are correct. One thing, however, about the view cube is it's a corporate asset. Many applications use it. Because of that, we can't make changes to the UI for it and I bet the behavior is designed to work in all apps. 

Thanks again,

[Scoox]

The viewcube itself is absolutely fine, I was only referring to the small inverted triangle button (bottom-right of the viewcube) which, when left-clicked, pops up a small menu. This menu opens on LMB button-up, rather than on LMB button-down like essentially all other menus in Fusion 360. Once you are familiar with the viewcube, you know you can access the menu by right-clicking the viewcube. From an ergonomics perspective, the viewcube is easier to aim for than the tiny menu button due to its size (aiming for small objects requires more dexterity). For me there is no compelling reason to use the menu button. However, if it could display the menu instantly on buttonn-down, then I would be very compelled to use it over the right-click, because I would take immediacy over 'aimability':

1) Click LMB, menu is displayed instantly

2) Without even releasing the LMB, motion towards and onto the target menu item

3) Release LMB. Boom.

With the right-mouse button:

1) Right-click viewcube (let's ignore the fact that it's easier to aim for)

2) Hold RMB and wait a few hundred milliseocnds for menu to show up, or release the RMB (and again wait as there is a bit of lag)

3) Once menu is in view, motion towards target menu item

4) Left-click menu item

5) Release mouse button

The second method takes longer and requires more steps.I don't see how anyone would be against this: after all, every other menu in Fusion 360 works this way. Sorry, I'm a bit of an ergonomics nutcase.

Another small issue is that the context menu does not open instantly upon releasing the RMB, i.e. there's a bit of lag. Would it be possible to reduce this lag? The fact that the user has released the RMB implies they have committed to opening the context menu, so it should be displayed as soon as possible.

[Phil.E]

Got it. 

Sorry I should have been more clear, all of the menus, buttons, etc. that operate the view cube are "the view cube" asset.

Thanks again,