Hot answers tagged tables
Exporting data can be more time consuming Ultimately it depends on how your users feel about it but exporting data requires users to think more and can add friction to their work flow. If I could only choose one option or the other I would go with option 1, however, export to Excel sounds like a very useful function so consider the following example. Show ...
When mixing data units, explicit is better It's very easy to confuse mixed units in a table, so best practice is to make the units explicit. If you can avoid this situation (e.g. using sections or different columns) that is usually better. But sometimes it's unavoidable because of space constraints, or for other reasons. Avoid using icons because it ...
A simple icon can clarify what units are implied in each case. This should solve the problem of the user inadvertently copying the units along with the actual value, and get a quick mental feedback of what's to be expected: EDIT: See Tohster's answer below, which appeals to me as the better solution.
I'm of the mind that you've answered your own question, with a couple of caveats. You have two examples, so effectively you have your own A/B test. If you are already talking to end users and consumers of this data and have garnered their opinion, after you have explained why you believe the second example is better (quick scan overview, simple to download, ...
There are several ways to do this...tailor it to the shape of your data First, don't use the – symbol. In finance and business, the – symbol is often used to represent the number 0, so this could be confusing to users. For most data tables, it's important to present numbers consistently. That means if you have a series of 8's, you should display an 8 in ...
You can add a new column on to the end of this: download bmml source – Wireframes created with Balsamiq Mockups ... wherever the end of those columns are. The user can then try to click that save button squished inside the column header. Or add a column on to this: download bmml source
Your question is not which A or B is better, but: What end user does with provided data and how use it (broder context)? Data is a source for decisions, so you need to know if end user needs to: find a single row to spot an anomaly or analyse particular part (add filters) recognize a pattern or min/max value (add sorting) analyse whole set or local ...
If you are filtering the data 'Date, year and month' wise then you don't need to do anything. Show the user data upfront and let user export it.
Tables and visual noise Based on the example you shared ( Employees/ Location/Salaries) I would say you should move away from the table format which are quite difficult to manipulate and add too much visual noise. Luke Wroblewski wrote this interesting piece about reducing visual noise in tables: The problem is that excessive visual noise and ...
Only top voted, non community-wiki answers of a minimum length are eligible