Vision can work wonders for a project. My favorite example is Krita. They really took of when they decided not to be yet another image manipulation program but focus on sketching and painting. Here is their vision statement:

Krita is a KDE program for sketching and painting, offering an end–to–end solution for creating digital painting files from scratch by masters.

Fields of painting that Krita explicitly supports are concept art,
creation of comics and textures for rendering.

Modelled on existing real-world painting materials and workflows,
Krita supports creative working by getting out of the way and with
snappy response.

Heiko rightfully pointed out that we need a vision for our mail application in the making. The goal of this thread is to create such a vision that will give us direction and focus.

Alright. Vision time. Codename: NextMail

Let me start with a brain dump:

I want my Linux using friends and family to be able to communicate securely without having to think about it too much. The only way I can convince them of using NextMail, is if it allows them to do their mails in a more convenient (or at least as convenient) way as before. I also want to be able to use NextMail to handle my own mails.

Convertibles and laptops with touchscreen are becoming more common. We could aim for an application that adapts its UI to the current context (laptop + mouse / laptop + touchscreen / tablet). The underlying technology (QtQuick; Akaonadi) and the architectural approach (QML API that strongly separates the data + functionality form the UI) are basically made to make this happen.

Another example vision of a KDE application, KDE Telepathy:

"KDE Telepathy aims to provide Plasma users an awesome open
communication experience that gives users a reason to switch away from
proprietary services.

We provide rich text chat and video calls that aims to fit in
seamlessly with the Plasma workspace and to provide sharing and
collaboration features to KDE applications. We provide support for
closed services such as Facebook, Steam etc. but our primary focus
will always be on open protocols."

First attempt for a NextMail (that's just the development codename, btw) vision:

NextMail aims to offer users such a convenient way to read and write emails on a personal level that they will prefer it over browser-based interfaces, while supporting cryptographic protocols for secure and confidential communication.
It offers a simple default interface, which still allows access to more advanced features used in a personal context for those who need them.

By strictly separating the user interface from the underlying logic, NextMail's user interface can be adapted to different device form factors and adapt on the fly to different modes of convertible devices.

Liberally stealing from colomar:

NextMail aims to provide the most convenient and effective way to communicate confidentially by email.

The interface is intended to be simple by default but flexible enough still offer more advanced features when the user needs it. By strictly separating the user interface from the underlying logic, NextMail's user interface can be adapted to different device form factors and adapt on the fly to different modes of convertible devices.

Adding to the confident communication part:

NextMail aims to provide a convenient and effective way to communicate confidentially by email. It targets private users and enables even "non techie" ones to have private and secure communication by making cartographic features accessible and actively promoting them. NextMails UI is made primarily for convertible devices and adapts to their current mode. The interface is intended to be simple by default but flexible enough to still offer more advanced features when the user needs it.

So let me be the Advocatus Diaboli: Convenience and simplicity are contraindicated. KMail is convenient (and superior to similar tools) due to its threading, for instance. "Made primarily for convertible devices" sounds reasonable. But don't we have such a client? At least @bjoernbalazs worked on a project some years ago.

I believe NM's vision should deal with Kmail/Kontact. For instance, you could just strip 80% of options from Kmail to make it simple. So why not have a vision about "communication experience" coupled to activities, where NM is just one facet of the application. And to throw in another idea: If you want to handle mailing lists or newsletter beyond the receive from and sent to level, it makes sense to have a completely different client - or UI. Or there might be someone who controls and configures software by using email to cope with security restrictions (I don't remember his name). Maybe the latter is out of scope

Heiko Tietze wrote:Convenience and simplicity are contraindicated. KMail is convenient (and superior to similar tools) due to its threading, for instance.

We are hoping to get both. I don't know if we can do that, but I want to try. "simple by default, more powerful when needed" - @colomar

Heiko Tietze wrote: "Made primarily for convertible devices" sounds reasonable. But don't we have such a client? At least @bjoernbalazs worked on a project some years ago.

Yes. That was Kontact Touch and aimed at < 5" touch devices. My GSoC project (that @colomar mentored) was about "porting" KMail Touch to Plasma Active (different sceen sizes/ different UI technology). NextMail is a continuation of said project where we follow the merge of tablets and laptops to convertible devices by creating a convertible mail client.

