[Brainstorming] Improving the Top level Menu/Breadcrumb/Navigation

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

[Brainstorming] Improving the Top level Menu/Breadcrumb/Navigation

vmassol
Administrator
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...

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)

* 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.

* 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)

WDYT?

Personally I would do this:
- implement this idea for the breadcrumb
- add “Go to wiki...”, “Go to space...", “Go to page..." menu entries in the Wiki/Space/Page top level menus
- expand the menu selection to the whole width for displaying the drop down (and not just above the small arrow)
- either support double-click or simply add the possibility to navigate to that element in the “Go to xxx...” submenu

Thanks
-Vincent


_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

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

Jean SIMARD
Very interesting reflexion.  See my comments below.

On Wed, Sep 24, 2014 at 10:04:02AM +0200, [hidden email] wrote:

> 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...
>
> 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)
>
> * 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.
>
> * 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)
>
> WDYT?
>
> Personally I would do this:
> - implement this idea for the breadcrumb
I like this idea of IntelliJ IDEA.  With a filter, I think this would be a nice
a solution.  2 small cons however (but I think they can be improved):
- No breadcrumb on each page.  You mentionned it for home page, it's also the
  case in edit mode I think (sometimes, I like opening another tab from edit
  mode, I don't know if I'm the only one)
- In one of our project, people told us they don't "see" breadcrumb.  And
  indeed, it's not as much highlighted than the top level menu.  However, I talk
  about the Colibri skin and in my opinion, the visibility of the breadcrumb has
  been improved in Flamingo (but still discrete which is good for the use but
  may be a problem if it becomes a major way of navigation).
> - add “Go to wiki...”, “Go to space...", “Go to page..." menu entries in the Wiki/Space/Page top level menus
This could be a nice solution instead of double-click.
> - expand the menu selection to the whole width for displaying the drop down (and not just above the small arrow)
Indeed, I never has the problem between clicking on the big button or on the
triangle because I'm use to this kind of UI.  But in a way, my brain tells me
that this is not very intuitive.  Removing these triangles sounds like a good
idea.
> - either support double-click or simply add the possibility to navigate to that element in the “Go to xxx...” submenu
I don't really like the idea of double-click since it's not a common action in a
web browser.
>
> Thanks
> -Vincent
>
>
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs

--
Jean Simard
[hidden email]
Research engineer at XWiki SAS
http://www.xwiki.com
Committer on the XWiki.org project
http://www.xwiki.org
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

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

Guillaume "Louis-Marie" Delhumeau
In reply to this post by vmassol
Hi.

I am happy that this topic is coming back.

2014-09-24 10:04 GMT+02:00 [hidden email] <[hidden email]>:

> 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
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>



--
Guillaume Delhumeau ([hidden email])
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

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

Ecaterina Moraru (Valica)
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 <
[hidden email]> wrote:

> Hi.
>
> I am happy that this topic is coming back.
>
> 2014-09-24 10:04 GMT+02:00 [hidden email] <[hidden email]>:
>
> > 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
> > [hidden email]
> > http://lists.xwiki.org/mailman/listinfo/devs
> >
>
>
>
> --
> Guillaume Delhumeau ([hidden email])
> Research & Development Engineer at XWiki SAS
> Committer on the XWiki.org project
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

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

Ecaterina Moraru (Valica)
On Wed, Sep 24, 2014 at 5:25 PM, Ecaterina Moraru (Valica) <
[hidden email]> 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 <
> [hidden email]> wrote:
>
>> Hi.
>>
>> I am happy that this topic is coming back.
>>
>> 2014-09-24 10:04 GMT+02:00 [hidden email] <[hidden email]>:
>>
>> > 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
>> > [hidden email]
>> > http://lists.xwiki.org/mailman/listinfo/devs
>> >
>>
>>
>>
>> --
>> Guillaume Delhumeau ([hidden email])
>> Research & Development Engineer at XWiki SAS
>> Committer on the XWiki.org project
>> _______________________________________________
>> devs mailing list
>> [hidden email]
>> http://lists.xwiki.org/mailman/listinfo/devs
>>
>
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

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

Eduard Moraru
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) <[hidden email]
> wrote:

> On Wed, Sep 24, 2014 at 5:25 PM, Ecaterina Moraru (Valica) <
> [hidden email]> 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 <
> > [hidden email]> wrote:
> >
> >> Hi.
> >>
> >> I am happy that this topic is coming back.
> >>
> >> 2014-09-24 10:04 GMT+02:00 [hidden email] <[hidden email]>:
> >>
> >> > 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
> >> > [hidden email]
> >> > http://lists.xwiki.org/mailman/listinfo/devs
> >> >
> >>
> >>
> >>
> >> --
> >> Guillaume Delhumeau ([hidden email])
> >> Research & Development Engineer at XWiki SAS
> >> Committer on the XWiki.org project
> >> _______________________________________________
> >> devs mailing list
> >> [hidden email]
> >> http://lists.xwiki.org/mailman/listinfo/devs
> >>
> >
> >
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

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

