Design of Telepathy Account KCM

[david at davidedmundson.co.uk]

I made a brief start mostly for the purposes of doing some nice mockups
(nearly done, will attach next email).

I think before the code can really start we need to completely sort out
the plugin interface. This may be easiest at the Sprint.

We're all happy with the plugin's supplying a widget for configuring the
main parameters. However we haven't quite agreed on how to do advanced
options yet. I'm happy to move towards the advanced configuration coming
from the plugin too, however I don't like:

>> only falling back to autogenerated when the
>> plugin doesn't cover some parameter.

I like falling back to the autogen UI if we don't have a plugin for the
protocol at all, but the concept of falling back to the autogen UI for a
single parameter doesn't lend itself to a consistent UI. It also fails in
the use case suggested by Dario where we might want to deliberately hide a
parameter.

As long as we maintain the configuration plugins, this shouldn't be needed
- and as such we should make the configuration plugins as simple as
possible so they can be easily maintained.

I would like to see AbstractAccountUi simply having two methods
 -virtual AbstractAccountParametersWidget* mainOptionsWidget(QWidget* parent)
 -virtual AbstractAccountParametersWidget* advancedOptionsWidget(QWidget*
parent)

This leaves the plugin author to decide if the advanced options widget
requires tabs or not, and reduces the need for any "registering
parameters"

Discuss.

Dave


> Hi guys,
>
> As George, I agree with mostly everything. David, do you need another pair
> of
> hands while you're at it? We might get started on it during the sprint, if
> you
> didn't start already.
>
> On Friday 27 August 2010 13:44:14 George Goldberg wrote:
>> On 27 August 2010 11:22, David Edmundson <david at davidedmundson.co.uk>
>> wrote:
>>
>> [snip]
>>
>> > 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.
>
> +1
>
>>
>> >  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).
>
> "Advanced parameters" or simply "Advanced" is what is most widespread and
> intuitive to the user. And I agree with George in avoiding the autogen
> interface wherever possible - providing an UI is far from complicated and
> gives a far better feeling - as long as we keep them all consistent. Maybe
> it's time to deal with some mockups?
>
>>
>> > 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.
>
> Nitpicking here: we should provide the least possible parameters. For
> example,
> such a use case (proxy for msn) would be already covered by proxy settings
> in
> KDE - and that's another reason for not going for an autogen interface,
> which
> might expose some parameters which are actually not really needed.
>
>>
>> --
>> George
>> _______________________________________________
>> KDE-Telepathy mailing list
>> KDE-Telepathy at kde.org
>> https://mail.kde.org/mailman/listinfo/kde-telepathy
>
> --
> -------------------
>
> Dario Freddi
> KDE Developer
> GPG Key Signature: 511A9A3B
> _______________________________________________
> KDE-Telepathy mailing list
> KDE-Telepathy at kde.org
> https://mail.kde.org/mailman/listinfo/kde-telepathy
>