Heiko Tietze wrote:I believe NM's vision should deal with Kmail/Kontact. For instance, you could just strip 80% of options from Kmail to make it simple.

I would love to do just that.
There are two problems:
# QtQuick is not matured enough to replace rock solid QWidgets for KMail / QWidgets are not good for creating convertible Uis.
# We can not remove/reorganize features from KMail without breaking some users workflows / feelings.

Maybe someday QtQuick is matured enough and NextMail can be used to build the next KMail. Meanwhile we share >90% of the underlying technology.

Heiko Tietze wrote:So why not have a vision about "communication experience" coupled to activities, where NM is just one facet of the application.

The activity related features I can think of are not really exciting. And all require additional manual configuration and we are aiming for convenient automagic (I think? )

# show different tags / searchfolders based on activity
# use different account for email creation based on activity
# enable/disable accounts based on activity -> might be useful in a "bring your own device" context where my private convertible is also the machine I bring to work. I could switch off my private mail when at work and the other way around.

Heiko Tietze wrote:And to throw in another idea: If you want to handle mailing lists or newsletter beyond the receive from and sent to level, it makes sense to have a completely different client - or UI.

I am not really interested in creating a client that focuses on mailing list + newsletters (only).

Hmmm...

One thing that would separate NextMail might be desktop integration; A mail app where 80% of its workflow exists outside the main window. This wouldn't be a "*nix" mail app, it would be a KDE app, and it would take heavy advantage of Plasma. Going with the "Simple by Default, Flexible when Needed" mantra, I think Plasma could be the answer to that; use simple, fast, plasma-based access points to composing and the inbox; focusing on users composing and reading messages directly on the desktop (though a system tray widget) - only opening the main window for configuration, composing more complex messages, or managing folders.

So, here's the vision statement I'm throwing out there;

NextMail aims to be a focused email client where users communicate securely by default, confidently by design, and quickly across a variety of devices. With deep integration into the KDE Nextmail will provide fast, simple access to conversations directly in Plasma for most conversation needs. Outside Plasma, the Nextmail application will focus on a flexible design with sensible defaults, where users can manage their accounts, contacts, folders, settings, and compose complex messages.

In a time of converging conversations it might not be needed to create a new mail client anymore. Why not aim at something bigger: a communication manager. That would combine different kinds of communication into one tool. Get the calls and SMS from KDE Connect, chats, g+, fb,... from ktp, meetings and mails from akonadi (probably all wrongly addressed, but you will get the idea) - and help users to organize this communication by people and topics.

Here btw Activities come into play (or what they could be). Topics could for instance be related to Activities (imagine an Activity for creating a vision for a new mail client). Now when you check communication within an activity, you only get the related stuff. That would be awesome.

Cryptography is included. Also seamless Desktop integration. Of course

Sorry. One has to be allowed to dream

Kver wrote:...deep integration into the KDE...

Sounds awesome (and makes KMail completely superfluously).

mbohlender wrote:I am not really interested in creating a client that....

The vision is not a schedule. You can start with just 10%.

But here is an alternative vision (not that I like it more):
NextMail is the default KDE email client, comparable to JuK vs. Amarok or Gwenview vs. digiKam. It provides essential features, focus on ease of use, simplicity and consistency with the visual styleguide. NextMail addresses the needs of non tech-savvy users that just want to receive and write emails to a couple of friends. It is complemented by KMail which covers all use cases for power users. NextMail will not introduce new concepts. Supportive features like address book, calendar, or special preview are provided by external tools.

bjoernbalazs wrote:One has to be allowed to dream

Nothing to add here

bjoernbalazs wrote:In a time of converging conversations it might not be needed to create a new mail client anymore. Why not aim at something bigger: a communication manager. That would combine different kinds of communication into one tool. Get the calls and SMS from KDE Connect, chats, g+, fb,... from ktp, meetings and mails from akonadi (probably all wrongly addressed, but you will get the idea) - and help users to organize this communication by people and topics.

Here btw Activities come into play (or what they could be). Topics could for instance be related to Activities (imagine an Activity for creating a vision for a new mail client). Now when you check communication within an activity, you only get the related stuff. That would be awesome.

Cryptography is included. Also seamless Desktop integration. Of course

Sorry. One has to be allowed to dream

Ah, yes, you remind me of the log post I wrote last year about Unified Communication, which went in exactly that direction. So yes, we still want that.

