Microsoft (Outlook+Exchange+Lync (formerly Office Communicator))
Re-Designing the classic email client
171–180 of 222 posts
Re: Re-Designing the classic email client
#172I feel sorry for the author here. Its very easy to criticise and hard to create. There are a lot of people here trying to tear him down. If you know better - stop sitting around on Hackernews and go make it. If not, then stop whining when someone is trying to do something constructive - or at the very least provide some points you think he can fix and be nice about it, not like a petulant 12-year old...
Re: Re-Designing the classic email client
#173Don't fix email. Fix communication. Why, on my iPhone, do I have: 1. An email app (which required a major update to unite mail boxes) 2. A "messages" app (which abstracts out two different message systems) 3. A phone app 4. A contacts app 5. Twitter 6. Facebook 7. Skype What I want to do is (a) send messages to people (I don't care how), (b) check messages I've received (from anyone, using any method), (c) manage my…
In my kitchen I have: 1. A fridge 2. A coffee machine 3. A stove 4. A microwave 5. A blender 6. Mixing bowls 7. Measuring cups All I want to do is feed myself. Why on earth do I need to have so many different things to do it? To...most people, having a separate "app" for things that do wildly different things is a good . Skype and email fill completely different roles to me, and I suspect they fill completely differe…
> If it's late, I might send my friend an email instead of an SMS because I know that the SMS will probably wake her up, and the email won't.
> Being able to control this is a good thing.
those are great points, and a solution that can really replace the 18 methods we have of sending messages today would take that into account. Email today has this lame "importance" flag nobody uses but certainly, if we could get over the familiarity hump, having a unified kind of message where we can configure how it travels and how it alerts the receiver (not to mention, that the receiver would be able to route these various classes of messages in any way he/she sees fit) is not a huge technical issue.
Re: Re-Designing the classic email client
#174This guy has teeny tiny letters hardcoded into JPGs on his web site. I can't read it. Fortunately, this means I can disregard what he has to say about UI/UX. Sometimes the medium IS the message.
Any other areas of your life where you throw the baby out with the bath water? Someone over salt some food so you assume that everything they say or do with food is wrong? Refuse to ever get a lift with a friend because they forgot to indicate once so obviously they can't be trusted to drive? I'm not wild about the way he's presented his website but I'm still willing to look at his ideas about e-mail workflow with an…
Someone's Photoshop mock-ups could have new ideas to introduce, yes.
This doesn't. It's just triage of messages as they come in and an all-attachments view, coupled with hand-waving about typography and design by someone who hopes a developer will contact him.
Re: Re-Designing the classic email client
#175Earlier quoted context omitted.
That's cufon, give the guy a break. That was cutting edge two years ago. We've gone from no-one but IE supporting font-face to lots of people in a remarkably short-time. HTML Zealots! I despair sometimes :)
He uses cufon on the website, but this page is just a bunch of jpegs — mail1.jpg, mail2.jpg, etc.
Exactly. Images-for-text was never cutting-edge.
Re: Re-Designing the classic email client
#176I comfortably ignore any comments about email and what it should be from anyone who hasn't used a text email client (well configured) like mutt, mh, elm, or an emacs mode for at least 100 hours. The only real complaints I have about email with a well-configured text client are: * HTML mail from idiots * Syncing on multiple machines, with offline mode (IMAP is ok, but you want to keep full repositories on laptops for…
I comfortably ignore any comments about email and what it should be from anyone who hasn't used a text email client (well configured) like mutt, mh, elm, or an emacs mode for at least 100 hours.
I comfortably ignore anyone that says "email needs to be fixed" from clients to the underlying system - it's awesome and nothing about it needs to change. People just need to learn to use it better.
I run everything through gmail, but I use my own domain (via an external SMTP server), so if gmail goes down I can just route mail directly to another machine.
I use fetchmail to POP everything off from gmail and I read that in pine. It gets everything regardless of filters, except spam.
My android synchs with gmail (obviously) and using the gmail app I can send as my "real" email address (and this scales obviously so I can send as any of a number of addresses I need to). I make heavy use of filters so I only get relevant stuff on my phone.
My daily ritual is to sit down at pine and scan non-vital email (such as newsletters and mailing lists etc.) that I didn't get on my phone because I filter stuff so heavily, then for each email apply the "GTD" approach of doing anything that can be done immediately, or forwarding it to a Basecamp todo list (using mailmanagr.com) or a Highrise task (depending on whether it's sales related or actual work that I have to do).
This generally takes me less than 30 minutes and is a great triage exercise.
Instead of teaching kids how to code in schools, let's start by teaching them how to use email! We used to learn how to write letters, why aren't we doing advanced email training in schools?
Re: Re-Designing the classic email client
#177Earlier quoted context omitted.
While I see a phone call as fundamentally different from an email, I don't see SMS as different. In fact, I see it as a really lame competing implementation of the same basic idea that deserves to die as soon as possible.
Funny, I see SMS as an improvement. Enforced brevity is an improvement IMO.
The only functionality that SMS provides and email doesn't (in most countries) is network notification, which can be easily fixed. It would be relatively easy to replace SMS with email without users noticing the difference.
Re: Re-Designing the classic email client
#178I comfortably ignore any comments about email and what it should be from anyone who hasn't used a text email client (well configured) like mutt, mh, elm, or an emacs mode for at least 100 hours. The only real complaints I have about email with a well-configured text client are: * HTML mail from idiots * Syncing on multiple machines, with offline mode (IMAP is ok, but you want to keep full repositories on laptops for…
Global directory across organizations
It sounds like a good idea- I used to think so, myself- but I've steadily been convinced otherwise by the (quite sharp) IT guys managing our directory.
Re: Re-Designing the classic email client
#179I comfortably ignore any comments about email and what it should be from anyone who hasn't used a text email client (well configured) like mutt, mh, elm, or an emacs mode for at least 100 hours. The only real complaints I have about email with a well-configured text client are: * HTML mail from idiots * Syncing on multiple machines, with offline mode (IMAP is ok, but you want to keep full repositories on laptops for…
Global directory across organizations It sounds like a good idea- I used to think so, myself- but I've steadily been convinced otherwise by the (quite sharp) IT guys managing our directory.
You don't want to give unlimited access, but once someone authorizes an individual as a contact, the contact should be kept up to date automatically if a phone number or email address changes.
(Also, partner organizations might want to share directories easily; I can see giving a full access to your directory to a contracting/temp agency you use, rather than giving them accounts. I'm sure there are better examples.)
Re: Re-Designing the classic email client
#180I comfortably ignore any comments about email and what it should be from anyone who hasn't used a text email client (well configured) like mutt, mh, elm, or an emacs mode for at least 100 hours. The only real complaints I have about email with a well-configured text client are: * HTML mail from idiots * Syncing on multiple machines, with offline mode (IMAP is ok, but you want to keep full repositories on laptops for…
I comfortably ignore any comments about email and what it should be from anyone who hasn't used a text email client (well configured) like mutt, mh, elm, or an emacs mode for at least 100 hours. I comfortably ignore anyone that says "email needs to be fixed" from clients to the underlying system - it's awesome and nothing about it needs to change. People just need to learn to use it better. I run everything through g…
Which part of email requires advanced training? The writing - covered by grammar, etc. The thinking - covered by critical thinking.
The spectacularly complex system you have set up to filter your email? That would be worth a semester or so. It's worth it for you, I'm sure, but the average person probably would collapse trying to set that up.