Design of Telepathy Account KCM

Dario Freddi drf54321 at gmail.com
Sun Aug 29 18:39:11 CEST 2010


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-telepathy/attachments/20100829/a6062e84/attachment.sig 


More information about the KDE-Telepathy mailing list