First this is an keyholder issue with not that much content - to create concrete subtasks for things to discuss seperatly.
Description
Description
| Status | Assigned | Task | ||
|---|---|---|---|---|
| Open | None | T14768 Workflow of encrypted Mails | ||
| Open | None | T14769 Dialogs after sending mails | ||
| Open | None | T14770 KeySelection dialog takes ages to load all keys | ||
| Open | None | T14771 KeySelection Dialog only shows technical informations | ||
| Open | None | T14772 libkleo keyselection and approval dialog for KMail |
Comment Actions
Hey VDG team, As the title tells you: I want to improve the current workflow of encrypted mails in KMail. At the moment focusing on the sending part of it. I need input from VDG about how to improve the current situation.
Comment Actions
It's currently not clear from the task descriptions what your goals are. I have next to no experience with encrypted email, but I know that PGP has a lot of built-in complexity that can be difficult to abstract away (part of why it isn't used by most people). Maybe someone else in the KDE VDG has more experience with encrypted email, but I don't know anyone in particular who does.
Comment Actions
@knauss: be aware that if the EARN IT anti-encryption bill passes, your efforts will all be for naught, as mail providers will begin refusing encrypted mail outright. Please spread the word!
Comment Actions
@ndavis: What infomation do you need to help? Have you watched the videos? And looked into the subtasks? Sorry I'm a little bit lost, what you need for information to go on. As I have deep understanding in the encrypted messages I'm somehow blind about the questions from newbies.
As a first step I want to get improve the situation when sending an encrypted message. I want to remove/replace/improve all the dialogs that pop up AFTER pressing "send". I think a user should in best case not click "OK" at any other dialog after pressing "send". The user should have information BEFORE pressing "Send", if they wants to send it under specific circumstances.
Comment Actions
It's just unclear what you need design help with. The videos show the current state, and it seems like it's not ideal since I can't understand any of it, but I don't know what to say or think beyond that. From my perspective as an inexperienced user, the ideal experience is that I don't even have to think about keys. It would only be something programmers and sysadmins would be concerned about. Emails would simply be encrypted when I want them to be. Maybe even by default without me being aware of it, similar to how https is everywhere by default on most important websites. I understand it's not as simple as that, otherwise encrypted email would already be far more common.
Comment Actions
Full ACK. An inexpirenced user should not been bothered with details, on the other side advanced users want to look at details and want to be able to see fingerprints/keyids etc. This matches what KDEs idea: simply by default but powerful when needed. But it is hard to find the good line.
The simple case: There is only one matching encrypted key you don't see any of these dialogs: You just hit "Send" and the mail is encrypted in background and sent, without any further communication with the user. Also we have the logic, that we enable encryption, if we detect that all recipients support encryption.
Unfortunately there are corner cases, when it is is not clear what to do. Sure for a lot cases we could do something, but that may lower the security level. The current approach is, to ask the user in any case if something is unclear. But my feeling is that a lot of those information are not relevant for all users, just for experienced ones. Without lowering the security level. How to communicate those information without breaking the workflow of the user. My thoughts are using more inline popups when creating the message, if those are mostly plain informative.
I hope that VDG can help me to find the line what to communicate and what not and find find better ways for communication than popups after hitting the "Sent" button.