2:07 p.m.
Hi,
Although a lot of articles discourages mixing top-level tabs with sidebars, I think in
this specific scenario we can make these patterns work but we have to make sure that the
users won’t be redirected to a blank landing page or we’ll have to create one.
For instance, suppose Containers second-level first item has three children, then when
clicking in “Containers” on the top bar, the user should be redirected to the first item
from this list (in the third level).
I’ve done some prototypes in the past with similar patterns and for the standard user who
navigates on web, this pattern of navigation is confusing. However the average
virtualization, cloud, storage and network operator users are usually facing UIs more
complex than this.
Between the two proposals I’m voting for proposal 1 but I prefer using Hamburger Button to
trigger a floating grouped-menu. This was proposed a few months ago in the ML.
I was in a workshop with some developers from Globo.com (Brazilian news portal) two years
ago when they were implementing this menu. The current version is way more polished than
the one they presented at the time and I really like how it turned. I’m attaching a
screenshot, but you can see it live with animations at http://g1.globo.com/.
This discussion also brings another question, should new plugins be restricted only to new
tabs on the first-level top bar or should we create some sort of “path” in tab-ext.xml?
I.e a new plugin can be appended to a specific region on Hosts Dashboard, on the
second-level (since Aline suggested moving Peer hosts to that area) or even create a new
level on a menu option that previously had no child items.
Regards,
Samuel
From: Jan Schneider [mailto:schneidj@linux.vnet.ibm.com]
Sent: sexta-feira, 9 de outubro de 2015 13:06
To: Samuel Henrique De Oliveira Guimaraes <samuel.guimaraes(a)eldorado.org.br>; Aline
Manera <alinefm(a)linux.vnet.ibm.com>
Cc: kimchi-devel(a)ovirt.org
Subject: Re: [Kimchi-devel] UI Change Request - Navigation
Hi Samuel,
I just had a discussion with Walter. We found that we need up to two navigation levels
under Host. The third navigation level however is not always required.
Please have a look at the two attached proposals to understand our requirements.
Kind regards
Jan and Walter
On 10/09/2015 04:36 PM, Samuel Henrique De Oliveira Guimaraes wrote:
Hi Jan,
I’m not sure if I’m following you. Did you mean changing the second-level navigation to
tabs instead of panel areas? If so should we merge Hosts and Admin tab in one page and
collapse the panels like old-ui behavior (maybe keeping the dashboard statistics on top
unchanged) but with new-ui styles OR add two new tabs to the toolbar?
I think the concept of accordion/collapsible elements works for Admin, but I don’t see it
working for the panels on Hosts tab, unless we group Basic Information, Repositories and
Debug Reports in one single collapsible area.
I also discussed with Aline if we should move Peer Hosts from top to the toolbar and make
it a plugin. Here’s a mockup I did with Chrome:
[cid:image001.jpg@01D10298.ADF2F380]
[cid:image002.jpg@01D10298.ADF2F380]
The reason why I think all panels in these pages can’t be merged in one tab is because if
all panels were collapsed, the page height would be around 3757 pixels. If admin items
were hidden, it would be around 2108 tall. I believe we would have to set the accordions
to hide other items when one item is collapsed. They don’t seem that tall in the PDF
because the images were resized.
I believe we have to study this following a “mobile-first” approach because once we all
agree with the new design, even if we don’t include the mobile design in 2.0 release,
we’ll have to keep some markup ready for responsive design to receive the new styles. I
think this new tab design would need some updates in tab-ext.xml and the JS files before
2.0 release, assuming other people or teams would start developing new plugins from 2.0
and on. If we update how the tabs are built in the UI from 2.0 to 2.1 for instance, that
may turn against us with retro compatibility issues.
[cid:image003.jpg@01D10298.ADF2F380]
Regards,
Samuel
From: kimchi-devel-bounces@ovirt.org<mailto:kimchi-devel-bounces@ovirt.org>
[mailto:kimchi-devel-bounces@ovirt.org] On Behalf Of Jan Schneider
Sent: quinta-feira, 8 de outubro de 2015 13:10
To: Aline Manera
<alinefm@linux.vnet.ibm.com><mailto:alinefm@linux.vnet.ibm.com>
Cc: kimchi-devel@ovirt.org<mailto:kimchi-devel@ovirt.org>
Subject: [Kimchi-devel] UI Change Request - Navigation
Hello Aline,
I refer to the latest version of the
User Interface Design Specification - Kimchi, 2014-12-23 (aka UI Design Spec)
which defines the following structure of functionalities:
Host (second level navigation via panel areas)
Performance (System Statistics)
Basic Information
Repositories
Debug Report
Software Updates
Guests
no second level functionalities
Templates
no second level functionalities
Storage
no second level functionalities
Networks
no second level functionalities
Administration (second level navigation via collapse/expand)
Firmware Update
SEP Configuration
Power Options
Configuration Backup
Network Configuration
SAN Adapters
Sensor Monitor
Problem Statement
We already decided to move all Administration functionalities to Host (currently not
updated in the UI Design Spec).
We are currently facing the following problems:
1) Host now contains 12 second level functionalities, all other (Guests, Templates, ...)
none.
We need to introduce a second level navigation for Host other than collapse/expand
2) The navigation bar elements Storage and Network (refering to Virtualization) also exist
in the Host context.
This might confuse the user.
Proposal
The described problems can be solved with the following changes:
1) Introducing a second level navigation
2) Changing the structure of functionalities as follows:
Host
Performance (System Statistics)
Basic Information
Repositories
Debug Report
Software Updates
Firmware Update
SEP Configuration
Power Options
Configuration Backup
Network Configuration
SAN Adapters
Sensor Monitor
Virtualization
Guests
Templates
Storage
Networks
Containers (future extension)
to be defined
Let's start a discussion on this.
Kind regards
Jan
