Add clearer action reminder in Journalist Interface to enable v3

[eloquence]

As part of the 1.7.0 release, we've agreed that we want to improve our reminder in the Journalist Interface to enable v3 onion services. The current banner looks as follows:

You can also see it on https://demo-journalist.securedrop.org/ after logging in using the dev credentials.

The plan of record is as follows:

• SecureDrop 1.7.0 (released in January) will still fully support v2 onion services
• SecureDrop 1.8.0 (released in February) will support Ubuntu 20.04 (Support for Ubuntu 20.04 (Focal) #4768), and exclusively support v3 onion services for Focal installs, without changing the behavior on Xenial.
• After April 30 (Ubuntu 16.04 EOL), instances not upgraded to Ubuntu 20.04 will self-disable.

In other words, the v3 switch is unavoidable due to the Xenial end-of-life. Our goal with the 1.7.0 release is to get more admins to make the switch prior to a reinstall on Focal, to make the process a bit easier for them. The specific action we need to motivate:

1. If v3 is already enabled, but v2 services are still available: Disable v2 services, ensure that all journalists/admins have v3 creds, and ensure that landing page points to v3 onion.

2. If v3 is not enabled yet: Enable v3 services (can still run them alongside v2 for a bit, per docs, then go v3-only).

We've discussed that this could potentially be done via different banners for 1) and 2) in the Journalist Interface. Let's kick around language/UX a bit in the comments, and I'll add the final agreed upon spec to the top-level issue.

User Story

As an administrator, I want to be reminded of critical actions I must take to keep my instance running, so that I'm not caught by surprise.

[eloquence]

Some initial suggestions re: UX & language:

• I think a more urgent banner color is appropriate in either case.
• For case 1: Action Required: Your SecureDrop servers are still reachable via v2 and v3 onion services. Make sure admins, journalists and sources are using v3 onion services, then disable v2 onion services. [Learn more]
• For case 2: Action Required: You must switch your SecureDrop to v3 onion services to ensure that it is reachable after April 30, 2021. [Learn more]

The omission of "April 30" in case 1 is intentional; IMO here it is most important to emphasize internal action vis-a-vis journalists & sources. Bear in mind that these banners would be swapped out again with the 1.8.0 release a few weeks later, which would emphasize the Ubuntu 20.04 transition and the April 30 deadline.

[ninavizz]

1. Text on the Docs page from the "Learn More" link in the banner, must be updated. The total experience of a user reading the banner, then going to that page, needs to be considered. Recommendations have been made and captured in this issue, as I'm not yet fluent enough with GIT to do a PR.
2. Banner text: Less is more. Keep it simple and on point.
3. Banner color should be Urgent Coral #FF3366.
4. Banner icon: Circle-bang icon in white. Art, in comment below @ 400%
5. A unique link class needs to be created for banners. It's not acceptable to have a blue underline on a link when the rest of the text is white; and all banners should have white hyperlinks/text. Other hyperlink styling should match how it is done elsewhere throughout the app, which I believe is done as a 1px border-bottom w/ padding and reduced opacity.
6. The first H3 after the Migrating from v2 to v3 H2, should be a migration checklist. This will be important for users who receive the second banner, below, so that they can identify what steps they have yet to do.
7. Open Q: the "s" on "Onion Service" vs "Onion Services" is confusing, and I dunno which is semantically correct.

Not started (v2) message

(!) Update Required Your SecureDrop’s server must be updated to v3 onion services by April 30 to remain live. Learn More

Partially done (v2/v3) message

(!) Update Completion Required Steps remain to complete your SecureDrop server’s onion service update. Please notify admin. Learn More

Mox

[ninavizz]

Circle-bang image in mockups is 20x20 @100%. This is a PNG of that at 4x the size, to compensate for pixel density degradation. Note: The PNG is white on transparent, so only shows here as a giant whitespace below the text.

[zenmonkeykstop]

Some nits on replacement text:

• there are 2 servers in an instance so references to server singular are not correct.
• "Please notify admin." doesn't seem grammatically sound.
• "updated to v3 onion services" might scan better as "updated to use v3 onion services"

[zenmonkeykstop]

Core PR #5679 is updated as follows:

• Text on the Docs page from the "Learn More" link in the banner, must be updated. TBD, out of scope for core pr
• Banner text: Less is more. Keep it simple and on point. Updated based on recommended text
• Banner color should be Urgent Coral #FF3366. done
• Banner icon: Circle-bang icon in white. Art, in comment below @ 400%
• A unique link class needs to be created for banners. done by overriding appropriate styles in alert-banner context rather than creating a separate class
• The first H3 after the Migrating from v2 to v3 H2, should be a migration checklist. TBD, out of scope for core pr
• Open Q: the "s" on "Onion Service" vs "Onion Services" is confusing, and I dunno which is semantically correct. there are multiple onion services at play so plural works IMO

[zenmonkeykstop]

Screenshot of the updated banner

:

[ninavizz]

Dang skippy, you fast—TY!! Looks great! :)

