Matthew Woehlke posted h4dgsh$vsu$1@xxxxxxxxxxxxx, excerpted below,
on Fri, 24 Jul 2009 18:42:08 -0500:
> Duncan wrote:
>> Question: Is there a reason it's abbreviated rather than spelled out
>> in the primary preview location?
>
> Mostly because it would be excessively long otherwise. See for example
> https://bugs.kde.org/show_bug.cgi?id=198978.
>> OTOH, there might be i18n reasons for your choice.
>
> Yes, in fact
That bug rather makes the point, doesn't it?
>> if that's the case, then wouldn't the same i18n issues apply to the
>> full word descriptions on the colors tab when other than common colors
>> is chosen?
>
> Hehe... see previously mentioned bug.
Interesting to see how good my shot in the dark actually was.
Unfortunately, it pretty well shoots down /that/ proposal.
>> But it didn't seem to be, as if I'm not mistaken, the primary preview
>> (abbreviated) has fewer elements (other than the button, etc) to
>> describe
>
> Ah... there /should/ be eight text (foreground) roles presented in the
> generic preview.
>
> /me counts...
>
> Yup, there are eight. As there should be.
OK.
> The set preview /had/ ten (that's per-row, mind; likewise the eight is
> for one row), but has now nine, as the background for Hover and Focus
> are not needed. But of course set preview doesn't have the window and
> button taking up extra space.
Indeed. 10 vs 8+, now 9 vs 8+. So there was indeed one more element,
but now it's effectively equal. And given the above i18n issues, if
anything, the full word version needs killed.
What about this? Would it be possible to have the important ones, say
thru inactive, in a "limited preview", and a button that would popup an
"extended preview" in, perhaps, a separate window, or perhaps a "vertical
expansion"? If so, that would reduce both sets substantially.
The current "Preview" label could be replaced by a "Limited Preview"
label and the usual "Details" (or "Extended") button, on the same line,
thus taking no more space.
Making the extended preview a separate window (utilities or whatever,
modeless), thus effecting a floating toolbar visible while the user makes
changes, should eliminate the too wide issue (particularly since it
wouldn't have the "icon-tab" list beside it).
And if it's a "Details" button, the "vertical expansion" mode as used
elsewhere in kde4 for details expansions could work reasonably well.
Since it'd be off by default, perhaps splitting each current row in half,
making two (four total) would work.
Talking about which, what about splitting it that way anyway? You could
even use your text size idea then, making the top row (thru inactive)
larger than the bottom row (negative onward), as you'd have considerably
more flexibility widthwise due to the otherwise shorter rows.
OK, there's some more targets for you to shoot down. =:^)
One other one: IIRC based on various dot articles I've read, etc, kde
does have at least limited access to some usability experts that have
volunteered to help. While as a power user I'm inclined to take a lot of
what they say with a huge grain of salt, otherwise we end up with the
emasculated config options of Gnome, it'd still be interesting to see
what they had to say about it, and perhaps they'll have some ideas that
can be put to practical use, without emasculating anything.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
___________________________________________________
This message is from the kde mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
