----- Original Message -----

From: "Einav Cohen" <ecohen@redhat.com> To: "Andrew Cathrow" <acathrow@redhat.com> Cc: engine-devel@ovirt.org, "Gilad Chaplik" <gchaplik@redhat.com>, "Miki Kenneth" <mkenneth@redhat.com>, "Simon Grinberg" <sgrinber@redhat.com>, "Eldan Hildesheim" <ehildesh@redhat.com>, "Eldan Hildesheim" <info@eldanet.com> Sent: Thursday, May 17, 2012 9:08:10 AM Subject: Re: custom properties sheet feature page

...

----- Original Message ----- From: "Andrew Cathrow" <acathrow@redhat.com> Sent: Thursday, May 17, 2012 3:32:05 PM

----- Original Message -----

...

From: "Einav Cohen" <ecohen@redhat.com> To: "Gilad Chaplik" <gchaplik@redhat.com>, "Andrew Cathrow" <acathrow@redhat.com>, "Miki Kenneth" <mkenneth@redhat.com>, "Simon Grinberg" <sgrinber@redhat.com>, "Eldan Hildesheim" <ehildesh@redhat.com>, "Eldan Hildesheim" <info@eldanet.com> Cc: engine-devel@ovirt.org Sent: Thursday, May 17, 2012 8:10:50 AM Subject: custom properties sheet feature page

Hi,

Please review/comment on the Custom Properties Sheet feature page: http://www.ovirt.org/wiki/Features/CustomPropertiesSheet

It looks great. Are all the keys going to be exposed in the dropdown, or will we have private keys that the user has to know about?

All keys will be exposed; not sure what you mean by "private", but all keys are treated the same today.

if we're exposing all (which is preferable) then it's perfect.

If we want some kind of differentiation between the keys, it is a another feature... [I could, of course, be missing something, please clarify if I did]

...

...

---- Thanks, Einav

----- Original Message -----

From: "Itamar Heim" <iheim@redhat.com> To: "Einav Cohen" <ecohen@redhat.com> Cc: "Andrew Cathrow" <acathrow@redhat.com>, "Eldan Hildesheim" <info@eldanet.com>, engine-devel@ovirt.org, "Simon Grinberg" <sgrinber@redhat.com>, "Eldan Hildesheim" <ehildesh@redhat.com> Sent: Friday, May 18, 2012 1:50:17 AM Subject: Re: [Engine-devel] custom properties sheet feature page

On 05/17/2012 04:08 PM, Einav Cohen wrote: ...

...

...

...

Hi,

Please review/comment on the Custom Properties Sheet feature page: http://www.ovirt.org/wiki/Features/CustomPropertiesSheet

It looks great. Are all the keys going to be exposed in the dropdown, or will we have private keys that the user has to know about?

All keys will be exposed; not sure what you mean by "private", but all keys are treated the same today. If we want some kind of differentiation between the keys, it is a another feature... [I could, of course, be missing something, please clarify if I did]

in the future, we may want to give permissions to which users are allowed to use which custom properties. not relevant for now.

Is this cool looking design be also available from the user portal? If so how do you prevent any user that just have permission to Edit VMs to do damage? With custom property you can do almost anything. Consider the case where there is a hook that allows to directly attach a LUN/Add Tap/more destructive options. It is intended for use of the sys admins but any user can use. You would say correctly that this was always the case. But with the old textbox interface the user would need to know that the option exists. Now we actually tell him what he can use. Cool for the webadmin / kind'a dangerous from the user portal until you get permissions per users feature for it. The minimum that is needed is an option to disable this properties tab in the user portal. Better have MLA for using properties at all if per property can't be accommodated.

Einav Cohen píše v Čt 17. 05. 2012 v 09:30 -0400:

...

----- Original Message ----- From: "David Jaša" <djasa@redhat.com> Sent: Thursday, May 17, 2012 3:40:19 PM

Einav Cohen píše v Čt 17. 05. 2012 v 08:10 -0400:

...

Hi,

Please review/comment on the Custom Properties Sheet feature page: http://www.ovirt.org/wiki/Features/CustomPropertiesSheet

Just my $0.02:

The table could have always empty row at the bottom, eliminating one or all [+] buttons and saving user one needless click:

[ key1 |v] [ value ] [+] [-] [ key2 |v] [ value ] [+] [-] [ key3 |v] [ value ] [-] [ "please select a key..." |v]

The [+] buttons at first and second rows would allow user to insert a row at specified location to make easy custom sorting of the properties (not applicable if properties are auto-sorted, in that case, all [+] buttons can be actually removed).

Thanks for the input, David. This is an interesting idea.

Indeed, when choosing a key in the last row, we can automatically add a new "please select a key..." row, which actually saves the user a button-click for adding a new row.

On the other hand, from graphic-design point of view, it will look more consistent and "pretty" if: - The "please select a key..." row won't be displayed (unless, or course, the user explicitly chose to add another row) - All (full) rows will have both [+] and [-] buttons next to them

If the [+] button in my proposal is just greyed out instead of ommited, it could satisfy both requirements.

i.e., instead of your suggestion, which looks like this:

[ key1 |v] [ value ] [+] [-] [ key2 |v] [ value ] [+] [-] [ key3 |v] [ value ] [-] [ "please select a key..." |v]

it will be "prettier" like this:

[ key1 |v] [ value ] [+] [-] [ key2 |v] [ value ] [+] [-] [ key3 |v] [ value ] [+] [-]

and only if clicking on [+], it will be:

[ key1 |v] [ value ] [+] [-] [ key2 |v] [ value ] [+] [-] [ key3 |v] [ value ] [+] [-] [ "please select a key..." |v]

I believe that auto-sorting can be confusing, as it can result in rows "jumping" up and down whenever changing the selection(s) in the Key drop-down(s),

this could be sort of mitigated by sorting server-side upon modification.

therefore I don't think it is a good idea to implement it here.

OTOH if we're to be manual sorting friendly, we should allow rearranging of the rows by drag & drop or by some sort of move up/down buttons and the dialog would start to be cluttered. I don't really like either of these but auto-sort is slightly better IMO as it is kept consistent accross various VMs without user interaction. David

...

David

...

---- Thanks, Einav _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

--

David Jaša, RHCE

SPICE QE based in Brno GPG Key: 22C33E24 Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24

_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

-- David Jaša, RHCE SPICE QE based in Brno GPG Key: 22C33E24 Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24

Einav Cohen píše v Čt 17. 05. 2012 v 10:14 -0400:

...

----- Original Message ----- From: "David Jaša" <djasa@redhat.com> Sent: Thursday, May 17, 2012 4:44:10 PM

Einav Cohen píše v Čt 17. 05. 2012 v 09:30 -0400:

...

...

----- Original Message ----- From: "David Jaša" <djasa@redhat.com> Sent: Thursday, May 17, 2012 3:40:19 PM

Einav Cohen píše v Čt 17. 05. 2012 v 08:10 -0400:

...

Hi,

Please review/comment on the Custom Properties Sheet feature page: http://www.ovirt.org/wiki/Features/CustomPropertiesSheet

Just my $0.02:

The table could have always empty row at the bottom, eliminating one or all [+] buttons and saving user one needless click:

[ key1 |v] [ value ] [+] [-] [ key2 |v] [ value ] [+] [-] [ key3 |v] [ value ] [-] [ "please select a key..." |v]

The [+] buttons at first and second rows would allow user to insert a row at specified location to make easy custom sorting of the properties (not applicable if properties are auto-sorted, in that case, all [+] buttons can be actually removed).

Thanks for the input, David. This is an interesting idea.

Indeed, when choosing a key in the last row, we can automatically add a new "please select a key..." row, which actually saves the user a button-click for adding a new row.

On the other hand, from graphic-design point of view, it will look more consistent and "pretty" if: - The "please select a key..." row won't be displayed (unless, or course, the user explicitly chose to add another row) - All (full) rows will have both [+] and [-] buttons next to them

I should have probably elaborated more on this. To me, UI with less elements looks cleaner and prettier even when one of them stands out. There's also nothing wrong with standing out if the element has "special" meaning (one add vs bunch of modify). Specifically, this looks cleaner to my eyes: [ key1 |v] [ value ] [-] [ key2 |v] [ value ] [-] [ key3 |v] [ value ] [-] [ "Please select a key..." |v] than [ key1 |v] [ value ] [+] [-] [ key2 |v] [ value ] [+] [-] [ key3 |v] [ value ] [+] [-]

...

If the [+] button in my proposal is just greyed out instead of ommited, it could satisfy both requirements.

Almost; the "please select a key..." row is still always displayed; question is if we want to save a button-click (your suggestion) or to have a "cleaner" sheet (my suggestion).

...

...

i.e., instead of your suggestion, which looks like this:

[ key1 |v] [ value ] [+] [-] [ key2 |v] [ value ] [+] [-] [ key3 |v] [ value ] [-] [ "please select a key..." |v]

it will be "prettier" like this:

[ key1 |v] [ value ] [+] [-] [ key2 |v] [ value ] [+] [-] [ key3 |v] [ value ] [+] [-]

and only if clicking on [+], it will be:

[ key1 |v] [ value ] [+] [-] [ key2 |v] [ value ] [+] [-] [ key3 |v] [ value ] [+] [-] [ "please select a key..." |v]

I believe that auto-sorting can be confusing, as it can result in rows "jumping" up and down whenever changing the selection(s) in the Key drop-down(s),

this could be sort of mitigated by sorting server-side upon modification.

...

therefore I don't think it is a good idea to implement it here.

OTOH if we're to be manual sorting friendly, we should allow rearranging of the rows by drag & drop or by some sort of move up/down buttons and the dialog would start to be cluttered.

I don't really like either of these but auto-sort is slightly better IMO as it is kept consistent accross various VMs without user interaction.

Indeed, auto-sort will keep the order consistent across all VMs. However, maybe the user would like to see the properties in the order in which he filled them; in this case, your suggestion of "move up/down buttons" is probably relevant here.

I believe that the majority of use-cases won't require more than 2 or 3 custom properties per VM, so sorting won't be that critical, therefore I assume we can start without it; I will add "sorting" to the "open issues" section in the wiki page.

That seems as more argument in favor of auto sorting. David

...

David

...

...

David

...

---- Thanks, Einav _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

--

David Jaša, RHCE

SPICE QE based in Brno GPG Key: 22C33E24 Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24

_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

--

David Jaša, RHCE

SPICE QE based in Brno GPG Key: 22C33E24 Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24

_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

-- David Jaša, RHCE SPICE QE based in Brno GPG Key: 22C33E24 Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24

inline Thanks, Gilad. ----- Original Message -----

From: "Einav Cohen" <ecohen@redhat.com> To: "David Jaša" <djasa@redhat.com>, "Miki Kenneth" <mkenneth@redhat.com>, "Andrew Cathrow" <acathrow@redhat.com>, "Simon Grinberg" <sgrinber@redhat.com>, "Eldan Hildesheim" <ehildesh@redhat.com>, "Eldan Hildesheim" <info@eldanet.com>, "Gilad Chaplik" <gchaplik@redhat.com> Cc: engine-devel@ovirt.org Sent: Friday, May 18, 2012 12:12:54 PM Subject: Re: [Engine-devel] custom properties sheet feature page

...

----- Original Message ----- From: "David Jaša" <djasa@redhat.com> Sent: Friday, May 18, 2012 11:33:44 AM

Einav Cohen píše v Čt 17. 05. 2012 v 10:14 -0400:

...

...

----- Original Message ----- From: "David Jaša" <djasa@redhat.com> Sent: Thursday, May 17, 2012 4:44:10 PM

Einav Cohen píše v Čt 17. 05. 2012 v 09:30 -0400:

...

...

----- Original Message ----- From: "David Jaša" <djasa@redhat.com> Sent: Thursday, May 17, 2012 3:40:19 PM

Einav Cohen píše v Čt 17. 05. 2012 v 08:10 -0400: > Hi, > > Please review/comment on the Custom Properties Sheet > feature > page: > http://www.ovirt.org/wiki/Features/CustomPropertiesSheet >

Just my $0.02:

The table could have always empty row at the bottom, eliminating one or all [+] buttons and saving user one needless click:

[ key1 |v] [ value ] [+] [-] [ key2 |v] [ value ] [+] [-] [ key3 |v] [ value ] [-] [ "please select a key..." |v]

The [+] buttons at first and second rows would allow user to insert a row at specified location to make easy custom sorting of the properties (not applicable if properties are auto-sorted, in that case, all [+] buttons can be actually removed).

Thanks for the input, David. This is an interesting idea.

Indeed, when choosing a key in the last row, we can automatically add a new "please select a key..." row, which actually saves the user a button-click for adding a new row.

On the other hand, from graphic-design point of view, it will look more consistent and "pretty" if: - The "please select a key..." row won't be displayed (unless, or course, the user explicitly chose to add another row) - All (full) rows will have both [+] and [-] buttons next to them

I should have probably elaborated more on this. To me, UI with less elements looks cleaner and prettier even when one of them stands out. There's also nothing wrong with standing out if the element has "special" meaning (one add vs bunch of modify).

Specifically, this looks cleaner to my eyes:

[ key1 |v] [ value ] [-] [ key2 |v] [ value ] [-] [ key3 |v] [ value ] [-] [ "Please select a key..." |v]

than

[ key1 |v] [ value ] [+] [-] [ key2 |v] [ value ] [+] [-] [ key3 |v] [ value ] [+] [-]

