Revisit Task Colors

[russdeffner]

This issue is to combine #1256 and #246 with a general recoloring of the task status. In the Activation Working Group we have noted that the 'red' for invalidated is maybe causing mappers to stay away from those tasks. We may also want to take into consideration color impaired vision to ensure all our mappers can easily understand what tasks are available to them.

[smit1678]

Thanks @russdeffner for bringing that up. One quick question: does an invalidated task even need to be colored?

I can see the case for a project manager or validator to maybe know, but for a mapper it doesn't make a difference right?

[russdeffner]

I think there is value in having some noticeable difference in a task that is invalidated - i.e. a bit of warning that it might be fixing stuff rather than just drawing new features.

[pantierra]

Probably related to this: #1523.

[zlavergne]

I've started using icons instead of additional colors. Here's an example of my implementation of task assignment:

For times when colors don't appropriately portray the status, I think icons could be super useful. I also had the idea that instead of red for invalidated (needs attention) you could use an exclamation point.

[ethan-nelson]

I am a big fan of icons :+1: we've struggled for a while with all the different colors. I tried to add pin-striping in TM2 to indicate a checked out task, but ran into issues with the map library at that point. An icon might be a way to indicate the status in a manner different than colors without being too overbearing. Furthermore, being able to see at a glance what state of task someone has checked out (e.g. mapping versus validating) could be beneficial.

[zlavergne]

I have the implementation for OpenLayers if you want to implement icons soon. But as @xamanu mentions in #1541 we may be switching from OL soon. If that's the case, it may be better to make the switch for the map library before adding icons. From what I've seen, not many people are making changes that rely heavily on the map so switching the map library might be safer than changing the whole front end framework.

Thoughts @xamanu?

[pantierra]

On the colors, we got some input from our redesign. Instead of adding more colors we were encouraged to reduce the states to what matters to the users:

What do you think about these states and colors?

I like the idea of using icons for further indication, like user to tasks assignments in #1575. And i guess we will have more good use for this for future features.

[pantierra]

For your information: In #1523 (and #1518) @theprover97 suggested to switch the current task colors for 'Bad Imagery' and 'Invalidated'.

[giblet22]

@xamanu I believe the comments about "what matters to the users" were from me on the redesign wireframes. Just to add some additonal context. In the screenshot you shared above, I think the most important things should be Ready to Map and Mapped (or maybe Needs validation), and More work needed.

I would argue that Locked for mapping and Validated should either have some sort of transparency or use a less intense color, so that users aren't confused about where they need to go.

[pantierra]

Let's compare concretely:

