[Kimchi-devel] UI Change Request - Navigation

Tue Oct 13 14:11:41 UTC 2015

On 09/10/2015 16:07, Samuel Henrique De Oliveira Guimaraes wrote:
>
> 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 at linux.vnet.ibm.com]
> *Sent:* sexta-feira, 9 de outubro de 2015 13:06
> *To:* Samuel Henrique De Oliveira Guimaraes 
> <samuel.guimaraes at eldorado.org.br>; Aline Manera 
> <alinefm at linux.vnet.ibm.com>
> *Cc:* kimchi-devel at 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 at ovirt.org
>     <mailto:kimchi-devel-bounces at ovirt.org>[mailto:kimchi-devel-bounces at ovirt.org]
>     *On Behalf Of *Jan Schneider
>     *Sent:* quinta-feira, 8 de outubro de 2015 13:10
>     *To:* Aline Manera <alinefm at linux.vnet.ibm.com>
>     <mailto:alinefm at linux.vnet.ibm.com>
>     *Cc:* kimchi-devel at ovirt.org <mailto:kimchi-devel at 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
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/kimchi-devel/attachments/20151013/505b4dde/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 45433 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/kimchi-devel/attachments/20151013/505b4dde/attachment.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 33049 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/kimchi-devel/attachments/20151013/505b4dde/attachment-0001.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 67941 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/kimchi-devel/attachments/20151013/505b4dde/attachment-0002.jpe>