Last source selected (aka last-seen source)

[sssoleileraaa]

Description

Currently, we do not display a conversation when the client starts up. The desired behavior is to show the last conversation a user was viewing during their last application session. Switching between different accounts and offline mode should not move the user away from what they are currently viewing.

Here I am assuming that the normal use case is for a user to start the application when they begin a session and close it when they finish. The other scenario, which seems less likely with a Qubes setup, is that a user logs out and keeps the application running, allowing other users to share the same session.

Acceptance criteria

Application start: user logs in as A

1. application starts
2. user logs in as A, sees conversation of the last-seen source from A's last session

--

The following is current behavior and should not change...

Application start: offline mode

1. application starts
2. user logs in in offline mode, no source is selected sees conversation of first source in the list

Application start: A's first session or A's last-seen source was deleted by another user

1. application starts
2. user logs in as A, no source is selected sees conversation of the first source in the list

Same application session: offline->A

1. offline user selects source X
2. user logs in as A, sees conversation of last-seen source from same session (source X)

Same application session: A->offline

1. user A selects source X
2. user logs out, continues to see conversation of last-seen source from same session (source X)

Same application session: A->B

1. user A selects source X
2. user logs in as B, continues to see conversation of last-seen source from same session (source X)

[eloquence]

So, @creviera and I chatted about this just now, and where we landed is that pre-selecting a source (based on the previous session or otherwise) is something we may want to avoid for now, until we have a better understanding of our users' expectations. Two main reasons:

• Always enforcing a selection means that, once Highlight sources with unseen source submissions #187 is implemented, we'll sometimes alter "seen" state on submissions that the user may not have an active intent to look at. That seems problematic, especially since it's not planned to let the user reset that state.

• While there may be benefits in dropping the user in the same conversation they were last in (it can be hard to remember codenames!), there may also be drawbacks. Users may not expect this behavior, and it may result in information being displayed on the screen that the user does not want to display (e.g., they want to show a source to a colleague who does not have access to SecureDrop, and it loads up another source they'd rather prefer to keep private).

If that reasoning makes sense to everyone else, we'd like to request Nina's help with two designs:

1. minimalist conversation view content for "no source selected"
2. minimalist conversation view content for "no source exists yet"

If we can agree on design for those cases that's easy to implement, that may be a better first pass than attempting to guess at the right selection logic. Besides, there's no way around doing a design for 2) (otherwise you just have two blank rectangles for an empty SecureDrop), so we might as well do one for 1) using similar design language. Thoughts?

[sssoleileraaa]

I would just like to add that this is current behavior of the application:

Same application session: offline->A

offline user selects source X
user logs in as A, sees conversation of last-seen source from same session (source X)

Same application session: A->offline

user A selects source X
user logs out, continues to see conversation of last-seen source from same session (source X)

Same application session: A->B

user A selects source X
user logs in as B, continues to see conversation of last-seen source from same session (source X)

So, as long as the instance of the application is the same, we currently don't un-select a source when a user logs out and logs back in as a different user.

[ninavizz]

Guys, I strongly disagree with that direction. I'm fine mocking-up the requested states—but the pattern of opening a client with the last selected item showing as selected, is an established standard. There's enough with this app that is not standard, to risk questioning established/solid interaction patterns. We also observed the opposite in testing. With many participants.

I also feel it's grasping at straws to suggest that a user might accidentally click on a Source w/o intending to read its submission. Users appear to be very, very intentional in their choices with reviewing sources.

[ninavizz]

P.S.: Showing a resolved "Empty State" when there's no content to select (as was created in the most recent pass on Briefcase), is a standard pattern—and, ya, is something I agree we need, that just hadn't popped-up onto my radar, yet. I'll create tickets for both requested mox, for the next sprint—if that's ok. If they're needed immediately, pls to let me know... tho I'd again, I'd rather not go with the newly suggested "no-selection on-open" pattern.

[eloquence]

We have the UX sprint review tomorrow; let's prioritize reviewing completed work, but we may be able to use some of the time to come to agreement on this. I don't think that'll be very hard, but I want to be sure we're all on the same page as to what questions we need to answer, and what data and evidence we have in support of answering them.

I see three questions we need to answer:

• Should we track last-selected data and use it for signed in users where possible? As I understand it, that's mainly what you're responding to above with an emphatic "yes" :)

• Should we, when we have no last-selected data (because the user is new, or because they're in offline mode), auto-select the most recent source, or select no source instead?

• How should we handle the "no sources are known to the client" state (no sources on server, or client has never sync'd)?

Let's discuss our understanding of the data & evidence together re: these questions, and then make a pragmatic decision as to what to implement in the next sprint or soon after.

[sssoleileraaa]

Update

After talks...

When there is no last-seen data, we will use a placeholder that @ninavizz will provide instead of showing the first source in the list. This has been moved out of this Issue's scope to here: #340

For this issue, the focus will be on showing the last-seen source when a user first logs into the application. See acceptance criteria above with the small update that we will not select first source but rather leave this as is (blank, no source selected).

[sssoleileraaa]

is showing the last-seen source when a user first logs into the application still a feature we want? seems like this is no longer desirable behavior.

[eloquence]

IMO we can close this. I suspect that "filter by codename" really gets us most of what we want here anyway, to quickly get back to a source you remember by its designation.