[Engine-devel] custom properties sheet feature page
David Jaša
djasa at redhat.com
Fri May 18 08:33:44 UTC 2012
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 ] [+] [-]
> >
> > 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.
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
More information about the Devel
mailing list