I have a table where there might be two values in one cell, what is the best practice to display this? With a comma or line break or something else? Unfortunately the values are quite long, and I believe is it rather important to let the user see both values, i.e. there cant be any hiding.
Having two values in one cell means that presumably you have to differentiate the two pieces of data. Differentiating them by being either side of a comma may not make them noticeable if the values themselves may be quite long, so you need an alternative approach.
Unfortunately though, this often means having a primary and secondary item which may not be what you want. Some options may be more or less helpful if either one of the items may be present but not the other.
- use font style (e.g. colour or weight) to distinguish the two
- use a background colour (not too bright!) and divide the cell into two equal portions left/right or top/bottom
- use position and justify them left and right, or align them top and bottom
- notionally divide the cell into two using a faint dividing line that doesn't reach the full extent of the cell (horz or vert)
- use brackets around the second item if, for example, it's a conversion or differentiator that is related to the first item
- use a discrete icon or glyph to prefix each items
- use a forward slash if the indication is that either the first or the second item is usable
- use some other symbol to imply the relationship between the two items
Within that last option might lie a clue as to your answer:
- What is the relationship between the two items, if any
- How do you want to represent that relationship to the user
Use some mechanism that doesn't just present the two items but helps to add value to the user by indicating their meaning, their equality, their relationship, or how it matters that there are two items in the cell.
To be honest I don't think we can answer the question without...
- making lots of assumptions
- speculating about possible use cases
- presenting lots of options that may or may not be relevant
...like I have probably done here.
I do not want to argue with those who say "You should rethink your tables". I have lots of tables that have fields whose contents are ... lists!
If you ever work with postGIS or any geographic database you will find many examples of list data stored in fields (polygons are stored as lists of coordinates). You can also have "lists of things" in selection forms. I even have "lists of lists" in some web applications.
Yes, list management is a nuisance, but ... why not? There's no much difference with lists generated dynamically from tables and is great for static values or values that don't change often.
This is an example of selection form with plenty of lists.
This another example contains lists of lists.
You may populate the "select" control with data from a table, and store the resulting CSV straight away. Fast and easy.