[Kimchi-devel] UI Change Request - Navigation
Socorro Stoppler
socorro at linux.vnet.ibm.com
Tue Oct 13 16:56:17 UTC 2015
In previous projects I've been on, we've had a Home page that listed the
various plugins (and the user can then click on the individual plugins
to go to the appropriate pages).
Just my two cents :)
-Socorro
On 10/13/2015 09:45 AM, Paulo Ricardo Paz Vital wrote:
> On Tue, 2015-10-13 at 17:17 +0200, Walter Niklaus wrote:
>> 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 agree with Walter in this point. For the user is much easier to
> browse by the tabs using it's functionality and area names than the
> plugin names.
>
> Let's remember that the main goal of Wok, Kimchi and Ginger is make
> easier the life of a user with ** NO ** knowledge about virtualization
> (and why not sys admin, too).
>
>
>> 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.
>>
> Why not add in some part of the screen the name of the plugin that is
> providing that page or, may be, a 'plugin management' screen listing
> all plugin names and each area/functionality it's providing?
>
> Best regards,
> Paulo Vital
>
>> 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
>> _______________________________________________
>> Kimchi-devel mailing list
>> Kimchi-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
More information about the Kimchi-devel
mailing list