[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