Skip to content
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

lock icon user interface inconsistency #22

Open
dajhorn opened this issue Jan 9, 2013 · 1 comment
Open

lock icon user interface inconsistency #22

dajhorn opened this issue Jan 9, 2013 · 1 comment

Comments

@dajhorn
Copy link

dajhorn commented Jan 9, 2013

Regarding the Mymail-Crypt for Gmail 20 extension running in Chrome 23.0.1271.97m for Windows.

I sent my first email through gmail-crypt in plain text because I thought that the [lock] Encrypt button was a status indicator instead of a button. This element is inconsistent with all modern browser interfaces and other similar products where a visible [lock] icon always means safety.

Expected behavior is:

  • The message is [unlocked] by default, and therefore insecure, until I take action to encrypt the message.
  • Or, if I can see something like [lock] Encrypt that implies protection, then clicking the [SEND] button prompts for the passphrase post-hoc.

Either of these two behaviors would reflect how desktop MUAs behave.

Phrases like insert private key and friends keys are also different than all other GPG/PGP applications that I've used, which forced me to think twice about what I needed to do. In this case, import private key would be a more conventional label.

(PS: The stop automatic draft uploading toggle worked for me.)

@seancolyer
Copy link
Owner

Thanks for the feedback.

I'll have to think to see if there is a reasonable way to change the button state as you're suggesting. I'm not sure the state decision should be as simple as "has the button been clicked?"; for a situation such as if someone wants to encrypt a message and then save a draft but not send the message. If you have a good approach in mind it would be great to see that in a pull request.

Regarding the phrases, I have intentionally chosen phrases that don't mesh currently with a lot of existing applications, because I find that they draw an extremely narrow audience and are not particularly intuitive. I believe that a project like this which aims to be simple to use should use corresponding language. Perhaps my choices haven't been perfect but I'm reluctant to use the same language as all other OpenPGP applications.

Glad the draft stopping was working for you. It was a surprisingly complex feature.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants