[KDE Usability] Alternative "advanced" settings?

[dotancohen]

I see that some valid feature requests are not implemented so that
there will not be "8 billion configuration options that really don't
improve life measurably" [1]. That is a valid point, KDE would be a
mess if there were a config option for everything. However, the
traditional appeal of KDE is configurablity. What are the usability
aspects of having additional, config-file-only options in KDE? This
would preserve the clean not-too-many-options current state of KDE 4,
yet let power users and KDE 3 refugees get the configurablity they
need. I understand that the line as to what gets a GUI option and what
gets a config file option will be hard to draw, but it would be no
harder to draw than the current line of what is important enough to
warrant yet another option in the menus.


[1] https://bugs.kde.org/show_bug.cgi?id=179782

--
Dotan Cohen

http://what-is-what.com
http://gibberish.co.il
_______________________________________________
kde-usability mailing list
kde-usability@...
https://mail.kde.org/mailman/listinfo/kde-usability

[Shaun Reich]

> What are the usability
> aspects of having additional, config-file-only options in KDE? This
> would preserve the clean not-too-many-options current state of KDE 4,
> yet let power users and KDE 3 refugees get the configurablity they
> need.

While I am not addressing the bug report directly, I will address the
generalities , the problem with adding configuration options to be
accessed only through the non-UI(config files), is not necessarily
just "usability", but the increased requirement of maintainability.

It is difficult enough as it is, to patrol and fix the issues with the
existing features. Adding additional features for a minority group, I
only see the disadvantages, greatly outweighting the possible
advantages.

Please understand, that for *most* cases where a configuration option
is wanted, it is not a simple (developer says): "oh okay, I will just
check that box then to let them configure it by hand". No, it is
creating functionality featureful or otherwise, from the non-existent.

In creating that feature, they have now introduced many future bug
reports from users who have it enabled, along with many wishlists for
features that they now feel can be added too, that merely remotely
coincide with the originally added one, just do to the catch-all
clause of "well this feature was added, this one is quite related to
that, so why not?"

Do also understand that there *will* be bugs with the newly introduced
features. It's an inevitability, and it becomes more hairy when you
add more and more of them, along with a large portion of the code just
being for config file options.

Do you see how it can add much more complexity to the hierarchy than
it just being (linearly), a "usability problem"?

--
KDE Developer,
Shaun Reich
_______________________________________________
kde-usability mailing list
kde-usability@...
https://mail.kde.org/mailman/listinfo/kde-usability

[dotancohen]

2009/10/26 Shaun Reich <predator106@...>:

>> What are the usability
>> aspects of having additional, config-file-only options in KDE? This
>> would preserve the clean not-too-many-options current state of KDE 4,
>> yet let power users and KDE 3 refugees get the configurablity they
>> need.
>
> While I am not addressing the bug report directly, I will address the
> generalities , the problem with adding configuration options to be
> accessed only through the non-UI(config files), is not necessarily
> just "usability", but the increased requirement of maintainability.
>
> It is difficult enough as it is, to patrol and fix the issues with the
> existing features. Adding additional features for a minority group, I
> only see the disadvantages, greatly outweighting the possible
> advantages.
>
> Please understand, that for *most* cases where a configuration option
> is wanted, it is not a simple (developer says): "oh okay, I will just
> check that box then to let them configure it by hand". No, it is
> creating functionality featureful or otherwise, from the non-existent.
>
> In creating that feature, they have now introduced many future bug
> reports from users who have it enabled, along with many wishlists for
> features that they now feel can be added too, that merely remotely
> coincide with the originally added one, just do to the catch-all
> clause of "well this feature was added, this one is quite related to
> that, so why not?"
>
> Do also understand that there *will* be bugs with the newly introduced
> features. It's an inevitability, and it becomes more hairy when you
> add more and more of them, along with a large portion of the code just
> being for config file options.
>
> Do you see how it can add much more complexity to the hierarchy than
> it just being (linearly), a "usability problem"?
>

Thank you, Shaun, I do realize how complicated it can be to add new
features. But for purposes of this thread, I have identified many bugs
that were closed because the developer felt that there the UI was
straying too far from simple. That is a valid point and I have no
intention of contesting it in the general sense, however many such
options are in fact necessary and users expect them. That is why I ask
about enabling the option, but keeping the UI simple by hiding it.
Those who need to know can use KDE Cheat Sheets or read the KDE
[Hidden|Advanced] Features wiki page.

I am interested in the usabiliy aspect of the approach. Of course, a
secondary appoach would be to have an Advanced Options tab that is not
hidden.

--
Dotan Cohen

http://what-is-what.com
http://gibberish.co.il
_______________________________________________
kde-usability mailing list
kde-usability@...
https://mail.kde.org/mailman/listinfo/kde-usability

[macias]

On Monday 26 October 2009 07:20:49 Dotan Cohen wrote:

> Thank you, Shaun, I do realize how complicated it can be to add new
> features.

But we won't escape from it. Computers are getting more and more
powerful, and people realize that times of ZXSpectrum, one memory
size, one resolution, etc. are gone (*). Way there is so much power
spent on animating desktop than on customizing computer for Joe or
Kate? Does every user spin the desktop box (/me don't).

> That is
> why I ask about enabling the option, but keeping the UI simple by
> hiding it.

Cheap and effective (for given time) way. Of course there is always a
question if this or that feature could not be blend in by design, or
if it really does not deserve for option.

> I am interested in the usabiliy aspect of the approach.

I don't see any, because I think it is out of scope of "normal" user.
Such feature let customize computer for geek, or by geek for weekend
user.

> Of course,
> a secondary appoach would be to have an Advanced Options tab that
> is not hidden.

This is bad from U7Y point of view. Simple testcase -- systemsettings.
I have always have to do doublecheck, because I don't know in advance
where the option is placed, and the "advanced" is meaningless. So I
can search (by looking) in non-advanced tabs, but I have to _scan_
one by one the "advanced" section.

Cheers,

(*) I miss them ;-)
_______________________________________________
kde-usability mailing list
kde-usability@...
https://mail.kde.org/mailman/listinfo/kde-usability

[dotancohen]

>> Of course,
>> a secondary appoach would be to have an Advanced Options tab that
>> is not hidden.
>
> This is bad from U7Y point of view. Simple testcase -- systemsettings.
> I have always have to do doublecheck, because I don't know in advance
> where the option is placed, and the "advanced" is meaningless. So I
> can search (by looking) in non-advanced tabs, but I have to _scan_
> one by one the "advanced" section.
>

That is a good point. Is there a HIG specification on the issue of
advanced / hidden settings? I didn't see any, assuming that the entire
HIG is here:
http://techbase.kde.org/Projects/Usability/HIG

--
Dotan Cohen

http://what-is-what.com
http://gibberish.co.il
_______________________________________________
kde-usability mailing list
kde-usability@...
https://mail.kde.org/mailman/listinfo/kde-usability