Hi, Some background: * Colibri ** menus displayed on hover ** custom menu JS ** menu entries could be icon+label+separator+link+whatever * Flamingo ** menus displayed on click ** menu component from Bootstrap ** it expects simple links or menu dropdown containers (not both functions) Theoretically Bootstrap doesn't support our use case and cannot replicate by default the Colibri's behavior. Any change we want to make to the menu Bootstrap component means we are branching from the default behavior and we will create a custom one. We really need to listen to clicks and not hover state, since we need to be mobile compatible. It's normal that the users feel a bit confused since they are used with a certain behavior and we tried to mix them in order to have both menu and navigation use cases. And I think the reason is a bit confusing is that the separation between the link and the arrow is invisible, compared with the btn-groups used for Edit or Add. For example, I think that making the separation more clean, like in this screenshot http://jira.xwiki.org/secure/attachment/28807/btn-group.png would improve a bit the things, but would need visual improvements and is not default also. Maybe we could think of a better solution if we were to go on this path. Behavior like double clicking a certain element will be a hidden interaction for the users. Double clicking is not a Web behavior and you cannot expect users to know on which links to simple click vs. on which to double click. In the usability testing sessions users had a hard time to double click on uploading image in the WYSIWYG popup, so I'm not sure about this approach's success. Regarding the IntelliJ IDEA screenshot, we already discuss about this idea and even made a similar proposal some long time ago, see http://design.xwiki.org/xwiki/bin/view/Improvements/ActionMenuNavigation Although this proposal is a nice idea and I would like to have it, I don't see how this would 'simplify' the current implementation. IMO it will make it even more complex and we would certainly need a custom menu. Also I see this as a new feature, than a solution to our current problem. When we implemented the current solution we discussed if the navigation should be put on the text or on the icon, see http://jira.xwiki.org/browse/XWIKI-10449 . The main problem is the findability of this functionality. Users might never press that icon (this problem applies to the solution brainstorming and the breadcrumb proposal). So I think the idea to have an entry with "Go to ..." could be a solution and to keep the menus interact with the default behavior (removing the navigation from the dropdown activator). Removing triangles is not an option. That is a default menu marker caret. So what are the next steps? We do a issue with the "Go to ..." solution? Thanks, Caty On Wed, Sep 24, 2014 at 11:55 AM, Guillaume "Louis-Marie" Delhumeau < gdelhumeau(a)xwiki.com&gt; wrote:

