[Kimchi-devel] UI Change Request - Navigation
Daniel Henrique Barboza
dhbarboza82 at gmail.com
Tue Oct 13 17:13:48 UTC 2015
I believe we can keep the tabs containing the name/title of the feature
instead of
the plug-in name and, post 2.0, we can think about adding the loaded
plug-ins
information in the About page or somewhere else.
If I'm not mistaken I think the login page contains the logos of all the
plug-ins
loaded and a mouseover in the logo will show the plug-in name. It's not
like the
user will be completely clueless about which plug-ins are loaded or not.
On 10/13/2015 01:56 PM, Socorro Stoppler wrote:
> 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
>
> _______________________________________________
> 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