vmassol
Administrator
 




On 9 Oct 2014 at 14:02:05, Eduard Moraru ([hidden email](mailto:[hidden email])) 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.

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) <
> > [hidden email]> 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 <
> > > [hidden email]> wrote:
> > >
> > >> Hi.
> > >>
> > >> I am happy that this topic is coming back.
> > >>
> > >> 2014-09-24 10:04 GMT+02:00 [hidden email] :
> > >>
> > >> > 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
> > >> > [hidden email]
> > >> > http://lists.xwiki.org/mailman/listinfo/devs
> > >> >
> > >>
> > >>
> > >>
> > >> --
> > >> Guillaume Delhumeau ([hidden email])
> > >> Research & Development Engineer at XWiki SAS
> > >> Committer on the XWiki.org project
> > >> _______________________________________________
> > >> devs mailing list
> > >> [hidden email]
> > >> http://lists.xwiki.org/mailman/listinfo/devs
> > >>
> > >
> > >
> > _______________________________________________
> > devs mailing list
> > [hidden email]
> > http://lists.xwiki.org/mailman/listinfo/devs
> >
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

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

Eduard Moraru
In reply to this post by Eduard Moraru
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 <[hidden email]> 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) <
> [hidden email]> wrote:
>
>> On Wed, Sep 24, 2014 at 5:25 PM, Ecaterina Moraru (Valica) <
>> [hidden email]> 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 <
>> > [hidden email]> wrote:
>> >
>> >> Hi.
>> >>
>> >> I am happy that this topic is coming back.
>> >>
>> >> 2014-09-24 10:04 GMT+02:00 [hidden email] <[hidden email]>:
>> >>
>> >> > 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
>> >> > [hidden email]
>> >> > http://lists.xwiki.org/mailman/listinfo/devs
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Guillaume Delhumeau ([hidden email])
>> >> Research & Development Engineer at XWiki SAS
>> >> Committer on the XWiki.org project
>> >> _______________________________________________
>> >> devs mailing list
>> >> [hidden email]
>> >> http://lists.xwiki.org/mailman/listinfo/devs
>> >>
>> >
>> >
>> _______________________________________________
>> devs mailing list
>> [hidden email]
>> http://lists.xwiki.org/mailman/listinfo/devs
>>
>
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

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

Eduard Moraru
In reply to this post by vmassol
On Thu, Oct 9, 2014 at 3:15 PM, [hidden email] <[hidden email]>
wrote:

>
>
>
>
>
> On 9 Oct 2014 at 14:02:05, Eduard Moraru ([hidden email](mailto:
> [hidden email])) 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?

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) <
> > > [hidden email]> 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 <
> > > > [hidden email]> wrote:
> > > >
> > > >> Hi.
> > > >>
> > > >> I am happy that this topic is coming back.
> > > >>
> > > >> 2014-09-24 10:04 GMT+02:00 [hidden email] :
> > > >>
> > > >> > 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
> > > >> > [hidden email]
> > > >> > http://lists.xwiki.org/mailman/listinfo/devs
> > > >> >
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> Guillaume Delhumeau ([hidden email])
> > > >> Research & Development Engineer at XWiki SAS
> > > >> Committer on the XWiki.org project
> > > >> _______________________________________________
> > > >> devs mailing list
> > > >> [hidden email]
> > > >> http://lists.xwiki.org/mailman/listinfo/devs
> > > >>
> > > >
> > > >
> > > _______________________________________________
> > > devs mailing list
> > > [hidden email]
> > > http://lists.xwiki.org/mailman/listinfo/devs
> > >
> > _______________________________________________
> > devs mailing list
> > [hidden email]
> > http://lists.xwiki.org/mailman/listinfo/devs
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

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

vmassol
Administrator
 




On 9 Oct 2014 at 14:23:49, Eduard Moraru ([hidden email](mailto:[hidden email])) wrote:

> On Thu, Oct 9, 2014 at 3:15 PM, [hidden email]  
> wrote:
>  
> >
> >
> >
> >
> >
> > On 9 Oct 2014 at 14:02:05, Eduard Moraru ([hidden email](mailto:
> > [hidden email])) 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) <
> > > > [hidden email]> 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 <
> > > > > [hidden email]> wrote:
> > > > >
> > > > >> Hi.
> > > > >>
> > > > >> I am happy that this topic is coming back.
> > > > >>
> > > > >> 2014-09-24 10:04 GMT+02:00 [hidden email] :
> > > > >>
> > > > >> > 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
> > > > >> > [hidden email]
> > > > >> > http://lists.xwiki.org/mailman/listinfo/devs
> > > > >> >
> > > > >>
> > > > >>
> > > > >>
> > > > >> --
> > > > >> Guillaume Delhumeau ([hidden email])
> > > > >> Research & Development Engineer at XWiki SAS
> > > > >> Committer on the XWiki.org project
> > > > >> _______________________________________________
> > > > >> devs mailing list
> > > > >> [hidden email]
> > > > >> http://lists.xwiki.org/mailman/listinfo/devs
> > > > >>
> > > > >
> > > > >
> > > > _______________________________________________
> > > > devs mailing list
> > > > [hidden email]
> > > > http://lists.xwiki.org/mailman/listinfo/devs
> > > >
> > > _______________________________________________
> > > devs mailing list
> > > [hidden email]
> > > http://lists.xwiki.org/mailman/listinfo/devs
> > _______________________________________________
> > devs mailing list
> > [hidden email]
> > http://lists.xwiki.org/mailman/listinfo/devs
> >
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

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

