Is OK/NOK better than "fail/success"

Question

My team is discussing how we should indicate, in a logbook, whether a specific action ended with success or not. I started putting it like

timestamp | action name (fail)    | description
timestamp | action name (success) | description

One of the team members suggested replacing fail/success with OK/NOK:

timestamp | first action name (OK)    | description
timestamp | 2nd action name (NOK)     | description

I wouldn't mind such a detail, if he didn't say it would improve readability. I doubt it:

1. OK and NOK correlate to 66 %, so arguably when quickly going through a lot of text, it is probable to confuse NOK for OK. To the contrary, fail has 0 correlation with success.
2. fail has a varying letter height, which success doesn't, making them look very different.

Am I thinking in the right direction? Is there any resource where I can read about such details? I believe something like this should be very well known in the area of cockpit or nuclear power plant control room design.

Answer 1

It appears that the biggest problem is being able to find the status indicators within a large group of text.

Barring some significant technical limitation, I would say your solution should be to display the status of each action in its own column.

This makes your question of exact terminology much less important by

• Reducing the importance of terminology for the sake of visibility
• Providing a clear, easy to scan column that displays the statuses in a consistent location

---

But to actually answer your question, I'd go with the "fail/success" pair without considering the exact context in which you're displaying this information.

Answer 2

If the output is binary (success/fail, OK/NOK, whatever), why not only show a status on the failure state?

timestamp | action name           | description
timestamp | action name           | description
timestamp | action name (FAILED)  | description
timestamp | action name           | description

Edit:

Some comments to the original question have mentioned that the ability to quickly scan and find errors is desired. In that case, I would recommend adding an additional column, but still only displaying failed cases.

For example:

  | timestamp | action name           | description
  | timestamp | action name           | description
! | timestamp | action name (FAILED)  | description
  | timestamp | action name           | description

Answer 3

What you need to examine is the use-case for these terms within the context of the project logbook. I have to guess here but I'd say the logbook is a project management tool - an aid to charting progress or discovering problems/blockers

'NOK' is not a commonly understood term. This means that anyone joining your team for reasons of scale, sickness cover, etc, as well as anyone outside your team auditing the project would need to have this term explained to them. Whereas 'success' and 'fail' make perfect sense to anyone capable of reading English.

If you want to improve the visibility of one or other of the two states then I suggest you look for a non-linguistic solution such as placing a shape next to failed items in the list.

Answer 4

Two things to think about:

In computing, it's common to use failure instead of just fail, because it happens to be the same number of characters as 'success', so in mono-spaced fonts they end up being the same width. (Side note: "warning" is also the same number of characters) In addition to this, some systems (like Linux/Unix) color the words - failure is usually colored red, and success is usually colored green/blue. So in these systems it's not the [dis]similarity of the words, or the fact they have the same character width that helps identify warnings/errors, it's the color that helps identify failures.

Word coloring is one technique I've seen in the aerospace industry, used with actual avionics equipment in cock pits.

The fact that success, failure, and warning are the same length means that the log message will start at the same location on each line. Eg:

timestamp | action | FAILURE | message/description
timestamp | action | WARNING | message/description
timestamp | action | SUCCESS | message/description

Which can help many people with readability. It's easy to ignore the first 3 columns if they're all the same width. And once you've identified failures/warnings, the most important columns for a human is probably the message/description. Action may be important, but if you see the error message you'll usually have a clue about what to do regardless of what action was taking place. Consider this [slightly contrived] counter-example where each status is a different width:

timestamp | action | fail | message/description
timestamp | action | successful | message/description
timestamp | action | warning | message/description

Now think of seeing that with dozens or hundreds of lines - it gets hard figure out where you need to focus your attention. Of course the simple fix there is to pad the status field with spaces, but then you might lull yourself into discerning status based on word width in the status column (which seems to be your current dilemma).

---

At least in the aerospace industry, I've seen the use of "GO/NO-GO" for indicating status. NO-GO can also be represented as NOGO or NGO, which is similar to your NOK. I would argue that this is much more widely known, used, and easy to understand for newcomers. And it assuages the concerns many commenters and some answers have pointed out in the more uncommon "NOT OK"/"NOK".

So I would probably do a bit of everything, if possible - take Andrew Martin's answer and use a symbol, color the letters, and pad spaces so the actual messages that you (as a human) want to read are all lined up. Of course this all depends on what kind of UI/format we're talking about - terminal? text file? rich text file? HTML? etc

