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