----- Original Message -----
> From: "Einav Cohen" <eco...@redhat.com>
> To: "Tomas Jelinek" <tjeli...@redhat.com>, "Daniel Erez" <de...@redhat.com>
> Cc: "Itamar Heim" <ih...@redhat.com>, "Michal Skrivanek"
> <michal.skriva...@redhat.com>, "Eldan Hildesheim"
> <i...@eldanet.com>, "engine-devel" <engine-devel@ovirt.org>, "Eldan
> Hildesheim" <ehild...@redhat.com>, "Malini Rao"
> <m...@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
>
> > ...
>
_______________________________________________
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