Answer 5

You could use pass/fail. This would satisfy the condition of making the words look different, but has the advantage of being the same number of characters.

timestamp | action name (fail) | description
timestamp | action name (pass) | description

Answer 6

As a further consideration, "OK/NOK" is clearly binary and only allows two possibilities. "Success" and "fail" more clearly allows for further possibilities - "warning" has already been described above as a third state, or "could not run" if preconditions are wrong, or "comms error" if the test was started but you couldn't get data back, or... You get the idea.

Answer 7

At a guess, I think your colleague is talking about readability because of verbosity. i.e. he doesn't want the success / fail to make the description harder to read

So why not have just (!) for failures, and nothing for success

timestamp | first action name       | description
timestamp | 2nd action name (!)     | description

This isn't usable for a first-time user as you'd have to explain that. However this is a log file so I wouldn't expect basic users to be looking at it but hopefully any developer should understand this and remember this as soon as they've been told it once.

At least this might get your colleague off NOK and will save you some bytes along the way.

Edit: I've now just spotted this is somewhat similar to @Andrew Martin's answer

Answer 8

I think the reason is psychological and has nothing to do with readability.

A NOK, not-OK, sounds way less harsh then a FAIL, FAILURE or ERROR. It's just a way to not have to use those "negative" words.

In my opinion you should not budge.

Answer 9

I know this thread is old, but in case anyone finds this useful: I don't know where you are from, or what field you work in, but in my field (industrial automation), OK/NOK are a de facto standard in Europe. If your colleague used to work/works in automation, maybe it is just what he is used to. However, I would point out that these are mostly shown on color screens and usually accompanied with green/red color. In a plain text log, I would definitely choose another way, unless the customer specified otherwise. Most likely what Harrison Paine suggested - no text for OK result and whatever you want for Not OK result.

Answer 10

Assuming there aren't any limitations on allowed characters, I always find emojis are great for easy readability of success/failure states, as they're the only way to render something in color within plain text alone:

timestamp | first action name | ✅ | description
timestamp | 2nd action name   | ❌ | description

For better accessibility (color-blindness, screen readers, etc.) it'd be better to include a text alternative too:

timestamp | first action name | ✅ success | description
timestamp | 2nd action name   | ❌ fail    | description

Answer 11

When looking at a log file there are two very important things. First finding the problem (or information) quickly, and being able to search for that 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

Should do that quite nicely. It's important that time-stamp and STATUS are left most. First because it's easier to line up, and second because it's what you care the most about. You start out with a "failure around 6pm". So you scroll to 6pm time stamp and start hunting for a failure.

Next issue is the ability to search log files. No one ever reads /var/log/syslog unless there having a really bad day. Instead they either tail it of grep it. With that in mind you want to have a FAIL and a OK look very different. I prefer -OK- and FAIL. Again this makes line up trivial, but more importantly my eyes can catch the difference between the two if they change rapidly. That is important for tail -f /some/log/file

It also works well with greping cat /some/log/file | grep FAIL will work very well. NOK and OK will not. They will both match "OK".

In short use -OK- and FAIL admins everywhere will appreciate that.

Answer 12

If you're just looking to replace the harshness of "FAIL", I'd suggest GO/NO GO.

In addition to give you a alternative to "success/fail", it gives your meetings a NASA-esque feel to them.

Answer 13

If your output device supports colour, you could colour-code the text in addition to putting a status message next to it. That way, it will be easy to see what was successful and what failed, no matter what actual text is used. You wouldn't have to store the colour information in the log file, but could add it dynamically when the log is displayed (this depends on whether or not your log file is displayed in a text viewer or in a bespoke log viewer).

Remember though that colourblind users may not be able to see red and green clearly, so make sure that there is some way to configure the colours used or offer an alternative black-and-white version (i.e. you still need a status message, not just colours).

Answer 14

YES, it is better than success/fail because success inclines to multiple interpretations.

how would one treat successful cancellation of the operation? is it a fail or success?

i think using pass/fail is more appropriate for boolean states, same as ok/nok.

Answer 15

NOK is definitely confusing. I'd personally go with Ryan's answer (FAILURE/WARNING/SUCCESS), but it's worth to mention another "standard": OK/KO. It's short, they have the same number of characters, it's understandable (KO is clearer than NOK I believe), but it lacks semantics compared to FAILURE/WARNING/SUCCESS.

Update: It seems OK/KO is specific to France, I didn't know that before