Email Apps Suck(schneid.io)
schneid.io
Email Apps Suck
https://schneid.io/blog/why-your-email-app-sucks.html
83 comments
That's an implementation detail, best left to the developer of the app. What I care about is UI, speed, search, privacy, etc.
I don't agree with you. Like with anything else, less abstraction = more performance. Creating a specific/targeted way to index, store and manage email data has its benefits too.
I'd hazard a guess that most proprietary formats are similar to the maildir format. Its just that the individual files are opqaue at the filesystem level. If you create thousands of tiny files then you are hoping that the file system design - which like any other design can only be optimized for specific workloads - can handle it better than a database type format specifically designed for email.
Then again a generic full text search system (which probably won't even know that they're email files) over those thousands of files would have to be better than a targeted design for email data.
You would miss certain optimizations like.. (making one up now) extracting and storing just the email headers in a separate region to speed up indexing and having some indirection built in to lookup that specific email.
I'd hazard a guess that most proprietary formats are similar to the maildir format. Its just that the individual files are opqaue at the filesystem level. If you create thousands of tiny files then you are hoping that the file system design - which like any other design can only be optimized for specific workloads - can handle it better than a database type format specifically designed for email.
Then again a generic full text search system (which probably won't even know that they're email files) over those thousands of files would have to be better than a targeted design for email data.
You would miss certain optimizations like.. (making one up now) extracting and storing just the email headers in a separate region to speed up indexing and having some indirection built in to lookup that specific email.
As far as I can tell from playing with many of them:
- Almost all (open source and proprietary) prefer mbox-style
- If not mbox, then it is monolithic file per folder, very few if any store email per file like maildir, despite it having many benefits [0] (if you are smarter than Bernstein on such things, please do write on these things; no one gives a shit to explain email out because it is not sexy)
- The index system always stores data separate of the email store; I have not seen a counter example, perhaps for Outlook, which I presume uses the Windows/OSX OS-level indexing
- To get back to my point re generic FTS, there it is, keep the OS ones so people can search in one place (I use recoll and notmuch for email specifically; it's annoying)
- What optimizations are there for indexing beyond header info? Again, good FTS systems can be extended (for what I define as good)[1]
I do not mean to criticize your points, but I do support work and all of these clients do good for non-technical users, but are ticking times bombs that shit themslves and require resyncing all data when they corrupt massive multi-gig files, let alone re-indexing it all.
Using them is one thing, having to fix them is what informs my opinions on this and why I sync to maildirs, use mutt-kz, and webmail depending on mood and time.
[0] https://cr.yp.to/proto/maildir.html
[1] https://bitbucket.org/medoc/recoll/wiki/IndexMailHeader apparently they have improved, perhaps I shall ditch notmuch out of notmuch discipline for email! Haha
- Almost all (open source and proprietary) prefer mbox-style
- If not mbox, then it is monolithic file per folder, very few if any store email per file like maildir, despite it having many benefits [0] (if you are smarter than Bernstein on such things, please do write on these things; no one gives a shit to explain email out because it is not sexy)
- The index system always stores data separate of the email store; I have not seen a counter example, perhaps for Outlook, which I presume uses the Windows/OSX OS-level indexing
- To get back to my point re generic FTS, there it is, keep the OS ones so people can search in one place (I use recoll and notmuch for email specifically; it's annoying)
- What optimizations are there for indexing beyond header info? Again, good FTS systems can be extended (for what I define as good)[1]
I do not mean to criticize your points, but I do support work and all of these clients do good for non-technical users, but are ticking times bombs that shit themslves and require resyncing all data when they corrupt massive multi-gig files, let alone re-indexing it all.
Using them is one thing, having to fix them is what informs my opinions on this and why I sync to maildirs, use mutt-kz, and webmail depending on mood and time.
[0] https://cr.yp.to/proto/maildir.html
[1] https://bitbucket.org/medoc/recoll/wiki/IndexMailHeader apparently they have improved, perhaps I shall ditch notmuch out of notmuch discipline for email! Haha
Well you're right that we can have a generic FTS system with a general OS based search with specific handlers for mailbox types. I guess you're trying to say that the file formats have become too complex where the clients themselves can't implement them bug-free. About that, perhaps another way to tackle that is not to go back to a more "primitive" format but to improve the quality of email clients.
Personally, I never have IT problems, so I can't comment on the support burden. But I agree with you that if I had to re-prioritize, then reducing the support costs by trading performance and going back to a simpler format is probably worth it.
Personally, I never have IT problems, so I can't comment on the support burden. But I agree with you that if I had to re-prioritize, then reducing the support costs by trading performance and going back to a simpler format is probably worth it.
If a filesystem is a poor match for an email database, I'd appreciate the use of a well-established, open, and documented database format. That is, a format not only your unique email client can understand. Something with an independent manipulation tool. In the perfect case, something that can be interoperably used by several different email clients (not in parallel, of course) and / or third-party indexing / filtering / other processing tools.
SQLite is used in many cases to store smaller things. It's likely not a good fit for a few gigabytes of email with binary attachments, though. I wonder what would be? NoSQL document-storing databases seem to have been created for a purpose like this. Is any of these used by any remotely popular client?
SQLite is used in many cases to store smaller things. It's likely not a good fit for a few gigabytes of email with binary attachments, though. I wonder what would be? NoSQL document-storing databases seem to have been created for a purpose like this. Is any of these used by any remotely popular client?
Again, shoving everything into one file is mbox, which is a recognized file format (if not database), and it does not help things that much.
I have wondered the Sqlite thing myself beyond my one criticism. If anything, you would love K9 Mail on Android, which does this out of necessity.
And some people have made SQL and noSQL email stores.
http://nosql.mypopescu.com/post/3083070885/couchdb-as-email-...
https://www.npmjs.com/package/haraka-nosql
http://www.dbmail.org/
I have wondered the Sqlite thing myself beyond my one criticism. If anything, you would love K9 Mail on Android, which does this out of necessity.
And some people have made SQL and noSQL email stores.
http://nosql.mypopescu.com/post/3083070885/couchdb-as-email-...
https://www.npmjs.com/package/haraka-nosql
http://www.dbmail.org/
>I wonder what would be?
Well, maybe the people writing email clients have already thought quite a bit on this topic, likely created several prototypes, benchmarked them and chosen one that works the best given their constraints and features. Now all that's left is to open the format specification :)
Well, maybe the people writing email clients have already thought quite a bit on this topic, likely created several prototypes, benchmarked them and chosen one that works the best given their constraints and features. Now all that's left is to open the format specification :)
There's nothing stopping a mail client from maintaining arbitrary indexes, caches, etc. in addition to the maildir.
Sure, every time you deviate from a targeted design you leave performance on the table. Whats acceptable to you, may not be to others.
Performance doing what? Email has several operations and none of these clients are performant at scale.
You know why mutt can be for me? I have a second program (isync/mbsync) sync the maildirs, a third to index it, and mutt is just for reading and sorting.
When you have one monolith doing all 3 at its will all the time, you get calls from users that Thunderbird and Mail.app are janky and the computer is hosed. It is interesting as FTS came to Thunderbird and they ran the indexer all the time, until they intelligently designed to have better controls around its execution as it destroyed general usability. Mail.app is better, but I see executive running it for days and it becomes a misbehaving pile of mess.
I am asking in a respectful tone and not to make light of your position, but what do you use? I want to get a better look into your view and I think this might help me understand you better, if you are willing to indulge me.
UPDATE: And when I say several things at once, ironically this is not by design! Email has changed a lot since the sendmail days (and that is cutting edge with respect to many veterans here) and thus there is well-known and accepted design I can think of beyond layers of addition on clients to meet definitions and changes in protocol, routinely made without any discussion of client operation beyond standards for file structures like mbox and Maildir, even they are formal standards, I would have to check,
You know why mutt can be for me? I have a second program (isync/mbsync) sync the maildirs, a third to index it, and mutt is just for reading and sorting.
When you have one monolith doing all 3 at its will all the time, you get calls from users that Thunderbird and Mail.app are janky and the computer is hosed. It is interesting as FTS came to Thunderbird and they ran the indexer all the time, until they intelligently designed to have better controls around its execution as it destroyed general usability. Mail.app is better, but I see executive running it for days and it becomes a misbehaving pile of mess.
I am asking in a respectful tone and not to make light of your position, but what do you use? I want to get a better look into your view and I think this might help me understand you better, if you are willing to indulge me.
UPDATE: And when I say several things at once, ironically this is not by design! Email has changed a lot since the sendmail days (and that is cutting edge with respect to many veterans here) and thus there is well-known and accepted design I can think of beyond layers of addition on clients to meet definitions and changes in protocol, routinely made without any discussion of client operation beyond standards for file structures like mbox and Maildir, even they are formal standards, I would have to check,
>Performance doing what? Email has several operations and none of these clients are performant at scale.
Well OK, so the most important for me is search, and the second most important is being able to quickly apply labels based on filters on a bulk-scale. I have found mutt to not really be performant and the workflow that I achieved was rather brittle (complicated by other factors like having to deal with HTML email). I'm currently using Gmail, but I am experimenting with outlook and I quite like the performance. I don't have a ton of email, maybe around 3-4GB, 25K emails. Bulk operations like 'select all' - do X on several thousand emails takes seconds (which is still slow IMHO FWIW). I haven't seen such performance with other clients. Granted, I haven't broken down every single client and benchmarked different workloads, so I'm only speaking in generalities.
And don't worry about offending me. I was just trying to stir up some conversation. I don't take offense if someone disagrees with me on the internet.
Well OK, so the most important for me is search, and the second most important is being able to quickly apply labels based on filters on a bulk-scale. I have found mutt to not really be performant and the workflow that I achieved was rather brittle (complicated by other factors like having to deal with HTML email). I'm currently using Gmail, but I am experimenting with outlook and I quite like the performance. I don't have a ton of email, maybe around 3-4GB, 25K emails. Bulk operations like 'select all' - do X on several thousand emails takes seconds (which is still slow IMHO FWIW). I haven't seen such performance with other clients. Granted, I haven't broken down every single client and benchmarked different workloads, so I'm only speaking in generalities.
And don't worry about offending me. I was just trying to stir up some conversation. I don't take offense if someone disagrees with me on the internet.
No worries, then. You like me enjoy stirring up to learn.
As I suggested, I slip everything up into different applications. I use mutt-kz and not much with isync to sync maildir, view it mutt, and do label/filtering like Gmail locally with notmuch on a Xapian FTS subsystem backend. It's fun.
As I suggested, I slip everything up into different applications. I use mutt-kz and not much with isync to sync maildir, view it mutt, and do label/filtering like Gmail locally with notmuch on a Xapian FTS subsystem backend. It's fun.
Then keep exactly your preferred high-performance database design, but derive its data from maildir, such that all mail is persisted in maildir first.
Yes, that would be a good way to go.
I am glad you made this point; I forgot to.
No mention of Postbox (https://www.postbox-inc.com)? It's based on Thunderbird, but has very good support for conversations and archiving (Gmail-like workflow) even for non-Gmail providers. It also has nice native looking styles for macOS and Windows.
For me, it is one of the best clients... although I use primarily windows and sometimes Linux (where it works fine with wine), so I can't try the macOS-only ones.
For me, it is one of the best clients... although I use primarily windows and sometimes Linux (where it works fine with wine), so I can't try the macOS-only ones.
As a FLOSS supporter, I have been perturbed they charge money and let Thunderbird languish, just like I have been as an individual user all these years. Problem is I don't make a profit off it. Do they give back? I would like to stand corrected if I arrogantly assumed.
Postbox isn't keeping their version of the PGP add on current. They are still offering version 1.2 while Enigmail is up to 1.9 now. That's a showstopper for me.
Yeah in hindsight it's obvious I should've mentioned this category, but as I mentioned in the article, I strongly prefer my email apps to be unified (i.e. both Mac + iOS available) and there are fewer and less interesting (IMO) Mac-only apps than iOS-only apps. Postbox is great if you're just looking for a stable, no-frills client that's desktop-only. I also use Mailplane sometimes (it's basically just a tabbed wrapper around the Gmail web interface).
Have to recommend Postbox as well. It is the only mail client that could integrate with my school's terrible email server, which saved me from using their broken web client. Postbox has a clean (but not exactly minimal) interface, a nice way of displaying conversations, great attachment handling, is super stable, and has been around a long time.
Mail.app is fine for me... What am I missing in an email client that Mail.app doesn't provide?
From the article:
"[...] it’s buggy and crashy, it needs to update my email library every few months when I open it (why does my email need a library?), and it lacks any sort of innovative feature set (or even support for things like snoozing)."
"[...] it’s buggy and crashy, it needs to update my email library every few months when I open it (why does my email need a library?), and it lacks any sort of innovative feature set (or even support for things like snoozing)."
And yet none of us seem to see those issues.
I can remember mail.app needing to rebuild a mailbox to a new format maybe twice or three times, since probably 2008.
1 person saying "x is buggy and crashes" doesn't mean much without actual descriptions of the problem.
I can remember mail.app needing to rebuild a mailbox to a new format maybe twice or three times, since probably 2008.
1 person saying "x is buggy and crashes" doesn't mean much without actual descriptions of the problem.
I mean, if you like Mail.app, use Mail.app. I'm not here to tell you that you should change how you read your email if you're satisfied with it. I was pithy in the Mail.app section because the article was already shaping up to be quite long and I just sort of assume everyone in the Apple ecosystem has used Mail.app at least a bit and knows its strengths and shortcomings already.
> knows its strengths and shortcomings already.
I've used mail.app since I've used OS X, and I wouldn't describe any version I've used as particularly "buggy" or "crashy"
I've used mail.app since I've used OS X, and I wouldn't describe any version I've used as particularly "buggy" or "crashy"
Not to pile on, but Mail.app has seemed the most predictable and consistently performing (with search and basic usage) of all of the clients I have used, including most of those mentioned in the article.
I realize this is just one data point, but as unpopular as your perspective is, stephenr, I share it.
I realize this is just one data point, but as unpopular as your perspective is, stephenr, I share it.
I agree. Mail.app works perfectly for me. It does what it stated it was going to do, provide a simple interface on top of 'pine' like functionality/usability. I have multiple email accounts and have a solid preference for POP3 over IMAP. I've been using email since the early 1980's and operate on multiple machines (Laptop, Workstation, iPhone, etc.) without issue.
For what it's worth, I have been using Outlook for Mac for about a year now and have really enjoyed it. Categorizing emails by folder is, well, what Outlook has always done well and search is surprisingly good.
Maybe I'm the odd one out, but I don't need any glitz and glam in my email client. I just want it to work and show me the email I want to see when I want to see it.
Maybe I'm the odd one out, but I don't need any glitz and glam in my email client. I just want it to work and show me the email I want to see when I want to see it.
It's all fun and games until you mirror the IMAP folder structure (what you sync with server) with local folders, break your Mac, and then import them into a new Mac and have to keep it all straight.
Or you have to make a PST export on a Mac and do it on a PC? Given my job, I am relieved but terrified I have not even had to worry about it. I just looked it up and chuckled. Not a surprise this will screw you.
http://answers.microsoft.com/en-us/mac/forum/macoffice2011-m...
Again, I said this before in another thread and stood in the middle of a minor flame. All email clients suck more than mutt.
Do I love mutt? Not so much. But the developers have the serenity to accept that which they cannot change, and that the whole charade blows. (Does a day go by where we do not pounce on those who propose secure email, as a protocol and system? Forget the clients even.) That, and I have low self-esteem and relate to people who poke fun at themselves for sucking a little less since the beginning. [0]
To relate it to a real technical issue. Mutt tries to be as nothing as possible, in terms of feature set and use case, while Outlook/Thunderbird/fat clients try to be everything.
Someone likened Outlook to Emacs (which I love ironically), which I would say is true with a caveat. Something as intimate as correspondence and personal communication programming needs to be powerfully extensible and customizable, and none of the fat clients have good interfaces for that. Not even mutt does easily, and this is the core of the problem.
Show me a world where everyone uses the same ink, pen, and paper to draft dead tree letters in the exactly style and preference and we can find an email that does not suck.
(Hint: there never was one and never will be! Let the downvotes descend upon me!)
[0] http://www.mutt.org/ I pray they never change this beautiful site and its header.
Or you have to make a PST export on a Mac and do it on a PC? Given my job, I am relieved but terrified I have not even had to worry about it. I just looked it up and chuckled. Not a surprise this will screw you.
http://answers.microsoft.com/en-us/mac/forum/macoffice2011-m...
Again, I said this before in another thread and stood in the middle of a minor flame. All email clients suck more than mutt.
Do I love mutt? Not so much. But the developers have the serenity to accept that which they cannot change, and that the whole charade blows. (Does a day go by where we do not pounce on those who propose secure email, as a protocol and system? Forget the clients even.) That, and I have low self-esteem and relate to people who poke fun at themselves for sucking a little less since the beginning. [0]
To relate it to a real technical issue. Mutt tries to be as nothing as possible, in terms of feature set and use case, while Outlook/Thunderbird/fat clients try to be everything.
Someone likened Outlook to Emacs (which I love ironically), which I would say is true with a caveat. Something as intimate as correspondence and personal communication programming needs to be powerfully extensible and customizable, and none of the fat clients have good interfaces for that. Not even mutt does easily, and this is the core of the problem.
Show me a world where everyone uses the same ink, pen, and paper to draft dead tree letters in the exactly style and preference and we can find an email that does not suck.
(Hint: there never was one and never will be! Let the downvotes descend upon me!)
[0] http://www.mutt.org/ I pray they never change this beautiful site and its header.
Greg Kroah-Hartman told me on LKML: "try mutt, you won't regret". I did try, and I don't regret indeed - I migrated to it :)
Well, certainly he would agree. MS devs who needed to patch the Linux kernel could not even get Outlook to do git-patch properly, as the old Linus anecdote went.
http://stackoverflow.com/questions/9814276/git-patch-file-at...
http://stackoverflow.com/questions/9814276/git-patch-file-at...
Sounds like you want Lotus Notes :) I actually wish someone would recreate something similar.
So did they. I think its called LibreOffice now? Haha.
https://en.wikipedia.org/wiki/IBM_Lotus_Symphony
https://en.wikipedia.org/wiki/IBM_Lotus_Symphony
You're not the only one, I just migrated my email from Outlook.com to a self-hosted Novell GroupWise install (cheaper than paying Office 365 or Google Apps fees every month for eternity for three mailboxes for my family, no ads and data stays in my control) - so far I've been really happy with the desktop client and just how much I'm able to customize it. Sure, it's not super pretty, but it's not the worst.
Too many 'modern' email clients try too hard to create a new workflow for email, I get an email, I read it - if I care about it I file it away in a folder or flag it for follow-up (at which point it will show in my tasklist in GW regardless of where I move the item), if I don't care about it I throw it in the trash.
Too many 'modern' email clients try too hard to create a new workflow for email, I get an email, I read it - if I care about it I file it away in a folder or flag it for follow-up (at which point it will show in my tasklist in GW regardless of where I move the item), if I don't care about it I throw it in the trash.
A friend uses MailMate[0]. It seems to be a bit pricey (50 USD), but considering it shot the fundraising campaign for the next release by 170%[1], I'm sure there are fans here.
[0]: https://freron.com/
[1]: https://www.indiegogo.com/projects/mailmate-2-0-the-email-cl...
[0]: https://freron.com/
[1]: https://www.indiegogo.com/projects/mailmate-2-0-the-email-cl...
I use this app every day and never heard about the campaign. I guess their marking wasn't really top notch, which even makes the shot even more impressing.
> My kingdom for a unified inbox and a Mac app. I would never leave Google Inbox again. It’s almost perfect – stable, amazing Google-powered search, snoozing by time and location, all the bells and whistles.
I've used Fluid.app[1] to create 'standalone applications' of webpages. It's always worked great, and is almost what the OP is asking for for 'inbox'.
[1]http://fluidapp.com/
I've used Fluid.app[1] to create 'standalone applications' of webpages. It's always worked great, and is almost what the OP is asking for for 'inbox'.
[1]http://fluidapp.com/
There's also Wmail[1], which I've been using for the past few months. It's essentially just an Electron wrapper around the web app, with all that entails. It's worked fairly well for me, though, and enables easier inbox switching.
[1]: http://thomas101.github.io/wmail/
[1]: http://thomas101.github.io/wmail/
Huh. Thanks for posting this, I actually hadn't heard of it. It avoids some of my complaints about Boxy[1]; I'll have to give it a try.
[1]: http://www.boxyapp.co/
[1]: http://www.boxyapp.co/
Great, I hope it works for you!
I've actually done this as well, but it's still not super satisfying. There's still no unified inbox so I have to have two tabs open in the Fluid app, and I don't get notifications or any nice native features like that. On that same grain, Boxy[1] is an unofficial Mac app wrapper for Inbox that adds notification support, but is even worse because it requires me to have a window open for each Gmail account (no tabbed interface).
[1]: http://www.boxyapp.co/
[1]: http://www.boxyapp.co/
For notifications, there are many Chrome extensions that add that feature to Inbox.
There may be extensions for other browsers as well, but I'm not sure about that.
It would be nice if Google added native support for notifications like they did with GMail though.
There may be extensions for other browsers as well, but I'm not sure about that.
It would be nice if Google added native support for notifications like they did with GMail though.
It's still very useful sometimes to have an offline copy of your mail, though. I also feel that email is something so integral that it should be a native app.
I've been using Mail.app for years and it's not bad for my needs, but it doesn't have any fancy features, for sure. But the fact that it's native and works decently with mail providers and allows me to manage multiple inboxes quite easily is enough for now.
I've been using Mail.app for years and it's not bad for my needs, but it doesn't have any fancy features, for sure. But the fact that it's native and works decently with mail providers and allows me to manage multiple inboxes quite easily is enough for now.
I feel Email has evolved organically since eons and what we have today is like the way humans have evolved over millions of years. While the standard look and feel remains the same pretty much, it has become one's identity for receiving messages on the web of all forms and types, of all needs from commerce to friends to business.
It is also a database of all our past communications. Apart that mobile adds further complexity. It is likely that any one answer for it can miss out things in the enthusiasm to bring out a simpler version or in the over-enthusiasm to make it complicated than what it should.
It is hard to quantify the "needs" as it caters to a wide audience as a one stop answer. Slack like app can take away the professional side, or a Facebook can take away the social side, but no matter what, you still need a email as it serves as the identity to reach out for the Web applications.
So whoever is building a new email App needs to keep all of this in mind and come out with something nifty yet powerful.
It is also a database of all our past communications. Apart that mobile adds further complexity. It is likely that any one answer for it can miss out things in the enthusiasm to bring out a simpler version or in the over-enthusiasm to make it complicated than what it should.
It is hard to quantify the "needs" as it caters to a wide audience as a one stop answer. Slack like app can take away the professional side, or a Facebook can take away the social side, but no matter what, you still need a email as it serves as the identity to reach out for the Web applications.
So whoever is building a new email App needs to keep all of this in mind and come out with something nifty yet powerful.
This is off topic, but the typeface in that article looks terrible in Firefox on Windows 8.1. All of the lower case e's are missing the horizontal line:
http://imgur.com/ShUxi15
Does it look okay in your browser?
http://imgur.com/ShUxi15
Does it look okay in your browser?
Hmmm that's not great. It looks fine for me in Firefox/Chrome on Mac. The base font is a Google webfont though (Merriweather) and sometimes I see those have random rendering problems for whatever reason.
I use palemoon. They are right now extremely upset that Google fonts is buggy, doesn't comply to standards, and Google not only refuses to fix it, but keep making changes that break palemoon workarounds. the project lead has seemly in the past months working more to create google font workarounds than on the rest of the browser.
This doesn't really surprise me. I should really download the ttf's and such and font-face it myself. My blog is built on a Jekyll theme that I lightly modified and as I recall didn't mess with the fonts at all.
firefox motto is take back the web.
start by disabling custom fonts. select decent defaults you like to stare at. done. perfect legibility, saved bandwidth, faster page load times, less data leakage to google (who magnanimously host all those fonts)
start by disabling custom fonts. select decent defaults you like to stare at. done. perfect legibility, saved bandwidth, faster page load times, less data leakage to google (who magnanimously host all those fonts)
I just realized I can be uniquely identified due to my personal font choice being a custom font by capturing the calculated value of font-family. I suppose I can rename the font to "Arial" and delete Arial and replace it with my custom font and call "Arial" instead of the proper font name.
I wonder if that would actually break any programs that try and use Arial as the default font... hmm...
I wonder if that would actually break any programs that try and use Arial as the default font... hmm...
won't save you. if you're that targeted they can also measure font sizing, or render it in a canvas and inspect the actual font shape.
I tried all mentioned in the post and comments. I am currently using MailMate (https://freron.com/) It is still lacking, but does most of the things I personally need.
I've used Gmail since 2004, when they had invites and everyone wanted one. I use Outlook for iOS at work and think it's great, although there's issues getting signatures to transfer when your company uses Sharepoint.
Email is a non issue for most people because most people just use a web browser and a mobile app. For the record, I wasn't impressed with Outlook for the Mac.
Email is a non issue for most people because most people just use a web browser and a mobile app. For the record, I wasn't impressed with Outlook for the Mac.
On the other hand iOS doesn't really support the use of alternatives to the built-in Mail app. I was trying Google Inbox in a new iPad where I didn't configure the built-in Mail, but then I wanted to mail a link to a web page from Safari and I couldn't. It seems is not possible to tell iOS or Safari that I want my emails to be sent through Inbox :(
> I was trying Google Inbox in a new iPad where I didn't configure the built-in Mail, but then I wanted to mail a link to a web page from Safari and I couldn't.
Sure you can – tap on the share button, then scroll to the Gmail icon and tap on it. A new email will be started in the Gmail application containing the page title and URL.
If you don't see the Gmail icon straight away, scroll to the end of the list, and tap on More… to add Gmail to the list.
Sure you can – tap on the share button, then scroll to the Gmail icon and tap on it. A new email will be started in the Gmail application containing the page title and URL.
If you don't see the Gmail icon straight away, scroll to the end of the list, and tap on More… to add Gmail to the list.
Every time I experiment with a new e-mail client, I return fairly quickly to Mail.app.
I like Mail.app.
Maybe that's a personal deficiency.
I like Mail.app.
Maybe that's a personal deficiency.
Give me a decent way to digg out and manage attachments and I'd be over the moon.
As far as digging out attachments across multiple messages in Mail.app (described here[0]):
- Select a group of messages (could be Command-A in a smart folder, for example).
- Then choose "File -> Save Attachments..."
- Finally, choose or create a directory where you'd like the attachments to reside.
As for managing them, I would imagine that would vary for each person in how they like to work and what they seek to accomplish.
0 - http://email.about.com/od/macosxmailtips/qt/How-to-Save-All-...
- Select a group of messages (could be Command-A in a smart folder, for example).
- Then choose "File -> Save Attachments..."
- Finally, choose or create a directory where you'd like the attachments to reside.
As for managing them, I would imagine that would vary for each person in how they like to work and what they seek to accomplish.
0 - http://email.about.com/od/macosxmailtips/qt/How-to-Save-All-...
Have you seen "Filed" by Emmerge? https://medium.com/posts-from-emmerge/filed-an-ai-assistant-...
It's not a deficiency, I'm a firm believer in people using what they enjoy. Life is far too short to tell people they're wrong because of what they use to read their email.
I tried most of the ones on the list. I'm currently using [Spark](https://sparkmailapp.com/) not as buggy as Airmail, mailbox many of the features I liked from both.
I've tried Spark too; I kind've slotted it under the "others" in the "needs Mac app" category. I didn't really feel it did anything better than EasilyDo Mail (which has more personal assistant type features) or Boxer (which is more customizable) if I was going to go for an app on iOS only.
I love Spark but they don't seem to have a clear way of making money so I'm concerned about its future.
My biggest gripe is that it doesn't integrate with their calendar app; which, I think is very silly.
While I also think email apps are not great, especially when trying to find a unified experience with macOS and iOS, I think CloudMagic for iOS is pretty good and Nylas N1 for macOS is also very good. maybe if N1 comes to iOS..
Nylas is pretty bug-ridden at this point, and they have committed to a pretty crazy pricing model ($7 per month). It's hard to get behind it.
> they have committed to a pretty crazy pricing model ($7 per month)
I actually sort of prefer email apps with this sort of pricing model; it makes me think they're trying to be financially sustainable rather than just getting acquihired in a year or two. I would definitely pay $7/mo for the right email app. (But I don't know if N1 is it; I added N1 and some other Mac-only email apps to the original article.)
I actually sort of prefer email apps with this sort of pricing model; it makes me think they're trying to be financially sustainable rather than just getting acquihired in a year or two. I would definitely pay $7/mo for the right email app. (But I don't know if N1 is it; I added N1 and some other Mac-only email apps to the original article.)
I used Nylas for a while when it first came out and liked it alot. Then out of the blue one day I started to get errors that it couldn't/wouldn't sync, spent more time than I should've trying to get it to work again with no success, so I had to ditch it.
If you're willing to give it another go, I'd love to help debug this for you. Shoot me an email? (I work at Nylas.)
I haven't tried Nylan N1 yet, but I've heard some decent things about it. To be honest I don't usually bother trying apps unless they have an iOS version (whereas while not having a Mac version is still a dealbreaker, I'll still give it a try on iOS).
The problem is the economics of non-SAS applications: getting an email client right is hard and the free alternatives are good enough for plebe-tier users. $4.99 a one-time pop isn't going to get it done.
I'm pretty happy...
OSX: Mail.app does the job very well, little bloat.
Linux: I like Geary. Lean but not as good as Mail.app though
Windows: Mailbird. Light but also not as good as Mail.app
For Business I have Outlook.
None is perfect but all do what I need in the corresponding context.
OSX: Mail.app does the job very well, little bloat.
Linux: I like Geary. Lean but not as good as Mail.app though
Windows: Mailbird. Light but also not as good as Mail.app
For Business I have Outlook.
None is perfect but all do what I need in the corresponding context.
Here's another new one to try http://dejalu.me/ (from one of the creators of Sparrow)
Can one use k9 with Gmail? I've never tried.
Yes. I do for Google Apps now for years. Why I love it, server-side IMAP search, which means you use server-side search not the Gmail way, but as part of the IMAP protocol.
Is it as fast and perfect? No. But I do not have to store so much damn email or increase the efficiency of Gmail's real-time tracking of my butt all over the world.
Is it as fast and perfect? No. But I do not have to store so much damn email or increase the efficiency of Gmail's real-time tracking of my butt all over the world.
Yes. Any IMAP client should work and I'm using K9 and TB successfully.
Geary is actually quite a nice e-mail client to use if you use GNOME or something close to GNOME (Unity, Cinnamon, Pantheon).
I just use gmail, it seems ok to me.
just use mail.app
email by definition sucks
Why? I haven't seen a single alternative, ever, that comes close to providing the flexibility, versatility or openness of email. Despite the ability to be pretty much what ever you want it to be, it's still a remarkable simple protocol.
Really the only thing email is lacking is good end-to-end encryption.
People suck at writing emails though. I partially blame Outlook, but also the unwillingness to wanting to read and write well. So much of the hassle of email has to do with volume and the sender not re-reading their writing before hitting send.
Really the only thing email is lacking is good end-to-end encryption.
People suck at writing emails though. I partially blame Outlook, but also the unwillingness to wanting to read and write well. So much of the hassle of email has to do with volume and the sender not re-reading their writing before hitting send.
If you're looking for a modern integration with PGP, you might consider checking out the recent update of N1. More on that here: https://nylas.com/blog/pgp (I work at Nylas.)
Even if you are not a technical user, you should respect the fact that proprietary formats will bite you. Look how many this guy alone used. If you use opensource, even, the mbox and mh all email, one giant file paradigm is all nice until it is corrupted.
I wish more clients respected Maildir underneath, or tried to bend the truth on Windows FAT32 and NTFS ad the ; in path names limitation is a pain.
https://en.wikipedia.org/wiki/Maildir#Filesystem_Compatibili...
Sadly even Thunderbird has struggled to re-engineer a Maildir subsystem where it was never intended. Show me any email client devs who had the khutzpah to even dare that.
https://bugzilla.mozilla.org/show_bug.cgi?id=845952
But you have a lot of safety in spreading it across files, and you can throw dumber full text search at it, shell scripts, and a lot more flexibility over all.
Sadly, some Unixisms will never escape Unix culture. As someone who has watched people screw 10+ years of email in Thunderbird n>1 times, I wish for the love of God everyone would use Maildir in the client, regardless of interface, free or not, et cetera.