Replies: 2 comments 2 replies
-
|
Thanks for looking into this and the write up of options, super clear. The feedback you mentioned, where is that from? Keen to understand if this is a one-off or something we've seen more comments about. With that in mind, I'd be inclined to either keep as is (option 1) or bring parity with Dotcom (option 4) depending on what we know re: feedback vs effort. Option 2 and 3 both seem overly complex, with option 3 taking up a lot of screen space and more effort from the user to digest compared to other options. If option 4 is relatively straightforward to implement, I think that's an improvement on the current implementation and seems like best path forward. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for reading through, I appreciate it! 👍
The specific piece of feedback I was referring to came to us via userhelp and central prod, and expressed a preference for abbreviated timezones (option 2) instead of long-form ones (option 3). Although option 1 is the current solution for the old templates, in AR we've started including timezones too. There are some differences in browser implementations that mean these are sometimes short-form and sometimes long-form (more details in #5002), so look like option 2 or 3 depending on the browser. It was investigating this issue that resulted in me writing up this document. I realised we should probably decide whether the approach we'd taken in AR was valid, whether we should revert to the old templates approach, or whether we should be mirroring dotcom. |
Beta Was this translation helpful? Give feedback.
-
|
As a random watcher interested in time and timezones... I had actually always assumed you were doing option 4 without the timezone. I think this is because I knew the UK only has one timezone and there was no indication otherwise. I only started to realise that it might be option 1 years later when the timestamp didn't really make sense with the event so I started to look into what time the event in the article had actually occurred. Option 4 is nice and simple. In some ways it's kind of nice to know what time of day the event happened for people in that area the event happened to without managing offsets and doing the math in my own head for everything. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for taking the time to read through and share your thoughts! That's a really interesting piece of feedback 👍 |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
In response to some user feedback on how we represent datetimes I've been doing some research on dates, times and timezones. I've opened this discussion to present some possible options for how we could represent dates and times on articles in apps, and to ask for feedback on these options. I think this is a question that has content, technical, and design considerations, so I'd be keen to hear thoughts from Editorial, UX/Design, Engineering and Product perspectives.
This discussion covers all the places that we show dates and times on articles, but the most prominent place they occur that I can think of is the publication timestamp near the top of most articles, so I've used that to demonstrate each option. I've attempted to give a few examples of advantages and disadvantages that have occurred to me, but this is definitely not comprehensive and it would be great to hear other perspectives on this!
I'm also not suggesting we have to change the way we currently do things, which is why I've included the current solution as one of the four options. Deciding to stick with it is one of the possible outcomes.
This is also intended to be a discussion about the iOS and Android "live" apps, not Editions, dotcom or AMP. While it's possible any comments or suggestions here could extend to those products, I think any plans for them should be considered a separate topic.
Thank you in advance for any time you spend reading and/or commenting on this discussion, and apologies this initial post is so long! 🙈
Options
1. Local Datetime, No Timezone (Current Solution)
We show dates and times in what we believe to be the user's local timezone, but we don't specify what that timezone is.
This is how the old app templates currently do things.
Advantages and Disadvantages
This is simple to do technically and arguably has the least visual complexity, but it could be considered ambiguous. It may not be clear to the user what timezone they're looking at. It may also be natural to assume the timezone is UK time, or possibly US or Australian time, because these are the countries for which we have editions. This ambiguity could be compounded for regions that span multiple timezones, like the US, Australia and Europe. There may also be a little more complexity than in option 4, so there may be some edge cases that cause problems.
2. Local Datetime, Abbreviated Timezone
We show dates and times in what we believe to be the user's local timezone, and we specify that timezone using a localised, abbreviated format (GMT, EDT, AEDT, CET etc.). See "A Note On Locales" below for more information on how this works.
Advantages and Disadvantages
A user will (hopefully) always see dates and times in their current timezone. They will also know what timezone is being used, unlike in option 1, and the timezone name won't be verbose and take up quite as much space as in option 3. The downside, as described in "A Note On Locales" below, is that some users in some cases may see "GMT-offset" timezones like GMT+1, GMT-5 etc. rather than a localised abbreviation like BST or EDT. As described in option 1, there's also more complexity involved here than in option 4 so there may be some edge cases.
3. Local Datetime, Full Timezone
We show dates and times in what we believe to be the user's local timezone, and we specify that timezone using a localised, long format ("Greenwich Mean Time", "Eastern Daylight Time", "Australian Eastern Daylight Time", "Central European Time" etc.). See "A Note On Locales" below for more information on how this works.
Advantages and Disadvantages
A user will (hopefully) always see dates and times in their current timezone. They will also know what timezone is being used, unlike in option 1, and they won't see "GMT-offset" timezones in some cases, as in option 2. The dates and times will, however, be quite verbose and produce a longer line of text than in the other options. Also, as with options 1 and 2 there may be more complexity than in option 4 so there may be some edge cases.
4. Editionalised Datetime
We show dates and times in one of three timezones corresponding to our editions. These timezones are:
This is the option dotcom currently uses.
Advantages and Disadvantages
In some ways this is simple logically and technically; it means you only ever have one of three timezones, which may limit ambiguity and edge cases. You could argue it also fits the theme of the edition: if you're reading news about the UK, for example, you're seeing when that news broke in a UK timezone. On the other hand it could be considered less helpful for anyone not living in one of those three specific timezones, because they may need to translate these into their current timezone. This is true even within countries; the US, for example, is divided across multiple timezones, some of which are several hours removed from New York (Eastern) time. It will also require a bit more technical work than the other options, as articles in apps don't currently understand different editions (the article endpoint/cache is not split by edition, as other MAPI endpoints are).
A Note On Locales
This is background information for understanding options 2 and 3 above. This is a bit of a deep-dive, so feel free to skip this section. Some of this is interpretation on my part, so if I've got anything wrong please correct me.
Abbreviated Timezones
There are a huge range of localised abbreviations (BST/EDT/AEDT etc.) for timezones, and my assumption is that it's not practical to expect that the average person is familiar with what they all mean. Therefore the internationalisation libraries and databases (Intl in the web world) only specify a subset for each locale (loosely speaking a locale could be thought of as a combination of region and language). What this means practically is that you'll only get localised abbreviations in some timezones for your locale; for others a "GMT-offset" abbreviation is used instead: GMT-5, GMT+10 etc..
For example, if a user has their device set up for English (UK) and they are currently in a UK or European timezone, they will get the localised names of these timezones: GMT/BST/CEST/EET, because it is assumed that a British English user will understand these abbreviations. However if they are in an American or Australian timezone they will instead see a "GMT-offset" format, like GMT-4 or GMT+10, because it is assumed they are not familiar with the localised abbreviations for these regions. Likewise if a user has their device set up for English (AU) and they are in an Australian timezone, they will get AEDT/AWST/ACST etc., but if they're in a European or American timezone they will instead see GMT+1, GMT-5 etc.. See the following table for some more examples (date used is "2022-05-02T00:12:12Z"):
Practically speaking it may be safe to assume that most people, most of the time will be in a timezone that's considered "local" by their device's locale, so these "GMT-offset" timezones should only show up occasionally. However, if that's not a good assumption please let me know!
Long-form Timezones
While using abbreviations is common, the localised timezones also have long-form names ("British Summer Time", "Eastern Daylight Time", "Australian Eastern Daylight Time" etc.). Unlike the abbreviations, the internationalisation libraries and databases don't appear to restrict the usage of these to a subset for each locale. My assumption is that these long-form names are considered descriptive enough that they can be understood by most people regardless of their locale. What this means in practice is that with these long-form names you lose the "GMT-offset" timezones; localised timezone names are available whatever timezone a user is in for any device locale. Here's what this looks like using the same example data from above - note that locale/timezone combinations that previous used "GMT-offset"s now have localised timezone names:
One possible downside in internationalisation terms is that they always appear in English, regardless of the language of the locale (unlike the abbreviations, which include the German MESZ for example). However, our content is in English, so this probably isn't a factor for our purposes.
Beta Was this translation helpful? Give feedback.
All reactions