freedomofpress / securedrop.org

Code for the SecureDrop project website
https://securedrop.org
GNU Affero General Public License v3.0
40 stars 8 forks source link

Usability concerns: Directory listing page #642

Open ninavizz opened 5 years ago

ninavizz commented 5 years ago

Yep, obligitory eye-roll... "oop, look what Nina did!"

Concerns

  1. Guidance on how to submit to each organization is overly verbose and difficult to follow.
  2. Page content assumes that users know what an onion address is.
  3. Page content also uses SD jargon "Landing Page," which users new to SD and not in tech will not know how to parse.
  4. Ordering of information does not follow anticipated user desires; forcing users to read what an organization would prefer, out of the user's desired order, is a known anti-pattern.

Quick Pass

Of course me being me, I had thoughts. Re-formatting the left column things, to me is the only "Must Do" on this mockup. The arrow on the "Back to Directory" button should be reversed and placed at the beginning of the button, tho, as is done in the mockup.

Content for the right column stuff shd be lightweight and visually tertiary, to all other page content. The necessity of using the Tor browser for .onion URLs, why the conflicting addys are a flag, and how to find a safe network to proceed with, are recommended content. With light iconography, and very brief blurbs.

image

eloquence commented 5 years ago

As usual, no promise that we can get to this in the near-term, but definitely good to think about as part of improving the source experience as a whole -- thanks for putting this together. :)

Curious what Harris thinks, but I like the idea of splitting the lengthy prose into clearer steps.

The current mock strikes me as exacerbating the cognitive overload in some respects, however. There's four steps, a tip, and some potential elaboration (as well as warnings we may want to show for specific entries). That's a lot; I think it's worth thinking about ways to make it more compact. To be fair, I think your design just makes the existing complexity more apparent.

Specifically for explaining Onion Services (which is the term we should use, "hidden service" has been deprecated), it may be better to use a progressive disclosure pattern, e.g., an overlay that appears if you hover over the term. Note that it's likely that the news organization's own landing page has additional info about this.

ninavizz commented 5 years ago
  1. Mockup generated as a step towards improvement, and a kick to get conversations started... not as a definitive recommendation of any kind. :)
  2. Motivation of recc was purely to cultivate a better sense of respect for the user's ability to parse what's being thrown at them, and to minimize confusion.
    • The cognitive burden of what's being asked of them is a lot, to begin with—and I agree, that's a separate design problem. As a quick/short-term solution though, I do feel that at least splitting-up the content in the left column would be a big win to accomplish as a near-term priority.
    • The outstanding/primary "issue," is the probability of users just ignoring everything in a big blob of text. At least they're more likely to comply, when things are split into numbers—and with what this .onion thing is, being clarified up-front.
  3. Yes, Harris! Always Harris!
  4. Yes, .onions are spoken to and explained, along with the Tor browser, in each org's LP. If we're asking users to "compare .onion addresses" first, though, that's some whackadoo tomfoolery if the user has never seen nor heard of a URL that's a bunch of garbled characters with an .onion addendum.
  5. The warnings make zero sense to me, as a non-technical user, as they're done today. Their current verbiage provokes more of a sense of imposter syndrome to me, than they communicate something I can meaningfully act upon. So, they're yet another thing I'd like to discuss in a broader "Design Problem" conversation. Yep, can add to "Future, Date TBD" items on UX meeting agenda page.