Re: [xwiki-devs] [Brainstorming] Improving the Top level Menu/Breadcrumb/Navigation

21 Oct 2014

Pro tip (via Caty) for the current implementation:
* The menu entry itself is still a link. Left clicking on it is disabled,
but middle clicking still works for opening in a new tab, without using the
"go to page" submenu entry. :)

Regarding Anca's mentions, I obviously agree.

Idea: What about if we just (taking in consideration the details from the
tip above) do some javascript magic to override bootstrap's click handler
for the top menu entries when the client is not a mobile device?
This would not mean implementing 2 versions of the menu, but it would
indeed need special testing (which could also be simulated/forced in our
functional tests with some special request parameter).

Thanks,
Eduard

On Tue, Oct 21, 2014 at 12:33 PM, vincent(a)massol.net &lt;vincent(a)massol.net&gt;
wrote:

...
  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(a)xwiki.com(mailto:
 lucaa(a)xwiki.com)) wrote:

  On Thu, Oct 9, 2014 at 5:59 PM,
vincent(a)massol.net
 wrote:

 >
 >
 >
 >
 >
 > On 9 Oct 2014 at 17:57:46, Jeremie BOUSQUET (  jeremie.bousquet(a)gmail.com
  > (mailto:jeremie.bousquet@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 vincent(a)massol.net :
 > >
 > > >
 > > >
 > > >
 > > >
 > > >
 > > > On 9 Oct 2014 at 14:23:49, Eduard Moraru (enygma2002(a)gmail.com 
(mailto:
  > > > enygma2002(a)gmail.com)) wrote:
 > > >
 > > > > On Thu, Oct 9, 2014 at 3:15 PM, vincent(a)massol.net
 > > > > wrote:
 > > > >
 > > > > >
 > > > > >
 > > > > >
 > > > > >
 > > > > >
 > > > > > On 9 Oct 2014 at 14:02:05, Eduard Moraru (enygma2002(a)gmail.com
 > (mailto:
 > > > > > enygma2002(a)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)  <
  > > > > > > >
valicac(a)gmail.com&gt; 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 <
 > > > > > > > > gdelhumeau(a)xwiki.com&gt; wrote:
 > > > > > > > >
 > > > > > > > >> Hi.
 > > > > > > > >>
 > > > > > > > >> I am happy that this topic is coming back.
 > > > > > > > >>
 > > > > > > > >> 2014-09-24 10:04 GMT+02:00 vincent(a)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/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
 > > > > >
 > > > > _______________________________________________
 > > > > 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
 > > >
 > > _______________________________________________
 > > 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
 >
 _______________________________________________
 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
  _______________________________________________
 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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Re: [xwiki-devs] [Brainstorming] Improving the Top level Menu/Breadcrumb/Navigation