Re: [Kimchi-devel] UI Change Request - Navigation

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@linux.vnet.ibm.com] > *Sent:* sexta-feira, 9 de outubro de 2015 13:06 > *To:* Samuel Henrique De Oliveira Guimaraes > <samuel.guimaraes(a)eldorado.org.br>; Aline Manera > <alinefm(a)linux.vnet.ibm.com&gt; > *Cc:* kimchi-devel(a)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@ovirt.org > <mailto:kimchi-devel-bounces@ovirt.org>[mailto:kimchi-devel-bounces@ovirt.org] > *On Behalf Of *Jan Schneider > *Sent:* quinta-feira, 8 de outubro de 2015 13:10 > *To:* Aline Manera <alinefm(a)linux.vnet.ibm.com&gt; > <mailto:alinefm@linux.vnet.ibm.com> > *Cc:* kimchi-devel(a)ovirt.org <mailto:kimchi-devel@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(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel