Differences between revisions 3 and 4
Revision 3 as of 2010-12-01 23:47:26
Size: 1435
Editor: shoobe01
Comment:
Revision 4 as of 2011-01-11 15:24:06
Size: 5005
Editor: shoobe01
Comment:
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
ALSO: Cultural Norms! And just because you are in one country, don't assume everyone is.
== Problem ==
Present text and numerical data in the most appropriate format for the context and viewer.


== Solution ==
Content types that are displayed regularly have become regularized in their display, and must be presented in specific formats to be easily recognizable to users.

The types of data being discussed are:
 * Names (First name first or last? Middle name, initial, or neither?)
 * Times (12 or 24 hours? Are seconds needed?)
 * Dates (Order of items may vary, abbreviations are rampant. In some cases, preceding zeroes may be relevant.)
 * Days of the week (Languages, as well as abbreviations all the way to single letters in some cases.)
 * Locations (City, State then ZIP. But is the state abbreviated conventionally, 2-letters or spelled out. And this is US only.)
 * Units of measure (°F, or °Farenheit, Miles or mi., Kilometers or km, and so on.)
There are many others. Some of these may be specific to a population, and be technical terms or jargon only understood by the user community.


== Variations ==
Two key challenges 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,

Cultural norms, ! And just because you are in one country, don't assume everyone is.
Line 7: Line 30:
Use date as specific examples, but say "there are other types, and maybe special ones for your project. Don't forget to come up with it for these."

 * '''Available space''' - For columnar display in any interface, but especially 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.

It is possible to add additional details to 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. For example, a date-time code of "Yesterday" can present a tooltip that says "19 March 2011 at 11:21 am."


== 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
Line 23: Line 61:
== Problem ==


== Solution ==


== Variations ==


== Interaction Details ==


== Presentation Details ==
Line 39: Line 63:
Do not make up abbreviations. If none comes 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, 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 road 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 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.

Things like dates, and especially how you can adjust it to match space available, because of cultural norms. If not here, then somewhere need to talk about contextually information, how "Yesterday" is almost always better than "23 October 2010." Relative locations also, and make sure those are just examples, and you need to think about data... Look at TWC data density progression table.

Problem

Present text and numerical data in the most appropriate format for the context and viewer.

Solution

Content types that are displayed regularly have become regularized in their display, and must be presented in specific formats to be easily recognizable to users.

The types of data being discussed are:

  • Names (First name first or last? Middle name, initial, or neither?)
  • Times (12 or 24 hours? Are seconds needed?)
  • Dates (Order of items may vary, abbreviations are rampant. In some cases, preceding zeroes may be relevant.)
  • Days of the week (Languages, as well as abbreviations all the way to single letters in some cases.)
  • Locations (City, State then ZIP. But is the state abbreviated conventionally, 2-letters or spelled out. And this is US only.)
  • Units of measure (°F, or °Farenheit, Miles or mi., Kilometers or km, and so on.)

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

Variations

Two key challenges 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,

Cultural norms, ! And just because you are in one country, don't assume everyone is.

Discuss dd-mmm-yy as a good format as it's unambiguous, also. "

  • Available space - For columnar display in any interface, but especially 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.

It is possible to add additional details to 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. For example, a date-time code of "Yesterday" can present a tooltip that says "19 March 2011 at 11:21 am."

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

  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:

  • 20 minutes ago
  • 8 hours ago
  • Tues. morning
  • Tuesday
  • Nov 20
  • 2008

Antipatterns

Do not make up abbreviations. If none comes 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, 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 road 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 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.

Examples

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