Client improvement: form view background color

[Emma]

Hi everyone,

I have a particular request from a client who wants to "blacklist" some parties. They still want to have access to those blacklisted parties as to any other party but they want to make sure it is really obvious the party is blacklisted.
The best solution that came to mind could be to have a (light) red background on the forms of those clients. In other word porting the "colors" attribute from the tree view to the form view.

As this is client side this is not just a module I can code and add to the sever.

So my question is: do you think this feature might be interesting to the general tryton public and if I code it and provide the patch, would you be willing to integrate it to the official tryton client?

Thanks

Emma

[Udo Spallek]

Hi Emma,

Thu, 3 May 2012 06:29:19 -0700 (PDT)
Emma <deles...@gmail.com>:

> The best solution that came to mind could be to have a (light) red
> background on the forms of those clients. In other word porting the
> "colors" attribute from the tree view to the form view.

we had some discussion about more color indicators for Tryton this in
the past. IIRC the topic came from the client design, which only allows
a connection to one database at a time. So in some multi-company setups
the user needs to have more than one Tryton client applications open.
To better distinguish these open clients, we thought about
framing or tinting the client with a color depending of the company.

On the other hand many colors are not this good for accessibility
(color blindness...).

Maybe another solution is to put a bold label in a
prominent place of the view, and show it depending on some state which
indicates the customer is 'blacklisted'.

Regards Udo
--
_____________________________
virtual things
Preisler & Spallek GbR
München - Aachen

Windeckstr. 77
81375 München
Tel: +49 (89) 710 481 55
Fax: +49 (89) 710 481 56

in...@virtual-things.biz
http://www.virtual-things.biz

[Emma]

On Thursday, 3 May 2012 16:46:40 UTC+2, udono wrote:

On the other hand many colors are not this good for accessibility
(color blindness...).

 

True, it shouldn't be the only indicator of blacklisting (and it is not there is a checkbox + text field stating why it has been blacklisted).

But it's what I've been asked and I guess colors can still be good and that's probably why is is already available in tree views

Emma

[Jan Grasnick | grasbauer ug]

Am 03.05.2012 15:29, schrieb Emma:
> Hi everyone,
>
> I have a particular request from a client who wants to "blacklist"
> some parties. They still want to have access to those blacklisted
> parties as to any other party but they want to make sure it is really
> obvious the party is blacklisted.
> The best solution that came to mind could be to have a (light) red
> background on the forms of those clients. In other word porting the
> "colors" attribute from the tree view to the form view.
>
> As this is client side this is not just a module I can code and add to
> the sever.

