[Kimchi-devel] UI Change Request - Navigation
Walter Niklaus
niklaus at linux.vnet.ibm.com
Tue Oct 13 14:55:23 UTC 2015
On 13.10.2015 16:17, Aline Manera wrote:
>
>
> 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.
Unfortunately (or fortunately from a functionality point of view) we
will have much more content now in Ginger than we had before:
- the Storage area will have:
- a potentially huge list of block devices (1000 is an
average configuration on a server running KVM on System z)
- filesystem info and actions
- logical volumes and their management
- SAN Adapters
- SWAP devices
- the Networking area will have:
- a list of NICs (including bond and bridge) which could
get quite large on big server
- OVS setup
And in addition we have consolidated the former host and admin tab
functionality now in the same main area/tab.
Having all this functionality in a collapsed content is not going to be
a useable solution because you need to do a lot of scrolling to get from
one area to the others.
Please have look at the example here:
http://www.ibm.com/design/language/framework/visual/introduction
Having this implementation seen in action makes me believe that it will
provide improved usability to our users.
>
>>> 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:
>>>
>>>
>>> ... deleted images(Walter Niklaus)
>>>
>>> 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.
>>>
>>> ... deleted images(Walter Niklaus)
>>>
>>> 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
>
>
>
> _______________________________________________
> 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/5db9a99c/attachment.html>
More information about the Kimchi-devel
mailing list