Folks, you speak of consistency and then come up with this solution... So we have a problem with "non-standard bootstrap dropdown buttons" that our users (whoever they may be) have a problem with understanding that there is either an action or a dropdown involved in the same button, like they can encounter in other interfaces along their computer usage history. Our solution is to stop using the mixed mode, and only use the "standard bootstrap dropdown buttons" that have their first action in the submenu the thing that would have happened in the past when the users clicked directly the action part of the "mixed button" we were using. Ok, we implement this solution, but we only do it for the top navigational elements. We completely ignore the "Add" and the "Edit" buttons that "suffer" from exactly the same "problem". My question is: why? If we do/did decide that this is the way to go, we should at least be consistent and do it everywhere in the UI, otherwise it just causes frustrations. Thanks, Eduard On Fri, Oct 3, 2014 at 4:21 PM, Ecaterina Moraru (Valica) &lt;valicac(a)gmail.com > On Wed, Sep 24, 2014 at 5:25 PM, Ecaterina Moraru (Valica) < > valicac(a)gmail.com> > > Hi, > > > > Some background: > > * Colibri > > ** menus displayed on hover > > ** custom menu JS > > ** menu entries could be icon+label+separator+link+whatever > > > > * Flamingo > > ** menus displayed on click > > ** menu component from Bootstrap > > ** it expects simple links or menu dropdown containers (not both > functions) > > > > Theoretically Bootstrap doesn't support our use case and cannot replicate > > by default the Colibri's behavior. > > Any change we want to make to the menu Bootstrap component means we are > > branching from the default behavior and we will create a custom one. > > We really need to listen to clicks and not hover state, since we need to > > be mobile compatible. > > > > It's normal that the users feel a bit confused since they are used with a > > certain behavior and we tried to mix them in order to have both menu and > > navigation use cases. > > And I think the reason is a bit confusing is that the separation between > > the link and the arrow is invisible, compared with the btn-groups used > for > > Edit or Add. For example, I think that making the separation more clean, > > like in this screenshot > > http://jira.xwiki.org/secure/attachment/28807/btn-group.png would > improve > > a bit the things, but would need visual improvements and is not default > > also. Maybe we could think of a better solution if we were to go on this > > path. > > > > Behavior like double clicking a certain element will be a hidden > > interaction for the users. Double clicking is not a Web behavior and you > > cannot expect users to know on which links to simple click vs. on which > to > > double click. In the usability testing sessions users had a hard time to > > double click on uploading image in the WYSIWYG popup, so I'm not sure > about > > this approach's success. > > > > Regarding the IntelliJ IDEA screenshot, we already discuss about this > idea > > and even made a similar proposal some long time ago, see > > http://design.xwiki.org/xwiki/bin/view/Improvements/ActionMenuNavigation > > Although this proposal is a nice idea and I would like to have it, I > don't > > see how this would 'simplify' the current implementation. IMO it will > make > > it even more complex and we would certainly need a custom menu. Also I > see > > this as a new feature, than a solution to our current problem. > > > > When we implemented the current solution we discussed if the navigation > > should be put on the text or on the icon, see > > http://jira.xwiki.org/browse/XWIKI-10449 . The main problem is the > > findability of this functionality. Users might never press that icon > (this > > problem applies to the solution brainstorming and the breadcrumb > proposal). > > > > So I think the idea to have an entry with "Go to ..." could be a solution > > and to keep the menus interact with the default behavior (removing the > > navigation from the dropdown activator). > > Removing triangles is not an option. That is a default menu marker caret. > > > > So what are the next steps? We do a issue with the "Go to ..." solution? > > > > http://jira.xwiki.org/browse/XWIKI-11166 > > > > Thanks, > > Caty > > > > On Wed, Sep 24, 2014 at 11:55 AM, Guillaume "Louis-Marie" Delhumeau < > > gdelhumeau(a)xwiki.com> > > >> Hi. > >> > >> I am happy that this topic is coming back. > >> > >> 2014-09-24 10:04 GMT+02:00 vincent(a)massol.net &lt;vincent(a)massol.net&gt;et>: > >> > >> > Hi devs, > >> > > >> > I’ve had a few persons tell me that they don’t like the small arrow in > >> the > >> > top level menu in Flamingo. It seems they either don’t understand the > >> > little triangles and what it’s about (submenu?) or they click on the > >> menu > >> > itself and go to another page when they were expecting some menu to > drop > >> > down, or... > >> > > >> > >> I don't like it neither. It is not consistent with other projects (such > as > >> JIRA). It is not consistent with what we are planning to do about the UI > >> language (see: > >> > >> > http://design.xwiki.org/xwiki/bin/download/Proposal/InterfaceAndContentLang… > >> ). > >> It is harder to use on mobiles, and people are surprised by what occurs > >> when they click on it. > >> > >> > >> > > >> > In addition we’re still missing a solution to easily navigate the wiki > >> > from any page (there’s the ctrl+G solution but this is more like a > >> shortcut > >> > to know and we need something more). > >> > > >> > So here are some ideas: > >> > > >> > * For the top level menu, make it simpler by having the drop down > >> display > >> > when you click anywhere in the menu (the whole width of it) and only > >> > navigate when you double click (there are actually few reasons to need > >> to > >> > navigate with the other idea below so we could also not do the double > >> click > >> > thing) > >> > > >> > >> +1 > >> > >> > >> > > >> > * In the breadcrumb OR in the top level menu OR in both (to be > decided) > >> > use something like this (screenshot taken from IntelliJ IDEA): > >> > > >> > > >> > https://www.evernote.com/shard/s119/sh/20e99ab3-2991-4aa8-a7b5-93088aad4944… > >> > > >> > This means when you click at a given level you get to see all sibling > >> > elements in the wiki for element you’re currently on (document, space, > >> > wiki). > >> > > >> > For example clicking on the “Home” wiki would show: > >> > - A filter box allowing you to type and it would auto suggest as you > >> type, > >> > completing with wiki names > >> > - An icon would be displayed on the left (or on the right) of the > filter > >> > box and if you click on it you’ll go the index page (Wiki Index in > this > >> > case) > >> > - A list of the first 10 wikis (an improvement would be to list first > >> the > >> > wiki that you’ve last navigated to) > >> > > >> > Same would apply for spaces and pages. > >> > > >> > We could even imagine that when you’re on a user profile page, > clicking > >> on > >> > it would display other user pages and the filter would filter on user > >> > pages. Actually we could imagine to when the current page has XObjects > >> in > >> > it, it would be possible to list all other pages in the wiki having > the > >> > same XClass. And if there are several XObjects, then somehow in the UI > >> > allow selecting which one to consider as the filter criteria. > >> > > >> > * Note 1: The breadcrumb is currently not displayed on all pages (it’s > >> not > >> > on the home page for example) and thus if we implement this idea in > the > >> > breadcrumb only then there’s no solution for navigating on the home > >> page. > >> > > >> > >> This is a behaviour that I have put because I thought it was not pretty > to > >> have a useless breadcrumb on the home page. It can be changed. > >> > >> > >> > > >> > * Note 2: If we were to implement this idea on the top level menu, > then > >> we > >> > still need to display the actions too. Several options: > >> > - a) Display the actions first and the navigation list after separated > >> by > >> > a ----- > >> > - b) Have a first entry in the drop down that says “Actions...” and > when > >> > you move the mouse over it a secondary menu with all actions are > >> displayed. > >> > Note that the alternative is possible too: Display the actions and > have > >> a > >> > “Go to..." menu entry. We would just need to choose to display what we > >> > think is the most used default (actions or navigation) > >> > > >> > >> +1 > >> > >> > >> > > >> > WDYT? > >> > > >> > Personally I would do this: > >> > - implement this idea for the breadcrumb > >> > > >> > >> +0, I need to think more about it > >> > >> > >> > - add “Go to wiki...”, “Go to space...", “Go to page..." menu entries > in > >> > the Wiki/Space/Page top level menus > >> > > >> > >> +1 > >> > >> > >> > - expand the menu selection to the whole width for displaying the drop > >> > down (and not just above the small arrow) > >> > > >> > >> +1 > >> > >> > >> > - either support double-click or simply add the possibility to > navigate > >> to > >> > that element in the “Go to xxx...” submenu > >> > > >> > >> +1 > >> > >> > >> > > >> > Thanks > >> > -Vincent > >> > > >> > > >> > _______________________________________________ > >> > devs mailing list > >> > devs(a)xwiki.org > >> > http://lists.xwiki.org/mailman/listinfo/devs > >> > > >> > >> > >> > >> -- > >> Guillaume Delhumeau (gdelhumeau(a)xwiki.com) > >> Research & Development Engineer at XWiki SAS > >> Committer on the XWiki.org project > >> _______________________________________________ > >> devs mailing list > >> devs(a)xwiki.org > >> http://lists.xwiki.org/mailman/listinfo/devs > >> > > > > > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs >

