[Engine-devel] custom properties sheet feature page

Fri May 18 09:12:54 UTC 2012

> ----- Original Message -----
> From: "David Jaša" <djasa at 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 at 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 at 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]

> 
> > > 
> > > 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 at 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 at 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 at 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 at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> 
> 