Live data from Hacker News

Re-Designing the classic email client

vanschneider.com

141–150 of 222 posts

Re: Re-Designing the classic email client

#142

Earlier quoted context omitted.

If I send 50 SMS to someone who is charged 10c per message, I have cost them $5.00. So I should care whether I send them an SMS vs. an email. Someone without a data plan doesn't have constant access to email. Maybe they only check it on a computer every few days. So if I want to send an instant message, SMS might be necessary. Randomly sending an email vs. an SMS does not "just work". Nor does forcing each person to…

Paying to receive an SMS makes absolutely no sense. Here in the UK, we pay to send them, not to receive them.

It's counted as one message each for the sender and receiver in the US. We are then billed simply by that number.

Re: Re-Designing the classic email client

#143
post #62

Don'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…

Software apps and physical appliances are very different, so your analogy is ridiculous.

When I email someone, software automatically routes it to the destination so I don't have to. Why should this not be abstracted across channels.

As for my trying to dictate how the recipient consumes incoming messages -- surely its more intelligent for each person to decide how they want to consume messages. I know some people who live in their SMS but ignore phone calls. Indeed the whole hierarchy of SMS / email / IM / phone / conference is very much in flux. Most people are probably more interested in who the sender is, not how they're sending.

But by your logic maybe I should use one app per person I talk to.

Re: Re-Designing the classic email client

#144
post #105

Earlier 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.

tl;dr will be the death of intelligent discourse.

There are lots of things I want to do with email that I can't do with SMS. Maybe half the emails I send could get across most of what they need to in 160 characters. Other recent messages included detailed tech support/troubleshooting, a list of equipment and design discussion with a partner about an application we're developing.

None of those would fit in 160 characters. There isn't even a way to losslessly compress them in to 160 characters. I can always write a short message when I only have a little bit to say though.

I also dislike twitter and like RSS. I'm evidently not in the majority.

Re: Re-Designing the classic email client

#145

Don'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…

The One Big App To Solve All Problems is the wrong way to go, in my opinion. From a coding standpoint, it's a maintenance nightmare. From a UI standpoint, it's nearly impossible to create something that is both easy to use and comprehensively granular. From a user standpoint, it's confusing as hell when that "one thing" doesn't work like it's supposed to.

Yeah, you're right in the sense of why do we need all this stuff? The answer is: because no one uses just one thing to communicate.

On a slightly different note: if someone messages you and is expecting a response, do you really need to try three or four different methods to send that response? Shouldn't the expectation be that you would send a response back by the method that they made the request?

Re: Re-Designing the classic email client

#146
post #34

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. 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…

If I can expand on your "HTML mail from idiots " -- HTML mail from non-idiots is pretty much a non-issue. A textual document with minimal markup renders well in a standard console email client. It's when an idiot sends you a highly-formatted email which is all-but-unreadable as straight text, that you've got issues. I'll add: the same highly-formatted emails are very likely to break horribly on handheld devices as we…

I also "love" when I receive "thank you for registering, click here to login", and after staring at the e-mail for a bit, seeing no links anywhere at all, I realize that the well-meaning-but-sadly-still-full-of-fail website operator that sent the message went to the trouble of providing a multipart/alternative with a text/plain body part, but implemented it as "strip the tags from the text/html part: that should be good enough".

Re: Re-Designing the classic email client

#147
post #146

Earlier quoted context omitted.

If I can expand on your "HTML mail from idiots " -- HTML mail from non-idiots is pretty much a non-issue. A textual document with minimal markup renders well in a standard console email client. It's when an idiot sends you a highly-formatted email which is all-but-unreadable as straight text, that you've got issues. I'll add: the same highly-formatted emails are very likely to break horribly on handheld devices as we…

I also "love" when I receive "thank you for registering, click here to login", and after staring at the e-mail for a bit, seeing no links anywhere at all, I realize that the well-meaning-but-sadly-still-full-of-fail website operator that sent the message went to the trouble of providing a multipart/alternative with a text/plain body part, but implemented it as "strip the tags from the text/html part: that should be g…

I have NO idea of what you're talking about ;-)

Re: Re-Designing the classic email client

#148
post #8

This 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.

The best UX designers I know are pretty horrible at HTML and CSS. Fortunately, that doesn't matter if they can communicate clearly through images.

While I agree that this piece would be strictly better as HTML, I'd rather see that people present their ideas somewhat sub-optimal than not at all.

Re: Re-Designing the classic email client

#149
post #28

MS Outlook has had something along these lines for years - they call it something else ("Quick Click" or something) but it allows you at least one-click colorization + task creation. It's not quite like he lays out but it's the basic idea of his "Actionsteps". I don't use it, and I would consider myself an Outlook power user. I have learned techniques that, quite frankly, just work better for me.

I use Outlook every day too, but don't really bother with the task tools that are built into it (even if it might (might!) integrate better with my email). It's too general-purpose. It's like giving me a full toolbox, and the only limit is my mind! I'd rather have a tool that is more purpose-built to handle my needs. These days I track todo-s in Trello and make sure my Inbox unread count stays at 0. That's it. The on…

I use the heck out of the appts and tasks - appts are "things that I have to physical participate in" (phone call, lunch) and tasks are "reminders". I would not survive long without those. I use Trello but only to manage a small team of tasks.

You said, "The only thing I'm missing is better attachment management" - to me, the worst part about Outlook is the search functionality. It's just awful IMO. I can deal with the crappy attachment handling/saving/etc but when it takes a week for the "Instant Search" thing to index my 2gb Outlook file, I get pissed haha

Re: Re-Designing the classic email client

#150
post #86

This person needs to try outlook. You see, there's a little flag you can click on next to the email with a task priority. And a todo bar/list which shows them in priority order. Not only has it existed before, but it really doesn't help that much. You still need to apply yourself to use it correctly. This doesn't change that. Sigh... but then I knew I was in for wheel re-invention as soon as I saw the "modern creativ…

Thank you. Outlook 2007 and 2010 have a) flags, b) user-taggable-color-coded categories, c) an extremely usable ToDo bar, and d) Xobni and a million other plugins that attempt to prioritize your incoming mail automatically.

I'm not saying Outlook works for me (it doesn't), but it's annoying that the author pretended Outlook doesn't exist, and essentially proposed his version of Outlook as a solution to the "problem".

Post reply on HN