Hi guys

I am currently porting the settings UI of Akonadi (primarily used in the Kontact application) to QML/QtQuick as a GSoC project. I would also like to give it a brush up in the process. The main idea is to organize it around the concept of Accounts instead of single, freely combine-able Identities/Smtp Servers/IMAP Servers and so on, but still allowing these kind of setups for people who need it. "Simple by default, powerful when needed".

You guys did a kickass job with the System Settings Application and I would like to achieve something similar for this project.
I want to do the legwork myself. What I primarily asking for is your guidance.

When doing my mockups for the new configuration UI I constantly hit two questions:
1. Do we really need that feature / Is anybody actually using this?
2. Does the grouping make sense for a user? (the grouping is technical, which might not represent the users view of the world)

For the first question: Is a user survey a reliable/ sensible approach for determining if a feature is (almost) not used. Is there a better way?

You solved the second question with a pile sorting study if I remember correctly. Would it make sense to do the same for this project?

hit me , If you have any other ideas or remarks about this project.

I am looking forward to work with you.

Cheers

Mike

mbohlender wrote:1. Do we really need that feature / Is anybody actually using this?...
For the first question: Is a user survey a reliable/ sensible approach for determining if a feature is (almost) not used. Is there a better way?

Absolutely. You could just ask like "Do you need foo?" And you will get 99% yes on clear questions (email address settings or the like) and 10% 'I don't care' for special stuff (Kontact color setup hell). It should be clear in advance what you do with the replies. A better (or rather different because of the higher effort for all) approach to ask users about requirements is the Kano-Method that aims to prioritize features on two dimension. It has been done for KGet some time ago, for example.

Basically all starts with a good vision. An example: Kontact should become as simple as possible. (I bet a lot of users would holler hooray here.) That means you strip off all settings, functions, options etc. that aren't really necessary for the core features (which are still a lot). No search, no view mode, etc. Based on this vision you could create a mockup and show it to the community. KDE is very open-minded and you will get a lot of replies. And more than a few might revise the initial agreement with maximum simplicity.

mbohlender wrote:2. Does the grouping make sense for a user? (the grouping is technical, which might not represent the users view of the world)
You solved the second question with a pile sorting study if I remember correctly. Would it make sense to do the same for this project?

I wouldn't run a card sorting to arrange UI controls. Isn't it clear which settings belong together?

All together I miss a good concept. No idea what 'arrange around accounts' means for the interaction, the workflow, features and so on. The whole project is one of the biggest topics- you will need help.

mbohlender wrote:Hi guys

I am currently porting the settings UI of Akonadi (primarily used in the Kontact application) to QML/QtQuick as a GSoC project. I would also like to give it a brush up in the process. The main idea is to organize it around the concept of Accounts instead of single, freely combine-able Identities/Smtp Servers/IMAP Servers and so on, but still allowing these kind of setups for people who need it. "Simple by default, powerful when needed".

First of all: Congrats on getting the GSoC project!
It's great that you're the one doing this, because you make sure not to lose sight of the user.

What I not only would like to see, but think is absolutely crucial, is an integration of email accounts within KAccounts in the future. I know this is not the scope of your project, but both the KAccounts and PIM team seem to agree that this is the way forward (because it would be very weird for users if they could add their Google account their, bot not their other mail accounts).

Therefore, if that integration cannot be achieved yet, I would not recommend putting too much effort into anything that would be thrown away when the integration happens.

With that out of the way, here's my take on your questions:

When doing my mockups for the new configuration UI I constantly hit two questions:
1. Do we really need that feature / Is anybody actually using this?
2. Does the grouping make sense for a user? (the grouping is technical, which might not represent the users view of the world)

For the first question: Is a user survey a reliable/ sensible approach for determining if a feature is (almost) not used. Is there a better way?

