Colors of fields
80 views
Skip to first unread message
Cédric Krier
Jul 4, 2015, 3:00:03 AM7/4/15
to tryton
Hi,
For now, we put a blue color on entries when they are required (and
switch to red when validated as empty).
I think it is a bad practice for 2 reasons:
- the colors are not custumizable and so they could not work on some
thèmes.
- it is doesn't help the accessibility [1] as this information is
only based on color.
So I was thinking instead about adding a "*" on the labels of the
required fields. This still stay quite visual (but not too much) and
readable for accessibility.
What do you think? Has anyone a better idea?
[1]
https://developer.gnome.org/accessibility-devel-guide/3.8/idp5133984.html.en
--
Cédric Krier - B2CK SPRL
Email/Jabber: cedric...@b2ck.com
Tel: +32 472 54 46 59
Website: http://www.b2ck.com/
For now, we put a blue color on entries when they are required (and
switch to red when validated as empty).
I think it is a bad practice for 2 reasons:
- the colors are not custumizable and so they could not work on some
thèmes.
- it is doesn't help the accessibility [1] as this information is
only based on color.
So I was thinking instead about adding a "*" on the labels of the
required fields. This still stay quite visual (but not too much) and
readable for accessibility.
What do you think? Has anyone a better idea?
[1]
https://developer.gnome.org/accessibility-devel-guide/3.8/idp5133984.html.en
--
Cédric Krier - B2CK SPRL
Email/Jabber: cedric...@b2ck.com
Tel: +32 472 54 46 59
Website: http://www.b2ck.com/
Jordi Esteve
Jul 4, 2015, 4:49:58 AM7/4/15
to tryto...@googlegroups.com
On 04/07/15 08:58, Cédric Krier wrote:
> Hi,
>
> For now, we put a blue color on entries when they are required (and
> switch to red when validated as empty).
> I think it is a bad practice for 2 reasons:
>
> - the colors are not custumizable and so they could not work on some
> thèmes.
>
> - it is doesn't help the accessibility [1] as this information is
> only based on color.
>
> So I was thinking instead about adding a "*" on the labels of the
> required fields. This still stay quite visual (but not too much) and
> readable for accessibility.
>
> What do you think? Has anyone a better idea?
>
I suggest to not remove the current behaviour. The blue color and
> Hi,
>
> For now, we put a blue color on entries when they are required (and
> switch to red when validated as empty).
> I think it is a bad practice for 2 reasons:
>
> - the colors are not custumizable and so they could not work on some
> thèmes.
>
> - it is doesn't help the accessibility [1] as this information is
> only based on color.
>
> So I was thinking instead about adding a "*" on the labels of the
> required fields. This still stay quite visual (but not too much) and
> readable for accessibility.
>
> What do you think? Has anyone a better idea?
>
switching to red if the field is not filled is intuitive and clear for
most people, the asterisk is not intuitive (needs a previous
explanation), so I suggest adding a "*" without removing current behaviour.
--
Jordi Esteve
Consultor Zikzakmedia SL
jes...@zikzakmedia.com
Mòbil 679 170 693
Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108
Cédric Krier
Jul 4, 2015, 5:40:03 AM7/4/15
to tryto...@googlegroups.com
On 2015-07-04 10:49, Jordi Esteve wrote:
> On 04/07/15 08:58, Cédric Krier wrote:
> >Hi,
> >
> >For now, we put a blue color on entries when they are required (and
> >switch to red when validated as empty).
> >I think it is a bad practice for 2 reasons:
> >
> > - the colors are not custumizable and so they could not work on some
> > thèmes.
> >
> > - it is doesn't help the accessibility [1] as this information is
> > only based on color.
> >
> >So I was thinking instead about adding a "*" on the labels of the
> >required fields. This still stay quite visual (but not too much) and
> >readable for accessibility.
> >
> >What do you think? Has anyone a better idea?
> >
>
> I suggest to not remove the current behaviour. The blue color and switching
> to red if the field is not filled is intuitive and clear for most people,
> the asterisk is not intuitive (needs a previous explanation), so I suggest
> adding a "*" without removing current behaviour.
This will not fix the first point about theme.
> On 04/07/15 08:58, Cédric Krier wrote:
> >Hi,
> >
> >For now, we put a blue color on entries when they are required (and
> >switch to red when validated as empty).
> >I think it is a bad practice for 2 reasons:
> >
> > - the colors are not custumizable and so they could not work on some
> > thèmes.
> >
> > - it is doesn't help the accessibility [1] as this information is
> > only based on color.
> >
> >So I was thinking instead about adding a "*" on the labels of the
> >required fields. This still stay quite visual (but not too much) and
> >readable for accessibility.
> >
> >What do you think? Has anyone a better idea?
> >
>
> I suggest to not remove the current behaviour. The blue color and switching
> to red if the field is not filled is intuitive and clear for most people,
> the asterisk is not intuitive (needs a previous explanation), so I suggest
> adding a "*" without removing current behaviour.
Mathias Behrle
Jul 4, 2015, 6:32:46 AM7/4/15
to tryto...@googlegroups.com
* Jordi Esteve: " Re: [tryton-dev] Colors of fields" (Sat, 04 Jul 2015 10:49:44
+0200):
> On 04/07/15 08:58, Cédric Krier wrote:
> > Hi,
> >
> > For now, we put a blue color on entries when they are required (and
> > switch to red when validated as empty).
> > I think it is a bad practice for 2 reasons:
> >
> > - the colors are not custumizable and so they could not work on some
> > thèmes.
> >
> > - it is doesn't help the accessibility [1] as this information is
> > only based on color.
> >
> > So I was thinking instead about adding a "*" on the labels of the
> > required fields. This still stay quite visual (but not too much) and
> > readable for accessibility.
> >
> > What do you think? Has anyone a better idea?
> >
>
> I suggest to not remove the current behaviour. The blue color and
> switching to red if the field is not filled is intuitive and clear for
> most people, the asterisk is not intuitive (needs a previous
> explanation), so I suggest adding a "*" without removing current behaviour.
Marking a field with a star is On/Off, while currently with colors we have the
evidence, that a field is required *and* showing after the validation,
which fields missed the validation. So by replacing colors with stars we would
lose one information level. Perhaps this could be solved by differentiating with
small and big star (small for required field, big for missing validation).
OTOH I would appreciate indeed, that the idea to surround the field with a red
line instead of coloring the background would make its way [0].
This change would make the interface less shouting, but more informative.
BTW the current state after [1] indeed confirms my reservations about a
unsteady moving interface [2]. You did your best to make it unobtrusive, but
the result is nevertheless, that after clicking a record and shifting of the
interface the mouse pointer is located above a different record and the user
has to re-orientate himself. I really don't like those unintentional jumping
interfaces on user interactions, perhaps other Trytonistas could give feedback
as well.
Even if in sao the info bar should be better placed at the top (I didn't have a
look at that), this shouldn't dictate the behavior of the gtk client. I don't
feel it to be the right approach to try to copy *slavishly* the gtk and the web
interface. Both interfaces have different pros and cons. When the web interface
affords different means for informational messages, the gtk client shouldn't
lose parts of his usability just to match the layout of this info bar in the
web client.
Just last but not least: I would prefer to have the messages centered like in
the initial proposal [3]. Currently they display left-aligned.
[0] https://bugs.tryton.org/msg20371
[1] http://hg.tryton.org/tryton/rev/4aabbd421cf5
[2] https://bugs.tryton.org/issue3465
[3] https://bugs.tryton.org/file2223/form_error.png
--
Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg
Tel: +49(761)471023
Fax: +49(761)4770816
http://www.m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6
+0200):
> On 04/07/15 08:58, Cédric Krier wrote:
> > Hi,
> >
> > For now, we put a blue color on entries when they are required (and
> > switch to red when validated as empty).
> > I think it is a bad practice for 2 reasons:
> >
> > - the colors are not custumizable and so they could not work on some
> > thèmes.
> >
> > - it is doesn't help the accessibility [1] as this information is
> > only based on color.
> >
> > So I was thinking instead about adding a "*" on the labels of the
> > required fields. This still stay quite visual (but not too much) and
> > readable for accessibility.
> >
> > What do you think? Has anyone a better idea?
> >
>
> I suggest to not remove the current behaviour. The blue color and
> switching to red if the field is not filled is intuitive and clear for
> most people, the asterisk is not intuitive (needs a previous
> explanation), so I suggest adding a "*" without removing current behaviour.
evidence, that a field is required *and* showing after the validation,
which fields missed the validation. So by replacing colors with stars we would
lose one information level. Perhaps this could be solved by differentiating with
small and big star (small for required field, big for missing validation).
OTOH I would appreciate indeed, that the idea to surround the field with a red
line instead of coloring the background would make its way [0].
This change would make the interface less shouting, but more informative.
BTW the current state after [1] indeed confirms my reservations about a
unsteady moving interface [2]. You did your best to make it unobtrusive, but
the result is nevertheless, that after clicking a record and shifting of the
interface the mouse pointer is located above a different record and the user
has to re-orientate himself. I really don't like those unintentional jumping
interfaces on user interactions, perhaps other Trytonistas could give feedback
as well.
Even if in sao the info bar should be better placed at the top (I didn't have a
look at that), this shouldn't dictate the behavior of the gtk client. I don't
feel it to be the right approach to try to copy *slavishly* the gtk and the web
interface. Both interfaces have different pros and cons. When the web interface
affords different means for informational messages, the gtk client shouldn't
lose parts of his usability just to match the layout of this info bar in the
web client.
Just last but not least: I would prefer to have the messages centered like in
the initial proposal [3]. Currently they display left-aligned.
[0] https://bugs.tryton.org/msg20371
[1] http://hg.tryton.org/tryton/rev/4aabbd421cf5
[2] https://bugs.tryton.org/issue3465
[3] https://bugs.tryton.org/file2223/form_error.png
--
Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg
Tel: +49(761)471023
Fax: +49(761)4770816
http://www.m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6
Oscar Andres Alvarez Montero
Jul 4, 2015, 8:49:19 AM7/4/15
to tryto...@googlegroups.com
I am curious, which context the color fail on some themes? because I never have saw to fail this feature
Cédric Krier
Jul 5, 2015, 3:35:03 AM7/5/15
to tryto...@googlegroups.com
On 2015-07-04 07:49, Oscar Andres Alvarez Montero wrote:
> I am curious, which context the color fail on some themes? because I never
> have saw to fail this feature
If I use a theme with blue color for text for example.
> I am curious, which context the color fail on some themes? because I never
> have saw to fail this feature
Also for accessibility see:
https://developer.gnome.org/accessibility-devel-guide/3.8/idp5133984.html.en
Cédric Krier
Jul 5, 2015, 3:45:03 AM7/5/15
to tryto...@googlegroups.com
be improved to give the name of the field with error and also I think we
can give a explaination for:
- required is simple: <Field> is required
- domain invalid: <Field> must follow: <domain parsed>
(only if we can parse it otherwise: <Field> is not valid for domain)
Also keep in mind, that the colors by default has no meaning, it has now
for current users because they learn it. But it is really not so obvious
for newbie, I'm often astonished by seeing new user not understand what
it means a bleu colored field.
I agree that a '*' on the label also need to be learn but we can teach
user by setting a tooltip on it and with my proposal for info.
> OTOH I would appreciate indeed, that the idea to surround the field with a red
> line instead of coloring the background would make its way [0].
> This change would make the interface less shouting, but more informative.
Jean Cavallo
Jul 6, 2015, 3:16:08 AM7/6/15
to tryto...@googlegroups.com
Wouldn't it be better to make it configurable someway ?
Our user will really feel the loss of colors as a loss of functionality of the
client.
2015-07-04 10:49 GMT+02:00 Jordi Esteve <jes...@zikzakmedia.com>:
The blue color and switching to red if the field is not filled is intuitive and clear for most people, the asterisk is not intuitive (needs a previous explanation), so I suggest adding a "*" without removing current behaviour.
Agreed
Jean Cavallo
Coopengo
Jean Cavallo
Jul 6, 2015, 3:17:40 AM7/6/15
to tryto...@googlegroups.com
Love this !
Jean Cavallo
Coopengo
Nicolas Évrard
Jul 6, 2015, 6:29:31 AM7/6/15
to tryton
* Cédric Krier [2015-07-04 08:58 +0200]:
>Hi,
Hello,
>For now, we put a blue color on entries when they are required (and
>switch to red when validated as empty).
>I think it is a bad practice for 2 reasons:
>
> - the colors are not custumizable and so they could not work on some
> thèmes.
>
> - it is doesn't help the accessibility [1] as this information is
> only based on color.
>
>So I was thinking instead about adding a "*" on the labels of the
>required fields. This still stay quite visual (but not too much) and
>readable for accessibility.
>
>What do you think? Has anyone a better idea?
Switching to GTK3 ;).
In fact I think this should be handle by GTK and not us.
They have those states available for the widgets:
https://developer.gnome.org/gtk3/stable/gtk3-Standard-Enumerations.html#GtkStateFlags
Amongst them there is GTK_STATE_FLAG_INCONSISTENT which states that
the widget is inconsistent and this state is available as a CSS-alike
pseudo-class for theme designers. It is then up to them to handle
this.
And for the accessibility information what we could do is to adding a
description to the invalid field that it's a required one (or
something else about domain) once the field is inconsistent and then
focus it, the assistive technology will then convey this information
to the user.
--
Nicolas Évrard - B2CK SPRL
E-mail/Jabber: nicolas...@b2ck.com
>Hi,
Hello,
>For now, we put a blue color on entries when they are required (and
>switch to red when validated as empty).
>I think it is a bad practice for 2 reasons:
>
> - the colors are not custumizable and so they could not work on some
> thèmes.
>
> - it is doesn't help the accessibility [1] as this information is
> only based on color.
>
>So I was thinking instead about adding a "*" on the labels of the
>required fields. This still stay quite visual (but not too much) and
>readable for accessibility.
>
>What do you think? Has anyone a better idea?
In fact I think this should be handle by GTK and not us.
They have those states available for the widgets:
https://developer.gnome.org/gtk3/stable/gtk3-Standard-Enumerations.html#GtkStateFlags
Amongst them there is GTK_STATE_FLAG_INCONSISTENT which states that
the widget is inconsistent and this state is available as a CSS-alike
pseudo-class for theme designers. It is then up to them to handle
this.
And for the accessibility information what we could do is to adding a
description to the invalid field that it's a required one (or
something else about domain) once the field is inconsistent and then
focus it, the assistive technology will then convey this information
to the user.
--
Nicolas Évrard - B2CK SPRL
E-mail/Jabber: nicolas...@b2ck.com
Cédric Krier
Jul 6, 2015, 6:40:03 AM7/6/15
to tryton
On 2015-07-06 12:29, Nicolas Évrard wrote:
> * Cédric Krier [2015-07-04 08:58 +0200]:
> >Hi,
>
> Hello,
>
> >For now, we put a blue color on entries when they are required (and
> >switch to red when validated as empty).
> >I think it is a bad practice for 2 reasons:
> >
> > - the colors are not custumizable and so they could not work on some
> > thèmes.
> >
> > - it is doesn't help the accessibility [1] as this information is
> > only based on color.
> >
> >So I was thinking instead about adding a "*" on the labels of the
> >required fields. This still stay quite visual (but not too much) and
> >readable for accessibility.
> >
> >What do you think? Has anyone a better idea?
>
> Switching to GTK3 ;).
> In fact I think this should be handle by GTK and not us.
> They have those states available for the widgets:
> https://developer.gnome.org/gtk3/stable/gtk3-Standard-Enumerations.html#GtkStateFlags
>
> Amongst them there is GTK_STATE_FLAG_INCONSISTENT which states that
> the widget is inconsistent and this state is available as a CSS-alike
> pseudo-class for theme designers. It is then up to them to handle
> this.
Except default theme doesn't change anything to an entry with this
> * Cédric Krier [2015-07-04 08:58 +0200]:
> >Hi,
>
> Hello,
>
> >For now, we put a blue color on entries when they are required (and
> >switch to red when validated as empty).
> >I think it is a bad practice for 2 reasons:
> >
> > - the colors are not custumizable and so they could not work on some
> > thèmes.
> >
> > - it is doesn't help the accessibility [1] as this information is
> > only based on color.
> >
> >So I was thinking instead about adding a "*" on the labels of the
> >required fields. This still stay quite visual (but not too much) and
> >readable for accessibility.
> >
> >What do you think? Has anyone a better idea?
>
> Switching to GTK3 ;).
> In fact I think this should be handle by GTK and not us.
> They have those states available for the widgets:
> https://developer.gnome.org/gtk3/stable/gtk3-Standard-Enumerations.html#GtkStateFlags
>
> Amongst them there is GTK_STATE_FLAG_INCONSISTENT which states that
> the widget is inconsistent and this state is available as a CSS-alike
> pseudo-class for theme designers. It is then up to them to handle
> this.
state. So it seems to not be designed with this specific purpose.
Nicolas Évrard
Jul 6, 2015, 7:24:33 AM7/6/15
to tryton
* Cédric Krier [2015-07-06 12:37 +0200]:
Indeed according to a discussion I have on #gtk+ the way to go is
to add the 'error' class on the widget. The default theme defines css
for this class (and I discovered other classes like 'question',
'warning', 'info' and so on).
to add the 'error' class on the widget. The default theme defines css
for this class (and I discovered other classes like 'question',
'warning', 'info' and so on).
Cédric Krier
Jul 6, 2015, 5:40:06 PM7/6/15
to tryton
On 2015-07-04 08:58, Cédric Krier wrote:
> Hi,
>
> For now, we put a blue color on entries when they are required (and
> switch to red when validated as empty).
> I think it is a bad practice for 2 reasons:
>
> - the colors are not custumizable and so they could not work on some
> thèmes.
>
> - it is doesn't help the accessibility [1] as this information is
> only based on color.
>
> So I was thinking instead about adding a "*" on the labels of the
> required fields. This still stay quite visual (but not too much) and
> readable for accessibility.
Indeed the '*' solution is not so beautiful.
> Hi,
>
> For now, we put a blue color on entries when they are required (and
> switch to red when validated as empty).
> I think it is a bad practice for 2 reasons:
>
> - the colors are not custumizable and so they could not work on some
> thèmes.
>
> - it is doesn't help the accessibility [1] as this information is
> only based on color.
>
> So I was thinking instead about adding a "*" on the labels of the
> required fields. This still stay quite visual (but not too much) and
> readable for accessibility.
So I worked on an other proposal:
- make label bold for required field
- have a better 'invalid form' message that describe the problem
So here is a screenshot of such invalid form with missing required field
and wrong value because of domain.
I think it is really an improvement because now we explain to the user
what is wrong and experienced user can still anticipate required fields.
Albert Cervera i Areny
Jul 6, 2015, 6:50:55 PM7/6/15
to tryto...@googlegroups.com
2015-07-06 23:36 GMT+02:00 Cédric Krier <cedric...@b2ck.com>:
> On 2015-07-04 08:58, Cédric Krier wrote:
>> Hi,
>>
>> For now, we put a blue color on entries when they are required (and
>> switch to red when validated as empty).
>> I think it is a bad practice for 2 reasons:
>>
>> - the colors are not custumizable and so they could not work on some
>> thèmes.
>>
>> - it is doesn't help the accessibility [1] as this information is
>> only based on color.
>>
>> So I was thinking instead about adding a "*" on the labels of the
>> required fields. This still stay quite visual (but not too much) and
>> readable for accessibility.
>
> Indeed the '*' solution is not so beautiful.
>
> So I worked on an other proposal:
>
> - make label bold for required field
> - have a better 'invalid form' message that describe the problem
>
> So here is a screenshot of such invalid form with missing required field
> and wrong value because of domain.
> I think it is really an improvement because now we explain to the user
> what is wrong and experienced user can still anticipate required fields.
>
I agree it is a very good improvement.
> On 2015-07-04 08:58, Cédric Krier wrote:
>> Hi,
>>
>> For now, we put a blue color on entries when they are required (and
>> switch to red when validated as empty).
>> I think it is a bad practice for 2 reasons:
>>
>> - the colors are not custumizable and so they could not work on some
>> thèmes.
>>
>> - it is doesn't help the accessibility [1] as this information is
>> only based on color.
>>
>> So I was thinking instead about adding a "*" on the labels of the
>> required fields. This still stay quite visual (but not too much) and
>> readable for accessibility.
>
> Indeed the '*' solution is not so beautiful.
>
> So I worked on an other proposal:
>
> - make label bold for required field
> - have a better 'invalid form' message that describe the problem
>
> So here is a screenshot of such invalid form with missing required field
> and wrong value because of domain.
> I think it is really an improvement because now we explain to the user
> what is wrong and experienced user can still anticipate required fields.
>
> --
> Cédric Krier - B2CK SPRL
> Email/Jabber: cedric...@b2ck.com
> Tel: +32 472 54 46 59
> Website: http://www.b2ck.com/
Albert Cervera i Areny
Tel. 93 553 18 03
@albertnan
www.NaN-tic.com
Jean Cavallo
Jul 7, 2015, 3:05:25 AM7/7/15
to tryto...@googlegroups.com
2015-07-07 0:50 GMT+02:00 Albert Cervera i Areny <alb...@nan-tic.com>:
> So here is a screenshot of such invalid form with missing required field
> and wrong value because of domain.
> I think it is really an improvement because now we explain to the user
> what is wrong and experienced user can still anticipate required fields.
>
I agree it is a very good improvement.
Indeed it looks rather good, and is very informative !
Jean Cavallo
Coopengo
Udo Spallek
Jul 7, 2015, 3:06:59 AM7/7/15
to tryto...@googlegroups.com
Mon, 6 Jul 2015 23:36:22 +0200
Cédric Krier <cedric...@b2ck.com>:
>On 2015-07-04 08:58, Cédric Krier wrote:
>> Hi,
>>
>> For now, we put a blue color on entries when they are required (and
>> switch to red when validated as empty).
>> I think it is a bad practice for 2 reasons:
>>
>> - the colors are not custumizable and so they could not work on
>> some thèmes.
>>
>> - it is doesn't help the accessibility [1] as this information is
>> only based on color.
>>
>> So I was thinking instead about adding a "*" on the labels of the
>> required fields. This still stay quite visual (but not too much) and
>> readable for accessibility.
>
>Indeed the '*' solution is not so beautiful.
>
>So I worked on an other proposal:
>
> - make label bold for required field
> - have a better 'invalid form' message that describe the problem
>
>So here is a screenshot of such invalid form with missing required
>field and wrong value because of domain.
>I think it is really an improvement because now we explain to the user
>what is wrong and experienced user can still anticipate required
>fields.
I like it, IMHO the best idea so far.
Cédric Krier <cedric...@b2ck.com>:
>On 2015-07-04 08:58, Cédric Krier wrote:
>> Hi,
>>
>> For now, we put a blue color on entries when they are required (and
>> switch to red when validated as empty).
>> I think it is a bad practice for 2 reasons:
>>
>> - the colors are not custumizable and so they could not work on
>> some thèmes.
>>
>> - it is doesn't help the accessibility [1] as this information is
>> only based on color.
>>
>> So I was thinking instead about adding a "*" on the labels of the
>> required fields. This still stay quite visual (but not too much) and
>> readable for accessibility.
>
>Indeed the '*' solution is not so beautiful.
>
>So I worked on an other proposal:
>
> - make label bold for required field
> - have a better 'invalid form' message that describe the problem
>
>So here is a screenshot of such invalid form with missing required
>field and wrong value because of domain.
>I think it is really an improvement because now we explain to the user
>what is wrong and experienced user can still anticipate required
>fields.
Jordi Esteve
Jul 7, 2015, 5:57:02 AM7/7/15
to tryto...@googlegroups.com
Raimon Esteve
Jul 7, 2015, 6:22:41 AM7/7/15
to tryto...@googlegroups.com
2015-07-06 23:36 GMT+02:00 Cédric Krier <cedric...@b2ck.com>:
> On 2015-07-04 08:58, Cédric Krier wrote:
>> Hi,
>>
>> For now, we put a blue color on entries when they are required (and
>> switch to red when validated as empty).
>> I think it is a bad practice for 2 reasons:
>>
>> - the colors are not custumizable and so they could not work on some
>> thèmes.
>>
>> - it is doesn't help the accessibility [1] as this information is
>> only based on color.
>>
>> So I was thinking instead about adding a "*" on the labels of the
>> required fields. This still stay quite visual (but not too much) and
>> readable for accessibility.
>
> Indeed the '*' solution is not so beautiful.
>
> So I worked on an other proposal:
>
> - make label bold for required field
> - have a better 'invalid form' message that describe the problem
>
> So here is a screenshot of such invalid form with missing required field
> and wrong value because of domain.
> I think it is really an improvement because now we explain to the user
> what is wrong and experienced user can still anticipate required fields.
+1 about screenshot
>> Hi,
>>
>> For now, we put a blue color on entries when they are required (and
>> switch to red when validated as empty).
>> I think it is a bad practice for 2 reasons:
>>
>> - the colors are not custumizable and so they could not work on some
>> thèmes.
>>
>> - it is doesn't help the accessibility [1] as this information is
>> only based on color.
>>
>> So I was thinking instead about adding a "*" on the labels of the
>> required fields. This still stay quite visual (but not too much) and
>> readable for accessibility.
>
> Indeed the '*' solution is not so beautiful.
>
> So I worked on an other proposal:
>
> - make label bold for required field
> - have a better 'invalid form' message that describe the problem
>
> So here is a screenshot of such invalid form with missing required field
> and wrong value because of domain.
> I think it is really an improvement because now we explain to the user
> what is wrong and experienced user can still anticipate required fields.
1- About a lot of messages and working a small screen, it's possible
message box is bigger than small screen. Scroll all window tab?
Message box have a maximun pixels to show messages and only scroll
message box?
2- Close button at the botton or at the top of message box?
Cédric Krier
Jul 7, 2015, 7:05:03 AM7/7/15
to tryto...@googlegroups.com
Scroll is not an option because it will require to define in pixel the
minimal height.
> 2- Close button at the botton or at the top of message box?
Mathias Behrle
Jul 7, 2015, 7:27:17 AM7/7/15
to tryto...@googlegroups.com
* Cédric Krier: " Re: [tryton-dev] Colors of fields" (Mon, 6 Jul 2015 23:36:22
+0200):
> On 2015-07-04 08:58, Cédric Krier wrote:
> > Hi,
> >
> > For now, we put a blue color on entries when they are required (and
> > switch to red when validated as empty).
> > I think it is a bad practice for 2 reasons:
> >
> > - the colors are not custumizable and so they could not work on some
> > thèmes.
> >
> > - it is doesn't help the accessibility [1] as this information is
> > only based on color.
> >
> > So I was thinking instead about adding a "*" on the labels of the
> > required fields. This still stay quite visual (but not too much) and
> > readable for accessibility.
>
> Indeed the '*' solution is not so beautiful.
>
> So I worked on an other proposal:
>
> - make label bold for required field
> - have a better 'invalid form' message that describe the problem
>
> So here is a screenshot of such invalid form with missing required field
> and wrong value because of domain.
> I think it is really an improvement because now we explain to the user
> what is wrong and experienced user can still anticipate required fields.
Best proposal so far and should also meet the acceptance of long standing users.
+0200):
> On 2015-07-04 08:58, Cédric Krier wrote:
> > Hi,
> >
> > For now, we put a blue color on entries when they are required (and
> > switch to red when validated as empty).
> > I think it is a bad practice for 2 reasons:
> >
> > - the colors are not custumizable and so they could not work on some
> > thèmes.
> >
> > - it is doesn't help the accessibility [1] as this information is
> > only based on color.
> >
> > So I was thinking instead about adding a "*" on the labels of the
> > required fields. This still stay quite visual (but not too much) and
> > readable for accessibility.
>
> Indeed the '*' solution is not so beautiful.
>
> So I worked on an other proposal:
>
> - make label bold for required field
> - have a better 'invalid form' message that describe the problem
>
> So here is a screenshot of such invalid form with missing required field
> and wrong value because of domain.
> I think it is really an improvement because now we explain to the user
> what is wrong and experienced user can still anticipate required fields.
Cédric Krier
Jul 7, 2015, 10:05:03 AM7/7/15
to tryton
On 2015-07-06 23:36, Cédric Krier wrote:
> On 2015-07-04 08:58, Cédric Krier wrote:
> > Hi,
> >
> > For now, we put a blue color on entries when they are required (and
> > switch to red when validated as empty).
> > I think it is a bad practice for 2 reasons:
> >
> > - the colors are not custumizable and so they could not work on some
> > thèmes.
> >
> > - it is doesn't help the accessibility [1] as this information is
> > only based on color.
> >
> > So I was thinking instead about adding a "*" on the labels of the
> > required fields. This still stay quite visual (but not too much) and
> > readable for accessibility.
>
> Indeed the '*' solution is not so beautiful.
>
> So I worked on an other proposal:
>
> - make label bold for required field
> - have a better 'invalid form' message that describe the problem
>
> So here is a screenshot of such invalid form with missing required field
> and wrong value because of domain.
> I think it is really an improvement because now we explain to the user
> what is wrong and experienced user can still anticipate required fields.
FYI, the feature https://bugs.tryton.org/issue4861
> On 2015-07-04 08:58, Cédric Krier wrote:
> > Hi,
> >
> > For now, we put a blue color on entries when they are required (and
> > switch to red when validated as empty).
> > I think it is a bad practice for 2 reasons:
> >
> > - the colors are not custumizable and so they could not work on some
> > thèmes.
> >
> > - it is doesn't help the accessibility [1] as this information is
> > only based on color.
> >
> > So I was thinking instead about adding a "*" on the labels of the
> > required fields. This still stay quite visual (but not too much) and
> > readable for accessibility.
>
> Indeed the '*' solution is not so beautiful.
>
> So I worked on an other proposal:
>
> - make label bold for required field
> - have a better 'invalid form' message that describe the problem
>
> So here is a screenshot of such invalid form with missing required field
> and wrong value because of domain.
> I think it is really an improvement because now we explain to the user
> what is wrong and experienced user can still anticipate required fields.
Albert Cervera i Areny
Jul 7, 2015, 4:35:53 PM7/7/15
to tryto...@googlegroups.com
2015-07-06 23:36 GMT+02:00 Cédric Krier <cedric...@b2ck.com>:
> On 2015-07-04 08:58, Cédric Krier wrote:
>> Hi,
>>
>> For now, we put a blue color on entries when they are required (and
>> switch to red when validated as empty).
>> I think it is a bad practice for 2 reasons:
>>
>> - the colors are not custumizable and so they could not work on some
>> thèmes.
>>
>> - it is doesn't help the accessibility [1] as this information is
>> only based on color.
>>
>> So I was thinking instead about adding a "*" on the labels of the
>> required fields. This still stay quite visual (but not too much) and
>> readable for accessibility.
>
> Indeed the '*' solution is not so beautiful.
>
> So I worked on an other proposal:
>
> - make label bold for required field
I think that making the label bold does not solve the problem when a
>> Hi,
>>
>> For now, we put a blue color on entries when they are required (and
>> switch to red when validated as empty).
>> I think it is a bad practice for 2 reasons:
>>
>> - the colors are not custumizable and so they could not work on some
>> thèmes.
>>
>> - it is doesn't help the accessibility [1] as this information is
>> only based on color.
>>
>> So I was thinking instead about adding a "*" on the labels of the
>> required fields. This still stay quite visual (but not too much) and
>> readable for accessibility.
>
> Indeed the '*' solution is not so beautiful.
>
> So I worked on an other proposal:
>
> - make label bold for required field
field has no label.
Of course, adding "*" has the same problem.
I don't see a better solution than changing the background color. To
circumvent the problem with themes or accessibility maybe we could
make the color configurable as a client side option. That would not be
ideal, but would improve current situation a little bit while not
suffering from the mentioned problems.
> - have a better 'invalid form' message that describe the problem
>
> So here is a screenshot of such invalid form with missing required field
> and wrong value because of domain.
> I think it is really an improvement because now we explain to the user
> what is wrong and experienced user can still anticipate required fields.
>
> --
> Cédric Krier - B2CK SPRL
> Email/Jabber: cedric...@b2ck.com
> Tel: +32 472 54 46 59
> Website: http://www.b2ck.com/
Cédric Krier
Jul 7, 2015, 5:35:03 PM7/7/15
to tryto...@googlegroups.com
On 2015-07-07 22:35, Albert Cervera i Areny wrote:
> 2015-07-06 23:36 GMT+02:00 Cédric Krier <cedric...@b2ck.com>:
> > On 2015-07-04 08:58, Cédric Krier wrote:
> >> Hi,
> >>
> >> For now, we put a blue color on entries when they are required (and
> >> switch to red when validated as empty).
> >> I think it is a bad practice for 2 reasons:
> >>
> >> - the colors are not custumizable and so they could not work on some
> >> thèmes.
> >>
> >> - it is doesn't help the accessibility [1] as this information is
> >> only based on color.
> >>
> >> So I was thinking instead about adding a "*" on the labels of the
> >> required fields. This still stay quite visual (but not too much) and
> >> readable for accessibility.
> >
> > Indeed the '*' solution is not so beautiful.
> >
> > So I worked on an other proposal:
> >
> > - make label bold for required field
>
> I think that making the label bold does not solve the problem when a
> field has no label.
>
> Of course, adding "*" has the same problem.
Indeed for me, this is purly accessory. I added only because I know many
> 2015-07-06 23:36 GMT+02:00 Cédric Krier <cedric...@b2ck.com>:
> > On 2015-07-04 08:58, Cédric Krier wrote:
> >> Hi,
> >>
> >> For now, we put a blue color on entries when they are required (and
> >> switch to red when validated as empty).
> >> I think it is a bad practice for 2 reasons:
> >>
> >> - the colors are not custumizable and so they could not work on some
> >> thèmes.
> >>
> >> - it is doesn't help the accessibility [1] as this information is
> >> only based on color.
> >>
> >> So I was thinking instead about adding a "*" on the labels of the
> >> required fields. This still stay quite visual (but not too much) and
> >> readable for accessibility.
> >
> > Indeed the '*' solution is not so beautiful.
> >
> > So I worked on an other proposal:
> >
> > - make label bold for required field
>
> I think that making the label bold does not solve the problem when a
> field has no label.
>
> Of course, adding "*" has the same problem.
of you will cry thinking it is a lost. But in reality, it is realy not
needed to have such information. User must encode all the value he
knows, then if when he tries to perform an action that requires some
missing information, he will be warned (and the focus will be put at the
right place) and he will try to find a solution to fill the missing
value.
Also why required should be a special case compared to other validation
like domain, SQL constraint etc. For me, Tryton should have the strictly
minimal constraint and thus those constraint should be so obvious that
they don't need to be shown.
> I don't see a better solution than changing the background color. To
> circumvent the problem with themes or accessibility maybe we could
> make the color configurable as a client side option.
> That would not be
> ideal, but would improve current situation a little bit while not
> suffering from the mentioned problems.
explain what is the meaning of this option which will not be so easy.
Plus it will create a new vector of issues.
Albert Cervera i Areny
Jul 8, 2015, 4:44:41 AM7/8/15
to tryto...@googlegroups.com
when making a field required when changing the state of the document,
for example. Such as the party is required in opportunities only when
state is "Opportunity" but not when it is a "Lead".
So yes, it is already inconsistent to have that information for some cases only.
>> I don't see a better solution than changing the background color. To
>> circumvent the problem with themes or accessibility maybe we could
>> make the color configurable as a client side option.
>
> Options are always the poorest answer.
>
>> That would not be
>> ideal, but would improve current situation a little bit while not
>> suffering from the mentioned problems.
>
> Except the application will become more complex, you will have to
> explain what is the meaning of this option which will not be so easy.
> Plus it will create a new vector of issues.
>
> --
> Cédric Krier - B2CK SPRL
> Email/Jabber: cedric...@b2ck.com
> Tel: +32 472 54 46 59
> Website: http://www.b2ck.com/
Reply all
Reply to author
Forward
0 new messages