<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Samuel,<br>
<br>
just to make it clear, I'm focusing now only on Ginger and the Host
tab. <br>
I don't think that we can wait with changing the navigation in
Ginger post-new-ui since we are planning to ship all this new
functionality already with this release. And due to the new
functionality the place required would be at least 4 times of the
currenlty consumed place, meaning that if we stay with the current
design we would have a huge page (sure with collapsing areas) that
would have the various functionalitites spread over multiple pages
to be scrolled down/up. And if I'm in the context of setting up a
host in its various aspects I need a clear navigation to get from
one area to another.<br>
We are in the process of developing a "New-UI", please lets try to
get the things we identify to require changes done now and not spend
the effort twice.<br>
<br>
When it comes to collect user feedback, I fully agree with you that
based on that feedback we should keep improving things.<br>
<br>
Thanks, Walter.<br>
<br>
<div class="moz-cite-prefix">On 13.10.2015 21:20, Samuel Henrique De
Oliveira Guimaraes wrote:<br>
</div>
<blockquote
cite="mid:bc4b0c57a3c24ac794ac0a9591ebe7d1@serv030.corp.eldorado.org.br"
type="cite">
<pre wrap="">We discussed adding a page showing wok logo + all installed plug-ins logos, something like Juju Charms does: <a class="moz-txt-link-freetext" href="https://jujucharms.com/">https://jujucharms.com/</a>
I do think we need to discuss a new navigation pattern but I believe it should be developed post-new-ui / after 2.0 and before mobile / responsive design development. Once we finish the new-ui html and css, while we test it I can make some quick high-fidelity mockups based on the assets that we have and then I believe we can evaluate with users if they like the current new-ui pattern, if an off-canvas / hamburger menu can replace the current new-ui menu, etc.
I've seen a lot in Wordpress blogs Select / Comboboxes elements instead of a menu. I don't have any background to evaluate screen reader accessibility with given component but I believe It should ask user confirmation before sending to a different page (most sites don't do that, they redirect once you select an option different than the current).
When we think in the context that Kimchi/Wok is not targeted for hardcore users that are used to AWS, Azure, VMWare vSphere panels, then it makes sense to use a simple tabbed navigation pattern like the proposed new-ui spec.
I do think that at some point we will be forced to deliver an alternate option if the user has several plugins installed. In one of the links that Walter sent we can see that NBC.com tried different patterns from hamburger icon and then switched back to a tabbed nav but they kept a "More" drop-down button: <a class="moz-txt-link-freetext" href="http://deep.design/wp-content/uploads/2015/07/Screen-Shot-2015-07-31-at-3.36.30-PM.png">http://deep.design/wp-content/uploads/2015/07/Screen-Shot-2015-07-31-at-3.36.30-PM.png</a>
For now I propose we use the proposed design in hosts-ginger.jpg that I attached for now, but I would definitely need some help with JS to make this work and that would envolve changing tab-ext.xml as well.
Samuel
-----Original Message-----
From: <a class="moz-txt-link-abbreviated" href="mailto:kimchi-devel-bounces@ovirt.org">kimchi-devel-bounces@ovirt.org</a> [<a class="moz-txt-link-freetext" href="mailto:kimchi-devel-bounces@ovirt.org">mailto:kimchi-devel-bounces@ovirt.org</a>] On Behalf Of Daniel Henrique Barboza
Sent: terça-feira, 13 de outubro de 2015 14:14
To: <a class="moz-txt-link-abbreviated" href="mailto:kimchi-devel@ovirt.org">kimchi-devel@ovirt.org</a>
Subject: Re: [Kimchi-devel] UI Change Request - Navigation
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:
</pre>
<blockquote type="cite">
<pre wrap="">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:
</pre>
<blockquote type="cite">
<pre wrap="">On Tue, 2015-10-13 at 17:17 +0200, Walter Niklaus wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">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).
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">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
</pre>
<blockquote type="cite">
<pre wrap="">Regards,
Walter.
On 13.10.2015 16:29, Aline Manera wrote:
</pre>
<blockquote type="cite">
<pre wrap=""> 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:
</pre>
<blockquote type="cite">
<pre wrap="">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: <a class="moz-txt-link-abbreviated" href="mailto:kimchi-devel-bounces@ovirt.org">kimchi-devel-bounces@ovirt.org</a> [mailto:
<a class="moz-txt-link-abbreviated" href="mailto:kimchi-devel-bounces@ovirt.org">kimchi-devel-bounces@ovirt.org</a>] On Behalf Of Jan Schneider
Sent: quinta-feira, 8 de outubro de 2015 13:10
To: Aline Manera <a class="moz-txt-link-rfc2396E" href="mailto:alinefm@linux.vnet.ibm.com"><alinefm@linux.vnet.ibm.com></a>
Cc: <a class="moz-txt-link-abbreviated" href="mailto:kimchi-devel@ovirt.org">kimchi-devel@ovirt.org</a>
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
</pre>
</blockquote>
<pre wrap="">
_______________________________________________
Kimchi-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Kimchi-devel@ovirt.org">Kimchi-devel@ovirt.org</a>
<a class="moz-txt-link-freetext" href="http://lists.ovirt.org/mailman/listinfo/kimchi-devel">http://lists.ovirt.org/mailman/listinfo/kimchi-devel</a>
</pre>
</blockquote>
<pre wrap="">_______________________________________________
Kimchi-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Kimchi-devel@ovirt.org">Kimchi-devel@ovirt.org</a>
<a class="moz-txt-link-freetext" href="http://lists.ovirt.org/mailman/listinfo/kimchi-devel">http://lists.ovirt.org/mailman/listinfo/kimchi-devel</a>
</pre>
</blockquote>
</blockquote>
<pre wrap="">
_______________________________________________
Kimchi-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Kimchi-devel@ovirt.org">Kimchi-devel@ovirt.org</a>
<a class="moz-txt-link-freetext" href="http://lists.ovirt.org/mailman/listinfo/kimchi-devel">http://lists.ovirt.org/mailman/listinfo/kimchi-devel</a>
</pre>
</blockquote>
<pre wrap="">
_______________________________________________
Kimchi-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Kimchi-devel@ovirt.org">Kimchi-devel@ovirt.org</a>
<a class="moz-txt-link-freetext" href="http://lists.ovirt.org/mailman/listinfo/kimchi-devel">http://lists.ovirt.org/mailman/listinfo/kimchi-devel</a>
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Kimchi-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Kimchi-devel@ovirt.org">Kimchi-devel@ovirt.org</a>
<a class="moz-txt-link-freetext" href="http://lists.ovirt.org/mailman/listinfo/kimchi-devel">http://lists.ovirt.org/mailman/listinfo/kimchi-devel</a>
</pre>
</blockquote>
<br>
</body>
</html>