So, in the version of our dreams, the pane on the left would just show conversations with certain people, regardless of which channel (across which channels) they happen.
The KPeople people already said that this is theoretically possible with KPeople (although needing more work). So if we can get Vishesh, David and Martin K. on board with his (and maaaaybe can convince Blue Systems to sponsor the work, or get some other sort of funding), we can make it a reality!

Heiko Tietze wrote:

Kver wrote:...deep integration into the KDE...

Sounds awesome (and makes KMail completely superfluously).

mbohlender wrote:I am not really interested in creating a client that....

The vision is not a schedule. You can start with just 10%.

But here is an alternative vision (not that I like it more):
NextMail is the default KDE email client, comparable to JuK vs. Amarok or Gwenview vs. digiKam. It provides essential features, focus on ease of use, simplicity and consistency with the visual styleguide. NextMail addresses the needs of non tech-savvy users that just want to receive and write emails to a couple of friends. It is complemented by KMail which covers all use cases for power users. NextMail will not introduce new concepts. Supportive features like address book, calendar, or special preview are provided by external tools.

bjoernbalazs wrote:One has to be allowed to dream

Nothing to add here

I *really* like your firm stance on simplicity and keeping it to essential features; and the fact that is, if you need complex features Kmail is not going away. Plus, the "flexible when needed" portion of the VDG mantra isn't necessarily about including complex features; it's just about allowing users to adjust the program as needed. For the most part, methinks, power-users are usually best served by power-programs. I would make some adjustments to your statement though; mostly in removing references to other programs, as they might eventually take different directions - or be understood by everyone; (I'm also throwing in my fiddlybit about integration - I think that would be a differentiator)

I've also rephrased "non-techie" to "casual"; Casual can refer to both casual computer users, and power-users using computers casually; which is a minor distinction, but does impact design decisions; A program developed for non-techies might be limit options for fear of a sub-optimal experience, while a casual program might have those additional options for users to optimise the flow for casual use. It's a nitpick, but de'rnit I'm nitpicking!

Security is also a trend in this thread, so I added that also. I also removed the portion on external tools, as that could imply those tools exist as plugins for the program; and refocused the language to more internal thinking...

NextMail is the default KDE email client, with a focus on essential features, ease of use, simplicity, and consistency with the KDE design and usability guidelines. It will leverage the flexibility and adaptability of KDE and Plasma to address the core needs of an email application required for casual usage, providing sensible and secure defaults users would be safe with. Nextmail does not implement non-standard services such as address books, calendars, or special previews; it will focus on polish, quality, and just doing standard email well.

Here's an alternative version with Colomars' unified communication ideal in mind;

NextTalk is the default KDE communication client, with a focus on essential features, ease of use, simplicity, and consistency with the KDE design and usability guidelines. It will leverage the flexibility and adaptability of KDE and Plasma to address the core needs of a conversation application required for casual usage, providing sensible and secure defaults users would be safe with. NextTalk does not implement non-standard services such as address books, calendars, or special previews; it will focus on polish, quality, and using standard supported client protocols (such as email and chat) well.

*note; a generic communication program might need some sort of address book so disparate account types can be connected to one user; Such as having my email and hangouts both connected to me.

Sounds as if we have a good basis to ask the users, providing that mbohlender accepts the decision out of the three (last two plus kver's first hifi idea).

I would offer to run the survey via Planet KDE to get a good number of responses.

Heiko Tietze wrote:Sounds as if we have a good basis to ask the users, providing that mbohlender accepts the decision out of the three (last two plus kver's first hifi idea).

I would offer to run the survey via Planet KDE to get a good number of responses.

No.
We have no users of NextMail so there are non to ask. If we had a product with an existing user base and we wanted to shift direction, then it would make sense to ask if our users would follow us. I see little value in doing a survey here, other than simulating a democracy that is not there. The only people that matter for the decision are those who commit to working on NextMail in the long run. So far I am the only developer (as in programmer) working on NextMail.

I like the idea of a unified communication manager but I want to be realistic and have achievable goals. Creating a convertible mail application is ambitious for a hobby project with a single developer. The only reason this is possible is because the necessary heavy lifting is already done and "all" that needs to be done is to create a QML API and put a UI of it. A unified communication manager requires far more work than I am able and willing to put into it.