jerakeen.org

created 17 January 2010 in notes tagged email and writtenwhiledrunk.

Sorry. I’m cynical about this new email client thing that Brent has kicked off. Don’t want to be a source of stop energy. But quite aside from my normal IT‘S DOOMED instincts, I think they’re solving the wrong problem.

There are people on the list saying that an email client needs to be aware that people have 3 computers and a phone nowadays. There are people wanting it to be properly mailing-list aware so that you don’t have to set up manual filtering rules. There are people wanting it to be more understanding of current email conventions, so it (for instance) will trim automatic mailing list footers from replies so you don’t get 30 lines of repeated cruft.

But the first of these goals undermines every other clever feature. Most of the current problems with email are inherent to IMAP, because IMAP is just a heap of folders with too many configuration options (folder prefix, for instance..). IMAP doesn’t do magical mailing list filtering, so it doesn’t matter if I have a clever client that does, because my phone won’t benefit from any of it. And if I reply to a mail from my phone, the footers won’t magically get trimmed, my phone doesn’t do that. And if your phone doesn’t sync with your desktop address book, you won’t be able to compose mail to your friends anyway.

Google Mail gets this right. They don’t do IMAP except as a backwards-compatible API to their mail store. They got to start again, and properly reinvent what mail is. Mailing list and spam filtering is done on the server side, rather than relying on the client to pull down all your mail, sort it, and push it into new folders. (Yes, there are server-side filtering systems. I don’t know any GUI clients with first-class support for them.) There’s one address book, and one place for that annoying ‘people I reply to go into my address book’ setting, and my mail sig, and all those other stupid things you need to tune every time you get a new email client.

The Android GMail client is a perfect example of what a client looks like in this world. It talks to the (secret / private) GMail API, it does offline mail reading, and queues actions so you can archive / filter / whatever mails while offline and it’ll push changes later. You can read and write mail. It doesn’t try to do anything clever, because anything clever done on one client isn’t reproduced on any other client. And if I don’t have a client on my current computer for GMail, I can use a web browser, and still get all the features of the server. I use the web gmail interface for everything anyway, because it’s better than any GUI client I’ve got.

GMail is a long way from being perfect. I’m not saying it’s the Solution. Maybe you disagree with the auto-conversation threading, and there’s the large nit that you’re not allowed to write your own client on the GMail API (due to the Google terms of service, plus you’d have to reverse-engineer it anyway). But I believe that Brent’s effort is never going to produce a truly great mail client because ‘Uses IMAP‘ is one of his core requirements.

created 13 February 2009 in stream tagged email, folders and sync.

New twitter: @ianbetteridge I'm happy for email to be checked only on-demand. I have many folders anyway. But calendar/contact sync is important.

http://twitter.com/jerakeen/statuses/1205766937

created 09 February 2009 in stream tagged email.

New twitter: I have no email. Luckily, everyone I know *also* uses tuffmail, so they can't send me any.

http://twitter.com/jerakeen/statuses/1192749793

created 13 October 2008 in links tagged apple, email, mail.app, signature and software.

Mail.app signatures are .webarchive files in your Library folder. You can create arbitrarily complex ones by making your own webarchives from custom HTML using Safari, and putting them there. Complicated, but nice that it’s possible.

http://allforces.com/2006/04/14/css-signatures/

created 15 August 2008 in links tagged css, email and html.

sending HTML email is hard. A guide to what things do and don’t work.

http://www.campaignmonitor.com/css/

created 12 December 2006 in links tagged email, filter, imap and sieve.

crazy language for filtering mail on the server side - I’ll need this if I want to move to tuffmail. I like my server-side filtering.

http://www.rfc-editor.org/rfc/rfc3028.txt

created 20 July 2006 in links tagged email, software and windows.

http://shellter.sourceforge.net/evolution/

created 04 November 2005 in links tagged email, mac, mail and software.

I love this thing - I use it to mark mail as spam, so it’s easy and I don’t have to touch the mouse.

http://www.indev.ca/MailActOn.html

created 03 October 2005 in links tagged cool, email, imap and javascript.

http://www.roundcube.net/

created 19 October 2004 in links tagged email and mac.

http://www.tikouka.net/mailapp/

created 13 August 2004 in blog tagged blog and email.

Muttley caused this train of thought. Blame him.

Thoughts for a blogging toy

Here’s something I might do. Every time I post a blog entry, people on a list could get a mail with the subject, contents, etc, just like I actually just sent the thing to a mailing list. People can reply to the mail, and their replies get put as comments on the blog entry, as well as mailed to the rest of the list. People posting comments from the web page, their comments go out to the list. So if you ignore the mail aspect, it’s a traditional blog, and if you ignore the blog aspect, it’s a traditional mailing list, albeit with the caveat that only the owner of the blog can start a thread. And hell, that’s optional, you could allow free posting…

Once you do that, of course, the blog could be viewed as merely a web based archive for the mailing list, just with a much nicer web interface than most mailing list archives. Blogging software has put a lot of effort into managing date-based information archives, much more than mailing lists. On the other hand, mailing lists have put much more effort into managing threaded conversations than blogs have.

This blurs the line about what it is, of course. I’d probably initially implement it as a blog, with a bit of mail glue attached, but I suspect the more elegant way would be to have a mailing list with a very sophisticated web archive attached to it, one that handles threads as entries, and that allows you to post to the mailing list through the archive page. The distinction between the two rapidly becomes moot, of course.

Hmmm. Must play with siesta

(later) More Rambling

So, muttley has rambled as well. Interesting. He has some ideas about multiple blogs tying together somehow that I’m not seeing a way of making work in my head, and I hate talking about things I can’t construct a nice working mental model of, but he’s right, it would be nice to have a system of mutliple blogs tied together. Like this.

You get thread ownership problems, though. As things stand, I control a conversation on my blog completely. (well, if I had comments working yet…). That’s ok if the blog is also a mailing list, because I’d control the mailing list server completely as well. But if, say, threads I started were hosts on my blog, and threads paul started were hosted on paul’s blog, we get issues of potential censorship, and people picking the thread to comment on based on who’s blog the start thread was on.

That issue asside, it’s quite easy to adapt the first model espoused above to this sort of thing. All the participating blogs would send stuff to the same mailing list, and the mail reciever would use some smarts to determine which mails were replies to which blogs, and post comments appropriately. All doable. For the second, more elegant, solution, where the blog is merely one way of representing the ‘message’ objects that the back-end understands, we’d either need to host all the blogs in one place, or have a distributed server, or something. Not sure.

Tell you what. I’ll actually implement something at some point, and we’ll see how easy the collaborative stuff is then.