From: "Malini Rao" <mrao@redhat.com> To: "Einav Cohen" <ecohen@redhat.com> Cc: "Daniel Erez" <derez@redhat.com>, "Eldan Hildesheim" <info@eldanet.com>, "engine-devel" <engine-devel@ovirt.org>, "Eldan Hildesheim" <ehildesh@redhat.com>, "Tomas Jelinek" <tjelinek@redhat.com> 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@redhat.com> To: "Daniel Erez" <derez@redhat.com> Cc: "Eldan Hildesheim" <info@eldanet.com>, "engine-devel" <engine-devel@ovirt.org>, "Eldan Hildesheim" <ehildesh@redhat.com>, "Malini Rao" <mrao@redhat.com>, "Tomas Jelinek" <tjelinek@redhat.com> 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@redhat.com> Sent: Wednesday, May 29, 2013 1:36:03 AM
----- Original Message -----
From: "Einav Cohen" <ecohen@redhat.com> To: "Daniel Erez" <derez@redhat.com>, "Malini Rao" <mrao@redhat.com>, "Eldan Hildesheim" <info@eldanet.com>, "Eldan Hildesheim" <ehildesh@redhat.com>, "Tomas Jelinek" <tjelinek@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org> Sent: Wednesday, May 29, 2013 2:30:09 AM Subject: Re: static header only in VM dialog?
----- Original Message ----- From: "Daniel Erez" <derez@redhat.com> Sent: Tuesday, May 28, 2013 6:18:20 PM
----- Original Message -----
From: "Einav Cohen" <ecohen@redhat.com> To: "Malini Rao" <mrao@redhat.com>, "Eldan Hildesheim" <info@eldanet.com>, "Eldan Hildesheim" <ehildesh@redhat.com> Cc: "Tomas Jelinek" <tjelinek@redhat.com>, derez@redhat.com, "engine-devel" <engine-devel@ovirt.org> 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
----- Original Message ----- 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.
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@redhat.com > To: "Tomas Jelinek" <tjelinek@redhat.com> > Cc: "Vojtech Szocs" <vszocs@redhat.com>, "Einav Cohen" > <ecohen@redhat.com>, > "Frank Kobzik" <fkobzik@redhat.com>, > "Eldan Hildesheim" <info@eldanet.com> > 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@redhat.com> > Gerrit-Reviewer: Daniel Erez <derez@redhat.com> > Gerrit-Reviewer: Einav Cohen <ecohen@redhat.com> > Gerrit-Reviewer: Eldan Hildesheim <info@eldanet.com> > Gerrit-Reviewer: Frank Kobzik <fkobzik@redhat.com> > Gerrit-Reviewer: Tomas Jelinek <tjelinek@redhat.com> > Gerrit-Reviewer: Vojtech Szocs <vszocs@redhat.com> >
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel