Talk:KTp/Components/Account Management GUI: Difference between revisions
(Created page with 'Suggestion on how to resolve the multiple CM issue: Braindump of parts which are currently bad: * The protocol list is far too long and contains many duplicate entries. Will be...') |
m (Drdanz moved page Talk:Real-Time Communication and Collaboration/Components/Account Management GUI to Talk:KTp/Components/Account Management GUI: As discussed at IRC meeting Real-Time_Communication_and_Collaboration is too long, we are moving a...) |
||
| (One intermediate revision by one other user not shown) | |||
| Line 1: | Line 1: | ||
Hiding complicated options: | |||
We need a mechanism to hide the really obscure options that 99.99% of people would ever want to edit. | |||
Proposal: | |||
The UI only shows the interface from the custom configuration. | |||
We don't show have a tabbed view, it's too cluttered and complicated. | |||
At the bottom of the page is a button "Edit raw parameters..." (wording can change, but it should be suitable scary sounding), this opens a dialog in which the user can set /everything/. This dialog can use the code that currently generates the form if no custom configuration exists. | |||
By putting these in a dialog which the user has to click a button to see, it's a clearer (IMHO) that most users really don't want to be here. It requires more of a deliberate effort than simply exporing tabs. | |||
I'll try and make a graphical mockup to support my proposal. | |||
---- | |||
Suggestion on how to resolve the multiple CM issue: | Suggestion on how to resolve the multiple CM issue: | ||
Latest revision as of 00:31, 10 November 2012
Hiding complicated options:
We need a mechanism to hide the really obscure options that 99.99% of people would ever want to edit.
Proposal:
The UI only shows the interface from the custom configuration. We don't show have a tabbed view, it's too cluttered and complicated.
At the bottom of the page is a button "Edit raw parameters..." (wording can change, but it should be suitable scary sounding), this opens a dialog in which the user can set /everything/. This dialog can use the code that currently generates the form if no custom configuration exists.
By putting these in a dialog which the user has to click a button to see, it's a clearer (IMHO) that most users really don't want to be here. It requires more of a deliberate effort than simply exporing tabs.
I'll try and make a graphical mockup to support my proposal.
Suggestion on how to resolve the multiple CM issue:
Braindump of parts which are currently bad:
* The protocol list is far too long and contains many duplicate entries. Will be even worse when we directly support "profiles".
* The names of some of the protocols need user-friendly-ing (and possibly even translating) i.e xmpp-local -> "People Nearby".
Suggestion on how to fix it:
* We only list protocols that have a custom KCM Shell for configuring them, with this we only ship MSN/Butterfly.
So the majority of users will never see MSN/Haze only MSN/Butterfly. (it would be up to us to decide which connection is the best for the majority. Same for all other protocols.)
* A user can seperately install MSN/Haze configuration KCM at which point they are able to use Haze.
Each configuration .desktop file would contains: Protocol Connection Name
The name field would be a translatable field for a user friendly version of the string. It would also allow seperation of having two different protocols such as "Jabber" (which uses gabble) and "Jabber (experimental)", which uses Wocky.
The obvious drawback is that you need to update some KDE parts whenever a new Telepathy Protocol is made - but you need that anyway to get an actually usable config anyway.