[Kimchi-devel] UI Change Request - Navigation
Aline Manera
alinefm at linux.vnet.ibm.com
Tue Oct 13 14:17:26 UTC 2015
On 13/10/2015 11:11, Aline Manera wrote:
>
>
> 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!!!
>
Just complementing, the vertical menu should be displayed as collapsed
content as we did for Ginger.
>> 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
>>
>
>
>
> _______________________________________________
> 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/20151013/f71d95cf/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/f71d95cf/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/f71d95cf/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/f71d95cf/attachment-0002.jpe>
More information about the Kimchi-devel
mailing list