On the index page, it may not be obvious enough that sources are submitting to a particular org and not just SecureDrop The Org

[heartsucker]

Description

When a source arrives at the landing page, it should be more clear that they are submitting docs to a particular news org and not something like To: SecureDrop, attn: Acme News Co where SD would forward the message along.

User Research Evidence

Did some work with a UX team and they suggested that it may not be clear to a source who exactly they are submitting a message/docs to.

User Stories

As a source, I want to know I'm submitting just to Acme New Co and not FPF/SD who will deliver my docs to Acme News Co.

[ninavizz]

@eloquence I've wanted to create a standardized template for the Newsroom Landing Page, for a while now—something we could deliver with the SD installation package. Not sure why the idea of doing this was pushed-back on, last year—rebase took priority, maybe?? (@redshiftzero @conorsch)

The specific concern @heartsucker is flagging, is of co-branding—but not only is newsroom co-branding w/ SD confusing and inconsistent across all newsroom landing pages, but the structuring of the content for easy consumption, and comprehension of the content itself, are also confusing and inconsistent.

We put Source users at great risk leaving the Landing Page design, co-branding decisions, and content decisions, to newsrooms. Usability issues on these pages = safety missteps on the part of Sources. Many newsrooms have "wall-o-text" landing pages, simply because they lack appropriate design resources—or their design resources are all allocated elsewhere.

Before even getting to the Landing Page, Sources also need to decide which channel is best for their communication needs—and leaving that page design and content to newsrooms seems silly, when a simple design template with content created and validated by us, seems like it could also deliver a lot of value. Again: usability fail = safety fail for Sources.

I'd love to revive this project with a near-term due date. Perhaps begin in late-Feb or early March, once the Workstation is further along?

It's not much design work, TBH; probably more webdev work & writing:

• Design an easy to read SecureDrop Landing Page layout with clear page hierarchies
  • A layout that could work with any combination of newsroom H1, H2s, H3s, and Body Styles
  • A fluid-grid layout that could function within a responsive site—so users could at least review its contents on their mobile devices.
