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.)

[ninavizz]

@eloquence Why wouldn't it have a "Last Refresh?"

• This is only before the first Source submission comes in, correct? That could be days or weeks after an Instance is installed—especially if there's no advertising ahead of time, double-especially if a newsroom never advertises their landing page and just keeps it buried as a link on a "Tips" page.
• After the first source submission it'd go to the other two screens.
• For many journalists logging in to check one instance (and potentially more than one Workstation across timezone), it especially feels important to distinguish between "The SecureDrop still has new car smell!" and "Cool, just like new again!" in empty state content.
• Beyond the empty state, some of this content might also be nice to show new users in an overlay, the first time they sign into the client... but that's post-Beta experiential chinrubbing.

Ok re: the app name, for this screen (and for now)—but I want to reiterate that this is a very different setup than Signal, Slack, other SaaS products, or POP3 or SMS or other messaging services. Yes, interaction patterns within the client draw from and speak to all those experiences... but this ecosystem is its own beast w/o common, analogous real world examples.

Slack, Signal, GMail, et al each run off a global server that users need never be concerned with, and with SecureDrop there is the app Server, at least one Workstation, and each Workstation has a client (in a world w/o the web UIs). The Landing Page, the Source UI, the Transfer USB—SecureDrop is an ecosystem of touchpoints. Each will need to be able to be spoken to with clarity and specificity in both user guide(s), docs, in UI messaging, and in help content.

In Slack, you and I are DM'ing and I know your experience is identical to mine. That won't be the case with a journalist needing to understand or speak to a Source's experience with SD, as one example of how this is truly more of an ecosystem than other analogous messaging apps.

SecureDrop also has multiple users on one side of the experiential fence (the newsroom), all working from/with a shared data-set. This adds another layer of subtle complexity into the messaging and documentation wrt clearly speaking to how things work in the context of time, other humans, and other touchpoints.

"Client" is alienating jargon to people outside of IT and dev, yet this touchpoint needs to be clearly spoken to as named something that I agree, cannot be a distraction or a dilution of the SecureDrop brand.

I don't want to rush into the naming exercise to just "get it done" hastily, but also don't want to endlessly punt on it. It has been my experience in many, many years of doing this, that it will bite us in the ass when writing user-friendly help and documentation text, at some point.

Oh, shit. Sprint planning is in (gulp) 9.5hrs. I should go to bed!

[ninavizz]

...ok, also created: https://zpl.io/bzqGPnE

I feel a follow-up design review would be helpful to clearly ascertain appropriate messaging, now that there are 4 versions of an "Empty State." For said review it'd be helpful for everyone to gather and to step-through the 4 different versions from Login thru the landed-upon screen.

If there's not enough value in having unique content on a "New Instance" empty pane vs the "Old instance, clean server" empty pane, I question having the distinct screen at all. Especially before gathering data from the field in the Pilot.

[eloquence]

My assumption was that the "Welcome" screen would appear only until the first refresh, but upon reflection I think you're right that this is overcomplicating things, and may even be jarring (if you only see that screen for a few minutes or even seconds).

I like your new alt screen as one that could cover both cases: first run of the client (new instance or not), and refresh-but-no-submissions. If it's a first run, we'd just omit the "Last Refresh:" bit.

I feel like it could use a generic headline ("No submissions yet" or similar) and some tightening of the verbiage, but otherwise it LGTM.

I hear you on the naming issue. I am in favor of some disambiguation, and I personally think something generic like SecureDrop Desktop or SecureDrop Journalist App is the way to go. Just want to make sure we have agreement on that before we put it into the specs; we can touch base on it in future Client Syncs.

[ninavizz]

I hear you on the naming issue. I am in favor of some disambiguation, and I personally think something generic like SecureDrop Desktop or SecureDrop Journalist App is the way to go. Just want to make sure we have agreement on that before we put it into the specs; we can touch base on it in future Client Syncs.

Yeah, my bad including a proposed client name in what in my mind was just a mockup—and not yet a spec. I'd rather not rush the conversation though, and think it'd be a better conversation to have once we're a little further along in developing the experience and have clearer ideas around documentation. Yes, there's a lot of reasons why some names may or may not work better than others, and generic-ness is certainly one of them.

I like your new alt screen as one that could cover both cases: first run of the client (new instance or not), and refresh-but-no-submissions. If it's a first run, we'd just omit the "Last Refresh:" bit.

I feel like it could use a generic headline ("No submissions yet" or similar) and some tightening of the verbiage, but otherwise it LGTM.

1. Why would we omit "Last Refresh" when what seems like an accurate reflection of that would be Just Now? (assuming that is an item that's part of the Humanize library, @creviera?)

2. Headline/Tightening comments, roger that!

[eloquence]

Why would we omit "Last Refresh" when what seems like an accurate reflection of that would be Just Now?

To clarify, my assumption is that the "Last Refresh: Just Now" would be shown when that is true, but not until it is (i.e. not until the client has completed the first-ever refresh operation).

[ninavizz]

Whaddya think of this @eloquence? 2 states on the "Refresh" bit, either "in progress" or "static."

[eloquence]

Looks good to me! (We'd still want to hide "Refresh in progress" in offline mode.)

Might still be worth doing a bit of wordsmithing on this "This is where .." bit, as it may not be entirely clear what "This" refers to in this sentence ("the left"?"). But I'd be OK leaving that for subsequent iterations.

[ninavizz]

Agreed wrt ambiguity on the word "this" in the above context. Would love to get suggestions, and would like to get final content ideas in this ticket before closing. w00t!

Thx for the call-out on offline mode req, will include that in final spec!

[ninavizz]

10 Jun Design Review

• Decided upon consolidated direction
• Decided to omit dynamic elements (so, timestamp or refresh progress indication) from screen users expect to be static

Updated Zeplin

• No Submissions
  • https://zpl.io/bz6W9jM « Signed-into Zeplin, shows CSS
  • https://scene.zeplin.io/project/5c807ea562f734bd2756b243/screen/5cfe9244f033df15f09e72ec « No sign-in req'd, but also no CSS

Source submissions will be listed to the left, once downloaded and decrypted.
This is where you will read messages, reply to sources, and work with files.

• No Source Selected
  • https://zpl.io/Vqv0vwJ « Signed-into Zeplin, shows CSS
  • https://scene.zeplin.io/project/5c807ea562f734bd2756b243/screen/5ceed1e215e53e1b4487ba40 « No sign-in req'd, but also no CSS

Select a source from the list, to:
• Read a conversation 
• View or retrieve files 
• Send a response