Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Re-Designing the classic email client

vanschneider.com

Post reply on HN
Print view View original

161–170 of 222 posts

Re: Re-Designing the classic email client

#161

Post by stcredzero »

Tloewald wrote: post #143
blhack wrote: post #62

Earlier quoted context omitted.

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

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.

There seems to be a whole world or metadata involving communications preferences which we've just barely started to scratch.

Re: Re-Designing the classic email client

#163

Post by cdcarter »

pvidler wrote: post #140
Timothee wrote: post #81

Earlier quoted context omitted.

"2. A "messages" app (which abstracts out two different message systems)" Is the abstraction a plus or a minus in your opinion? I'm asking because on one hand you're asking for a unified communication app, but on the other, the way you wrote that part, it sounds like a bad thing. Taking this specific example, I think it shows that aggregating communication media is difficult and maybe not a good thing. In Messages, S…

Even the messages app is almost too confusing, let alone combining everything else as well. As far as I understand it, if I send an SMS then anyone with a signal can get it; if I send an iMessage, then they need an internet connection or it won't go through -- is that right? If so, it's a pain to mix them up, as many areas do not get good 3G coverage (especially indoors) but excellent phone signal. Surprisingly few o…

Messages will send as an SMS if the iMessage isn't delivered in a reasonably short amount of time.

Re: Re-Designing the classic email client

#164

Post by tambourine_man »

tambourine_man wrote: post #21
ben0x539 wrote: post #5

holy shit just write your web pages in html, not everything needs to be a crazy javascript abomination where the body text fades in slowly

If it falls back gracefully, why not? As pointed by others, the site just is a bunch of JPEGs, which is a very bad choice indeed (accessibility, search engine access, speed, etc). But aesthetics do matter. If done properly, you could just grab the content and use your favority reader with a click of a button in case you desagree with the author's taste.

Of course it doesn't.

I'm not defending the site, I'm saying there is nothing wrong with a JavaScript intensive site, if properly done (this one isn't).

Re: Re-Designing the classic email client

#165

Post by sramsay »

I take the point about clutter and typography, but the best email client I have ever used is nmh " rel="nofollow">http://www.nongnu.org/nmh/>, largely because I was able to hack together this kind of work flow effortlessly. I'm always marveling at how modern clients lack the capabilities I have in a piece of software that has changed little since the RAND Corporation put it together decades ago.

Re: Re-Designing the classic email client

#166

Post by bmelton »

hapless wrote: post #106
bmelton wrote: post #47

Earlier quoted context omitted.

In all fairness, running a speed test against a site that is currently on the front page of HN is a little bit of a stacked deck, isn't it?

Isn't that when it matters the most?

Perhaps, but that completely misses the point.

The HN effect completely crashes lots of servers. It's not at all unlikely that the page appears snappy most of the time and is simply so ill-performant at the moment because it was being hammered.

Not saying that's true or false, mind you; Just that when something is on the front page of HN is perhaps the least likely time to gather a representative benchmark.

Re: Re-Designing the classic email client

#168

Post by alexwolfe »

I think it's an interesting UI design and concept and has some strong visual appeal to it. I realize a lot of the concepts in this design have been tried before in one way or another. However, just as important as the design is seeing how if actually feels. I think it certainly looks good in photoshop but the trick is executing in a way that makes it feel "right" too. Any plans for development?

Re: Re-Designing the classic email client

#169

Post by a3_nm »

rdl wrote: 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…

* Full text search and tagging. (Hence, http://notmuchmail.org/)
Post reply on HN