On Thu, Oct 9, 2014 at 3:15 PM, vincent(a)massol.net &lt;vincent(a)massol.net&gt; wrote: "It seems they either don’t understand the little triangles and what it’s about (submenu?) or they click on the menu itself and go to another page when they were expecting some menu to drop down, or.." There is no difference from the "problem" you have mentioned in the OP. The user sees an arrow and clicks on the button to expand the menu, but instead ends up reloading the page (either to edit mode or to view mode, same thing). You will say that he wanted to edit anyway, yes, but maybe he did not want to edit in the default mode, so the user's "intent" (as you defined it in the OP) is still not respected. We either do it one way, or the other, all I ask for is consistency. Do we want to introduce yet another compromise in this young skin? Thanks, Eduard

Hi, In fact, colibri top-menu was better than bootstrap buttons ! :D Why not putting back old ways of interacting ? - re-add display of dropdown menu on hover [1] - re-add underlining on hover of links in menu text Problem I feel is for second item as it seems bootstrap won't easily allow you to hover on something (for dropdown) and click on it (to do something else than show dropdown). Also I suppose there are impacts on mobile version. I don't think the new flamingo way is bad, but visually it looks very similar to colibri (a text + a little triangle), but when you hover nothing happens, and you have no visual clue that something different may happen if you click on the text or on the triangle. For example take the "New" button in Outlook 2007 which is exactly a dropdown button, when I hover on it I see a clear separation between the "New" text, and the arrow, so I can assume that both lead to different results. With the "Add" and "Edit" buttons it's completely different, you see the separation, and on hoovering the color changes (of the text OR of the arrow background). You are prepared to the fact that something different will occur. But doing the same in top menu would clearly not fit expected look&feel of this beautiful skin... BR, Jeremie [1] - http://cameronspear.com/demos/bootstrap-hover-dropdown/ 2014-10-09 16:02 GMT+02:00 vincent(a)massol.net &lt;vincent(a)massol.net&gt;et>:

