SI Redesign: Phase One

[ninavizz]

This is a child-epic to the parent epic #6210

Introduction

This epic has been assembled to create the neatest-possible artifact to push as a Feature Branch into a first phase of user testing. Outputs from this Epic will not need immediate L10 work, nor change-management stuff with customers. One or two customers will need to be sourced to run a branch of this as their SD instance, per the Phase One Research Plan.

Acceptance Criteria

A functional branch created that reflects all of the changes shown in the Frankenstein E prototype, from which the Phase One Research Plan was drafted.

Please go into the corresponding Figma file to look at details such as hex values, padding/positioning particulars, components, etc. If you're new to Figma with SecureDrop, so are all of us—here's your guide! Because pixel-perfect matching (within reason) is the goal, it is my ask that folks not try to "eyeball" things—and make the effort to look at values in the "Inspect" panel w/in Figma. 🙏🏻

Stuff

This section is broken-out into three distinct categories of stuff. Page layouts for the Flow Inversion will be much easier to do, once the earlier of the Design System items have been tackled. Et Cetera are quick-win items neither dependent upon the broader design system, nor inverting the Generate/Submit flow.

• Design System
• Flow Inversion
• Et Cetera

Design System

Colors, typography, icons—aesthetic things. Mostly CSS, but some HTML to adapt layouts to updated CSS. Also (and important!) worked-into the new design system, are Focus states that presume an ability to intuitively navigate the UI with a keyboard (tab/cursor/return). The "How" on that may need to be its own issue, at a later date.
Components from Figma Design file.

Typography Updates

Because the body class is set to "normal" today, and not with a concise font-size or line-height, some of the typesetting has been difficult to manage to date. Assigning this descending (or ascending?) property to other classes may wack them out a bit and require some pairing to reconcile. Also, updates will need to be checked in Tor Browser, not just Firefox; as sizing things can look different in Tor vs Firefox.

• body to: Noto Sans, Arial, sans-serif; font-size: 13px; line-height: 19px; color: #3D3D3D
• bold to inherit body characteristics, but use color: #000000; and add letter-spacing: 0.5px
• H1 and H2 updates per Figma
• All headers across SI: see last section here, "Standardization"

Buttons

Note: Per standardization section below, all buttons across the SI should be classed to one of the four below styles as part of this work. Will make things muuuch easier, to update button styles in the future. 😺

• Primary & Secondary "blue" buttons
  • Colors/styling for :default, :hover, :focus in alignment with updated components
  • Kill icon on "Cancel" button
  • Likely small updates to text classes, once the body up above is done. See Figma for how they should look.
• Delete All & Delete Message buttons
  • Colors/styling for Delete All :default, :hover, :focus in alignment with updated components
  • New icon artwork & colors for Delete Message
  • :focus on Delete Message

Messaging

• Messaging formats to give all success/error strings a "declarative" and "description" (per this one error message—not sure if there are others). Classing the declarative part of messages apart from descriptions is required for styling, and the aforelinked message only exists today as the "description" part of that.
• Messaging styles so all message classes show this size, in this position, no rounded-corners, these colors, these icons, and with the text/icon positioning following the updated components spec (and how the description text should wrap).
• Re-class "Reply Deleted" message to be green/success, with a declarative of: Deleted! and a description of: You have deleted our reply message to you. (open to edits on description)

Replies

Note: No changes to Empty reply state, this is just to the replies themselves + the info text above them.

• Styling CSS changes on messaging bubble outline/fill colors, corners, stroke weight, padding, and timestamp background/font colors, per Figma screen
• Add blue "i" icon before sentence on info bubble per Figma screen
  • Kill strings & Edit remaining string in SI "Reply" Message #6212 is a dependency for all of the styling to show, correctly.

General Standardization

• Buttons on index page should be classed w/ primary and secondary per this new system, and draw from the same styles as all the other primary and secondary buttons.
• All pages with a solid or outline button, should have those button styles correspond to the primary, secondary, or deletion button styles defined above.
• H1s should only exist on the index, login, and lookup (aka Welcome!) page(s).
• All headers are H2s on lookup?fromlogin (aka Welcome back) page and "Keep In Touch" page.
• Headers and descriptions on .index page should be classed as H1 and body, respectively.
• All pages with a primary/secondary button lockup, should have the two buttons spaced 10px apart and 14px below the object above them. See also note on ordering of primary/secondary buttons in Et Cetera, below.

Flow Inversion

The meat & potatoes of this first phase! Note that in production, the "Submit" page has two headers on it that are the same size no matter if a Source is using SD for the first time, or in a follow-up visit. With the new design direction the first time a source visits an instance (aka the "Welcome" page), there is a clear H1 and an H2; whereas on the return visit, the Submit page instead has two H2s.

Backend things

Lots of handwavey interpretive dance from the designer, to imply all the things she doesn't understand that make the inverted flow possible on the backend. :)

"Welcome" Page

See Figma Design file. First time a source visits a SecureDrop, what is currently called the "lookup" page.

