Linked by Thom Holwerda on Thu 21st Jun 2007 22:14 UTC
KDE "If you visited the Plasma project's outdated Web site in past weeks, you might have gotten the impression that the team behind the project to revitalize the KDE desktop hasn't been up to much these past months. Delve into KDE's SVN repository, mailing lists, or the mind of lead developer Aaron Seigo, however, and you'll find a more exciting story." More here.
Thread beginning with comment 249708
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE
by Kroc on Thu 21st Jun 2007 22:54 UTC in reply to "RE"
Kroc
Member since:
2005-11-10

* clicking the sub-icon to open a file duplicates and confuses double clicking an icon to open it too. Is there a difference between the two? The user cannot be 100% certain. I thought when he first clicked the sub-icon that it would "edit" the file instead of "open", because it would be just plain weird to also open the file when double-click would do the same.

* Having an icon with the corners essentially lopped off y click regions makes for aiming, moving and processing icons more difficult. Especially considering that the sub-icons don't appear until your mouse is over the icon, meaning that if I'm rapidly dragging files from one folder to another, I could end up clicking one of the sub-icons very easy. My target is reduced.

* These icons can be mime-type specific. With lots of different apps vying for importance, the end user is going to have to manage these sub-icons. The average user rarely, if ever, ventures into Preferences. They will continue being annoyed by a feature rather than turn it off.

* Mystery-meat-navigation. You have no idea what's going to happen until it happens. An average user often fears that clicking the wrong icon will delete something. Presenting them with 4 icons to do with the one icon they're looking at is only going to increase this fear, let alone increase the amount of options they have to deal with.

I could go on for ages honestly, but it's 1AM in the morning.

I deal with completely average users every single day. People who even have difficulty using a mouse. I know very well what makes a good interface and what makes a bad one from many years of first hand experience. I can assure you that I've clocked up more hours of watching users using interfaces than you or your team has testing KDE4.

Reply Parent Score: 5

RE
by BluenoseJake on Thu 21st Jun 2007 22:57 in reply to "RE"
BluenoseJake Member since:
2005-08-11

"I can assure you that I've clocked up more hours of watching users using interfaces than you or your team has testing KDE4."

That's a pretty arrogant assumption, and I would think probably wrong. Anybody can play that game.

Reply Parent Score: 5

RE
by Kroc on Thu 21st Jun 2007 23:01 in reply to "RE"
Kroc Member since:
2005-11-10

I've been fixing computers since I was 16 (7 years), do you want to place bets, because I'm pretty assured of my statement? I'm very much in the opinion that icons-on-icons is starting off on the wrong foot. No amount of improvement and tweaking can fix what is IMO a fundamental design mistake - layering click targets. Imagine if your browser back button went all the way back to the first entered page if you clicked the left half; and only back once if you clicked the right half. No amount of polish would fix a turd like that.

Edited 2007-06-21 23:07

Reply Parent Score: 5

RE
by aseigo on Thu 21st Jun 2007 23:10 in reply to "RE"
aseigo Member since:
2005-07-06

> clicking the sub-icon to open a file

it was a demonstration to show how clicking activates an action. since the icons already launch something it was the easiest action to perform, as it was pre-existing.

> Having an icon with the corners essentially lopped
> off y click regions makes for aiming, moving and
> processing icons more difficult

remember what i said about not having tried something? see, moving isn't impeded. if you click and drag on any part of the icon, including the little minibuttons, it moves. yes, this was tested on users and yes, had you tried it yourself you'd know that.

aiming and processing are silly points since they actually make aiming and processing easier as they give contextual regions to pre-qualify your aiming and processing.

> These icons can be mime-type specific. With lots of
> different apps vying for importance, the end user
> is going to have to manage these sub-icons.

straw man.

we've never said the icons were configurable or that individual applications would have a go at claiming those spots.

> Mystery-meat-navigation. You have no idea what's
> going to happen until it happens

which is also what happens with plain ol' icons until the user builds up a (rather sophisticated, btw) mental model of what happens when you click, double click, drag and right click on such a beast. you are operating from a pre-assumed body of knowledge and discounting the learning involved in acruing said body of knowledge.

moreover, i'm not sure what part of "we tested with text and will be moving in that direction" was hard to understand from my first reply, but there it is again.

> I can assure you that I've clocked up more hours of
> watching users using interfaces than you or your
> team has testing KDE4.

you really don't want to try to win a cock length contest on this one. trust me.

