search

freedomofpress / securedrop-client

a Qt-based GUI for SecureDrop journalists 📰🗞️
GNU Affero General Public License v3.0
42 stars 39 forks source link

File Only "Preview" Text #996

Open ninavizz opened 4 years ago

ninavizz commented 4 years ago

Problem

Currently, when only a file is sent as the sole Source submission or as the most recent item in a conversation, the Preview area shows the characters <Encrypted file on server>

When text is surfaced to users in the funny < and > symbols, it looks like a code-fart (so, broken). It doesn't look intentional. Likewise, when those words are presented in that context, it reads robotically... whereas in all caps and in the context of the file-widget for a file that's not been downloaded, it feels more appropriately descriptive w/o sounding robot-y.

Solution

Present the text as — language here — which is one em-dash, a space, words, another space, and the end em-dash. That will look intentional.

@eloquence and I had discussed and agreed on what text should be shown there, many months ago, and I cannot remember what we'd agreed to—or what syntax Erik would have used in the Issue (I tried and could not find anything). I'm fine with the verbiage — file only — all lowercase. I don't feel that either punctuation or mixed/sentence-case are appropriate, for this.

eloquence commented 4 years ago

For background, the original discussion about the desired behavior of preview snippets was mainly in #135.

We also use the <> syntax for messages and replies that haven't been downloaded and decrypted yet, in the <Message not yet available> format, including in the previews of those messages/replies.

Once a file has been downloaded, the preview changes to the format File: filename.ext (though note inconsistency pre/post sync, #904).

My view:

ninavizz commented 4 years ago

All good points, thx for the clarifications Erik.

I still feel that including the <> syntax in user-visible UI is likely to cause confusion—for the reasons stated above, wrt user-exposed formatting norms. I realize it's a bit of a nit, but my concern is that users may percieve something in the UI as broken or compromised, vs intended and simply rough.

— language here — is more standard and thus clearly intentional formatting/syntax for user-exposed UI particulars, whereas <language here> is not. Even non-technical users are likely to interpret that as code that accidentally got exposed in the UI.

For downloaded files, I like File: filename.ext and had forgotten we did that. :)

Would either you or jen be comfortable changing only how the syntax/formatting is done, in time for beta? The language particulars I'm not at all worried about, only concerned with users suspecting their client is broken or compromised somehow, because blurbs are contained within <> thingys.

eloquence commented 4 years ago

My view is that if we change it for <Encrypted file> placeholders, we should do it for <Message not downloaded yet> placeholders that use that syntax as well. As long as we agree that styling like — Message not downloaded yet — looks better/clearer including in speech bubbles (easy to test in a branch), it seems like a small change, provided you're not suggesting formatting/styling changes beyond that. That doesn't mean it will make it in time for the first release, mind you. :)

ninavizz commented 4 years ago

@eloquence Yes, totally agreed on all points—in Preview areas and in Bubbles, I'd love that.

The more common formatting standard for a temporal state on an item w/ an in-progress background action such as <Message not downloaded yet> would be either italicization with a ... after the sentence. So, <em>Message not downloaded yet...</em>, or doing the text gray w/o italicization and with the ellipses: <color="gray">Message not downloaded yet...</color>

That said, the em-dash vs the <> thingys, will at least project a correct semiotic of broken vs not, so if the em-dash approach is easier for message not downloaded I'm ok with that, for now.

Encrypted File is a temporal state pending a user-action, not pending an in-progress background action. As such, the em-dash is its preferred styling.

Not worried about the customers exposed in the first release, more worried about subsequent customers.

eloquence commented 4 years ago

Per discussion on Slack, deferring changes to formatting for now to avoid UX churn, we'll look into a design solution for all placeholder types during the pilot, and will ensure users are aware that current client behavior is intentional.