KTp/Components/Account Management GUI
WARNING: Brain-dump on this page. Please take with a liberal pinch of salt
Design Notes/Features
- KCM Module - can be reused in config dialog of any Telepathy using App to give a "configure accounts" option.
- Built in default auto-generated UI as a fallback for configuring any Connection manager.
- Plugin interface to provide prettier UI's for particular connection managers.
- Plugins for most important connection managers asap:
- Gabble
- Butterfly
- Salut
- Haze (mainly the more common protocols in Haze)
Current Status
List of outstanding tasks available here:
http://community.kde.org/Real-Time_Communication_and_Collaboration/Components/Accounts_KCM_Tasks
Open Issues
The following parts are up for debate/need investigating:
Contact
Developed mainly by George Goldberg (Find me on IRC in #kde-telepathy as 'grundleborg' or email me: 'grundleborg googlemail com'.
Redesign
Use Cases
Add an Account
Imhotep has a Yahoo Messenger account which he wants to use to text chat with his friends. He's not particularly computer savvy, but knows his username and password. However, he tends to get confused when presented with too many unfamiliar form fields.
Pretzel, on the other hand, is at school. He wants to be able to use his netbook to chat to his MSN buddies during classes on the school network. However, the school uses a proxy server and blocks the default MSN port. Pretzel is pretty good with computers so wants to change the advanced network and proxy settings of his MSN account to get round the school network limitations.
Fred has been having trouble getting his MSN account to work. He doesn't know this, but it is due to a bug in the telepathy-butterfly version his distribution ships. He asks on the KDE forums for help, and someone recommends he tries connecting to the account with another MSN connection manager, such as telepathy-haze. Fred doesn't know what a "Connection Manager" is, but the other user gives him step by step instructions for how to use telepathy-haze.
Conclusions
- Adding accounts needs to be as simple as possible by default, only presenting the minimum necessary fields.
- Advanced options need to be accessible but not threatening to less tech-savvy users.
- A appropriate default choice of CM for a given protocol should be made where more than one is installed without bothering the user. However, it should be possible for users to manually specify a non-default CM for an account if they want.
Edit Account
Charlie wants to change the display name of his Jabber account.
Danni is having problems with network connectivity for her MSN account behind a corporate firewall. She's quite good with computers so she wants to play around with the account network and proxy settings to try and get it working.
Bob also wants to edit his Jabber account - he has changed the password from his home computer, and needs to update the stored one on his work computer.
Alice typed in her AIM screen name slightly wrong when creating the account. She wants to edit it without having to recreate the account and enter all the other details again too.
Conclusions
- All properties of accounts should be editable, including the username/screenname property.
- UI should display the basic properties only on the first page displayed to the user, but should still allow editing all advanced properties with the minimum of clicking.
Delete Account
Alice no longer wants to log into her AIM account on her work computer, but she still intends to use it on her home one.
Bob has decided he doesn't trust jabber.org any more, so he wants to remove his jabber account both from his computer and from jabber.org altogether.
Conclusions
- Deleting account should be easily possible from the UI.
- It should, if possible either support optionally deleting the account altogether (if the IM network allows this), or possibly point the user to web-based ways of doing this if it is not possible programmatically?
Technical Requirements
Properties that must be configurable
Basic Properties include:
- Some of Account.Parameters - the required ones e.g. username and password.
- Account.Displayname - the name to give this account in the accounts list locally, e.g. Jabber: [email protected] or something.
- Account.Nickname - my name to be displayed in other people's buddy list.
- Account.Enabled - whether this account is enabled or disabled.
- Account.ConnectAutomatically - whether to connect the account automatically on startup.
- Account.Avatar - my personal avatar image for this account. Should there be some global avatar applied to all accounts unless you set one here, which would except it from the global one.
Advanced Properties include:
- The rest of Account.Parameters - network settings and other advanced protocol/cm specific misc.
Other Properties:
- Do we support creation of accounts as supported by some Jabber servers? ** The old way of doing that seems to be mostly disused now, but I definitely heard mention of a new less spammy way of registering accounts automatically although I don't think gabble supports it yet. Definitely worth asking upstream Telepathy about this a bit. Grundleborg 12:39, 19 January 2010 (UTC)
The problem of multiple CM's for each protocol
This section is somewhat out of date and should be revised once profile support lands in telepathy-qt4 upstream
One feature of Telepathy from a technical point of view, is however, quite a substantial problem from a user-interaction point of view. Telepathy allows you to have multiple Connection Managers (CM's) installed for a given protocol. For instance, I may have both telepathy-butterfly and telepathy-haze installed which will both support MSN accounts.
This is a useful feature because:
- CM's can support different feature sets - I may want to use MSN over HTTPS, which is only supported by haze (afaik, but this is just an example).
- CM's may support multiple protocols (e.g. haze) which means I might want one for one protocol, or another for another one
- CM's may fall unmaintained and a better one may be found for a certain protocol (or just bugs in certain ones).
This is a problem because:
- We don't want to have to bother users with the technical detail of which CM they are using (what the hell is a CM anyway, and why should they care). However, we do want to make it easily possible for more technical users who do care about what CM they use to choose.
We need a UI that does not confuse non-technical users with the CM choice, but on the other hand it must allow selection.
Accounts cannot be sensibly transferred from one CM to another, because the parameters used by them are not standardised. We will choose to accept this limitation for now, since trying to work round it in the UI to allow changing the CM of an account is not reliably possible (too many different versions of CM's and the set of all possible CM's (past and future) not being knowable by us).