[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    Re: All routes - a way to solve the (settings-)GUI issues
From:       Ellen Reitmayr <ellen () kde ! org>
Date:       2006-01-17 10:21:24
Message-ID: 200601171121.25659.ellen () kde ! org
[Download RAW message or body]

On Monday, 16. January 2006 17:16, Sven Burmeister wrote:

> > Sounds good!
>
> Thanks, but I am a realist, if one does not code it oneself, it is very
> unlikely to be realised. :) Or should I really file a wishlist item in
> bugzilla?

Hm, into which bugzilla section exactly? Just for KMail? For KDE in General?

And even if there is a technical framework for All Routes - do you think 
developers will be able to insert the contents and consider all relations in 
an appropriate way? The information will have to be edited, will have to be 
adjusted to use cases, because simply providing links to all relevant 
settings and related help texts will be an overload for the users.

So the idea will first of all require a good framework that supports those 
people who will later develop all routes contents.

Once it is implemented, developers, usability people and information 
developers will have to collaborate to fill it with contents - because 
neither of them is able to properly do it on their own. And they will have to 
touch (almost) every application... uffz. 

I wonder if we shouldn't do it the other way round: Improve the information 
architecture of the settings dialogs of selected applications: e.g. Kontact, 
Konversation, Konqui. Step by step provide related information for relevant 
items in the settings. Ask somebody to implement a search function for 
Settings dialogs. 

Why so? If we provide a new feature (All Routes) as a framework many KDE apps 
will implement it, but 90% will not provide proper contents. The result will 
be that users won't understand the benefit and won't utilise it - just like 
What's This. So instead of providing this 'New feature' (All routes), we base 
on existing things and expand them step by step for selected applications. 
The users won't even realise that this is 'a new feature', but simply feel 
supported in a better way (while doing tasks as they ever did them). 

Once a bunch of good contents exists, one can think of revising the design of 
the settings dialog to something like 'all routes'.

>
> A remark to the ideas for Kontact. I do not think it is sensible to hide
> everything concerning e.g. encryption until the user receives an encrypted
> email and clicks on it. The logviewer can be hidden, fair enough, but not
> the encrypt-icon in the toolbar, as it should be the trigger for the
> encryption-wizard, if it was not already set up. What is more obvious than
> to click on the encryption-icon, when wanting to set up encryption? The
> user needs an obvious start-button for functionalities, clicking the
> encryption-icon starts encrypting, be it via the wizard, or actually
> encrypting.

Hm, I partly agree, partly disagree.
Those who do not know what encryption is won't click the toolbar icon to 
encrypt there mail. Those who know what encryption is need to have a hidden 
folder with a secret key. Maybe the buttons should be shown if such a key 
exists, even if not for the sender identity's email address.
Additionally, in the Identity's wizard, users may be asked if they want to 
associate it with a secret key, even if there is no hidden key folder. 
However, this featuer won't be implemented so soon, i fear. So we got some 
time to think of the best fitting workflows ;-)

>
> Sven
> _______________________________________________
> kde-usability mailing list
> kde-usability@kde.org
> https://mail.kde.org/mailman/listinfo/kde-usability

-- 
---
Ellen Reitmayr
KDE Usability Project
usability.kde.org
_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread]