[xwiki-devs] [Brainstorming] Improving the Top level Menu/Breadcrumb/Navigation
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/... 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
Very interesting reflexion. See my comments below. On Wed, Sep 24, 2014 at 10:04:02AM +0200, [email protected] 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 > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs -- Jean Simard [email protected] Research engineer at XWiki SAS http://www.xwiki.com Committer on the XWiki.org project http://www.xwiki.org
Hi. I am happy that this topic is coming back. 2014-09-24 10:04 GMT+02:00 [email protected] <[email protected]>:
Hi devs,
I’ve had a few persons tell me that they don’t like the small arrow in the top level menu in Flamingo. It seems they either don’t understand the little triangles and what it’s about (submenu?) or they click on the menu itself and go to another page when they were expecting some menu to drop down, or...
I don't like it neither. It is not consistent with other projects (such as JIRA). It is not consistent with what we are planning to do about the UI language (see: http://design.xwiki.org/xwiki/bin/download/Proposal/InterfaceAndContentLangu...). It is harder to use on mobiles, and people are surprised by what occurs when they click on it.
In addition we’re still missing a solution to easily navigate the wiki from any page (there’s the ctrl+G solution but this is more like a shortcut to know and we need something more).
So here are some ideas:
* For the top level menu, make it simpler by having the drop down display when you click anywhere in the menu (the whole width of it) and only navigate when you double click (there are actually few reasons to need to navigate with the other idea below so we could also not do the double click thing)
+1
* In the breadcrumb OR in the top level menu OR in both (to be decided) use something like this (screenshot taken from IntelliJ IDEA):
https://www.evernote.com/shard/s119/sh/20e99ab3-2991-4aa8-a7b5-93088aad4944/...
This means when you click at a given level you get to see all sibling elements in the wiki for element you’re currently on (document, space, wiki).
For example clicking on the “Home” wiki would show: - A filter box allowing you to type and it would auto suggest as you type, completing with wiki names - An icon would be displayed on the left (or on the right) of the filter box and if you click on it you’ll go the index page (Wiki Index in this case) - A list of the first 10 wikis (an improvement would be to list first the wiki that you’ve last navigated to)
Same would apply for spaces and pages.
We could even imagine that when you’re on a user profile page, clicking on it would display other user pages and the filter would filter on user pages. Actually we could imagine to when the current page has XObjects in it, it would be possible to list all other pages in the wiki having the same XClass. And if there are several XObjects, then somehow in the UI allow selecting which one to consider as the filter criteria.
* Note 1: The breadcrumb is currently not displayed on all pages (it’s not on the home page for example) and thus if we implement this idea in the breadcrumb only then there’s no solution for navigating on the home page.
This is a behaviour that I have put because I thought it was not pretty to have a useless breadcrumb on the home page. It can be changed.
* Note 2: If we were to implement this idea on the top level menu, then we still need to display the actions too. Several options: - a) Display the actions first and the navigation list after separated by a ----- - b) Have a first entry in the drop down that says “Actions...” and when you move the mouse over it a secondary menu with all actions are displayed. Note that the alternative is possible too: Display the actions and have a “Go to..." menu entry. We would just need to choose to display what we think is the most used default (actions or navigation)
+1
WDYT?
Personally I would do this: - implement this idea for the breadcrumb
+0, I need to think more about it
- add “Go to wiki...”, “Go to space...", “Go to page..." menu entries in the Wiki/Space/Page top level menus
+1
- expand the menu selection to the whole width for displaying the drop down (and not just above the small arrow)
+1
- either support double-click or simply add the possibility to navigate to that element in the “Go to xxx...” submenu
+1
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project
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 < [email protected]> wrote:
Hi.
I am happy that this topic is coming back.
2014-09-24 10:04 GMT+02:00 [email protected] <[email protected]>:
Hi devs,
I’ve had a few persons tell me that they don’t like the small arrow in the top level menu in Flamingo. It seems they either don’t understand the little triangles and what it’s about (submenu?) or they click on the menu itself and go to another page when they were expecting some menu to drop down, or...
I don't like it neither. It is not consistent with other projects (such as JIRA). It is not consistent with what we are planning to do about the UI language (see:
http://design.xwiki.org/xwiki/bin/download/Proposal/InterfaceAndContentLangu... ). It is harder to use on mobiles, and people are surprised by what occurs when they click on it.
In addition we’re still missing a solution to easily navigate the wiki from any page (there’s the ctrl+G solution but this is more like a
shortcut
to know and we need something more).
So here are some ideas:
* For the top level menu, make it simpler by having the drop down display when you click anywhere in the menu (the whole width of it) and only navigate when you double click (there are actually few reasons to need to navigate with the other idea below so we could also not do the double click thing)
+1
* In the breadcrumb OR in the top level menu OR in both (to be decided) use something like this (screenshot taken from IntelliJ IDEA):
https://www.evernote.com/shard/s119/sh/20e99ab3-2991-4aa8-a7b5-93088aad4944/...
This means when you click at a given level you get to see all sibling elements in the wiki for element you’re currently on (document, space, wiki).
For example clicking on the “Home” wiki would show: - A filter box allowing you to type and it would auto suggest as you
type,
completing with wiki names - An icon would be displayed on the left (or on the right) of the filter box and if you click on it you’ll go the index page (Wiki Index in this case) - A list of the first 10 wikis (an improvement would be to list first the wiki that you’ve last navigated to)
Same would apply for spaces and pages.
We could even imagine that when you’re on a user profile page, clicking on it would display other user pages and the filter would filter on user pages. Actually we could imagine to when the current page has XObjects in it, it would be possible to list all other pages in the wiki having the same XClass. And if there are several XObjects, then somehow in the UI allow selecting which one to consider as the filter criteria.
* Note 1: The breadcrumb is currently not displayed on all pages (it’s not on the home page for example) and thus if we implement this idea in the breadcrumb only then there’s no solution for navigating on the home page.
This is a behaviour that I have put because I thought it was not pretty to have a useless breadcrumb on the home page. It can be changed.
* Note 2: If we were to implement this idea on the top level menu, then
we
still need to display the actions too. Several options: - a) Display the actions first and the navigation list after separated by a ----- - b) Have a first entry in the drop down that says “Actions...” and when you move the mouse over it a secondary menu with all actions are displayed. Note that the alternative is possible too: Display the actions and have a “Go to..." menu entry. We would just need to choose to display what we think is the most used default (actions or navigation)
+1
WDYT?
Personally I would do this: - implement this idea for the breadcrumb
+0, I need to think more about it
- add “Go to wiki...”, “Go to space...", “Go to page..." menu entries in the Wiki/Space/Page top level menus
+1
- expand the menu selection to the whole width for displaying the drop down (and not just above the small arrow)
+1
- either support double-click or simply add the possibility to navigate to that element in the “Go to xxx...” submenu
+1
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Wed, Sep 24, 2014 at 5:25 PM, Ecaterina Moraru (Valica) < [email protected]> wrote:
Hi,
Some background: * Colibri ** menus displayed on hover ** custom menu JS ** menu entries could be icon+label+separator+link+whatever
* Flamingo ** menus displayed on click ** menu component from Bootstrap ** it expects simple links or menu dropdown containers (not both functions)
Theoretically Bootstrap doesn't support our use case and cannot replicate by default the Colibri's behavior. Any change we want to make to the menu Bootstrap component means we are branching from the default behavior and we will create a custom one. We really need to listen to clicks and not hover state, since we need to be mobile compatible.
It's normal that the users feel a bit confused since they are used with a certain behavior and we tried to mix them in order to have both menu and navigation use cases. And I think the reason is a bit confusing is that the separation between the link and the arrow is invisible, compared with the btn-groups used for Edit or Add. For example, I think that making the separation more clean, like in this screenshot http://jira.xwiki.org/secure/attachment/28807/btn-group.png would improve a bit the things, but would need visual improvements and is not default also. Maybe we could think of a better solution if we were to go on this path.
Behavior like double clicking a certain element will be a hidden interaction for the users. Double clicking is not a Web behavior and you cannot expect users to know on which links to simple click vs. on which to double click. In the usability testing sessions users had a hard time to double click on uploading image in the WYSIWYG popup, so I'm not sure about this approach's success.
Regarding the IntelliJ IDEA screenshot, we already discuss about this idea and even made a similar proposal some long time ago, see http://design.xwiki.org/xwiki/bin/view/Improvements/ActionMenuNavigation Although this proposal is a nice idea and I would like to have it, I don't see how this would 'simplify' the current implementation. IMO it will make it even more complex and we would certainly need a custom menu. Also I see this as a new feature, than a solution to our current problem.
When we implemented the current solution we discussed if the navigation should be put on the text or on the icon, see http://jira.xwiki.org/browse/XWIKI-10449 . The main problem is the findability of this functionality. Users might never press that icon (this problem applies to the solution brainstorming and the breadcrumb proposal).
So I think the idea to have an entry with "Go to ..." could be a solution and to keep the menus interact with the default behavior (removing the navigation from the dropdown activator). Removing triangles is not an option. That is a default menu marker caret.
So what are the next steps? We do a issue with the "Go to ..." solution?
http://jira.xwiki.org/browse/XWIKI-11166
Thanks, Caty
On Wed, Sep 24, 2014 at 11:55 AM, Guillaume "Louis-Marie" Delhumeau < [email protected]> wrote:
Hi.
I am happy that this topic is coming back.
2014-09-24 10:04 GMT+02:00 [email protected] <[email protected]>:
Hi devs,
I’ve had a few persons tell me that they don’t like the small arrow in the top level menu in Flamingo. It seems they either don’t understand the little triangles and what it’s about (submenu?) or they click on the menu itself and go to another page when they were expecting some menu to drop down, or...
I don't like it neither. It is not consistent with other projects (such as JIRA). It is not consistent with what we are planning to do about the UI language (see:
http://design.xwiki.org/xwiki/bin/download/Proposal/InterfaceAndContentLangu... ). It is harder to use on mobiles, and people are surprised by what occurs when they click on it.
In addition we’re still missing a solution to easily navigate the wiki from any page (there’s the ctrl+G solution but this is more like a
shortcut
to know and we need something more).
So here are some ideas:
* For the top level menu, make it simpler by having the drop down display when you click anywhere in the menu (the whole width of it) and only navigate when you double click (there are actually few reasons to need to navigate with the other idea below so we could also not do the double click thing)
+1
* In the breadcrumb OR in the top level menu OR in both (to be decided) use something like this (screenshot taken from IntelliJ IDEA):
https://www.evernote.com/shard/s119/sh/20e99ab3-2991-4aa8-a7b5-93088aad4944/...
This means when you click at a given level you get to see all sibling elements in the wiki for element you’re currently on (document, space, wiki).
For example clicking on the “Home” wiki would show: - A filter box allowing you to type and it would auto suggest as you
type,
completing with wiki names - An icon would be displayed on the left (or on the right) of the filter box and if you click on it you’ll go the index page (Wiki Index in this case) - A list of the first 10 wikis (an improvement would be to list first the wiki that you’ve last navigated to)
Same would apply for spaces and pages.
We could even imagine that when you’re on a user profile page, clicking on it would display other user pages and the filter would filter on user pages. Actually we could imagine to when the current page has XObjects in it, it would be possible to list all other pages in the wiki having the same XClass. And if there are several XObjects, then somehow in the UI allow selecting which one to consider as the filter criteria.
* Note 1: The breadcrumb is currently not displayed on all pages (it’s not on the home page for example) and thus if we implement this idea in the breadcrumb only then there’s no solution for navigating on the home page.
This is a behaviour that I have put because I thought it was not pretty to have a useless breadcrumb on the home page. It can be changed.
* Note 2: If we were to implement this idea on the top level menu, then
we
still need to display the actions too. Several options: - a) Display the actions first and the navigation list after separated by a ----- - b) Have a first entry in the drop down that says “Actions...” and when you move the mouse over it a secondary menu with all actions are displayed. Note that the alternative is possible too: Display the actions and have a “Go to..." menu entry. We would just need to choose to display what we think is the most used default (actions or navigation)
+1
WDYT?
Personally I would do this: - implement this idea for the breadcrumb
+0, I need to think more about it
- add “Go to wiki...”, “Go to space...", “Go to page..." menu entries in the Wiki/Space/Page top level menus
+1
- expand the menu selection to the whole width for displaying the drop down (and not just above the small arrow)
+1
- either support double-click or simply add the possibility to navigate to that element in the “Go to xxx...” submenu
+1
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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) <[email protected]
wrote:
On Wed, Sep 24, 2014 at 5:25 PM, Ecaterina Moraru (Valica) < [email protected]> wrote:
Hi,
Some background: * Colibri ** menus displayed on hover ** custom menu JS ** menu entries could be icon+label+separator+link+whatever
* Flamingo ** menus displayed on click ** menu component from Bootstrap ** it expects simple links or menu dropdown containers (not both functions)
Theoretically Bootstrap doesn't support our use case and cannot replicate by default the Colibri's behavior. Any change we want to make to the menu Bootstrap component means we are branching from the default behavior and we will create a custom one. We really need to listen to clicks and not hover state, since we need to be mobile compatible.
It's normal that the users feel a bit confused since they are used with a certain behavior and we tried to mix them in order to have both menu and navigation use cases. And I think the reason is a bit confusing is that the separation between the link and the arrow is invisible, compared with the btn-groups used for Edit or Add. For example, I think that making the separation more clean, like in this screenshot http://jira.xwiki.org/secure/attachment/28807/btn-group.png would improve a bit the things, but would need visual improvements and is not default also. Maybe we could think of a better solution if we were to go on this path.
Behavior like double clicking a certain element will be a hidden interaction for the users. Double clicking is not a Web behavior and you cannot expect users to know on which links to simple click vs. on which to double click. In the usability testing sessions users had a hard time to double click on uploading image in the WYSIWYG popup, so I'm not sure about this approach's success.
Regarding the IntelliJ IDEA screenshot, we already discuss about this idea and even made a similar proposal some long time ago, see http://design.xwiki.org/xwiki/bin/view/Improvements/ActionMenuNavigation Although this proposal is a nice idea and I would like to have it, I don't see how this would 'simplify' the current implementation. IMO it will make it even more complex and we would certainly need a custom menu. Also I see this as a new feature, than a solution to our current problem.
When we implemented the current solution we discussed if the navigation should be put on the text or on the icon, see http://jira.xwiki.org/browse/XWIKI-10449 . The main problem is the findability of this functionality. Users might never press that icon (this problem applies to the solution brainstorming and the breadcrumb proposal).
So I think the idea to have an entry with "Go to ..." could be a solution and to keep the menus interact with the default behavior (removing the navigation from the dropdown activator). Removing triangles is not an option. That is a default menu marker caret.
So what are the next steps? We do a issue with the "Go to ..." solution?
http://jira.xwiki.org/browse/XWIKI-11166
Thanks, Caty
On Wed, Sep 24, 2014 at 11:55 AM, Guillaume "Louis-Marie" Delhumeau < [email protected]> wrote:
Hi.
I am happy that this topic is coming back.
2014-09-24 10:04 GMT+02:00 [email protected] <[email protected]>:
Hi devs,
I’ve had a few persons tell me that they don’t like the small arrow in the top level menu in Flamingo. It seems they either don’t understand the little triangles and what it’s about (submenu?) or they click on the menu itself and go to another page when they were expecting some menu to drop down, or...
I don't like it neither. It is not consistent with other projects (such as JIRA). It is not consistent with what we are planning to do about the UI language (see:
http://design.xwiki.org/xwiki/bin/download/Proposal/InterfaceAndContentLangu...
). It is harder to use on mobiles, and people are surprised by what occurs when they click on it.
In addition we’re still missing a solution to easily navigate the wiki from any page (there’s the ctrl+G solution but this is more like a
shortcut
to know and we need something more).
So here are some ideas:
* For the top level menu, make it simpler by having the drop down display when you click anywhere in the menu (the whole width of it) and only navigate when you double click (there are actually few reasons to need to navigate with the other idea below so we could also not do the double click thing)
+1
* In the breadcrumb OR in the top level menu OR in both (to be
decided)
use something like this (screenshot taken from IntelliJ IDEA):
https://www.evernote.com/shard/s119/sh/20e99ab3-2991-4aa8-a7b5-93088aad4944/...
This means when you click at a given level you get to see all sibling elements in the wiki for element you’re currently on (document, space, wiki).
For example clicking on the “Home” wiki would show: - A filter box allowing you to type and it would auto suggest as you
type,
completing with wiki names - An icon would be displayed on the left (or on the right) of the filter box and if you click on it you’ll go the index page (Wiki Index in this case) - A list of the first 10 wikis (an improvement would be to list first the wiki that you’ve last navigated to)
Same would apply for spaces and pages.
We could even imagine that when you’re on a user profile page, clicking on it would display other user pages and the filter would filter on user pages. Actually we could imagine to when the current page has XObjects in it, it would be possible to list all other pages in the wiki having the same XClass. And if there are several XObjects, then somehow in the UI allow selecting which one to consider as the filter criteria.
* Note 1: The breadcrumb is currently not displayed on all pages (it’s not on the home page for example) and thus if we implement this idea in the breadcrumb only then there’s no solution for navigating on the home page.
This is a behaviour that I have put because I thought it was not pretty to have a useless breadcrumb on the home page. It can be changed.
* Note 2: If we were to implement this idea on the top level menu,
then we
still need to display the actions too. Several options: - a) Display the actions first and the navigation list after separated by a ----- - b) Have a first entry in the drop down that says “Actions...” and when you move the mouse over it a secondary menu with all actions are displayed. Note that the alternative is possible too: Display the actions and have a “Go to..." menu entry. We would just need to choose to display what we think is the most used default (actions or navigation)
+1
WDYT?
Personally I would do this: - implement this idea for the breadcrumb
+0, I need to think more about it
- add “Go to wiki...”, “Go to space...", “Go to page..." menu entries in the Wiki/Space/Page top level menus
+1
- expand the menu selection to the whole width for displaying the drop down (and not just above the small arrow)
+1
- either support double-click or simply add the possibility to navigate to that element in the “Go to xxx...” submenu
+1
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On 9 Oct 2014 at 14:02:05, Eduard Moraru ([email protected](mailto:[email protected])) wrote:
Folks, you speak of consistency and then come up with this solution...
So we have a problem with "non-standard bootstrap dropdown buttons" that our users (whoever they may be) have a problem with understanding that there is either an action or a dropdown involved in the same button, like they can encounter in other interfaces along their computer usage history.
Our solution is to stop using the mixed mode, and only use the "standard bootstrap dropdown buttons" that have their first action in the submenu the thing that would have happened in the past when the users clicked directly the action part of the "mixed button" we were using.
Ok, we implement this solution, but we only do it for the top navigational elements. We completely ignore the "Add" and the "Edit" buttons that "suffer" from exactly the same "problem".
My question is: why?
If we do/did decide that this is the way to go, we should at least be consistent and do it everywhere in the UI, otherwise it just causes frustrations.
There’s a difference. For the Edit/Add button click the button will do what the user wants. Click the arrow is only for advanced featurs. Thanks -Vincent
Thanks, Eduard
On Fri, Oct 3, 2014 at 4:21 PM, Ecaterina Moraru (Valica) > > wrote:
On Wed, Sep 24, 2014 at 5:25 PM, Ecaterina Moraru (Valica) < [email protected]> wrote:
Hi,
Some background: * Colibri ** menus displayed on hover ** custom menu JS ** menu entries could be icon+label+separator+link+whatever
* Flamingo ** menus displayed on click ** menu component from Bootstrap ** it expects simple links or menu dropdown containers (not both functions)
Theoretically Bootstrap doesn't support our use case and cannot replicate by default the Colibri's behavior. Any change we want to make to the menu Bootstrap component means we are branching from the default behavior and we will create a custom one. We really need to listen to clicks and not hover state, since we need to be mobile compatible.
It's normal that the users feel a bit confused since they are used with a certain behavior and we tried to mix them in order to have both menu and navigation use cases. And I think the reason is a bit confusing is that the separation between the link and the arrow is invisible, compared with the btn-groups used for Edit or Add. For example, I think that making the separation more clean, like in this screenshot http://jira.xwiki.org/secure/attachment/28807/btn-group.png would improve a bit the things, but would need visual improvements and is not default also. Maybe we could think of a better solution if we were to go on this path.
Behavior like double clicking a certain element will be a hidden interaction for the users. Double clicking is not a Web behavior and you cannot expect users to know on which links to simple click vs. on which to double click. In the usability testing sessions users had a hard time to double click on uploading image in the WYSIWYG popup, so I'm not sure about this approach's success.
Regarding the IntelliJ IDEA screenshot, we already discuss about this idea and even made a similar proposal some long time ago, see http://design.xwiki.org/xwiki/bin/view/Improvements/ActionMenuNavigation Although this proposal is a nice idea and I would like to have it, I don't see how this would 'simplify' the current implementation. IMO it will make it even more complex and we would certainly need a custom menu. Also I see this as a new feature, than a solution to our current problem.
When we implemented the current solution we discussed if the navigation should be put on the text or on the icon, see http://jira.xwiki.org/browse/XWIKI-10449 . The main problem is the findability of this functionality. Users might never press that icon (this problem applies to the solution brainstorming and the breadcrumb proposal).
So I think the idea to have an entry with "Go to ..." could be a solution and to keep the menus interact with the default behavior (removing the navigation from the dropdown activator). Removing triangles is not an option. That is a default menu marker caret.
So what are the next steps? We do a issue with the "Go to ..." solution?
http://jira.xwiki.org/browse/XWIKI-11166
Thanks, Caty
On Wed, Sep 24, 2014 at 11:55 AM, Guillaume "Louis-Marie" Delhumeau < [email protected]> wrote:
Hi.
I am happy that this topic is coming back.
2014-09-24 10:04 GMT+02:00 [email protected] :
Hi devs,
I’ve had a few persons tell me that they don’t like the small arrow in the top level menu in Flamingo. It seems they either don’t understand the little triangles and what it’s about (submenu?) or they click on the menu itself and go to another page when they were expecting some menu to drop down, or...
I don't like it neither. It is not consistent with other projects (such as JIRA). It is not consistent with what we are planning to do about the UI language (see:
http://design.xwiki.org/xwiki/bin/download/Proposal/InterfaceAndContentLangu...
). It is harder to use on mobiles, and people are surprised by what occurs when they click on it.
In addition we’re still missing a solution to easily navigate the wiki from any page (there’s the ctrl+G solution but this is more like a
shortcut
to know and we need something more).
So here are some ideas:
* For the top level menu, make it simpler by having the drop down display when you click anywhere in the menu (the whole width of it) and only navigate when you double click (there are actually few reasons to need to navigate with the other idea below so we could also not do the double click thing)
+1
* In the breadcrumb OR in the top level menu OR in both (to be
decided)
use something like this (screenshot taken from IntelliJ IDEA):
https://www.evernote.com/shard/s119/sh/20e99ab3-2991-4aa8-a7b5-93088aad4944/...
This means when you click at a given level you get to see all sibling elements in the wiki for element you’re currently on (document, space, wiki).
For example clicking on the “Home” wiki would show: - A filter box allowing you to type and it would auto suggest as you
type,
completing with wiki names - An icon would be displayed on the left (or on the right) of the filter box and if you click on it you’ll go the index page (Wiki Index in this case) - A list of the first 10 wikis (an improvement would be to list first the wiki that you’ve last navigated to)
Same would apply for spaces and pages.
We could even imagine that when you’re on a user profile page, clicking on it would display other user pages and the filter would filter on user pages. Actually we could imagine to when the current page has XObjects in it, it would be possible to list all other pages in the wiki having the same XClass. And if there are several XObjects, then somehow in the UI allow selecting which one to consider as the filter criteria.
* Note 1: The breadcrumb is currently not displayed on all pages (it’s not on the home page for example) and thus if we implement this idea in the breadcrumb only then there’s no solution for navigating on the home page.
This is a behaviour that I have put because I thought it was not pretty to have a useless breadcrumb on the home page. It can be changed.
* Note 2: If we were to implement this idea on the top level menu,
then we
still need to display the actions too. Several options: - a) Display the actions first and the navigation list after separated by a ----- - b) Have a first entry in the drop down that says “Actions...” and when you move the mouse over it a secondary menu with all actions are displayed. Note that the alternative is possible too: Display the actions and have a “Go to..." menu entry. We would just need to choose to display what we think is the most used default (actions or navigation)
+1
WDYT?
Personally I would do this: - implement this idea for the breadcrumb
+0, I need to think more about it
- add “Go to wiki...”, “Go to space...", “Go to page..." menu entries in the Wiki/Space/Page top level menus
+1
- expand the menu selection to the whole width for displaying the drop down (and not just above the small arrow)
+1
- either support double-click or simply add the possibility to navigate to that element in the “Go to xxx...” submenu
+1
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Thu, Oct 9, 2014 at 3:15 PM, [email protected] <[email protected]> wrote:
On 9 Oct 2014 at 14:02:05, Eduard Moraru ([email protected](mailto: [email protected])) wrote:
Folks, you speak of consistency and then come up with this solution...
So we have a problem with "non-standard bootstrap dropdown buttons" that our users (whoever they may be) have a problem with understanding that there is either an action or a dropdown involved in the same button, like they can encounter in other interfaces along their computer usage history.
Our solution is to stop using the mixed mode, and only use the "standard bootstrap dropdown buttons" that have their first action in the submenu the thing that would have happened in the past when the users clicked directly the action part of the "mixed button" we were using.
Ok, we implement this solution, but we only do it for the top navigational elements. We completely ignore the "Add" and the "Edit" buttons that "suffer" from exactly the same "problem".
My question is: why?
If we do/did decide that this is the way to go, we should at least be consistent and do it everywhere in the UI, otherwise it just causes frustrations.
There’s a difference. For the Edit/Add button click the button will do what the user wants. Click the arrow is only for advanced featurs.
"It seems they either don’t understand the little triangles and what it’s about (submenu?) or they click on the menu itself and go to another page when they were expecting some menu to drop down, or.." There is no difference from the "problem" you have mentioned in the OP. The user sees an arrow and clicks on the button to expand the menu, but instead ends up reloading the page (either to edit mode or to view mode, same thing). You will say that he wanted to edit anyway, yes, but maybe he did not want to edit in the default mode, so the user's "intent" (as you defined it in the OP) is still not respected. We either do it one way, or the other, all I ask for is consistency. Do we want to introduce yet another compromise in this young skin? Thanks, Eduard
Thanks -Vincent
Thanks, Eduard
On Fri, Oct 3, 2014 at 4:21 PM, Ecaterina Moraru (Valica) > > wrote:
On Wed, Sep 24, 2014 at 5:25 PM, Ecaterina Moraru (Valica) < [email protected]> wrote:
Hi,
Some background: * Colibri ** menus displayed on hover ** custom menu JS ** menu entries could be icon+label+separator+link+whatever
* Flamingo ** menus displayed on click ** menu component from Bootstrap ** it expects simple links or menu dropdown containers (not both functions)
Theoretically Bootstrap doesn't support our use case and cannot replicate by default the Colibri's behavior. Any change we want to make to the menu Bootstrap component means we are branching from the default behavior and we will create a custom one. We really need to listen to clicks and not hover state, since we need to be mobile compatible.
It's normal that the users feel a bit confused since they are used with a certain behavior and we tried to mix them in order to have both menu and navigation use cases. And I think the reason is a bit confusing is that the separation between the link and the arrow is invisible, compared with the btn-groups used for Edit or Add. For example, I think that making the separation more clean, like in this screenshot http://jira.xwiki.org/secure/attachment/28807/btn-group.png would improve a bit the things, but would need visual improvements and is not default also. Maybe we could think of a better solution if we were to go on this path.
Behavior like double clicking a certain element will be a hidden interaction for the users. Double clicking is not a Web behavior and you cannot expect users to know on which links to simple click vs. on which to double click. In the usability testing sessions users had a hard time to double click on uploading image in the WYSIWYG popup, so I'm not sure about this approach's success.
Regarding the IntelliJ IDEA screenshot, we already discuss about this idea and even made a similar proposal some long time ago, see
http://design.xwiki.org/xwiki/bin/view/Improvements/ActionMenuNavigation
Although this proposal is a nice idea and I would like to have it, I don't see how this would 'simplify' the current implementation. IMO it will make it even more complex and we would certainly need a custom menu. Also I see this as a new feature, than a solution to our current problem.
When we implemented the current solution we discussed if the navigation should be put on the text or on the icon, see http://jira.xwiki.org/browse/XWIKI-10449 . The main problem is the findability of this functionality. Users might never press that icon (this problem applies to the solution brainstorming and the breadcrumb proposal).
So I think the idea to have an entry with "Go to ..." could be a solution and to keep the menus interact with the default behavior (removing the navigation from the dropdown activator). Removing triangles is not an option. That is a default menu marker caret.
So what are the next steps? We do a issue with the "Go to ..." solution?
http://jira.xwiki.org/browse/XWIKI-11166
Thanks, Caty
On Wed, Sep 24, 2014 at 11:55 AM, Guillaume "Louis-Marie" Delhumeau < [email protected]> wrote:
Hi.
I am happy that this topic is coming back.
2014-09-24 10:04 GMT+02:00 [email protected] :
Hi devs,
I’ve had a few persons tell me that they don’t like the small arrow in the top level menu in Flamingo. It seems they either don’t understand the little triangles and what it’s about (submenu?) or they click on the menu itself and go to another page when they were expecting some menu to drop down, or...
I don't like it neither. It is not consistent with other projects (such as JIRA). It is not consistent with what we are planning to do about the UI language (see:
http://design.xwiki.org/xwiki/bin/download/Proposal/InterfaceAndContentLangu...
). It is harder to use on mobiles, and people are surprised by what occurs when they click on it.
In addition we’re still missing a solution to easily navigate the
wiki
from any page (there’s the ctrl+G solution but this is more like a shortcut to know and we need something more).
So here are some ideas:
* For the top level menu, make it simpler by having the drop down display when you click anywhere in the menu (the whole width of it) and only navigate when you double click (there are actually few reasons to need to navigate with the other idea below so we could also not do the double click thing)
+1
* In the breadcrumb OR in the top level menu OR in both (to be
decided)
use something like this (screenshot taken from IntelliJ IDEA):
https://www.evernote.com/shard/s119/sh/20e99ab3-2991-4aa8-a7b5-93088aad4944/...
This means when you click at a given level you get to see all
sibling
elements in the wiki for element you’re currently on (document, space, wiki).
For example clicking on the “Home” wiki would show: - A filter box allowing you to type and it would auto suggest as you type, completing with wiki names - An icon would be displayed on the left (or on the right) of the filter box and if you click on it you’ll go the index page (Wiki Index in this case) - A list of the first 10 wikis (an improvement would be to list first the wiki that you’ve last navigated to)
Same would apply for spaces and pages.
We could even imagine that when you’re on a user profile page, clicking on it would display other user pages and the filter would filter on user pages. Actually we could imagine to when the current page has XObjects in it, it would be possible to list all other pages in the wiki having the same XClass. And if there are several XObjects, then somehow in the UI allow selecting which one to consider as the filter criteria.
* Note 1: The breadcrumb is currently not displayed on all pages (it’s not on the home page for example) and thus if we implement this idea in the breadcrumb only then there’s no solution for navigating on the home page.
This is a behaviour that I have put because I thought it was not pretty to have a useless breadcrumb on the home page. It can be changed.
* Note 2: If we were to implement this idea on the top level menu,
then we
still need to display the actions too. Several options: - a) Display the actions first and the navigation list after separated by a ----- - b) Have a first entry in the drop down that says “Actions...” and when you move the mouse over it a secondary menu with all actions are displayed. Note that the alternative is possible too: Display the actions and have a “Go to..." menu entry. We would just need to choose to display what we think is the most used default (actions or navigation)
+1
WDYT?
Personally I would do this: - implement this idea for the breadcrumb
+0, I need to think more about it
- add “Go to wiki...”, “Go to space...", “Go to page..." menu entries in the Wiki/Space/Page top level menus
+1
- expand the menu selection to the whole width for displaying the drop down (and not just above the small arrow)
+1
- either support double-click or simply add the possibility to navigate to that element in the “Go to xxx...” submenu
+1
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On 9 Oct 2014 at 14:23:49, Eduard Moraru ([email protected](mailto:[email protected])) wrote:
On Thu, Oct 9, 2014 at 3:15 PM, [email protected] wrote:
On 9 Oct 2014 at 14:02:05, Eduard Moraru ([email protected](mailto: [email protected])) wrote:
Folks, you speak of consistency and then come up with this solution...
So we have a problem with "non-standard bootstrap dropdown buttons" that our users (whoever they may be) have a problem with understanding that there is either an action or a dropdown involved in the same button, like they can encounter in other interfaces along their computer usage history.
Our solution is to stop using the mixed mode, and only use the "standard bootstrap dropdown buttons" that have their first action in the submenu the thing that would have happened in the past when the users clicked directly the action part of the "mixed button" we were using.
Ok, we implement this solution, but we only do it for the top navigational elements. We completely ignore the "Add" and the "Edit" buttons that "suffer" from exactly the same "problem".
My question is: why?
If we do/did decide that this is the way to go, we should at least be consistent and do it everywhere in the UI, otherwise it just causes frustrations.
There’s a difference. For the Edit/Add button click the button will do what the user wants. Click the arrow is only for advanced featurs.
"It seems they either don’t understand the little triangles and what it’s about (submenu?) or they click on the menu itself and go to another page when they were expecting some menu to drop down, or.."
There is no difference from the "problem" you have mentioned in the OP. The user sees an arrow and clicks on the button to expand the menu, but instead ends up reloading the page (either to edit mode or to view mode, same thing). You will say that he wanted to edit anyway, yes, but maybe he did not want to edit in the default mode, so the user's "intent" (as you defined it in the OP) is still not respected.
We either do it one way, or the other, all I ask for is consistency. Do we want to introduce yet another compromise in this young skin?
The problem I saw is that users were not clicking the arrow but the main button part (thus navigating instead of having the main options). What we want is that it’s the simplest possible for the user for his use case at hand: - When I click Edit or Add (not the arrow, the button) it’s the simplest possible. Edit will choose the good default mode and add will add a page - When I click the wiki/space/page button (not the arrow) I want the actions to be displayed rather than the navigation since navigation is a secondary use case for these buttons At least that’s how I view it. Forcing the user to have 2 clicks to do the main action on a button would be a pity. Now you’re going to say that we could keep the arrow for the wiki/space/page buttons to navigate. We could, but it doesn’t feel natural. What do you suggest? Thanks -Vincent
Thanks, Eduard
Thanks -Vincent
Thanks, Eduard
On Fri, Oct 3, 2014 at 4:21 PM, Ecaterina Moraru (Valica) > > wrote:
On Wed, Sep 24, 2014 at 5:25 PM, Ecaterina Moraru (Valica) < [email protected]> wrote:
Hi,
Some background: * Colibri ** menus displayed on hover ** custom menu JS ** menu entries could be icon+label+separator+link+whatever
* Flamingo ** menus displayed on click ** menu component from Bootstrap ** it expects simple links or menu dropdown containers (not both functions)
Theoretically Bootstrap doesn't support our use case and cannot replicate by default the Colibri's behavior. Any change we want to make to the menu Bootstrap component means we are branching from the default behavior and we will create a custom one. We really need to listen to clicks and not hover state, since we need to be mobile compatible.
It's normal that the users feel a bit confused since they are used with a certain behavior and we tried to mix them in order to have both menu and navigation use cases. And I think the reason is a bit confusing is that the separation between the link and the arrow is invisible, compared with the btn-groups used for Edit or Add. For example, I think that making the separation more clean, like in this screenshot http://jira.xwiki.org/secure/attachment/28807/btn-group.png would improve a bit the things, but would need visual improvements and is not default also. Maybe we could think of a better solution if we were to go on this path.
Behavior like double clicking a certain element will be a hidden interaction for the users. Double clicking is not a Web behavior and you cannot expect users to know on which links to simple click vs. on which to double click. In the usability testing sessions users had a hard time to double click on uploading image in the WYSIWYG popup, so I'm not sure about this approach's success.
Regarding the IntelliJ IDEA screenshot, we already discuss about this idea and even made a similar proposal some long time ago, see
http://design.xwiki.org/xwiki/bin/view/Improvements/ActionMenuNavigation
Although this proposal is a nice idea and I would like to have it, I don't see how this would 'simplify' the current implementation. IMO it will make it even more complex and we would certainly need a custom menu. Also I see this as a new feature, than a solution to our current problem.
When we implemented the current solution we discussed if the navigation should be put on the text or on the icon, see http://jira.xwiki.org/browse/XWIKI-10449 . The main problem is the findability of this functionality. Users might never press that icon (this problem applies to the solution brainstorming and the breadcrumb proposal).
So I think the idea to have an entry with "Go to ..." could be a solution and to keep the menus interact with the default behavior (removing the navigation from the dropdown activator). Removing triangles is not an option. That is a default menu marker caret.
So what are the next steps? We do a issue with the "Go to ..." solution?
http://jira.xwiki.org/browse/XWIKI-11166
Thanks, Caty
On Wed, Sep 24, 2014 at 11:55 AM, Guillaume "Louis-Marie" Delhumeau < [email protected]> wrote:
Hi.
I am happy that this topic is coming back.
2014-09-24 10:04 GMT+02:00 [email protected] :
> Hi devs, > > I’ve had a few persons tell me that they don’t like the small arrow in the > top level menu in Flamingo. It seems they either don’t understand the > little triangles and what it’s about (submenu?) or they click on the menu > itself and go to another page when they were expecting some menu to drop > down, or... >
I don't like it neither. It is not consistent with other projects (such as JIRA). It is not consistent with what we are planning to do about the UI language (see:
http://design.xwiki.org/xwiki/bin/download/Proposal/InterfaceAndContentLangu...
). It is harder to use on mobiles, and people are surprised by what occurs when they click on it.
> > In addition we’re still missing a solution to easily navigate the wiki > from any page (there’s the ctrl+G solution but this is more like a shortcut > to know and we need something more). > > So here are some ideas: > > * For the top level menu, make it simpler by having the drop down display > when you click anywhere in the menu (the whole width of it) and only > navigate when you double click (there are actually few reasons to need to > navigate with the other idea below so we could also not do the double click > thing) >
+1
> > * In the breadcrumb OR in the top level menu OR in both (to be decided) > use something like this (screenshot taken from IntelliJ IDEA): > >
https://www.evernote.com/shard/s119/sh/20e99ab3-2991-4aa8-a7b5-93088aad4944/...
> > This means when you click at a given level you get to see all sibling > elements in the wiki for element you’re currently on (document, space, > wiki). > > For example clicking on the “Home” wiki would show: > - A filter box allowing you to type and it would auto suggest as you type, > completing with wiki names > - An icon would be displayed on the left (or on the right) of the filter > box and if you click on it you’ll go the index page (Wiki Index in this > case) > - A list of the first 10 wikis (an improvement would be to list first the > wiki that you’ve last navigated to) > > Same would apply for spaces and pages. > > We could even imagine that when you’re on a user profile page, clicking on > it would display other user pages and the filter would filter on user > pages. Actually we could imagine to when the current page has XObjects in > it, it would be possible to list all other pages in the wiki having the > same XClass. And if there are several XObjects, then somehow in the UI > allow selecting which one to consider as the filter criteria. > > * Note 1: The breadcrumb is currently not displayed on all pages (it’s not > on the home page for example) and thus if we implement this idea in the > breadcrumb only then there’s no solution for navigating on the home page. >
This is a behaviour that I have put because I thought it was not pretty to have a useless breadcrumb on the home page. It can be changed.
> > * Note 2: If we were to implement this idea on the top level menu, then we > still need to display the actions too. Several options: > - a) Display the actions first and the navigation list after separated by > a ----- > - b) Have a first entry in the drop down that says “Actions...” and when > you move the mouse over it a secondary menu with all actions are displayed. > Note that the alternative is possible too: Display the actions and have a > “Go to..." menu entry. We would just need to choose to display what we > think is the most used default (actions or navigation) >
+1
> > WDYT? > > Personally I would do this: > - implement this idea for the breadcrumb >
+0, I need to think more about it
> - add “Go to wiki...”, “Go to space...", “Go to page..." menu entries in > the Wiki/Space/Page top level menus >
+1
> - expand the menu selection to the whole width for displaying the drop > down (and not just above the small arrow) >
+1
> - either support double-click or simply add the possibility to navigate to > that element in the “Go to xxx...” submenu >
+1
> > Thanks > -Vincent > > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs >
-- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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 [email protected] <[email protected]>:
On 9 Oct 2014 at 14:23:49, Eduard Moraru ([email protected](mailto: [email protected])) wrote:
On Thu, Oct 9, 2014 at 3:15 PM, [email protected] wrote:
On 9 Oct 2014 at 14:02:05, Eduard Moraru ([email protected](mailto: [email protected])) wrote:
Folks, you speak of consistency and then come up with this
solution...
So we have a problem with "non-standard bootstrap dropdown buttons"
that
our users (whoever they may be) have a problem with understanding that there is either an action or a dropdown involved in the same button, like they can encounter in other interfaces along their computer usage history.
Our solution is to stop using the mixed mode, and only use the "standard bootstrap dropdown buttons" that have their first action in the submenu the thing that would have happened in the past when the users clicked directly the action part of the "mixed button" we were using.
Ok, we implement this solution, but we only do it for the top navigational elements. We completely ignore the "Add" and the "Edit" buttons that "suffer" from exactly the same "problem".
My question is: why?
If we do/did decide that this is the way to go, we should at least be consistent and do it everywhere in the UI, otherwise it just causes frustrations.
There’s a difference. For the Edit/Add button click the button will do what the user wants. Click the arrow is only for advanced featurs.
"It seems they either don’t understand the little triangles and what it’s about (submenu?) or they click on the menu itself and go to another page when they were expecting some menu to drop down, or.."
There is no difference from the "problem" you have mentioned in the OP. The user sees an arrow and clicks on the button to expand the menu, but instead ends up reloading the page (either to edit mode or to view mode, same thing). You will say that he wanted to edit anyway, yes, but maybe he did not want to edit in the default mode, so the user's "intent" (as you defined it in the OP) is still not respected.
We either do it one way, or the other, all I ask for is consistency. Do we want to introduce yet another compromise in this young skin?
The problem I saw is that users were not clicking the arrow but the main button part (thus navigating instead of having the main options).
What we want is that it’s the simplest possible for the user for his use case at hand: - When I click Edit or Add (not the arrow, the button) it’s the simplest possible. Edit will choose the good default mode and add will add a page - When I click the wiki/space/page button (not the arrow) I want the actions to be displayed rather than the navigation since navigation is a secondary use case for these buttons
At least that’s how I view it.
Forcing the user to have 2 clicks to do the main action on a button would be a pity.
Now you’re going to say that we could keep the arrow for the wiki/space/page buttons to navigate. We could, but it doesn’t feel natural.
What do you suggest?
Thanks -Vincent
Thanks, Eduard
Thanks -Vincent
Thanks, Eduard
On Fri, Oct 3, 2014 at 4:21 PM, Ecaterina Moraru (Valica) > > wrote:
On Wed, Sep 24, 2014 at 5:25 PM, Ecaterina Moraru (Valica) < [email protected]> wrote:
Hi,
Some background: * Colibri ** menus displayed on hover ** custom menu JS ** menu entries could be icon+label+separator+link+whatever
* Flamingo ** menus displayed on click ** menu component from Bootstrap ** it expects simple links or menu dropdown containers (not both functions)
Theoretically Bootstrap doesn't support our use case and cannot replicate by default the Colibri's behavior. Any change we want to make to the menu Bootstrap component means
we
are
branching from the default behavior and we will create a custom one. We really need to listen to clicks and not hover state, since we need to be mobile compatible.
It's normal that the users feel a bit confused since they are used with a certain behavior and we tried to mix them in order to have both menu and navigation use cases. And I think the reason is a bit confusing is that the separation between the link and the arrow is invisible, compared with the btn-groups used for Edit or Add. For example, I think that making the separation more clean, like in this screenshot http://jira.xwiki.org/secure/attachment/28807/btn-group.png would improve a bit the things, but would need visual improvements and is not default also. Maybe we could think of a better solution if we were to go on this path.
Behavior like double clicking a certain element will be a hidden interaction for the users. Double clicking is not a Web behavior and you cannot expect users to know on which links to simple click vs. on which to double click. In the usability testing sessions users had a hard time to double click on uploading image in the WYSIWYG popup, so I'm not sure about this approach's success.
Regarding the IntelliJ IDEA screenshot, we already discuss about this idea and even made a similar proposal some long time ago, see
http://design.xwiki.org/xwiki/bin/view/Improvements/ActionMenuNavigation
Although this proposal is a nice idea and I would like to have it, I don't see how this would 'simplify' the current implementation. IMO it will make it even more complex and we would certainly need a custom menu. Also I see this as a new feature, than a solution to our current problem.
When we implemented the current solution we discussed if the navigation should be put on the text or on the icon, see http://jira.xwiki.org/browse/XWIKI-10449 . The main problem is the findability of this functionality. Users might never press that icon (this problem applies to the solution brainstorming and the breadcrumb proposal).
So I think the idea to have an entry with "Go to ..." could be a solution and to keep the menus interact with the default behavior (removing the navigation from the dropdown activator). Removing triangles is not an option. That is a default menu marker caret.
So what are the next steps? We do a issue with the "Go to ..." solution?
http://jira.xwiki.org/browse/XWIKI-11166
Thanks, Caty
On Wed, Sep 24, 2014 at 11:55 AM, Guillaume "Louis-Marie" Delhumeau < [email protected]> wrote:
> Hi. > > I am happy that this topic is coming back. > > 2014-09-24 10:04 GMT+02:00 [email protected] : > > > Hi devs, > > > > I’ve had a few persons tell me that they don’t like the small arrow in > the > > top level menu in Flamingo. It seems they either don’t understand the > > little triangles and what it’s about (submenu?) or they click on the > menu > > itself and go to another page when they were expecting some menu to drop > > down, or... > > > > I don't like it neither. It is not consistent with other projects (such as > JIRA). It is not consistent with what we are planning to do about the UI > language (see: > >
http://design.xwiki.org/xwiki/bin/download/Proposal/InterfaceAndContentLangu...
> ). > It is harder to use on mobiles, and people are surprised by what occurs > when they click on it. > > > > > > In addition we’re still missing a solution to easily navigate the wiki > > from any page (there’s the ctrl+G solution but this is more like a > shortcut > > to know and we need something more). > > > > So here are some ideas: > > > > * For the top level menu, make it simpler by having the drop down > display > > when you click anywhere in the menu (the whole width of it) and only > > navigate when you double click (there are actually few reasons to need > to > > navigate with the other idea below so we could also not do the double > click > > thing) > > > > +1 > > > > > > * In the breadcrumb OR in the top level menu OR in both (to be decided) > > use something like this (screenshot taken from IntelliJ IDEA): > > > > >
https://www.evernote.com/shard/s119/sh/20e99ab3-2991-4aa8-a7b5-93088aad4944/...
> > > > This means when you click at a given level you get to see all sibling > > elements in the wiki for element you’re currently on (document, space, > > wiki). > > > > For example clicking on the “Home” wiki would show: > > - A filter box allowing you to type and it would auto suggest as you > type, > > completing with wiki names > > - An icon would be displayed on the left (or on the right) of the filter > > box and if you click on it you’ll go the index page (Wiki Index in this > > case) > > - A list of the first 10 wikis (an improvement would be to list first > the > > wiki that you’ve last navigated to) > > > > Same would apply for spaces and pages. > > > > We could even imagine that when you’re on a user profile page, clicking > on > > it would display other user pages and the filter would filter on user > > pages. Actually we could imagine to when the current page has XObjects > in > > it, it would be possible to list all other pages in the wiki having the > > same XClass. And if there are several XObjects, then somehow in the UI > > allow selecting which one to consider as the filter criteria. > > > > * Note 1: The breadcrumb is currently not displayed on all pages (it’s > not > > on the home page for example) and thus if we implement this idea in the > > breadcrumb only then there’s no solution for navigating on the home > page. > > > > This is a behaviour that I have put because I thought it was not pretty to > have a useless breadcrumb on the home page. It can be changed. > > > > > > * Note 2: If we were to implement this idea on the top level menu, then > we > > still need to display the actions too. Several options: > > - a) Display the actions first and the navigation list after separated > by > > a ----- > > - b) Have a first entry in the drop down that says “Actions...” and when > > you move the mouse over it a secondary menu with all actions are > displayed. > > Note that the alternative is possible too: Display the actions and have > a > > “Go to..." menu entry. We would just need to choose to display what we > > think is the most used default (actions or navigation) > > > > +1 > > > > > > WDYT? > > > > Personally I would do this: > > - implement this idea for the breadcrumb > > > > +0, I need to think more about it > > > > - add “Go to wiki...”, “Go to space...", “Go to page..." menu entries in > > the Wiki/Space/Page top level menus > > > > +1 > > > > - expand the menu selection to the whole width for displaying the drop > > down (and not just above the small arrow) > > > > +1 > > > > - either support double-click or simply add the possibility to navigate > to > > that element in the “Go to xxx...” submenu > > > > +1 > > > > > > Thanks > > -Vincent > > > > > > _______________________________________________ > > devs mailing list > > [email protected] > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > > -- > Guillaume Delhumeau ([email protected]) > Research & Development Engineer at XWiki SAS > Committer on the XWiki.org project > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs >
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On 9 Oct 2014 at 17:57:46, Jeremie BOUSQUET ([email protected](mailto:[email protected])) wrote:
Hi,
In fact, colibri top-menu was better than bootstrap buttons ! :D
Why not putting back old ways of interacting ? - re-add display of dropdown menu on hover [1] - re-add underlining on hover of links in menu text
The reason we changed that was for mobiles. We could decide to have different behaviors on mobile and desktops but not sure it’s best. WDYT? Thanks -Vincent
Problem I feel is for second item as it seems bootstrap won't easily allow you to hover on something (for dropdown) and click on it (to do something else than show dropdown). Also I suppose there are impacts on mobile version.
I don't think the new flamingo way is bad, but visually it looks very similar to colibri (a text + a little triangle), but when you hover nothing happens, and you have no visual clue that something different may happen if you click on the text or on the triangle. For example take the "New" button in Outlook 2007 which is exactly a dropdown button, when I hover on it I see a clear separation between the "New" text, and the arrow, so I can assume that both lead to different results.
With the "Add" and "Edit" buttons it's completely different, you see the separation, and on hoovering the color changes (of the text OR of the arrow background). You are prepared to the fact that something different will occur. But doing the same in top menu would clearly not fit expected look&feel of this beautiful skin...
BR, Jeremie
[1] - http://cameronspear.com/demos/bootstrap-hover-dropdown/
2014-10-09 16:02 GMT+02:00 [email protected] :
On 9 Oct 2014 at 14:23:49, Eduard Moraru ([email protected](mailto: [email protected])) wrote:
On Thu, Oct 9, 2014 at 3:15 PM, [email protected] wrote:
On 9 Oct 2014 at 14:02:05, Eduard Moraru ([email protected](mailto: [email protected])) wrote:
Folks, you speak of consistency and then come up with this
solution...
So we have a problem with "non-standard bootstrap dropdown buttons"
that
our users (whoever they may be) have a problem with understanding that there is either an action or a dropdown involved in the same button, like they can encounter in other interfaces along their computer usage history.
Our solution is to stop using the mixed mode, and only use the "standard bootstrap dropdown buttons" that have their first action in the submenu the thing that would have happened in the past when the users clicked directly the action part of the "mixed button" we were using.
Ok, we implement this solution, but we only do it for the top navigational elements. We completely ignore the "Add" and the "Edit" buttons that "suffer" from exactly the same "problem".
My question is: why?
If we do/did decide that this is the way to go, we should at least be consistent and do it everywhere in the UI, otherwise it just causes frustrations.
There’s a difference. For the Edit/Add button click the button will do what the user wants. Click the arrow is only for advanced featurs.
"It seems they either don’t understand the little triangles and what it’s about (submenu?) or they click on the menu itself and go to another page when they were expecting some menu to drop down, or.."
There is no difference from the "problem" you have mentioned in the OP. The user sees an arrow and clicks on the button to expand the menu, but instead ends up reloading the page (either to edit mode or to view mode, same thing). You will say that he wanted to edit anyway, yes, but maybe he did not want to edit in the default mode, so the user's "intent" (as you defined it in the OP) is still not respected.
We either do it one way, or the other, all I ask for is consistency. Do we want to introduce yet another compromise in this young skin?
The problem I saw is that users were not clicking the arrow but the main button part (thus navigating instead of having the main options).
What we want is that it’s the simplest possible for the user for his use case at hand: - When I click Edit or Add (not the arrow, the button) it’s the simplest possible. Edit will choose the good default mode and add will add a page - When I click the wiki/space/page button (not the arrow) I want the actions to be displayed rather than the navigation since navigation is a secondary use case for these buttons
At least that’s how I view it.
Forcing the user to have 2 clicks to do the main action on a button would be a pity.
Now you’re going to say that we could keep the arrow for the wiki/space/page buttons to navigate. We could, but it doesn’t feel natural.
What do you suggest?
Thanks -Vincent
Thanks, Eduard
Thanks -Vincent
Thanks, Eduard
On Fri, Oct 3, 2014 at 4:21 PM, Ecaterina Moraru (Valica) > > wrote:
On Wed, Sep 24, 2014 at 5:25 PM, Ecaterina Moraru (Valica) < [email protected]> wrote:
> Hi, > > Some background: > * Colibri > ** menus displayed on hover > ** custom menu JS > ** menu entries could be icon+label+separator+link+whatever > > * Flamingo > ** menus displayed on click > ** menu component from Bootstrap > ** it expects simple links or menu dropdown containers (not both functions) > > Theoretically Bootstrap doesn't support our use case and cannot replicate > by default the Colibri's behavior. > Any change we want to make to the menu Bootstrap component means
we
are
> branching from the default behavior and we will create a custom one. > We really need to listen to clicks and not hover state, since we need to > be mobile compatible. > > It's normal that the users feel a bit confused since they are used with a > certain behavior and we tried to mix them in order to have both menu and > navigation use cases. > And I think the reason is a bit confusing is that the separation between > the link and the arrow is invisible, compared with the btn-groups used for > Edit or Add. For example, I think that making the separation more clean, > like in this screenshot > http://jira.xwiki.org/secure/attachment/28807/btn-group.png would improve > a bit the things, but would need visual improvements and is not default > also. Maybe we could think of a better solution if we were to go on this > path. > > Behavior like double clicking a certain element will be a hidden > interaction for the users. Double clicking is not a Web behavior and you > cannot expect users to know on which links to simple click vs. on which to > double click. In the usability testing sessions users had a hard time to > double click on uploading image in the WYSIWYG popup, so I'm not sure about > this approach's success. > > Regarding the IntelliJ IDEA screenshot, we already discuss about this idea > and even made a similar proposal some long time ago, see >
http://design.xwiki.org/xwiki/bin/view/Improvements/ActionMenuNavigation
> Although this proposal is a nice idea and I would like to have it, I don't > see how this would 'simplify' the current implementation. IMO it will make > it even more complex and we would certainly need a custom menu. Also I see > this as a new feature, than a solution to our current problem. > > When we implemented the current solution we discussed if the navigation > should be put on the text or on the icon, see > http://jira.xwiki.org/browse/XWIKI-10449 . The main problem is the > findability of this functionality. Users might never press that icon (this > problem applies to the solution brainstorming and the breadcrumb proposal). > > So I think the idea to have an entry with "Go to ..." could be a solution > and to keep the menus interact with the default behavior (removing the > navigation from the dropdown activator). > Removing triangles is not an option. That is a default menu marker caret. > > So what are the next steps? We do a issue with the "Go to ..." solution? >
http://jira.xwiki.org/browse/XWIKI-11166
> Thanks, > Caty > > On Wed, Sep 24, 2014 at 11:55 AM, Guillaume "Louis-Marie" Delhumeau < > [email protected]> wrote: > >> Hi. >> >> I am happy that this topic is coming back. >> >> 2014-09-24 10:04 GMT+02:00 [email protected] : >> >> > Hi devs, >> > >> > I’ve had a few persons tell me that they don’t like the small arrow in >> the >> > top level menu in Flamingo. It seems they either don’t understand the >> > little triangles and what it’s about (submenu?) or they click on the >> menu >> > itself and go to another page when they were expecting some menu to drop >> > down, or... >> > >> >> I don't like it neither. It is not consistent with other projects (such as >> JIRA). It is not consistent with what we are planning to do about the UI >> language (see: >> >>
http://design.xwiki.org/xwiki/bin/download/Proposal/InterfaceAndContentLangu...
>> ). >> It is harder to use on mobiles, and people are surprised by what occurs >> when they click on it. >> >> >> > >> > In addition we’re still missing a solution to easily navigate the wiki >> > from any page (there’s the ctrl+G solution but this is more like a >> shortcut >> > to know and we need something more). >> > >> > So here are some ideas: >> > >> > * For the top level menu, make it simpler by having the drop down >> display >> > when you click anywhere in the menu (the whole width of it) and only >> > navigate when you double click (there are actually few reasons to need >> to >> > navigate with the other idea below so we could also not do the double >> click >> > thing) >> > >> >> +1 >> >> >> > >> > * In the breadcrumb OR in the top level menu OR in both (to be decided) >> > use something like this (screenshot taken from IntelliJ IDEA): >> > >> > >>
https://www.evernote.com/shard/s119/sh/20e99ab3-2991-4aa8-a7b5-93088aad4944/...
>> > >> > This means when you click at a given level you get to see all sibling >> > elements in the wiki for element you’re currently on (document, space, >> > wiki). >> > >> > For example clicking on the “Home” wiki would show: >> > - A filter box allowing you to type and it would auto suggest as you >> type, >> > completing with wiki names >> > - An icon would be displayed on the left (or on the right) of the filter >> > box and if you click on it you’ll go the index page (Wiki Index in this >> > case) >> > - A list of the first 10 wikis (an improvement would be to list first >> the >> > wiki that you’ve last navigated to) >> > >> > Same would apply for spaces and pages. >> > >> > We could even imagine that when you’re on a user profile page, clicking >> on >> > it would display other user pages and the filter would filter on user >> > pages. Actually we could imagine to when the current page has XObjects >> in >> > it, it would be possible to list all other pages in the wiki having the >> > same XClass. And if there are several XObjects, then somehow in the UI >> > allow selecting which one to consider as the filter criteria. >> > >> > * Note 1: The breadcrumb is currently not displayed on all pages (it’s >> not >> > on the home page for example) and thus if we implement this idea in the >> > breadcrumb only then there’s no solution for navigating on the home >> page. >> > >> >> This is a behaviour that I have put because I thought it was not pretty to >> have a useless breadcrumb on the home page. It can be changed. >> >> >> > >> > * Note 2: If we were to implement this idea on the top level menu, then >> we >> > still need to display the actions too. Several options: >> > - a) Display the actions first and the navigation list after separated >> by >> > a ----- >> > - b) Have a first entry in the drop down that says “Actions...” and when >> > you move the mouse over it a secondary menu with all actions are >> displayed. >> > Note that the alternative is possible too: Display the actions and have >> a >> > “Go to..." menu entry. We would just need to choose to display what we >> > think is the most used default (actions or navigation) >> > >> >> +1 >> >> >> > >> > WDYT? >> > >> > Personally I would do this: >> > - implement this idea for the breadcrumb >> > >> >> +0, I need to think more about it >> >> >> > - add “Go to wiki...”, “Go to space...", “Go to page..." menu entries in >> > the Wiki/Space/Page top level menus >> > >> >> +1 >> >> >> > - expand the menu selection to the whole width for displaying the drop >> > down (and not just above the small arrow) >> > >> >> +1 >> >> >> > - either support double-click or simply add the possibility to navigate >> to >> > that element in the “Go to xxx...” submenu >> > >> >> +1 >> >> >> > >> > Thanks >> > -Vincent >> > >> > >> > _______________________________________________ >> > devs mailing list >> > [email protected] >> > http://lists.xwiki.org/mailman/listinfo/devs >> > >> >> >> >> -- >> Guillaume Delhumeau ([email protected]) >> Research & Development Engineer at XWiki SAS >> Committer on the XWiki.org project >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs >> > > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
2014-10-09 17:59 GMT+02:00 [email protected] <[email protected]>:
On 9 Oct 2014 at 17:57:46, Jeremie BOUSQUET ([email protected] (mailto:[email protected])) wrote:
Hi,
In fact, colibri top-menu was better than bootstrap buttons ! :D
Why not putting back old ways of interacting ? - re-add display of dropdown menu on hover [1] - re-add underlining on hover of links in menu text
The reason we changed that was for mobiles. We could decide to have different behaviors on mobile and desktops but not sure it’s best. WDYT?
Windows 8 decided to have same behaviors on mobile and desktop, but not sure it was best ... ;-) Particularly because they restricted desktop version because of mobile limitations. Taken the other way, if I had a sensitive screen on my computer, and I could tap on it with my finger, I would do the same error of taping on the text instead of the arrow I suppose, so I'm not sure it's a problem of mobile/desktop. 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 [email protected] :
On 9 Oct 2014 at 14:23:49, Eduard Moraru ([email protected](mailto: [email protected])) wrote:
On Thu, Oct 9, 2014 at 3:15 PM, [email protected] wrote:
On 9 Oct 2014 at 14:02:05, Eduard Moraru ([email protected]
(mailto:
[email protected])) wrote:
Folks, you speak of consistency and then come up with this solution...
So we have a problem with "non-standard bootstrap dropdown buttons" that our users (whoever they may be) have a problem with understanding that there is either an action or a dropdown involved in the same button, like they can encounter in other interfaces along their computer usage history.
Our solution is to stop using the mixed mode, and only use the "standard bootstrap dropdown buttons" that have their first action in the submenu the thing that would have happened in the past when the users clicked directly the action part of the "mixed button" we were using.
Ok, we implement this solution, but we only do it for the top navigational elements. We completely ignore the "Add" and the "Edit" buttons that "suffer" from exactly the same "problem".
My question is: why?
If we do/did decide that this is the way to go, we should at least be consistent and do it everywhere in the UI, otherwise it just causes frustrations.
There’s a difference. For the Edit/Add button click the button will do what the user wants. Click the arrow is only for advanced featurs.
"It seems they either don’t understand the little triangles and what it’s about (submenu?) or they click on the menu itself and go to another page when they were expecting some menu to drop down, or.."
There is no difference from the "problem" you have mentioned in the OP. The user sees an arrow and clicks on the button to expand the menu, but instead ends up reloading the page (either to edit mode or to view mode, same thing). You will say that he wanted to edit anyway, yes, but maybe he did not want to edit in the default mode, so the user's "intent" (as you defined it in the OP) is still not respected.
We either do it one way, or the other, all I ask for is consistency. Do we want to introduce yet another compromise in this young skin?
The problem I saw is that users were not clicking the arrow but the main button part (thus navigating instead of having the main options).
What we want is that it’s the simplest possible for the user for his use case at hand: - When I click Edit or Add (not the arrow, the button) it’s the simplest possible. Edit will choose the good default mode and add will add a page - When I click the wiki/space/page button (not the arrow) I want the actions to be displayed rather than the navigation since navigation is a secondary use case for these buttons
At least that’s how I view it.
Forcing the user to have 2 clicks to do the main action on a button would be a pity.
Now you’re going to say that we could keep the arrow for the wiki/space/page buttons to navigate. We could, but it doesn’t feel natural.
What do you suggest?
Thanks -Vincent
Thanks, Eduard
Thanks -Vincent
Thanks, Eduard
On Fri, Oct 3, 2014 at 4:21 PM, Ecaterina Moraru (Valica) > >
wrote:
> On Wed, Sep 24, 2014 at 5:25 PM, Ecaterina Moraru (Valica) < > [email protected]> wrote: > > > Hi, > > > > Some background: > > * Colibri > > ** menus displayed on hover > > ** custom menu JS > > ** menu entries could be icon+label+separator+link+whatever > > > > * Flamingo > > ** menus displayed on click > > ** menu component from Bootstrap > > ** it expects simple links or menu dropdown containers (not
both
> functions) > > > > Theoretically Bootstrap doesn't support our use case and cannot replicate > > by default the Colibri's behavior. > > Any change we want to make to the menu Bootstrap component means we are > > branching from the default behavior and we will create a custom one. > > We really need to listen to clicks and not hover state, since we need to > > be mobile compatible. > > > > It's normal that the users feel a bit confused since they are used with a > > certain behavior and we tried to mix them in order to have both menu and > > navigation use cases. > > And I think the reason is a bit confusing is that the separation between > > the link and the arrow is invisible, compared with the btn-groups used > for > > Edit or Add. For example, I think that making the separation more clean, > > like in this screenshot > > http://jira.xwiki.org/secure/attachment/28807/btn-group.png would > improve > > a bit the things, but would need visual improvements and is not default > > also. Maybe we could think of a better solution if we were to go on this > > path. > > > > Behavior like double clicking a certain element will be a hidden > > interaction for the users. Double clicking is not a Web behavior and you > > cannot expect users to know on which links to simple click vs. on which > to > > double click. In the usability testing sessions users had a hard time to > > double click on uploading image in the WYSIWYG popup, so I'm not sure > about > > this approach's success. > > > > Regarding the IntelliJ IDEA screenshot, we already discuss about this > idea > > and even made a similar proposal some long time ago, see > >
http://design.xwiki.org/xwiki/bin/view/Improvements/ActionMenuNavigation
> > Although this proposal is a nice idea and I would like to have it, I > don't > > see how this would 'simplify' the current implementation. IMO it will > make > > it even more complex and we would certainly need a custom menu. Also I > see > > this as a new feature, than a solution to our current problem. > > > > When we implemented the current solution we discussed if the navigation > > should be put on the text or on the icon, see > > http://jira.xwiki.org/browse/XWIKI-10449 . The main problem is the > > findability of this functionality. Users might never press that icon > (this > > problem applies to the solution brainstorming and the breadcrumb > proposal). > > > > So I think the idea to have an entry with "Go to ..." could be a solution > > and to keep the menus interact with the default behavior (removing the > > navigation from the dropdown activator). > > Removing triangles is not an option. That is a default menu marker caret. > > > > So what are the next steps? We do a issue with the "Go to ..." solution? > > > > http://jira.xwiki.org/browse/XWIKI-11166 > > > > Thanks, > > Caty > > > > On Wed, Sep 24, 2014 at 11:55 AM, Guillaume "Louis-Marie" Delhumeau < > > [email protected]> wrote: > > > >> Hi. > >> > >> I am happy that this topic is coming back. > >> > >> 2014-09-24 10:04 GMT+02:00 [email protected] : > >> > >> > Hi devs, > >> > > >> > I’ve had a few persons tell me that they don’t like the small arrow in > >> the > >> > top level menu in Flamingo. It seems they either don’t understand the > >> > little triangles and what it’s about (submenu?) or they click on the > >> menu > >> > itself and go to another page when they were expecting some menu to > drop > >> > down, or... > >> > > >> > >> I don't like it neither. It is not consistent with other projects (such > as > >> JIRA). It is not consistent with what we are planning to do about the UI > >> language (see: > >> > >> >
http://design.xwiki.org/xwiki/bin/download/Proposal/InterfaceAndContentLangu...
> >> ). > >> It is harder to use on mobiles, and people are surprised by what occurs > >> when they click on it. > >> > >> > >> > > >> > In addition we’re still missing a solution to easily navigate the wiki > >> > from any page (there’s the ctrl+G solution but this is more like a > >> shortcut > >> > to know and we need something more). > >> > > >> > So here are some ideas: > >> > > >> > * For the top level menu, make it simpler by having the drop down > >> display > >> > when you click anywhere in the menu (the whole width of it) and only > >> > navigate when you double click (there are actually few reasons to need > >> to > >> > navigate with the other idea below so we could also not do the double > >> click > >> > thing) > >> > > >> > >> +1 > >> > >> > >> > > >> > * In the breadcrumb OR in the top level menu OR in both (to be > decided) > >> > use something like this (screenshot taken from IntelliJ IDEA): > >> > > >> > > >> >
https://www.evernote.com/shard/s119/sh/20e99ab3-2991-4aa8-a7b5-93088aad4944/...
> >> > > >> > This means when you click at a given level you get to see all sibling > >> > elements in the wiki for element you’re currently on (document, space, > >> > wiki). > >> > > >> > For example clicking on the “Home” wiki would show: > >> > - A filter box allowing you to type and it would auto suggest as you > >> type, > >> > completing with wiki names > >> > - An icon would be displayed on the left (or on the right) of the > filter > >> > box and if you click on it you’ll go the index page (Wiki Index in > this > >> > case) > >> > - A list of the first 10 wikis (an improvement would be to list first > >> the > >> > wiki that you’ve last navigated to) > >> > > >> > Same would apply for spaces and pages. > >> > > >> > We could even imagine that when you’re on a user profile page, > clicking > >> on > >> > it would display other user pages and the filter would filter on user > >> > pages. Actually we could imagine to when the current page has XObjects > >> in > >> > it, it would be possible to list all other pages in the wiki having > the > >> > same XClass. And if there are several XObjects, then somehow in the UI > >> > allow selecting which one to consider as the filter criteria. > >> > > >> > * Note 1: The breadcrumb is currently not displayed on all pages (it’s > >> not > >> > on the home page for example) and thus if we implement this idea in > the > >> > breadcrumb only then there’s no solution for navigating on the home > >> page. > >> > > >> > >> This is a behaviour that I have put because I thought it was not pretty > to > >> have a useless breadcrumb on the home page. It can be changed. > >> > >> > >> > > >> > * Note 2: If we were to implement this idea on the top level menu, > then > >> we > >> > still need to display the actions too. Several options: > >> > - a) Display the actions first and the navigation list after separated > >> by > >> > a ----- > >> > - b) Have a first entry in the drop down that says “Actions...” and > when > >> > you move the mouse over it a secondary menu with all actions are > >> displayed. > >> > Note that the alternative is possible too: Display the actions and > have > >> a > >> > “Go to..." menu entry. We would just need to choose to display what we > >> > think is the most used default (actions or navigation) > >> > > >> > >> +1 > >> > >> > >> > > >> > WDYT? > >> > > >> > Personally I would do this: > >> > - implement this idea for the breadcrumb > >> > > >> > >> +0, I need to think more about it > >> > >> > >> > - add “Go to wiki...”, “Go to space...", “Go to page..." menu entries > in > >> > the Wiki/Space/Page top level menus > >> > > >> > >> +1 > >> > >> > >> > - expand the menu selection to the whole width for displaying the drop > >> > down (and not just above the small arrow) > >> > > >> > >> +1 > >> > >> > >> > - either support double-click or simply add the possibility to > navigate > >> to > >> > that element in the “Go to xxx...” submenu > >> > > >> > >> +1 > >> > >> > >> > > >> > Thanks > >> > -Vincent > >> > > >> > > >> > _______________________________________________ > >> > devs mailing list > >> > [email protected] > >> > http://lists.xwiki.org/mailman/listinfo/devs > >> > > >> > >> > >> > >> -- > >> Guillaume Delhumeau ([email protected]) > >> Research & Development Engineer at XWiki SAS > >> Committer on the XWiki.org project > >> _______________________________________________ > >> devs mailing list > >> [email protected] > >> http://lists.xwiki.org/mailman/listinfo/devs > >> > > > > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On 9 Oct 2014 at 18:15:23, Jeremie BOUSQUET ([email protected](mailto:[email protected])) wrote:
2014-10-09 17:59 GMT+02:00 [email protected] :
On 9 Oct 2014 at 17:57:46, Jeremie BOUSQUET ([email protected] (mailto:[email protected])) wrote:
Hi,
In fact, colibri top-menu was better than bootstrap buttons ! :D
Why not putting back old ways of interacting ? - re-add display of dropdown menu on hover [1] - re-add underlining on hover of links in menu text
The reason we changed that was for mobiles. We could decide to have different behaviors on mobile and desktops but not sure it’s best. WDYT?
Windows 8 decided to have same behaviors on mobile and desktop, but not sure it was best ... ;-) Particularly because they restricted desktop version because of mobile limitations.
Taken the other way, if I had a sensitive screen on my computer, and I could tap on it with my finger, I would do the same error of taping on the text instead of the arrow I suppose, so I'm not sure it's a problem of mobile/desktop.
This is exactly what we fixed for the wiki/space/page menus so I’m glad you like it :)
I certainly would never think of double-taping anything inside my browser (particularly because I currently use double-tap to zoom in and out).
We don’t do that… Thanks -Vincent
Thanks -Vincent
Problem I feel is for second item as it seems bootstrap won't easily allow you to hover on something (for dropdown) and click on it (to do something else than show dropdown). Also I suppose there are impacts on mobile version.
I don't think the new flamingo way is bad, but visually it looks very similar to colibri (a text + a little triangle), but when you hover nothing happens, and you have no visual clue that something different may happen if you click on the text or on the triangle. For example take the "New" button in Outlook 2007 which is exactly a dropdown button, when I hover on it I see a clear separation between the "New" text, and the arrow, so I can assume that both lead to different results.
With the "Add" and "Edit" buttons it's completely different, you see the separation, and on hoovering the color changes (of the text OR of the arrow background). You are prepared to the fact that something different will occur. But doing the same in top menu would clearly not fit expected look&feel of this beautiful skin...
BR, Jeremie
[1] - http://cameronspear.com/demos/bootstrap-hover-dropdown/
2014-10-09 16:02 GMT+02:00 [email protected] :
On 9 Oct 2014 at 14:23:49, Eduard Moraru ([email protected](mailto: [email protected])) wrote:
On Thu, Oct 9, 2014 at 3:15 PM, [email protected] wrote:
On 9 Oct 2014 at 14:02:05, Eduard Moraru ([email protected]
(mailto:
[email protected])) wrote:
> Folks, you speak of consistency and then come up with this solution... > > So we have a problem with "non-standard bootstrap dropdown buttons" that > our users (whoever they may be) have a problem with understanding that > there is either an action or a dropdown involved in the same button, like > they can encounter in other interfaces along their computer usage history. > > Our solution is to stop using the mixed mode, and only use the "standard > bootstrap dropdown buttons" that have their first action in the submenu the > thing that would have happened in the past when the users clicked directly > the action part of the "mixed button" we were using. > > Ok, we implement this solution, but we only do it for the top navigational > elements. We completely ignore the "Add" and the "Edit" buttons that > "suffer" from exactly the same "problem". > > My question is: why? > > If we do/did decide that this is the way to go, we should at least be > consistent and do it everywhere in the UI, otherwise it just causes > frustrations.
There’s a difference. For the Edit/Add button click the button will do what the user wants. Click the arrow is only for advanced featurs.
"It seems they either don’t understand the little triangles and what it’s about (submenu?) or they click on the menu itself and go to another page when they were expecting some menu to drop down, or.."
There is no difference from the "problem" you have mentioned in the OP. The user sees an arrow and clicks on the button to expand the menu, but instead ends up reloading the page (either to edit mode or to view mode, same thing). You will say that he wanted to edit anyway, yes, but maybe he did not want to edit in the default mode, so the user's "intent" (as you defined it in the OP) is still not respected.
We either do it one way, or the other, all I ask for is consistency. Do we want to introduce yet another compromise in this young skin?
The problem I saw is that users were not clicking the arrow but the main button part (thus navigating instead of having the main options).
What we want is that it’s the simplest possible for the user for his use case at hand: - When I click Edit or Add (not the arrow, the button) it’s the simplest possible. Edit will choose the good default mode and add will add a page - When I click the wiki/space/page button (not the arrow) I want the actions to be displayed rather than the navigation since navigation is a secondary use case for these buttons
At least that’s how I view it.
Forcing the user to have 2 clicks to do the main action on a button would be a pity.
Now you’re going to say that we could keep the arrow for the wiki/space/page buttons to navigate. We could, but it doesn’t feel natural.
What do you suggest?
Thanks -Vincent
Thanks, Eduard
Thanks -Vincent
> Thanks, > Eduard > > On Fri, Oct 3, 2014 at 4:21 PM, Ecaterina Moraru (Valica) > >
wrote:
> > > On Wed, Sep 24, 2014 at 5:25 PM, Ecaterina Moraru (Valica) < > > [email protected]> wrote: > > > > > Hi, > > > > > > Some background: > > > * Colibri > > > ** menus displayed on hover > > > ** custom menu JS > > > ** menu entries could be icon+label+separator+link+whatever > > > > > > * Flamingo > > > ** menus displayed on click > > > ** menu component from Bootstrap > > > ** it expects simple links or menu dropdown containers (not both > > functions) > > > > > > Theoretically Bootstrap doesn't support our use case and cannot replicate > > > by default the Colibri's behavior. > > > Any change we want to make to the menu Bootstrap component means we are > > > branching from the default behavior and we will create a custom one. > > > We really need to listen to clicks and not hover state, since we need to > > > be mobile compatible. > > > > > > It's normal that the users feel a bit confused since they are used with a > > > certain behavior and we tried to mix them in order to have both menu and > > > navigation use cases. > > > And I think the reason is a bit confusing is that the separation between > > > the link and the arrow is invisible, compared with the btn-groups used > > for > > > Edit or Add. For example, I think that making the separation more clean, > > > like in this screenshot > > > http://jira.xwiki.org/secure/attachment/28807/btn-group.png would > > improve > > > a bit the things, but would need visual improvements and is not default > > > also. Maybe we could think of a better solution if we were to go on this > > > path. > > > > > > Behavior like double clicking a certain element will be a hidden > > > interaction for the users. Double clicking is not a Web behavior and you > > > cannot expect users to know on which links to simple click vs. on which > > to > > > double click. In the usability testing sessions users had a hard time to > > > double click on uploading image in the WYSIWYG popup, so I'm not sure > > about > > > this approach's success. > > > > > > Regarding the IntelliJ IDEA screenshot, we already discuss about this > > idea > > > and even made a similar proposal some long time ago, see > > >
http://design.xwiki.org/xwiki/bin/view/Improvements/ActionMenuNavigation
> > > Although this proposal is a nice idea and I would like to have it, I > > don't > > > see how this would 'simplify' the current implementation. IMO it will > > make > > > it even more complex and we would certainly need a custom menu. Also I > > see > > > this as a new feature, than a solution to our current problem. > > > > > > When we implemented the current solution we discussed if the navigation > > > should be put on the text or on the icon, see > > > http://jira.xwiki.org/browse/XWIKI-10449 . The main problem is the > > > findability of this functionality. Users might never press that icon > > (this > > > problem applies to the solution brainstorming and the breadcrumb > > proposal). > > > > > > So I think the idea to have an entry with "Go to ..." could be a solution > > > and to keep the menus interact with the default behavior (removing the > > > navigation from the dropdown activator). > > > Removing triangles is not an option. That is a default menu marker caret. > > > > > > So what are the next steps? We do a issue with the "Go to ..." solution? > > > > > > > http://jira.xwiki.org/browse/XWIKI-11166 > > > > > > > Thanks, > > > Caty > > > > > > On Wed, Sep 24, 2014 at 11:55 AM, Guillaume "Louis-Marie" Delhumeau < > > > [email protected]> wrote: > > > > > >> Hi. > > >> > > >> I am happy that this topic is coming back. > > >> > > >> 2014-09-24 10:04 GMT+02:00 [email protected] : > > >> > > >> > Hi devs, > > >> > > > >> > I’ve had a few persons tell me that they don’t like the small arrow in > > >> the > > >> > top level menu in Flamingo. It seems they either don’t understand the > > >> > little triangles and what it’s about (submenu?) or they click on the > > >> menu > > >> > itself and go to another page when they were expecting some menu to > > drop > > >> > down, or... > > >> > > > >> > > >> I don't like it neither. It is not consistent with other projects (such > > as > > >> JIRA). It is not consistent with what we are planning to do about the UI > > >> language (see: > > >> > > >> > >
http://design.xwiki.org/xwiki/bin/download/Proposal/InterfaceAndContentLangu...
> > >> ). > > >> It is harder to use on mobiles, and people are surprised by what occurs > > >> when they click on it. > > >> > > >> > > >> > > > >> > In addition we’re still missing a solution to easily navigate the wiki > > >> > from any page (there’s the ctrl+G solution but this is more like a > > >> shortcut > > >> > to know and we need something more). > > >> > > > >> > So here are some ideas: > > >> > > > >> > * For the top level menu, make it simpler by having the drop down > > >> display > > >> > when you click anywhere in the menu (the whole width of it) and only > > >> > navigate when you double click (there are actually few reasons to need > > >> to > > >> > navigate with the other idea below so we could also not do the double > > >> click > > >> > thing) > > >> > > > >> > > >> +1 > > >> > > >> > > >> > > > >> > * In the breadcrumb OR in the top level menu OR in both (to be > > decided) > > >> > use something like this (screenshot taken from IntelliJ IDEA): > > >> > > > >> > > > >> > >
https://www.evernote.com/shard/s119/sh/20e99ab3-2991-4aa8-a7b5-93088aad4944/...
> > >> > > > >> > This means when you click at a given level you get to see all sibling > > >> > elements in the wiki for element you’re currently on (document, space, > > >> > wiki). > > >> > > > >> > For example clicking on the “Home” wiki would show: > > >> > - A filter box allowing you to type and it would auto suggest as you > > >> type, > > >> > completing with wiki names > > >> > - An icon would be displayed on the left (or on the right) of the > > filter > > >> > box and if you click on it you’ll go the index page (Wiki Index in > > this > > >> > case) > > >> > - A list of the first 10 wikis (an improvement would be to list first > > >> the > > >> > wiki that you’ve last navigated to) > > >> > > > >> > Same would apply for spaces and pages. > > >> > > > >> > We could even imagine that when you’re on a user profile page, > > clicking > > >> on > > >> > it would display other user pages and the filter would filter on user > > >> > pages. Actually we could imagine to when the current page has XObjects > > >> in > > >> > it, it would be possible to list all other pages in the wiki having > > the > > >> > same XClass. And if there are several XObjects, then somehow in the UI > > >> > allow selecting which one to consider as the filter criteria. > > >> > > > >> > * Note 1: The breadcrumb is currently not displayed on all pages (it’s > > >> not > > >> > on the home page for example) and thus if we implement this idea in > > the > > >> > breadcrumb only then there’s no solution for navigating on the home > > >> page. > > >> > > > >> > > >> This is a behaviour that I have put because I thought it was not pretty > > to > > >> have a useless breadcrumb on the home page. It can be changed. > > >> > > >> > > >> > > > >> > * Note 2: If we were to implement this idea on the top level menu, > > then > > >> we > > >> > still need to display the actions too. Several options: > > >> > - a) Display the actions first and the navigation list after separated > > >> by > > >> > a ----- > > >> > - b) Have a first entry in the drop down that says “Actions...” and > > when > > >> > you move the mouse over it a secondary menu with all actions are > > >> displayed. > > >> > Note that the alternative is possible too: Display the actions and > > have > > >> a > > >> > “Go to..." menu entry. We would just need to choose to display what we > > >> > think is the most used default (actions or navigation) > > >> > > > >> > > >> +1 > > >> > > >> > > >> > > > >> > WDYT? > > >> > > > >> > Personally I would do this: > > >> > - implement this idea for the breadcrumb > > >> > > > >> > > >> +0, I need to think more about it > > >> > > >> > > >> > - add “Go to wiki...”, “Go to space...", “Go to page..." menu entries > > in > > >> > the Wiki/Space/Page top level menus > > >> > > > >> > > >> +1 > > >> > > >> > > >> > - expand the menu selection to the whole width for displaying the drop > > >> > down (and not just above the small arrow) > > >> > > > >> > > >> +1 > > >> > > >> > > >> > - either support double-click or simply add the possibility to > > navigate > > >> to > > >> > that element in the “Go to xxx...” submenu > > >> > > > >> > > >> +1 > > >> > > >> > > >> > > > >> > Thanks > > >> > -Vincent > > >> > > > >> > > > >> > _______________________________________________ > > >> > devs mailing list > > >> > [email protected] > > >> > http://lists.xwiki.org/mailman/listinfo/devs > > >> > > > >> > > >> > > >> > > >> -- > > >> Guillaume Delhumeau ([email protected]) > > >> Research & Development Engineer at XWiki SAS > > >> Committer on the XWiki.org project > > >> _______________________________________________ > > >> devs mailing list > > >> [email protected] > > >> http://lists.xwiki.org/mailman/listinfo/devs > > >> > > > > > > > > _______________________________________________ > > devs mailing list > > [email protected] > > http://lists.xwiki.org/mailman/listinfo/devs > > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Thu, Oct 9, 2014 at 5:59 PM, [email protected] <[email protected]> wrote:
On 9 Oct 2014 at 17:57:46, Jeremie BOUSQUET ([email protected] (mailto:[email protected])) wrote:
Hi,
In fact, colibri top-menu was better than bootstrap buttons ! :D
Why not putting back old ways of interacting ? - re-add display of dropdown menu on hover [1] - re-add underlining on hover of links in menu text
The reason we changed that was for mobiles. We could decide to have different behaviors on mobile and desktops but not sure it’s best. WDYT?
I think it's not bad to have a slightly different behaviour for desktop and mobile. I don't have much experience with this but I think that we should not ruin desktop experience because it has to work on mobile. If different behaviour is the solution, let's do it. I think the old behaviour with the hover was quite natural, and the fact that bootstrap does not have those buttons by default is because it's mobile first. But, as much as we'd want it, XWiki is not yet mobile first (I would say most of the usage of XWiki today is still desktop, but since I don't have statistics I cannot prove it. I can only use my personal statistic, from my experience and the cases I know). 2 clicks feels completely unnatural on desktop, especially when coming from colibri. I would not want to let Bootstrap kill our UI choices, I think it's the bad reason to say that "we won't do it because bootstrap does not have a default component for it". Thanks, Anca
Thanks -Vincent
Problem I feel is for second item as it seems bootstrap won't easily allow you to hover on something (for dropdown) and click on it (to do something else than show dropdown). Also I suppose there are impacts on mobile version.
I don't think the new flamingo way is bad, but visually it looks very similar to colibri (a text + a little triangle), but when you hover nothing happens, and you have no visual clue that something different may happen if you click on the text or on the triangle. For example take the "New" button in Outlook 2007 which is exactly a dropdown button, when I hover on it I see a clear separation between the "New" text, and the arrow, so I can assume that both lead to different results.
With the "Add" and "Edit" buttons it's completely different, you see the separation, and on hoovering the color changes (of the text OR of the arrow background). You are prepared to the fact that something different will occur. But doing the same in top menu would clearly not fit expected look&feel of this beautiful skin...
BR, Jeremie
[1] - http://cameronspear.com/demos/bootstrap-hover-dropdown/
2014-10-09 16:02 GMT+02:00 [email protected] :
On 9 Oct 2014 at 14:23:49, Eduard Moraru ([email protected](mailto: [email protected])) wrote:
On Thu, Oct 9, 2014 at 3:15 PM, [email protected] wrote:
On 9 Oct 2014 at 14:02:05, Eduard Moraru ([email protected]
(mailto:
[email protected])) wrote:
Folks, you speak of consistency and then come up with this solution...
So we have a problem with "non-standard bootstrap dropdown buttons" that our users (whoever they may be) have a problem with understanding that there is either an action or a dropdown involved in the same button, like they can encounter in other interfaces along their computer usage history.
Our solution is to stop using the mixed mode, and only use the "standard bootstrap dropdown buttons" that have their first action in the submenu the thing that would have happened in the past when the users clicked directly the action part of the "mixed button" we were using.
Ok, we implement this solution, but we only do it for the top navigational elements. We completely ignore the "Add" and the "Edit" buttons that "suffer" from exactly the same "problem".
My question is: why?
If we do/did decide that this is the way to go, we should at least be consistent and do it everywhere in the UI, otherwise it just causes frustrations.
There’s a difference. For the Edit/Add button click the button will do what the user wants. Click the arrow is only for advanced featurs.
"It seems they either don’t understand the little triangles and what it’s about (submenu?) or they click on the menu itself and go to another page when they were expecting some menu to drop down, or.."
There is no difference from the "problem" you have mentioned in the OP. The user sees an arrow and clicks on the button to expand the menu, but instead ends up reloading the page (either to edit mode or to view mode, same thing). You will say that he wanted to edit anyway, yes, but maybe he did not want to edit in the default mode, so the user's "intent" (as you defined it in the OP) is still not respected.
We either do it one way, or the other, all I ask for is consistency. Do we want to introduce yet another compromise in this young skin?
The problem I saw is that users were not clicking the arrow but the main button part (thus navigating instead of having the main options).
What we want is that it’s the simplest possible for the user for his use case at hand: - When I click Edit or Add (not the arrow, the button) it’s the simplest possible. Edit will choose the good default mode and add will add a page - When I click the wiki/space/page button (not the arrow) I want the actions to be displayed rather than the navigation since navigation is a secondary use case for these buttons
At least that’s how I view it.
Forcing the user to have 2 clicks to do the main action on a button would be a pity.
Now you’re going to say that we could keep the arrow for the wiki/space/page buttons to navigate. We could, but it doesn’t feel natural.
What do you suggest?
Thanks -Vincent
Thanks, Eduard
Thanks -Vincent
Thanks, Eduard
On Fri, Oct 3, 2014 at 4:21 PM, Ecaterina Moraru (Valica) > >
wrote:
> On Wed, Sep 24, 2014 at 5:25 PM, Ecaterina Moraru (Valica) < > [email protected]> wrote: > > > Hi, > > > > Some background: > > * Colibri > > ** menus displayed on hover > > ** custom menu JS > > ** menu entries could be icon+label+separator+link+whatever > > > > * Flamingo > > ** menus displayed on click > > ** menu component from Bootstrap > > ** it expects simple links or menu dropdown containers (not
both
> functions) > > > > Theoretically Bootstrap doesn't support our use case and cannot replicate > > by default the Colibri's behavior. > > Any change we want to make to the menu Bootstrap component means we are > > branching from the default behavior and we will create a custom one. > > We really need to listen to clicks and not hover state, since we need to > > be mobile compatible. > > > > It's normal that the users feel a bit confused since they are used with a > > certain behavior and we tried to mix them in order to have both menu and > > navigation use cases. > > And I think the reason is a bit confusing is that the separation between > > the link and the arrow is invisible, compared with the btn-groups used > for > > Edit or Add. For example, I think that making the separation more clean, > > like in this screenshot > > http://jira.xwiki.org/secure/attachment/28807/btn-group.png would > improve > > a bit the things, but would need visual improvements and is not default > > also. Maybe we could think of a better solution if we were to go on this > > path. > > > > Behavior like double clicking a certain element will be a hidden > > interaction for the users. Double clicking is not a Web behavior and you > > cannot expect users to know on which links to simple click vs. on which > to > > double click. In the usability testing sessions users had a hard time to > > double click on uploading image in the WYSIWYG popup, so I'm not sure > about > > this approach's success. > > > > Regarding the IntelliJ IDEA screenshot, we already discuss about this > idea > > and even made a similar proposal some long time ago, see > >
http://design.xwiki.org/xwiki/bin/view/Improvements/ActionMenuNavigation
> > Although this proposal is a nice idea and I would like to have it, I > don't > > see how this would 'simplify' the current implementation. IMO it will > make > > it even more complex and we would certainly need a custom menu. Also I > see > > this as a new feature, than a solution to our current problem. > > > > When we implemented the current solution we discussed if the navigation > > should be put on the text or on the icon, see > > http://jira.xwiki.org/browse/XWIKI-10449 . The main problem is the > > findability of this functionality. Users might never press that icon > (this > > problem applies to the solution brainstorming and the breadcrumb > proposal). > > > > So I think the idea to have an entry with "Go to ..." could be a solution > > and to keep the menus interact with the default behavior (removing the > > navigation from the dropdown activator). > > Removing triangles is not an option. That is a default menu marker caret. > > > > So what are the next steps? We do a issue with the "Go to ..." solution? > > > > http://jira.xwiki.org/browse/XWIKI-11166 > > > > Thanks, > > Caty > > > > On Wed, Sep 24, 2014 at 11:55 AM, Guillaume "Louis-Marie" Delhumeau < > > [email protected]> wrote: > > > >> Hi. > >> > >> I am happy that this topic is coming back. > >> > >> 2014-09-24 10:04 GMT+02:00 [email protected] : > >> > >> > Hi devs, > >> > > >> > I’ve had a few persons tell me that they don’t like the small arrow in > >> the > >> > top level menu in Flamingo. It seems they either don’t understand the > >> > little triangles and what it’s about (submenu?) or they click on the > >> menu > >> > itself and go to another page when they were expecting some menu to > drop > >> > down, or... > >> > > >> > >> I don't like it neither. It is not consistent with other projects (such > as > >> JIRA). It is not consistent with what we are planning to do about the UI > >> language (see: > >> > >> >
http://design.xwiki.org/xwiki/bin/download/Proposal/InterfaceAndContentLangu...
> >> ). > >> It is harder to use on mobiles, and people are surprised by what occurs > >> when they click on it. > >> > >> > >> > > >> > In addition we’re still missing a solution to easily navigate the wiki > >> > from any page (there’s the ctrl+G solution but this is more like a > >> shortcut > >> > to know and we need something more). > >> > > >> > So here are some ideas: > >> > > >> > * For the top level menu, make it simpler by having the drop down > >> display > >> > when you click anywhere in the menu (the whole width of it) and only > >> > navigate when you double click (there are actually few reasons to need > >> to > >> > navigate with the other idea below so we could also not do the double > >> click > >> > thing) > >> > > >> > >> +1 > >> > >> > >> > > >> > * In the breadcrumb OR in the top level menu OR in both (to be > decided) > >> > use something like this (screenshot taken from IntelliJ IDEA): > >> > > >> > > >> >
https://www.evernote.com/shard/s119/sh/20e99ab3-2991-4aa8-a7b5-93088aad4944/...
> >> > > >> > This means when you click at a given level you get to see all sibling > >> > elements in the wiki for element you’re currently on (document, space, > >> > wiki). > >> > > >> > For example clicking on the “Home” wiki would show: > >> > - A filter box allowing you to type and it would auto suggest as you > >> type, > >> > completing with wiki names > >> > - An icon would be displayed on the left (or on the right) of the > filter > >> > box and if you click on it you’ll go the index page (Wiki Index in > this > >> > case) > >> > - A list of the first 10 wikis (an improvement would be to list first > >> the > >> > wiki that you’ve last navigated to) > >> > > >> > Same would apply for spaces and pages. > >> > > >> > We could even imagine that when you’re on a user profile page, > clicking > >> on > >> > it would display other user pages and the filter would filter on user > >> > pages. Actually we could imagine to when the current page has XObjects > >> in > >> > it, it would be possible to list all other pages in the wiki having > the > >> > same XClass. And if there are several XObjects, then somehow in the UI > >> > allow selecting which one to consider as the filter criteria. > >> > > >> > * Note 1: The breadcrumb is currently not displayed on all pages (it’s > >> not > >> > on the home page for example) and thus if we implement this idea in > the > >> > breadcrumb only then there’s no solution for navigating on the home > >> page. > >> > > >> > >> This is a behaviour that I have put because I thought it was not pretty > to > >> have a useless breadcrumb on the home page. It can be changed. > >> > >> > >> > > >> > * Note 2: If we were to implement this idea on the top level menu, > then > >> we > >> > still need to display the actions too. Several options: > >> > - a) Display the actions first and the navigation list after separated > >> by > >> > a ----- > >> > - b) Have a first entry in the drop down that says “Actions...” and > when > >> > you move the mouse over it a secondary menu with all actions are > >> displayed. > >> > Note that the alternative is possible too: Display the actions and > have > >> a > >> > “Go to..." menu entry. We would just need to choose to display what we > >> > think is the most used default (actions or navigation) > >> > > >> > >> +1 > >> > >> > >> > > >> > WDYT? > >> > > >> > Personally I would do this: > >> > - implement this idea for the breadcrumb > >> > > >> > >> +0, I need to think more about it > >> > >> > >> > - add “Go to wiki...”, “Go to space...", “Go to page..." menu entries > in > >> > the Wiki/Space/Page top level menus > >> > > >> > >> +1 > >> > >> > >> > - expand the menu selection to the whole width for displaying the drop > >> > down (and not just above the small arrow) > >> > > >> > >> +1 > >> > >> > >> > - either support double-click or simply add the possibility to > navigate > >> to > >> > that element in the “Go to xxx...” submenu > >> > > >> > >> +1 > >> > >> > >> > > >> > Thanks > >> > -Vincent > >> > > >> > > >> > _______________________________________________ > >> > devs mailing list > >> > [email protected] > >> > http://lists.xwiki.org/mailman/listinfo/devs > >> > > >> > >> > >> > >> -- > >> Guillaume Delhumeau ([email protected]) > >> Research & Development Engineer at XWiki SAS > >> Committer on the XWiki.org project > >> _______________________________________________ > >> devs mailing list > >> [email protected] > >> http://lists.xwiki.org/mailman/listinfo/devs > >> > > > > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Tue, Oct 21, 2014 at 11:00 AM, Anca Luca <[email protected]> wrote:
On Thu, Oct 9, 2014 at 5:59 PM, [email protected] <[email protected]> wrote:
On 9 Oct 2014 at 17:57:46, Jeremie BOUSQUET ([email protected] (mailto:[email protected])) wrote:
Hi,
In fact, colibri top-menu was better than bootstrap buttons ! :D
Why not putting back old ways of interacting ? - re-add display of dropdown menu on hover [1] - re-add underlining on hover of links in menu text
The reason we changed that was for mobiles. We could decide to have different behaviors on mobile and desktops but not sure it’s best. WDYT?
I think it's not bad to have a slightly different behaviour for desktop and mobile. I don't have much experience with this but I think that we should not ruin desktop experience because it has to work on mobile. If different behaviour is the solution, let's do it.
"ruin desktop experience because it has to work on mobile", yep that's called Windows 8 :)
I think the old behaviour with the hover was quite natural, and the fact that bootstrap does not have those buttons by default is because it's mobile first. But, as much as we'd want it, XWiki is not yet mobile first (I would say most of the usage of XWiki today is still desktop, but since I don't have statistics I cannot prove it. I can only use my personal statistic, from my experience and the cases I know).
2 clicks feels completely unnatural on desktop, especially when coming from colibri.
I would not want to let Bootstrap kill our UI choices, I think it's the bad reason to say that "we won't do it because bootstrap does not have a default component for it".
Thanks, Anca
Thanks -Vincent
Problem I feel is for second item as it seems bootstrap won't easily allow you to hover on something (for dropdown) and click on it (to do something else than show dropdown). Also I suppose there are impacts on mobile version.
I don't think the new flamingo way is bad, but visually it looks very similar to colibri (a text + a little triangle), but when you hover nothing happens, and you have no visual clue that something different may happen if you click on the text or on the triangle. For example take the "New" button in Outlook 2007 which is exactly a dropdown button, when I hover on it I see a clear separation between the "New" text, and the arrow, so I can assume that both lead to different results.
With the "Add" and "Edit" buttons it's completely different, you see the separation, and on hoovering the color changes (of the text OR of the arrow background). You are prepared to the fact that something different will occur. But doing the same in top menu would clearly not fit expected look&feel of this beautiful skin...
BR, Jeremie
[1] - http://cameronspear.com/demos/bootstrap-hover-dropdown/
2014-10-09 16:02 GMT+02:00 [email protected] :
On 9 Oct 2014 at 14:23:49, Eduard Moraru ([email protected](mailto: [email protected])) wrote:
On Thu, Oct 9, 2014 at 3:15 PM, [email protected] wrote:
On 9 Oct 2014 at 14:02:05, Eduard Moraru ([email protected]
(mailto:
[email protected])) wrote:
> Folks, you speak of consistency and then come up with this solution... > > So we have a problem with "non-standard bootstrap dropdown buttons" that > our users (whoever they may be) have a problem with understanding that > there is either an action or a dropdown involved in the same button, like > they can encounter in other interfaces along their computer usage history. > > Our solution is to stop using the mixed mode, and only use the "standard > bootstrap dropdown buttons" that have their first action in the submenu the > thing that would have happened in the past when the users clicked directly > the action part of the "mixed button" we were using. > > Ok, we implement this solution, but we only do it for the top navigational > elements. We completely ignore the "Add" and the "Edit" buttons that > "suffer" from exactly the same "problem". > > My question is: why? > > If we do/did decide that this is the way to go, we should at least be > consistent and do it everywhere in the UI, otherwise it just causes > frustrations.
There’s a difference. For the Edit/Add button click the button will do what the user wants. Click the arrow is only for advanced featurs.
"It seems they either don’t understand the little triangles and what it’s about (submenu?) or they click on the menu itself and go to another page when they were expecting some menu to drop down, or.."
There is no difference from the "problem" you have mentioned in the OP. The user sees an arrow and clicks on the button to expand the menu, but instead ends up reloading the page (either to edit mode or to view mode, same thing). You will say that he wanted to edit anyway, yes, but maybe he did not want to edit in the default mode, so the user's "intent" (as you defined it in the OP) is still not respected.
We either do it one way, or the other, all I ask for is consistency. Do we want to introduce yet another compromise in this young skin?
The problem I saw is that users were not clicking the arrow but the main button part (thus navigating instead of having the main options).
What we want is that it’s the simplest possible for the user for his use case at hand: - When I click Edit or Add (not the arrow, the button) it’s the simplest possible. Edit will choose the good default mode and add will add a page - When I click the wiki/space/page button (not the arrow) I want the actions to be displayed rather than the navigation since navigation is a secondary use case for these buttons
At least that’s how I view it.
Forcing the user to have 2 clicks to do the main action on a button would be a pity.
Now you’re going to say that we could keep the arrow for the wiki/space/page buttons to navigate. We could, but it doesn’t feel natural.
What do you suggest?
Thanks -Vincent
Thanks, Eduard
Thanks -Vincent
> Thanks, > Eduard > > On Fri, Oct 3, 2014 at 4:21 PM, Ecaterina Moraru (Valica) > >
wrote:
> > > On Wed, Sep 24, 2014 at 5:25 PM, Ecaterina Moraru (Valica) < > > [email protected]> wrote: > > > > > Hi, > > > > > > Some background: > > > * Colibri > > > ** menus displayed on hover > > > ** custom menu JS > > > ** menu entries could be icon+label+separator+link+whatever > > > > > > * Flamingo > > > ** menus displayed on click > > > ** menu component from Bootstrap > > > ** it expects simple links or menu dropdown containers (not both > > functions) > > > > > > Theoretically Bootstrap doesn't support our use case and cannot replicate > > > by default the Colibri's behavior. > > > Any change we want to make to the menu Bootstrap component means we are > > > branching from the default behavior and we will create a custom one. > > > We really need to listen to clicks and not hover state, since we need to > > > be mobile compatible. > > > > > > It's normal that the users feel a bit confused since they are used with a > > > certain behavior and we tried to mix them in order to have both menu and > > > navigation use cases. > > > And I think the reason is a bit confusing is that the separation between > > > the link and the arrow is invisible, compared with the btn-groups used > > for > > > Edit or Add. For example, I think that making the separation more clean, > > > like in this screenshot > > > http://jira.xwiki.org/secure/attachment/28807/btn-group.png would > > improve > > > a bit the things, but would need visual improvements and is not default > > > also. Maybe we could think of a better solution if we were to go on this > > > path. > > > > > > Behavior like double clicking a certain element will be a hidden > > > interaction for the users. Double clicking is not a Web behavior and you > > > cannot expect users to know on which links to simple click vs. on which > > to > > > double click. In the usability testing sessions users had a hard time to > > > double click on uploading image in the WYSIWYG popup, so I'm not sure > > about > > > this approach's success. > > > > > > Regarding the IntelliJ IDEA screenshot, we already discuss about this > > idea > > > and even made a similar proposal some long time ago, see > > >
http://design.xwiki.org/xwiki/bin/view/Improvements/ActionMenuNavigation
> > > Although this proposal is a nice idea and I would like to have it, I > > don't > > > see how this would 'simplify' the current implementation. IMO it will > > make > > > it even more complex and we would certainly need a custom menu. Also I > > see > > > this as a new feature, than a solution to our current problem. > > > > > > When we implemented the current solution we discussed if the navigation > > > should be put on the text or on the icon, see > > > http://jira.xwiki.org/browse/XWIKI-10449 . The main problem is the > > > findability of this functionality. Users might never press that icon > > (this > > > problem applies to the solution brainstorming and the breadcrumb > > proposal). > > > > > > So I think the idea to have an entry with "Go to ..." could be a solution > > > and to keep the menus interact with the default behavior (removing the > > > navigation from the dropdown activator). > > > Removing triangles is not an option. That is a default menu marker caret. > > > > > > So what are the next steps? We do a issue with the "Go to ..." solution? > > > > > > > http://jira.xwiki.org/browse/XWIKI-11166 > > > > > > > Thanks, > > > Caty > > > > > > On Wed, Sep 24, 2014 at 11:55 AM, Guillaume "Louis-Marie" Delhumeau < > > > [email protected]> wrote: > > > > > >> Hi. > > >> > > >> I am happy that this topic is coming back. > > >> > > >> 2014-09-24 10:04 GMT+02:00 [email protected] : > > >> > > >> > Hi devs, > > >> > > > >> > I’ve had a few persons tell me that they don’t like the small arrow in > > >> the > > >> > top level menu in Flamingo. It seems they either don’t understand the > > >> > little triangles and what it’s about (submenu?) or they click on the > > >> menu > > >> > itself and go to another page when they were expecting some menu to > > drop > > >> > down, or... > > >> > > > >> > > >> I don't like it neither. It is not consistent with other projects (such > > as > > >> JIRA). It is not consistent with what we are planning to do about the UI > > >> language (see: > > >> > > >> > >
http://design.xwiki.org/xwiki/bin/download/Proposal/InterfaceAndContentLangu...
> > >> ). > > >> It is harder to use on mobiles, and people are surprised by what occurs > > >> when they click on it. > > >> > > >> > > >> > > > >> > In addition we’re still missing a solution to easily navigate the wiki > > >> > from any page (there’s the ctrl+G solution but this is more like a > > >> shortcut > > >> > to know and we need something more). > > >> > > > >> > So here are some ideas: > > >> > > > >> > * For the top level menu, make it simpler by having the drop down > > >> display > > >> > when you click anywhere in the menu (the whole width of it) and only > > >> > navigate when you double click (there are actually few reasons to need > > >> to > > >> > navigate with the other idea below so we could also not do the double > > >> click > > >> > thing) > > >> > > > >> > > >> +1 > > >> > > >> > > >> > > > >> > * In the breadcrumb OR in the top level menu OR in both (to be > > decided) > > >> > use something like this (screenshot taken from IntelliJ IDEA): > > >> > > > >> > > > >> > >
https://www.evernote.com/shard/s119/sh/20e99ab3-2991-4aa8-a7b5-93088aad4944/...
> > >> > > > >> > This means when you click at a given level you get to see all sibling > > >> > elements in the wiki for element you’re currently on (document, space, > > >> > wiki). > > >> > > > >> > For example clicking on the “Home” wiki would show: > > >> > - A filter box allowing you to type and it would auto suggest as you > > >> type, > > >> > completing with wiki names > > >> > - An icon would be displayed on the left (or on the right) of the > > filter > > >> > box and if you click on it you’ll go the index page (Wiki Index in > > this > > >> > case) > > >> > - A list of the first 10 wikis (an improvement would be to list first > > >> the > > >> > wiki that you’ve last navigated to) > > >> > > > >> > Same would apply for spaces and pages. > > >> > > > >> > We could even imagine that when you’re on a user profile page, > > clicking > > >> on > > >> > it would display other user pages and the filter would filter on user > > >> > pages. Actually we could imagine to when the current page has XObjects > > >> in > > >> > it, it would be possible to list all other pages in the wiki having > > the > > >> > same XClass. And if there are several XObjects, then somehow in the UI > > >> > allow selecting which one to consider as the filter criteria. > > >> > > > >> > * Note 1: The breadcrumb is currently not displayed on all pages (it’s > > >> not > > >> > on the home page for example) and thus if we implement this idea in > > the > > >> > breadcrumb only then there’s no solution for navigating on the home > > >> page. > > >> > > > >> > > >> This is a behaviour that I have put because I thought it was not pretty > > to > > >> have a useless breadcrumb on the home page. It can be changed. > > >> > > >> > > >> > > > >> > * Note 2: If we were to implement this idea on the top level menu, > > then > > >> we > > >> > still need to display the actions too. Several options: > > >> > - a) Display the actions first and the navigation list after separated > > >> by > > >> > a ----- > > >> > - b) Have a first entry in the drop down that says “Actions...” and > > when > > >> > you move the mouse over it a secondary menu with all actions are > > >> displayed. > > >> > Note that the alternative is possible too: Display the actions and > > have > > >> a > > >> > “Go to..." menu entry. We would just need to choose to display what we > > >> > think is the most used default (actions or navigation) > > >> > > > >> > > >> +1 > > >> > > >> > > >> > > > >> > WDYT? > > >> > > > >> > Personally I would do this: > > >> > - implement this idea for the breadcrumb > > >> > > > >> > > >> +0, I need to think more about it > > >> > > >> > > >> > - add “Go to wiki...”, “Go to space...", “Go to page..." menu entries > > in > > >> > the Wiki/Space/Page top level menus > > >> > > > >> > > >> +1 > > >> > > >> > > >> > - expand the menu selection to the whole width for displaying the drop > > >> > down (and not just above the small arrow) > > >> > > > >> > > >> +1 > > >> > > >> > > >> > - either support double-click or simply add the possibility to > > navigate > > >> to > > >> > that element in the “Go to xxx...” submenu > > >> > > > >> > > >> +1 > > >> > > >> > > >> > > > >> > Thanks > > >> > -Vincent > > >> > > > >> > > > >> > _______________________________________________ > > >> > devs mailing list > > >> > [email protected] > > >> > http://lists.xwiki.org/mailman/listinfo/devs > > >> > > > >> > > >> > > >> > > >> -- > > >> Guillaume Delhumeau ([email protected]) > > >> Research & Development Engineer at XWiki SAS > > >> Committer on the XWiki.org project > > >> _______________________________________________ > > >> devs mailing list > > >> [email protected] > > >> http://lists.xwiki.org/mailman/listinfo/devs > > >> > > > > > > > > _______________________________________________ > > devs mailing list > > [email protected] > > http://lists.xwiki.org/mailman/listinfo/devs > > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
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 ([email protected](mailto:[email protected])) wrote:
On Thu, Oct 9, 2014 at 5:59 PM, [email protected] wrote:
On 9 Oct 2014 at 17:57:46, Jeremie BOUSQUET ([email protected] (mailto:[email protected])) wrote:
Hi,
In fact, colibri top-menu was better than bootstrap buttons ! :D
Why not putting back old ways of interacting ? - re-add display of dropdown menu on hover [1] - re-add underlining on hover of links in menu text
The reason we changed that was for mobiles. We could decide to have different behaviors on mobile and desktops but not sure it’s best. WDYT?
I think it's not bad to have a slightly different behaviour for desktop and mobile. I don't have much experience with this but I think that we should not ruin desktop experience because it has to work on mobile. If different behaviour is the solution, let's do it.
I think the old behaviour with the hover was quite natural, and the fact that bootstrap does not have those buttons by default is because it's mobile first. But, as much as we'd want it, XWiki is not yet mobile first (I would say most of the usage of XWiki today is still desktop, but since I don't have statistics I cannot prove it. I can only use my personal statistic, from my experience and the cases I know).
2 clicks feels completely unnatural on desktop, especially when coming from colibri.
I would not want to let Bootstrap kill our UI choices, I think it's the bad reason to say that "we won't do it because bootstrap does not have a default component for it".
Thanks, Anca
Thanks -Vincent
Problem I feel is for second item as it seems bootstrap won't easily allow you to hover on something (for dropdown) and click on it (to do something else than show dropdown). Also I suppose there are impacts on mobile version.
I don't think the new flamingo way is bad, but visually it looks very similar to colibri (a text + a little triangle), but when you hover nothing happens, and you have no visual clue that something different may happen if you click on the text or on the triangle. For example take the "New" button in Outlook 2007 which is exactly a dropdown button, when I hover on it I see a clear separation between the "New" text, and the arrow, so I can assume that both lead to different results.
With the "Add" and "Edit" buttons it's completely different, you see the separation, and on hoovering the color changes (of the text OR of the arrow background). You are prepared to the fact that something different will occur. But doing the same in top menu would clearly not fit expected look&feel of this beautiful skin...
BR, Jeremie
[1] - http://cameronspear.com/demos/bootstrap-hover-dropdown/
2014-10-09 16:02 GMT+02:00 [email protected] :
On 9 Oct 2014 at 14:23:49, Eduard Moraru ([email protected](mailto: [email protected])) wrote:
On Thu, Oct 9, 2014 at 3:15 PM, [email protected] wrote:
On 9 Oct 2014 at 14:02:05, Eduard Moraru ([email protected]
(mailto:
[email protected])) wrote:
> Folks, you speak of consistency and then come up with this solution... > > So we have a problem with "non-standard bootstrap dropdown buttons" that > our users (whoever they may be) have a problem with understanding that > there is either an action or a dropdown involved in the same button, like > they can encounter in other interfaces along their computer usage history. > > Our solution is to stop using the mixed mode, and only use the "standard > bootstrap dropdown buttons" that have their first action in the submenu the > thing that would have happened in the past when the users clicked directly > the action part of the "mixed button" we were using. > > Ok, we implement this solution, but we only do it for the top navigational > elements. We completely ignore the "Add" and the "Edit" buttons that > "suffer" from exactly the same "problem". > > My question is: why? > > If we do/did decide that this is the way to go, we should at least be > consistent and do it everywhere in the UI, otherwise it just causes > frustrations.
There’s a difference. For the Edit/Add button click the button will do what the user wants. Click the arrow is only for advanced featurs.
"It seems they either don’t understand the little triangles and what it’s about (submenu?) or they click on the menu itself and go to another page when they were expecting some menu to drop down, or.."
There is no difference from the "problem" you have mentioned in the OP. The user sees an arrow and clicks on the button to expand the menu, but instead ends up reloading the page (either to edit mode or to view mode, same thing). You will say that he wanted to edit anyway, yes, but maybe he did not want to edit in the default mode, so the user's "intent" (as you defined it in the OP) is still not respected.
We either do it one way, or the other, all I ask for is consistency. Do we want to introduce yet another compromise in this young skin?
The problem I saw is that users were not clicking the arrow but the main button part (thus navigating instead of having the main options).
What we want is that it’s the simplest possible for the user for his use case at hand: - When I click Edit or Add (not the arrow, the button) it’s the simplest possible. Edit will choose the good default mode and add will add a page - When I click the wiki/space/page button (not the arrow) I want the actions to be displayed rather than the navigation since navigation is a secondary use case for these buttons
At least that’s how I view it.
Forcing the user to have 2 clicks to do the main action on a button would be a pity.
Now you’re going to say that we could keep the arrow for the wiki/space/page buttons to navigate. We could, but it doesn’t feel natural.
What do you suggest?
Thanks -Vincent
Thanks, Eduard
Thanks -Vincent
> Thanks, > Eduard > > On Fri, Oct 3, 2014 at 4:21 PM, Ecaterina Moraru (Valica) > >
wrote:
> > > On Wed, Sep 24, 2014 at 5:25 PM, Ecaterina Moraru (Valica) < > > [email protected]> wrote: > > > > > Hi, > > > > > > Some background: > > > * Colibri > > > ** menus displayed on hover > > > ** custom menu JS > > > ** menu entries could be icon+label+separator+link+whatever > > > > > > * Flamingo > > > ** menus displayed on click > > > ** menu component from Bootstrap > > > ** it expects simple links or menu dropdown containers (not both > > functions) > > > > > > Theoretically Bootstrap doesn't support our use case and cannot replicate > > > by default the Colibri's behavior. > > > Any change we want to make to the menu Bootstrap component means we are > > > branching from the default behavior and we will create a custom one. > > > We really need to listen to clicks and not hover state, since we need to > > > be mobile compatible. > > > > > > It's normal that the users feel a bit confused since they are used with a > > > certain behavior and we tried to mix them in order to have both menu and > > > navigation use cases. > > > And I think the reason is a bit confusing is that the separation between > > > the link and the arrow is invisible, compared with the btn-groups used > > for > > > Edit or Add. For example, I think that making the separation more clean, > > > like in this screenshot > > > http://jira.xwiki.org/secure/attachment/28807/btn-group.png would > > improve > > > a bit the things, but would need visual improvements and is not default > > > also. Maybe we could think of a better solution if we were to go on this > > > path. > > > > > > Behavior like double clicking a certain element will be a hidden > > > interaction for the users. Double clicking is not a Web behavior and you > > > cannot expect users to know on which links to simple click vs. on which > > to > > > double click. In the usability testing sessions users had a hard time to > > > double click on uploading image in the WYSIWYG popup, so I'm not sure > > about > > > this approach's success. > > > > > > Regarding the IntelliJ IDEA screenshot, we already discuss about this > > idea > > > and even made a similar proposal some long time ago, see > > >
http://design.xwiki.org/xwiki/bin/view/Improvements/ActionMenuNavigation
> > > Although this proposal is a nice idea and I would like to have it, I > > don't > > > see how this would 'simplify' the current implementation. IMO it will > > make > > > it even more complex and we would certainly need a custom menu. Also I > > see > > > this as a new feature, than a solution to our current problem. > > > > > > When we implemented the current solution we discussed if the navigation > > > should be put on the text or on the icon, see > > > http://jira.xwiki.org/browse/XWIKI-10449 . The main problem is the > > > findability of this functionality. Users might never press that icon > > (this > > > problem applies to the solution brainstorming and the breadcrumb > > proposal). > > > > > > So I think the idea to have an entry with "Go to ..." could be a solution > > > and to keep the menus interact with the default behavior (removing the > > > navigation from the dropdown activator). > > > Removing triangles is not an option. That is a default menu marker caret. > > > > > > So what are the next steps? We do a issue with the "Go to ..." solution? > > > > > > > http://jira.xwiki.org/browse/XWIKI-11166 > > > > > > > Thanks, > > > Caty > > > > > > On Wed, Sep 24, 2014 at 11:55 AM, Guillaume "Louis-Marie" Delhumeau < > > > [email protected]> wrote: > > > > > >> Hi. > > >> > > >> I am happy that this topic is coming back. > > >> > > >> 2014-09-24 10:04 GMT+02:00 [email protected] : > > >> > > >> > Hi devs, > > >> > > > >> > I’ve had a few persons tell me that they don’t like the small arrow in > > >> the > > >> > top level menu in Flamingo. It seems they either don’t understand the > > >> > little triangles and what it’s about (submenu?) or they click on the > > >> menu > > >> > itself and go to another page when they were expecting some menu to > > drop > > >> > down, or... > > >> > > > >> > > >> I don't like it neither. It is not consistent with other projects (such > > as > > >> JIRA). It is not consistent with what we are planning to do about the UI > > >> language (see: > > >> > > >> > >
http://design.xwiki.org/xwiki/bin/download/Proposal/InterfaceAndContentLangu...
> > >> ). > > >> It is harder to use on mobiles, and people are surprised by what occurs > > >> when they click on it. > > >> > > >> > > >> > > > >> > In addition we’re still missing a solution to easily navigate the wiki > > >> > from any page (there’s the ctrl+G solution but this is more like a > > >> shortcut > > >> > to know and we need something more). > > >> > > > >> > So here are some ideas: > > >> > > > >> > * For the top level menu, make it simpler by having the drop down > > >> display > > >> > when you click anywhere in the menu (the whole width of it) and only > > >> > navigate when you double click (there are actually few reasons to need > > >> to > > >> > navigate with the other idea below so we could also not do the double > > >> click > > >> > thing) > > >> > > > >> > > >> +1 > > >> > > >> > > >> > > > >> > * In the breadcrumb OR in the top level menu OR in both (to be > > decided) > > >> > use something like this (screenshot taken from IntelliJ IDEA): > > >> > > > >> > > > >> > >
https://www.evernote.com/shard/s119/sh/20e99ab3-2991-4aa8-a7b5-93088aad4944/...
> > >> > > > >> > This means when you click at a given level you get to see all sibling > > >> > elements in the wiki for element you’re currently on (document, space, > > >> > wiki). > > >> > > > >> > For example clicking on the “Home” wiki would show: > > >> > - A filter box allowing you to type and it would auto suggest as you > > >> type, > > >> > completing with wiki names > > >> > - An icon would be displayed on the left (or on the right) of the > > filter > > >> > box and if you click on it you’ll go the index page (Wiki Index in > > this > > >> > case) > > >> > - A list of the first 10 wikis (an improvement would be to list first > > >> the > > >> > wiki that you’ve last navigated to) > > >> > > > >> > Same would apply for spaces and pages. > > >> > > > >> > We could even imagine that when you’re on a user profile page, > > clicking > > >> on > > >> > it would display other user pages and the filter would filter on user > > >> > pages. Actually we could imagine to when the current page has XObjects > > >> in > > >> > it, it would be possible to list all other pages in the wiki having > > the > > >> > same XClass. And if there are several XObjects, then somehow in the UI > > >> > allow selecting which one to consider as the filter criteria. > > >> > > > >> > * Note 1: The breadcrumb is currently not displayed on all pages (it’s > > >> not > > >> > on the home page for example) and thus if we implement this idea in > > the > > >> > breadcrumb only then there’s no solution for navigating on the home > > >> page. > > >> > > > >> > > >> This is a behaviour that I have put because I thought it was not pretty > > to > > >> have a useless breadcrumb on the home page. It can be changed. > > >> > > >> > > >> > > > >> > * Note 2: If we were to implement this idea on the top level menu, > > then > > >> we > > >> > still need to display the actions too. Several options: > > >> > - a) Display the actions first and the navigation list after separated > > >> by > > >> > a ----- > > >> > - b) Have a first entry in the drop down that says “Actions...” and > > when > > >> > you move the mouse over it a secondary menu with all actions are > > >> displayed. > > >> > Note that the alternative is possible too: Display the actions and > > have > > >> a > > >> > “Go to..." menu entry. We would just need to choose to display what we > > >> > think is the most used default (actions or navigation) > > >> > > > >> > > >> +1 > > >> > > >> > > >> > > > >> > WDYT? > > >> > > > >> > Personally I would do this: > > >> > - implement this idea for the breadcrumb > > >> > > > >> > > >> +0, I need to think more about it > > >> > > >> > > >> > - add “Go to wiki...”, “Go to space...", “Go to page..." menu entries > > in > > >> > the Wiki/Space/Page top level menus > > >> > > > >> > > >> +1 > > >> > > >> > > >> > - expand the menu selection to the whole width for displaying the drop > > >> > down (and not just above the small arrow) > > >> > > > >> > > >> +1 > > >> > > >> > > >> > - either support double-click or simply add the possibility to > > navigate > > >> to > > >> > that element in the “Go to xxx...” submenu > > >> > > > >> > > >> +1 > > >> > > >> > > >> > > > >> > Thanks > > >> > -Vincent > > >> > > > >> > > > >> > _______________________________________________ > > >> > devs mailing list > > >> > [email protected] > > >> > http://lists.xwiki.org/mailman/listinfo/devs > > >> > > > >> > > >> > > >> > > >> -- > > >> Guillaume Delhumeau ([email protected]) > > >> Research & Development Engineer at XWiki SAS > > >> Committer on the XWiki.org project > > >> _______________________________________________ > > >> devs mailing list > > >> [email protected] > > >> http://lists.xwiki.org/mailman/listinfo/devs > > >> > > > > > > > > _______________________________________________ > > devs mailing list > > [email protected] > > http://lists.xwiki.org/mailman/listinfo/devs > > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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, [email protected] <[email protected]> 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 ([email protected](mailto: [email protected])) wrote:
On Thu, Oct 9, 2014 at 5:59 PM, [email protected] wrote:
On 9 Oct 2014 at 17:57:46, Jeremie BOUSQUET (
(mailto:[email protected])) wrote:
Hi,
In fact, colibri top-menu was better than bootstrap buttons ! :D
Why not putting back old ways of interacting ? - re-add display of dropdown menu on hover [1] - re-add underlining on hover of links in menu text
The reason we changed that was for mobiles. We could decide to have different behaviors on mobile and desktops but not sure it’s best. WDYT?
I think it's not bad to have a slightly different behaviour for desktop and mobile. I don't have much experience with this but I think that we should not ruin desktop experience because it has to work on mobile. If different behaviour is the solution, let's do it.
I think the old behaviour with the hover was quite natural, and the fact that bootstrap does not have those buttons by default is because it's mobile first. But, as much as we'd want it, XWiki is not yet mobile first (I would say most of the usage of XWiki today is still desktop, but since I don't have statistics I cannot prove it. I can only use my personal statistic, from my experience and the cases I know).
2 clicks feels completely unnatural on desktop, especially when coming from colibri.
I would not want to let Bootstrap kill our UI choices, I think it's the bad reason to say that "we won't do it because bootstrap does not have a default component for it".
Thanks, Anca
Thanks -Vincent
Problem I feel is for second item as it seems bootstrap won't easily allow you to hover on something (for dropdown) and click on it (to do
something
else than show dropdown). Also I suppose there are impacts on mobile version.
I don't think the new flamingo way is bad, but visually it looks very similar to colibri (a text + a little triangle), but when you hover nothing happens, and you have no visual clue that something different may happen if you click on the text or on the triangle. For example take the "New" button in Outlook 2007 which is exactly a dropdown button, when I hover on it I see a clear separation between the "New" text, and the arrow, so I can assume that both lead to different results.
With the "Add" and "Edit" buttons it's completely different, you see the separation, and on hoovering the color changes (of the text OR of the arrow background). You are prepared to the fact that something different will occur. But doing the same in top menu would clearly not fit expected look&feel of this beautiful skin...
BR, Jeremie
[1] - http://cameronspear.com/demos/bootstrap-hover-dropdown/
2014-10-09 16:02 GMT+02:00 [email protected] :
On 9 Oct 2014 at 14:23:49, Eduard Moraru ([email protected]
(mailto:
[email protected])) wrote:
On Thu, Oct 9, 2014 at 3:15 PM, [email protected] wrote:
> > > > > > On 9 Oct 2014 at 14:02:05, Eduard Moraru ([email protected] (mailto: > [email protected])) wrote: > > > Folks, you speak of consistency and then come up with this solution... > > > > So we have a problem with "non-standard bootstrap dropdown buttons" that > > our users (whoever they may be) have a problem with understanding that > > there is either an action or a dropdown involved in the same button, like > > they can encounter in other interfaces along their computer usage > history. > > > > Our solution is to stop using the mixed mode, and only use the "standard > > bootstrap dropdown buttons" that have their first action in the submenu > the > > thing that would have happened in the past when the users clicked > directly > > the action part of the "mixed button" we were using. > > > > Ok, we implement this solution, but we only do it for the top > navigational > > elements. We completely ignore the "Add" and the "Edit" buttons that > > "suffer" from exactly the same "problem". > > > > My question is: why? > > > > If we do/did decide that this is the way to go, we should at least be > > consistent and do it everywhere in the UI, otherwise it just causes > > frustrations. > > There’s a difference. For the Edit/Add button click the button will do > what the user wants. Click the arrow is only for advanced featurs. >
"It seems they either don’t understand the little triangles and what it’s about (submenu?) or they click on the menu itself and go to another page when they were expecting some menu to drop down, or.."
There is no difference from the "problem" you have mentioned in the OP. The user sees an arrow and clicks on the button to expand the menu, but instead ends up reloading the page (either to edit mode or to view mode, same thing). You will say that he wanted to edit anyway, yes, but maybe he did not want to edit in the default mode, so the user's "intent" (as you defined it in the OP) is still not respected.
We either do it one way, or the other, all I ask for is consistency. Do we want to introduce yet another compromise in this young skin?
The problem I saw is that users were not clicking the arrow but the main button part (thus navigating instead of having the main options).
What we want is that it’s the simplest possible for the user for his use case at hand: - When I click Edit or Add (not the arrow, the button) it’s the simplest possible. Edit will choose the good default mode and add will add a page - When I click the wiki/space/page button (not the arrow) I want the actions to be displayed rather than the navigation since navigation is a secondary use case for these buttons
At least that’s how I view it.
Forcing the user to have 2 clicks to do the main action on a button would be a pity.
Now you’re going to say that we could keep the arrow for the wiki/space/page buttons to navigate. We could, but it doesn’t feel natural.
What do you suggest?
Thanks -Vincent
Thanks, Eduard
> > Thanks > -Vincent > > > Thanks, > > Eduard > > > > On Fri, Oct 3, 2014 at 4:21 PM, Ecaterina Moraru (Valica) > > wrote: > > > > > On Wed, Sep 24, 2014 at 5:25 PM, Ecaterina Moraru (Valica) < > > > [email protected]> wrote: > > > > > > > Hi, > > > > > > > > Some background: > > > > * Colibri > > > > ** menus displayed on hover > > > > ** custom menu JS > > > > ** menu entries could be icon+label+separator+link+whatever > > > > > > > > * Flamingo > > > > ** menus displayed on click > > > > ** menu component from Bootstrap > > > > ** it expects simple links or menu dropdown containers (not both > > > functions) > > > > > > > > Theoretically Bootstrap doesn't support our use case and cannot > replicate > > > > by default the Colibri's behavior. > > > > Any change we want to make to the menu Bootstrap component means we > are > > > > branching from the default behavior and we will create a custom one. > > > > We really need to listen to clicks and not hover state, since we > need to > > > > be mobile compatible. > > > > > > > > It's normal that the users feel a bit confused since they are used > with a > > > > certain behavior and we tried to mix them in order to have both menu > and > > > > navigation use cases. > > > > And I think the reason is a bit confusing is that the separation > between > > > > the link and the arrow is invisible, compared with the btn-groups > used > > > for > > > > Edit or Add. For example, I think that making the separation more > clean, > > > > like in this screenshot > > > > http://jira.xwiki.org/secure/attachment/28807/btn-group.png would > > > improve > > > > a bit the things, but would need visual improvements and is not > default > > > > also. Maybe we could think of a better solution if we were to go on > this > > > > path. > > > > > > > > Behavior like double clicking a certain element will be a hidden > > > > interaction for the users. Double clicking is not a Web behavior and > you > > > > cannot expect users to know on which links to simple click vs. on > which > > > to > > > > double click. In the usability testing sessions users had a hard > time to > > > > double click on uploading image in the WYSIWYG popup, so I'm not sure > > > about > > > > this approach's success. > > > > > > > > Regarding the IntelliJ IDEA screenshot, we already discuss about this > > > idea > > > > and even made a similar proposal some long time ago, see > > > > >
http://design.xwiki.org/xwiki/bin/view/Improvements/ActionMenuNavigation
> > > > Although this proposal is a nice idea and I would like to have it, I > > > don't > > > > see how this would 'simplify' the current implementation. IMO it will > > > make > > > > it even more complex and we would certainly need a custom menu. Also > I > > > see > > > > this as a new feature, than a solution to our current problem. > > > > > > > > When we implemented the current solution we discussed if the > navigation > > > > should be put on the text or on the icon, see > > > > http://jira.xwiki.org/browse/XWIKI-10449 . The main problem is the > > > > findability of this functionality. Users might never press that icon > > > (this > > > > problem applies to the solution brainstorming and the breadcrumb > > > proposal). > > > > > > > > So I think the idea to have an entry with "Go to ..." could be a > solution > > > > and to keep the menus interact with the default behavior (removing > the > > > > navigation from the dropdown activator). > > > > Removing triangles is not an option. That is a default menu marker > caret. > > > > > > > > So what are the next steps? We do a issue with the "Go to ..." > solution? > > > > > > > > > > http://jira.xwiki.org/browse/XWIKI-11166 > > > > > > > > > > Thanks, > > > > Caty > > > > > > > > On Wed, Sep 24, 2014 at 11:55 AM, Guillaume "Louis-Marie" Delhumeau < > > > > [email protected]> wrote: > > > > > > > >> Hi. > > > >> > > > >> I am happy that this topic is coming back. > > > >> > > > >> 2014-09-24 10:04 GMT+02:00 [email protected] : > > > >> > > > >> > Hi devs, > > > >> > > > > >> > I’ve had a few persons tell me that they don’t like the small > arrow in > > > >> the > > > >> > top level menu in Flamingo. It seems they either don’t understand > the > > > >> > little triangles and what it’s about (submenu?) or they click on > the > > > >> menu > > > >> > itself and go to another page when they were expecting some menu > to > > > drop > > > >> > down, or... > > > >> > > > > >> > > > >> I don't like it neither. It is not consistent with other projects > (such > > > as > > > >> JIRA). It is not consistent with what we are planning to do about > the UI > > > >> language (see: > > > >> > > > >> > > > >
http://design.xwiki.org/xwiki/bin/download/Proposal/InterfaceAndContentLangu...
> > > >> ). > > > >> It is harder to use on mobiles, and people are surprised by what > occurs > > > >> when they click on it. > > > >> > > > >> > > > >> > > > > >> > In addition we’re still missing a solution to easily navigate the > wiki > > > >> > from any page (there’s the ctrl+G solution but this is more like a > > > >> shortcut > > > >> > to know and we need something more). > > > >> > > > > >> > So here are some ideas: > > > >> > > > > >> > * For the top level menu, make it simpler by having the drop down > > > >> display > > > >> > when you click anywhere in the menu (the whole width of it) and > only > > > >> > navigate when you double click (there are actually few reasons to > need > > > >> to > > > >> > navigate with the other idea below so we could also not do the > double > > > >> click > > > >> > thing) > > > >> > > > > >> > > > >> +1 > > > >> > > > >> > > > >> > > > > >> > * In the breadcrumb OR in the top level menu OR in both (to be > > > decided) > > > >> > use something like this (screenshot taken from IntelliJ IDEA): > > > >> > > > > >> > > > > >> > > > >
https://www.evernote.com/shard/s119/sh/20e99ab3-2991-4aa8-a7b5-93088aad4944/...
> > > >> > > > > >> > This means when you click at a given level you get to see all > sibling > > > >> > elements in the wiki for element you’re currently on (document, > space, > > > >> > wiki). > > > >> > > > > >> > For example clicking on the “Home” wiki would show: > > > >> > - A filter box allowing you to type and it would auto suggest as > you > > > >> type, > > > >> > completing with wiki names > > > >> > - An icon would be displayed on the left (or on the right) of the > > > filter > > > >> > box and if you click on it you’ll go the index page (Wiki Index in > > > this > > > >> > case) > > > >> > - A list of the first 10 wikis (an improvement would be to list > first > > > >> the > > > >> > wiki that you’ve last navigated to) > > > >> > > > > >> > Same would apply for spaces and pages. > > > >> > > > > >> > We could even imagine that when you’re on a user profile page, > > > clicking > > > >> on > > > >> > it would display other user pages and the filter would filter on > user > > > >> > pages. Actually we could imagine to when the current page has > XObjects > > > >> in > > > >> > it, it would be possible to list all other pages in the wiki > having > > > the > > > >> > same XClass. And if there are several XObjects, then somehow in > the UI > > > >> > allow selecting which one to consider as the filter criteria. > > > >> > > > > >> > * Note 1: The breadcrumb is currently not displayed on all pages > (it’s > > > >> not > > > >> > on the home page for example) and thus if we implement this idea > in > > > the > > > >> > breadcrumb only then there’s no solution for navigating on the > home > > > >> page. > > > >> > > > > >> > > > >> This is a behaviour that I have put because I thought it was not > pretty > > > to > > > >> have a useless breadcrumb on the home page. It can be changed. > > > >> > > > >> > > > >> > > > > >> > * Note 2: If we were to implement this idea on the top level menu, > > > then > > > >> we > > > >> > still need to display the actions too. Several options: > > > >> > - a) Display the actions first and the navigation list after > separated > > > >> by > > > >> > a ----- > > > >> > - b) Have a first entry in the drop down that says “Actions...” > and > > > when > > > >> > you move the mouse over it a secondary menu with all actions are > > > >> displayed. > > > >> > Note that the alternative is possible too: Display the actions and > > > have > > > >> a > > > >> > “Go to..." menu entry. We would just need to choose to display > what we > > > >> > think is the most used default (actions or navigation) > > > >> > > > > >> > > > >> +1 > > > >> > > > >> > > > >> > > > > >> > WDYT? > > > >> > > > > >> > Personally I would do this: > > > >> > - implement this idea for the breadcrumb > > > >> > > > > >> > > > >> +0, I need to think more about it > > > >> > > > >> > > > >> > - add “Go to wiki...”, “Go to space...", “Go to page..." menu > entries > > > in > > > >> > the Wiki/Space/Page top level menus > > > >> > > > > >> > > > >> +1 > > > >> > > > >> > > > >> > - expand the menu selection to the whole width for displaying the > drop > > > >> > down (and not just above the small arrow) > > > >> > > > > >> > > > >> +1 > > > >> > > > >> > > > >> > - either support double-click or simply add the possibility to > > > navigate > > > >> to > > > >> > that element in the “Go to xxx...” submenu > > > >> > > > > >> > > > >> +1 > > > >> > > > >> > > > >> > > > > >> > Thanks > > > >> > -Vincent > > > >> > > > > >> > > > > >> > _______________________________________________ > > > >> > devs mailing list > > > >> > [email protected] > > > >> > http://lists.xwiki.org/mailman/listinfo/devs > > > >> > > > > >> > > > >> > > > >> > > > >> -- > > > >> Guillaume Delhumeau ([email protected]) > > > >> Research & Development Engineer at XWiki SAS > > > >> Committer on the XWiki.org project > > > >> _______________________________________________ > > > >> devs mailing list > > > >> [email protected] > > > >> http://lists.xwiki.org/mailman/listinfo/devs > > > >> > > > > > > > > > > > _______________________________________________ > > > devs mailing list > > > [email protected] > > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > _______________________________________________ > > devs mailing list > > [email protected] > > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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, [email protected] <[email protected]> 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 ([email protected](mailto: [email protected])) wrote:
On Thu, Oct 9, 2014 at 5:59 PM, [email protected] wrote:
On 9 Oct 2014 at 17:57:46, Jeremie BOUSQUET (
(mailto:[email protected])) wrote:
Hi,
In fact, colibri top-menu was better than bootstrap buttons ! :D
Why not putting back old ways of interacting ? - re-add display of dropdown menu on hover [1] - re-add underlining on hover of links in menu text
The reason we changed that was for mobiles. We could decide to have different behaviors on mobile and desktops but not sure it’s best. WDYT?
I think it's not bad to have a slightly different behaviour for desktop and mobile. I don't have much experience with this but I think that we should not ruin desktop experience because it has to work on mobile. If different behaviour is the solution, let's do it.
I think the old behaviour with the hover was quite natural, and the fact that bootstrap does not have those buttons by default is because it's mobile first. But, as much as we'd want it, XWiki is not yet mobile first (I would say most of the usage of XWiki today is still desktop, but since I don't have statistics I cannot prove it. I can only use my personal statistic, from my experience and the cases I know).
2 clicks feels completely unnatural on desktop, especially when coming from colibri.
I would not want to let Bootstrap kill our UI choices, I think it's the bad reason to say that "we won't do it because bootstrap does not have a default component for it".
Thanks, Anca
Thanks -Vincent
Problem I feel is for second item as it seems bootstrap won't easily allow you to hover on something (for dropdown) and click on it (to do
something
else than show dropdown). Also I suppose there are impacts on mobile version.
I don't think the new flamingo way is bad, but visually it looks very similar to colibri (a text + a little triangle), but when you hover nothing happens, and you have no visual clue that something different may happen if you click on the text or on the triangle. For example take the "New" button in Outlook 2007 which is exactly a dropdown button, when I hover on it I see a clear separation between the "New" text, and the arrow, so I can assume that both lead to different results.
With the "Add" and "Edit" buttons it's completely different, you see the separation, and on hoovering the color changes (of the text OR of the arrow background). You are prepared to the fact that something different will occur. But doing the same in top menu would clearly not fit expected look&feel of this beautiful skin...
BR, Jeremie
[1] - http://cameronspear.com/demos/bootstrap-hover-dropdown/
2014-10-09 16:02 GMT+02:00 [email protected] :
On 9 Oct 2014 at 14:23:49, Eduard Moraru ([email protected]
(mailto:
[email protected])) wrote:
On Thu, Oct 9, 2014 at 3:15 PM, [email protected] wrote:
> > > > > > On 9 Oct 2014 at 14:02:05, Eduard Moraru ([email protected] (mailto: > [email protected])) wrote: > > > Folks, you speak of consistency and then come up with this solution... > > > > So we have a problem with "non-standard bootstrap dropdown buttons" that > > our users (whoever they may be) have a problem with understanding that > > there is either an action or a dropdown involved in the same button, like > > they can encounter in other interfaces along their computer usage > history. > > > > Our solution is to stop using the mixed mode, and only use the "standard > > bootstrap dropdown buttons" that have their first action in the submenu > the > > thing that would have happened in the past when the users clicked > directly > > the action part of the "mixed button" we were using. > > > > Ok, we implement this solution, but we only do it for the top > navigational > > elements. We completely ignore the "Add" and the "Edit" buttons that > > "suffer" from exactly the same "problem". > > > > My question is: why? > > > > If we do/did decide that this is the way to go, we should at least be > > consistent and do it everywhere in the UI, otherwise it just causes > > frustrations. > > There’s a difference. For the Edit/Add button click the button will do > what the user wants. Click the arrow is only for advanced featurs. >
"It seems they either don’t understand the little triangles and what it’s about (submenu?) or they click on the menu itself and go to another page when they were expecting some menu to drop down, or.."
There is no difference from the "problem" you have mentioned in the OP. The user sees an arrow and clicks on the button to expand the menu, but instead ends up reloading the page (either to edit mode or to view mode, same thing). You will say that he wanted to edit anyway, yes, but maybe he did not want to edit in the default mode, so the user's "intent" (as you defined it in the OP) is still not respected.
We either do it one way, or the other, all I ask for is consistency. Do we want to introduce yet another compromise in this young skin?
The problem I saw is that users were not clicking the arrow but the main button part (thus navigating instead of having the main options).
What we want is that it’s the simplest possible for the user for his use case at hand: - When I click Edit or Add (not the arrow, the button) it’s the simplest possible. Edit will choose the good default mode and add will add a page - When I click the wiki/space/page button (not the arrow) I want the actions to be displayed rather than the navigation since navigation is a secondary use case for these buttons
At least that’s how I view it.
Forcing the user to have 2 clicks to do the main action on a button would be a pity.
Now you’re going to say that we could keep the arrow for the wiki/space/page buttons to navigate. We could, but it doesn’t feel natural.
What do you suggest?
Thanks -Vincent
Thanks, Eduard
> > Thanks > -Vincent > > > Thanks, > > Eduard > > > > On Fri, Oct 3, 2014 at 4:21 PM, Ecaterina Moraru (Valica) > > wrote: > > > > > On Wed, Sep 24, 2014 at 5:25 PM, Ecaterina Moraru (Valica) < > > > [email protected]> wrote: > > > > > > > Hi, > > > > > > > > Some background: > > > > * Colibri > > > > ** menus displayed on hover > > > > ** custom menu JS > > > > ** menu entries could be icon+label+separator+link+whatever > > > > > > > > * Flamingo > > > > ** menus displayed on click > > > > ** menu component from Bootstrap > > > > ** it expects simple links or menu dropdown containers (not both > > > functions) > > > > > > > > Theoretically Bootstrap doesn't support our use case and cannot > replicate > > > > by default the Colibri's behavior. > > > > Any change we want to make to the menu Bootstrap component means we > are > > > > branching from the default behavior and we will create a custom one. > > > > We really need to listen to clicks and not hover state, since we > need to > > > > be mobile compatible. > > > > > > > > It's normal that the users feel a bit confused since they are used > with a > > > > certain behavior and we tried to mix them in order to have both menu > and > > > > navigation use cases. > > > > And I think the reason is a bit confusing is that the separation > between > > > > the link and the arrow is invisible, compared with the btn-groups > used > > > for > > > > Edit or Add. For example, I think that making the separation more > clean, > > > > like in this screenshot > > > > http://jira.xwiki.org/secure/attachment/28807/btn-group.png would > > > improve > > > > a bit the things, but would need visual improvements and is not > default > > > > also. Maybe we could think of a better solution if we were to go on > this > > > > path. > > > > > > > > Behavior like double clicking a certain element will be a hidden > > > > interaction for the users. Double clicking is not a Web behavior and > you > > > > cannot expect users to know on which links to simple click vs. on > which > > > to > > > > double click. In the usability testing sessions users had a hard > time to > > > > double click on uploading image in the WYSIWYG popup, so I'm not sure > > > about > > > > this approach's success. > > > > > > > > Regarding the IntelliJ IDEA screenshot, we already discuss about this > > > idea > > > > and even made a similar proposal some long time ago, see > > > > >
http://design.xwiki.org/xwiki/bin/view/Improvements/ActionMenuNavigation
> > > > Although this proposal is a nice idea and I would like to have it, I > > > don't > > > > see how this would 'simplify' the current implementation. IMO it will > > > make > > > > it even more complex and we would certainly need a custom menu. Also > I > > > see > > > > this as a new feature, than a solution to our current problem. > > > > > > > > When we implemented the current solution we discussed if the > navigation > > > > should be put on the text or on the icon, see > > > > http://jira.xwiki.org/browse/XWIKI-10449 . The main problem is the > > > > findability of this functionality. Users might never press that icon > > > (this > > > > problem applies to the solution brainstorming and the breadcrumb > > > proposal). > > > > > > > > So I think the idea to have an entry with "Go to ..." could be a > solution > > > > and to keep the menus interact with the default behavior (removing > the > > > > navigation from the dropdown activator). > > > > Removing triangles is not an option. That is a default menu marker > caret. > > > > > > > > So what are the next steps? We do a issue with the "Go to ..." > solution? > > > > > > > > > > http://jira.xwiki.org/browse/XWIKI-11166 > > > > > > > > > > Thanks, > > > > Caty > > > > > > > > On Wed, Sep 24, 2014 at 11:55 AM, Guillaume "Louis-Marie" Delhumeau < > > > > [email protected]> wrote: > > > > > > > >> Hi. > > > >> > > > >> I am happy that this topic is coming back. > > > >> > > > >> 2014-09-24 10:04 GMT+02:00 [email protected] : > > > >> > > > >> > Hi devs, > > > >> > > > > >> > I’ve had a few persons tell me that they don’t like the small > arrow in > > > >> the > > > >> > top level menu in Flamingo. It seems they either don’t understand > the > > > >> > little triangles and what it’s about (submenu?) or they click on > the > > > >> menu > > > >> > itself and go to another page when they were expecting some menu > to > > > drop > > > >> > down, or... > > > >> > > > > >> > > > >> I don't like it neither. It is not consistent with other projects > (such > > > as > > > >> JIRA). It is not consistent with what we are planning to do about > the UI > > > >> language (see: > > > >> > > > >> > > > >
http://design.xwiki.org/xwiki/bin/download/Proposal/InterfaceAndContentLangu...
> > > >> ). > > > >> It is harder to use on mobiles, and people are surprised by what > occurs > > > >> when they click on it. > > > >> > > > >> > > > >> > > > > >> > In addition we’re still missing a solution to easily navigate the > wiki > > > >> > from any page (there’s the ctrl+G solution but this is more like a > > > >> shortcut > > > >> > to know and we need something more). > > > >> > > > > >> > So here are some ideas: > > > >> > > > > >> > * For the top level menu, make it simpler by having the drop down > > > >> display > > > >> > when you click anywhere in the menu (the whole width of it) and > only > > > >> > navigate when you double click (there are actually few reasons to > need > > > >> to > > > >> > navigate with the other idea below so we could also not do the > double > > > >> click > > > >> > thing) > > > >> > > > > >> > > > >> +1 > > > >> > > > >> > > > >> > > > > >> > * In the breadcrumb OR in the top level menu OR in both (to be > > > decided) > > > >> > use something like this (screenshot taken from IntelliJ IDEA): > > > >> > > > > >> > > > > >> > > > >
https://www.evernote.com/shard/s119/sh/20e99ab3-2991-4aa8-a7b5-93088aad4944/...
> > > >> > > > > >> > This means when you click at a given level you get to see all > sibling > > > >> > elements in the wiki for element you’re currently on (document, > space, > > > >> > wiki). > > > >> > > > > >> > For example clicking on the “Home” wiki would show: > > > >> > - A filter box allowing you to type and it would auto suggest as > you > > > >> type, > > > >> > completing with wiki names > > > >> > - An icon would be displayed on the left (or on the right) of the > > > filter > > > >> > box and if you click on it you’ll go the index page (Wiki Index in > > > this > > > >> > case) > > > >> > - A list of the first 10 wikis (an improvement would be to list > first > > > >> the > > > >> > wiki that you’ve last navigated to) > > > >> > > > > >> > Same would apply for spaces and pages. > > > >> > > > > >> > We could even imagine that when you’re on a user profile page, > > > clicking > > > >> on > > > >> > it would display other user pages and the filter would filter on > user > > > >> > pages. Actually we could imagine to when the current page has > XObjects > > > >> in > > > >> > it, it would be possible to list all other pages in the wiki > having > > > the > > > >> > same XClass. And if there are several XObjects, then somehow in > the UI > > > >> > allow selecting which one to consider as the filter criteria. > > > >> > > > > >> > * Note 1: The breadcrumb is currently not displayed on all pages > (it’s > > > >> not > > > >> > on the home page for example) and thus if we implement this idea > in > > > the > > > >> > breadcrumb only then there’s no solution for navigating on the > home > > > >> page. > > > >> > > > > >> > > > >> This is a behaviour that I have put because I thought it was not > pretty > > > to > > > >> have a useless breadcrumb on the home page. It can be changed. > > > >> > > > >> > > > >> > > > > >> > * Note 2: If we were to implement this idea on the top level menu, > > > then > > > >> we > > > >> > still need to display the actions too. Several options: > > > >> > - a) Display the actions first and the navigation list after > separated > > > >> by > > > >> > a ----- > > > >> > - b) Have a first entry in the drop down that says “Actions...” > and > > > when > > > >> > you move the mouse over it a secondary menu with all actions are > > > >> displayed. > > > >> > Note that the alternative is possible too: Display the actions and > > > have > > > >> a > > > >> > “Go to..." menu entry. We would just need to choose to display > what we > > > >> > think is the most used default (actions or navigation) > > > >> > > > > >> > > > >> +1 > > > >> > > > >> > > > >> > > > > >> > WDYT? > > > >> > > > > >> > Personally I would do this: > > > >> > - implement this idea for the breadcrumb > > > >> > > > > >> > > > >> +0, I need to think more about it > > > >> > > > >> > > > >> > - add “Go to wiki...”, “Go to space...", “Go to page..." menu > entries > > > in > > > >> > the Wiki/Space/Page top level menus > > > >> > > > > >> > > > >> +1 > > > >> > > > >> > > > >> > - expand the menu selection to the whole width for displaying the > drop > > > >> > down (and not just above the small arrow) > > > >> > > > > >> > > > >> +1 > > > >> > > > >> > > > >> > - either support double-click or simply add the possibility to > > > navigate > > > >> to > > > >> > that element in the “Go to xxx...” submenu > > > >> > > > > >> > > > >> +1 > > > >> > > > >> > > > >> > > > > >> > Thanks > > > >> > -Vincent > > > >> > > > > >> > > > > >> > _______________________________________________ > > > >> > devs mailing list > > > >> > [email protected] > > > >> > http://lists.xwiki.org/mailman/listinfo/devs > > > >> > > > > >> > > > >> > > > >> > > > >> -- > > > >> Guillaume Delhumeau ([email protected]) > > > >> Research & Development Engineer at XWiki SAS > > > >> Committer on the XWiki.org project
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 <[email protected]> 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, [email protected] <[email protected]> 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 ([email protected](mailto: [email protected])) wrote:
On Thu, Oct 9, 2014 at 5:59 PM, [email protected] wrote:
On 9 Oct 2014 at 17:57:46, Jeremie BOUSQUET (
(mailto:[email protected])) wrote:
Hi,
In fact, colibri top-menu was better than bootstrap buttons ! :D
Why not putting back old ways of interacting ? - re-add display of dropdown menu on hover [1] - re-add underlining on hover of links in menu text
The reason we changed that was for mobiles. We could decide to have different behaviors on mobile and desktops but not sure it’s best. WDYT?
I think it's not bad to have a slightly different behaviour for desktop and mobile. I don't have much experience with this but I think that we should not ruin desktop experience because it has to work on mobile. If different behaviour is the solution, let's do it.
I think the old behaviour with the hover was quite natural, and the fact that bootstrap does not have those buttons by default is because it's mobile first. But, as much as we'd want it, XWiki is not yet mobile first (I would say most of the usage of XWiki today is still desktop, but since I don't have statistics I cannot prove it. I can only use my personal statistic, from my experience and the cases I know).
2 clicks feels completely unnatural on desktop, especially when coming from colibri.
I would not want to let Bootstrap kill our UI choices, I think it's the bad reason to say that "we won't do it because bootstrap does not have a default component for it".
Thanks, Anca
Thanks -Vincent
Problem I feel is for second item as it seems bootstrap won't
easily
allow
you to hover on something (for dropdown) and click on it (to do something else than show dropdown). Also I suppose there are impacts on mobile version.
I don't think the new flamingo way is bad, but visually it looks very similar to colibri (a text + a little triangle), but when you hover nothing happens, and you have no visual clue that something different may happen if you click on the text or on the triangle. For example take the "New" button in Outlook 2007 which is exactly a dropdown button, when I hover on it I see a clear separation between the "New" text, and the arrow, so I can assume that both lead to different results.
With the "Add" and "Edit" buttons it's completely different, you see the separation, and on hoovering the color changes (of the text OR of the arrow background). You are prepared to the fact that something different will occur. But doing the same in top menu would clearly not fit expected look&feel of this beautiful skin...
BR, Jeremie
[1] - http://cameronspear.com/demos/bootstrap-hover-dropdown/
2014-10-09 16:02 GMT+02:00 [email protected] :
On 9 Oct 2014 at 14:23:49, Eduard Moraru ([email protected]
(mailto:
[email protected])) wrote:
> On Thu, Oct 9, 2014 at 3:15 PM, [email protected] > wrote: > > > > > > > > > > > > > On 9 Oct 2014 at 14:02:05, Eduard Moraru ( [email protected] (mailto: > > [email protected])) wrote: > > > > > Folks, you speak of consistency and then come up with this solution... > > > > > > So we have a problem with "non-standard bootstrap dropdown buttons" that > > > our users (whoever they may be) have a problem with understanding that > > > there is either an action or a dropdown involved in the same button, like > > > they can encounter in other interfaces along their computer usage > > history. > > > > > > Our solution is to stop using the mixed mode, and only use the "standard > > > bootstrap dropdown buttons" that have their first action in the submenu > > the > > > thing that would have happened in the past when the users clicked > > directly > > > the action part of the "mixed button" we were using. > > > > > > Ok, we implement this solution, but we only do it for the top > > navigational > > > elements. We completely ignore the "Add" and the "Edit" buttons that > > > "suffer" from exactly the same "problem". > > > > > > My question is: why? > > > > > > If we do/did decide that this is the way to go, we should at least be > > > consistent and do it everywhere in the UI, otherwise it just causes > > > frustrations. > > > > There’s a difference. For the Edit/Add button click the button will do > > what the user wants. Click the arrow is only for advanced featurs. > > > > "It seems they either don’t understand the little triangles and what it’s > about (submenu?) or they click on the menu itself and go to another page > when they were expecting some menu to drop down, or.." > > There is no difference from the "problem" you have mentioned in the OP. The > user sees an arrow and clicks on the button to expand the menu, but instead > ends up reloading the page (either to edit mode or to view mode, same > thing). You will say that he wanted to edit anyway, yes, but maybe he did > not want to edit in the default mode, so the user's "intent" (as you > defined it in the OP) is still not respected. > > We either do it one way, or the other, all I ask for is consistency. Do we > want to introduce yet another compromise in this young skin?
The problem I saw is that users were not clicking the arrow but the main button part (thus navigating instead of having the main options).
What we want is that it’s the simplest possible for the user for his use case at hand: - When I click Edit or Add (not the arrow, the button) it’s the simplest possible. Edit will choose the good default mode and add will add a page - When I click the wiki/space/page button (not the arrow) I want the actions to be displayed rather than the navigation since navigation is a secondary use case for these buttons
At least that’s how I view it.
Forcing the user to have 2 clicks to do the main action on a button would be a pity.
Now you’re going to say that we could keep the arrow for the wiki/space/page buttons to navigate. We could, but it doesn’t feel natural.
What do you suggest?
Thanks -Vincent
> Thanks, > Eduard > > > > > Thanks > > -Vincent > > > > > Thanks, > > > Eduard > > > > > > On Fri, Oct 3, 2014 at 4:21 PM, Ecaterina Moraru (Valica)
wrote:
> > > > > > > On Wed, Sep 24, 2014 at 5:25 PM, Ecaterina Moraru (Valica) < > > > > [email protected]> wrote: > > > > > > > > > Hi, > > > > > > > > > > Some background: > > > > > * Colibri > > > > > ** menus displayed on hover > > > > > ** custom menu JS > > > > > ** menu entries could be icon+label+separator+link+whatever > > > > > > > > > > * Flamingo > > > > > ** menus displayed on click > > > > > ** menu component from Bootstrap > > > > > ** it expects simple links or menu dropdown containers (not both > > > > functions) > > > > > > > > > > Theoretically Bootstrap doesn't support our use case and cannot > > replicate > > > > > by default the Colibri's behavior. > > > > > Any change we want to make to the menu Bootstrap component means we > > are > > > > > branching from the default behavior and we will create a custom one. > > > > > We really need to listen to clicks and not hover state, since we > > need to > > > > > be mobile compatible. > > > > > > > > > > It's normal that the users feel a bit confused since they are used > > with a > > > > > certain behavior and we tried to mix them in order to have both menu > > and > > > > > navigation use cases. > > > > > And I think the reason is a bit confusing is that the separation > > between > > > > > the link and the arrow is invisible, compared with the btn-groups > > used > > > > for > > > > > Edit or Add. For example, I think that making the separation more > > clean, > > > > > like in this screenshot > > > > > http://jira.xwiki.org/secure/attachment/28807/btn-group.png would > > > > improve > > > > > a bit the things, but would need visual improvements and is not > > default > > > > > also. Maybe we could think of a better solution if we were to go on > > this > > > > > path. > > > > > > > > > > Behavior like double clicking a certain element will be a hidden > > > > > interaction for the users. Double clicking is not a Web behavior and > > you > > > > > cannot expect users to know on which links to simple click vs. on > > which > > > > to > > > > > double click. In the usability testing sessions users had a hard > > time to > > > > > double click on uploading image in the WYSIWYG popup, so I'm not sure > > > > about > > > > > this approach's success. > > > > > > > > > > Regarding the IntelliJ IDEA screenshot, we already discuss about this > > > > idea > > > > > and even made a similar proposal some long time ago, see > > > > > > >
http://design.xwiki.org/xwiki/bin/view/Improvements/ActionMenuNavigation
> > > > > Although this proposal is a nice idea and I would like to have it, I > > > > don't > > > > > see how this would 'simplify' the current implementation. IMO it will > > > > make > > > > > it even more complex and we would certainly need a custom menu. Also > > I > > > > see > > > > > this as a new feature, than a solution to our current problem. > > > > > > > > > > When we implemented the current solution we discussed if the > > navigation > > > > > should be put on the text or on the icon, see > > > > > http://jira.xwiki.org/browse/XWIKI-10449 . The main problem is the > > > > > findability of this functionality. Users might never press that icon > > > > (this > > > > > problem applies to the solution brainstorming and the breadcrumb > > > > proposal). > > > > > > > > > > So I think the idea to have an entry with "Go to ..." could be a > > solution > > > > > and to keep the menus interact with the default behavior (removing > > the > > > > > navigation from the dropdown activator). > > > > > Removing triangles is not an option. That is a default menu marker > > caret. > > > > > > > > > > So what are the next steps? We do a issue with the "Go to ..." > > solution? > > > > > > > > > > > > > http://jira.xwiki.org/browse/XWIKI-11166 > > > > > > > > > > > > > Thanks, > > > > > Caty > > > > > > > > > > On Wed, Sep 24, 2014 at 11:55 AM, Guillaume "Louis-Marie" Delhumeau < > > > > > [email protected]> wrote: > > > > > > > > > >> Hi. > > > > >> > > > > >> I am happy that this topic is coming back. > > > > >> > > > > >> 2014-09-24 10:04 GMT+02:00 [email protected] : > > > > >> > > > > >> > Hi devs, > > > > >> > > > > > >> > I’ve had a few persons tell me that they don’t like the small > > arrow in > > > > >> the > > > > >> > top level menu in Flamingo. It seems they either don’t understand > > the > > > > >> > little triangles and what it’s about (submenu?) or they click on > > the > > > > >> menu > > > > >> > itself and go to another page when they were expecting some menu > > to > > > > drop > > > > >> > down, or... > > > > >> > > > > > >> > > > > >> I don't like it neither. It is not consistent with other projects > > (such > > > > as > > > > >> JIRA). It is not consistent with what we are planning to do about > > the UI > > > > >> language (see: > > > > >> > > > > >> > > > > > >
http://design.xwiki.org/xwiki/bin/download/Proposal/InterfaceAndContentLangu...
> > > > >> ). > > > > >> It is harder to use on mobiles, and people are surprised by what > > occurs > > > > >> when they click on it. > > > > >> > > > > >> > > > > >> > > > > > >> > In addition we’re still missing a solution to easily navigate the > > wiki > > > > >> > from any page (there’s the ctrl+G solution but this is more like a > > > > >> shortcut > > > > >> > to know and we need something more). > > > > >> > > > > > >> > So here are some ideas: > > > > >> > > > > > >> > * For the top level menu, make it simpler by having the drop down > > > > >> display > > > > >> > when you click anywhere in the menu (the whole width of it) and > > only > > > > >> > navigate when you double click (there are actually few reasons to > > need > > > > >> to > > > > >> > navigate with the other idea below so we could also not do the > > double > > > > >> click > > > > >> > thing) > > > > >> > > > > > >> > > > > >> +1 > > > > >> > > > > >> > > > > >> > > > > > >> > * In the breadcrumb OR in the top level menu OR in both (to be > > > > decided) > > > > >> > use something like this (screenshot taken from IntelliJ IDEA): > > > > >> > > > > > >> > > > > > >> > > > > > >
https://www.evernote.com/shard/s119/sh/20e99ab3-2991-4aa8-a7b5-93088aad4944/...
> > > > >> > > > > > >> > This means when you click at a given level you get to see all > > sibling > > > > >> > elements in the wiki for element you’re currently on (document, > > space, > > > > >> > wiki). > > > > >> > > > > > >> > For example clicking on the “Home” wiki would show: > > > > >> > - A filter box allowing you to type and it would auto suggest as > > you > > > > >> type, > > > > >> > completing with wiki names > > > > >> > - An icon would be displayed on the left (or on the right) of the > > > > filter > > > > >> > box and if you click on it you’ll go the index page (Wiki Index in > > > > this > > > > >> > case) > > > > >> > - A list of the first 10 wikis (an improvement would be to list > > first > > > > >> the > > > > >> > wiki that you’ve last navigated to) > > > > >> > > > > > >> > Same would apply for spaces and pages. > > > > >> > > > > > >> > We could even imagine that when you’re on a user profile page, > > > > clicking > > > > >> on > > > > >> > it would display other user pages and the filter would filter on > > user > > > > >> > pages. Actually we could imagine to when the current page has > > XObjects > > > > >> in > > > > >> > it, it would be possible to list all other pages in the wiki > > having > > > > the > > > > >> > same XClass. And if there are several XObjects, then somehow in > > the UI > > > > >> > allow selecting which one to consider as the filter criteria. > > > > >> > > > > > >> > * Note 1: The breadcrumb is currently not displayed on all pages > > (it’s > > > > >> not > > > > >> > on the home page for example) and thus if we implement this idea > > in > > > > the > > > > >> > breadcrumb only then there’s no solution for navigating on the > > home > > > > >> page. > > > > >> > > > > > >> > > > > >> This is a behaviour that I have put because I thought it was not > > pretty > > > > to > > > > >> have a useless breadcrumb on the home page. It can be changed. > > > > >> > > > > >> > > > > >> > > > > > >> > * Note 2: If we were to implement this idea on the top level menu, > > > > then > > > > >> we > > > > >> > still need to display the actions too. Several options: > > > > >> > - a) Display the actions first and the navigation list after > > separated > > > > >> by > > > > >> > a ----- > > > > >> > - b) Have a first entry in the drop down that says “Actions...” > > and > > > > when > > > > >> > you move the mouse over it a secondary menu with all actions are > > > > >> displayed. > > > > >> > Note that the alternative is possible too: Display the actions and > > > > have > > > > >> a > > > > >> > “Go to..." menu entry. We would just need to choose to display > > what we > > > > >> > think is the most used default (actions or navigation) > > > > >> > > > > > >> > > > > >> +1 > > > > >> > > > > >> > > > > >> > > > > > >> > WDYT? > > > > >> > > > > > >> > Personally I would do this: > > > > >> > - implement this idea for the breadcrumb > > > > >> > > > > > >> > > > > >> +0, I need to think more about it > > > > >> > > > > >> > > > > >> > - add “Go to wiki...”, “Go to space...", “Go to page..." menu > > entries > > > > in > > > > >> > the Wiki/Space/Page top level menus > > > > >> > > > > > >> > > > > >> +1 > > > > >> > > > > >> > > > > >> > - expand the menu selection to the whole width for displaying the > > drop > > > > >> > down (and not just above the small arrow) > > > > >> > > > > > >> > > > > >> +1 > > > > >> > > > > >> > > > > >> > - either support double-click or simply add the possibility to > > > > navigate > > > > >> to > > > > >> > that element in the “Go to xxx...” submenu > > > > >> > > > > > >> > > > > >> +1 > > > > >> > > > > >> > > > > >> > > > > > >> > Thanks > > > > >> > -Vincent > > > > >> > > > > > >> > > > > > >> > _______________________________________________ > > > > >> > devs mailing list > > > > >> > [email protected] > > > > >> > http://lists.xwiki.org/mailman/listinfo/devs > > > > >> > > > > > >> > > > > >> > > > > >> > > > > >> -- > > > > >> Guillaume Delhumeau ([email protected]) > > > > >> Research & Development Engineer at XWiki SAS > > > > >> Committer on the XWiki.org project
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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 <[email protected]> wrote:
Folks, you speak of consistency and then come up with this solution...
So we have a problem with "non-standard bootstrap dropdown buttons" that our users (whoever they may be) have a problem with understanding that there is either an action or a dropdown involved in the same button, like they can encounter in other interfaces along their computer usage history.
Our solution is to stop using the mixed mode, and only use the "standard bootstrap dropdown buttons" that have their first action in the submenu the thing that would have happened in the past when the users clicked directly the action part of the "mixed button" we were using.
Ok, we implement this solution, but we only do it for the top navigational elements. We completely ignore the "Add" and the "Edit" buttons that "suffer" from exactly the same "problem".
My question is: why?
If we do/did decide that this is the way to go, we should at least be consistent and do it everywhere in the UI, otherwise it just causes frustrations.
Thanks, Eduard
On Fri, Oct 3, 2014 at 4:21 PM, Ecaterina Moraru (Valica) < [email protected]> wrote:
On Wed, Sep 24, 2014 at 5:25 PM, Ecaterina Moraru (Valica) < [email protected]> wrote:
Hi,
Some background: * Colibri ** menus displayed on hover ** custom menu JS ** menu entries could be icon+label+separator+link+whatever
* Flamingo ** menus displayed on click ** menu component from Bootstrap ** it expects simple links or menu dropdown containers (not both functions)
Theoretically Bootstrap doesn't support our use case and cannot replicate by default the Colibri's behavior. Any change we want to make to the menu Bootstrap component means we are branching from the default behavior and we will create a custom one. We really need to listen to clicks and not hover state, since we need to be mobile compatible.
It's normal that the users feel a bit confused since they are used with a certain behavior and we tried to mix them in order to have both menu and navigation use cases. And I think the reason is a bit confusing is that the separation between the link and the arrow is invisible, compared with the btn-groups used for Edit or Add. For example, I think that making the separation more clean, like in this screenshot http://jira.xwiki.org/secure/attachment/28807/btn-group.png would improve a bit the things, but would need visual improvements and is not default also. Maybe we could think of a better solution if we were to go on this path.
Behavior like double clicking a certain element will be a hidden interaction for the users. Double clicking is not a Web behavior and you cannot expect users to know on which links to simple click vs. on which to double click. In the usability testing sessions users had a hard time to double click on uploading image in the WYSIWYG popup, so I'm not sure about this approach's success.
Regarding the IntelliJ IDEA screenshot, we already discuss about this idea and even made a similar proposal some long time ago, see
http://design.xwiki.org/xwiki/bin/view/Improvements/ActionMenuNavigation
Although this proposal is a nice idea and I would like to have it, I don't see how this would 'simplify' the current implementation. IMO it will make it even more complex and we would certainly need a custom menu. Also I see this as a new feature, than a solution to our current problem.
When we implemented the current solution we discussed if the navigation should be put on the text or on the icon, see http://jira.xwiki.org/browse/XWIKI-10449 . The main problem is the findability of this functionality. Users might never press that icon (this problem applies to the solution brainstorming and the breadcrumb proposal).
So I think the idea to have an entry with "Go to ..." could be a solution and to keep the menus interact with the default behavior (removing the navigation from the dropdown activator). Removing triangles is not an option. That is a default menu marker caret.
So what are the next steps? We do a issue with the "Go to ..." solution?
http://jira.xwiki.org/browse/XWIKI-11166
Thanks, Caty
On Wed, Sep 24, 2014 at 11:55 AM, Guillaume "Louis-Marie" Delhumeau < [email protected]> wrote:
Hi.
I am happy that this topic is coming back.
2014-09-24 10:04 GMT+02:00 [email protected] <[email protected]>:
Hi devs,
I’ve had a few persons tell me that they don’t like the small arrow in the top level menu in Flamingo. It seems they either don’t understand the little triangles and what it’s about (submenu?) or they click on the menu itself and go to another page when they were expecting some menu to drop down, or...
I don't like it neither. It is not consistent with other projects (such as JIRA). It is not consistent with what we are planning to do about the UI language (see:
http://design.xwiki.org/xwiki/bin/download/Proposal/InterfaceAndContentLangu...
). It is harder to use on mobiles, and people are surprised by what occurs when they click on it.
In addition we’re still missing a solution to easily navigate the
wiki
from any page (there’s the ctrl+G solution but this is more like a shortcut to know and we need something more).
So here are some ideas:
* For the top level menu, make it simpler by having the drop down display when you click anywhere in the menu (the whole width of it) and only navigate when you double click (there are actually few reasons to need to navigate with the other idea below so we could also not do the double click thing)
+1
* In the breadcrumb OR in the top level menu OR in both (to be
decided)
use something like this (screenshot taken from IntelliJ IDEA):
https://www.evernote.com/shard/s119/sh/20e99ab3-2991-4aa8-a7b5-93088aad4944/...
This means when you click at a given level you get to see all sibling elements in the wiki for element you’re currently on (document,
space,
wiki).
For example clicking on the “Home” wiki would show: - A filter box allowing you to type and it would auto suggest as you type, completing with wiki names - An icon would be displayed on the left (or on the right) of the filter box and if you click on it you’ll go the index page (Wiki Index in this case) - A list of the first 10 wikis (an improvement would be to list first the wiki that you’ve last navigated to)
Same would apply for spaces and pages.
We could even imagine that when you’re on a user profile page, clicking on it would display other user pages and the filter would filter on user pages. Actually we could imagine to when the current page has XObjects in it, it would be possible to list all other pages in the wiki having the same XClass. And if there are several XObjects, then somehow in the UI allow selecting which one to consider as the filter criteria.
* Note 1: The breadcrumb is currently not displayed on all pages (it’s not on the home page for example) and thus if we implement this idea in the breadcrumb only then there’s no solution for navigating on the home page.
This is a behaviour that I have put because I thought it was not pretty to have a useless breadcrumb on the home page. It can be changed.
* Note 2: If we were to implement this idea on the top level menu,
then we
still need to display the actions too. Several options: - a) Display the actions first and the navigation list after separated by a ----- - b) Have a first entry in the drop down that says “Actions...” and when you move the mouse over it a secondary menu with all actions are displayed. Note that the alternative is possible too: Display the actions and have a “Go to..." menu entry. We would just need to choose to display what we think is the most used default (actions or navigation)
+1
WDYT?
Personally I would do this: - implement this idea for the breadcrumb
+0, I need to think more about it
- add “Go to wiki...”, “Go to space...", “Go to page..." menu entries in the Wiki/Space/Page top level menus
+1
- expand the menu selection to the whole width for displaying the drop down (and not just above the small arrow)
+1
- either support double-click or simply add the possibility to navigate to that element in the “Go to xxx...” submenu
+1
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
participants (9)
-
Anca Luca -
Ecaterina Moraru (Valica) -
Eduard Moraru -
Guillaume "Louis-Marie" Delhumeau -
Guillaume Lerouge -
Jean SIMARD -
Jeremie BOUSQUET -
Thomas Mortagne -
vincent＠massol.net