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

From: "Einav Cohen" <ecohen(a)redhat.com&gt; To: "Daniel Erez" <derez(a)redhat.com&gt;, "Tomas Jelinek" <tjelinek(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; Cc: "engine-devel" <engine-devel(a)ovirt.org&gt;, "Itamar Heim" <iheim(a)redhat.com&gt; Sent: Friday, May 31, 2013 1:18:53 PM Subject: Re: [Engine-devel] static header only in VM dialog? > ----- Original Message ----- > From: "Daniel Erez" <derez(a)redhat.com&gt; > Sent: Friday, May 31, 2013 12:28:54 PM > > > ----- Original Message ----- > > From: "Einav Cohen" <ecohen(a)redhat.com&gt; > > To: "Michal Skrivanek" <michal.skrivanek(a)redhat.com&gt;, "Tomas Jelinek" > > <tjelinek(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;, "Daniel Erez" <derez(a)redhat.com&gt;, "Malini Rao" > > <mrao(a)redhat.com&gt;, "Itamar Heim" > > <iheim(a)redhat.com&gt; > > Sent: Friday, May 31, 2013 6:56:33 PM > > Subject: Re: [Engine-devel] static header only in VM dialog? > > > > > > ... > > > > > > > > [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. > > > > > > There was a discussion about postponing it, but not much further it > > > seems. > > > In any case It may not be necessarily wrong to have dialog reorg in 3.3 > > > without insttypes as it will at least get people to get used to it and > > > we > > > can gather feedback. It's not that it removes any functionality, on the > > > contrary, e.g. the type ahead feature even solves some of the bugs we > > > already have. > > > > indeed - it doesn't remove functionality, and I agree that it would be a > > good > > opportunity to get feedback about some things such as the type-ahead list > > box, > > however the top static header in particular with only the DC/Cluster + > > Quota > > in it may seem strange / annoying, as it would just seem like something > > that > > takes up "real estate" in the dialog in *all* side-tab without a real > > good > > reason. > > > > so there are pros and cons for introducing only the first patch batch to > > ovirt-3.3, > > I guess; Ideally, I would suggest to maybe re-organize the patches a bit > > differently, > > so that the top static header in particular wouldn't be part of this > > first > > patch batch, > > i.e., I would suggest introducing the top static header along with adding > > the > > Instance > > Types fields [which, to my understanding, is exactly what Daniel has > > originally suggested > > on the patch [1] in his gerrit comment(s) from May 28/29 (depends on the > > timezone) - > > only now I fully understand his concern (I think/hope)...]. > > Exactly, I prefer that the static header will be introduced along with the > new dialog > I.e. squashed with the final dialog patch (with instance types fields). > I understand that the static header might make sense for the final dialog - I am actually waiting for Tomas's response on what exactly is going to be included within the top static header of the dialog in his current 7-patches batch (see my previous response in the thread) - there is a chance that it makes some sense to introduce the top static section at this stage (instead of waiting for the "final dialog patch" in which the Instance Types and Image fields will be introduced), as it already affects a "nice" amount of side-tabs. - even if the fields that are included in the top static header in the current patch-batch don't really justify introducing the top static section at this stage, there are other things that (IMO) should be taken into consideration when deciding how to proceed [see my (1.a), (1.b), (2) "essay" in one of my previous responses in the thread] > (though I still don't like the idea that it's relevant only for some > side-tabs). I think that UX wise (and Malini/Eldan can comment on that), if the top section affect a significant amount of side-tabs, it is better that this section would be displayed in *all* side tabs, rather than have it visible only in the relevant side-tabs, which can be a bit irritating to the eye when "jumping" between side-tabs.

[of course, I assume that completely different, creative solutions can be found, but even if so - I suggest to think about them in a later stage, after introducing the Instance Types feature into the system / getting some more feedback on the current top static header solution] > Added my remarks to the patch: http://gerrit.ovirt.org/#/c/14635/ > > > > > not sure how easy it is to do though - I know that *a lot* of time and > > effort > > were > > already invested in these patches as they are now, and I wouldn't want > > that > > the reviewing/ > > merging process will be held off for much longer. > > > > To sum up: these are the options, as I see them: > > > > 1) keep the current patch batch as is and: > > > > a. merge it in time for ovirt-3.3, or: > > > > b. merge it post ovirt-3.3. > > > > - or - > > > > 2) go with what Daniel has suggested in his gerrit comment: reorganize > > the > > patches so that > > the top static header would be introduced only along with the instance > > types > > fields [that > > way, it won't matter what makes it into ovirt-3.3 - the first patch > > batch, > > or > > both (or none)]. > > > > I am in favor of (1.b) or (2). However, weighing the cons of (1.a) > > against > > the pros of (1.a) / > > cons of (1.b) or against the effort that (2) will require, and taking > > into > > consideration the > > effort that was already invested, I am not strongly against (1.a) as > > well. > > > > [1] http://gerrit.ovirt.org/#/c/14635/ > > > > > ... > > > > > _______________________________________________ > Engine-devel mailing list > Engine-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > > >