Enhance UX of Navigation

Registered by Jaromir Coufal

Currently there is happening few activities which intends adding new tab into main navigation. Unfortunately current navigation is clumsy to handle these. In this case we need to find better way how to deal with navigation. And it is great opportunity for us to have a look at overall Horizon's navigation and enhance that in order to satisfy current as well as future needs better.

As the first thing we need to GATHER as much information and feedback about issues as possible.

Then there needs to be DESIGNING part, proposing one (maybe more) possibilities of how to handle overall navigation in the UI better. Of course followed by discussions around in order to get proper feedback and agreement on the solution.

Last part would be IMPLEMENTATION itself which would follow discussed and designed concept.

(Improvement of Information Architecture deserves its own separate blueprint: https://blueprints.launchpad.net/horizon/+spec/improve-ia)

Blueprint information

Jaromir Coufal
Jaromir Coufal
David Lyle
Series goal:
Accepted for icehouse
Milestone target:
milestone icon 2014.1
Started by
David Lyle
Completed by
David Lyle


[jcoufal] So, firstly, my thanks to all participants who gave feedback (at any source). It was all very valuable and helpful. I went through all of that and put together a summary of current issues:

1) Navigation is not scaling for more dashboards (Project, Admin, ...)
2) Missing more than one level in navigation
3) Each dashboard might contain different hierarchy (number of levels)
4) Missing breadcrumbs (backtrack)
5) Content of dashboards (IA)
6) Improve classing and HTML structure - for better customization

I am looking on information architecture together with some design proposals, which should ideally address 1-5. Updates coming soon.

Implementation details we can address later (6).


[jcoufal] Thanks Toshi for suggestion - It would be great to list here issues, which other contributors are having with navigation:
* Navigation is not scaling for more dashboards (Project, Admin, ...)
* Each dashboard might contain different hierarchy (number of levels)

[jcoufal] Working on wireframes, will include them here soon.

[david-lyle] The current tab system is extremely limited space wise. There is support for the Project, Admin and maybe one more tab with an extremely brief name (e.g., 5 characters in length). Horizon is intended to be an extensible platform. Allowing at most one custom dashboard is not overly extensible.

There are two main issues I see here.
1. Horizon should be extensible.
2. What should the included dashboards be?

To solve #1, regardless of the answer to #2 requires an implementation other than a fixed width set of tabs.

A low impact change I've implemented is an accordion style navigation. Which I can contribute if desired.

For #2, I think with the RBAC blueprint work, and because of the almost complete overlap between the two, the Project and Admin dashboards should be merged and what actions the user has access to is based on roles and policy.

[david-lyle] dead end navigation is problematic, that is views with no obvious was to step back out of other than clicking the parent panel link in the left hand nav.

As I mentioned in the G+ Community or maybe other people also mentioned, I feel something is wrong with the project / admin being on the same level of Information Architecture. I think those are different hierarchy in terms of IA.
Header area can be utilized more effectively, maybe some functions could be moved to the header area (such as region).
This is more implementation issue, html (I mean html structure including css classname and idname) and css are not easy to maintenance and customize. For the production uses, I think many people want to change the look and feel or something.

>> David
dead end navigation means such as Network detail or poerdetail? should there be kind of breadcrumb?

[JeffW] Definitely need to solve the problem where structural changes to the navigation require code changes; I would like to see the navigation be config-based so that different orgs can change it to suite their needs. I do like the accordion style proposed by david, as it's something we're also working on in our implementation. Also, in our implementation we basically got rid of the tabs and changed them to stylized links up in a navigation bar, which gives "unlimited" space for dashboards, but really there's no need for so many as others have said.

