Don't use relative times for Conversations panel timestamps. #2707
Conversation
|
Agree this is a problem, and Session Desktop behavior deviates from other platform behavior too, spoke about this with the team, the approach we settled on was.
We want to implement this cross platform, this is most similar to the iOS approach currently. We can merge this if it conforms to the above rules EDIT: Updated month -> year, previous solution didn't make sense |
This proposal has even more granularity than the one I proposed (which was merely how Telegram does it), so I'm not opposed to it except for one detail: The use of 12- vs. 24-hour clock should be determined by the user's locale, not hard-coded. |
Instead, we move to Telegram-style timestamping: * If the conversation last received a message today, just the time of the message is used, e.g. 12:03. * If the conversation last received a message in the last week, just the day of the message is used, e.g. Mon. * If the conversation last received a message more than a week ago, the date of the message is used, e.g. 13/03/2023.
See oxen-io#2707 (comment) for the discussion. * If the conversation last received a message today, just the time of the message is used, e.g. 12:03. * If the conversation last received a message in the last week, the day and time of the message are used, e.g. Mon 12:03. * If the conversation last received a message this calendar year, the month, day of month and time of the message are used, e.g. Mar 13 12:03. * If the conversation last received a message in a previous calendar year, the date of the message is used, e.g. 13/03/2023.
|
A second commit has now been added to this PR to further modify the timestamps to comply with Kee's spec above. As I suggested, I have left the issue of 12- vs. 24-hour clock to the user's locale.
|
I feel that it's too granular, feels over engineering. Also the month level isn't properly defined, I think you mean the same "year", not the same "month".
Personally I don't like too many levels, two levels including "today" and "everyday before" is enough for me. Three levels (skip the week level) is also fine. The week level is annoying to me, because "Tuesday" doesn't tell me what date is that day and I have to find an external tool to convert it to a YYYY-MM-DD or double check what day is today and do some mental calculation. It's not a big deal if this is the final design already, but at least I think someone like me who doesn't like it should make some voice. |
Indeed. That's how I interpreted the spec, too.
I have posed this question in detail to about half a dozen people now, and no two of them ultimately stated the same preference. This is a highly subjective area. Ideally, the number of levels, the criteria for the boundaries between those levels, and the timestamping for each level would be available as advanced configuration options, hidden from users for whom the defaults are intuitive, but available to users who like to tweak every last aspect of their software experience. More generally, I'd like to see Session adopt an Advanced Configuration checkbox under Settings that allows the bolder user to access and configure any such options that less sophisticated users might find confusing or potentially disruptive. |
As a user I don't mind having Advanced Configuration, but I rarely use them in most daily apps I use. If there is no Advanced Configuration, I am usually fine to sacrifice my preference and accept it. As an open source contributor to the Oxen project, I can understand the dev team might have their opinions on allocating limited development resources, reducing communication overhead, saving code reviewing effort, minimizing future code refactoring costs, etc. I just check Signal and found it doesn't have Advanced Configuration either, which gives an example that the lack of Advanced Configuration doesn't prevent an app from growing to 40 million month active users ;-) Signal do have a few unofficial forks though: https://community.signalusers.org/t/signals-complementary-downstream-projects-please-list-them-here/5093/2 Maybe when Session grows to 40 million month active users, there would be a few unofficial forks for minorities as well. |
Those are all valid considerations, of course. Proper resource and scope management is very important, particularly when one has to operate within tight constraints.
Different people have different needs, tastes and levels of expertise, so different software will appeal to different users. Underpinning most of my PRs is the unabashedly selfish desire to nudge Session in the direction I'd like to see it go. That happens to be more towards the Element and Telegram end of the spectrum in terms of power (i.e. feature set) and flexibility (i.e. configurability) than the Signal end, which I personally find too basic to have a unique use case.
I think that moment may come a lot sooner for Session, as there is a much smaller choice of decentralised, anonymous messengers. In that sense, users like me will naturally seek to mould Session to give us what we desire from it. |
| @@ -48,14 +48,29 @@ export const Timestamp = (props: Props) => { | |||
|
|
|||
| const momentValue = moment(timestamp); | |||
| let dateString: string = ''; | |||
| // Set the locale for the timestamps. | |||
| moment.locale(osLocaleSync().replace(/_/g, '-')); | |||
There was a problem hiding this comment.
I guess that's a blocking call which is a bad idea to have in the renderer side
You should be able to get the locale required by the user (and not just the system one) using:
const lang = (window.i18n as any).getLocale();
There was a problem hiding this comment.
That code will retrieve only the generic language, e.g. en, not the specific locale variant, such as en_gb.
See oxen-io#2707 (comment) for the discussion. * If the conversation last received a message today, just the time of the message is used, e.g. 12:03. * If the conversation last received a message in the last week, the day and time of the message are used, e.g. Mon 12:03. * If the conversation last received a message this calendar year, the month, day of month and time of the message are used, e.g. Mar 13 12:03. * If the conversation last received a message in a previous calendar year, the date of the message is used, e.g. 13/03/2023.
|
Tracking this issue internally for desktop through https://optf.atlassian.net/browse/SES-1101 tasks are present for other platforms as well to make sure the approach is consistent |
|
An update on this, as part of the cross platform strings refactor we are going to allow users to customize how they see dates. Mockups on desktop look like this
With the following options being supported
|
Contributor checklist:
clearnetbranchyarn readyrun passes successfully (more about tests here)Description
I find the conversation panel's timestamps a bit annoying. I don't really like the relative timestamps, i.e. 6 mins ago, 2 months ago, etc.
What does 2 months ago even mean? More than 30 or 31 days? About 60 days? More than 45?
I decided to reimplement these timestamps Telegram-style:
An attempt is made to use the system locale when formatting these.
This could be made into a configurable option under Settings, so that relative or absolute timestamps can be chosen by the user.