• Kill passphrase widget
• Kill logout button
• Add an H1 classed header above File/Message module that says: Welcome!
• Edit description text below the H1 that says: You may send us any type of file, a message, or both. After your first submission, we’ll let you know how to keep in touch.
• Add Encryption call-to-action (CTA) with blue key icon, below files side of the module, per Figma. Opens existing "Why Public Key?" page—which needs other edits, both near and longer term.
• Kill italicized GPG text above File/Message module. Overlooked by users, and Encryption CTA replaces (and will likely catch their attention, better, based on 2019 testing observations).
• Edit text below "Browse" button to read: You may upload 1 file up to 500mb, per submission
• Edit primary button to say "Send" and not "Submit" (maybe? Now on the fence with this, after considering above item)
  • Note: On Figma the ordering of the buttons is not changed from production, but imho I'd love to see their ordering changed, too. Primary on the right and secondary on the left, is the modern paradigm.
• Error bubble size/placement for this one screen.
• Edit overall page spacing/padding of above items, to reflect updated design layout and visual grid.

"Welcome Back" page

See Figma Design file. Return sources, after they log in. Below items presume the "Welcome" page has already been done.

• All of the items from the "Welcome" page (above)
• Kill page description
• Class header as H2
• Edit header to read "Send a File, a Message, or both"
• Add log out button

"Keep In Touch" page

See Figma Design file for pixel-perfect layout specs. The hybridized confirm & generate page mashup!

• All of the items from the "Welcome Back" page (above)
• Add Passphrase Widget
• Add hide/show control below Passphrase Widget
• Add "Keep In Touch" content below "Log Out" button and Confirmation Message, and above "Welcome Back" page H2. Page's H2, description, above the passphrase widget, and bullets below w/ hide/show control below it. H2: Keep In Touch, description: Please check back in a few days to see if our team has questions about your submission. You will need the below <i>passphrase</i> to do that. On SecureDrop, a passphrase is used as both your username and your password. ul bullets: <b>• Keep it secret.</b> Do not share your passphrase with anyone. <b>• Keep it safe.</b> There is no passphrase recovery.

Et Cetera

One-off items that can be done as unrelated quick-wins to the above.

• Update text on "Why Public Key?" page per Edit/Rethink GPG Guidance in SI #6193
• Re-order all buttons to show the primary on the Right, and the secondary on the Left. This is a standard paradigm that is not reflected in the SI today, nor in the Figma. I hadn't sought to slay this dragon in any of the design explos, but doggone it'd make me happy to see happen (presuming Kev agrees)!
• Re-style Passphrase Widget per SI: Re-Style Passphrase Widget #6213
• Add weeble icon to Login page per Figma. May be good to do with Design System standardization things for that page, too?
• Enable keyboard navigation per A11y best practices & to use new :focus states

[eloquence]

During the current sprint, @eaon @ninavizz and @zenmonkeykstop will focus on narrowing the scope of near-term deliverables (e.g., CSS standardization), some of which can potentially be released independently. As time allows, @eaon may be able to start implementing some of those agreed upon changes.

[cfm]

Re: HTML/CSS standardization: The modal confirmation dialog used in the Journalist Interface offers an example of using parameterized Jinja templates as reusable UI components rendered (that is, to HTML) entirely server-side. This could allow us to standardize on a set of reusable widgets while avoiding the client-side JavaScript requirements of most UI frameworks.

