[dev] [commits] Horde branch master updated. 62b322a88d6e33fe766d813d16b6580fc4974775

Jan Schneider jan at horde.org
Tue Nov 12 10:46:14 UTC 2013


Zitat von Michael M Slusarz <slusarz at horde.org>:

> Quoting Jan Schneider <jan at horde.org>:
>
>>> My one issue with the current context menus is that, unlike say  
>>> Windows, the row that triggers the submenu *is* a valid clickable  
>>> item.  In Windows, that isn't the case.  I'd sort of like to see a  
>>> context-menu UI where, for items that are clickable by themselves,  
>>> that the submenu is not displayed unless you hover over the  
>>> right-most 15% of the row.  Especially if those submenus are  
>>> "advanced" options, they shouldn't be displayed to a normal user  
>>> but should be easily available for more advanced users.
>>
>> I completely lost you here.
>
> In Windows, say you have a menu with two entries:
>
> File
> Other >
>
> "File" is directly clickable.  "Other" is a submenu.  Hovering over  
> Other opens the submenu.  But Other *itself* is never clickable.
>
> That is different from our context menus, where the parent item MAY  
> be clickable (and may not).  It's not consistent UI - and these kind  
> of window UI menus are both 1) common and 2) generally consistent  
> across various UIs.  So making "Other" clickable, in Horde, may be  
> fairly useless since people don't know to click on it in the first  
> place.
>
> So in this situation, it sounds great to say just add a submenu to  
> the parent action with the thought that only advanced users would  
> ever reach the next level.  But the problem is that once you  
> introduce a submenu, you change the expected behavior of the parent  
> item.  So you are forcing even novice users to have to navigate (or  
> at least view) the submenu contents.  And that's not great UI either.
>
> I was suggesting that we introduce a type of context menu action  
> where the submenu is not automatically displayed on hover -- unless  
> you happen to hover over the "activating" area.  i.e. the popdown  
> icon.  But this activating area would only be a small portion of the  
> menu entry, so generally the submenu would never pop open  
> unless/until it is explicitly desired.
>
> michael
>
> ___________________________________
> Michael Slusarz [slusarz at horde.org]

Ah, understood. And makes sense. Though I disagree that Windows'  
context menu behaviour is the de-facto standard UI behaviour. I have  
to admit I didn't look for context menus specifically, but at least  
for main menus (and I don't consider those to be completely different  
to context menus), I see all kind of behaviour regularly: open on  
hover, open on click, open on hover and being clickable, open on  
clicking or hovering icon, etc.

I personally like menus to 1) open only on click (either on drop down  
icon or menu entry) and 2) stay open until you explicitely close them  
or click anywhere else. It's still on my todo list to beef up the  
Horde main menu with JS to modify the current behaviour, though not  
with high priority.
-- 
Jan Schneider
The Horde Project
http://www.horde.org/



More information about the dev mailing list