jerem
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 [hidden email] <[hidden email]>:

>
>
>
>
>
> On 9 Oct 2014 at 14:23:49, Eduard Moraru ([hidden email](mailto:
> [hidden email])) wrote:
>
> > On Thu, Oct 9, 2014 at 3:15 PM, [hidden email]
> > wrote:
> >
> > >
> > >
> > >
> > >
> > >
> > > On 9 Oct 2014 at 14:02:05, Eduard Moraru ([hidden email](mailto:
> > > [hidden email])) 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) <
> > > > > [hidden email]> 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 <
> > > > > > [hidden email]> wrote:
> > > > > >
> > > > > >> Hi.
> > > > > >>
> > > > > >> I am happy that this topic is coming back.
> > > > > >>
> > > > > >> 2014-09-24 10:04 GMT+02:00 [hidden email] :
> > > > > >>
> > > > > >> > 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
> > > > > >> > [hidden email]
> > > > > >> > http://lists.xwiki.org/mailman/listinfo/devs
> > > > > >> >
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> --
> > > > > >> Guillaume Delhumeau ([hidden email])
> > > > > >> Research & Development Engineer at XWiki SAS
> > > > > >> Committer on the XWiki.org project
> > > > > >> _______________________________________________
> > > > > >> devs mailing list
> > > > > >> [hidden email]
> > > > > >> http://lists.xwiki.org/mailman/listinfo/devs
> > > > > >>
> > > > > >
> > > > > >
> > > > > _______________________________________________
> > > > > devs mailing list
> > > > > [hidden email]
> > > > > http://lists.xwiki.org/mailman/listinfo/devs
> > > > >
> > > > _______________________________________________
> > > > devs mailing list
> > > > [hidden email]
> > > > http://lists.xwiki.org/mailman/listinfo/devs
> > > _______________________________________________
> > > devs mailing list
> > > [hidden email]
> > > http://lists.xwiki.org/mailman/listinfo/devs
> > >
> > _______________________________________________
> > devs mailing list
> > [hidden email]
> > http://lists.xwiki.org/mailman/listinfo/devs
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

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

vmassol
Administrator
 




On 9 Oct 2014 at 17:57:46, Jeremie BOUSQUET ([hidden email](mailto:[hidden email])) 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?

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 [hidden email] :
>  
> >
> >
> >
> >
> >
> > On 9 Oct 2014 at 14:23:49, Eduard Moraru ([hidden email](mailto:
> > [hidden email])) wrote:
> >
> > > On Thu, Oct 9, 2014 at 3:15 PM, [hidden email]
> > > wrote:
> > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On 9 Oct 2014 at 14:02:05, Eduard Moraru ([hidden email](mailto:
> > > > [hidden email])) 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) <
> > > > > > [hidden email]> 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 <
> > > > > > > [hidden email]> wrote:
> > > > > > >
> > > > > > >> Hi.
> > > > > > >>
> > > > > > >> I am happy that this topic is coming back.
> > > > > > >>
> > > > > > >> 2014-09-24 10:04 GMT+02:00 [hidden email] :
> > > > > > >>
> > > > > > >> > 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
> > > > > > >> > [hidden email]
> > > > > > >> > http://lists.xwiki.org/mailman/listinfo/devs
> > > > > > >> >
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >> --
> > > > > > >> Guillaume Delhumeau ([hidden email])
> > > > > > >> Research & Development Engineer at XWiki SAS
> > > > > > >> Committer on the XWiki.org project
> > > > > > >> _______________________________________________
> > > > > > >> devs mailing list
> > > > > > >> [hidden email]
> > > > > > >> http://lists.xwiki.org/mailman/listinfo/devs
> > > > > > >>
> > > > > > >
> > > > > > >
> > > > > > _______________________________________________
> > > > > > devs mailing list
> > > > > > [hidden email]
> > > > > > http://lists.xwiki.org/mailman/listinfo/devs
> > > > > >
> > > > > _______________________________________________
> > > > > devs mailing list
> > > > > [hidden email]
> > > > > http://lists.xwiki.org/mailman/listinfo/devs
> > > > _______________________________________________
> > > > devs mailing list
> > > > [hidden email]
> > > > http://lists.xwiki.org/mailman/listinfo/devs
> > > >
> > > _______________________________________________
> > > devs mailing list
> > > [hidden email]
> > > http://lists.xwiki.org/mailman/listinfo/devs
> > _______________________________________________
> > devs mailing list
> > [hidden email]
> > http://lists.xwiki.org/mailman/listinfo/devs
> >
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

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

