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