An attempt at solving KControl's usability problems..

Frans Englich frans.englich at
Mon Jan 26 20:30:42 GMT 2004

On Monday 26 January 2004 06:32, George Staikos wrote:
>   Some notes:
> > 4) Usually more efficient and faster code.
>    It is not possible for a generator to write more efficient and faster
> code than a human, in particular since a human wrote the generator. 
> Perhaps inexperienced or lazy programmers write less efficient code, but
> this is not a valid argument.

I guess this topic could be discussed for ages, when it comes to the uic vs 
handcrafted it really doesn't matter. It's removed.

>    Furthermore, it is easier to make "hand tuned" UIs without designer. 
> That being said, I do prefer designer wherever possible.

Agreed, the designer is preferred when possible. Unfortunately, there is 
AFAICT too many cases where you have to fine tune afterwards, kstdguiitems on 
kpushbuttons, the kintnuminput, selecting pictures for pixmaps(for playing 
nice with kde). But it's probably because of my inexperience.
> > "it is important to avoid technical and "scary" terms"
>    Sorry, some things are technical.  Allowing people to remain ignorant is
> the wrong approach.  If they don't understand the terms, they probably
> don't need to be there to begin with and therefore will not reasonably
> change things.  Alternatively, they may need to learn the terms, which is
> reasonable.  We even have some things in society for this, namely books and
> school.  If they do understand the terms, they likely want to be there and
> want to do things, and don't want silly non-technical approximations to the
> correct terms.  If this is a real problem, have an "advanced" mode in the
> KCM.

An earlier version(to be found on kde-usability) had the following paragraph 
after the naming recommendations:

The above name recommendations is guidelines and must not be 
strictly followed. If the name demands to be longer than average
in order to be informative that is of course ok. Similarly, don't
simplify words in case it then does not reflect the content. The 
recommendations exist to make the names informative, representative
for the content and easy to read - not the opposite.
The recommendations can also be applied on phrases used elsewhere in 
the KCM.

(I removed it because I thought the introduction emphasized enough it was 
guidelines and /recommendations/ and not a "strict" spec. Perhaps it should 
be readded, hm..)

In other words, when something is technical by nature it is not possible to 
simplify and then it of course doesn't make sense shopping things off. But 
when something can be expressed, without compromising the original meaning  
so mortal users also can understand the phrase, that is of course wanted, for 
several reasons.
From a theoretical viewpoint it sounds obvious but as a developer it is 
apparently easily forgotten(or ignored..). I added that paragraph in order to 
remind developers and help using a typical user's perspective.



More information about the kde-core-devel mailing list