[Kimchi-devel] UI Change Request - Navigation
Chandra Shehkhar Reddy Potula
chandra at linux.vnet.ibm.com
Wed Oct 14 07:00:14 UTC 2015
I agree with Walter, Paulo and Daniel !!!
We have to provide UI functionality in such way that user experience is
smooth in whatever the actions he/she want to perform instead showing
the features/functionality distinguishes offered by the individual plugins.
We have keep off the developer hat when we are looking into the UI
aspects and think like end user what he/she want to do !!!
I am in favor of proposal 1, which I feel better one to go for !!!
On 10/13/2015 10:43 PM, Daniel Henrique Barboza wrote:
> 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
>
> _______________________________________________
> 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