Reply Parent Score: 5

v RE
by Kroc on Thu 21st Jun 2007 23:13 in reply to "RE"
RE
by sappyvcv on Thu 21st Jun 2007 23:20 in reply to "RE"
sappyvcv Member since:
2005-07-06

it was a demonstration to show how clicking activates an action. since the icons already launch something it was the easiest action to perform, as it was pre-existing.

So if the concept is so useful, why couldn't you, for purpose of the demonstration, come up with some real-world uses for it so people can better understand why it exists and what problem it solves? Instead of making it do something that can and is accomplished with double-clicking already. That's generally what software companies do when demoying technologies.

straw man.

we've never said the icons were configurable or that individual applications would have a go at claiming those spots.


Ok, then tell us how it works?

which is also what happens with plain ol' icons until the user builds up a (rather sophisticated, btw) mental model of what happens when you click, double click, drag and right click on such a beast. you are operating from a pre-assumed body of knowledge and discounting the learning involved in acruing said body of knowledge.

Almost a valid point, but it's must most simplistic for existing icons. Double clicking opens the file in the default application, which is easy to remember. Dragging it to an application general opens the file somehow as well. Your technology has that AND it's adding up to 4 more actions per icon that can be VERY different per icon type. If you did add text labels it would definitely improve usability, but I'm still not convinced it's that useful.

Reply Parent Score: 2

ignore him please
by backdoc on Fri 22nd Jun 2007 03:25 in reply to "RE"
backdoc Member since:
2006-01-14

The amount of time, effort and energy kde developers put into kde is unimaginable.

There are ALWAYS going to be squeaky wheels that want to get greased. If you are not careful, you believe that they represent the majority.

When you are as knowledgeable and passionate about something as the KDE team, I know it must be difficult to ignore detractors. But, it costs you energy and momentum.

I understand constructive criticism. But, that it is not what Kroc is providing. His comments are arrogant, distasteful, out of order and antagonistic.

Just ignore people like him and know there are many many more who appreciate the hard work the KDE team is doing.

I'm sure you knew all of that. But, maybe it's nice to be reassured occasionally.

Regards and Thanks.

Reply Parent Score: 4

RE
by l3mr on Fri 22nd Jun 2007 08:01 in reply to "RE"
l3mr Member since:
2007-05-01

Did you also test it with users with visual or motor impairments? Or even only (KDE)-untrained users?

Can I at least disable it?

Reply Parent Score: 1

RE
by kanwar.plaha on Fri 22nd Jun 2007 01:40 in reply to "RE"
kanwar.plaha Member since:
2006-02-20

Kroc, I can bet my entire checkout of the kde4 svn last night that the moment GNOME guys copy this feature and proclaim it the greatest thing since sliced bread, you would stand up and applause too.

Having followed development of both DE's since they started off, I can say this with reasonable accuracy since every feature/app copied into GNOME suddenly becomes the most user-friendly and accessible and what-not.

Sorry, but i had to say this. It is rather frustrating to read comments such as yours and then read comments singing praises to similar features implemented elsewhere ...
Maybe, its a flame-bait but it had to be said.

Reply Parent Score: 4

RE
by hobgoblin on Fri 22nd Jun 2007 07:02 in reply to "RE"
hobgoblin Member since:
2005-07-06

the open action was clearly a proof of concept.

he talked about having special actions like adding to play list and similar.

hell, it may well be that double clicking can be disabled, given that these icons showed when floating the mouse over the icon.

hell, double clicking isnt perfect either. unless one makes sure to hit the icon every single time, one is bound to end up getting the "edit file name" function ever so often because one is a bit slow. sure, one can tune that in places like a control panel. but unless you think you know something about computers, you dont venture there for fear of breaking something.

Reply Parent Score: 2

RE
by eosp on Fri 22nd Jun 2007 16:53 in reply to "RE"
eosp Member since:
2005-07-07

clicking the sub-icon to open a file duplicates and confuses double clicking an icon to open it too. Is there a difference between the two? The user cannot be 100% certain. I thought when he first clicked the sub-icon that it would "edit" the file instead of "open", because it would be just plain weird to also open the file when double-click would do the same.


Opening the file was just an example. For a source code file, the buttons might be:
* edit it
* compile it
* (for a header) run a search to see what #includes it
* commit it into the tree

Or for a sound file:
* play it
* put it in the playlist
* share it
* view metadata

Reply Parent Score: 3