Finding a good email setup and ranting about user-friendliness

created: 2022-06-28 21:51:25 EDT

modified: 2022-06-28 21:51:25 EDT


Whenever I need to read and send emails my usual solution is an awkward and annoying trip to a web browser to visit my email provider's web-app. A proper solution would be to find a good desktop client to use, but I don't work with many emails in the first place so it's never been much of a priority. I used thunderbird for a while but it's a big and bloated for me. The one mail user agent that I've put a decent amount of effort into trying to use in the past is neomutt.

neomutt is awkward to configure though, especially if your goal is just to read emails and not to dig through piles of documentation to gain a full and comprehensive understanding of neomutt. Determining how to actually point it to your mail server in the first place isn't made very easy to figure out. On the official website's documentation, the information is found under the generically named "Optional Features" subsection, following a couple of paragraphs describing how to decide which SSL/TLS library to use for encryption (a). Using multiple accounts at once has pretty bad support too, requiring that you read a bunch of documentation on the account-hook command and similar and use them to write an error-prone configuration file manually stitching together all your different profiles. Part of the cause of these problems is that (neo) mutt is well over two decades old and has some of its features stuck in the last millennium. mutt didn't even have built in IMAP/POP3/etc. support when it started. After some lackluster configuration attempts I eventually gave up at using neomutt practically.

(a) "Optional Features" from neomutt

Following a recent burst of motivation, I decided to look for some different mail clients, and landed on a newer program, aerc (b). I started the program and it gave me an interactive prompt asking for my email, IMAP server, etc., and after giving that, it told me how to make another account if I desired to and asked if I wanted to open the tutorial, which is a short manpage listing a dozen or so keybindings and short descriptions of the different menus you can visit. All of the learning and configuration that was required for use of the program was finished in the first couple minutes of me starting it. This is a much better experience than neomutt. Despite that, aerc has a lot of similarities to neomutt in design principles. They both provide a long list of configuration options and commands allowing for a high degree of customizabilty.

(b) aerc

The problem with documentation in neomutt as opposed to aerc is not that it has too many features, or too much documentation, or even that the documentation is too confusing. The problem is that neomutt puts a lot of friction between a new user and the things they're intending to do with the software. The path of least resistance to start using a mail client is to fill out the information required to connect to the server and to learn how to read and send messages. A good program will anticipate those requirements and put the information needed to execute them within easy reach. Users may also have a long-term goal of gaining a higher level of control and customizability over their software, and for that a different, more involved and complete, set of information needs to be provided. neomutt prioritizes that long-term goal and provides poorly for the short-term one.

The delivery of the information a new user might need doesn't necessarily have to be done the way aerc does it, by providing a "helping hand" within the program itself. I tend to be skeptical of things like that in simple command-line utilities, for example one that provides suggestions for likely-misspelled commands or arguments, because it can increase complexity, although I don't care too much about that as long as it doesn't get annoying. The same effect can be achieved with good external documentation.

So, the conclusion to my email journey is aerc.