oxen-io
Don't use relative times for Conversations panel timestamps.
Contributor checklist:
- [x] My commits are in nice logical chunks with good commit messages
- [x] My changes are rebased on the latest
clearnetbranch - [x] A
yarn readyrun passes successfully (more about tests here) - [x] My changes are ready to be shipped to users
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:
- If the conversation last received a message today, just the time of the message is given, e.g. 12:03.
- If the conversation last received a message in the last week, just the day of the message is given, e.g. Mon.
- If the conversation last received a message more than a week ago, the date of the message is given, e.g. 13/03/2023.
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.
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.
- If the message was sent/received on the same day we show: 12 hour time + am/pm
- 12:43 pm
- If the message was sent/received in the same week we show: word abbreviation day of week + 12 hour time + am/pm
- Tue 12:34 pm
- If the message was sent/received in the same year we show, word abbreviation of month, date (day) and 12 hour time + am/pm
- Mar 7 12:34 pm
- If the message was sent or received outside of the current year, then we show dd/mm/yy
- 07/03/23
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
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.
If the message was sent/received on the same day we show: 12 hour time + am/pm
- 12:43 pm
If the message was sent/received in the same week we show: word abbreviation day of week + 12 hour time + am/pm
- Tue 12:34 pm
If the message was sent/received in the same month we show, word abbreviation of month, date (day) and 12 hour time + am/pm
- Mar 7 12:34 pm
If the message was sent or received outside of the current year, then we show dd/mm/yy
- 07/03/23
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.
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.
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.
If the message was sent/received on the same day we show: 12 hour time + am/pm
- 12:43 pm
If the message was sent/received in the same week we show: word abbreviation day of week + 12 hour time + am/pm
- Tue 12:34 pm
If the message was sent/received in the same month we show, word abbreviation of month, date (day) and 12 hour time + am/pm
- Mar 7 12:34 pm
If the message was sent or received outside of the current year, then we show dd/mm/yy
- 07/03/23
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
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".
If the message was sent/received in the same month we show, word abbreviation of month, date (day) and 12 hour time + am/pm
- Mar 7 12:34 pm
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.
Also the month level isn't properly defined, I think you mean the same "year", not the same "month".
Indeed. That's how I interpreted the spec, too.
Personally I don't like too many levels, two levels including "today" and "everyday before" is enough for me. 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.
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.
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.
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.
Those are all valid considerations, of course. Proper resource and scope management is very important, particularly when one has to operate within tight constraints.
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 ;-)
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.
Maybe when Session grows to 40 million month active users, there would be a few unofficial forks for minorities as well.
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.
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