* Not having a secondary level of navigation in the left-nav really restricts the level of granularity that can be achieved through the navigation. Having an accordion-like nav structure would help this as well as setting a corresponding url convention like we have for the current nav (I.e. The url should be "dashboard/primary_nav/secondary_nav")
* Which leads to my second issue, having a robust breadcrumb system so it is easy for the user to backtrack to previous pages would really help the user from getting lost in drill downs. A strong url convention would make this fairly easy to implement.
* The fixed width of the left nav makes it awkward to have more than 3 dashboards. Instead of the current tab-like structure for adding dashboard we could switch to a drop down.

Longer term (Icehouse or later), laundry list navigation is good for admins, but for non-admin users, a workflow based traversal would hopefully be less confusing for users. A more graphical approach at a high level would help, then show tables when we are down at the detail leveled views where anything but a table would be inferior. Show me the user what resources I have in a hierarchical view and provide me actions to do to those entities.

[lblanchard - 09-06-2013] I've started a discussion on the G+ UX page around this proposal:

Here is a link to the G+ post too:

[jcoufal 2013-09-09]
Added second variant for navigation: http://people.redhat.com/~jcoufal/openstack/2013-09-09_os_navigation.pdf
G+ link: https://plus.google.com/115177641540718537778/posts/EEwGmhfDbHB

[mrunge 2013-09-11]
Jarda, Liz, thank you very much for both proposals, as they make the changes more clear.

I'm a bit concerned about the use of drop down boxes, as they increase the need for mouse clicks. One click to select the drop down box, one to select the target.

[jcoufal 2013-09-11]
Hello Matthias, thanks for the feedback. As for dropdowns, it depends where the dropdown is situated. There are 3 location:

1) Dropdown for Dashboard / Project / Region. In this case, you are right, that user needs 2 clicks in order to change it. Changing contexts is not primary use case in the navigation or header, it is definitely needed, but it won't be used that often. If I ask a question - How often are user switching between projects or regions, the answer would be - not that often and definitely not more than browsing through the navigation items. That's why I consider it ok to go there through 2 clicks. I think that these selectors should be visible but shouldn't take primary role. Anyway, if you have some idea or suggestion how we can improve it any input is definitely welcome.

2) User menu. Here is the same case as 1, this is not primary use case for our end users. They go to user menu only if they need to change settings or log out.

2) Dropdown for tertiary navigation. And here I tried to simplify the access. If you are going to the third level of navigation, we can't afford another horizontal panel, because it will be getting very confusing and hard to orient in. Therefore there is dropdown from second level to access the third one, but you don't have to click on it. You just hover over the second item and the submenu will appear automatically for you. So just one click to access the third level items. We can go even further to 4th or 5th levels (although I really don't recommend to have that deep IA) since you can cascade menus automatically on hovering items. So in conclusion, it is only one click here.

In general, 2 clicks are still ok even for primary functions because not everything can be accessible at one time, especially in very complicated applications. I know that reducing number of clicks is primary goal but there needs to be some line, where it is really needed (mainly primary use cases) and where reducing it might bring more problems (usually secondary functionalities).

Matthias, did this help to solve your concerns? Just let me know if anything is unclear or if there are other concerns.

[mvidori 2013-09-30]
Don't you think that adding a menu at the top of the screen will degrade the UX and usable space. I mean most of people currently have 16:9 screen, if we put a second or a third top bar, in most of the cases the user will have to scroll (which is pretty painful). Horizon does not use all the horizontal space, we will put more blank space on both size of the screen and a lot of informations on the top. Accordions and dropdown are a good way to save space but I think we need to have just one top bar.

[julim 2013-10-02]
I've reviewed both Liz and Jarda's proposal and have commented with several comments on the G+ links for each:

* Liz's proposal: https://plus.google.com/114338935017256814972/posts/coQqJ9e8hHJ
* Jarda's proposal: https://plus.google.com/115177641540718537778/posts/EEwGmhfDbHB

To summarize, both proposals are fairly similar in the overall navigation with the main differences on how they handled selection for Region, Domain, and Project -- both of which were handled either through a dropdown listbox which consisted of a single attribute or a combination of multiple attributes. This was probably the biggest concern in both navigation design proposals as both designs handling of these items do not scale nor address some user stories (or rather meet the use case needs). Refer to comments on G+ for specific details.

[jcoufal 2013-10-04]
There is very simple prototype of one version: http://people.redhat.com/~jcoufal/openstack/navigation/prototype/

Please ignore styling, it's just very quick code, a bit dirty and there are some styling bugs in context selector. I don't want to hold it because of that, we can make it clean in patch proposals then. Just focus on interactions.

mvidori: Hi Max. I believe it won't decrease UX. I completely understand your points and these are exactly right reasons for vertical navigation. In Liz's proposal there are rationals of why horizontal, she has more text then I will write here, but few of my points:
* Horizontal navigation is standard in these days, most people is used to this type of navigation. I don't say it's wrong to have vertical one, I love it, but the truth is, that standard is horizontal.
* Regarding 16:9 monitors - fact is that first position is 16:9 but second highest number is still 4:3, taking around 15% of users [0].
* I don't think that the navigation occupies that much vertical space in the end (see prototype), furthermore it's nto always visible and in the future, I want to have it sticky but collapsable when scrolling. If you compare it to other bigger sites (let's say Google+, CNN, etc), they have horizontal nav as well and it's actually higher than OpenStack proposed one. It is different field of interest, but the common element here is complexity, which is handled great.
* By using flexible design, we can very nicely re-use horizontal space for content.

I'll be honest with you, I was inclining to vertical navigation as well from the beginning. I tried to jump outside of the box - I sketched and tried various options, tested them on various levels and on flexibility. In the end I think that they are pretty close to each other regarding pros and cons, but based on reasons mentioned above, horizontal navigation seems more beneficial. Of course we need to improve content area as well, but we can't do everything at once.

Anyway, thank you very much for sharing your concerns and if more people think that it is better approach, we definitely should put more focus on that.

[0] http://gs.statcounter.com/#resolution-ww-monthly-201210-201309-bar

julim: I will reply on Google+.

I understand your needs, and we have to change the navigation. But (and it will be my last try) side bar is not a part of the old way to design website. The most popular website (http://www.ebizmba.com/articles/most-popular-websites) use it (Facebook, Youtube, Wikipedia, Twitter). They just have one or at least two levels of top bar.

Css framework use them even in their presentation site: bootstrap, purecss (big fan of this one), gumpy, etc...

Even Android has added them in their design recommendations: http://developer.android.com/design/patterns/navigation-drawer.html

"Criticism is easy and art is difficult ; to do is hard, to judge is easy". So, I will try to design something (with the desired features).

[jcoufal 2013-10-04]
Oh, I never said that it's old fashion design and I completely agree that sidebar is very useful feature (especially in these days) and I count with that in some way for future. I was more referring to horizontal vs current vertical navigation.

Anyway, if you have something on your mind, it would be great if you can even just sketch it and bring it here. The whole discussion is happening on Google+ community (https://plus.google.com/u/0/communities/100954512393463248122), but I hope we will move it to better place very soon - working on that.

Looking forward to your ideas and I will try to think about that as well, you definitely have good points.

[mvidori 2013-10-08]
Hi guys!
Here is an example of a design for Horizon : http://horizon-design.maur.12.lc/
The widget at the top is the same has yours jcoufal, I was just too lazy to readapt the js.
Don't look at the source, it is a totally quick and dirty (really dirty, I am ashamed of myself) proof of concept.

[david-lyle 2014-01-18] not quite ready, moving to i-3

Gerrit topic: https://review.openstack.org/#q,topic:bp/navigation-enhancement,n,z

Addressed by: https://review.openstack.org/70034
    Implementing accordion navigation

[david-lyle | 2014-03-01] It came to my attention that the final design spec was never linked here, so adding: http://people.redhat.com/~jcoufal/openstack/navigation/2013-12-03_os_navigation_vertical.pdf


Work Items