2014-10-09 17:59 GMT+02:00 vincent(a)massol.net &lt;vincent(a)massol.net&gt;et>: Windows 8 decided to have same behaviors on mobile and desktop, but not sure it was best ... ;-) Particularly because they restricted desktop version because of mobile limitations. Taken the other way, if I had a sensitive screen on my computer, and I could tap on it with my finger, I would do the same error of taping on the text instead of the arrow I suppose, so I'm not sure it's a problem of mobile/desktop. I certainly would never think of double-taping anything inside my browser (particularly because I currently use double-tap to zoom in and out).

On Thu, Oct 9, 2014 at 5:59 PM, vincent(a)massol.net &lt;vincent(a)massol.net&gt; wrote: I think it's not bad to have a slightly different behaviour for desktop and mobile. I don't have much experience with this but I think that we should not ruin desktop experience because it has to work on mobile. If different behaviour is the solution, let's do it. I think the old behaviour with the hover was quite natural, and the fact that bootstrap does not have those buttons by default is because it's mobile first. But, as much as we'd want it, XWiki is not yet mobile first (I would say most of the usage of XWiki today is still desktop, but since I don't have statistics I cannot prove it. I can only use my personal statistic, from my experience and the cases I know). 2 clicks feels completely unnatural on desktop, especially when coming from colibri. I would not want to let Bootstrap kill our UI choices, I think it's the bad reason to say that "we won't do it because bootstrap does not have a default component for it". Thanks, Anca

It's hard to disagree with this and I also agree it would be a pity to have a suboptimal desktop experience because of touch devices :) Remaining questions: * How much work is it to maintain 2 versions of the menus (one for touch devices and one for Desktop)? * Is it natural/ok for users to have the Colibri behavior when using boostrap menus/buttons? Thanks -Vincent On 21 Oct 2014 at 11:00:48, Anca Luca (lucaa@xwiki.com(mailto:lucaa@xwiki.com)) wrote:

Hi, on this topic, I liked this intermediary solution a lot for the desktop mode: - *Nothing happening on hover* - I actually think removing the on hover behavior is great in the top bar - I've seen it generate confusion / frustration in the wild, especially when there's a menu, (for which on hover behavior makes sense) underneath - *Entity name is a link to the wiki home / space home / page* - *Clicking on the arrow button displays the menu* - Maybe the actual issue is to make the arrow more prominent as a clickable button? Thanks, Guillaume On Tue, Oct 21, 2014 at 11:33 AM, vincent(a)massol.net &lt;vincent(a)massol.net&gt; wrote:

Now, regarding the actual problem: We have been doing this for years and years, our users are used to this (clicking on the top entry) and everybody was fine with it. Now we want to perform 2 clicks instead of 1. Why? Where are the jira issues and the user list emails complaining about our current way of doing it? More so, where are the complaints about doing the same thing in Flamingo? There's not even a proposal on this topic, just this brainstorming that has "stormed" right to implementation. Don`t get me wrong, I`m not asking for a proposal or approval of every minor thing we do to the product, but this type of things are very high profile and I don`t like to see (seemingly) random implementations and/org partial or rushed solutions without agreement on the topic. P.S.: Having a better look, it seems that the "non-standard bootstrap dropdown buttons" are actually standard bootstrap dropdown buttons. The only non-standard thing about it is us using them in the top navigation section. Thanks, Eduard On Thu, Oct 9, 2014 at 3:00 PM, Eduard Moraru &lt;enygma2002(a)gmail.com&gt; wrote: