An attempt at solving KControl's usability problems..
frans.englich at telia.com
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
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
(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
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