Re: [Engine-devel] static header only in VM dialog?
----- Original Message -----
From: "Einav Cohen" <ecohen(a)redhat.com>
To: "Tomas Jelinek" <tjelinek(a)redhat.com>, "Daniel Erez"
<derez(a)redhat.com>
Cc: "Itamar Heim" <iheim(a)redhat.com>, "Michal Skrivanek"
<michal.skrivanek(a)redhat.com>, "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>
Sent: Monday, June 3, 2013 8:26:45 AM
Subject: Re: [Engine-devel] static header only in VM dialog?
> > ...
> >
> > @Tomas - I suggest that you will clarify:
> >
> > A) which fields exactly are going to be included in the top static header
> > of
> > the New VM
> > dialog *in your current patch batch* [2], and:
>
> - Data Center
> - Cluster
> - Quota
> - Template (because according to the mockup the Image field will contain
> both
> Template and Image, so until we have images, just templates are there)
> - Vm Type (e.g. if server or desktop)
> - OS type
> (well, basically according to mockup, just without the instance type)
>
> >
> > B) which side-tabs in the New VM dialog will be affected by the fields in
> > (A).
>
> More or less all with some exceptions - especially thanx to the template
> field. And this will not change at all after introducing instance
> types/templates because template = instance type + image.
So it seems that it would make sense to introduce the top static header even
before introducing the Instance Types + Image fields, as it already contains
fields (namely 'Template') that affect most of the side-tabs.
Thanks, Tomas, for the clarification.
> So the question is not really if we want to
> wait until the instance types and images will affect enough side tabs
> (because that
> will not change at all) but if we want to have a top header panel or not. I
> personally start to think that it is more or less a question of taste.
> One may argue that it makes the dialogs more understandable (by having
> context all the time) and other that it makes them more un-understandable
> by
> flood of information in context you don't need.
> I guess either way has some advantages and disadvantages and there is no
> strict good/wrong solution.
+1
One way to limit this flooding of information in unnecessary contexts is to not apply a
blind rule that the static panel will appear for all dialogs with sub tabs. As outlined in
a previous email, the static panel should be used only if there is a dependency and it is
impossible to show the interdependent fields on the same page. The other important thing
we should do is very carefully consider what fields populate the static panel. The idea is
that this panel is minimal and should definitely not becoming like a page in itself.
-Malini
> ...