jerem
2014-10-09 17:59 GMT+02:00 [hidden email] <[hidden email]>:

>
>
>
>
>
> On 9 Oct 2014 at 17:57:46, Jeremie BOUSQUET ([hidden email]
> (mailto:[hidden email])) 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.
I certainly would never think of double-taping anything inside my browser
(particularly because I currently use double-tap to zoom in and out).



>
> 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 [hidden email] :
> >
> > >
> > >
> > >
> > >
> > >
> > > On 9 Oct 2014 at 14:23:49, Eduard Moraru ([hidden email](mailto:
> > > [hidden email])) wrote:
> > >
> > > > On Thu, Oct 9, 2014 at 3:15 PM, [hidden email]
> > > > wrote:
> > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On 9 Oct 2014 at 14:02:05, Eduard Moraru ([hidden email]
> (mailto:
> > > > > [hidden email])) 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) <
> > > > > > > [hidden email]> 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 <
> > > > > > > > [hidden email]> wrote:
> > > > > > > >
> > > > > > > >> Hi.
> > > > > > > >>
> > > > > > > >> I am happy that this topic is coming back.
> > > > > > > >>
> > > > > > > >> 2014-09-24 10:04 GMT+02:00 [hidden email] :
> > > > > > > >>
> > > > > > > >> > 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
> > > > > > > >> > [hidden email]
> > > > > > > >> > http://lists.xwiki.org/mailman/listinfo/devs
> > > > > > > >> >
> > > > > > > >>
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> --
> > > > > > > >> Guillaume Delhumeau ([hidden email])
> > > > > > > >> Research & Development Engineer at XWiki SAS
> > > > > > > >> Committer on the XWiki.org project
> > > > > > > >> _______________________________________________
> > > > > > > >> devs mailing list
> > > > > > > >> [hidden email]
> > > > > > > >> http://lists.xwiki.org/mailman/listinfo/devs
> > > > > > > >>
> > > > > > > >
> > > > > > > >
> > > > > > > _______________________________________________
> > > > > > > devs mailing list
> > > > > > > [hidden email]
> > > > > > > http://lists.xwiki.org/mailman/listinfo/devs
> > > > > > >
> > > > > > _______________________________________________
> > > > > > devs mailing list
> > > > > > [hidden email]
> > > > > > http://lists.xwiki.org/mailman/listinfo/devs
> > > > > _______________________________________________
> > > > > devs mailing list
> > > > > [hidden email]
> > > > > http://lists.xwiki.org/mailman/listinfo/devs
> > > > >
> > > > _______________________________________________
> > > > devs mailing list
> > > > [hidden email]
> > > > http://lists.xwiki.org/mailman/listinfo/devs
> > > _______________________________________________
> > > devs mailing list
> > > [hidden email]
> > > http://lists.xwiki.org/mailman/listinfo/devs
> > >
> > _______________________________________________
> > devs mailing list
> > [hidden email]
> > http://lists.xwiki.org/mailman/listinfo/devs
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

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

vmassol
Administrator
 




On 9 Oct 2014 at 18:15:23, Jeremie BOUSQUET ([hidden email](mailto:[hidden email])) wrote:

> 2014-10-09 17:59 GMT+02:00 [hidden email] :
>  
> >
> >
> >
> >
> >
> > On 9 Oct 2014 at 17:57:46, Jeremie BOUSQUET ([hidden email]
> > (mailto:[hidden email])) 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 [hidden email] :
> > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On 9 Oct 2014 at 14:23:49, Eduard Moraru ([hidden email](mailto:
> > > > [hidden email])) wrote:
> > > >
> > > > > On Thu, Oct 9, 2014 at 3:15 PM, [hidden email]
> > > > > wrote:
> > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On 9 Oct 2014 at 14:02:05, Eduard Moraru ([hidden email]
> > (mailto:
> > > > > > [hidden email])) 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) <
> > > > > > > > [hidden email]> 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 <
> > > > > > > > > [hidden email]> wrote:
> > > > > > > > >
> > > > > > > > >> Hi.
> > > > > > > > >>
> > > > > > > > >> I am happy that this topic is coming back.
> > > > > > > > >>
> > > > > > > > >> 2014-09-24 10:04 GMT+02:00 [hidden email] :
> > > > > > > > >>
> > > > > > > > >> > 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
> > > > > > > > >> > [hidden email]
> > > > > > > > >> > http://lists.xwiki.org/mailman/listinfo/devs
> > > > > > > > >> >
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >> --
> > > > > > > > >> Guillaume Delhumeau ([hidden email])
> > > > > > > > >> Research & Development Engineer at XWiki SAS
> > > > > > > > >> Committer on the XWiki.org project
> > > > > > > > >> _______________________________________________
> > > > > > > > >> devs mailing list
> > > > > > > > >> [hidden email]
> > > > > > > > >> http://lists.xwiki.org/mailman/listinfo/devs
> > > > > > > > >>
> > > > > > > > >
> > > > > > > > >
> > > > > > > > _______________________________________________
> > > > > > > > devs mailing list
> > > > > > > > [hidden email]
> > > > > > > > http://lists.xwiki.org/mailman/listinfo/devs
> > > > > > > >
> > > > > > > _______________________________________________
> > > > > > > devs mailing list
> > > > > > > [hidden email]
> > > > > > > http://lists.xwiki.org/mailman/listinfo/devs
> > > > > > _______________________________________________
> > > > > > devs mailing list
> > > > > > [hidden email]
> > > > > > http://lists.xwiki.org/mailman/listinfo/devs
> > > > > >
> > > > > _______________________________________________
> > > > > devs mailing list
> > > > > [hidden email]
> > > > > http://lists.xwiki.org/mailman/listinfo/devs
> > > > _______________________________________________
> > > > devs mailing list
> > > > [hidden email]
> > > > http://lists.xwiki.org/mailman/listinfo/devs
> > > >
> > > _______________________________________________
> > > devs mailing list
> > > [hidden email]
> > > http://lists.xwiki.org/mailman/listinfo/devs
> > _______________________________________________
> > devs mailing list
> > [hidden email]
> > http://lists.xwiki.org/mailman/listinfo/devs
> >
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

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

Anca Luca
In reply to this post by vmassol
On Thu, Oct 9, 2014 at 5:59 PM, [hidden email] <[hidden email]>
wrote:

>
>
>
>
>
> On 9 Oct 2014 at 17:57:46, Jeremie BOUSQUET ([hidden email]
> (mailto:[hidden email])) 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 [hidden email] :
> >
> > >
> > >
> > >
> > >
> > >
> > > On 9 Oct 2014 at 14:23:49, Eduard Moraru ([hidden email](mailto:
> > > [hidden email])) wrote:
> > >
> > > > On Thu, Oct 9, 2014 at 3:15 PM, [hidden email]
> > > > wrote:
> > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On 9 Oct 2014 at 14:02:05, Eduard Moraru ([hidden email]
> (mailto:
> > > > > [hidden email])) 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) <
> > > > > > > [hidden email]> 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 <
> > > > > > > > [hidden email]> wrote:
> > > > > > > >
> > > > > > > >> Hi.
> > > > > > > >>
> > > > > > > >> I am happy that this topic is coming back.
> > > > > > > >>
> > > > > > > >> 2014-09-24 10:04 GMT+02:00 [hidden email] :
> > > > > > > >>
> > > > > > > >> > 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
> > > > > > > >> > [hidden email]
> > > > > > > >> > http://lists.xwiki.org/mailman/listinfo/devs
> > > > > > > >> >
> > > > > > > >>
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> --
> > > > > > > >> Guillaume Delhumeau ([hidden email])
> > > > > > > >> Research & Development Engineer at XWiki SAS
> > > > > > > >> Committer on the XWiki.org project
> > > > > > > >> _______________________________________________
> > > > > > > >> devs mailing list
> > > > > > > >> [hidden email]
> > > > > > > >> http://lists.xwiki.org/mailman/listinfo/devs
> > > > > > > >>
> > > > > > > >
> > > > > > > >
> > > > > > > _______________________________________________
> > > > > > > devs mailing list
> > > > > > > [hidden email]
> > > > > > > http://lists.xwiki.org/mailman/listinfo/devs
> > > > > > >
> > > > > > _______________________________________________
> > > > > > devs mailing list
> > > > > > [hidden email]
> > > > > > http://lists.xwiki.org/mailman/listinfo/devs
> > > > > _______________________________________________
> > > > > devs mailing list
> > > > > [hidden email]
> > > > > http://lists.xwiki.org/mailman/listinfo/devs
> > > > >
> > > > _______________________________________________
> > > > devs mailing list
> > > > [hidden email]
> > > > http://lists.xwiki.org/mailman/listinfo/devs
> > > _______________________________________________
> > > devs mailing list
> > > [hidden email]
> > > http://lists.xwiki.org/mailman/listinfo/devs
> > >
> > _______________________________________________
> > devs mailing list
> > [hidden email]
> > http://lists.xwiki.org/mailman/listinfo/devs
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

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

Thomas Mortagne
Administrator
On Tue, Oct 21, 2014 at 11:00 AM, Anca Luca <[hidden email]> wrote:

