Un membre aveugle de notre équipe

Mon équipe s'appuie beaucoup sur la couleur dans notre code pour décrire les fonctionnalités sur lesquelles il faut travailler (nous colorions les lignes de code qui nécessitent de l'attention). Nous avons un ami proche qui est daltonien et souhaite rejoindre notre équipe. Que pouvons-nous faire pour mettre en évidence les besoins qui fonctionnent sans utiliser de couleur? Nous avons environ 25 personnes dans l'équipe qui sont toutes habituées au système de coloration des lignes et nous l'avons trouvé le plus efficace.

Montrez-lui les couleurs que vous utilisez pour mettre en évidence le code et demandez-lui de vous dire lesquelles il ne peut pas distinguer.

Puis changez ces couleurs avec celles avec lesquelles il peut travailler.

L'un des développeurs avec qui je collabore régulièrement est daltonien. Le problème n'est pas seulement qu'il ne peut pas distinguer les couleurs, mais aussi qu'il n'a pas tendance à beaucoup penser à la couleur. Lui et d'autres personnes daltoniennes apprennent à en faire une non-question au point que la couleur, même si elles peuvent se distinguer, devient un mauvais outil pour distinguer les choses. Nous parlions il y a un peu des jeux Xbox - certains jeux mal écrits distinguent les boutons sur lesquels appuyer uniquement par couleur. Même s'ils choisissent des couleurs qu'il peut distinguer, son cerveau n'est pas configuré pour prêter attention à la couleur et la différencier.

