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

> ----- Original Message ----- > From: "Tomas Jelinek" <tjelinek(a)redhat.com&gt; > Sent: Friday, May 31, 2013 2:22:57 AM > > > > ----- Original Message ----- >> 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. > > Just a small note: the first patch we are talking about > (http://gerrit.ovirt.org/#/c/14635) > adds only Data Center, Cluster and Quota to the header. > There is a second patch (http://gerrit.ovirt.org/#/c/15011/) which moves the > OS type and > template to the header. > The Image and Instance Type fields are not implemented yet. The current > patches just redesigns > the current UX according to the mockups - the new entities will be integrated > after we will have > an agreement and this batch of patches will be merged. OK, that explains a lot... :) many thanks, Tomas, for the clarification. I understand now Daniels's concern; it indeed doesn't make much sense for the DC/Cluster and Quota fields to be the only fields in the top static section. However, as this is a preparation for the Instance Types fields patches, it makes sense that we will first do the preparation work (i.e. change/reorganize the existing dialog layout), and then incorporate the Instance Types fields into it (given that it is being done *shortly* afterwards), or simply do everything altogether. @Tomas - ideally, the code that actually adds the Instance Types fields should have been part of this patch chain (either in more patches, or in "larger" patches), as again - I agree with Daniel that it makes no sense to having a static header in the VM dialogs with only DC/Cluster and Quota in them [1]. However, there is a chance that it would have been resulted in very large patches / a very long series of patches, which would have been even harder to review/rebase/etc. how long will it take for you to have the patches that actually add the Instance Types fields ready (once the first batch is merged)? as long as it will be done shortly afterwards, then your approach seems ok (again - my main concern is [1]). [1] my main concern is that this batch of patches (dialog reorg) will make it into ovirt 3.3, but the second batch (which will contain the actual Instance Types fields) won't make it in time [see the ovirt 3.3 schedule in: http://www.ovirt.org/OVirt_3.3_release-management - ovirt 3.3 feature freeze is today (?!)]; so I wouldn't want to see ovirt 3.3 being released with only the first patch batch merged into it. either both batches should be there, or both batches should not be there.

>> >> >>> >>> 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 >>>> >>>> >>>> >>> >> >