Create "Empty" state for Conversation/Reply Pane

[ninavizz]

Per discussion with Erik:

2 scenarios,

• Lots of Sources, just none selected
• No Sources at all, a totally blank-slate shiny new Client

Different content or design for the right side of the Client UI? The same? How will these look/work?

[ninavizz]

First rev, ready for review:

https://invis.io/G3RX7IFWYQP

Offline Mode Empty Convo Pane

I personally love the idea of curating a library of "How It All Works" tidbits, to load in rotation (so—one static message per load, but different messages in each load instance). Especially for acclimating users either new to the single-laptop Worksation experience, new to Qubes, and/or new to SD, it seems like a terrific customer education opportunity.

Mockups above just include 1 such tidbit; I'd recommend 2 additional ones, for Beta. Maybe one speaking to printing and saving files from the [Disp-VM] Briefcase, and another speaking to encryption concepts? They need to be very short, as the one included in the mockup is.

Totally Empty Client

...likewise, with nothing to look-at user educational content w/ link-outs seems like a nice idea for the Entirely Empty view.

@creviera will upload the Empty Source List view into Zeplin and tag it as Preliminary, until confirmed by team that this is how we wanna go. :)

[eloquence]

Thanks @ninavizz, a lot of great food for thought here. For now, I recommend that we focus on tightening the MVP language, and then we can kick around ideas for things like interest content, which are unlikely to make it into beta. As always, I think hammering even simple language out will takes us some time, so I'd like to focus the conversation on that to begin with.

I think the Instructional Value prop is actionable as-is as the standard screen to show when no sources are selected. It strikes a good balance of length, and may help users who may not have a good mental model for the application yet. If @creviera and @redshiftzero agree, I think we should line that up for implementation.

I do like the reassuring Everything Works screen for the scenario where no sources have been downloaded yet. However, I do think we have to use somewhat different language:

• The user may have selected offline mode when starting the client, so the part about being connected to the server may not be true.

• I don't think we want to say "since your last server scrub". We don't know if this SecureDrop is brand-new or not (which is one of the most common scenarios in which users will see this screen). Also, "server scrub" sounds ambiguous to me. [To be fair, I acknowledge that during beta we'll probably not be dealing with any brand-new SecureDrops.]

• Although I like how re-assuring "Everything works" sounds, I fear that (especially during a beta) there may be scenarios where it could have the opposite effect. I imagine a situation where the user sees an "Everything works" screen while a Qubes error message is hovering above the client window, or there's some Tor network issue we failed to account for.

How about language along the following lines:

Variant 1:

Nothing to see here.
We have not received any SecureDrop submissions yet.
Last Refresh: 24 minutes ago

Variant 2:

Welcome to SecureDrop!
After the first refresh, you will see submissions from sources on the left.

Rationale: Duplicating the refresh time could be helpful especially in the case where the user is worried that something is wrong. To me, this approximates the goal of "Everything Works" -- confirming to the user that we have in fact performed a successful sync. Thoughts?

[sssoleileraaa]

I think the educational content on startup/ empty screen is an excellent idea. I agree that the Instructional Value prop is actionable for beta and can be used for both online and offline mode. We could even include the tip links at the bottom of the pane as you did here: https://projects.invisionapp.com/share/G3RX7IFWYQP#/screens/362286254

[sssoleileraaa]

Ah, just realized, the Instructional Value prop says that you can retrieve files and send responses, which isn't true for offline mode.

[ninavizz]

@creviera Damn fine catch wrt offline-mode content incompatibility! Will tweek, accordingly, for tomorrow's review.

WRT your comment above, the pages alluded-to with those links don't exist yet, is the thing. :D

I didn't label things "Beta Feasible" or "Post Beta Idea," because I didn't want to taint the first round of feedback or impressions with feasibility stuff—even though feasibility will guide much of what gets into the MVP Beta. If that makes sense.

I love link-outs to educational content, and when that content exists totally want to have those as-appropriate in the Client. It gets tiresome when the same stuff is presented to users over and over again, though, so part of making something like that work is programming a rotation of different things, in—and then governing what users should see, when... how it all works, etc. Not to make things more complex than they should be, but I do at a minimum want some more insight from user needs to guide how such a feature is implemented. A keen eye in the Pilot on what content would be good for users in such articles, and at which stage in their journey with the Workstation it'd be helpful to show them those things, is most of what I wanted everyone to see such a screen for, as a concept at this early stage. If that makes sense?

[ninavizz]

14 May Design Review

• No Source Selected feedback & next steps
  • Consensus that Instructional Value Prop is the direction to pursue.
  • Erik clarified that it actually is accurate in offline mode, and team agreed that offline state changes when a user clicks a Source will accomplish need Allie flagged, above.
  • Nina to refine typography, then post spec to Zeplin.
• No Content feedback & next steps
  • Consensus that helpful tips & articles to read will be nice to program-in, after we learn more about users and have the bandwidth to curate such info properly.
    • Erik: will be interesting to see where users find themselves at a standstill wrt Tor issues or other things, and where else such nuggets for user-ed might be valuable.
  • Lots of concerns around Config Confirmed content
  • Concern around use of word "scrub" and specificity of assuming a server scrub had happened
  • Nina's assumption that everything is cool if a user could sign in, is not correct
  • Other concerns, all enumerated in comments above
  • Consensus that a hybrid of Erik's above suggestions to be mocked-up & submitted for a follow-up review.
  • Uncertainty around use of "Nothing to see here!" language (by Allie and Jen, I think). Nina wary of saying "Welcome" just after a user may have been shown the "Greetings!" salutation at login.
  • The designer will make it work, possibly in an offline/online state; but will target the simplest possible solution, and re-submit for review.

[ninavizz]

No source selected

Updated per asks in last crit, and delivered to Zeplin

[ninavizz]

No content, existing instance

Updated per asks in last crit, and delivered to Zeplin

[ninavizz]

No content, new instance

Updated per asks in last crit, and delivered to Zeplin

Variant 2:

Welcome to SecureDrop!
After the first refresh, you will see submissions from sources on the left.

^ Well, no... not if the server still has nada submissions. 😖
As such, the above screen. Whaddyou think @eloquence?

[eloquence]

Yes, I think the language in the spec works. Note that in this case (new instance) there would not be a "Last Refresh" yet.

I would prefer to avoid introducing "SecureDrop Desktop" until we agree as a team that we want to use that name for the app, and just say "SecureDrop" for now.

(In addition to the potential for confusion, it's possible that even if we choose a name like "SecureDrop Desktop", we may not want to use it except where disambiguation is clearly required. For example, Signal Desktop uses "Signal" in its window title, and only uses "Signal Desktop" in places like "About" and help pages.)