5:35 a.m.
----- Original Message -----
From: "Gilad Chaplik" <gchaplik(a)redhat.com>
Sent: Friday, May 18, 2012 12:25:45 PM
inline
Thanks,
Gilad.
----- Original Message -----
> From: "Einav Cohen" <ecohen(a)redhat.com>
> To: "David Jaša" <djasa(a)redhat.com>, "Miki Kenneth"
> <mkenneth(a)redhat.com>, "Andrew Cathrow"
<acathrow(a)redhat.com>,
> "Simon Grinberg" <sgrinber(a)redhat.com>, "Eldan
Hildesheim"
> <ehildesh(a)redhat.com>, "Eldan Hildesheim"
> <info(a)eldanet.com>, "Gilad Chaplik" <gchaplik(a)redhat.com>
> Cc: engine-devel(a)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(a)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(a)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(a)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..."?
* Need to make sure that validation fails in case field value is not empty and key is
"please select a key...".
Due to both of these reasons, I prefer to not show an input control at all in this case.
* 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(a)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(a)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(a)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(a)ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
> >
> >
>