Account setup is unnecessarily technical [UX suggestions]
Open, WishlistPublic

Description

So, I just finished setting up my first email account. So far I love the look of Kube, from it's clean design, threaded conversations and integration into my beloved KDE-made Plasma desktop. It's beautiful and my new most beloved email client! I did ran into a number of UX issues, which I thought I'd share along with some suggestions. Essentially, the ideal for setup would just be "what's your email address" and "what's your password". This is possible. It already exists for me in Thunderbird. Here's what I currently get in Kube though and my suggestions for making it clearer / more seamless for a new user:

  1. At the start I'm forced to choose Either "Kolab Now" "Google" or "Custom". What's "Custom"? Who knows? It sounds like an option to configure one of the other two choices. Can Kube be used with an account that's not Kolab Now or Google? It's unclear.

Suggestion:
Just ask for my email address. If it ends in "@gmail.com" "@google.com" or similar, you know it's Gmail. I imagine Kolab Now also uses it's own domains, however either way, if the domain is something that's not recognized, then I'd suggest transparently using Thunderbirds autoconfig service to find out if configuration settings for that domain are known and can just be set for the user without further knowledge needed. If the domain isn't known to the autoconfig service, we can still improve the SMPTP / IMAP setup as outlined later here, and only for users who need it without them having to click on an unlcear "Custom" button.

  1. When creating an account, there is excessive visual emphasis on too many items making it unclear where the user should look / interact first. There are large, wide orange undelines underneath almost *everything*.

Suggestion:
I get it. Almost all the fields need to be filled in, so you've put a big orange underline under all of them. It's excessive though. Visual design in UX works better when the user is pointed to the single thing they should pay attention to, rather than trying to get them to look everywhere. Firstly, you can emphasize which fields are mandatory in a less visually overwhelming way by putting the orange (although I'd argue red, has more of a precedent to denote critical) line to the left side of the field instead of the entire bottom edge (or right side for RTL languages). If you really wanted to make it clearer you could even just emphasize ONE field that is necessary to still fill out, and then once that is done, then emphasize the next. This way the user is only ever being shown one clear next step.

  1. Users are forced to enter domains with full transport protocol, domain and port configuration in a character perfect syntax as Kube expects it or configuration fails.

For example, I actually put in the correct smtp and imap domains and password, but configuration failed. Why? It was unclear. All I got was a "Configration error". It turns out that I missed that Kube also wants me to enter "imaps://" at the start (why?!) can't we guess this for imap? and "smtps://" at the start (?!!). It also wanted me to enter : and the port numbers. Sure the port numbers are necessary (well, actually, Thunderbird's autoconfig service...) but the light grey example text wasn't obvious enough for event a technical user such as myself to notice and realize that was the place where that info was required to be entered.

Suggestion:
A separate field for ports would have made it clear that entering port numbers in that step were mandatory. Better yet would be using autoconfig, and if that fails, trying with the standard 993/587 ports and only if that also fails, explicitly adding fields for the user to fill out. At the very least, if no port is entered, point the user back to the field where you expect it, asking them to fill it in. The user shouldn't *ever* have to enter "imaps://" or "smtp://". Use a dropdown/radio button if you refuse on autoconfig.

Anyway, I hope my criticisms come across as constructive. I love what you've made. It's gorgeous, and I'd only like to help make Kube even moreso! <3 <3 <3

bugsbane created this task.Apr 24 2019, 3:50 PM
bugsbane triaged this task as Wishlist priority.

Thanks! Constructive criticism is always welcome =)

In general I agree with all your points, mostly anyways. Anyways, here's why we are where we are:

  1. The idea is exactly that you get the easiest possible setup experience. Deducing everything from the email domain is not always possible (my kolabnow.com address is @mailqueue.ch), so having per service setup dialogs allows us to provide the best possible experience for that service. I don't think it's realistic to do full blown autoconfiguration for everything (imap, smtp, caldav, carddav) at the moment (just purely from a technical point of view). The "Custom" option is then really just a hack because we can't cover all services. So IMO having this extra step of selecting your service does more good than harm, if we assume that we optimize for services that are on that list. I know that the list of "supported" services is rather thin at the moment, that's just a matter of different priorities (patches are welcome). Perhaps this could already be improved by just using different wording, e.g. "Pick your service provider:" and then instead of "Custom" use "Other Services".
  1. No objections, we'd just have to experiment with what works well.
  1. I agree the custom setup could use some love, it just hasn't been a priority so far. One limitation that we have right now is that we can't check if a connection works or not (could be implemented though), so we have to just blindly gather all information, and then we'll know if it works or not. This is clearly suboptimal and something that should be improved.
cmollekopf moved this task from New to Triaged on the Kube: Bugs board.Aug 17 2019, 9:51 AM

Yes, I totally agree with 3) (easy setup). I set up an account yesterday. I'm quite an experienced user, but somehow managed to ignore the grey syntax provided by Kube for IMAP and SMTP. I fiddled around for 20 minutes before I noticed this information. Then it worked well.

I would be much better to provide fields in the way that e-mail or domain providers provide the server information, i.e. usually e.g.:

Server: imap.xyz.eu
Port: 143

etc.

E.g.
https://www.df.eu/de/support/df-faq/e-mail/pop3-imap-postfaecher/mail-programme/

Thus you should just have these two fields ("Server" and "Port") to fill in with the information provided by the provider.