When to remove labels for data elements?

Question

Removing labels seems to offer a trade off between clarity and concision. For editable forms, labels are necessary, but when should we forgo them when displaying that data back to an end user?

For example, here's a simple form with labels:

If you had a read-only view with labels, you could just disable inputs like this:

But if we present just the data and remove field labels altogether, I don't think we lose much clarity, and most users familiar with american names and address could parse the fields back into their original buckets if need be:

Data with well defined structures that has a well defined mapping to a real world analog seems the least risky, but examples of unadorned read-only data exist all of good design.

Here are two examples of content that is immediately presented without the pretense of a label to suggest how the data must be understood. In both cases, it looks almost silly to try to explicitly name those fields in the path to clarity

Certainly the Content Management System being used to edit articles would provide separate input fields, but the rules feel different for presenting that content to end users. Are there any guidelines as to when we can safely remove field labels without introducing ambiguity?

Answer 1

One way that Steve Schoger from RefacotringUI refers to this is to "think outside the database"

Your UI doesn't need to map one-to-one with your data's fields and values.

Here are a few ideas you can use to present "field: value" data in a more interesting way:

Original

Updated

In the updated example, context drives clarity. Also, the values must be unambiguous when the labels are removed. If there's only a single price or address for a house, you can safely remove labels. But if you needed to differentiate between 'Asking Price' and 'Listing Price', you'd probably need to re-introduce labels

Answer 2

It's going to depend on context. For your address example, separate uneditable text input boxes make sense when you want to show information that can be changed, but don't want users to go back and forth between different viewing and editing pages. So generally, a single address field is only used on summary type pages.

As for your other examples, again, it depends. For example, suppose I don't know what the tags do? The natural place to put a help link or mouse-over popup is on the "Tags:" label. Also, without your "Date Uploaded" label, I would've assumed "Last Modified", which can mean I thought it was more out-date information than it really is.