As for the mockups, I’m happy to see mail is being re-worked

The only bit I’m really worried about is how threads would work in these suggestions. I am often involved in discussions in very long and branched-out threads and fear that flattening it all out in a conversation-style time-only-based manner would make it very confusing to read.

Regarding moving the folders¹ into a pull-down/pop-up/whatever menu and having only the favourite folders and searches in a side-bar, I initially was against it, but I slept on it and it might indeed be good to have the user concentrate on that one (virtual) folder, that one thread and ignore the unread mail counts.

For the same reason, I think that a separate window for reading mail might not be a bad idea – if the threading gets done right! It might be a good way to concentrate on the mail, thread at hand. Especially if the mail list (=main) window gets dimmed out behind it and the keyboard navigation is made easy.

Also I do realise that some people use their e-mail inbox in the Getting Things Done way (personally I don’t, even if I use some GTD methods for organising myself), but I don’t think we can make that assumption for everyone. Different people use e-mail in different ways, but pretty much everyone does, so the new interface should either be a jack-of-all-trades or we should clarify which audience should which of the several new interfaces please..
—
[1] Since I have to follow many mailing lists, I have two e-mail accounts (work/FSFE and private) and several (two dozen?) folders that are organised in a tree. I would love to finally be able to see KMail just turn off my work e-mail when it’s outside of the Work Activity and pop it back up (and ignore the private mail) when it’s back in the Work Activity.

KMail is not going to die.
It is a full-featured enterprise groupware email client and therefore has much much much more features than any individual email user would ever need. What KDE lacks is an email client for "normal people" (which still don't want to rel exclusively on IMAP as Trojita does), That doesn't mean we shouldn't support professional email use with the client we're designing (or mailing lists, because we want to use it ourselves, don't we? ), but I think we can leave the overblown crazy enterprise usecases to KMail.

colomar wrote:KMail is not going to die
[…]
but I think we can leave the overblown crazy enterprise usecases to KMail.

Even in that case, it would be good to identify these enterprise use cases, so a) we know what not to aim for in the lightweight app and b) to figure out how KMail could be made better.

I wouldn’t be surprised if the enterprise and crazy usecases did not overlap much

Nice work!

hook wrote:

colomar wrote:KMail is not going to die
[…]
but I think we can leave the overblown crazy enterprise usecases to KMail.

Even in that case, it would be good to identify these enterprise use cases, so a) we know what not to aim for in the lightweight app and b) to figure out how KMail could be made better.

I wouldn’t be surprised if the enterprise and crazy usecases did not overlap much

Yes, it would definitely be good to identify these usecases! My previous job title was "Project Manager User-Centered Design", so I'm all for a UCD (or actually HCD a.k.a. Human-Centered Design nowadays) approach.
We'll have to keep it light-weight for it to work for people who do it in their spare time, but even light-weight HCD is better than no HCD.

hook wrote:An even crazier idea: how about we let the end-user re-arange his interface the way he wants. I imagine a crossover between how Calligra and the newest (30 and newer) Firefox.

Sounds like a fun idea for the future. It is far out of reach for now though.

"Makes it super easy for designers" was a bit misleading I am afraid. The API will enable QML developers to write email clients without having to look at "scary" C++ code. Writing / designing the application with QML is still a lot of work that wont magically go away.

I am planing to add standard UI components (full mail view, mail editor, mail list items...) in a later iteration. That will make it very easy for someone with little QML knowledge to write a very basic client. Creating a polished one will still be a lot of work.

We can revisit the idea of a (fully) customizable client once the above is done. I am currently not interested in developing such a thing though. Maybe someone else will.

colomar wrote:Pretty much all modern screens use a widescreen format, so usually vertical space is much more precious than horizontal space, so putting things next to others instead of above/below often makes more sense.

True. That is why I prefer to have the mail view right of the mail list instead of underneath it and it is also why it makes more sense to have a separate window for the composer rather than having it "inline" in the mail view. Having separate window detached from the rest of the application has other benefits as well. We can change the state of the app to look at another email for reference without disturbing the writing of the mail or take the (smaller) composer window to another screen and look have a different application displaying something for reference.

having the buttons for "reply & forward" inline might make sense, when we want to display email threads instead of a single mail in the mail view.

colomar wrote:Yes, it would definitely be good to identify these usecases! My previous job title was "Project Manager User-Centered Design", so I'm all for a UCD (or actually HCD a.k.a. Human-Centered Design nowadays) approach.
We'll have to keep it light-weight for it to work for people who do it in their spare time, but even light-weight HCD is better than no HCD.

Yes! Let us find out who our "normal" users are before we design for them.
How can we approach this?

a new try, with a sidebar and threads. The reply function is inside but if one replies a new window could pop up. The folder sidebar on the left could also be a list with the names of the folders, the sidebar on the right is for to dos, important contacts and mails. i didnt include a search function but it could be above the mail view.

http://tradukt.ch/owncloud/public.php?service=files&t=25be95303760fdbe86e5732fa191d713

mbohlender wrote:

colomar wrote:Yes, it would definitely be good to identify these usecases! My previous job title was "Project Manager User-Centered Design", so I'm all for a UCD (or actually HCD a.k.a. Human-Centered Design nowadays) approach.
We'll have to keep it light-weight for it to work for people who do it in their spare time, but even light-weight HCD is better than no HCD.

Yes! Let us find out who our "normal" users are before we design for them.
How can we approach this?

Step 1 would be: Identify the target user group
Step 2: Find a representative sample for that user group
Step 3: Interview and observe them to find out how they use an email program

The target user group has to be defined first, a product should never be made for "everyone", because then it lacks focus.