taskbar: onlyGroupWhenFull

[Michael Rudolph]

2008/11/2 Sebastian Kügler <sebas at kde.org>:
> On Sunday 02 November 2008 12:48:57 Michael Rudolph wrote:
>> 2008/11/2 Aaron J. Seigo <aseigo at kde.org>:
>> > it depends if you want to just start an exploratory session or actually
>> > pitch a mostly- or wholey-formed idea. but the essentials generally are:
>> >
>> > * be realistic
>> > * be ready to test
>> > * be ready to present tangibles beyond words
> [...]
>> > every time i've seen someone appear and end up with nothing happening
>> > it's because they have failed on one or more of the above.
>
>> now that's really great. Considering that I'm involved for quite a
>> while now, a sooner note would probably have helped all of us.
>> Regardless of the quality of my contributions so far, I think they
>> show at least enough engagement to warrant such a note from you
>> (anyone in the community) to tell me, that you don't know what to make
>> of my contributions.
>
> I wouldn't take this offensive, it just touches the very basics of KDE
> practicality.
>
> The "tangibles" thing is probably what you are afraid of since you "can't
> code" (put bluntly). So instead you need buy-in from those who do. How does
> one get this buy-in? By proving that working with you, based on your ideas and
> designs makes the lives of developers easier. There are actually quite some
> people inside KDE that "can't code" but have a lot of influence when it comes
> to technical implementation. Think of Nuno, Celeste, but also Dan Leinir
> Jensen. They all do design work and hardly ever touch code, still they're very
> respected inside the community and people actually listen to them and
> developers implement it in the way those designer-people tell them to.
>
> It's not easy, but it's also not impossible to have noticable influence on
> implementation without being a developer.
>
>> I think your distinction between philosophy and applied philosophy is
>> rather counter productive, but I won't go into that one; it'd probably
>> be rather philosophizing than applied philosophizing :-)
>>
>> I thought we agreed in Frankfurt, when we briefly discussed the ways
>> of the plamsa, that it would be better to keep the document rather
>> abstract, to not simply present solutions, but rather point to
>> mistakes of the past, show what's wrong with current user interfaces
>> or metaphorically speaking: show the box people are in, so they can
>> start to think outside of it themselves.
>
> I think a distinction between "applied design principles" and "crazy ideas
> that could make a difference in the future" is necessary here, and would in
> fact clear up the misunderstanding.
>
>> I sure don't mind presenting my own ideas (and see them become a
>> reality), that'd be absolutely amazing, but wouldn't it be much more
>> productive right now to bring disruptive ideas to wake everyone up and
>> thus allow everyone to come up with ideas of their own that are more
>> than just variations of the win95 idea?
>
> You know, there aren't a lot of disruptive ideas. There only are if you're
> watching from the outside. Every noticable innovation (with very little
> exceptions in fact) is the result of years of hard work and incremental
> improvements. It only looks like a disruptive thing to people who didn't
> follow closely. (A good read is "The Myths of Innovation" by Josh Berkus.)
>
> That would also explain why I don't see how "Plasma is so totally different
> for normal users" (while it supports pretty much all the exact workflows
> people are used to, only with added flexibility). It's hard to notice how much
> your child grows when you see it every day ... (wild guess here ;-)).
>
>> So if you have something different in mind or are simply not satisfied
>> with my execution on the ways of the plasma, just let me know. I'll
>> gladly help plasma -- with what I have to offer.
>
> I'd say it's your contribution. The more useful it is to people working with
> it, the more it'll be used. The more it'll be used, the more you can steer the
> direction plasma takes. (Well, probably not steer but facilitate the
> movement.)
> --
> sebas
>
Hello everyone,

thank you Marco and Sebastian for taking the time to reply.

I agree with you, that there is quite a misunderstanding here and also
that there will be quite a lesson to learn for me, once I try to do
design work with you guys. But there is also another misunderstanding:
I don't really want anyone to buy into my ideas or to implement what I
am talking about or to become my private developer.

I think it is one of the strengths of the open source collaboration
model to simply have a large number of people who individually scratch
an itch of theirs. And I think it would be detrimental to the open
source ecosystem, if there were too many people who do not code, yet
interfered with design decisions. S/he who codes decides.

It would be much more productive, in my point of view, for non-coders
to talk about itches or diseases, about health and medicine and
hygiene (yes, I'm a sucker for stretching metaphors till they burst
:-) so those who do the scratching can do it more informed and
generally more educated. That's beneficial in more than one way:
better scratching (of course), but self-reliance along with better
results helps to keep motivation high and helps to attract new
scratchers. Whereas telling scratchers how to scratch might yield good
results in isolated cases, but rather kills motivation in the long
run.

So what I think would be a good thing and what I'd like to do and I
was under the impression, that Aaron shared this conviction, is to
engage people in discussions around the topic of humans and computers
interfacing with each other. The ways of the plasma was one, probably
clumsy, attempt to do so. I think Celeste's offer to discuss the topic
of user research could be such a discussion, too.

So the question remains, how can this be done? (when even Celeste, who
is a well respected member of the community, can't get the discussion
going) This is of course assuming you all agree, that it could prove
useful to have more people with a working knowlegde of HCI.

I'm still rather clueless about how I can help plasma.

michael