> On Thu, Oct 9, 2014 at 5:59 PM, [hidden email] <[hidden email]>
> wrote:
>
>>
>>
>>
>>
>>
>> On 9 Oct 2014 at 17:57:46, Jeremie BOUSQUET ([hidden email]
>> (mailto:[hidden email])) 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 [hidden email] :
>> >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > On 9 Oct 2014 at 14:23:49, Eduard Moraru ([hidden email](mailto:
>> > > [hidden email])) wrote:
>> > >
>> > > > On Thu, Oct 9, 2014 at 3:15 PM, [hidden email]
>> > > > wrote:
>> > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > > On 9 Oct 2014 at 14:02:05, Eduard Moraru ([hidden email]
>> (mailto:
>> > > > > [hidden email])) 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) <
>> > > > > > > [hidden email]> 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 <
>> > > > > > > > [hidden email]> wrote:
>> > > > > > > >
>> > > > > > > >> Hi.
>> > > > > > > >>
>> > > > > > > >> I am happy that this topic is coming back.
>> > > > > > > >>
>> > > > > > > >> 2014-09-24 10:04 GMT+02:00 [hidden email] :
>> > > > > > > >>
>> > > > > > > >> > 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
>> > > > > > > >> > [hidden email]
>> > > > > > > >> > http://lists.xwiki.org/mailman/listinfo/devs
>> > > > > > > >> >
>> > > > > > > >>
>> > > > > > > >>
>> > > > > > > >>
>> > > > > > > >> --
>> > > > > > > >> Guillaume Delhumeau ([hidden email])
>> > > > > > > >> Research & Development Engineer at XWiki SAS
>> > > > > > > >> Committer on the XWiki.org project
>> > > > > > > >> _______________________________________________
>> > > > > > > >> devs mailing list
>> > > > > > > >> [hidden email]
>> > > > > > > >> http://lists.xwiki.org/mailman/listinfo/devs
>> > > > > > > >>
>> > > > > > > >
>> > > > > > > >
>> > > > > > > _______________________________________________
>> > > > > > > devs mailing list
>> > > > > > > [hidden email]
>> > > > > > > http://lists.xwiki.org/mailman/listinfo/devs
>> > > > > > >
>> > > > > > _______________________________________________
>> > > > > > devs mailing list
>> > > > > > [hidden email]
>> > > > > > http://lists.xwiki.org/mailman/listinfo/devs
>> > > > > _______________________________________________
>> > > > > devs mailing list
>> > > > > [hidden email]
>> > > > > http://lists.xwiki.org/mailman/listinfo/devs
>> > > > >
>> > > > _______________________________________________
>> > > > devs mailing list
>> > > > [hidden email]
>> > > > http://lists.xwiki.org/mailman/listinfo/devs
>> > > _______________________________________________
>> > > devs mailing list
>> > > [hidden email]
>> > > http://lists.xwiki.org/mailman/listinfo/devs
>> > >
>> > _______________________________________________
>> > devs mailing list
>> > [hidden email]
>> > http://lists.xwiki.org/mailman/listinfo/devs
>> _______________________________________________
>> devs mailing list
>> [hidden email]
>> http://lists.xwiki.org/mailman/listinfo/devs
>>
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs



--
Thomas Mortagne
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

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

vmassol
Administrator
In reply to this post by Anca Luca
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 ([hidden email](mailto:[hidden email])) wrote:

> On Thu, Oct 9, 2014 at 5:59 PM, [hidden email]
> wrote:
>
> >
> >
> >
> >
> >
> > On 9 Oct 2014 at 17:57:46, Jeremie BOUSQUET ([hidden email]
> > (mailto:[hidden email])) 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 [hidden email] :
> > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On 9 Oct 2014 at 14:23:49, Eduard Moraru ([hidden email](mailto:
> > > > [hidden email])) wrote:
> > > >
> > > > > On Thu, Oct 9, 2014 at 3:15 PM, [hidden email]
> > > > > wrote:
> > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On 9 Oct 2014 at 14:02:05, Eduard Moraru ([hidden email]
> > (mailto:
> > > > > > [hidden email])) 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) <
> > > > > > > > [hidden email]> 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 <
> > > > > > > > > [hidden email]> wrote:
> > > > > > > > >
> > > > > > > > >> Hi.
> > > > > > > > >>
> > > > > > > > >> I am happy that this topic is coming back.
> > > > > > > > >>
> > > > > > > > >> 2014-09-24 10:04 GMT+02:00 [hidden email] :
> > > > > > > > >>
> > > > > > > > >> > 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
> > > > > > > > >> > [hidden email]
> > > > > > > > >> > http://lists.xwiki.org/mailman/listinfo/devs
> > > > > > > > >> >
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >> --
> > > > > > > > >> Guillaume Delhumeau ([hidden email])
> > > > > > > > >> Research & Development Engineer at XWiki SAS
> > > > > > > > >> Committer on the XWiki.org project
> > > > > > > > >> _______________________________________________
> > > > > > > > >> devs mailing list
> > > > > > > > >> [hidden email]
> > > > > > > > >> http://lists.xwiki.org/mailman/listinfo/devs
> > > > > > > > >>
> > > > > > > > >
> > > > > > > > >
> > > > > > > > _______________________________________________
> > > > > > > > devs mailing list
> > > > > > > > [hidden email]
> > > > > > > > http://lists.xwiki.org/mailman/listinfo/devs
> > > > > > > >
> > > > > > > _______________________________________________
> > > > > > > devs mailing list
> > > > > > > [hidden email]
> > > > > > > http://lists.xwiki.org/mailman/listinfo/devs
> > > > > > _______________________________________________
> > > > > > devs mailing list
> > > > > > [hidden email]
> > > > > > http://lists.xwiki.org/mailman/listinfo/devs
> > > > > >
> > > > > _______________________________________________
> > > > > devs mailing list
> > > > > [hidden email]
> > > > > http://lists.xwiki.org/mailman/listinfo/devs
> > > > _______________________________________________
> > > > devs mailing list
> > > > [hidden email]
> > > > http://lists.xwiki.org/mailman/listinfo/devs
> > > >
> > > _______________________________________________
> > > devs mailing list
> > > [hidden email]
> > > http://lists.xwiki.org/mailman/listinfo/devs
> > _______________________________________________
> > devs mailing list
> > [hidden email]
> > http://lists.xwiki.org/mailman/listinfo/devs
> >
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

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

