On Thu, Oct 9, 2014 at 5:59 PM, vinc...@massol.net <vinc...@massol.net> wrote:
> > > > > > On 9 Oct 2014 at 17:57:46, Jeremie BOUSQUET (jeremie.bousq...@gmail.com > (mailto:jeremie.bousq...@gmail.com)) wrote: > > > 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 > > The reason we changed that was for mobiles. We could decide to have > different behaviors on mobile and desktops but not sure it’s best. WDYT? > 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 > > Thanks > -Vincent > > > 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 vinc...@massol.net : > > > > > > > > > > > > > > > > > > > > On 9 Oct 2014 at 14:23:49, Eduard Moraru (enygma2...@gmail.com(mailto: > > > enygma2...@gmail.com)) wrote: > > > > > > > On Thu, Oct 9, 2014 at 3:15 PM, vinc...@massol.net > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 9 Oct 2014 at 14:02:05, Eduard Moraru (enygma2...@gmail.com > (mailto: > > > > > enygma2...@gmail.com)) 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. > > > > > > > > > > There’s a difference. For the Edit/Add button click the button > will do > > > > > what the user wants. Click the arrow is only for advanced featurs. > > > > > > > > > > > > > "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? > > > > > > The problem I saw is that users were not clicking the arrow but the > main > > > button part (thus navigating instead of having the main options). > > > > > > What we want is that it’s the simplest possible for the user for his > use > > > case at hand: > > > - When I click Edit or Add (not the arrow, the button) it’s the > simplest > > > possible. Edit will choose the good default mode and add will add a > page > > > - When I click the wiki/space/page button (not the arrow) I want the > > > actions to be displayed rather than the navigation since navigation is > a > > > secondary use case for these buttons > > > > > > At least that’s how I view it. > > > > > > Forcing the user to have 2 clicks to do the main action on a button > would > > > be a pity. > > > > > > Now you’re going to say that we could keep the arrow for the > > > wiki/space/page buttons to navigate. We could, but it doesn’t feel > natural. > > > > > > What do you suggest? > > > > > > Thanks > > > -Vincent > > > > > > > Thanks, > > > > Eduard > > > > > > > > > > > > > > Thanks > > > > > -Vincent > > > > > > > > > > > Thanks, > > > > > > Eduard > > > > > > > > > > > > On Fri, Oct 3, 2014 at 4:21 PM, Ecaterina Moraru (Valica) > > > wrote: > > > > > > > > > > > > > On Wed, Sep 24, 2014 at 5:25 PM, Ecaterina Moraru (Valica) < > > > > > > > vali...@gmail.com> wrote: > > > > > > > > > > > > > > > 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 < > > > > > > > > gdelhum...@xwiki.com> wrote: > > > > > > > > > > > > > > > >> Hi. > > > > > > > >> > > > > > > > >> I am happy that this topic is coming back. > > > > > > > >> > > > > > > > >> 2014-09-24 10:04 GMT+02:00 vinc...@massol.net : > > > > > > > >> > > > > > > > >> > 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/InterfaceAndContentLanguageSeparation/1.1Preview.png > > > > > > > >> ). > > > > > > > >> 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/aa6d10a258c9c4c7c69ede4fd45a1254 > > > > > > > >> > > > > > > > > >> > 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@xwiki.org > > > > > > > >> > http://lists.xwiki.org/mailman/listinfo/devs > > > > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> -- > > > > > > > >> Guillaume Delhumeau (gdelhum...@xwiki.com) > > > > > > > >> Research & Development Engineer at XWiki SAS > > > > > > > >> Committer on the XWiki.org project > > > > > > > >> _______________________________________________ > > > > > > > >> devs mailing list > > > > > > > >> devs@xwiki.org > > > > > > > >> http://lists.xwiki.org/mailman/listinfo/devs > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > devs mailing list > > > > > > > devs@xwiki.org > > > > > > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > > > > > > > > > _______________________________________________ > > > > > > devs mailing list > > > > > > devs@xwiki.org > > > > > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > _______________________________________________ > > > > > devs mailing list > > > > > devs@xwiki.org > > > > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > > > > > _______________________________________________ > > > > devs mailing list > > > > devs@xwiki.org > > > > http://lists.xwiki.org/mailman/listinfo/devs > > > _______________________________________________ > > > devs mailing list > > > devs@xwiki.org > > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > _______________________________________________ > > devs mailing list > > devs@xwiki.org > > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ > devs mailing list > devs@xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