A user survey can be anything from perfectly valid to utterly useless, depending on the quality of the survey and the representativeness of the sample. If you create a carefully crafted survey and recruit participants for it via PlanetKDE and news.kde.org with a catchy article, you get a very good view of the opinions of the readership of those sites. How well that readerships represents your target audience is a completely separate question, and one I cannot answer at all.

You solved the second question with a pile sorting study if I remember correctly. Would it make sense to do the same for this project?

What grouping are you referring to?

I am looking forward to work with you.

So do we

Thanks for the replies!

Looks like I did not provide enough context. Here is what I am working on:

Our user Alice wants to use her email account with Kontact (or another email client using Akonadi. She uses a wizard (e.g. KAccounts) to set everything up. Alice does not like some of the default assumptions the wizard made for her, so she opens the config UI (e.g. from within KAccounts) and changes things according to her needs.
Said config UI is what this project is about.

Vision
My UX vision for this project is to make the core settings of Akonadi more accessible to average users while maintaining (most of) the more advanced option for powerusers with special needs. That way Kontact can remain the customizable beast that it is while other (simpler) users of Akonadi (e.g. Active Mail) can use the default config dialog as well.

I don't know what these core features are yet. Apart from encryption features that I deeply care about personally.
Finding them would be the first research goal for this project I guess.

Heiko Tietze wrote:I wouldn't run a card sorting to arrange UI controls. Isn't it clear which settings belong together?

Not necessarily. I am not sure every users expects to find cryptograpy settings under "Identity" (where you can also set your Name and a pretty picture of you.

Heiko Tietze wrote:All together I miss a good concept. No idea what 'arrange around accounts' means for the interaction, the workflow, features and so on. The whole project is one of the biggest topics- you will need help

Like Thomas already stated things are moving towards KAccounts. The idea behind KAccounts is that the users add their credetials for a service provider (e.g. google) once and KAccounts configures everything for them (email for KMail, calendar for KOrganizer, chat for telepathy and so on). The current configuration within KMail is the complete opposite. You have separate identities, sending account and recieving accounts that you can combine in any combination you want. Both concepts don't work that well together. So the idea is to bring the Akonadi config closer to the concept of KAccounts.

The way I want to maintain the freely combineable option would be to have an "Expert Account " next to the Google, Standart IMAP and so on Accounts. Said "Expert Account" could just act like the current config does. This gives us a nice migration path as well.

colomar wrote:KAccounts

Yes. I hope it became clear from my previous answer that KAccounts is the end goal.

colomar wrote:A user survey can be anything from perfectly valid to utterly useless, depending on the quality of the survey and the representativeness of the sample. If you create a carefully crafted survey and recruit participants for it via PlanetKDE and news.kde.org with a catchy article, you get a very good view of the opinions of the readership of those sites. How well that readerships represents your target audience is a completely separate question, and one I cannot answer at all.

Yes I was expecting something like that. Do we have an alternative?

colomar wrote:What grouping are you referring to?

I hope the identity/cryptography example from my previous reply makes it clear enough. if not i can elaborate.

mbohlender wrote:Looks like I did not provide enough context. Here is what I am working on:

Good start. So the project does not intends to replace all settings but accounts related only, right?

If I wouldn't know which requirements were relevant to users I'd ask the community in a qualitative inquiry. Either you introduce the intended changes (many users may not see the impact of your vision) and just ask for their needs, or you find a couple of questions like "What special setup do you have in respect to encryption?". Without a comprehensive list of requirements you can neither prioritize them or rather classify into novice vs. expert settings not you can run the card sorting (analysis of grouping).

Heiko Tietze wrote: So the project does not intends to replace all settings but accounts related only, right?

Long term I want to rework all settings, but this GSoC project is about accounts related stuff only. We got to start somewhere.

What software tools can you command for doing the survey?

mbohlender wrote:What software tools can you command for doing the survey?

I run the card sorting on ConceptCodify https://conceptcodify.com/, Kano on http://www.kanosurvey.com/, large surveys on User Weave http://user-weave.com (ask for invitation to the platform if you are interested), and simple votings within a blog post.