Ivan Čukić

dr Ivan Čukić

Author of "Functional Programming in C++", KDE developer and Free/Libre software enthusiast

For inquiries about KDE projects (requesting features, submitting bugs, asking general questions etc.), you can use:

KDE Community Forum
Bug reporting site
#plasma IRC channel

You need to contact me directly?

KDE related:
ivan.cukic [at] kde.org

Non KDE related things:
ivan [at] this domain

IRC Network: libera.chat
Nick: ivan|home
Channel: #plasma

Projects

Blog categories

Functional Programming in C++

If you like C++, you might be interested in my book. It contains quite a few gems of modern C++ programming.

It is available for purchase at:

Patronage

Mmm, more pies!

Published by Ivan Čukić in the KDE development section, on 9 February 2010

A small visual update of Lancelot’s pies:

Concerning bars instead of pies:

Bars below the text (like in dolphin) will not be implemented:

I’m trying to keep everything in Lancelot generic enough with a complete model-view separation, so introducing a widget just for a specific model is not an option. Comment by Ivan Čukić — 7 February 2010
Bars as a part of the icon

This one would be allowed when concerning the above statement. But I don’t really see the point in doing it. When the usability is concerned, bars are more desired when comparing multiple statistical variables (national growth per year), while when percentages are concerned, pies are the way to go (and to increase the usability even more – these are color coded – from blue, through yellow to red). Introducing a new feature just for the sake of it is not something I’m willing to do. If you can convince me that bars* are better** than pies, I’m ready to listen.

bars that can fit into the icon itself like the current pies do. ** better as in “should replace the pies” - having a configuration option for something this insignificant would be a waste of space.

Comments:

