[Kimchi-devel] UI Change Request - Navigation
Walter Niklaus
niklaus at linux.vnet.ibm.com
Mon Oct 12 14:03:10 UTC 2015
Hi Samuel,
my comments are from a user point of view, I'm relying on your insights
when comes to technical doabilty.
Thanks, Walter.
On 09.10.2015 21: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.
>
> 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.
>
Good point. Makes sense to me.
>
> 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/.
>
I like a lot of the aspects from what's implemented on the globo.com page:
- the menue doesn't take away any real estate from your screen,
therefore having an additional level of navigation isn't such a big issue.
- you can get to your target menue in one click
- from what I see, it gives you the possibility to turn back on the
previous level tabs with just one click. Did I get that right ?
If all this is right, then I'm perfectly ok with this proposal.
>
> 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.
>
Our base assumption was that plugins wouldn't be restricted to new tabs
only when using the new framework.
Based on that assumption we decided that the functionality which was in
the Administration tab in the old design, would now be extending the
functionality of the Host tab in the new design.
Ideally a new plugin could be extending functionality on any level, and
even on multiple levels.
Here the use cases I'm aware of:
- plugin as a new tab --> for example containers may be one
- plugin extending an existing tab
--> Ginger extending the Host tab which was created by
Ginger-common
--> Aline's example with the peer hosts
- plugin extending one or more individual UI-panels with functionality
--> Gingers390x plugin offering "Enable/Add Network",
"Enable/Add SAN Adapter" Action-button on the Networking and Storage
screens
since these are platform specific functions implemented
in this specific plugin
Samuel, could we cover all these use-cases via the approach you
mentioned as the "sort of path in tab-ext.xml" ? I guess that would be
great because it sounds very flexible.
> 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://niklaus@imap.linux.ibm.com:993/fetch%3EUID%3E.INBOX%3E934?header=quotebody&part=1.1.2&filename=image001.jpg
>
> imap://niklaus@imap.linux.ibm.com:993/fetch%3EUID%3E.INBOX%3E934?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://niklaus@imap.linux.ibm.com:993/fetch%3EUID%3E.INBOX%3E934?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
>
>
>
> _______________________________________________
> Kimchi-devel mailing list
> Kimchi-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/kimchi-devel/attachments/20151012/0837ef70/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/20151012/0837ef70/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/20151012/0837ef70/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/20151012/0837ef70/attachment-0002.jpe>
More information about the Kimchi-devel
mailing list