Votre système actuel est en panne . Il n'y a pas deux façons à ce sujet. Si son daltonisme soulève même une question sur son travail avec vous, il y a quelque chose de terriblement mal. Peut-être qu'il apprend à travailler avec lui (mon ami devra vérifier les couleurs avec nous s'il fait du travail de conception visuelle, par exemple), mais cela ne devrait pas du tout être pris en compte dans la prise de décision. Il peut également être une ressource extrêmement précieuse dans le développement d'applications accessibles en vous aidant à les vérifier très facilement.

Mis à part mon ami daltonien, l'un des grands projets de conception que j'avais à l'université était une application très visuelle pour un client daltonien. Nous ne le considérions pas comme une limitation, mais plutôt comme une opportunité d'apprendre. Nous avons trouvé un outil génial appelé Vischeck qui simulait ce que les personnes daltoniennes voient (toutes sortes différentes). C'est une bonne chose d'apprendre ces techniques maintenant avec votre ami qui va probablement simplement rouler avec pendant que vous montez à bord. Si vous attendez d'avoir un candidat que vous ne pouvez pas embaucher simplement parce qu'il ne peut pas voir les mêmes couleurs que vous (cela ne vous semble-t-il pas ridiculement ridicule?), Vous allez vous mettre dans toutes sortes des ennuis.

Maintenant, cela ne veut pas dire que vous devez supprimer les couleurs. S'ils travaillent pour vous, tant mieux. Ne faites pas d'eux la principale méthode de diffusion des informations au sein de l'équipe, faites-en une aide supplémentaire supplémentaire. Pensez à la coloration syntaxique dans un éditeur de code. Le code est parfaitement lisible sans lui. Même quelqu'un qui ne se soucie pas du tout de la couleur peut utiliser l'éditeur sans aucun problème. Les couleurs sont là pour la commodité des personnes qui les utiliseront, rien de plus.

Je ne suis pas un avocat ou un professionnel des ressources humaines mais cette citation: "avec une équipe d'environ 25 personnes, il n'est pas pratique de mettre en œuvre un système complètement différent" soulève des drapeaux rouges avec les règles de l'ADA.

À moins que la vue en couleur ne soit une exigence spécifique de l'emploi, vous ne pouvez pas discriminer le handicap du daltonisme et vous devez faire des aménagements raisonnables pour lui permettre de travailler. L'impraticabilité n'est pas un moyen de défense dans un procès pour discrimination, bien que je répète encore une fois que je ne suis pas avocat.

Quelque chose de simple comme rendre les couleurs configurables suffirait, les options d'affichage configurables sont juste du bon sens.

Du son. Forme. Police de caractère. Style. Taille. Commentaires texte.

Vous ne pouvez pas y penser par vous-même? Si vous ne pouvez pas trouver d'alternatives, pourquoi quelqu'un veut-il travailler avec vous?

(Oui. Son. Il existe de nombreux lecteurs d'écran et appareils adaptatifs pour les aveugles. Nombreux. Vous n'en avez pas trouvé un seul? Vraiment?)

Qu'est-il arrivé à laisser des commentaires utiles? Vraiment, je pense que laisser des commentaires comme "cela nécessite un peu de travail", "cela devrait être refactorisé", "à mettre en œuvre", ou "complètement cassé ici, réparer immédiatement" serait beaucoup plus efficace qu'un schéma de couleurs fou . Les commentaires écrits peuvent être immédiatement compris par n'importe qui (même un aveugle, s'il a un lecteur d'écran). En outre, vous pouvez le faire dans un éditeur de texte normal et non dans un outil interne que le nouveau gars devrait apprendre à utiliser.

Cette personne est-elle complètement daltonienne? C'est très rare; la plupart des cas de daltonisme sont plutôt spécifiques, c'est-à-dire que le rouge et le vert se ressemblent, mais toutes les autres couleurs fonctionnent. Vous pouvez sélectionner un ensemble de couleurs sans ambiguïté, même pour des types spécifiques de daltonisme (éventuellement même plusieurs types).

Alternativement, les couleurs pourraient être complétées par des symboles simples (comment ajouter de la couleur aux fichiers texte de toute façon?)

Vous devez utiliser un balisage sémantique plutôt que des lignes à colorier.
Le moyen le plus simple serait d'utiliser HTML:

doFoo();
<span class="refactor">doUgglyThing();</span>
doBar();
doBaz();
<span class="debug">makeBug();</span>

Et puis vous lui laissez adapter la feuille de style en fonction de ses besoins. C'est également purement textuel, il convient donc au contrôle de version.
Si vous êtes prêt à investir un peu de temps, vous pouvez simplement créer un petit éditeur HTML léger en JavaScript pour le faire pour vous.
Ou utilisez des commentaires pour mettre en évidence différentes sections, puis rédigez un petit outil d'affichage qui vous permet de personnaliser les formats. C'est probablement la meilleure option, car cela signifie que toutes ces informations sont directement dans votre base de code et qu'elles peuvent toutes être conservées en un seul endroit. Quelque chose comme:

doFoo();
doUgglyThing();//REFACTOR
doBar();
doBaz();
makeBug();//DEBUG

Enfin, une option prête à l'emploi serait d'utiliser un éditeur de texte sémantique tel qu'Ulysse . Vous pouvez baliser et marquer différents types de sections et attribuer des formats aux types de section. Vous pouvez également commenter différentes sections, etc. Il a également un exportateur HTML (entre autres), il est donc tout à fait approprié pour écrire de la documentation.

Ajoutez un système supplémentaire qui transmet les mêmes informations que celles fournies par votre utilisation de la couleur.

Cela pourrait être:

1. Symboles.
2. Taille
3. Emplacement.

Ou tout autre chose, vraiment. Cependant, le problème troublant ici est que vous semblez penser que ceux-ci constituent un "système complètement différent" - ce n'est pas le cas - vos utilisateurs existants peuvent choisir de les ignorer complètement et de s'appuyer sur les couleurs, s'ils le souhaitent.

Attribuez à chaque tâche un rang numérique et conservez la liste triée.

Rank  Description
--------------------------------------------------------------------------
1     Find a way to make our task list readable by the new guy
3     Gain some rep by asking a question on Programmers
9     Convince the manager that 25-people team might need an issue tracker

Tard dans la soirée, mais: Color Oracle est un programme qui s'exécute sur votre ordinateur et fait ressembler votre bureau à une personne atteinte de l'un des différents types de daltonisme. Exécutez-le avec votre IDE ouvert et ajustez les couleurs que vous utilisez pour diverses choses. Très peu de personnes sont totalement daltoniennes, dans le sens où elles ne peuvent percevoir aucune différence de couleur; vous pourriez être en mesure de choisir un ensemble de couleurs qui fonctionne pour cette personne et pour votre équipe.

La chose la plus simple serait probablement de prendre quelques heures et d'ajouter un nouveau symbole pour chaque couleur (lik3 # avec du rouge; @@ pour le bleu, etc.) et de le mettre dans une ligne de commentaire près du texte en couleur. De cette façon, la personne daltonienne peut simplement rechercher tous # et trouver toutes les lignes rouges. Il ne peut pas numériser une page et faire sauter la couleur sur lui, mais il y a peu d'informations textuelles qui pourraient le faire de toute façon (la couleur est vraiment une expérience sensorielle puissante pour les humains).

Mais je suis d'accord que vous devriez probablement commencer la transition vers un outil de suivi des problèmes; on dirait que vous avez bricolé quelque chose de potentiellement inefficace (même si bien sûr je n'ai pas vu ce que vous avez).

C'est une évidence, mais vraiment, ne vous fiez pas beaucoup à la couleur, à votre code.

Et en général, ne comptez pas sur un système d'édition obligatoire.
(un IDE peut être tolérable, mais seulement avec suffisamment de compromis en termes de productivité)

L'établissement d'une convention d'indentation appropriée est déjà assez difficile, prend du temps, est une question de querelles et une source de mécontentement. La couleur obligatoire obligerait la plupart des gens que je connais à monter les barricades .

D'après les commentaires, je constate que vous utilisez un outil que vous avez développé en interne. Cela étant, la solution est simple. Parcourez le code ligne par ligne et marquez chaque ligne qui affecte la façon dont le code est affiché comme nécessitant une amélioration significative. Ensuite, corrigez votre code . La valeur que votre outil fournit n'est pas dans le jeu de couleurs particulier que vous avez choisi ou même que toute l'équipe utilise actuellement un jeu de couleurs. La valeur est que vous pouvez marquer le code de manière significative. La façon dont ce sens est représenté devrait être entièrement configurable. Considérez le travail comme une opportunité bienvenue pour améliorer votre produit.