Ivan Čukić
@<a href="#comment-12719" rel="nofollow">Federico</a>: To repeat myself: "But, you’re right, I’ll change it to feel more clock-like."
Fri13
I would take the bars as well. The pie is always hard to read, even showing a single data. And bars are not used anywhere else on KDE SC that it is not familiar to be see them in Lancelot while Dolphin and everything else use bars with background what makes them not to need the scale at all.
And the pie even takes big chunk away from the icons. And different colors are bad for space status because new/avarage user does not know what creen, yellow, red, blue etc colors mean.
But there is some problems with Dolphin way as well. That the space bar is shown only when hovering over the device or it is selected. (but I got answer that is technical problem not to query all the times the disk space and waking up the disks from sleep etc). Thats why I am littlebit questioning this pie even more.
Karl Ove Hufthammer
Pie charts may be the single worst way of displaying proportions, but when it’s used to represent only to categories (empty/used space), they are not too bad. Still, there are better alternatives.
The reason why they are so based, was first studied by William S. Cleveland, and as a mathematician, I am sure you’ll appreciate his interesting original 1984 paper:
Graphical Perception: Theory, Experimentation, and Application to the Development of Graphical Methods Author(s): William S. Cleveland and Robert McGill Source: Journal of the American Statistical Association, Vol. 79, No. 387 (Sep., 1984), pp. 531-554 Published by: American Statistical Association Stable URL: http://www.jstor.org/stable/2288400
For information specfically on problems with pie charts, the article ‘Save the Pies for Dessert’ by Stephen Few has a thorough discussion and several examples: http://www.perceptualedge.com/articles/08-21-07.pdf
Personally (and as a statistician) I have severe problems reading the pie charts in your screenshots. I’m still not quite sure which parts represent the used and the empty space. (OK, after reading the stuff about colour, I understand which parts represent what, but I still don’t perceive this when looking at the charts, and the use of blue as a colour makes the colour-coding even more unusual.)
The above problems disappear when using a well-designed (horizontal or vertical) bar, where the empty (transparent) parts represents the empty space, and the filled part (starting from the left or the bottom) represents the filled/used space. (If you’re just using two different colours on the bar, part of the perception problem reappears; it must be an empty colour and a fill colour. The fill colour can be colour-coded, from green through yellow to red.)
Ivan Čukić
@<a href="#comment-12714" rel="nofollow">Karl Ove Hufthammer</a>:
Well, the article you linked says exactly what I am speaking of, even when the author is biased.
"Pie charts are not without their strengths. The primary strength of a pie chart is the fact that the message “part-to-whole relationship” is built right into it in an obvious way."
It goes on further to say:
"A bar graph doesn’t have this obvious purpose built into its design. Not as directly, anyway, but it can be built into bar graphs in a way that prompts people to think in terms of a whole and its parts. This can be accomplished in part by using a percentage scale. It is easy and natural to think in terms of various percentages in relation to..."
I don't have the space to make *any* scales in bars. Or anything similar.
Federico
I'd like to see both implemented in a general class. Just think of bars and pie graphs embedded in icons to show information such as the state of progress of a copy operation or a print operation. I'd love to see this idea comes to life: http://forum.kde.org/brainstorm.php#idea38897
Great work!
Sorry for my bad english
Federico
Despite I am a physicist, I also agree with shamaz. Clock methaphor seems to be more intuitive to me than trigonometric circle: I noticed that I immediately watched at 12 o clock (north), expecting the graph to be on the right (clockwise)
Emil Sedgh
Hi First, the feature seems so cool. Is it commited to trunk? i svn up'ed but its not there.
Second, is there any way to change Lancelot tabs? Currently, Lancelot opens on 'Applications' tab. I actually use krunner to open applications. So i use Lancelot for its 'Computer' tab. However, i found no way of defaulting it.
Anyway, lancelot is nice. Keep up the nice work.
Ivan Čukić
@<a href="#comment-12703" rel="nofollow">shamaz</a>: I'm a mathematician, so the counter-clockwise is /natural/ to me :) But, you're right, I'll change it to feel more clock-like.
@<a href="#comment-12705" rel="nofollow">Shyru</a>: Finally a valid analogy for a bar. Still, it doesn't really convince me that bars are better. I'll ask Seele what she thinks.
@<a href="#comment-12707" rel="nofollow">Emil Sedgh</a>: Yes, it is in the trunk - has been since my last blog post.
As for the sections, I'll probably make the order (thus allowing the change in the default shown item) customizable for 4.5 - like Favourites (amongst other parts) are.
shamaz
@Ivan Čukić : ah ! :) the famous unit circle ! (we name this 'trigonometric circle' in my France) Now I understand :)
anon
Keep the pies. Don't worry about the naysayers. =)
shamaz
Well, I think bars would be better would be more simple to read. I realized while staring at your screenshot that I had a hard time finding how much space is really used... The reason is that apparently, you start to fill the pie at '3 o clock' (east). What's the rationale for this choice ? Starting at '12 o clock' (north) seems more natural to me, since everybody is used to the clock metaphor. Maybe '9 o clock' (west) would be another solution for people used to read from left to right (but there are also RTL users...).
shamaz
oh, I have to add that you are filling the pie in counter clockwise :)
Shyru
Perhaps vertical bars would be a great compromise. They would then represent the fill-status of a drive like a bottle is filled. This would be easy to grasp and see (imho easier than the pies, because it would look cleaner and not so busy, and judging how full something is by its fill-level is something we do every day when we look at bottles or a glass). It would also consume less space if placed on the left side of the icon. But thats just a suggestion, i'm also fine with the pies.
Chris
Forgive me if I'm missing the obvious but I don't get your first argument.
If you add a "fill state" to the model that represents the percentage of how much a disk is filled (0-100%) it would be perfectly fine to extend the main widget (showing only icon and name / path) by some other ones adding the specialized "fill state representation" logic (e.g. your current circle, vertical bars on the left, horizontal bars bellow the name / path and so on).
That way you would still have a clean model view separation with the possibility to use whatever visualization you want. What's the problem you see with this way?
Further I have to admit I didn't get the way your current circles represent the fill state either (starting at 3 o'clock and going counter clock wise) until I read the comments here ;D.
Last but not least I think that bars are perfectly fine to represent a fill state since we are already used it on computers (e.g. from other file managers) as well as in real life (e.g. an half full / empty bottle).
So it is basically a matter of taste about which one shouldn't argue ;D (and my above suggestion would allow everyone to get what one prefers while keeping the model cleanly separated from the view).
Could you therefore please reconsider this or explain why you don't like this suggestion so I perhaps can convince you? ;D
Ivan Čukić
@<a href="#comment-12730" rel="nofollow">Fri13</a>: Pies will be updated only on hover - so that the disk is not awaken - like in dolphin, but I'm still going to retain them even in non-hovered mode.
@<a href="#comment-12732" rel="nofollow">Chris</a>: "Expand the main widget"
The point is that almost everything (that is, everything apart from the edit box and scrollbars) in L is the *same* widget called ExtenderButton and its private subclass ActionListItem which adds DnD support.
So, all list items in all lists and everything else is essentially the same widget.
All models have the same API.
Now, introducing another method to the model and a feature for the ExtenderButtton/ActionListItem for the sole purpose of having a bar below the text (which would replace the mount path, which IMO is more important) in *one* model is a bit overkill, don't you think?

Ok, so, the best pro-bar reason I've heard till now is 'other kde apps do it'. You'll have to beat that one ;)

Write a new comment...