Only nit with above mockup: No colon after the bolded text in the message, pls? Read below to see why. It just impedes the user's ability to consume that content as we expect to consume UI messaging. Also, see Material UI's copywriting best practies guide for punctuation advisement (included in this bulleted list on the SD UX wiki). Material UI = Google, so $$$ of research informed its guide.

Some nits on replacement text:

• there are 2 servers in an instance so references to server singular are not correct.
• "Please notify admin." doesn't seem grammatically sound.
• "updated to v3 onion services" might scan better as "updated to use v3 onion services"

UI text is often not grammatically correct per-se, for usability reasons.

It's important to both not butcher the language, while also taking liberties to speak in a fashion more abbreviated than you would in any context other than in contextual product messaging (app UIs, warning/instruction labels on a chainsaw, lathe, or tractor, etc) or road signs. Text composed for people to use while endeavoring a task.

If you spend time in a machine shop or a metal fab studio, a similar pattern for composing text can be observed in most of the on-machine instruction stuff. Especially for welders and gas equipment.

Kind of on par with what we noticed in user testing for Safe Delete, users don't want "filler" words that make things grammatically correct. If they see sentences "correctly" structured, they'll more likely blow an item off as optional prose or feel-good "nice to read" text. So, keeping things terse in UI messaging, is very intentional and important.

All of the above blathering, said—I'd prefer to keep the blurbs spoken to in the last two bullets as they are, for usability?

First bullet, rad catch—I'm NEVER going to get used to that, ty!

[zenmonkeykstop]

That's a good point re instructional text, but this isn't the same context. We're not providing directly relevant instructions/warnings, we're trying to convince users that there's a completely new problem that they have to go and solve somewhere else.

My take on it is: we're looking for users to trust that there is an issue and then to take appropriate steps. To go all in on the machine shop analogy, that trust relationship is implied in the context of, say a manufacturer's info panel on a drill press, but has to be established for ephemeral messaging, like, say, a post-it stuck over the same panel. One big red flag for malicious messaging online is dodgy grammar/spelling (see, for example, most phishing emails, or scam IRS voicemails). If we're going to ask JI users to click a link and go to an external site (which we never do normally), we need to remove as many sources of stress about that choice, and having the banner text not make grammatical sense is a source of stress.

[zenmonkeykstop]

Also see alternate wording based on @eloquence feedback here: #5679 (comment)

[ninavizz]

Kev: I created that analogy on the fly last night, to try and demonstrate a concept. It clearly doesn't match, but we are not trying to "convince" users of anything other than "Things need to be fixed, click here to learn more."

The text I suggested follows UI best practices for notifications text. Period. Nitty grammar and punctuation rules, included. Your security points don't hold up. Security absolutely is relevant, but I am following industry standard rules with my recommendation. Maybe not for open source, but for mainstream software—and for journalists, that's what needs to matter.

Please review the Material guide I suggested, above. It is this context. Users do not think in the detail that you are suggesting. They just don't. Enterprise users, nerdy users, all users.