Note that in your suggestion above, you cannot insert a new key in between existing keys - only at the end; so although "cleaner", it has less functionality (depends also on the sorting, which is another issue; if there is auto-sorting, it doesn't matter). It is also a matter of taste, I guess, so no absolute right or wrong here IMO. [Others - you are welcome to comment as well]

+1 another tiny comment: can the empty line contain all the fields from initial state [["please select a key..."][field(empty)][+][-]] instead of showing them only after selecting a key. [["please select a key..."]] both of these scenarios are liable, I can select a key, regret (change back to [please select a key]) and the field and buttons are still visible. so for the sake of complexity, I prefer to have only one.

...

...

...

If the [+] button in my proposal is just greyed out instead of ommited, it could satisfy both requirements.

Almost; the "please select a key..." row is still always displayed; question is if we want to save a button-click (your suggestion) or to have a "cleaner" sheet (my suggestion).

...

...

i.e., instead of your suggestion, which looks like this:

[ key1 |v] [ value ] [+] [-] [ key2 |v] [ value ] [+] [-] [ key3 |v] [ value ] [-] [ "please select a key..." |v]

it will be "prettier" like this:

[ key1 |v] [ value ] [+] [-] [ key2 |v] [ value ] [+] [-] [ key3 |v] [ value ] [+] [-]

and only if clicking on [+], it will be:

[ key1 |v] [ value ] [+] [-] [ key2 |v] [ value ] [+] [-] [ key3 |v] [ value ] [+] [-] [ "please select a key..." |v]

I believe that auto-sorting can be confusing, as it can result in rows "jumping" up and down whenever changing the selection(s) in the Key drop-down(s),

this could be sort of mitigated by sorting server-side upon modification.

...

therefore I don't think it is a good idea to implement it here.

OTOH if we're to be manual sorting friendly, we should allow rearranging of the rows by drag & drop or by some sort of move up/down buttons and the dialog would start to be cluttered.

I don't really like either of these but auto-sort is slightly better IMO as it is kept consistent accross various VMs without user interaction.

Indeed, auto-sort will keep the order consistent across all VMs. However, maybe the user would like to see the properties in the order in which he filled them; in this case, your suggestion of "move up/down buttons" is probably relevant here.

I believe that the majority of use-cases won't require more than 2 or 3 custom properties per VM, so sorting won't be that critical, therefore I assume we can start without it; I will add "sorting" to the "open issues" section in the wiki page.

That seems as more argument in favor of auto sorting.

Or no sorting at all (i.e. simply display in order of filling)... In any case, open issue has been added to the wiki.

...

David

...

...

David

...

...

David

> ---- > Thanks, > Einav > _______________________________________________ > Engine-devel mailing list > Engine-devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel

--

David Jaša, RHCE

SPICE QE based in Brno GPG Key: 22C33E24 Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24

_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

--

David Jaša, RHCE

SPICE QE based in Brno GPG Key: 22C33E24 Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24

_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

--

David Jaša, RHCE

SPICE QE based in Brno GPG Key: 22C33E24 Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24

_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

----- Original Message -----

From: "Einav Cohen" <ecohen@redhat.com> To: "Gilad Chaplik" <gchaplik@redhat.com> Cc: engine-devel@ovirt.org, "David Jaša" <djasa@redhat.com>, "Miki Kenneth" <mkenneth@redhat.com>, "Andrew Cathrow" <acathrow@redhat.com>, "Simon Grinberg" <sgrinber@redhat.com>, "Eldan Hildesheim" <ehildesh@redhat.com>, "Eldan Hildesheim" <info@eldanet.com> Sent: Friday, May 18, 2012 12:35:34 PM Subject: Re: [Engine-devel] custom properties sheet feature page

...

----- Original Message ----- From: "Gilad Chaplik" <gchaplik@redhat.com> Sent: Friday, May 18, 2012 12:25:45 PM

inline

Thanks, Gilad.

----- Original Message -----

...

From: "Einav Cohen" <ecohen@redhat.com> To: "David Jaša" <djasa@redhat.com>, "Miki Kenneth" <mkenneth@redhat.com>, "Andrew Cathrow" <acathrow@redhat.com>, "Simon Grinberg" <sgrinber@redhat.com>, "Eldan Hildesheim" <ehildesh@redhat.com>, "Eldan Hildesheim" <info@eldanet.com>, "Gilad Chaplik" <gchaplik@redhat.com> Cc: engine-devel@ovirt.org Sent: Friday, May 18, 2012 12:12:54 PM Subject: Re: [Engine-devel] custom properties sheet feature page

...

----- Original Message ----- From: "David Jaša" <djasa@redhat.com> Sent: Friday, May 18, 2012 11:33:44 AM

Einav Cohen píše v Čt 17. 05. 2012 v 10:14 -0400:

...

...

----- Original Message ----- From: "David Jaša" <djasa@redhat.com> Sent: Thursday, May 17, 2012 4:44:10 PM

Einav Cohen píše v Čt 17. 05. 2012 v 09:30 -0400: > > ----- Original Message ----- > > From: "David Jaša" <djasa@redhat.com> > > Sent: Thursday, May 17, 2012 3:40:19 PM > > > > Einav Cohen píše v Čt 17. 05. 2012 v 08:10 -0400: > > > Hi, > > > > > > Please review/comment on the Custom Properties Sheet > > > feature > > > page: > > > http://www.ovirt.org/wiki/Features/CustomPropertiesSheet > > > > > > > Just my $0.02: > > > > The table could have always empty row at the bottom, > > eliminating > > one > > or > > all [+] buttons and saving user one needless click: > > > > [ key1 |v] [ value ] [+] [-] > > [ key2 |v] [ value ] [+] [-] > > [ key3 |v] [ value ] [-] > > [ "please select a key..." |v] > > > > The [+] buttons at first and second rows would allow > > user > > to > > insert a > > row at specified location to make easy custom sorting > > of > > the > > properties > > (not applicable if properties are auto-sorted, in that > > case, > > all > > [+] > > buttons can be actually removed). > > Thanks for the input, David. This is an interesting idea. > > Indeed, when choosing a key in the last row, we can > automatically > add a new "please select a key..." row, which actually > saves > the > user a button-click for adding a new row. > > On the other hand, from graphic-design point of view, it > will > look > more consistent and "pretty" if: > - The "please select a key..." row won't be displayed > (unless, > or > course, the user explicitly chose to add another row) > - All (full) rows will have both [+] and [-] buttons next > to > them

I should have probably elaborated more on this. To me, UI with less elements looks cleaner and prettier even when one of them stands out. There's also nothing wrong with standing out if the element has "special" meaning (one add vs bunch of modify).

Specifically, this looks cleaner to my eyes:

[ key1 |v] [ value ] [-] [ key2 |v] [ value ] [-] [ key3 |v] [ value ] [-] [ "Please select a key..." |v]

than

[ key1 |v] [ value ] [+] [-] [ key2 |v] [ value ] [+] [-] [ key3 |v] [ value ] [+] [-]

Note that in your suggestion above, you cannot insert a new key in between existing keys - only at the end; so although "cleaner", it has less functionality (depends also on the sorting, which is another issue; if there is auto-sorting, it doesn't matter). It is also a matter of taste, I guess, so no absolute right or wrong here IMO. [Others - you are welcome to comment as well]

+1

another tiny comment: can the empty line contain all the fields from initial state [["please select a key..."][field(empty)][+][-]] instead of showing them only after selecting a key. [["please select a key..."]]

both of these scenarios are liable, I can select a key, regret (change back to [please select a key]) and the field and buttons are still visible.

so for the sake of complexity, I prefer to have only one.

* Note that the field input control type (text-box, drop-down) depends on the key anyway (more accurately, on the validation regular expression of the key), so what are you going to show in case of "please select a key..."?

empty text-box

* Need to make sure that validation fails in case field value is not empty and key is "please select a key...".

Due to both of these reasons, I prefer to not show an input control at all in this case.

still, I don't see any difference, except adding complexity/devel-time/bugs later on. plus I think it's nicer.

* No problem of having a "+" button there; however, need to make sure that in case there is only one row in the sheet and it is with "please select a key...", the "-" button should be either hidden or disabled (or non-responsive), since we can't remove the last row.

...

...

...

...

...

If the [+] button in my proposal is just greyed out instead of ommited, it could satisfy both requirements.

Almost; the "please select a key..." row is still always displayed; question is if we want to save a button-click (your suggestion) or to have a "cleaner" sheet (my suggestion).

...

> > i.e., instead of your suggestion, which looks like this: > > [ key1 |v] [ value ] [+] [-] > [ key2 |v] [ value ] [+] [-] > [ key3 |v] [ value ] [-] > [ "please select a key..." |v] > > it will be "prettier" like this: > > [ key1 |v] [ value ] [+] [-] > [ key2 |v] [ value ] [+] [-] > [ key3 |v] [ value ] [+] [-] > > and only if clicking on [+], it will be: > > [ key1 |v] [ value ] [+] [-] > [ key2 |v] [ value ] [+] [-] > [ key3 |v] [ value ] [+] [-] > [ "please select a key..." |v] > > I believe that auto-sorting can be confusing, as it can > result > in > rows "jumping" up and down whenever changing the > selection(s) > in > the Key drop-down(s),

this could be sort of mitigated by sorting server-side upon modification.

> therefore I don't think it is a good idea to implement > it > here.

OTOH if we're to be manual sorting friendly, we should allow rearranging of the rows by drag & drop or by some sort of move up/down buttons and the dialog would start to be cluttered.

I don't really like either of these but auto-sort is slightly better IMO as it is kept consistent accross various VMs without user interaction.

Indeed, auto-sort will keep the order consistent across all VMs. However, maybe the user would like to see the properties in the order in which he filled them; in this case, your suggestion of "move up/down buttons" is probably relevant here.

I believe that the majority of use-cases won't require more than 2 or 3 custom properties per VM, so sorting won't be that critical, therefore I assume we can start without it; I will add "sorting" to the "open issues" section in the wiki page.

That seems as more argument in favor of auto sorting.

Or no sorting at all (i.e. simply display in order of filling)... In any case, open issue has been added to the wiki.

...

David

...

...

David

> > > > > David > > > > > ---- > > > Thanks, > > > Einav > > > _______________________________________________ > > > Engine-devel mailing list > > > Engine-devel@ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > -- > > > > David Jaša, RHCE > > > > SPICE QE based in Brno > > GPG Key: 22C33E24 > > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 > > 22C3 > > 3E24 > > > > > > > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel@ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > >

--

David Jaša, RHCE

SPICE QE based in Brno GPG Key: 22C33E24 Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24

_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

--

David Jaša, RHCE

SPICE QE based in Brno GPG Key: 22C33E24 Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24

_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

----- Original Message -----

From: "David Jaša" <djasa@redhat.com> To: "Gilad Chaplik" <gchaplik@redhat.com> Cc: "Einav Cohen" <ecohen@redhat.com>, engine-devel@ovirt.org, "Miki Kenneth" <mkenneth@redhat.com>, "Andrew Cathrow" <acathrow@redhat.com>, "Simon Grinberg" <sgrinber@redhat.com>, "Eldan Hildesheim" <ehildesh@redhat.com>, "Eldan Hildesheim" <info@eldanet.com> Sent: Friday, May 18, 2012 12:51:43 PM Subject: Re: [Engine-devel] custom properties sheet feature page

Gilad Chaplik píše v Pá 18. 05. 2012 v 05:44 -0400:

...

----- Original Message -----

...

From: "Einav Cohen" <ecohen@redhat.com> To: "Gilad Chaplik" <gchaplik@redhat.com> Cc: engine-devel@ovirt.org, "David Jaša" <djasa@redhat.com>, "Miki Kenneth" <mkenneth@redhat.com>, "Andrew Cathrow" <acathrow@redhat.com>, "Simon Grinberg" <sgrinber@redhat.com>, "Eldan Hildesheim" <ehildesh@redhat.com>, "Eldan Hildesheim" <info@eldanet.com> Sent: Friday, May 18, 2012 12:35:34 PM Subject: Re: [Engine-devel] custom properties sheet feature page

...

----- Original Message ----- From: "Gilad Chaplik" <gchaplik@redhat.com> Sent: Friday, May 18, 2012 12:25:45 PM

inline

Thanks, Gilad.

----- Original Message -----

...

From: "Einav Cohen" <ecohen@redhat.com> To: "David Jaša" <djasa@redhat.com>, "Miki Kenneth" <mkenneth@redhat.com>, "Andrew Cathrow" <acathrow@redhat.com>, "Simon Grinberg" <sgrinber@redhat.com>, "Eldan Hildesheim" <ehildesh@redhat.com>, "Eldan Hildesheim" <info@eldanet.com>, "Gilad Chaplik" <gchaplik@redhat.com> Cc: engine-devel@ovirt.org Sent: Friday, May 18, 2012 12:12:54 PM Subject: Re: [Engine-devel] custom properties sheet feature page

...

----- Original Message ----- From: "David Jaša" <djasa@redhat.com> Sent: Friday, May 18, 2012 11:33:44 AM

Einav Cohen píše v Čt 17. 05. 2012 v 10:14 -0400: > > ----- Original Message ----- > > From: "David Jaša" <djasa@redhat.com> > > Sent: Thursday, May 17, 2012 4:44:10 PM > > > > Einav Cohen píše v Čt 17. 05. 2012 v 09:30 -0400: > > > > ----- Original Message ----- > > > > From: "David Jaša" <djasa@redhat.com> > > > > Sent: Thursday, May 17, 2012 3:40:19 PM > > > > > > > > Einav Cohen píše v Čt 17. 05. 2012 v 08:10 -0400: > > > > > Hi, > > > > > > > > > > Please review/comment on the Custom Properties > > > > > Sheet > > > > > feature > > > > > page: > > > > > http://www.ovirt.org/wiki/Features/CustomPropertiesSheet > > > > > > > > > > > > > Just my $0.02: > > > > > > > > The table could have always empty row at the > > > > bottom, > > > > eliminating > > > > one > > > > or > > > > all [+] buttons and saving user one needless click: > > > > > > > > [ key1 |v] [ value ] [+] [-] > > > > [ key2 |v] [ value ] [+] [-] > > > > [ key3 |v] [ value ] [-] > > > > [ "please select a key..." |v] > > > > > > > > The [+] buttons at first and second rows would > > > > allow > > > > user > > > > to > > > > insert a > > > > row at specified location to make easy custom > > > > sorting > > > > of > > > > the > > > > properties > > > > (not applicable if properties are auto-sorted, in > > > > that > > > > case, > > > > all > > > > [+] > > > > buttons can be actually removed). > > > > > > Thanks for the input, David. This is an interesting > > > idea. > > > > > > Indeed, when choosing a key in the last row, we can > > > automatically > > > add a new "please select a key..." row, which > > > actually > > > saves > > > the > > > user a button-click for adding a new row. > > > > > > On the other hand, from graphic-design point of view, > > > it > > > will > > > look > > > more consistent and "pretty" if: > > > - The "please select a key..." row won't be displayed > > > (unless, > > > or > > > course, the user explicitly chose to add another row) > > > - All (full) rows will have both [+] and [-] buttons > > > next > > > to > > > them

I should have probably elaborated more on this. To me, UI with less elements looks cleaner and prettier even when one of them stands out. There's also nothing wrong with standing out if the element has "special" meaning (one add vs bunch of modify).

Specifically, this looks cleaner to my eyes:

[ key1 |v] [ value ] [-] [ key2 |v] [ value ] [-] [ key3 |v] [ value ] [-] [ "Please select a key..." |v]

than

[ key1 |v] [ value ] [+] [-] [ key2 |v] [ value ] [+] [-] [ key3 |v] [ value ] [+] [-]

Note that in your suggestion above, you cannot insert a new key in between existing keys - only at the end; so although "cleaner", it has less functionality (depends also on the sorting, which is another issue; if there is auto-sorting, it doesn't matter). It is also a matter of taste, I guess, so no absolute right or wrong here IMO. [Others - you are welcome to comment as well]

+1

another tiny comment: can the empty line contain all the fields from initial state [["please select a key..."][field(empty)][+][-]] instead of showing them only after selecting a key. [["please select a key..."]]

both of these scenarios are liable, I can select a key, regret (change back to [please select a key]) and the field and buttons are still visible.

so for the sake of complexity, I prefer to have only one.

* Note that the field input control type (text-box, drop-down) depends on the key anyway (more accurately, on the validation regular expression of the key), so what are you going to show in case of "please select a key..."?

empty text-box

...

* Need to make sure that validation fails in case field value is not empty and key is "please select a key...".

I would prefer to just disable the value input field and do re-validation upon change of key (clear the value if it fails validation against a new key) or server-side when it is changed (clear the key-value pair altogether).

+1 for disabling -1 for clearing - it is not advised to clear a field if its fails on validation.

David

...

...

Due to both of these reasons, I prefer to not show an input control at all in this case.

still, I don't see any difference, except adding complexity/devel-time/bugs later on. plus I think it's nicer.

...

* No problem of having a "+" button there; however, need to make sure that in case there is only one row in the sheet and it is with "please select a key...", the "-" button should be either hidden or disabled (or non-responsive), since we can't remove the last row.

...

...

...

...

> > > > If the [+] button in my proposal is just greyed out > > instead > > of > > ommited, > > it could satisfy both requirements. > > Almost; the "please select a key..." row is still always > displayed; > question is if we want to save a button-click (your > suggestion) > or > to have a "cleaner" sheet (my suggestion). > > > > > > > > > i.e., instead of your suggestion, which looks like > > > this: > > > > > > [ key1 |v] [ value ] [+] [-] > > > [ key2 |v] [ value ] [+] [-] > > > [ key3 |v] [ value ] [-] > > > [ "please select a key..." |v] > > > > > > it will be "prettier" like this: > > > > > > [ key1 |v] [ value ] [+] [-] > > > [ key2 |v] [ value ] [+] [-] > > > [ key3 |v] [ value ] [+] [-] > > > > > > and only if clicking on [+], it will be: > > > > > > [ key1 |v] [ value ] [+] [-] > > > [ key2 |v] [ value ] [+] [-] > > > [ key3 |v] [ value ] [+] [-] > > > [ "please select a key..." |v] > > > > > > I believe that auto-sorting can be confusing, as it > > > can > > > result > > > in > > > rows "jumping" up and down whenever changing the > > > selection(s) > > > in > > > the Key drop-down(s), > > > > this could be sort of mitigated by sorting server-side > > upon > > modification. > > > > > therefore I don't think it is a good idea to > > > implement > > > it > > > here. > > > > OTOH if we're to be manual sorting friendly, we should > > allow > > rearranging > > of the rows by drag & drop or by some sort of move > > up/down > > buttons > > and > > the dialog would start to be cluttered. > > > > I don't really like either of these but auto-sort is > > slightly > > better > > IMO > > as it is kept consistent accross various VMs without > > user > > interaction. > > Indeed, auto-sort will keep the order consistent across > all > VMs. > However, maybe the user would like to see the properties > in > the > order in which he filled them; in this case, your > suggestion > of > "move up/down buttons" is probably relevant here. > > I believe that the majority of use-cases won't require > more > than > 2 > or 3 custom properties per VM, so sorting won't be that > critical, > therefore I assume we can start without it; I will add > "sorting" > to the "open issues" section in the wiki page. >

That seems as more argument in favor of auto sorting.

Or no sorting at all (i.e. simply display in order of filling)... In any case, open issue has been added to the wiki.

...

David

> > > > David > > > > > > > > > > > > > David > > > > > > > > > ---- > > > > > Thanks, > > > > > Einav > > > > > _______________________________________________ > > > > > Engine-devel mailing list > > > > > Engine-devel@ovirt.org > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > -- > > > > > > > > David Jaša, RHCE > > > > > > > > SPICE QE based in Brno > > > > GPG Key: 22C33E24 > > > > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 > > > > CD00 > > > > 22C3 > > > > 3E24 > > > > > > > > > > > > > > > > _______________________________________________ > > > > Engine-devel mailing list > > > > Engine-devel@ovirt.org > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > -- > > > > David Jaša, RHCE > > > > SPICE QE based in Brno > > GPG Key: 22C33E24 > > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 > > 22C3 > > 3E24 > > > > > > > > > _______________________________________________ > Engine-devel mailing list > Engine-devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel

--

David Jaša, RHCE

SPICE QE based in Brno GPG Key: 22C33E24 Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24

_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

--

David Jaša, RHCE

SPICE QE based in Brno GPG Key: 22C33E24 Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24

----- Original Message -----

From: "Einav Cohen" <ecohen@redhat.com> To: "Gilad Chaplik" <gchaplik@redhat.com> Cc: "Eldan Hildesheim" <info@eldanet.com>, engine-devel@ovirt.org, "Simon Grinberg" <sgrinber@redhat.com>, "Eldan Hildesheim" <ehildesh@redhat.com>, "David Jaša" <djasa@redhat.com> Sent: Friday, May 18, 2012 1:02:03 PM Subject: Re: [Engine-devel] custom properties sheet feature page

...

----- Original Message ----- From: "Gilad Chaplik" <gchaplik@redhat.com> Sent: Friday, May 18, 2012 12:56:00 PM

----- Original Message -----

...

From: "David Jaša" <djasa@redhat.com> To: "Gilad Chaplik" <gchaplik@redhat.com> Cc: "Einav Cohen" <ecohen@redhat.com>, engine-devel@ovirt.org, "Miki Kenneth" <mkenneth@redhat.com>, "Andrew Cathrow" <acathrow@redhat.com>, "Simon Grinberg" <sgrinber@redhat.com>, "Eldan Hildesheim" <ehildesh@redhat.com>, "Eldan Hildesheim" <info@eldanet.com> Sent: Friday, May 18, 2012 12:51:43 PM Subject: Re: [Engine-devel] custom properties sheet feature page

Gilad Chaplik píše v Pá 18. 05. 2012 v 05:44 -0400:

...

----- Original Message -----

...

From: "Einav Cohen" <ecohen@redhat.com> To: "Gilad Chaplik" <gchaplik@redhat.com> Cc: engine-devel@ovirt.org, "David Jaša" <djasa@redhat.com>, "Miki Kenneth" <mkenneth@redhat.com>, "Andrew Cathrow" <acathrow@redhat.com>, "Simon Grinberg" <sgrinber@redhat.com>, "Eldan Hildesheim" <ehildesh@redhat.com>, "Eldan Hildesheim" <info@eldanet.com> Sent: Friday, May 18, 2012 12:35:34 PM Subject: Re: [Engine-devel] custom properties sheet feature page

...

----- Original Message ----- From: "Gilad Chaplik" <gchaplik@redhat.com> Sent: Friday, May 18, 2012 12:25:45 PM

inline

Thanks, Gilad.

----- Original Message ----- > From: "Einav Cohen" <ecohen@redhat.com> > To: "David Jaša" <djasa@redhat.com>, "Miki Kenneth" > <mkenneth@redhat.com>, "Andrew Cathrow" > <acathrow@redhat.com>, > "Simon Grinberg" <sgrinber@redhat.com>, "Eldan > Hildesheim" > <ehildesh@redhat.com>, "Eldan Hildesheim" > <info@eldanet.com>, "Gilad Chaplik" <gchaplik@redhat.com> > Cc: engine-devel@ovirt.org > Sent: Friday, May 18, 2012 12:12:54 PM > Subject: Re: [Engine-devel] custom properties sheet > feature > page > > > ----- Original Message ----- > > From: "David Jaša" <djasa@redhat.com> > > Sent: Friday, May 18, 2012 11:33:44 AM > > > > Einav Cohen píše v Čt 17. 05. 2012 v 10:14 -0400: > > > > ----- Original Message ----- > > > > From: "David Jaša" <djasa@redhat.com> > > > > Sent: Thursday, May 17, 2012 4:44:10 PM > > > > > > > > Einav Cohen píše v Čt 17. 05. 2012 v 09:30 -0400: > > > > > > ----- Original Message ----- > > > > > > From: "David Jaša" <djasa@redhat.com> > > > > > > Sent: Thursday, May 17, 2012 3:40:19 PM > > > > > > > > > > > > Einav Cohen píše v Čt 17. 05. 2012 v 08:10 > > > > > > -0400: > > > > > > > Hi, > > > > > > > > > > > > > > Please review/comment on the Custom > > > > > > > Properties > > > > > > > Sheet > > > > > > > feature > > > > > > > page: > > > > > > > http://www.ovirt.org/wiki/Features/CustomPropertiesSheet > > > > > > > > > > > > > > > > > > > Just my $0.02: > > > > > > > > > > > > The table could have always empty row at the > > > > > > bottom, > > > > > > eliminating > > > > > > one > > > > > > or > > > > > > all [+] buttons and saving user one needless > > > > > > click: > > > > > > > > > > > > [ key1 |v] [ value ] [+] > > > > > > [-] > > > > > > [ key2 |v] [ value ] [+] > > > > > > [-] > > > > > > [ key3 |v] [ value ] > > > > > > [-] > > > > > > [ "please select a key..." |v] > > > > > > > > > > > > The [+] buttons at first and second rows would > > > > > > allow > > > > > > user > > > > > > to > > > > > > insert a > > > > > > row at specified location to make easy custom > > > > > > sorting > > > > > > of > > > > > > the > > > > > > properties > > > > > > (not applicable if properties are auto-sorted, > > > > > > in > > > > > > that > > > > > > case, > > > > > > all > > > > > > [+] > > > > > > buttons can be actually removed). > > > > > > > > > > Thanks for the input, David. This is an > > > > > interesting > > > > > idea. > > > > > > > > > > Indeed, when choosing a key in the last row, we > > > > > can > > > > > automatically > > > > > add a new "please select a key..." row, which > > > > > actually > > > > > saves > > > > > the > > > > > user a button-click for adding a new row. > > > > > > > > > > On the other hand, from graphic-design point of > > > > > view, > > > > > it > > > > > will > > > > > look > > > > > more consistent and "pretty" if: > > > > > - The "please select a key..." row won't be > > > > > displayed > > > > > (unless, > > > > > or > > > > > course, the user explicitly chose to add another > > > > > row) > > > > > - All (full) rows will have both [+] and [-] > > > > > buttons > > > > > next > > > > > to > > > > > them > > > > I should have probably elaborated more on this. To me, > > UI > > with > > less > > elements looks cleaner and prettier even when one of > > them > > stands > > out. > > There's also nothing wrong with standing out if the > > element > > has > > "special" meaning (one add vs bunch of modify). > > > > Specifically, this looks cleaner to my eyes: > > > > [ key1 |v] [ value ] [-] > > [ key2 |v] [ value ] [-] > > [ key3 |v] [ value ] [-] > > [ "Please select a key..." |v] > > > > than > > > > [ key1 |v] [ value ] [+] [-] > > [ key2 |v] [ value ] [+] [-] > > [ key3 |v] [ value ] [+] [-] > > > > > > Note that in your suggestion above, you cannot insert a > new > key > in > between existing keys - only at the end; so > although "cleaner", it has less functionality (depends > also > on > the > sorting, which is another issue; if there is > auto-sorting, > it > doesn't matter). > It is also a matter of taste, I guess, so no absolute > right > or > wrong > here IMO. > [Others - you are welcome to comment as well]

+1

another tiny comment: can the empty line contain all the fields from initial state [["please select a key..."][field(empty)][+][-]] instead of showing them only after selecting a key. [["please select a key..."]]

both of these scenarios are liable, I can select a key, regret (change back to [please select a key]) and the field and buttons are still visible.

so for the sake of complexity, I prefer to have only one.

* Note that the field input control type (text-box, drop-down) depends on the key anyway (more accurately, on the validation regular expression of the key), so what are you going to show in case of "please select a key..."?

empty text-box

...

* Need to make sure that validation fails in case field value is not empty and key is "please select a key...".

I would prefer to just disable the value input field and do re-validation upon change of key (clear the value if it fails validation against a new key) or server-side when it is changed (clear the key-value pair altogether).

+1 for disabling -1 for clearing - it is not advised to clear a field if its fails on validation.

...

David

...

...

Due to both of these reasons, I prefer to not show an input control at all in this case.

still, I don't see any difference, except adding complexity/devel-time/bugs later on. plus I think it's nicer.

...

* No problem of having a "+" button there; however, need to make sure that in case there is only one row in the sheet and it is with "please select a key...", the "-" button should be either hidden or disabled (or non-responsive), since we can't remove the last row.

Don't forget to take this ^^^ also under consideration.

silence means agreement :)

...

...

...

...

...

> > > > > > > > > > > If the [+] button in my proposal is just greyed out > > > > instead > > > > of > > > > ommited, > > > > it could satisfy both requirements. > > > > > > Almost; the "please select a key..." row is still > > > always > > > displayed; > > > question is if we want to save a button-click (your > > > suggestion) > > > or > > > to have a "cleaner" sheet (my suggestion). > > > > > > > > > > > > > > > > > i.e., instead of your suggestion, which looks > > > > > like > > > > > this: > > > > > > > > > > [ key1 |v] [ value ] [+] [-] > > > > > [ key2 |v] [ value ] [+] [-] > > > > > [ key3 |v] [ value ] [-] > > > > > [ "please select a key..." |v] > > > > > > > > > > it will be "prettier" like this: > > > > > > > > > > [ key1 |v] [ value ] [+] [-] > > > > > [ key2 |v] [ value ] [+] [-] > > > > > [ key3 |v] [ value ] [+] [-] > > > > > > > > > > and only if clicking on [+], it will be: > > > > > > > > > > [ key1 |v] [ value ] [+] [-] > > > > > [ key2 |v] [ value ] [+] [-] > > > > > [ key3 |v] [ value ] [+] [-] > > > > > [ "please select a key..." |v] > > > > > > > > > > I believe that auto-sorting can be confusing, as > > > > > it > > > > > can > > > > > result > > > > > in > > > > > rows "jumping" up and down whenever changing the > > > > > selection(s) > > > > > in > > > > > the Key drop-down(s), > > > > > > > > this could be sort of mitigated by sorting > > > > server-side > > > > upon > > > > modification. > > > > > > > > > therefore I don't think it is a good idea to > > > > > implement > > > > > it > > > > > here. > > > > > > > > OTOH if we're to be manual sorting friendly, we > > > > should > > > > allow > > > > rearranging > > > > of the rows by drag & drop or by some sort of move > > > > up/down > > > > buttons > > > > and > > > > the dialog would start to be cluttered. > > > > > > > > I don't really like either of these but auto-sort > > > > is > > > > slightly > > > > better > > > > IMO > > > > as it is kept consistent accross various VMs > > > > without > > > > user > > > > interaction. > > > > > > Indeed, auto-sort will keep the order consistent > > > across > > > all > > > VMs. > > > However, maybe the user would like to see the > > > properties > > > in > > > the > > > order in which he filled them; in this case, your > > > suggestion > > > of > > > "move up/down buttons" is probably relevant here. > > > > > > I believe that the majority of use-cases won't > > > require > > > more > > > than > > > 2 > > > or 3 custom properties per VM, so sorting won't be > > > that > > > critical, > > > therefore I assume we can start without it; I will > > > add > > > "sorting" > > > to the "open issues" section in the wiki page. > > > > > > > That seems as more argument in favor of auto sorting. > > Or no sorting at all (i.e. simply display in order of > filling)... > In any case, open issue has been added to the wiki. > > > > > David > > > > > > > > > > David > > > > > > > > > > > > > > > > > > > > > David > > > > > > > > > > > > > ---- > > > > > > > Thanks, > > > > > > > Einav > > > > > > > _______________________________________________ > > > > > > > Engine-devel mailing list > > > > > > > Engine-devel@ovirt.org > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > -- > > > > > > > > > > > > David Jaša, RHCE > > > > > > > > > > > > SPICE QE based in Brno > > > > > > GPG Key: 22C33E24 > > > > > > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 > > > > > > CD00 > > > > > > 22C3 > > > > > > 3E24 > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Engine-devel mailing list > > > > > > Engine-devel@ovirt.org > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > David Jaša, RHCE > > > > > > > > SPICE QE based in Brno > > > > GPG Key: 22C33E24 > > > > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 > > > > CD00 > > > > 22C3 > > > > 3E24 > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Engine-devel mailing list > > > Engine-devel@ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > -- > > > > David Jaša, RHCE > > > > SPICE QE based in Brno > > GPG Key: 22C33E24 > > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 > > 22C3 > > 3E24 > > > > > > > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel@ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > >

--

David Jaša, RHCE

SPICE QE based in Brno GPG Key: 22C33E24 Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24

_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

[top posting] Mock-ups have been updated according to this thread. You can check it in the feature page: http://www.ovirt.org/wiki/Features/CustomPropertiesSheet If you have any further comments, please share. ---- Thanks, Einav ----- Original Message -----

From: "Gilad Chaplik" <gchaplik@redhat.com> To: "David Jaša" <djasa@redhat.com> Cc: "Einav Cohen" <ecohen@redhat.com>, "Eldan Hildesheim" <info@eldanet.com>, engine-devel@ovirt.org, "Eldan Hildesheim" <ehildesh@redhat.com>, "Simon Grinberg" <sgrinber@redhat.com> Sent: Sunday, May 20, 2012 3:50:15 PM Subject: Re: [Engine-devel] custom properties sheet feature page

----- Original Message -----

...

From: "Gilad Chaplik" <gchaplik@redhat.com> To: "Einav Cohen" <ecohen@redhat.com> Cc: "David Jaša" <djasa@redhat.com>, "Eldan Hildesheim" <info@eldanet.com>, engine-devel@ovirt.org, "Eldan Hildesheim" <ehildesh@redhat.com>, "Simon Grinberg" <sgrinber@redhat.com> Sent: Friday, May 18, 2012 1:15:16 PM Subject: Re: [Engine-devel] custom properties sheet feature page

----- Original Message -----

...

From: "Einav Cohen" <ecohen@redhat.com> To: "Gilad Chaplik" <gchaplik@redhat.com> Cc: "Eldan Hildesheim" <info@eldanet.com>, engine-devel@ovirt.org, "Simon Grinberg" <sgrinber@redhat.com>, "Eldan Hildesheim" <ehildesh@redhat.com>, "David Jaša" <djasa@redhat.com> Sent: Friday, May 18, 2012 1:02:03 PM Subject: Re: [Engine-devel] custom properties sheet feature page

...

----- Original Message ----- From: "Gilad Chaplik" <gchaplik@redhat.com> Sent: Friday, May 18, 2012 12:56:00 PM

----- Original Message -----

...

From: "David Jaša" <djasa@redhat.com> To: "Gilad Chaplik" <gchaplik@redhat.com> Cc: "Einav Cohen" <ecohen@redhat.com>, engine-devel@ovirt.org, "Miki Kenneth" <mkenneth@redhat.com>, "Andrew Cathrow" <acathrow@redhat.com>, "Simon Grinberg" <sgrinber@redhat.com>, "Eldan Hildesheim" <ehildesh@redhat.com>, "Eldan Hildesheim" <info@eldanet.com> Sent: Friday, May 18, 2012 12:51:43 PM Subject: Re: [Engine-devel] custom properties sheet feature page

Gilad Chaplik píše v Pá 18. 05. 2012 v 05:44 -0400:

...

----- Original Message ----- > From: "Einav Cohen" <ecohen@redhat.com> > To: "Gilad Chaplik" <gchaplik@redhat.com> > Cc: engine-devel@ovirt.org, "David Jaša" > <djasa@redhat.com>, > "Miki Kenneth" <mkenneth@redhat.com>, "Andrew Cathrow" > <acathrow@redhat.com>, "Simon Grinberg" > <sgrinber@redhat.com>, > "Eldan Hildesheim" <ehildesh@redhat.com>, "Eldan > Hildesheim" <info@eldanet.com> > Sent: Friday, May 18, 2012 12:35:34 PM > Subject: Re: [Engine-devel] custom properties sheet > feature > page > > > ----- Original Message ----- > > From: "Gilad Chaplik" <gchaplik@redhat.com> > > Sent: Friday, May 18, 2012 12:25:45 PM > > > > inline > > > > Thanks, > > Gilad. > > > > ----- Original Message ----- > > > From: "Einav Cohen" <ecohen@redhat.com> > > > To: "David Jaša" <djasa@redhat.com>, "Miki Kenneth" > > > <mkenneth@redhat.com>, "Andrew Cathrow" > > > <acathrow@redhat.com>, > > > "Simon Grinberg" <sgrinber@redhat.com>, "Eldan > > > Hildesheim" > > > <ehildesh@redhat.com>, "Eldan Hildesheim" > > > <info@eldanet.com>, "Gilad Chaplik" > > > <gchaplik@redhat.com> > > > Cc: engine-devel@ovirt.org > > > Sent: Friday, May 18, 2012 12:12:54 PM > > > Subject: Re: [Engine-devel] custom properties sheet > > > feature > > > page > > > > > > > ----- Original Message ----- > > > > From: "David Jaša" <djasa@redhat.com> > > > > Sent: Friday, May 18, 2012 11:33:44 AM > > > > > > > > Einav Cohen píše v Čt 17. 05. 2012 v 10:14 -0400: > > > > > > ----- Original Message ----- > > > > > > From: "David Jaša" <djasa@redhat.com> > > > > > > Sent: Thursday, May 17, 2012 4:44:10 PM > > > > > > > > > > > > Einav Cohen píše v Čt 17. 05. 2012 v 09:30 > > > > > > -0400: > > > > > > > > ----- Original Message ----- > > > > > > > > From: "David Jaša" <djasa@redhat.com> > > > > > > > > Sent: Thursday, May 17, 2012 3:40:19 PM > > > > > > > > > > > > > > > > Einav Cohen píše v Čt 17. 05. 2012 v 08:10 > > > > > > > > -0400: > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > Please review/comment on the Custom > > > > > > > > > Properties > > > > > > > > > Sheet > > > > > > > > > feature > > > > > > > > > page: > > > > > > > > > http://www.ovirt.org/wiki/Features/CustomPropertiesSheet > > > > > > > > > > > > > > > > > > > > > > > > > Just my $0.02: > > > > > > > > > > > > > > > > The table could have always empty row at > > > > > > > > the > > > > > > > > bottom, > > > > > > > > eliminating > > > > > > > > one > > > > > > > > or > > > > > > > > all [+] buttons and saving user one > > > > > > > > needless > > > > > > > > click: > > > > > > > > > > > > > > > > [ key1 |v] [ value ] > > > > > > > > [+] > > > > > > > > [-] > > > > > > > > [ key2 |v] [ value ] > > > > > > > > [+] > > > > > > > > [-] > > > > > > > > [ key3 |v] [ value ] > > > > > > > > [-] > > > > > > > > [ "please select a key..." |v] > > > > > > > > > > > > > > > > The [+] buttons at first and second rows > > > > > > > > would > > > > > > > > allow > > > > > > > > user > > > > > > > > to > > > > > > > > insert a > > > > > > > > row at specified location to make easy > > > > > > > > custom > > > > > > > > sorting > > > > > > > > of > > > > > > > > the > > > > > > > > properties > > > > > > > > (not applicable if properties are > > > > > > > > auto-sorted, > > > > > > > > in > > > > > > > > that > > > > > > > > case, > > > > > > > > all > > > > > > > > [+] > > > > > > > > buttons can be actually removed). > > > > > > > > > > > > > > Thanks for the input, David. This is an > > > > > > > interesting > > > > > > > idea. > > > > > > > > > > > > > > Indeed, when choosing a key in the last row, > > > > > > > we > > > > > > > can > > > > > > > automatically > > > > > > > add a new "please select a key..." row, which > > > > > > > actually > > > > > > > saves > > > > > > > the > > > > > > > user a button-click for adding a new row. > > > > > > > > > > > > > > On the other hand, from graphic-design point > > > > > > > of > > > > > > > view, > > > > > > > it > > > > > > > will > > > > > > > look > > > > > > > more consistent and "pretty" if: > > > > > > > - The "please select a key..." row won't be > > > > > > > displayed > > > > > > > (unless, > > > > > > > or > > > > > > > course, the user explicitly chose to add > > > > > > > another > > > > > > > row) > > > > > > > - All (full) rows will have both [+] and [-] > > > > > > > buttons > > > > > > > next > > > > > > > to > > > > > > > them > > > > > > > > I should have probably elaborated more on this. To > > > > me, > > > > UI > > > > with > > > > less > > > > elements looks cleaner and prettier even when one > > > > of > > > > them > > > > stands > > > > out. > > > > There's also nothing wrong with standing out if the > > > > element > > > > has > > > > "special" meaning (one add vs bunch of modify). > > > > > > > > Specifically, this looks cleaner to my eyes: > > > > > > > > [ key1 |v] [ value ] [-] > > > > [ key2 |v] [ value ] [-] > > > > [ key3 |v] [ value ] [-] > > > > [ "Please select a key..." |v] > > > > > > > > than > > > > > > > > [ key1 |v] [ value ] [+] [-] > > > > [ key2 |v] [ value ] [+] [-] > > > > [ key3 |v] [ value ] [+] [-] > > > > > > > > > > > > > > Note that in your suggestion above, you cannot insert > > > a > > > new > > > key > > > in > > > between existing keys - only at the end; so > > > although "cleaner", it has less functionality > > > (depends > > > also > > > on > > > the > > > sorting, which is another issue; if there is > > > auto-sorting, > > > it > > > doesn't matter). > > > It is also a matter of taste, I guess, so no absolute > > > right > > > or > > > wrong > > > here IMO. > > > [Others - you are welcome to comment as well] > > > > +1 > > > > another tiny comment: > > can the empty line contain all the fields from initial > > state > > [["please select a key..."][field(empty)][+][-]] > > instead of showing them only after selecting a key. > > [["please select a key..."]] > > > > both of these scenarios are liable, > > I can select a key, regret (change back to [please > > select > > a > > key]) > > and > > the field and buttons are still visible. > > > > so for the sake of complexity, I prefer to have only > > one. > > * Note that the field input control type (text-box, > drop-down) > depends on the key anyway (more accurately, on the > validation > regular expression of the key), so what are you going to > show > in > case of "please select a key..."?

empty text-box

> > * Need to make sure that validation fails in case field > value > is > not > empty and key is "please select a key...". >

I would prefer to just disable the value input field and do re-validation upon change of key (clear the value if it fails validation against a new key) or server-side when it is changed (clear the key-value pair altogether).

+1 for disabling -1 for clearing - it is not advised to clear a field if its fails on validation.

Actually while implementing it, having a disabled field makes the user think why it's disabled, it is a bit confusing + less minimal :) I suggest to leave it as Einav's initial proposal.

...

...

...

...

David

...

> Due to both of these reasons, I prefer to not show an > input > control > at all in this case.

still, I don't see any difference, except adding complexity/devel-time/bugs later on. plus I think it's nicer.

> > * No problem of having a "+" button there; however, need > to > make > sure > that in case there is only one row in the sheet and it is > with > "please select a key...", the "-" button should be either > hidden > or > disabled (or non-responsive), since we can't remove the > last > row.

Don't forget to take this ^^^ also under consideration.

silence means agreement :)

...

...

...

...

> > > > > > > > > > > > > > > > > > > > > > > > If the [+] button in my proposal is just greyed > > > > > > out > > > > > > instead > > > > > > of > > > > > > ommited, > > > > > > it could satisfy both requirements. > > > > > > > > > > Almost; the "please select a key..." row is still > > > > > always > > > > > displayed; > > > > > question is if we want to save a button-click > > > > > (your > > > > > suggestion) > > > > > or > > > > > to have a "cleaner" sheet (my suggestion). > > > > > > > > > > > > > > > > > > > > > > > > > i.e., instead of your suggestion, which looks > > > > > > > like > > > > > > > this: > > > > > > > > > > > > > > [ key1 |v] [ value ] [+] > > > > > > > [-] > > > > > > > [ key2 |v] [ value ] [+] > > > > > > > [-] > > > > > > > [ key3 |v] [ value ] > > > > > > > [-] > > > > > > > [ "please select a key..." |v] > > > > > > > > > > > > > > it will be "prettier" like this: > > > > > > > > > > > > > > [ key1 |v] [ value ] [+] > > > > > > > [-] > > > > > > > [ key2 |v] [ value ] [+] > > > > > > > [-] > > > > > > > [ key3 |v] [ value ] [+] > > > > > > > [-] > > > > > > > > > > > > > > and only if clicking on [+], it will be: > > > > > > > > > > > > > > [ key1 |v] [ value ] [+] > > > > > > > [-] > > > > > > > [ key2 |v] [ value ] [+] > > > > > > > [-] > > > > > > > [ key3 |v] [ value ] [+] > > > > > > > [-] > > > > > > > [ "please select a key..." |v] > > > > > > > > > > > > > > I believe that auto-sorting can be confusing, > > > > > > > as > > > > > > > it > > > > > > > can > > > > > > > result > > > > > > > in > > > > > > > rows "jumping" up and down whenever changing > > > > > > > the > > > > > > > selection(s) > > > > > > > in > > > > > > > the Key drop-down(s), > > > > > > > > > > > > this could be sort of mitigated by sorting > > > > > > server-side > > > > > > upon > > > > > > modification. > > > > > > > > > > > > > therefore I don't think it is a good idea to > > > > > > > implement > > > > > > > it > > > > > > > here. > > > > > > > > > > > > OTOH if we're to be manual sorting friendly, we > > > > > > should > > > > > > allow > > > > > > rearranging > > > > > > of the rows by drag & drop or by some sort of > > > > > > move > > > > > > up/down > > > > > > buttons > > > > > > and > > > > > > the dialog would start to be cluttered. > > > > > > > > > > > > I don't really like either of these but > > > > > > auto-sort > > > > > > is > > > > > > slightly > > > > > > better > > > > > > IMO > > > > > > as it is kept consistent accross various VMs > > > > > > without > > > > > > user > > > > > > interaction. > > > > > > > > > > Indeed, auto-sort will keep the order consistent > > > > > across > > > > > all > > > > > VMs. > > > > > However, maybe the user would like to see the > > > > > properties > > > > > in > > > > > the > > > > > order in which he filled them; in this case, your > > > > > suggestion > > > > > of > > > > > "move up/down buttons" is probably relevant here. > > > > > > > > > > I believe that the majority of use-cases won't > > > > > require > > > > > more > > > > > than > > > > > 2 > > > > > or 3 custom properties per VM, so sorting won't > > > > > be > > > > > that > > > > > critical, > > > > > therefore I assume we can start without it; I > > > > > will > > > > > add > > > > > "sorting" > > > > > to the "open issues" section in the wiki page. > > > > > > > > > > > > > That seems as more argument in favor of auto > > > > sorting. > > > > > > Or no sorting at all (i.e. simply display in order of > > > filling)... > > > In any case, open issue has been added to the wiki. > > > > > > > > > > > David > > > > > > > > > > > > > > > > David > > > > > > > > > > > > > > > > > > > > > > > > > > > > > David > > > > > > > > > > > > > > > > > ---- > > > > > > > > > Thanks, > > > > > > > > > Einav > > > > > > > > > _______________________________________________ > > > > > > > > > Engine-devel mailing list > > > > > > > > > Engine-devel@ovirt.org > > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > David Jaša, RHCE > > > > > > > > > > > > > > > > SPICE QE based in Brno > > > > > > > > GPG Key: 22C33E24 > > > > > > > > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 > > > > > > > > B125 > > > > > > > > CD00 > > > > > > > > 22C3 > > > > > > > > 3E24 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Engine-devel mailing list > > > > > > > > Engine-devel@ovirt.org > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > David Jaša, RHCE > > > > > > > > > > > > SPICE QE based in Brno > > > > > > GPG Key: 22C33E24 > > > > > > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 > > > > > > CD00 > > > > > > 22C3 > > > > > > 3E24 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Engine-devel mailing list > > > > > Engine-devel@ovirt.org > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > -- > > > > > > > > David Jaša, RHCE > > > > > > > > SPICE QE based in Brno > > > > GPG Key: 22C33E24 > > > > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 > > > > CD00 > > > > 22C3 > > > > 3E24 > > > > > > > > > > > > > > > > _______________________________________________ > > > > Engine-devel mailing list > > > > Engine-devel@ovirt.org > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > >

--

David Jaša, RHCE

SPICE QE based in Brno GPG Key: 22C33E24 Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24

_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel