Problem

You must display information, especially text and numerical data, in the most appropriate and recognizable format for the context and the viewer.

The presentation of Ordered Data is largely a matter of design, and can be implemented with any technical means. For many interfaces, such as all web sites, it is important that only the proper data be sent, so this is implemented at the server side. Any level of client software will work equally well.

Solution

Content types that are routinely displayed have become regularized in their display. You have to presented them in specific formats so they are easily recognizable to the users.

The types of data being discussed are, for example:

As well as many others. Some of these may be specific to a population, and be technical terms or jargon only understood by the user community.

A table showing how tabular data (for The Weather Channel mobile web) can be compressed or expanded as space allows. This shows many methods of displaying several types of ordered data.

Variations

The two key challenges you will discover in presenting ordered data are true for all systems, not just mobiles:

User expectations

In many cases, this can go all the way to universally accepted standards for notation. Units of measure, for example, have standards for long and abbreviated display which should always be followed. Many others have cultural norms instead. Dates are displayed in several formats, commonly flipping month and date, without labels to say which is which.

If your product will be employed by users from different backgrounds, try to use unambiguous display methods whenever possible. For dates, avoid abbreviating months as numerals. 4/11 can be April 11th or November 4th, so the only slightly longer "Apr 11" is entirely clear.

Available space

For columnar display in any interface, but a special challenging on many mobile devices, ordered data types like dates may have design pressure to be compressed to the point they can become unreadable. Do not just rely on common sense, but refer to universally understood display standards to assure the compressed format will be readable. Also consider use of variable formatting based on the available size; if a larger device is used, or the screen is rotated, display larger amounts of information.

Interaction Details

This is a presentation pattern, and generally supports no interaction at all.

You may wish to add additional details to explain any ordered data that may be confusing. For example, if a date is very shortened, then a tooltip or some interactive method may present further details. Information can also be optionally presented in multiple formats, for example a date-time code of "Yesterday" can present a tooltip that says "19 March 2011 at 11:21 am."

All normal interactions are available for any of the information presented. A common method is to provide additional information on each line, accessed by the use of a Link, Button or other common method.

Presentation Details

There are far too many of these formats to discuss in detail. Some examples have been provided above. Instead, this space will be used to discuss another method of displaying some content types, relative display. This is most useful for dates and times, but as these are very commonly encountered by many types of systems, are worth detailing.

Relative dates and times use the conventional format users would when in conversation. No one says "I called him at 2:17 pm," when they can say "I called him about five minutes ago." Communicating in natural manners like this reduces cognitive load, making interfaces more usable and speedier.

Timings can change depending on the context, but one example of how to do this is:

  1. Within the current hour, show as minutes ago. Over 20 minutes, round to the nearest five minutes.
  2. Within the current day, or within 8 hours, show the time as number of hours ago.
  3. Within the last two days, shown the day of the week, and the time range, morning, afternoon, evening, night.
  4. Within the past week, show the day of the week.
  5. Older than this, but within 12 months, show as Mmm/DD.
  6. Older than 12 months, show as the year alone.

Examples:

Antipatterns

Do not rely on user settings to solve cultural norm issues. The vast majority of users will not perform such setup. Even if forced, as part of a first-run process, defaults will be used to speed it up. Customization may be allowed, but assure that default conditions are clear and unambiguous.

Do not make up abbreviations. If one does not come to mind, it doesn't mean that it doesn't exist, just that you don't know what it is. Use reference works to find the correct abbreviation. Always find good references, preferably by the governing body of any technical organization, and do not trust hearsay. Street labels in the US, for example, are being rewritten somewhat randomly by local departments and the abbreviation for Lane is now often LA, instead of LN. This sort of change can be confusing.

Do not use default label values without understanding if they have meaning. For another roadway example, many digital mapping services use "Street" as the default type of roadway. However, in many cities saying "Street" means it run the opposite way as an "Avenue." This carries as much meaning as assuming unspecified times of day are "AM."

Don't go overboard with interactive display methods. Avoid interfering with the primary interaction of the display, such as selection of a line item. While tooltips can be helpful, too many can make it difficult to read the rest of the data set.

Next: Tooltip

Discuss & Add

Please do not change content above this line, as it's a perfect match with the printed book. Everything else you want to add goes down here.

Personal Names from Around the World

* http://www.w3.org/International/questions/qa-personal-names from W3C. Guidelines, examples, and how to make forms that make sense for everyone. Good stuff.

Date & Time

Since I started being so conscious of this topic, there have been many examples, but most are pretty specific to the industry or other domain. However, date and time cause no end of trouble.

What with various client groups having their own parochial needs and perceptions, I almost give up on best practices. Instead, let me just tell you about the pitfalls, and why regionalization is an issue.

Time

In the US, we like to pretend that all time is on two, consecutive 12 hour time periods. A few people use "military time." When you see it on your airline ticket or somewhere, you call it that.

But have you ever wondered why every digital clock has a 24-hour time mode, it's not for soldiers. And have you noticed it's just called "24 hour time"? That's because in much of the world they use that (or more often, and like actual soldiers, both). Yes, everyday people use 24 hour clocks. I have seen storefronts in Europe where the hours are listed as 10-18. 10 am to 6 pm, if you can figure it out, and yes it is used as a shorthand in some places, without the need to say "18-hundred hours" or any such silliness.

I don't even want to talk about time zones.

Date

As I write this, my Twitterverse is overloaded with people excited that it's 11/12/13. And then a few hours later, people I follow in the rest of the world mocking us Americans. This drives my Canadian wife absolutely nuts.

There is no standard, but the US is almost alone in abbreviating MM/DD/YY. In other countries, it's mostly DD/MM/YY. So 6/10, June 10th to us Americans is October 6th to everyone else. Without question, immediately. There are other ways to do it, also.

The most unequivocal format is DD Mmm YYYY. Spell the month. Sure, spellings change regionally, but as long as you are in the same alphabet, most abbreviations are at least similar so you can get by. Most everyone in the world can read 10 Jun 2013 properly.

If you have an app, pick up the regional preference for date encoding and use that.

Localization & Regionalization

Much to talk about here, but first and foremost I want to tell you: There is rarely a need for a language or locale picker on mobile. We have enough data from the handset. And I don't just mean by turning on the GPS. The language of the device is, for example, readable by your app or website! That's great stuff. Use it.

More on DTC Formats

Long article, good examples, but confusingly formatted. Absolute pronouncements that are sorta rebutted later in the article. Use with caution. http://uxmovement.com/content/absolute-vs-relative-timestamps-when-to-use-which/?utm_content=bufferb5911&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer

Ordered Data (last edited 2015-05-23 18:42:04 by shoobe01)