On Tue, Oct 21, 2014 at 11:00 AM, Anca Luca <[email protected]> wrote: > On Thu, Oct 9, 2014 at 5:59 PM, [email protected] <[email protected]> > wrote: > >> >> >> >> >> >> On 9 Oct 2014 at 17:57:46, Jeremie BOUSQUET ([email protected] >> (mailto:[email protected])) 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.
"ruin desktop experience because it has to work on mobile", yep that's called Windows 8 :) > > 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 [email protected] : >> > >> > > >> > > >> > > >> > > >> > > >> > > On 9 Oct 2014 at 14:23:49, Eduard Moraru ([email protected](mailto: >> > > [email protected])) wrote: >> > > >> > > > On Thu, Oct 9, 2014 at 3:15 PM, [email protected] >> > > > wrote: >> > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > On 9 Oct 2014 at 14:02:05, Eduard Moraru ([email protected] >> (mailto: >> > > > > [email protected])) 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) < >> > > > > > > [email protected]> 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 < >> > > > > > > > [email protected]> wrote: >> > > > > > > > >> > > > > > > >> Hi. >> > > > > > > >> >> > > > > > > >> I am happy that this topic is coming back. >> > > > > > > >> >> > > > > > > >> 2014-09-24 10:04 GMT+02:00 [email protected] : >> > > > > > > >> >> > > > > > > >> > 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 >> > > > > > > >> > [email protected] >> > > > > > > >> > http://lists.xwiki.org/mailman/listinfo/devs >> > > > > > > >> > >> > > > > > > >> >> > > > > > > >> >> > > > > > > >> >> > > > > > > >> -- >> > > > > > > >> Guillaume Delhumeau ([email protected]) >> > > > > > > >> Research & Development Engineer at XWiki SAS >> > > > > > > >> Committer on the XWiki.org project >> > > > > > > >> _______________________________________________ >> > > > > > > >> devs mailing list >> > > > > > > >> [email protected] >> > > > > > > >> http://lists.xwiki.org/mailman/listinfo/devs >> > > > > > > >> >> > > > > > > > >> > > > > > > > >> > > > > > > _______________________________________________ >> > > > > > > devs mailing list >> > > > > > > [email protected] >> > > > > > > http://lists.xwiki.org/mailman/listinfo/devs >> > > > > > > >> > > > > > _______________________________________________ >> > > > > > devs mailing list >> > > > > > [email protected] >> > > > > > http://lists.xwiki.org/mailman/listinfo/devs >> > > > > _______________________________________________ >> > > > > devs mailing list >> > > > > [email protected] >> > > > > http://lists.xwiki.org/mailman/listinfo/devs >> > > > > >> > > > _______________________________________________ >> > > > devs mailing list >> > > > [email protected] >> > > > http://lists.xwiki.org/mailman/listinfo/devs >> > > _______________________________________________ >> > > devs mailing list >> > > [email protected] >> > > http://lists.xwiki.org/mailman/listinfo/devs >> > > >> > _______________________________________________ >> > devs mailing list >> > [email protected] >> > http://lists.xwiki.org/mailman/listinfo/devs >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs >> > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