• Determine what content should live on that page and how it should be presented, in partnership with our fabulous FPF Training peeps.
• 2-3 user research days w/ 5-8 users on each day, to validate content choices and design.
  • 1 day per week, with design iterations for the next session throughout the rest of the week.
  • The research will be MUCH easier (tho we'd want to offer $20 gift-cards to participants) than what we did with Journalists for the workstation.
• Potentially also design/test a "Tips" page template to help guide Sources in choosing which channel is best for them: Signal, Email, Encrypted Email, Facebook, WhatsApp, or SecureDrop.
  • Sources need it spelled-out for them how Facebook and WhatsApp are simply NOT secure, and how/why—but simply and concisely. Something we also learned from newsrooms in our Workstation research.
  • This could also help newsrooms get the most useful content contributed to their SecureDrop instances, to reduce irrelevant local news tips—something we heard happens, in our research sessions.
  • Production options for a stand-alone page, or a nested module w/in a newsroom's existing website.
  • Yep, should be responsive and use existing newsroom styles

[eloquence]

@heartsucker Could you clarify whether you're talking about the SecureDrop index page?

Or about the newsroom-created landing page, e.g. https://www.nytimes.com/tips ?

[ninavizz]

^ The above is how the Index pages are supposed to be configured. Curious if some newsrooms mis-configure them, and they instead simply show the SD logo? THAT would be very confusing. Or, if SimplySecure folks looked at the demo instance on the SD site (that shows the SD logo as is shown in Erik's comment)?

The demo instance it seems, could stand to have a fictional newsroom logo there (such as The Daily Bugle from Spiderman, or The Daily Planet from Superman) to provide a more accurate representation of newsroom SD instances. Or more simply, a graphic of a dotted-line square with "Newsroom Logo Here" inside.

Regardless—how the co-branding is done throughout the Source experience, and the language Selector in the Source UI, I feel are both problematic in the current Source experience. Would love to do a usability scrub to the Source experience, at some point. <3

[huertanix]

I read this issue and interpreted as talking about the securedrop.org landing page.

I psuedo-randomly chose 10 SecureDrops (maybe too small a sample size) from the securedrop.org directly to look at, and all of them had their own logos and not the default one.

It would be fun to have the Daily Bugle logo end up online for a bit in a new SecureDrop's launch while people upload those great pictures of Spider Man that J. Jonah Jameson is always asking for! My gut read of newsroom staff would be that it'd be too fun and not srs bsns enough though. :<

[ninavizz]

DC Comics doesn't have much of a sense of humor, so I doubt they'd play along—even if newsroom staff appreciated the gesture: https://www.americanbar.org/groups/litigation/committees/intellectual-property/practice/2015/dc-comics-trademark-police/

[ninavizz]

@heartsucker ??

[heartsucker]

This was suggested by @bumbleblue, and I think the idea was that the index page on the Source Interface might not make it obvious enough that SD is self hosted and not a managed service. Sources might think that they are dumping docs into the One True SecureDrop run by FPF and then FPF passes them along to the org whose logo is present. @bumbleblue may want to make sure I'm correctly stating what she said during the review we did this week.

[ninavizz]

On the hunch @bumbleblue flagged this from looking at the docs — as a maybe-related-but-maybe-not-related observation, I've been thinking we should update all screenshots (at a minimum, for Sources) in the Docs to show a news org logo in place of where the SecureDrop logo is. It's just so very confusing imho, having a big/bold SecureDrop logo where the news org logo should be.

For usability I'd recommend using the most easily recognizable news org's logo in each language; so for Arabic Docs, that'd be AlJazeera, and for English docs that'd be NYT. @zenmonkeykstop @huertanix What do you guys think about this?

[huertanix]

@ninavizz Slightly worried that it might be perceived as picking favorites or an implicit endorsement of the news org. This might be where a fictional news org could be handy to use.

[ninavizz]

@huertanix I know. That's a big part of why I loved the idea of The Daily Planet; a fictional news org easily recognizable to many. Time Warner owns DC Comics, and I highly doubt they'd ok our use of the DP logo. Last night I'd also thought of well known news orgs that no longer exist, and could think of none.

So: I see your point. It also concerns me.

Bloom Beacon was used by Berkeley Breathed in Bloom County; I could ping him to see if he'd be open to us using it? Heck, if he thinks SD is cool, maybe Opus could be a whistleblower in a future strip... ??

I'm averse to making-up something random, because you know said fictional name pulled from nowhere would actually exist—and potential legal trouble could follow.

Alternately, FaithLeaks seems niche enough to communicate the point in a widely relatable/identifiable fashion that using a techy-niche or NGO logo would not.

[huertanix]

@ninavizz I was thinking about Image's Paper Girls today and it turns out that the Cleveland Preserver is a fictional newspaper. It's a p deep cut in pop culture but not sure how territorial Image is about IP vs. DC Comics. Bloom Beacon also sounds cool though.

[ninavizz]

@huartanix Oooh, never heard of Paper Girls before—it looks neat!

Tangentially, I feel it could also be really helpful to use character names from a comic in docs or videos demonstrating how SD works—so, Opus as a whistleblower and Milo as the journalist, or Jude as a whistleblower and Charlotte as the journalist. Or something similar. Narrative is such a helpful cognitive-hook for users, and comics rule.

Do you know Paper Girls' creator(s)? Happy to reach-out to them, too, if you do not.

[huertanix]

Having a whole cast would be great! Sadly I don't know the creators of Paper Girls, but I have a friend who knows basically everyone in the indie comics world; Will ask her.

[redshiftzero]

So the reason we have the SecureDrop logo in the source interface guide docs is that it's the default for the application. If a news organization wants to customize the source interface to make it clearer to sources that they are leaking to NYT and not SecureDrop inc., they can do so, but otherwise the default logo will be there. Do we think it would decrease confusion to have the docs updated without updating the behavior on prod instances (i.e. ensuring that organizations customize the logo)?

[ninavizz]

IMHO it should be a requirement for orgs to customize their logos. Sources need to know who they're submitting information to—and it would work in everyone's favor to play usability police with co-branding mandates and a canned landing-page design, imho.

I do think that part of this broader issue, is shipping SD with a different default logo; and with the <alt> tag for the logo being the name of the news org w/ SD (so, Share information securely with The New York Times).

The SD logo can go elsewhere, but it was significantly confusing to me when I first came into the SD universe, how the docs presented the UI. Erik had a funny story to share about Wikimedia shipping with a logo so intentionally ugly that orgs would therefore be forced to change it. I like the idea of us doing something similar; like a greyscale illustration of a globe or a newspaper, with YOUR LOGO HERE in bright red.

[ninavizz]

^ Also... I know we want to force users to read things on pages, to read documentation, etc. It's been my experience in years of work doing usability testing tho, that they won't—even if you try to force them to. They get frustrated and abandon or make mistakes, before being forced to read things.

Which is why choices in crafting page layout hierarchies, use of branding, use of iconography, and brevity in written language, are all so important.

[bumbleblue]

Sorry for being late to the discussion - @heartsucker got it right, my point was that the mental model for the Source here needs to be: "SD is an open-source-service that [my favourite newsroom] uses to get information securely," not "I am dropping to SD, and giving access to [my favourite newsroom]." And the larger point, as @ninavizz said, is perhaps giving newsrooms more control over branding. But that's a larger discussion, and I see advantages and disadvantages.

[ninavizz]

Bigger picture, it seems like re-thinking how the product vs instance-org branding is handled needs to happen. We should definitely learn more about this—and @bumbleblue I appreciate you flagging & adding clarification to! Will add into research priorities for the Source Experience. :)

In the interim though, I do feel small things can and should be done to make the entry to the SD experience smoother for Sources. Replacing the SD logo on screens in the docs with the FPF logo feels like a good first step on the mental-models front, as does elimination of the word "Source" in copy that seeks to speak directly to Source users (such as the docs nav). @eloquence @redshiftzero how do you both feel about maybe doing both of these low-hanging-fruit items in a near term release?