View Full Version : Interface should follow Windows Standards for mouse click in menu navigation

07-13-2007, 12:05 AM
This is the Windows Standard for mouse click operation in menus:

1. Press down on mouse button; result Menu opens (e.g. File menu opens)
2. While keeping mouse button depressed, slide mouse to select sub-menu item (e.g. "Save As")
3. Release mouse button while mouse is positioned over desired menu item; result, Item opens (e.g. the "Save As" dialog opens)
4. Hit ESC key; result, the dialog is dismissed (e.g., Save As dialog closes without performing any operation)

By contrast, the current SpeedEdit usage requires twice as many clicks plus precision mouse movements, making the interface tedious and tiresome to navigate:

This is the SpeedEdit modus operandi:
1. To open Menu (e.g. "File") requires Press AND Release of mouse button (twice as many operations as Windows Standard above)
2. To open sub-menu (e.g. "Save As") requires additional Press AND Release of mouse button (again, twice as many operations as Windows Standard above, which only requires Release to perform this operation)
3. To dismiss active dialog (e.g. "Save As" dialog box) requires precise mouse navigation to the small "X" or "Close" buttons; there is NO keyboard shortcut to dismiss the dialog (such as ESC, or Alt-C, or Alt-F4)

This may seem like a small thing, but I can already see, after having opened the SpeedEdit interface for one minute, that using the application is going to take at least twice as many clicks as a standard Windows app.

Moreover, to move from one Top Menu to another Top Menu, e.g. to move from the "File" Menu to the "Output" Menu:

The Windows Standard would function like so:
1. Depress mouse button while over the "File" menu, and the "File" menu appears
2. While keeping the mouse button depressed, move mouse to the "Output" menu, and the File menu automatically closes and the Output menu automatically opens.

But the SpeedEdit modus operandi is:
1. Click and Release to open File Menu
2. THERE IS NO WAY TO DISMISS THE OPEN MENU except by Press and Release in a foreign area. (Pressing ESC should close the menu; moving the mouse over a different top Menu should open said menu and automatically close the File menu)
3. To open a different menu requires a THIRD press and release of the mouse button.

So, moving from the File to the Output menu in Windows Standard procedure requires only a depress and movement of the mouse, but performing the same operation in SpeedEdit requires THREE presses and THREE releases of the mouse - effectively six times as many mouse operations as the Windows Standard (one Press versus three Press-And-Release).

Let's just say this makes for tedious navigation of the menu structure. Please, please, oh please, include at least an option in Preferences to have Menus and Dialogs respond to the mouse per the Windows Standard operating procedure.

I want to love this program and do a lot of work with it, and I do not want it to be twice as hard, nor six times as hard to click through, compared to a Standard Windows application.

Thank you for your consideration.

07-13-2007, 03:31 AM
This has been something that I have asked for since VT2. Thank you, now I'm not the only one.


11-20-2007, 02:23 PM
I am shocked - shocked - to hear that. :eek:

Surely there is an awareness of the need to bring the SE interface up to basic Windows usability standards.

11-20-2007, 09:03 PM
If these few things bother you that much, try editing on an AVID! :D
VT/SE are so windows like it only takes my new guys a couple hours before they can go solo.

11-21-2007, 07:21 AM
Come on, Ted...
You know about that "time is money" thing... this is one of those issues. I don't believe much else would need to change to have something like this happen. No interface change, graphically, need apply.
But being able to navigate in those 'body-trained' manners goes a long way. Particularly if one bounces around many progs that follow the standard to land in one that doesn't.

11-21-2007, 07:53 AM
This really doesn't bother me personally much, but following standards is generally a good idea - unless a strong case against can be made (I've no idea what 'the case against' may be here, mind you.)

Certain users are more keyboard-centric, which can elevate this issue's importance for them. Then again, 'keyboarders' often fail to give a moment's thought to those who are stylus fans (for whom a trip to the keyboard is anathema.)

Not intending to hijack the thread, but I suspect this long-standing complaint is related to something else we've discussed before - the competition for dev resources. For example, if I had to choose between 'Esc key dismiss' and better MP3 support, I know which one would get my vote just at the moment. We've talked about the unfortunate tendency of lesser issues (which nevertheless justifiably irritate some) to fall to the bottom of the priority list and stay there. I'm not sure what the answer is.

11-21-2007, 09:29 AM
Robert, I wasn't trying to say there isn't room for improvement by any means.
Be good or I'll have to take you out for another 100 MPH drive in a convertable on a cold night! :D

11-21-2007, 11:42 AM
If you click a menu once in Windows it does stay open too, but you don't have to click to open sub-menus, just hover there.

11-21-2007, 12:18 PM
:devil: Ted!!

Made me laugh. And yes, I am looking forward to another Heart-Attack Ride with you.

And I know that improvement is something that is as important to you as it is for me.

Dunno about good, either...