|Time to display||Past||Future|
|Under a minute||Just now||Right now|
|Under 1 hour||11m ago||In 11m|
|This year||Jan 15||December 23|
|Other years||Jan 15, 2017||Dec 23, 2028|
Address inputs vary widely from country to country. Pega UX recommends the following pattern for the most inclusive workflow.
- If available and the user is online, use the Location Autocomplete component to capture user data.
- Otherwise, if a user's needs are exclusive to a single specific country, find and follow the country standards found on Wikipedia.
- However, a user's needs may span across multiple countries, in which case use the generic template below (source: Wikipedia)
- Country: Fields, labels, and languages may need to change based on this answer, so it must be first.
- City area / District
- City / Town / Village
- Postal code
Finally, all address values should use the standard naming found in the semantic autocomplete attribute spec.
Date and time
Relative times give a general idea of a past or future event. This is the format most common in Pega applications. Examples of usage include conversations or object updates.
Show relative times in the user’s current time zone. The order of dates and months should be valid for that region. Use of 12 hour or 24 hour clock should also be valid for that region.
Exact timestamps are detailed and very technical. Reserve them for things such as audits and detailed histories. Exact times will always include a time, and almost always a date.
If the application will have an international audience, use the ISO-8601 standard (Y-M-D). If the application is for a specific region, use the region appropriate layout (M/D/Y for USA; D/M/Y for most others).If the application is for no particular region, use the American standard (shown) as a default.
|General usage||Dec 31, 2017 2:13pm|
|Audits and logs||2017-12-31 14:13:30|
For internationalized guidance on month abbreviations, Princeton has a decent overview of the variations.