Re: [Engine-devel] static header only in VM dialog?

From: "Malini Rao" <mrao(a)redhat.com&gt; To: "Einav Cohen" <ecohen(a)redhat.com&gt; Cc: "Daniel Erez" <derez(a)redhat.com&gt;, "Eldan Hildesheim" <info(a)eldanet.com&gt;, "engine-devel" <engine-devel(a)ovirt.org&gt;, "Eldan Hildesheim" <ehildesh(a)redhat.com&gt;, "Tomas Jelinek" <tjelinek(a)redhat.com&gt; Sent: Thursday, May 30, 2013 5:56:59 PM Subject: Re: [Engine-devel] static header only in VM dialog? Sorry to join the thread late. The long weekend was followed by a conference for the UX team and hence the delay. See comments below inline - ----- Original Message ----- > From: "Einav Cohen" <ecohen(a)redhat.com&gt; > To: "Daniel Erez" <derez(a)redhat.com&gt; > Cc: "Eldan Hildesheim" <info(a)eldanet.com&gt;, "engine-devel" > <engine-devel(a)ovirt.org&gt;, "Eldan Hildesheim" > <ehildesh(a)redhat.com&gt;, "Malini Rao" <mrao(a)redhat.com&gt;, "Tomas Jelinek" > <tjelinek(a)redhat.com&gt; > Sent: Wednesday, May 29, 2013 8:21:30 AM > Subject: Re: [Engine-devel] static header only in VM dialog? > > > ----- Original Message ----- > > From: "Daniel Erez" <derez(a)redhat.com&gt; > > Sent: Wednesday, May 29, 2013 1:36:03 AM > > > > > > > > ----- Original Message ----- > > > From: "Einav Cohen" <ecohen(a)redhat.com&gt; > > > To: "Daniel Erez" <derez(a)redhat.com&gt;, "Malini Rao" <mrao(a)redhat.com&gt;, > > > "Eldan Hildesheim" <info(a)eldanet.com&gt;, "Eldan > > > Hildesheim" <ehildesh(a)redhat.com&gt;, "Tomas Jelinek" > > > <tjelinek(a)redhat.com&gt; > > > Cc: "engine-devel" <engine-devel(a)ovirt.org&gt; > > > Sent: Wednesday, May 29, 2013 2:30:09 AM > > > Subject: Re: static header only in VM dialog? > > > > > > > ----- Original Message ----- > > > > From: "Daniel Erez" <derez(a)redhat.com&gt; > > > > Sent: Tuesday, May 28, 2013 6:18:20 PM > > > > > > > > > > > > ----- Original Message ----- > > > > > From: "Einav Cohen" <ecohen(a)redhat.com&gt; > > > > > To: "Malini Rao" <mrao(a)redhat.com&gt;, "Eldan Hildesheim" > > > > > <info(a)eldanet.com&gt;, > > > > > "Eldan Hildesheim" <ehildesh(a)redhat.com&gt; > > > > > Cc: "Tomas Jelinek" <tjelinek(a)redhat.com&gt;, derez(a)redhat.com, > > > > > "engine-devel" > > > > > <engine-devel(a)ovirt.org&gt; > > > > > Sent: Wednesday, May 29, 2013 12:53:47 AM > > > > > Subject: static header only in VM dialog? > > > > > > > > > > when reviewing the code for the "redesign of vm related dialogs", > > > > > Daniel > > > > > has > > > > > raised an interesting question: Why do we want the static header > > > > > only > > > > > in > > > > > VM > > > > > dialog? > > > > > > > > > > (I assume that he refers to the top section of the New VM dialog as > > > > > seen > > > > > in > > > > > [1], which > > > > > contains the DC/Cluster, Quota, etc information, and is "static", > > > > > i.e., > > > > > it > > > > > is > > > > > always > > > > > displayed, regardless of the selected side-tab within the dialog) > > > > > > > > > > I agree with what Daniel is implying here: for consistency, we > > > > > would > > > > > probably > > > > > want to > > > > > introduce this static header to other dialogs, at least to the ones > > > > > that > > > > > also > > > > > contain > > > > > side-tabs in which it makes sense to turn the "header" to static > > > > > [e.g. > > > > > "New Host" (which contains a DC + Cluster "header") - see > > > > > http://oi39.tinypic.com/2z84xnp.jpg, > > > > > "New Cluster" (which contains a DC "header") - see > > > > > http://oi40.tinypic.com/2vmyj2x.jpg] MR: Consistency is important but we need to make only UIs with similar purposes consistent and not aim for consistency where it will not serve a real Usability goal or worse get in the way. See next comment for more on UX motivation for this static panel for new VM creation where it was originally proposed. > > > > > > > > > > [I assume, of course, that all the VM-like dialogs (e.g. New/Edit > > > > > VM-Pool) > > > > > will also have > > > > > static headers - I don't know if the patch already takes care of > > > > > that > > > > > or > > > > > not] > > > > > > > > > > Thoughts? > > > > > > > > > > [@Daniel - if you had something else in mind, and/or other dialogs > > > > > in > > > > > mind > > > > > - > > > > > please feel free > > > > > to add/amend/etc] MR: Before we proliferate this UI paradigm into other areas, let us look at the list of dialogs where we are considering this against the primary UX motivations with which this static panel was originally suggested. UX can help with this exercise on where it makes sense to have the static panel. > > > > > > > > Besides consistency matters, I wanted to understand what's the > > > > motivation > > > > of > > > > keeping these widgets static. I.e. is it an essential preparation for > > > > the > > > > new > > > > instance type dialog or a new concept for tab based dialogs > > > > (as DC/Cluster values aren't necessarily relevant for each tab in the > > > > dialog) > > > > > > [maybe Tomas/Eldan/Malini can help here as well] MR: Here are the original motivations for this static panel. 1. Context for dependencies - In the create VM dialog and the introduction of instance types and images, we came up with two core needs for the UI - There were some fields that were context-setting for other fields with dependencies. So, changing these context setting field values would alter the choices in other fields on one of the sub-tabs or eliminate or populate fields in these tabs. We wanted to ground the user with the context so that they can observe any changes that happen on a tab and determine what caused that change in the static panel. 2. Basic and mandatory - In the create VM dialog and the introduction of instance types and images, we also had to represent different levels of definition needed. For e.g, there were some basic and mandatory fields that were minimally needed for the definition of a VM irrespective of whether the user was basic or advanced. These fields were included in the static panel or at the most in the very first sub tab if they were not a context setting field for any other dependent field. This way the user does not have to go anywhere else to do a basic definition of the VM. Then we had another layer of permissioning where the fields you had access to on various tabs depended on whether you were a basic or advanced user. But note, we did have scenarios where some advanced fields made it to the static panel because they were a context setter. So to summarize the motivation of why the static panel and what should go into the static panel - You need a static panel ONLY if you have certain fields (basic or advanced) that act as context setters for all or some of the other fields in the other sub-tabs. Static panels can further optionally be extended to present all the fields that are needed for basic definition of an object. If there is no dependency and there is a dialog with multiple sub-tabs, then we SHOULD NOT just create a static panel for the basic definition fields. These fields should populate the first sub tab. Let me know if any further clarifications are needed. > > > > > > these static widgets (as well as the type ahead list box [1], for > > > example) > > > are part of > > > the instance types feature that had its design details published in [2] > > > and > > > [3], and the > > > implementation was done according to this design. I don't see any > > > reason > > > to > > > not utilize > > > this newly-introduced concept in other side-tab-based dialogs as well, > > > if > > > it > > > makes sense > > > (ui consistency considerations are sufficient, IMO, but I could be > > > wrong > > > - > > > maybe it is > > > relevant/correct to introduce this new concept only in the VM-like > > > dialogs). MR: The UX motivations for the static panel are generalizable even though they were designed for the New VM dialog. See above comment. But we need to gauge the reqs on each of the dialogs with subtabs against the core motivation and see if we need the static panel on it or not. > > > > > > regarding the specific concern about the DC/Cluster values that aren't > > > necessarily relevant > > > for each side-tab in the dialog: I agree with that statement, MR: If any field recommended in the UX proposal is not useful as a context setter, then please let us know and we can move it to the first sub-tab. however: > > > > > > - putting the "Instance Type" drop-down at the top static section is > > > very > > > useful (see [4] > > > for explanation), and as the Instance Types list is derived from the > > > selected > > > DC, it makes > > > sense (to me) to put the DC in that top static section as well. MR: Agree. That is probably why we ended up leaving the DC there. > > > > > > - the DC/Cluster are relevant for some of the tabs in the dialog (Host, > > > Resource Allocation?) > > > > Only for Host. > > Resource Allocation is directly affected by the selected template. > > Therefore, it sounds very confusing to me... > > Unless we add template to the static header as well? MR: I think we incorporated the templates into the Image field and denoted it with an icon preceding the drop down choice. So, the template is in the static panel.

> > The answer is yes, in a sense: Instance Types + Images are actually > somewhat "replacing" Templates [the general approach is to move to > basing VMs on Instance Types + Images, rather than on Templates; > it allows more flexibility in combining hardware configuration + image > configuration for the VM, without (necessarily) editing each VM field > separately]. > > So as I stated in my previous response: Having the "Instance Types" > field (and "Image" field) in the top static section is very useful, as > they affect the fields in most / a lot of the side-tabs. > > Based on the above: > > Do you agree that it makes sense to have a top static section in general > [even only for the "Instance Types" field and "Image" field (again, as > they affect most / a lot of side-tabs fields)]? > If so: Do you think that it makes sense to include the DC field in that > top static section as well (at least due to the fact that the "Instance > Types" list and "Images" list are derived from the selected DC)? MR: Yes makes sense to include DC in static panel because some of the other fields in the static panel are dependent on it. > > [Tomas/Malini/Eldan - if there is additional/different reasoning for > putting > the DC/Cluster field on the top static section - please share] > > > (which will be odd for the other tabs). > > > > So I still don't get the motivation UX-wise. > > E.g. it seems really weird to change the entire DC from Console tab > > (or, as a matter of fact, from most other tabs). MR: Not sure I understand. You can change DC when you are on ANY sub tab because the DC is a field in the static panel. The static panel is not the sub-tab. > > In the new instance type dialog, which tabs could be directly affected by > > DC/Cluster? > > IIUC, only Host? Do we really need a static header just for this tab? MR: Ideally, if we have only one sub-tab that has some dependencies with some basic fields, we should try to design the first sub-tab to have all those fields and eliminate the static panel. But if it is weird to have those additional fields on the very first sub-tab from a workflow perspective, then we should have the static panel even if the dependency is only on one sub-tab. The rule we are going by then is that it doesn't hurt to have context info on the top but it hurts more to not have that context info when needed. > > > > > so for consistency-within-the-dialog considerations, it is probably a > > > good > > > idea to simply > > > always show these fields within this top static section. > > > > > > [there is a good chance that I am missing your point here - please > > > correct > > > me > > > if necessary] > > > > > > [1] http://gerrit.ovirt.org/#/c/14936/ > > > > > > [2] http://www.ovirt.org/Features/Instance_Types > > > > > > [3] http://www.ovirt.org/images/9/9e/Instance_type.pdf > > > > > > [4] whenever changing the "Instance Type" value, you can automatically > > > see > > > how these changes > > > affect the fields in the current tab on which you are standing (e.g. if > > > you > > > are standing on > > > the "System" side-tab, you can change the "Instance Type" selected item > > > and > > > immediately see > > > the changes within the "System" side-tab contents), and vice-versa: if > > > you > > > are changing a value > > > that was originally propagated from the instance-type, you will see the > > > instance-type automatically > > > change to "custom"/"not applicable" as a result, so no need to "jump" > > > between > > > side-tabs in order > > > to observe these changes. > > > > > > > > > > > > > > > > > ---- > > > > > Thanks, > > > > > Einav > > > > > > > > > > [1] http://www.ovirt.org/images/9/9e/Instance_type.pdf > > > > > > > > > > ----- Original Message ----- > > > > > > From: derez(a)redhat.com > > > > > > To: "Tomas Jelinek" <tjelinek(a)redhat.com&gt; > > > > > > Cc: "Vojtech Szocs" <vszocs(a)redhat.com&gt;, "Einav Cohen" > > > > > > <ecohen(a)redhat.com&gt;, > > > > > > "Frank Kobzik" <fkobzik(a)redhat.com&gt;, > > > > > > "Eldan Hildesheim" <info(a)eldanet.com&gt; > > > > > > Sent: Tuesday, May 28, 2013 5:05:38 PM > > > > > > Subject: Change in ovirt-engine[master]: userportal,webadmin: > > > > > > redesign > > > > > > of > > > > > > vm related dialogs > > > > > > > > > > > > Daniel Erez has posted comments on this change. > > > > > > > > > > > > Change subject: userportal,webadmin: redesign of vm related > > > > > > dialogs > > > > > > ...................................................................... > > > > > > > > > > > > > > > > > > Patch Set 5: (1 inline comment) > > > > > > > > > > > > Code looks good. > > > > > > A few questions regarding the design: > > > > > > 1. Why do we want the static header only in VM dialog? > > > > > > 2. DC/Host are really relevant for all tabs? > > > > > > 3. Is it just a preparation for the final instance type dialog? > > > > > > 4. If it's indeed merely preparation, shouldn't it be merged only > > > > > > once > > > > > > we > > > > > > have the full picture of the new dialog? > > > > > > > > > > > > .................................................... > > > > > > File > > > > > > frontend/webadmin/modules/gwt-common/src/main/java/org/ovirt/engine/ui/common/widget/dialog/tab/DialogTabPanel.ui.xml > > > > > > Line 21: > > > > > > Line 22: .header { > > > > > > Line 23: background-color: #D3D3D3; > > > > > > Line 24: border-bottom: 1px solid #CED8DF; > > > > > > Line 25: margin-bottom: 15px; > > > > > > is it supposed to be that large? > > > > > > Line 26: padding-top: 6px; > > > > > > Line 27: margin-top: 4px; > > > > > > Line 28: margin-right: 3px; > > > > > > Line 29: display: none; > > > > > > > > > > > > > > > > > > -- > > > > > > To view, visit http://gerrit.ovirt.org/14635 > > > > > > To unsubscribe, visit http://gerrit.ovirt.org/settings > > > > > > > > > > > > Gerrit-MessageType: comment > > > > > > Gerrit-Change-Id: Icad8098e286f821da25fac22fd0a840a42f105c9 > > > > > > Gerrit-PatchSet: 5 > > > > > > Gerrit-Project: ovirt-engine > > > > > > Gerrit-Branch: master > > > > > > Gerrit-Owner: Tomas Jelinek <tjelinek(a)redhat.com&gt; > > > > > > Gerrit-Reviewer: Daniel Erez <derez(a)redhat.com&gt; > > > > > > Gerrit-Reviewer: Einav Cohen <ecohen(a)redhat.com&gt; > > > > > > Gerrit-Reviewer: Eldan Hildesheim <info(a)eldanet.com&gt; > > > > > > Gerrit-Reviewer: Frank Kobzik <fkobzik(a)redhat.com&gt; > > > > > > Gerrit-Reviewer: Tomas Jelinek <tjelinek(a)redhat.com&gt; > > > > > > Gerrit-Reviewer: Vojtech Szocs <vszocs(a)redhat.com&gt; > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel(a)ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > >