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). 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