We had a very similar request from a client: colour the objects of a
quality module if the tests are in status failed. We coloured the tree
an in the view - as already implemented. In the form we putted an
image width field.function(field.binary('State
Image'),'get_state_image'). In the module we are streaming the images to
the client depending of the state of the object. This can be a fast
solution for your needs ...

Jan

[Cédric Krier]

On 03/05/12 08:19 -0700, Emma wrote:
> But it's what I've been asked and I guess colors can still be good and
> that's probably why is is already available in tree views

Indeed, the colors in tree view are not really good. The proof is that
almost any modules use it.
I think it will be good to have a global “rethink” of this functionnality.

--
Cédric Krier

B2CK SPRL
Rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
Email/Jabber: cedric...@b2ck.com
Website: http://www.b2ck.com/

[Emma]

On Thursday, 3 May 2012 17:33:19 UTC+2, grasbauer wrote:

We had a very similar request from a client:

... 

In the form we putted an image width field.function(field.binary('State
Image'),'get_state_image'). In the module we are streaming the images to
the client depending of the state of the object. This can be a fast
solution for your needs ...

Thanks, but since it seems to be a request that is apparently recurrent, wouldn't it be good to implement it as a feature instead as a workaround?

[Nicolas Évrard]

* Cédric Krier [2012-05-03 17:40 +0200]:

>On 03/05/12 08:19 -0700, Emma wrote:
>> But it's what I've been asked and I guess colors can still be good and
>> that's probably why is is already available in tree views
>
>Indeed, the colors in tree view are not really good. The proof is that
>almost any modules use it.
>I think it will be good to have a global “rethink” of this functionnality.

I don't like notification areas but the huge white square used as the
form title could be used to display some visual indications. Similarly
the same icons could be used in the treeviews.

But I don't know what and I don't know how.

--
Nicolas Évrard

B2CK SPRL
rue de Rotterdam, 4

4000 Liège
Belgium
Tel: +32 472 54 46 59

E-mail/Jabber: nicolas...@b2ck.com
Website: http://www.b2ck.com/

[Emma]

>I think it will be good to have a global “rethink” of this functionnality.

I don't like notification areas but the huge white square used as the
form title could be used to display some visual indications. Similarly
the same icons could be used in the treeviews.

But I don't know what and I don't know how.

Ok, what about adding something like res.tag 

Using those tags (some basic tags could be defined like some basic icons are defined and more could be registered) records could be tagged inside the code (view or model?) using pyson similarly to states or even maybe a new state.

Tag rendering would be defined inside "res.tag" but individual users could eventually redefine it inside their preferences.

Here are a few ways tags could be rendered:

• in form view:
• icon inside the "huge white square"
• tag name in full text in "the huge white square" <= probably the best for visually impaired people
• background or text color in the huge white square
• form background color
• in tree view:
• icon on the left
• tag name in full text (on the left I guess)
• color
• font-weight / font decoration

this would be a flexible way to "do the trick" which (I think) would please everyone (people who want colors and those who don't). 

What do you think?

[Cédric Krier]

On 08/05/12 07:58 -0700, Emma wrote:
> > >I think it will be good to have a global “rethink” of this
> > functionnality.
> >
> > I don't like notification areas but the huge white square used as the
> > form title could be used to display some visual indications. Similarly
> > the same icons could be used in the treeviews.
> >
> > But I don't know what and I don't know how.
>
>
> Ok, what about adding something like res.tag
> Using those tags (some basic tags could be defined like some basic icons
> are defined and more could be registered) records could be tagged inside
> the code (view or model?) using pyson similarly to states or even maybe a
> new state.
>
> Tag rendering would be defined inside "res.tag" but individual users could
> eventually redefine it inside their preferences.
> Here are a few ways tags could be rendered:
>

> - in form view:
> - icon inside the "huge white square"
> - tag name in full text in "the huge white square" <= probably the

> best for visually impaired people

> - background or text color in the huge white square
> - form background color
> - in tree view:
> - icon on the left
> - tag name in full text (on the left I guess)
> - color
> - font-weight / font decoration

>
>
> this would be a flexible way to "do the trick" which (I think) would please
> everyone (people who want colors and those who don't).
>
> What do you think?

I don't think the "huge white square" is the right place to put
information about the current record in form view because it is the same
white square displayed in the list view. So it is bad to have different
meaning for the same widget.

Yes, it could be good for completness to be able to diplay icons in
form. And icon is just a selection field, so why not having a widget
icon for such fields.

For me, the color should be removed because it can not be managed
correctly with the theme of the client. You can have wrong combination
that makes text unreadable. Indeed I think colored icons could be a good
replacement and if there is a widget for the form view, than we have a
global solution.

--
Cédric Krier

B2CK SPRL

Rue de Rotterdam, 4

4000 Liège
Belgium
Tel: +32 472 54 46 59

[Emma]

On Tuesday, 8 May 2012 17:50:31 UTC+2, Cédric Krier wrote:

I don't think the "huge white square" is the right place to put
information about the current record in form view because it is the same
white square displayed in the list view. So it is bad to have different
meaning for the same widget.

What about left to the huge white square then? In between the huge white square and the form menu icon?

Yes, it could be good for completness to be able to diplay icons in
form. And icon is just a selection field, so why not having a widget
icon for such fields.

A widget or maybe have an icon property defineable for records (then display it in tree/form/any other view)

 

For me, the color should be removed because it can not be managed
correctly with the theme of the client. You can have wrong combination
that makes text unreadable. Indeed I think colored icons could be a good
replacement and if there is a widget for the form view, than we have a
global solution.

A global solution is clearly  the way to go, I also think it's wrong to define colors separately in tree views.

But I think the "manageabilty" of colors in respect to the theme of some users is a non-issue if well thought.

First of all Tryton is a professional software used in a professional environment, therefore few people customize their theme. BUT that's not a valid reason to ignore those few people (I'm one of them). That is why I suggested the tagging system and the ability to customize the way tags (or however you want to call them) are rendered on a per-user basis inside the preferences for those who do customize their themes and who might run across incompatible renderings.

Plus, so far the colors that have been used are "pure basic" colors (blue, grey, red, ...) which are not really used in themes, so even if incompatibilities might occur it's still probably a very rare exception.

Also, using a cutomizable tagging system (system-wide AND user-defineable) would let companies decide the way they want things displayed (opposed to the current color system in tree-view, ie: the sys-admin wants draft account moves to be listed in grey instead of red because it's the way their old accounting software used to do it and people are used to it).

Should colors be the default way to highlight records? Probably not, but on 5 people taking part to this current thread, 2 have been asked by clients to use colors, so I think banning colors all together is not the way to go either.

[Cédric Krier]

On 08/05/12 09:56 -0700, Emma wrote:
>
>
> On Tuesday, 8 May 2012 17:50:31 UTC+2, Cédric Krier wrote:
> >
> > I don't think the "huge white square" is the right place to put
> > information about the current record in form view because it is the same
> > white square displayed in the list view. So it is bad to have different
> > meaning for the same widget.
> >
>
> What about left to the huge white square then? In between the huge white
> square and the form menu icon?

It is the same issue. This place is shared between form and list.

So then we must define a global schema for the colors that will be
customizable on the client side with preferences.
I propose to use the color names:
https://en.wikipedia.org/wiki/ANSI_escape_code#Colors
Than we could have a configuration object that will give coloring rules
to Model using a rule system and those rules will be push to the client
via the fields_view_get. This make the colorization just a configuration
job.

But we still need to find a way to display this color to the form view.
I thought (but not sure it is good) to put it in a border of the form.

[Emma]

On Tuesday, May 8, 2012 7:43:31 PM UTC+2, Cédric Krier wrote:

So then we must define a global schema for the colors that will be
customizable on the client side with preferences.
I propose to use the color names:
https://en.wikipedia.org/wiki/ANSI_escape_code#Colors

8 colors seems to be quite enough (well, maybe 7 since I'm not sure it would be wise to use "white") and it would only be a slight alteration to the COLOR_SCHEMES defined in tryton.common.

While re-working colors, I guess enabling customization of 'required' and 'invalid' colors could be a good idea for the same theme-related reasons.

 

Than we could have a configuration object that will give coloring rules
to Model using a rule system and those rules will be push to the client
via the fields_view_get. This make the colorization just a configuration
job.

That would work.

I was thinking about having a _highlight (or something else) property on models that would be a dictionary with 'icons' and 'colors' as keys. The values being a pyson string a bit like field states work but with colors/icons instead of just True/False

But we still need to find a way to display this color to the form view.
I thought (but not sure it is good) to put it in a border of the form.

No border for un-colored records and a colored border for colored records. I guess it could work but I'm not sure whether  it's good either.

Back to the huge white square...

The square is shared between views, but would it be a problem to implement the same behaviors in all view types?

This area already is partially "record dependent". I mean the record number on the right is updated in both view types. So why not update more than the record number still in both view types?

I'm still thinking about an icon to the left of the title and also colors; either coloring of the font or maybe better coloring of the background using the "coupled" color of the record (ie: red font for the record in the list view and light red background for the title area) I think it might be more obvious than just a border. I guess border and title area combined could be good?

[Cédric Krier]

On 08/05/12 11:51 -0700, Emma wrote:
> Back to the huge white square...
> The square is shared between views, but would it be a problem to implement
> the same behaviors in all view types?
> This area already is partially "record dependent". I mean the record number
> on the right is updated in both view types. So why not update more than the
> record number still in both view types?

I really don't think it is a good design, nor that it will be clear to
the user. Because on a list view, there could be a large distant between
the title and the selected record.

> I'm still thinking about an icon to the left of the title and also colors;
> either coloring of the font or maybe better coloring of the background
> using the "coupled" color of the record (ie: red font for the record in the
> list view and light red background for the title area) I think it might be
> more obvious than just a border. I guess border and title area combined
> could be good?

I'm still thinking that icons are just fields so they must be display
with the fields. Moreover on list view, it is really clean to have it in
a column.

As summary, I think that background for list and border for form are
good choice.

[Dominique Chabord]

Hello

Le 03/05/2012 15:29, Emma a �crit :

they want to make sure it is really obvious the
> party is blacklisted.

why noy seting the party "unactive", so you cannot do operations on it
anywhere and you have to ask for unactive parties to read them ?

hth

--
Dominique Chabord - SISalp

[Emma]

On Monday, 14 May 2012 19:17:43 UTC+2, Dominique Chabord wrote:

why noy seting the party "unactive", so you cannot do operations on it
anywhere and you have to ask for unactive parties to read them ?

Because even if blacklisted, action should still be performed on them and the list (forms) this topic is related to is generated by a wizard and should always include blacklisted records