Design of Telepathy Account KCM

David Edmundson david at davidedmundson.co.uk
Fri Aug 27 12:22:31 CEST 2010


I've spent the past two evenings rummaging through making some account UI
plugins, and investigating some bugs in the main account. Now that I've got a 
good idea about how it works, I would like to redesign
it :-)

Right now, all I would like to focus on is the configuration/editing of an
account. This is tricky because we have two types of users.
 - Those who only want to see the most basic options in order to make
their account work (i.e "account name", "password")

 - Those who want to configure absolute every detail, in the most obscure
network scenarios.


The current design:
The current design is incredibly clever, but it's clever in a way that
IMHO always leads to a non-optimal user interface.

How the current design works:

The current design generates two lists of parameters for the protocol,
mandatory and optional.

It then loads the custom configuration UI and requests; one widget for
mandatory parameters, and a list of widgets for any optional parameters.

If any paramters have not been covered in the custom configuration UI, it
then lists them in two additional tabs, again split by mandatory and
optional.


Problems:

Mandatory and Optional parameters can not be shown in the same tab widget,
this doesn't always make sense, for example "password" in Gabble is
optional. (note the main code is actually full of hacks to allow this
particular case to exist in the other widget).

Every paramter for a protocol is always shown to the user. There is no
way to hide anything. This is a significant UI issue for the majority of
users. When helping a friend set up their first Jabber account they went
through every setting (in Kopete at the time) saying "what should I set
this to?", despite me telling them to leave everything else as default.

Tab overload - because of the dynamic/custom UI splitting we end up with 4
tabs for Gabble, some of which are mostly just whitespace. Tab's aren't a
great way to hide options, as most users will click on them anyway, and it
makes the whole process look very complicated, even if it's not.


Proposal:

Clearly we don't need to display every option, Empathy only displays a
very small subset of parameter options with absolutely no way of reaching
the others, and the number of complaints vs number of happy users seems very
small.

However - it wouldn't be KDE if we didn't beat the Gnome equivalent, I
propose:
 In the configuration area we load the Account Plugin widget, which
displays a very carefully selected small set of options for setting up
the account. Username, password - similar to the things Empathy displays.

 It's up to the author of the Account Plugin widget to ensure that it
contains every mandatory parameter. This should be fairly obvious from
even the most basic testing.

 At the bottom of the page we have a button "Edit Raw Parameters..."
(wording can be decided upon. It's quite important), this loads a dialog
which displays George's fancy code for displaying every single parameter
on a protocol (including those listed in the main widget).

Reasoning:
 This design seperates "things most people want to change" and "the scary
stuff" by a whole seperate dialog, it's much more of a visual seperation.
Most users who just want to write "username", "password" aren't
overloaded by options.

 Advanced users who know what a STUN server is, and want to change it,
still have an option to.

 Results in simpler code, both in the AccountsKCM, and in all the plugins
- and that has to be a good thing.


More information about the KDE-Telepathy mailing list