Linked by Thom Holwerda on Wed 11th Jul 2012 01:24 UTC
Graphics, User Interfaces "We're able to produce absolutely stunning websites and mobile apps with great interaction design. Interfaces that are smooth and fun and let us understand information without even trying. But when it comes to email clients, we get a bit of a boring feeling, like using an old piece of software from 10 years ago. I think we can do better. So let's do that." Great ideas and beautiful design by Tobias van Schneider, but why he would forcefully shoehorn this clearly digital UI into Mac OS X is beyond me. It has no place there. This just screams Metro.
Thread beginning with comment 526419
To read all comments associated with this story, please click here.
(Re)Thinking
by sorpigal on Wed 11th Jul 2012 17:15 UTC
sorpigal
Member since:
2005-11-02

There are problems with "email." This guy doesn't know what they are or how to fix them, but he senses it.

What are the issues? What are the causes? What are the solutions? I can identify some of these things.

The first 'problem' with "email" is that it's email and not something else. What I mean is that email as such has no problem, but the things people want to do with the concept are out of sync with the protocols, formats and interfaces that exist. Some people turn to so-called alternatives (wave, facebook messages, etc) but these are not replacement for all classes of use.

The way people want to use a non-instant, asynchronous, one-to-many, arbitrary-sized person-to-person and person-to-machine means of communicating and exchanging data is at odds with the system we have today which is called email.

In a corporate environment email is a different thing than it is to a private user. A kernel developer uses it differently from a college student, should such a student use it at all (which is no longer certain). It's unlikely that all users could agree on an improved UI, because they don't agree on the current UIs.

The problem with the article's author's attempt to design a new "email" UI is that it is addressing the cosmetic and interactivity problems of a small subset of use-cases without addressing the architectural issues which lead to the problems he sees, and to the problems he doesn't see. If you identify how you *want* to use "email" and design a new system that makes such usage natural then the UX problems the author identifies, and many others, will fade away without effort. If you attempt to bolt on a new coat of paint (if I may mix my metaphors) then you will perpetuate the fundamental flaws of the structure underlying your paint and prevent entire classes of users from seeing any benefit of your "improvements."

Some things to keep in mind. No matter what replaces email it will have certain characteristics: It will have no central authority, it will use identical-looking identifiers (user@host, etc) and it will also be called email.

Reply Score: 4