Bug 116752 - [usability] elegant taskbar reduces visible click target
Summary: [usability] elegant taskbar reduces visible click target
Status: RESOLVED WORKSFORME
Alias: None
Product: kicker
Classification: Plasma
Component: general (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: Aaron J. Seigo
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-11-20 12:23 UTC by Florian Grässle
Modified: 2006-03-15 16:42 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments
different taskbar entry representations (13.44 KB, image/png)
2005-11-20 13:54 UTC, Florian Grässle
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Florian Grässle 2005-11-20 12:23:24 UTC
Version:            (using KDE Devel)
Installed from:    Compiled sources
OS:                Linux

With kde 3.5 a new taskbar style is introduced: the elegant taskbar. It looks more elegant than previous versions, no doubt. But it has one negative side effect: due to the fact that the frame around taskbar entries is no longer visible (i.e. not until one hovers over the entries) it is not obvious by first sight where to click a taskbar entry. So for small entry titles like e.g. "juk" or "karm" the elegant style reduces the visible target to just the few letters of the names of these entries. In classic mode the whole size of the taskbar entry is the visible target.

While I personally like the look of the elegant taskbar I do think that it may pose problems for new users and even experienced ones. The frame around the taskbar entries is a visual guide which shouldn't be dropped by default. So I suggest the following:

1.) Make the classic taskbar look the default one

Note that this issue has been reported to me from several other experienced users.
Comment 1 Aaron J. Seigo 2005-11-20 13:07:33 UTC
> that it may pose problems for new users and even experienced ones

may or does? if the latter, what is the basis for the claim?
Comment 2 Marco Menardi 2005-11-20 13:52:10 UTC
I totally agree. One of the basic rules of UI is that the user must have a visual clue of the meaning of the visual elements. A "button" that looks as a button is imediately recognized as something that can be clicked. For instance, I do hate the "M$ IE way" of the toolbar, where tool buttons are flat (how can you guess is somthing that has to be "pressed"?) and also all grayed our until you pass over them with the mouse (how can you imediatly tell which ones are available?).
Something that "looks better" (from an aesthetic point of view) not necessary is more usable, and a UI has to be *usable* and easy to use. Maybe this flat taskbar looks better for someone (I don't agree) but your brain has not unconscious clue about a) is something that can be clicked? b) where to click?. Ok, you can become aquainted to all that bad design (like M$ IE), but this does not mean that we must follow that "non sense" when we can avoid it.
Comment 3 Florian Grässle 2005-11-20 13:54:20 UTC
Created attachment 13570 [details]
different taskbar entry representations
Comment 4 Florian Grässle 2005-11-20 13:56:52 UTC
> may or does? if the latter, what is the basis for the claim?

It does in the sense that -- as I said -- several people approached me with this issue.

One told me that the non existant frames around the taskbar entries would make her unnecessarily _think_ and wonder where exactly to click.

Have a look at the attached screenshot which shows the different behaviours:

-the juk entry doesn't have the frame. only the label represents the taskbar entry.
-the karm one does have the frame. the whole taskbar item appears as clickable at once. 

Sure - I didn't conduct a usability study. But if several people approach me with exactly the same problem independently it is a sign that something is wrong here.
Comment 5 Aaron J. Seigo 2005-11-20 22:10:33 UTC
> But if several people approach me with exactly the same problem independently

or it could mean that these are all people looking for usability issues and figure that this is a problem. but it has occurred before that people have assumed something would be meaningfully slower / more difficult and lo! it wasn't.

i'm generally fairly sensitive to such things; i even reorganize my window decorations to be more ergonomic. 

so just now i tested this with a user who uses windows to see how this would affect anything. they switched between windows with no problem (in fact, her only comment was why some items (the grouped ones) had arrows and the others didn't; a little exploration with the mouse gave her the answer =). i didn't inform her what was being tested for, only to switch between various windows (kwrite, karm and kontact being the buttons available).

interestingly, she ended up clicking not on the words but on the button area even though it is set to elegant. 

i really think we're dealing with a theoretical rather than a real problem here.

please feel free to test a larger number of people (one person is about 4 people shy of a proper test IMO) and prove otherwise.
Comment 6 Aaron J. Seigo 2005-12-01 18:19:31 UTC
3.5 is a happy place. if this issue actually does end up surfacing in coming months i'll address it, but i'm happy there.
Comment 7 Florian Grässle 2006-03-15 13:10:07 UTC
Yesterday a long time KDE user that upgraded to 3.5.1 told me he would never again do an upgrade without completely cleansing his .kde folder. When I asked him why he replied that something must have gone wrong and that now there are no frames around the task entries anymore which annoyed him a lot. I told him this was not a bug but a feature to make the task bar look better and that he could change it in the task bar settings. He needed further advice to find the respective setting.

Sorry, Aaron, but I really do think this is an issue. I talked this over again with two other KDE usability contributors, and we agree that the choice to make it the default setting was an unlucky one and should at least have been discussed beforehand.
Comment 8 Aaron J. Seigo 2006-03-15 16:41:59 UTC
> Yesterday a long time KDE user that upgraded

this is an upgrade expectation, not a "the flat buttons don't work!" issue. virtually every change made annoys someone or catches someone off guard. and people who are disgruntled tend to vocalize that, which is good but should be taken with that understanding (their increased vocality).

i've made a lot of changes in kde and kicker and many of those changes have had people report back they didn't like it. some had a -lot- of people report they don't like a particular change. i've come to learn that the fact people report they don't like it isn't meaningful in and of itself, but the reasons they don't like it.

many people have actually come up and expressed that they like the new kicker arrangement and i do feel it does have an overall positive impact on the desktop experience by reducing the visual clutter and letting people concentrate more on the central tasks at hand (which are almost never in the panel, btw, but in a window above the panel).

having watched people use the taskbar, i can tell you that there are two issues, one related to the 'elegant' style and one not:

1) the arrows for multiple-window buttons is not clearly associated with the button without mousing over. this is made worse on sparsely populated taskbars; it's also something that acclimatization helps relieve as the mouse over buttons provide visual feedback that there is grouping

2) it's very hard to find a specific button in a crowded taskbar unless you know the icons of all the apps. for beginner-to-intermediate users i've watched, it results in them being very slow with the taskbar. there's a fundamental issue with the taskbar here, though i'm not sure right now what to do about it (and it's not related to the lack or appearance of buttons.)
Comment 9 Aaron J. Seigo 2006-03-15 16:42:45 UTC
ah, i should also add that i've watched more people use the flat button taskbar since posting #5 ...