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

Eldan Hildesheim ehildesh at redhat.com
Sun Jun 2 08:47:45 UTC 2013 

Eldan:

I prepared 2 mockups to explain the differences between the grey docked panel and the grey non-docked panel. (The data inside is not accurate)
I added the colour values for who ever is going to implement the dialogue.

dialogue_not_docked.png:
This mockup is like we have today:
Since it's INSIDE of the general left tab, it has a CONSTANT padding around it. (bg color should be #e5e5e5, the padding is important)

dialogue_docked.png:
Contrary to the previous mockup, here the grey panel is docked - no padding, this is to emphasise that the panel is STATIC.
To emphasise it graphically the bg color is the same as before only this time it has a darker border (#d3d3d3)  
This is also more easy to implement:
The  difference between both of the panel is once the padding border is white and once its dark grey.

Eldan 

----- Original Message -----
From: "Malini Rao" <mrao at redhat.com>
To: "Einav Cohen" <ecohen at redhat.com>
Cc: "Daniel Erez" <derez at redhat.com>, "Tomas Jelinek" <tjelinek at redhat.com>, "Eldan Hildesheim" <info at eldanet.com>, "Eldan Hildesheim" <ehildesh at redhat.com>, "engine-devel" <engine-devel at ovirt.org>, "Itamar Heim" <iheim at redhat.com>
Sent: Friday, May 31, 2013 8:28:42 PM
Subject: Re: [Engine-devel] static header only in VM dialog?





----- Original Message -----
> From: "Einav Cohen" <ecohen at redhat.com>
> To: "Daniel Erez" <derez at redhat.com>, "Tomas Jelinek" <tjelinek at redhat.com>, "Malini Rao" <mrao at redhat.com>, "Eldan
> Hildesheim" <info at eldanet.com>, "Eldan Hildesheim" <ehildesh at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>, "Itamar Heim" <iheim at redhat.com>
> 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 at redhat.com>
> > Sent: Friday, May 31, 2013 12:28:54 PM
> > 
> > 
> > ----- Original Message -----
> > > From: "Einav Cohen" <ecohen at redhat.com>
> > > To: "Michal Skrivanek" <michal.skrivanek at redhat.com>, "Tomas Jelinek"
> > > <tjelinek at redhat.com>
> > > Cc: "Eldan Hildesheim" <info at eldanet.com>, "engine-devel"
> > > <engine-devel at ovirt.org>, "Eldan Hildesheim"
> > > <ehildesh at redhat.com>, "Daniel Erez" <derez at redhat.com>, "Malini Rao"
> > > <mrao at redhat.com>, "Itamar Heim"
> > > <iheim at redhat.com>
> > > 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.


MR - Yes, if we have a static top panel, it should be truly static- i.e, it should stay displayed irrespective of whether the currently selected side tab has a dependency or context info on the static panel or not.  


> 
> [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 at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> > 
> > 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dialogue_docked.png
Type: image/png
Size: 63344 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130602/4b0f583d/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dialogue_not_docked.png
Type: image/png
Size: 41100 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130602/4b0f583d/attachment-0001.png>

More information about the Engine-devel mailing list