Prototype & validate read/unread options for SecureDrop Client

[eloquence]

Clearly indicating read/unread status is a strong candidate for the next major feature to be shipped to SecureDrop Workstation users. Our current specification for this functionality, including potential ways to split it up, can be found here:

freedomofpress/securedrop-client#187

This specification is pretty complete, but it is very much based on a messaging paradigm. It does not map against the current logic on the server, which is:

• shared for all users
• only expresses one state (downloaded vs. not downloaded)
• is limited to messages/files (replies are displayed as read by default in the Journalist Interface, even if authored by someone else)

I believe we need to consider alternatives to the options spelled out in freedomofpress/securedrop-client#187, but also prototype all options more clearly in the context of the current SecureDrop Client design, and validate them with both current and prospective users.

Alternative option: explicit "mark as read" feature with shared read/unread status

Hypothesis: Messenger-like behavior (where looking at things implicitly marks them as read) may not be desirable because glancing at a source is not the same as having reviewed it. An explicit "mark as read" feature integrated in the conversation view may be more appropriate for SecureDrop.

How this could work:

• As a user, I would be able to mark a conversation as read up to (and including) the most recent messages and documents.
• If a conversation includes information more recent than what has been marked as read, it would be marked as bold in the source list. Otherwise, it would not be bold.
• There would be a single shared "marked as read" state for each source, though it could be attributed to the user who marked the source as read.
• If desirable, the "marked as read by Nellie" data could be shown in the conversation view, as well.

Potential upsides:

• All users of the system would be able to use this for a lightweight review workflow, without tags/assignments. Basically, "read" would be synonymous with "dealt with".
• Using a single per-source state simplifies things greatly:
  • We don't have to worry about storing per-user data on the server or the client.
  • We can display this information even when we don't know who is currently using the SecureDrop Client (e.g., offline mode).

Potential downsides:

• Users may be frustrated by having to manually "mark as read", and may forget about it in practice.
• It could be confusing if the read/unread status of a source changes even though the user has not looked at it.
• Forcing users into a different mental model compared to, e.g., Signal may cause friction when using both applications are used at the same time.

[eloquence]

Signal is adding "Mark as unread"; with a shared read/unread flag per source, a similar pattern could be a good way to facilitate lightweight review workflows.

[ninavizz]

Oops, this was completed and implemented, some time ago. :)