Fwd: Re: Application duplication (was: Re: cdbakeoven)
Martijn Klingens
klingens at kde.org
Sat Apr 20 19:56:16 BST 2002
On Saturday 20 April 2002 20:21, Thomas Zander wrote:
> You refer to internal consistency; I also mean consistency over time. So a
> feature is where you expect it to be every time you 'search' for it.
That (can) happen between KDE releases as well. And as long as it happens
really gradually I doubt anyone would fin it annoying or intrusive. Besides,
it the GUI would evolve properly it wouldn't happen at all, because the GUI
would put each and every option exactly there where _you_ want it.
And yes, that will be hard to do, but I stated that already three posts ago...
> The biggest problem people had with 'Kays Power Tools' was that they read
> in a magazine about a really cool feature and could not find it in their
> GUI. That was because the application had not yet decided your level of
> expertise was great enough to present that feature.
Is this a true example? I found the GUI of Kai's Power Tools pretty much
non-standard and as a result quite difficult to learn, but I never found
features that weren't there at all initially. And the philosophy behind KPT
was that you had to 'explore' the GUI instead of the plugins offering a
predefined way of working. A typical artist's point of view if you ask me,
but maybe it did work for the real target audience... I havent used KPT since
version 5 though, so you might be referring to a newer version as well.
> The other way around is that I use a feature ones every 6 months (changing
> my background colors for example) I don't want the feature to suddenly be
> positioned somewhere else.
If the GUI would truly adapt itself, it would even adapt itself to that
particular use case...
> Even if I seldomly use a feature, I still see that the feature is there
> when I select an equivilant feature in the same menu.
Tsja... Offering all features in the menus and dialogs at the same time is a
blessing and a curse and I haven't decided what is worse. Too much options
makes the GUI look overly complex and scaring, too little of them, or hiding
options always tends to make people unaware of the feature in the first
place. No idea what's better, both are equally bad if you ask me.
> In other words; it is impossible to keep internal consistency, consitency
> over time _and_ consistency between the user-model and programmers-model in
> check if the applications starts changing the interface.
Consistency over time is not preserved between revisions anyway, and a gradual
change is probably much less confusing as the leaps a version upgrade causes.
> Maybe it can be done; if I type [tab][tab] in bash I see a list of
> commands; that could be sorted on usage. But for a limited set of commands
> (like most applications we have today) I don't see how it will gain the
> user in speed.
What about making dialogs turn into wizards or vice versa depending on the
user's way of working? Adding verbosity to options or hiding it? Analyzing a
user's behaviour and hiding options the user never touches, maybe even in
other applications? Allowing the user to adjust the menus and so just like
you can already adjust key bindings and toolbars? Etc...
Martijn
More information about the kde-core-devel
mailing list