(I speculated along these lines during today's sprint-planning meeting, and this is a more-concrete version of that proposal for the purpose of this epic.)

[eaon]

While working on getting some visual details right, I noticed that the font I saw in Tor Browser wasn't the correct one. I wrongly assumed that Noto Sans gets shipped by Tor, but this is only true for non-latin scripts - for sans-serif latin it defaults to Arimo.

Because we want sources to use Tor Browser's Safest security level, that's what we're stuck with - as far as I can tell, Arimo is the only sans-serif font available to us, because the security level will block any fonts we'd by trying to ship ourselves. Sorry @ninavizz :(

Reaching far into the future here: if JavaScript would become available in the SI, "trusted" fonts could also become candidates for resources to be loaded despite the default security policy. Even then though, we'd probably want to minimize the amount of font data we need to download because of the usual hidden service slowdown. The current version of Noto Sans is 1.4MB big, but Noto Sans Display (which is a minimally narrower version) would allow us to pick what specific weight/variant we actually use and is only ~380kB a pop - the variable weight version clocks in at 3.2MB unfortunately.

[ninavizz]

@eaon You owe me Zero apologies, friend! I honestly quite prefer that family, over Noto—which I never really "liked," but felt was the safest to standardize against. I will update all of my Figma stuff tonight/today, accordingly.

THANK YOU for doing all the research work on that! Evidently they keep changing their minds... as Firefox ships native with Fira Sans, which I'd presumed to be our alternative. But, no. lol. More, later!

[ninavizz]

@eaon Hey hey! Sorry to drag my tail on all this, but the Figma file has finally been all tidied-up, standardized, etc.; all Arimo, everything that should be in the Figma as standardized styles, and all the positioning/spacing finessed. Also, the funny opacity-stuff on buttons, un-done and simplified. Generalized styles have also been documented for the team & ongoing use, here.

[ninavizz]

Design Updates

Following today's yesterday's meeting with Kev, Michael, and Erik, I split the current "Frankenstein E" direction for the Source UI's flow inversion, into two distinct phases: the first, E1, is just design-system stuff and small string changes. The second, E2, is the complete/first iteration of the "Flow Inversion."

E1

Frankenstein-E1 was drafted to reflect changes discussed, that are targeting the 2.3.0 release.

Most of these changes are design-system-only, and in no way touch the flow of the experience itself (the "Flow Inversion"). Most of the strings are the same, and the goal with the 2.3.0 changes are "non-controversial, no-mountains-moved style changes" to get the bulk of the styles-only things out of the way before the heavy lifting with inverting the flow.

Thus far, @eaon has ROCKED the styles updates with glorious new buttons, messaging, a newly styled Codename widget with separated Hide/Show control, and typography updates. We agreed today that:

• the body styling still needs some polishing to get the text a bit bigger, and add other not-obvious attributes for the current PR Michael is working on.
• The :focus states for keyboard navigation are also a a BIG improvement (you gotta check 'em out, @cfm!), and clarification was offered on dialing-in :focus for keyboard-only interactions, vs :active for when things are clicked (the design system updated to show both, after Michael's initial work attempting to make sense of my un-finished system).
• Click-into (?!) states for the Message field and Browse buttons. I'm really tired and up late, and Michael knows what I'm talking about.
• Not in this PR, but in a forthcoming PR, update the text to say "Show Codename" to provide a good screen-reader experience.

A few additional stretch-goals were also identified in today's meeting. These were also added into E1.

• Delete Confirm Modals. Sources deserve a safe deletion experience, too? ;)
• Reverse button ordering to have the primary button to the right, and the secondary (cancel) button to the left.
  • While that is not a Linux paradigm, it's been a web-app paradigm for many years; has always been the Mac paradigm, and a few years ago Windows decided to follow suit with Macs.
• Cleaned-up Generate page content to match what the team workshopped together, back in July. Yes, the goal is to ditch the page altogether for both user research and then in the long run, however the text on the Inverted Flow's Confirmation page will be identical (or near identical) to the Workshopped Generate page's text; so why not? Kev wants to make some tweeks to the text, and I'd love to see y'all workshop on that some more! Only ask, is to keep in mind how those changes may or may not carry over into the Flow Inversion Confirmation Page.
• Encryption 411 page tweeks suggested in Smol GPG Page Tweeks #6272, with or without the inline bang styling shown in E1 mockup.
• Smol String Changes
  • Submit to Send on the primary buttons
  • Less robotic, more human; a behavior, not a page action to a server.
  • Yes, we all love cyberpunk—but, following the 3rd design principle, shaping a calmer experience is a goal.
  • Submit Files or Messages to Send a File, a Message, or both
    • Emphasize the single-upload/message bit, for usability. Single-file upload was surprise and frustration to all users in prior testing.
  • Submit Documents button on Generate page, to Continue
    • "Documents" is needlessly restrictive, and "Submit" is a technical page action and the broader act of engagement; not a human behavior enabled by navigating to the next page.
    • It's just the least-friction-involved "Ok, do the next thing" button text.
  • Kill 3 of the 4 sentences in the note to Sources encouraging Reply deletion.
  • Text below Browse button for file uploads, from: Maximum upload size: 500 MB to: You may upload 1 file at a time, each up to 500mb
    • We hate the single-file upload restriction, but let's upset the users less and be clearer about it? 😄 Cultivate calm and confidence.

E2

The E2 version picks up from the E1 design updates, to complete a "minimum testable version" of the Flow Inversion direction.

The design system developed for E1 carries over to E2; please ignore the "Design System" frame on that Figma page, as the individual components in E2 all draw from E1's design system.

The page layouts and flow changes include:

• Bye bye, Generate page and hello "Welcome—Confirm" page/page-content.
• Simplified header voice/tone. Welcome, Keep In Touch, and Send a File, a Message, or both
• Encryption Link below "Browse" button, replaces the 3 lines of body text. One, with all that body text the "Confirm" page is entirely too busy and overwhelming. Two, users navigated directly to the "Browse" button, and fixated on it and the text below it, before paying attention to the text above. Three, users are more likely to ignore all the text on the page, the more text there is.

BTW, sorry this got soooooo long. I'm me, and I'm also really tired.

[rocodes]

I don't know if this is muddying the waters, but after testing out the new SI changes (and they look great!), I also noticed that there is an error page on the SI that could use some love. (Specifically, I find the wording "Look up a codename...." to be kind of confusing).

It might not fit into the current refactor that's happening, but just wanted to put it out there that perhaps we can change that wording (it goes to the login page, so even "Log in" would be clearer).