-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Compose new static page for post-SUI Logout #94
Comments
@rocodes @zenmonkeykstop Hey gang... this is an update to what's above, based on Friday Feedback before everyone went on break. Let me know what y'all think, I'd love to un-block Ro! |
The exact wording I'd like someone to weigh in on (I'd make it shorter - "Click the icon on the Tor browser toolbar to hide your SecureDrop activity" -- we can't exactly say whether there will be no traces of SD activity on their device, and I wouldn't give advice on whether or not they should check back) but the design looks very clean to me. |
@rocodes Thanks for the feedback.... I don't disagree, that ideally I'd like it to be shorter. My rationale:
This additional line of text imho does not detract from the first ask; while it also adds an important reminder to the next step in the experience—which was never intentionally orchestrated as an experience for users, and as such has many workflow probs (sources not submitting under the same codename, a primary known prob—with many more likely not yet known probs). |
I think this is important (sources submitting under different codenames), but (possibly) belongs with a larger conversation about communicating to sources what the "codename" is/does. I'm not sure if the logout flow is the best place to intervene with that kind of knowledge if it hasn't been emphasized already by the (pretty excellent!) reminders throughout the submission experience, such as "remember, your codename is ___ " / "Forgot your codename?" etc. Relevant SD tickets: |
I am 100% with you, in agreeing this is far from the best place to put that reminder on the codename. :) We're very far away from having the bandwidth to solve for the codename ambiguity and other—abundant—Source UI problems... that need to be solved for in a proper/holistic effort, is the thing. Unfortunately, reminders to do an action (write down a codename) are hollow, if a user doesn't know the value behind taking that action. Nowhere, have we communicated the value. And I agree, this is a shitty place to make that first value-prop. While I agree this is a turd-polish "solution" (that is more of a band-aid), it's something we have the bandwidth for, today—to address a known problem that likely impacts newsrooms as much as it does sources. Because it fits into that overlap area sweet-spot of likely impacting newsroom workflows, it feels important for me to seize every reasonable turd-polish opportunity we can get—until we have the bandwidth to properly solve for it. Unfortunately, that's kind of the general gist with most Source UI fixes, at the moment. Where we have reasonable opportunities, we have to take them. |
I second @rocodes' point about telling sources to check back. Making it conditional "If you want to check back..." seems OK, but there will be sources who have no plans to check back, and the page should reflect that. The critical element for source security here is that they hit that broom button. Anything that distracts from that CTA is harmful IMO. |
To resolve freedomofpress/securedrop#4952, we will need to revise the contents of the message that is shown on session expiry as well. For now, to manage scope, I don't think we should change the interaction flow here, but the content should be updated to reflect the changes to the Tor Browser UI, with the stretch goal of also cleaning up the message presentation a bit (e.g., giant hand icon). |
This is an iteration on the mockup above, per everyone's feedback. There are specific motivations behind each word that's shown—this is not an arbitrary choice of words—to influence behavior by Sources. Users most often look for a primary action to inform their behavior choices, before reading content on a page—often they skip the content altogether. Saying "Thank you" in My priorities here, are:
Attached (below) is the broom icon, saved as a PNG at 4x the 100% resolution. |
@eloquence Did the purple bar get killed at the top of that screen? |
I'll look into the purple bar thing - if it did get killed, I am the likely culprit. Re wording: I completely agree, but I also think it is important to clarify that they have in fact successfully logged out when they see this new page (similar to the old "thank you for exiting your session!" wording). |
@rocodes I feel the big "Log In" button clearly achieves the goal you're identifying, while keeping our ask focused. "Thank you" too clearly implies the user is at the end of a task. They're not, though. From +15yrs of observing users in testing sessions, I can pretty confidently assert that any additional text will backfire on us, here. Even if we didn't use the verbiage "thank you" and just stated in a small sentence a confirmation they've logged out, the more text there is, the more likely the user is to TL;DR ignore it. Again: we can't fall-back on the assumption "this is too important for them to ignore," because that's not how human brains work. |
^ Every word in the The |
No, but it only shows up if JavaScript is enabled in Tor (that's what the warning is about), which it was not in the screenshot I shared with you. |
@rocodes So... insight into my own brain: the argument you cite above, I was just wrestling with. Hard. In composing the text for this screen. In this scenario, the user didn't even chose to log out; so in a way its even more urgent that the text be brief, here, as they'll likely only encounter it while tab hunting. It's TOTALLY wacky to not say 'You have been logged out due to inactivity. Log in to check for responses or to share more with us.' yet because of behavioral-cognitive-reality things, stuffing all that text into this message would most likely backfire on getting users to take the protective actions they need for their own safety. @eloquence This feels like Yet Another Urgent Need for the Learn More/TL;DR Page to be completed. Ro, if we had such a page, a simple "Learn More" link to an FAQ there, would be my preferred solution to this conundrum. |
I don't have a strong opinion on whether or not we have to explicitly acknowledge that the user has logged out. I agree that the "Log in" button gives a strong visual hint to that effect, and subtle recognizable hints like this can often be as effective at conveying the state of a system as explicit language. As has been noted, we should not say "This will ensure you leave no trace of your SecureDrop activity on this device", or wording to that effect, because the scope of the "New Identity" feature is too limited to make any such assurance (we don't know what else the user has done on the device). How about:
I would also suggest to tweak the wording "Click the [icon] icon to Create New Identity" a little bit, because the capitalization does not map to anything in the user interface (the tooltip just says "New Identity"). I would change this to:
As you have done in your more recent mockup. |
...ok, so (for the "user clicked log out" screen): H1: |
(For anyone following along, we're talking about the session expiry case) I think it's reasonable to omit the language about logging back in because the login button is literally immediately below the message, so it's obvious that it's an action available to the user. However, I do think we need to explicitly acknowledge what happened (session timeout), or the message itself has high potential to be too confusing and disorienting to be actionable. The user may even distrust it. |
I do feel it's important to include the last half of the sentence, here, as the phrase Also, I'm well aware the below sentences feel backwards. Per my above cited notation that the first few words must trigger actions in the user's brain, it felt important to keep them inverted in support of the urgency for the user to take action. |
It is - the button says "LOG IN". You're working from an older screenshot or mockup. |
(Still commenting on the session expiry case) If this was a straightforward "the user must click this button every time" thing, I would agree with your approach, but it's not straightforward -- the user needs to understand this action in the context of what they're doing, especially because "New Identity" is a potentially destructive operation (it closes other open windows or tabs and erases all data about them). For example, a source may have done a significant amount of other work in other tabs or windows. Now they are being asked to click a button that closes all other tabs and windows. Why are we asking them to do that? What are the consequences of doing that? In practice, the user may want to revisit those other tabs before taking this action, or they may decide that it's appropriate for them to do this after they're completely done with their session. For this reason, I would err on the side of a straightforward construction that can be easily read, even if it has somewhat lower follow-through, e.g.:
|
I agree that the "explain what happened" (you were logged out due to inactivity) should come first, but I defer to rest of team, esp ux. Whenever there is consensus on wording I will include it! |
Yeah, I'm cool with Erik's suggestion—especially since this page is served from passive neglect, vs the user taking an action with the theoretical intent to protect themselves. I tweaked it a touch to reduce word-count, though; as "browser data" and "history" are kinda redundant. @eloquence If that tweek looks good to you, perhaps let's edit the other message to read the same? |
Nice edit, works for me! I have a slight preference for using "Tor browser activity data" over "Tor browser's activity data" throughout (may be a bit easier to translate as well) but either is fine with me. |
@eloquence Your grammar is better than mine, so I (the native English speaker) will always defer to you (the non-native English speaker) on those points. (cough) yeah. :D @rocodes I believe consensus has emerged! Thank you for your patience with our (my) pedantry. If there are discrepancies between the Zeplin mox and the text below, follow the text below. :) Ship It!For the scenario: User logs out, and no UI is shown on the screen other than the H1 and body, with the logout button, languages selector, footer, and newsroom logo. For the scenario: User ignores authenticated session and system logs them out. |
^ ...also, note: FYI @rocodes the stop-bang is not intended to be the standard error message styling. This is a slight twist on that, with an octagon instead of a circle, on the bang. I could probably stand to post those finalized styles, here, soon... |
Per resolution established in SD #4952
The text was updated successfully, but these errors were encountered: