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:
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
On Tue, 2015-10-13 at 17:17 +0200, Walter Niklaus wrote: 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@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@linux.vnet.ibm.com> Cc: 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@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel