Hello! I’ve been using Delta for about a week and I really like it, but have some thoughts on my experience so far and how the user experience might be improved. I apologize if I’ve missed any other threads with a similar discussion. Thanks for taking the time to read and consider my proposal!
Problem Statement
Most people, however, don’t use Delta Chat (though I have been trying to convince my friends!) and the application is built on top of email. The application should therefore be more flexible about what it considers a chat (any email can be a chat but some chats are more fully featured than others).
The current model uses the following three options for showing “Classic E-Mails”
- No, chats only
- For accepted contacts
- All
The request model uses email as a request from a contact (or nearly so, I haven’t quite grokked what happens in an email with multiple addresses) worthy of putting in the chat list but it uses a contact as the model for whether to show classic emails. The block list works on a contact level but also shows up on chats/requests that haven’t been accepted.
Because the application is modeled in this way, I found myself having the following struggle:
- If you select show All classical emails on and your inbox receives a large number of diverse emails you wouldn’t want as chats (marketing, etc), you receive a flood of notifications and your chat list is overwhelmed with “requests” from first contacts since the app is started. You then have to painstakingly block or mute every one of these to get to a usable chat list.
- If you select Show classical email for accepted contacts, you either have to send the first email, or you have to have accepted the contact’s “request” under the “All” strategy. new emails that might be worthy for the chat list would be blocked if you hadn’t already accepted them.
Proposed Solution
I would like to propose an alternative model.
Dispense with the distinction of classic emails and chats and drive the experience with two lists of contacts that the user can manage:
- ALLOW LIST: new emails from this list of contacts will always show up as chats in the interface.
- BLOCK LIST: new emails from this list of contacts will never show up as chats in the interface.
and one that is auto-generated off of the incoming emails
- REQUEST LIST: new emails from contacts that are not on the ALLOW LIST or the BLOCK list are held locally but not shown in the chat list and grouped by contact.
Explanation
Any contacts that Delta discovers that are not on the allow or block list are considered “requests”. Delta should continue to hold emails from these contacts but not show them in the chat list. Within the interface, there should be a section for “requests”, which should be grouped by contact. If the user selects the contact in the requests list, the user can look at the emails that delta is holding for that contact as a list. If the user determines that the contact is “allowed”, all of those emails should appear as chats in the main chat list. If the user determines that the contact is “blocked”, all held messages are deleted from delta.
The allow and block lists could be stored as a special email in the user’s account (similar to a note to self) so that when Delta is used on multiple devices, the list is synced between instances and all instances handle the messages appropriately.
Similar works
The closest example I can think of to this categorization model is in HEY. When the user receives emails from an unknown sender, it goes into the “email screener”, where it must then be set to either allowed or blocked. In HEY, blocked emails aren’t dropped but they’re never seen in the inbox (“imbox”) which is more pleasant for the user.