[Kimchi-devel] UI Change Request - Navigation

Tue Oct 13 15:17:43 UTC 2015

Aline,

I consider making the user select a tab named "Kimchi"  or "Ginger" very 
confusing because she/he will have to learn the hard way which is the 
one she/he is looking for.
I see your point about clarity on the responsabiltiy of a certain 
plugin.  I would propose to have the plugin name and potentially its 
icon as well visible when the respective tab is activ.

Regards,
Walter.

On 13.10.2015 16:29, Aline Manera wrote:
>
> My suggestion is to use the plugin name as the first tab level.
>
> So instead of "Host", Ginger. And instead of "Virtualization", Kimchi.
> That way the user is aware on each plugin is responsible for what and 
> also give the plugin more visibility inside wok.
>
> Regards,
> Aline Manera
>
> On 09/10/2015 11:36, 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:
>>
>> 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.
>>
>>
>> Regards,
>>
>> Samuel
>>
>> *From:*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>
>> *Cc:* 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/219d6c49/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/219d6c49/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/219d6c49/attachment-0001.jpe>