Design of Telepathy Account KCM

Thu Sep 2 02:11:14 CEST 2010

Usability and general prettyness have been my goals with tweaking the accounts 
KCM. 

Improvements I'd like to make on the old configuration:
 - The main page was almost completely whitespace. 
 - As a user I don't  immediately know what the checkbox next to the account 
entry in the list does. 
 - The apply/cancel buttons from the KCM don't really have any meaning, as we 
save account changes immediately.
 - There is no feedback as to the status of the account, as a user I want to 
know if changing some settings actaully made it work - and if I've entered a 
correct username/password whilst I still have it on screen.

I've made a 'working mockup' which hopefully fixes the above, and matches 
everything we've talked about so far.

http://dev.sharpley.org.uk/temp/telepathy/telepathy_accounts_config_mockup_1.png

Far from perfect, here are some more brainstorming thoughts and questions:

George's wiki page on use cases and things the KCM needs to covers explicitly 
states a user should be able to set "connect automatically" and "enable". Even 
as a sort-of developer I wouldn't like to say with 100% certainty I can 
explain the difference. How do we display this to a user? Do we even need to? 

Should the list of accounts on the list show the state of the account?
As a user I want to immediately see the state of everything, without clicking 
through them. 
I'm thinking making it look more like the list in Kickoff, with a bigger icon 
and two lines of text "Jabber: dave at jabber.org" (then just beneath in a 
different colour font) "Connected". I'm going to have a play and see if I like 
the idea when I can see it.

Where should we configure avatars? 

That's probably enough for now...

On Tuesday 31 Aug 2010 09:15:15 david at davidedmundson.co.uk wrote:
> 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
> 
> _______________________________________________
> KDE-Telepathy mailing list
> KDE-Telepathy at kde.org
> https://mail.kde.org/mailman/listinfo/kde-telepathy