Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Show last_updated time as well as date in sources list #1563

Open
philmcmahon opened this issue Sep 16, 2022 · 0 comments · May be fixed by guardian/securedrop-client#11
Open

Show last_updated time as well as date in sources list #1563

philmcmahon opened this issue Sep 16, 2022 · 0 comments · May be fixed by guardian/securedrop-client#11
Labels
help wanted Extra attention is needed ux

Comments

@philmcmahon
Copy link
Contributor

Description

This would be a short term improvement pending #538 - it would be helpful to see the time as well as the date in the sources list. Whilst we currently only have the date of last source activity, this is still fairly useful information.

I've noticed that this goes against the guidelines suggested in #332 - are we avoiding showing the time currently because it's not a true 'last updated' timestamp but only refers to the source?

I started having a stab at this (https://github.com/guardian/securedrop-client/tree/show-last-updated-time) but having found the issues above it looks like more discussion would make sense before persevering. Here's what the sources list could look like:

Screenshot 2022-09-16 at 14 07 23

How will this impact SecureDrop users?

Users may assume that the time refers to the 'last activity' rather than 'last source activity' - we could perhaps use a tooltip to make this clearer. I would argue that the existing date could lead to the same confusion, so adding the time would still be an improvement.

How would this affect the SecureDrop Workstation threat model?

User Stories

On the journalist interface we can see e.g. "20 minutes ago"; on the workstation it just shows the date (and not the year). Not having a time is a significant problem in a multi-user workflow because we know when whoever was last on shift did their job. Now we can't see if a "read" post was read during the course of that shift or not.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Extra attention is needed ux
Projects
None yet
3 participants