What is best way to represent empty value inside table of rows with some optional columns?
'', empty, N/A, -, -------- (number of allowed chars), any other advice?
asked Apr 20, 2011 at 6:04
-
Not completely answering your question, but maybe this question about the default state of a required select box might help you.– LodeCommented Apr 20, 2011 at 19:54
Add a comment
|
8 Answers
Do you want to draw the users attentions to the lack of a value?
If Yes
"N/A" or some kind of graphic in a distinct color would be best.
If No,
You need something that is not visually distracting but is still easy to read.
The "easy to read" part can be tricky. An empty cell or an empty cell with a subtle background color like grey would be my first choice.
The problem you might run into with that is (depending on your design, column with, border, ect), it may make if more difficult to determine which line of data a value is a part of.
A dash or a double dash can be easier to follow visually, thus making it easier for the user to determine which value goes with which row. Row colors and other design tricks can make that a non issue, but it should be considered as an option.
In the end, as usual for this site, the best thing to do would be create multiple mock ups using your current design each with a different "empty" value and do some usability testing to see which one the users 1) find easier to user, 2) like better.
A faded or grayed-out placeholder text could also work pretty well.
What exactly does empty mean to the user? How do you want them to respond? Be as specific as you can be for the user to react appropriately. This interacts with the data type to suggest the best representation.
A Blank
An empty blank is clear enough for most string data types (e.g., names, addresses) and probably dates and times too. This is the preferred representation for just about any data type the user can edit. Depending on your exact graphic design, it can be plenty eye-catching, appearing as a “hole” in an otherwise dense form. However, a blank may be ambiguous for numeric data types, including monetary –users may think blank = nothing = zero. The same can be said for any near-blank representation, such as a dash or dot.
A Hidden Field
If it’s patently obvious to your users the attribute does not apply for the current data object or context (e.g., wingspan for a powerboat), then can simply hide the entire field –both the blank and the label. If it doesn’t exist for the class of object you’re representing, then maybe it doesn’t have to exist in your UI.
“Empty” or “Blank” or “No Answer”
These suggest to the user that someone didn’t provide the data, so these are good choices if that’s why the system doesn’t have a string to show. “No Answer” specifically suggests someone was asked a question (verbal or written) but didn’t answer. “Empty” or “blank” suggest that items in a form were incomplete. All of these are ambiguous on why the data wasn’t entered. Maybe the value was unknown. Maybe it doesn’t apply. But if you don’t know why someone left it blank, then you’ve nothing else to show.
“Not Applicable”
These imply that the attribute the data describes doesn’t apply in the context. This is preferred to simply hiding the field when it’s not obvious to the users, given their background, that the attribute doesn’t apply. For example, in a table listing a banks’ various account options (CDs and such) the interest rate for a Savings Derivative S-Corporation Vehicle may be labeled “Not Applicable” because Savings Derivative S-Corporation Vehicles don’t pay interest –they pay dividends. Not Applicable is commonly abbreviated “N/A,” but spell it out if you have space –some think “N/A” means “no answer,” which is not necessarily what you mean.
“Unk” or “Unknown”
These imply the attribute applies to the context and the data exists but the system doesn’t know what it is, so that’s different than being “Not Applicable.” It’s different from “Blank” or “Empty” in that it doesn’t suggest a human in the loop. Like “Blank” or “Empty,” it doesn’t say why the data is unknown, which may have implications for your users’ responses
More Specific Strings
If you know why the data is unknown, then you may want to indicate that to your users. “Sensor Broken” implies something very different than “Sensor Overloaded,” which means something different than “Unable to Calculate” (e.g., due to divide by zero). Generally, if you can be more specific, then be more specific.
“NaN” or “Null”
Techy. Use only if your users are database administrators or otherwise known to be familiar with the concepts. Don’t expect laypeople to know that Null isn’t the same as zero.
Distinguishing Data from No Data
If you’re using a string such as “No Answer” or “No Signal,” you may need to provide some indication that the string itself is not the data. This normally isn’t an issue with numeric data types –the fact that it’s a string rather than a number makes it clear enough –but it can be ambiguous with string data types. Does “Status: Data Lost” mean the object is in a state of “Data Lost” or that the system lost the data necessary to determine the state?
Surrounding the string with parentheses, braces, or dashes is good enough for most situations. Using alternative font color or style (e.g., italics) can help, but these don’t necessarily tell the user if the data is real or not –just that it’s different. Such graphic coding is best to suggest the user action.
For example, faded gray text suggests users simply skip the field –it’s neither meaningful nor changeable. This may be good for something like “Not Applicable.” Bold red text suggests users must urgently attend to the matter. They need to correct the data or the problem with the source, or they must follow alternative procedures for working without the data. This may be good for various Unknown conditions like “Sensor Broken.”
answered Apr 21, 2011 at 12:42
Cells should be empty in most cases. This makes it easy to quickly see empty cells in a large table. You could choose "—" or "none" or something simliar for aesthetic reasons, but this might add too much visual "noise" if there are a lot of empty cells.
answered Apr 21, 2011 at 2:45
Keep interface as simple as possible not to confuse the user with your icons. Leave it BLANK or just a "-" sign.
Might depend on the data, but as a rule of thumb I'd go with empty. Is the fact that some columns are optional significant?
answered Apr 20, 2011 at 6:16
I've struggled with this as well, but I do not agree with blank area in many cases. In a table, absolutely. But in a listing it raises the question: "Why isn't that data there in this case, but available in some."
I haven't come up with a good phrase, but currently running with "No information available".
This boils down to preference. I use two dashes --
answered Apr 20, 2011 at 18:28
