Design of Telepathy Account KCM

[George Goldberg]

On 27 August 2010 11:22, David Edmundson <david at davidedmundson.co.uk> wrote:
>

Hi David,

In general, I strongly agree with what you are proposing (and I'd like
to have seen it happen months ago... if only there were more hours in
a day). Some more specific comments are made inline below.

> 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.

Agreed. The rest of the KCM is subject to change once telepathy-qt4
gets profile support, which means there is no point dicussing other
aspects yet.

> 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.

There are some quite extensive use cases written up on the wiki [1].
Would be a good idea to keep these in mind when we are discussing this
topic.

>
>
> 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.

Yup

>
> 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.

This is actually incorrect, but it still sucks, so no point going into
a great deal of explanation.

>
>
> 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).

Agreed. That was a temporary hack just to make it possible to use the
kcm while we were all working on other things.

>
> 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.

Agreed

>
>
> 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.

Agreed. "basic setup" should be on one page, and should have all
mandatory parameters and anything else (e.g. gabble password) that
will allow 90% of users to get set up straight away.

>
>  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.

This can, however, be a bit tricky when different CM versions change
their params, but I'm not aware of any case of new manadatory params
being introduced, so we should be OK there.

>
>  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).

Actually, this is the bit I'm not quite convinced about. The
autogenerated parameter edit widgets should be a fall-back of last
resort, so I would prefer this "advanced" section to contain some nice
UI from the plugins, only falling back to autogenerated when the
plugin doesn't cover some parameter. Perhaps a tabbed UI would be OK
in this "advanced" part (maybe a pop-up widget containing a tab ui...
but this is getting pointlessly specific, so whatever).

>
> 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.

Yes, although keep in mind that some people might need to e.g. set a
HTTP proxy for msn, which shouldn't be in the basic UI, but should be
in the Advanced UI, but the person might not really know what they are
doing because some script kiddy friend told them how to make it work
etc (hence my reason for wanting the plugins to provide nice advanced
UI too). This is covered in the use cases on the wiki.

--
George