Eduard Moraru
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, [hidden email] <[hidden email]>
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 ([hidden email](mailto:
> [hidden email])) wrote:
>
> > On Thu, Oct 9, 2014 at 5:59 PM, [hidden email]
> > wrote:
> >
> > >
> > >
> > >
> > >
> > >
> > > On 9 Oct 2014 at 17:57:46, Jeremie BOUSQUET (
> [hidden email]
> > > (mailto:[hidden email])) 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 [hidden email] :
> > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On 9 Oct 2014 at 14:23:49, Eduard Moraru ([hidden email]
> (mailto:
> > > > > [hidden email])) wrote:
> > > > >
> > > > > > On Thu, Oct 9, 2014 at 3:15 PM, [hidden email]
> > > > > > wrote:
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On 9 Oct 2014 at 14:02:05, Eduard Moraru ([hidden email]
> > > (mailto:
> > > > > > > [hidden email])) 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)
> <
> > > > > > > > > [hidden email]> 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 <
> > > > > > > > > > [hidden email]> wrote:
> > > > > > > > > >
> > > > > > > > > >> Hi.
> > > > > > > > > >>
> > > > > > > > > >> I am happy that this topic is coming back.
> > > > > > > > > >>
> > > > > > > > > >> 2014-09-24 10:04 GMT+02:00 [hidden email] :
> > > > > > > > > >>
> > > > > > > > > >> > 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
> > > > > > > > > >> > [hidden email]
> > > > > > > > > >> > http://lists.xwiki.org/mailman/listinfo/devs
> > > > > > > > > >> >
> > > > > > > > > >>
> > > > > > > > > >>
> > > > > > > > > >>
> > > > > > > > > >> --
> > > > > > > > > >> Guillaume Delhumeau ([hidden email])
> > > > > > > > > >> Research & Development Engineer at XWiki SAS
> > > > > > > > > >> Committer on the XWiki.org project
> > > > > > > > > >> _______________________________________________
> > > > > > > > > >> devs mailing list
> > > > > > > > > >> [hidden email]
> > > > > > > > > >> http://lists.xwiki.org/mailman/listinfo/devs
> > > > > > > > > >>
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > _______________________________________________
> > > > > > > > > devs mailing list
> > > > > > > > > [hidden email]
> > > > > > > > > http://lists.xwiki.org/mailman/listinfo/devs
> > > > > > > > >
> > > > > > > > _______________________________________________
> > > > > > > > devs mailing list
> > > > > > > > [hidden email]
> > > > > > > > http://lists.xwiki.org/mailman/listinfo/devs
> > > > > > > _______________________________________________
> > > > > > > devs mailing list
> > > > > > > [hidden email]
> > > > > > > http://lists.xwiki.org/mailman/listinfo/devs
> > > > > > >
> > > > > > _______________________________________________
> > > > > > devs mailing list
> > > > > > [hidden email]
> > > > > > http://lists.xwiki.org/mailman/listinfo/devs
> > > > > _______________________________________________
> > > > > devs mailing list
> > > > > [hidden email]
> > > > > http://lists.xwiki.org/mailman/listinfo/devs
> > > > >
> > > > _______________________________________________
> > > > devs mailing list
> > > > [hidden email]
> > > > http://lists.xwiki.org/mailman/listinfo/devs
> > > _______________________________________________
> > > devs mailing list
> > > [hidden email]
> > > http://lists.xwiki.org/mailman/listinfo/devs
> > >
> > _______________________________________________
> > devs mailing list
> > [hidden email]
> > http://lists.xwiki.org/mailman/listinfo/devs
>
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

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