Current	theprover97	ready2go (#1385)	Redesign

Some inputs:

• "Invalidated" shall change to "More work needed" (#1376) as proposed in the redesign.
• There are concerns about the red colour for invalidated/more work needed.
• Recapping the design thoughts, it was confusing for - especially beginner - mappers to handle too many layers, which don't mean much to them (what do i care whether it is bad imagery? i just want to know which tasks I can jump on, how much is done, and what is pending, ...)
• One reaction on the colours of the redesign is the desire for more transparent colours, that allow to see the map underneath.
• @nrotstan proposes (#1385) to introduce more layers, to make certain states more explicit (partially mapped, something which was started but not finished; review requested, to communicate to validators that help or more time will be needed from them)

I gave it a try to combine what I think are the best elements of each proposals based on our conversations:

• "Bad imagery" falls kind out of the row, because it describes not a state but a diagnosis and that makes it difficult for new users. I also think that in the future there might be other reasons, why certain areas are "Not for mapping". And I think it is the appropriate to use the red here.
• The "review needed" state is added as it might be really useful. The "invalidated/more work needed", I considered combining with "partially mapped". We could track the reason for being on the state of "more work needed", whether it was because somebody mapped it partially or it was returned by the validator. But on the map overview, we might be able have one indicator for something it there, and more work is needed.
• Following the idea of @theprover97, using grey for the "more work needed", but lighting it up a bit, so it becomes closer to "ready to map". At the end, both types are for people to pick up and choosing similar colours may give a user the right hint.
• I follow here the redesign proposal to not differentiate between locked and locked by you. The border on the square speaks for itself, I assume.

This proposal is not shorting the list of seven elements. But hopefully it is more consolidated and combining many good thoughts and improvements in itself.

[zlavergne]

@xamanu if icons are going to be part of the redesign, I think the Locked state is another good use for them. That would be one fewer colors to deal with. I think using a lock icon either colored green if "locked by me" or red if just "locked" would be a very clear representation 🔒 🎉

[pantierra]

I want to bring into the conversation also this comment from @giblet22 in #1004 regarding another layer - the priority area:

Can we change either the color of invalidated or the color of the priority area? They're both the same shade of red and someone could interpret a priority area as invalidated and may choose to not map it.

---

And the request to take into consideration colour blindness (#608):

We received a notice from a user that the color coding on the map grid is hard for red/green folks to see. He suggested a roll over task status would help with the issue if we can't also find another way to address it.

I'm going to close the other issues, so we can concentrate conversation here.

[verdy-p]

Beware of the red and green colors used for "review needed" (or invalidated) and "ready". If their lightness is not contrasting enough, they are confusable (notably on their light semi-transparent shades that are used for coloring the tiles and not obscuring them completely; we still must know where we are on the map).

But for accessibility (by color bling people), the most problematic distinctions are always somewhere ion the middle on red and green (both are usually distinguished if they are "pure" enough, i.e. with a large enough "angle" of the hue component of colors, in HSL representation), and they are in the subtle shades of beige/brown (saturated yellow is usually disintguished because of its more important lightness than plain red, the darker, and plain green, mid-light, while yellow is much lighter).

For evaluating a color scheme, please convert colors in HSL, make sure that all colors have all pairs of H differences larger than 30 degrees, and preferably larger than 60 degrees in the green-to-red sector of the color-wheel for "color blind" peoples, otherwise make sure that differences of lightness (L) are larger than 20% (you need larger difference of L if differences of hue (H) is smaller). The difference of saturation (S) does not matter and is cleared by the ~50% transparency applied, and the fact colors are then made slighly lighter.

Note that about 10 to 15% of males (notably within the Caucasian/white group where it is the largest) have color blindness. It is not something to ignore. The most common group are still seeing tri-stimuli colors, but they have a perception of the green component "shifted" a bit toward the red (this is caused by a genetic mutation of the chromatic filter in retina cells).

Some rare people have also this shifted component, but it comes in addition to the "normal" green component: they have both types of cells in their eyes, so their perception is quadri-stimuli, and their perception of the color gammut is larger than most people (they can distinguish thousands more distinctive colors with the same lightness and saturation; they are highly values by some companies and in arts or for exploring nature and finding interesting isolates).

There are even people that have also a rare mutation of the red chromatic filter, with a second red component: they can distinguish colors even in very dark environements (where the perception of "blue" by most people is fading a lot, keeping only a vision of red-yellow/brown-green shades with the larger wavelengths: in dark environments, the tri-stimuli vision of most people becomes bi-stimuli, and mono-stimuli in very dark environements; but people with an extra red component can still preserve a tri-stimuli vision i.e. a wide gammut comparable to the vision in light environment; this extra red does not change significantly their perception of colors in light environment, except it may sometimes allow them to perceive better separation of greens and yellows/browns)

And don't generalize what you find in the litterature: these are just statistic models of human vision based on averages and most often ignoring the standard deviation (caused by different relatove composition of cells from each type of chromatic filter). As well the distribution of chromatic filters is NOT uniform on the retina (so you may perceive more colors in the center of vision and less in the periphery).

In conclusion: nobody sees the colors the "normal" way, everyone is unique (and the situation evolves negatively across life). That's why the HSL model is very useful, it allows evaluating that there are enough differences. The (s)RGB model here is defective (and in fact it's based on three "base" component colors that actually do not match the real colors of human chormatic filters, which are much more complex in composition than the simple ionic composition of filters used on screens; inks for printing, paintaing or drawing are much more finaly tuned, notably those based on natural components which are also very expensive and not easy to stabilize chemically across time as they are oxydated rapidly, notably the blue components, and the natural green components are oxydized towards reds; the same "oxydation" process also occurs across life in cells of animal retinas, but it is slower because it is protected or renewed by biologic mechanisms).

It's in fact very easy to convert your chosen color palette to HSL and sort colors in a spreadsheet (in L, H, S order, but I bet your colors scheme will already have low differences of "L" once rendered with transparency applied, so the "H" component becomes the most important one), to evaluate the difference between successive rows: you'll see immediately if your colorscheme is accessible enough for most people (even for those rare ones that have a nearly monochromatic vision of the world).

[pantierra]

Yes, I agree that the HSL model will help us much more for finding the best colours. And clearly there are different types of and grades of colour vision deficiency. Over-simplifying the issue: at end it comes down to a reduced sensitivity for the spectrum of colours. And we are having quite some colours for coding the map. I don't see a real way of making all of them visual in a perfect way for a person with colour vision deficiency. However I think we can help people by thinking about grouping the layers and indicating colours to the type of users that are going to make an action on it:

• "Ready to map" and "needs more work" are for mappers.
• "Review needed" and "Mapped" is for validators
• "Validated", "not for mapping" (currently "bad imagery") and "locked" is for nobody.

So, I would try to make these three groups visual for a person with colour vision deficiency. One way of doing this is going with the brightness or lightness (L) of the colours (following the HSL model):

• For mappers: brightest (with white and light grey we are probably on the right path)
• For validators: in between (this needs some refinement on the colours proposed before)
• For nobody: darkest (green and red works actually good here, when grouping)

For assignment and locked, it might be a very good idea to go with icons.

The priority area is really challenging. In the perspective of colour vision deficiency, an icon could be a solution. But then, it seem that the icons start becoming a bit overwhelming, especially when thinking about assigned and locked tasks in a priority area :) The other option could be a coloured layer in between the lightness of the others. Not sure, whether this can be confusing and persons who may have challenges differentiating it from the layer for validators ("mapped" and "review needed"). Thoughts?

For all interested people, there is a browser extension to review a page (and the colours proposed here), similar like a person with different types of colour blindnesses.

[tania-pires]

I' ve done an exercise with color and iconography after all your feedback. Do you think it'll work better that way?

[zlavergne]

I' ve done an exercise with color and iconography after all your feedback. Do you think it'll work better that way?

Priority Area as an icon will cause issues I think. If we show the flag, we can't show the Assigned or Locked icon which are more important because either of those restrictions determine if a user is able to take the task.

I think a good option for Priority Area could be hashing the color @xamanu suggested for priority area. Hashing is a very distinguishable pattern to accomodate color deficiency. Added benefit, a yellow hashing is somewhat universal as "attention" like its use for police tape and other warning signs 🚧

[tania-pires]

@zlavergne I redesigned according to your feedback in order to be possible to compare the two solutions.

[Vaomatua]

The icons will be a good improvement, and the colors look good. I don't quite follow "Not for mapping", isn't everything that isn't a part of the task not for mapping? "More work needed" is a great improvement. I would still like to see the legend be a static image off of the map (sorry if that is in another thread).

[hexiaok]

Please see the proposed map style and layer legends design:

For layer name: --change "not for mapping" to "blocked for mapping", also suggest if we can hide the layer as contributors are not suggested to work on it; --change "locked" to "selected by other mappers", will be easier for users to understand;

I also did colorblind simulation, and I feel the contrast is good enough of the current color scheme:

[willemarcel]

• As I had said earlier, I suggest to remove the project boundary, as it's not a relevant information.
• I think we need a bit more transparency on the tasks layer, and I would put the priority area behind the task layer and not on top of it.
• I don't like the colour of "Blocked for mapping", I think we are driving the attention of the user to the less important tasks.

[jbergmann91]

Can I clarify what the "Blocked for Mapping" and "Assigned to other mapper" functionality is?

[willemarcel]

@jbergmann91 "Blocked for Mapping" corresponds to "Bad imagery". "Assigned to other mapper" is a functionality available only in the Apple instance. Maybe we will have it on other instances in the future.

[pantierra]

I agree with @willemarcel's comments.

And I would prefer to switch the icons, to have the human, for somebody is working on it, and the potentially new functionality using the lock, for reserved (assigned) to a user.

Maybe we can also change the wording from "Review needed" to "More mapping needed". Sounds more welcoming to take on for mappers.

And related to @jbergmann91 question, maybe is "blocked for mapping" also very strong. It is not really blocked, but not good for mapping, either because the imagery is bad at this place, or there might only be an area (like for example a lake or the sea) without any objects. What is a good and short wording we can use here?

[pantierra]

I don't like the colour of "Blocked for mapping", I think we are driving the attention of the user to the less important tasks

Thinking about this a little bit more radical: why do we need a colour? Can't we just exclude them from the tasks? This would be great from a user design perspective! But it has the downside that a task just disappears, after it has been marked as unmapable and can not be brought back easily. Continuing the thought.., we could bring in some approval queue for the project manager to check on tasks that have been marked unmapable to be either deleted or brought back. @hexiaok what do you think?

[verdy-p]

instead of a so dark colouring for "blocked for mapping", I could use a fuzzying ligh grey pattern. Fuzzying however is not as simple to implement as a simpler alpha layer, as it requires complx compositing support (not just 1 pixel over 1 and not so simple to do in CSS, unless the browser has advanced support for "filters", and otherwise it requires a modern browser support for the canvas). An example is shown here using a "blur" filter: https://stackoverflow.com/questions/27583937/how-can-i-make-a-css-glass-blur-effect-work-for-an-overlay

Le mer. 6 nov. 2019 à 22:39, Felix D. notifications@github.com a écrit :

I don't like the colour of "Blocked for mapping", I think we are driving the attention of the user to the less important tasks Thinking about this a little bit more radical: why do we need a colour? Can't we just exclude them from the tasks? This would be great from a user design perspective! But it has the downside what a task marked as unmapable disappears and can not be brought back. Continuing the thought, we could bring in some approval queue for the project manager to check on tasks that have been marked unmapable to be either deleted or brought back... @hexiaok https://github.com/hexiaok what do you think?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/hotosm/tasking-manager/issues/1257?email_source=notifications&email_token=AAKSUG2XGZNGSBCIEVYV4NTQSM2PPA5CNFSM4F7ROLRKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDICM6I#issuecomment-550512249, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAKSUGZ46WSWK7SECZGZDYTQSM2PPANCNFSM4F7ROLRA .

[zlavergne]

Another option could be to make the "blocked for mapping" have half or less of the opacity of the default transparency for a task. It would seemingly disappear without actually being removed in the case of a PM needing to check and revert the status. This wouldn't add additional responsibility on the PM to check a queue to review the tasks.

[zlavergne]

You can read more about the task assignment feature in #1575. One part of it allows PM's to manually assign tasks to individuals but it also will introduce an idea of "project ownership". If a user locks a task, it is then assigned to them whether they finish or not. Either way it is their responsibility to come back and finish the task. This is of course, a setting for the project.

[hexiaok]

Thanks for all the feedback. Here I summarize all the comments here:

1: remove the project boundary Will do 2: more transparency I can adjust a bit and test out more 3: priority area behind the task layer Not sure, we need to highlight the priority area to users? 4: blocked for mapping Maybe we can say “not ready for mapping”? agree the color is a bit too strong, happy to try adding more transparency or trying out some grey pattern 5: switch icons We can try. But again we already use “locked” to indicate the concept of “other mapper is working on the task” existing users might be confused if we change the concept. Btw does a mapper need to know whether it’s “assigned to other mappers” or “selected by other mappers”? in fact they all indicate the mapper can’t choose the task. Can we just use one icon? Perhaps the Project Manager/Admin needs to know the difference? 6: change "Review needed" to "More mapping needed" Sounds good

[pantierra]

After today's user group meeting the following state names have been suggested:

• Available for mapping
• Ready for validation
• More mapping needed
• Finished
• Unavailable
• Locked

[hexiaok]

updates made:

• remove AOI boundary
• add more layer transparency
• change layer style for "Unavailable" (previously "blocked for mapping")
• remove layer "assigned to other mappers"
• update the layer names

also test out using aerial images as the backgroup map

[pantierra]

Thanks for all the input and work @hexiaok and @willemarcel. Happy to confirm that this is part of TM4 (currently in testing phase).