[Kimchi-devel] UI Change Request - Navigation
Walter Niklaus
niklaus at linux.vnet.ibm.com
Tue Oct 13 14:27:02 UTC 2015
Hi Samuel,
today I got reminded that we have to pass the accessability tests with
our UI and was searching if the hamburger meneu design would be in the
way of this requirement. I didn't find any clear statement about it but
I got a lot of hits on why to not use hamburger menus:
http://courtneyengle.com/2014/06/24/mobile-responsive-navigation-accessibility/
http://techcrunch.com/2014/05/24/before-the-hamburger-button-kills-you/
https://lmjabreu.com/post/why-and-how-to-avoid-hamburger-menus/
In order to get some feedback or new ideas I contacted a UI-guy I know
from a former project and he pointed me to this:
http://www.ibm.com/design/language/framework/visual/introduction
This is in fact reflecting exactly the concept we need.
Please let me know what you think about it.
Thanks, Walter.
On 12.10.2015 16:03, Walter Niklaus wrote:
> 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:
>>
>> .... 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 image(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
>> <mailto:alinefm at linux.vnet.ibm.com><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/2b4e2a0f/attachment.html>
More information about the Kimchi-devel
mailing list