Guillaume Lerouge
In reply to this post by vmassol
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, [hidden email] <[hidden email]>
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 ([hidden email](mailto:
> [hidden email])) wrote:
>
> > On Thu, Oct 9, 2014 at 5:59 PM, [hidden email]
> > wrote:
> >
> > >
> > >
> > >
> > >
> > >
> > > On 9 Oct 2014 at 17:57:46, Jeremie BOUSQUET (
> [hidden email]
> > > (mailto:[hidden email])) 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 [hidden email] :
> > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On 9 Oct 2014 at 14:23:49, Eduard Moraru ([hidden email]
> (mailto:
> > > > > [hidden email])) wrote:
> > > > >
> > > > > > On Thu, Oct 9, 2014 at 3:15 PM, [hidden email]
> > > > > > wrote:
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On 9 Oct 2014 at 14:02:05, Eduard Moraru ([hidden email]
> > > (mailto:
> > > > > > > [hidden email])) 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)
> <
> > > > > > > > > [hidden email]> 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 <
> > > > > > > > > > [hidden email]> wrote:
> > > > > > > > > >
> > > > > > > > > >> Hi.
> > > > > > > > > >>
> > > > > > > > > >> I am happy that this topic is coming back.
> > > > > > > > > >>
> > > > > > > > > >> 2014-09-24 10:04 GMT+02:00 [hidden email] :
> > > > > > > > > >>
> > > > > > > > > >> > 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
> > > > > > > > > >> > [hidden email]
> > > > > > > > > >> > http://lists.xwiki.org/mailman/listinfo/devs
> > > > > > > > > >> >
> > > > > > > > > >>
> > > > > > > > > >>
> > > > > > > > > >>
> > > > > > > > > >> --
> > > > > > > > > >> Guillaume Delhumeau ([hidden email])
> > > > > > > > > >> Research & Development Engineer at XWiki SAS
> > > > > > > > > >> Committer on the XWiki.org project
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

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

Anca Luca
Hi all,

I kind of liked this solution as well, I think, I sort of ended up getting
used to it. Indeed maybe the button needs to be more obviously a button.

The big disadvantage of hover is that people don't realise that the menu is
clickable by itself. I have seen a lot of users trying to choose something
from the submenu, not even trying to click on the top of the menu because
they don't realize the menu is clickable itself as well. This is also valid
for the edit menu, but a bit less bothering because regular users in
general don't have a submenu for the edit menu.

So, if I was to choose now, then maybe the 6.2.1 version would be "the
one", but with an improvement of the arrow to make it look more like an
extra clickable button to unpack more options.
Also, maybe a combination of the 2: clickable menu and an extra option to
go to the space in the menu if the user unpacks it.

I would be curious of Vincent's experience, which started this change in
the first place (the fact that people don't figure out that they can unpack
the menu or that they click the whole item to unpack the menu).

Thanks,
Anca

On Tue, Oct 21, 2014 at 3:43 PM, Guillaume Lerouge <[hidden email]>
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, [hidden email] <[hidden email]>
> 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 ([hidden email](mailto:
> > [hidden email])) wrote:
> >
> > > On Thu, Oct 9, 2014 at 5:59 PM, [hidden email]
> > > wrote:
> > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On 9 Oct 2014 at 17:57:46, Jeremie BOUSQUET (
> > [hidden email]
> > > > (mailto:[hidden email])) 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 [hidden email] :
> > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On 9 Oct 2014 at 14:23:49, Eduard Moraru ([hidden email]
> > (mailto:
> > > > > > [hidden email])) wrote:
> > > > > >
> > > > > > > On Thu, Oct 9, 2014 at 3:15 PM, [hidden email]
> > > > > > > wrote:
> > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On 9 Oct 2014 at 14:02:05, Eduard Moraru (
> [hidden email]
> > > > (mailto:
> > > > > > > > [hidden email])) 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)
> > <
> > > > > > > > > > [hidden email]> 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 <
> > > > > > > > > > > [hidden email]> wrote:
> > > > > > > > > > >
> > > > > > > > > > >> Hi.
> > > > > > > > > > >>
> > > > > > > > > > >> I am happy that this topic is coming back.
> > > > > > > > > > >>
> > > > > > > > > > >> 2014-09-24 10:04 GMT+02:00 [hidden email] :
> > > > > > > > > > >>
> > > > > > > > > > >> > 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
> > > > > > > > > > >> > [hidden email]
> > > > > > > > > > >> > http://lists.xwiki.org/mailman/listinfo/devs
> > > > > > > > > > >> >
> > > > > > > > > > >>
> > > > > > > > > > >>
> > > > > > > > > > >>
> > > > > > > > > > >> --
> > > > > > > > > > >> Guillaume Delhumeau ([hidden email])
> > > > > > > > > > >> Research & Development Engineer at XWiki SAS
> > > > > > > > > > >> Committer on the XWiki.org project
> >
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs