New answers tagged

0

One thing not mentioned so far is that any non-white background color makes it very easy to highlight textboxes and some other interactive UI elements (checkboxes, comboboxes, dropboxes, etc), by using white.


176

There is not really a "UX" reason for this—or if there is, it is a very limited one. The actual reason why dialog backgrounds are (by default) some shade of grey is because some designers thought that looked better. In many early operating systems, dialog and window backgrounds were stark white. Obviously they were white on the original Mac OS, since it had ...


16

Because the difference between the font-color and the background-color can cause eye strain and is not optimal. Having black or dark-grey text on a lighter grey background is the easiest for the human eye to read. See this link for a more detailed answer. It tells you when to use brighter fonts with a dark background, and also when not to do this. ...


35

Too much white can cause eye strain, so tints of grey reduce this. There is another ux.se topic which discusses white vs grey backgrounds: Grey versus white background for ease of use and readability/legibility


1

This behaviour does two main jobs: first, it draws attention to your popup / dialog box and second, let's user know that the page behind it (for browsers) it's inactive in this state. And those shadows or overlays are making a pretty good job. Also the colour doesn't matter, you could use white, red, blue etc. as long the UI permits.


3

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


0

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 ...


0

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.


0

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 ...


0

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 ...


1

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.


-4

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,...


1

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 ...


1

The short answer, as mentioned already, is readability: we read from top to bottom, so it follows that textual communication would flow from top to bottom. Some applications, like short, sequential communication (ie, chat) require one to read previous messages for context, in order to understand the most recent comments, hence the use of bottom-appending of ...


123

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 ...


18

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 ...


23

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 ...


35

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, ...



Top 50 recent answers are included