Re: [Engine-devel] custom properties sheet feature page

----- Original Message ----- From: "Gilad Chaplik" <gchaplik(a)redhat.com&gt; Sent: Friday, May 18, 2012 12:25:45 PM inline Thanks, Gilad. ----- Original Message ----- > From: "Einav Cohen" <ecohen(a)redhat.com&gt; > To: "David Jaša" <djasa(a)redhat.com&gt;, "Miki Kenneth" > <mkenneth(a)redhat.com&gt;, "Andrew Cathrow" <acathrow(a)redhat.com&gt;, > "Simon Grinberg" <sgrinber(a)redhat.com&gt;, "Eldan Hildesheim" > <ehildesh(a)redhat.com&gt;, "Eldan Hildesheim" > <info(a)eldanet.com&gt;, "Gilad Chaplik" <gchaplik(a)redhat.com&gt; > Cc: engine-devel(a)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(a)redhat.com&gt; > > 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(a)redhat.com&gt; > > > > 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(a)redhat.com&gt; > > > > > > 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(a)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(a)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(a)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(a)ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > >