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.
It is becoming a mess!!!! That way we will have more menus than content.
It is the same to create a new menu entry for each collapsed content in
Ginger plugin.
I tend to agree with 2 top-level tabs but *without* any vertical menu!!!
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:
imap://alinefm@imap.linux.ibm.com:993/fetch%3EUID%3E.kimchi-devel%3E11925?header=quotebody&part=1.1.2&filename=image001.jpg
imap://alinefm@imap.linux.ibm.com:993/fetch%3EUID%3E.kimchi-devel%3E11925?header=quotebody&part=1.1.3&filename=image002.jpg
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.
imap://alinefm@imap.linux.ibm.com:993/fetch%3EUID%3E.kimchi-devel%3E11925?header=quotebody&part=1.1.4&filename=image003.jpg
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(a)linux.vnet.ibm.com>
<mailto:alinefm@linux.vnet.ibm.com>
*Cc:* kimchi-devel(a)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