On 9 Oct 2014 at 18:15:23, Jeremie BOUSQUET
([email protected](mailto:[email protected])) wrote:
> 2014-10-09 17:59 GMT+02:00 [email protected] :
>
> >
> >
> >
> >
> >
> > 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?
> >
>
> 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.
This is exactly what we fixed for the wiki/space/page menus so I’m glad you
like it :)
> I certainly would never think of double-taping anything inside my browser
> (particularly because I currently use double-tap to zoom in and out).
We don’t do that…
Thanks
-Vincent
> > 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
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
