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

18 May 2012


      ...
----- Original Message -----
From: "Gilad Chaplik" <gchaplik@redhat.com>
Sent: Friday, May 18, 2012 12:56:00 PM
----- Original Message -----
...
From: "David Jaša" <djasa@redhat.com>
To: "Gilad Chaplik" <gchaplik@redhat.com>
Cc: "Einav Cohen" <ecohen@redhat.com>, engine-devel@ovirt.org,
"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:51:43 PM
Subject: Re: [Engine-devel] custom properties sheet feature page
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).
+1 for disabling
-1 for clearing - it is not advised to clear a field if its fails on
validation.
...
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.
Don't forget to take this ^^^ also under consideration.
...
...
...
...
...
...
>
> > >
> > > 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
_______________________________________________
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel