Many are the times I've lost changes, because moving cursor too fast, ending up opening the user menu and clicking "Edit Account" when aiming for the save button.
Maybe possible to move it or solve this in some other manor?
(Yes, most times you can use command/ctrl-Save, but not when cursor being placed in a richtext editor window – then the web browser's save function kicks in instead. That's why I tend to use the Save button.)
Those drop-down on hover menus drive me nuts anyway. Pain in the neck.
Maybe a setting to turn off the auto-open-on-hover could be added? That would be pretty nifty actually.
That would mean that the sub-menus would never be available. It would need some Javascript to make it open on click.
This is why when I originally designed the top menu bar for Evo I used a "dropline" menu, where the submenus are listed in a secondary menu bar rather than a dropdown.
Just to also have a different opinion: I never had that issue to click the user menu instead of save and I like the dropdown menus in Revo much more than the Evo menu.
But a optional setting to require a click on 1st level menu items to reveal the dropdown should not hurt.
Well, for me the only thing needed really, is perhaps relocate the Save button a bit on new rescources/TVs/chunks etc, because it winds up directly under the menu and you lose all things you've typed in, when accidentally mis-click.
For example have the buttons aligned left instead of right or something, keeping SAVE at the same spot every time.
Second DavPah.
Or just swapping "Save" and "Help" would probably work as well.
In fact, I had the same problems with the account menu popping up accidently when I wanted to hit the save button. I don't have a proper solution in mind right know, but +1 for anything making the situation better.
Maybe the click option will improve the manager for touch devices also?
I wonder if maybe a CSS transition can delay opening the menus?
The delay idea is a good one. And it does not only apply to the save button. Everytime I'm reaching for the row of buttons and not being careful, I often pass over the account menu and wind up in the wrong place if not careful.
I changed the value in the manager's index.css
{visibility:visible;
opacity:1;
filter:alpha(opacity=100);
transition:all .15s ease;
transition-delay:.2s
}
Just changing the delay from .2 to .7 made a huge difference.
Well, yes, that's better, but I am the "click"-type-of-guy and I am being forced to this hover-stuff by a dev who thinks he knows how I shall work. Hm.
Why not make it a system setting, so everybody can set it on system level and overwrite it per user?
Having a choice is awesome!
That would be awesome. And throw in control over the dark gray hover-over info-boxes too, that sometimes blocks up things too much and brings another kind of frustration.
Having it on click would require some serious Javascript modifications. I don't see how it could reasonably be an option. A binary yes/no option is one thing, but having two different functions is something else.
If someone were to create a pull request for the transition delay that would be terrific :)
Nice, also had this issue many times... So let's got, let's ship it :shipit:
When 2.3 was in pre-release, didn't the left and the right menu behave different? I remember having a long discussion to remove the "click on the main nav button auto calls the first menu item" for the user menu, cog and help (#11600). Back then you could not log out on a tablet because tapping on the user menu called the "Edit account" page, making it imposible to get to the "logout" button: you can't hover on a touch device.
Nowadays one can use the MODX Manager quite well on a tablet. And when I tap on a menu button, the menu opens. Isn't there already some JS in charge of handling the input events? I mean, we still have ExtJS on board which handles everything. And wasn't handling clicks already implemented when 2.3 was released?
Sure, a delay seems to be a solution, but not if you are "slow" like someone with a handicap. A delay doesn't make the manager more acessible. It just delays something that should be handled by a click/tap.
Or maybe the behaviour could be managed with some system settings like "react-on" (click.tap / hover) and "hover-delay-time".
just my 2.5 cent. ;-)
Ha! Found the github discussion on the main nav from back then:
https://github.com/modxcms/revolution/issues/11706 #11704 #11600
@mindeffects you make some excellent points—especially around using Revo on a tablet, just because it's imperfect doesnt' mean it can't be improved.
It might be good to turn some of these suggestions into design and interaction principles for the project so that when people are adding or changing interactions that they don't make it up or ignore use cases. Perhaps an RFC around how links, menus, buttons and navigation should behave and what ExtJS properties might need to be attached under those user stories.
This has been merged!
@modxbot close
Most helpful comment
@mindeffects you make some excellent points—especially around using Revo on a tablet, just because it's imperfect doesnt' mean it can't be improved.
It might be good to turn some of these suggestions into design and interaction principles for the project so that when people are adding or changing interactions that they don't make it up or ignore use cases. Perhaps an RFC around how links, menus, buttons and navigation should behave and what ExtJS properties might need to be attached under those user stories.