Est-ce que OK / NOK est meilleur que "échec / succès"
Mon équipe discute de la façon dont nous devrions indiquer, dans un journal de bord, si une action spécifique s'est terminée avec succès ou non. J'ai commencé à le mettre comme
timestamp | action name (fail) | description
timestamp | action name (success) | description
Un des membres de l'équipe a suggéré de remplacer l'échec/le succès par OK/NOK:
timestamp | first action name (OK) | description
timestamp | 2nd action name (NOK) | description
Cela ne me dérangerait pas un tel détail, s'il ne disait pas que cela améliorerait la lisibilité. J'en doute:
- OK et NOK correspondent à 66%, donc sans doute lorsque vous parcourez rapidement beaucoup de texte, il est probable de confondre NOK pour OK. Au contraire,
faila 0 corrélation avecsuccess. faila une hauteur de lettre variable, ce quesuccessn'a pas, ce qui les rend très différents.
Suis-je en train de penser dans la bonne direction? Y a-t-il une ressource où je peux lire de tels détails? Je crois que quelque chose comme ça devrait être très bien connu dans le domaine de la conception de la cabine de pilotage ou de la centrale nucléaire.
Il semble que le plus gros problème soit de trouver les indicateurs de statut dans un grand groupe de texte.
Sauf limitation technique importante, je dirais que votre solution devrait être de afficher le statut de chaque action dans sa propre colonne.
Cela rend votre question de terminologie exacte beaucoup moins importante
- Réduire l'importance de la terminologie pour la visibilité
- Fournir une colonne claire et facile à analyser qui affiche les statuts dans un emplacement cohérent
Mais pour répondre à votre question, je choisirais la paire "échec/succès" sans tenir compte du contexte exact dans lequel vous affichez ces informations.
Si la sortie est binaire (succès/échec, OK/NOK, peu importe), pourquoi ne pas seulement afficher un état sur l'état d'échec?
timestamp | action name | description
timestamp | action name | description
timestamp | action name (FAILED) | description
timestamp | action name | description
Éditer:
Certains commentaires à la question d'origine ont mentionné que la possibilité de numériser rapidement et de trouver des erreurs est souhaitée. Dans ce cas, je recommanderais d'ajouter une colonne supplémentaire, mais en affichant uniquement les cas ayant échoué.
Par exemple:
| timestamp | action name | description
| timestamp | action name | description
! | timestamp | action name (FAILED) | description
| timestamp | action name | description
Ce que vous devez examiner, c'est le cas d'utilisation de ces termes dans le contexte du journal de bord du projet. Je dois deviner ici, mais je dirais que le journal de bord est un outil de gestion de projet - une aide à la cartographie des progrès ou à la découverte de problèmes/bloqueurs
"NOK" n'est pas un terme communément compris. Cela signifie que toute personne rejoignant votre équipe pour des raisons d'échelle, de couverture maladie, etc., ainsi que toute personne extérieure à votre équipe qui audite le projet devra se faire expliquer ce terme. Alors que "succès" et "échec" sont parfaitement logiques pour quiconque est capable de lire l'anglais.
Si vous souhaitez améliorer la visibilité de l'un ou l'autre des deux états, je vous suggère de rechercher une solution non linguistique telle que placer une forme à côté des éléments ayant échoué dans la liste.
Deux choses à penser:
En informatique, il est courant d'utiliser échec au lieu de simplement échouer, car il se trouve que c'est le même nombre de caractères que 'succès', donc en mono- les polices espacées elles finissent par avoir la même largeur. (Note latérale: "avertissement" est également le même nombre de caractères) En plus de cela, certains systèmes (comme Linux/Unix) colorent les mots - l'échec est généralement coloré en rouge et le succès est généralement coloré en vert/bleu. Donc, dans ces systèmes, ce n'est pas la [dis] similitude des mots, ou le fait qu'ils ont la même largeur de caractère qui aide à identifier les avertissements/erreurs, c'est la couleur qui aide à identifier les échecs.
La coloration des mots est une technique que j'ai vue dans l'industrie aérospatiale, utilisée avec de l'équipement d'avionique réel dans des cockpits.
Le fait que la réussite, l'échec et l'avertissement soient de la même longueur signifie que le message de journal démarrera au même emplacement sur chaque ligne. Par exemple:
timestamp | action | FAILURE | message/description
timestamp | action | WARNING | message/description
timestamp | action | SUCCESS | message/description
Ce qui peut aider de nombreuses personnes à être lisibles. Il est facile d'ignorer les 3 premières colonnes si elles sont toutes de la même largeur. Et une fois que vous avez identifié les échecs/avertissements, les colonnes les plus importantes pour un humain sont probablement le message/la description. L'action peut être importante, mais si vous voyez le message d'erreur, vous aurez généralement une idée de ce qu'il faut faire, quelle que soit l'action en cours. Considérez ce contre-exemple [légèrement artificiel] où chaque état est d'une largeur différente:
timestamp | action | fail | message/description
timestamp | action | successful | message/description
timestamp | action | warning | message/description
Pensez maintenant à voir cela avec des dizaines ou des centaines de lignes - il devient difficile de savoir où vous devez concentrer votre attention. Bien sûr, la solution simple consiste à garnir le champ d'état avec des espaces, mais vous pourriez vous endormir dans un état de discernement basé sur la largeur de Word dans la colonne d'état (ce qui semble être votre dilemme actuel).
Au moins dans l'industrie aérospatiale, j'ai vu l'utilisation de "GO/NO-GO" pour indiquer le statut. NO-GO peut également être représenté comme NOGO ou ONG, ce qui est similaire à votre NOK. Je dirais que c'est beaucoup plus connu, utilisé et facile à comprendre pour les nouveaux arrivants. Et cela apaise les inquiétudes de nombreux commentateurs et certaines réponses ont souligné dans le plus rare "PAS OK"/"NOK".
Donc, je ferais probablement un peu de tout, si possible - prenez Andrew Martin réponse et utilisez un symbole, coloriez les lettres et remplissez les espaces de sorte que les messages réels que vous (en tant qu'humain) souhaitez lire sont tous alignés. Bien sûr, tout dépend du type d'interface/format dont nous parlons - terminal? fichier texte? fichier texte riche? HTML? etc
Vous pouvez utiliser réussite/échec. Cela satisferait à la condition de rendre les mots différents, mais présente l'avantage d'avoir le même nombre de caractères.
timestamp | action name (fail) | description
timestamp | action name (pass) | description
Je sais que ce fil est ancien, mais au cas où quelqu'un trouverait cela utile: je ne sais pas d'où vous venez, ni dans quel domaine vous travaillez, mais dans mon domaine (automatisation industrielle), OK/NOK est une norme de facto dans L'Europe . Si votre collègue travaillait/travaille dans l'automatisation, c'est peut-être juste ce à quoi il est habitué. Cependant, je voudrais souligner que ceux-ci sont principalement affichés sur des écrans couleur et généralement accompagnés de couleur verte/rouge. Dans un journal en texte brut, je choisirais certainement une autre façon, sauf indication contraire du client. Probablement ce que Harrison Paine a suggéré - pas de texte pour le résultat OK et tout ce que vous voulez pour le résultat Pas OK.
Je suppose que votre collègue parle de lisibilité à cause de la verbosité. c'est-à-dire qu'il ne veut pas que le succès/échoue à rendre la description plus difficile à lire
Alors pourquoi ne pas avoir simplement (!) pour les échecs, et rien pour le succès
timestamp | first action name | description
timestamp | 2nd action name (!) | description
Ce n'est pas utilisable pour un nouvel utilisateur car il faudrait l'expliquer. Cependant, il s'agit d'un fichier journal, donc je ne m'attendrais pas à ce que les utilisateurs de base le consultent, mais j'espère que tout développeur devrait le comprendre et s'en souvenir dès qu'il lui aura été dit une fois.
Au moins, cela pourrait éloigner votre collègue de NOK et vous fera économiser quelques octets en cours de route.
Edit : Je viens de repérer ceci est quelque peu similaire à @ la réponse d'Andrew Martin
Je pense que la raison est psychologique et n'a rien à voir avec la lisibilité.
Un NOK, non-OK, semble beaucoup moins sévère qu'un échec, un échec ou une erreur. C'est juste une façon de ne pas avoir à utiliser ces mots "négatifs".
À mon avis, vous ne devriez pas bouger.
En outre, "OK/NOK" est clairement binaire et ne permet que deux possibilités. "Succès" et "échec" permettent plus clairement d'autres possibilités - "avertissement" a déjà été décrit ci-dessus comme un troisième état, ou "n'a pas pu s'exécuter" si les conditions préalables sont incorrectes, ou "erreur de communication" si le test a été lancé mais vous n'a pas pu récupérer les données, ou ... Vous avez l'idée.
Lorsque vous regardez un fichier journal, il y a deux choses très importantes. D'abord trouver rapidement le problème (ou l'information) et pouvoir rechercher cette information.
timestamp STATUS Action Details of the log entry
timestamp STATUS Action Details of the log entry
timestamp STATUS Action Details of the log entry
Devrait le faire très bien. Il est important que l'horodatage et le STATUT restent le plus. D'abord parce qu'il est plus facile de s'aligner, et ensuite parce que c'est ce qui vous intéresse le plus. Vous commencez avec un "échec vers 18h". Vous faites donc défiler jusqu'à 18 heures et commencez à rechercher un échec.
Le problème suivant est la possibilité de rechercher des fichiers journaux. Personne ne lit/var/log/syslog sauf s'il y a une très mauvaise journée. Au lieu de cela, ils le tail le grep le. Dans cet esprit, vous voulez avoir un échec et un look OK très différent. Je préfère -OK- et FAIL. Encore une fois, cela rend l'alignement trivial, mais plus important encore, mes yeux peuvent voir la différence entre les deux s'ils changent rapidement. C'est important pour tail -f /some/log/file
Il fonctionne également bien avec greping cat /some/log/file | grep FAIL fonctionnera très bien. NOK et OK ne le seront pas. Ils correspondent tous les deux à "OK".
En bref -OK- et FAIL les administrateurs de partout apprécieront cela.
Si vous cherchez simplement à remplacer la dureté de "FAIL", je suggère GO/NO GO.
En plus de vous offrir une alternative au "succès/échec", cela donne à vos réunions une impression de NASA.
Si votre périphérique de sortie prend en charge la couleur, vous pouvez coder le texte en couleur en plus de placer un message d'état à côté. De cette façon, il sera facile de voir ce qui a réussi et ce qui a échoué, quel que soit le texte utilisé. Vous n'auriez pas à stocker les informations de couleur dans le fichier journal, mais pourriez les ajouter dynamiquement lorsque le journal est affiché (cela dépend si votre fichier journal est affiché dans une visionneuse de texte ou dans une visionneuse de journal sur mesure).
N'oubliez pas que les utilisateurs daltoniens peuvent ne pas voir clairement le rouge et le vert, alors assurez-vous qu'il existe un moyen de configurer les couleurs utilisées ou d'offrir une version alternative en noir et blanc (c'est-à-dire que vous avez toujours besoin d'un message d'état, pas seulement couleurs).