Re: KDE is now broken (Fwd: Heads-up: KDE4 hitting testing tonight (UTC) )
On Wed, May 27, 2009 at 04:35:01PM -0500, Boyd Stephen Smith Jr. wrote:
> In <[🔎] 20090527205951.GP5158@cat.rubenette.is-a-geek.com>, lee wrote:
> >On Wed, May 27, 2009 at 12:10:54PM -0500, Boyd Stephen Smith Jr. wrote:
> >> >It's
> >> >something hidden from the user instead of telling them about
> >> >it. That's never a good idea.
> >>
> >> Actually, according to actual HCI studies it is often better to hide
> >> things from a user instead of telling them about it.
> >
> >What means "better" in that case?
>
> They are able to complete a series of tasks in less time or with less
> prompting/guidance.
>
> >> Now, once the user starts
> >> looking for that setting, it should be available, but too many settings
> >> and too much explanatory text confuses rather than enlightens.
> >
> >Whatever you do, there's nothing that helps against stupidity.
>
> And being confused by an over-abundance of options is not a sign of
> stupidity. While the number of facts one can track shows some
> correspondence to financial success, academic success, and the one-size-
> fits-all monstrosity that is IQ, it is much lower than the number of options
> that will fit on a 800x600 panel, even for the very
> successful/"intelligent".
I'm talking about knowledge and understanding. If your users don't
have sufficient knowledge and understanding to complete a series of
tasks, hiding knowledge and means to increase understanding --- or
indications that they might lack sufficient knowledge and
understanding or motivations to learn more --- will not enable them to
complete a series of tasks.
Given sufficient knowledge and understanding and an appropriate way in
which options are being presented, having options isn't confusing.
You can try to "level" everything down to "no
knowledge/understanding/skill/talent/intelligence required" and thus
try to keep your users stupid. But I don't want to use that kind of
software, and I'm against keeping people stupid.
> >Then it's irrelevant that translations can be "usually much faster"
> >when an RDBMS is used.
>
> Okay, but it is not irrelevant that the translations can still be hidden
> from the user so there's no reason to worry about minor migration issues
> with it anymore that with plain-text files.
They shouldn't be hidden.
> Change happens. Trying to prevent it is futile. Instead, focus on
> shaping the future into something you like better than the present.
That's why I'm saying it would be nice if something could be used or
invented that avoids future problems with reading/using data that has
been created a long time ago or stored for a long time.
Reply to: