Open source user experience

[Celeste Lyn Paul]

On Wednesday 18 February 2009 03:39:54 pm Aaron J. Seigo wrote:
> On Wednesday 18 February 2009, Celeste Lyn Paul wrote:
> > On Wednesday 18 February 2009 02:09:11 pm Aaron J. Seigo wrote:
> > > On Tuesday 17 February 2009, Michael Rudolph wrote:
> > >
> > > honestly, we're lacking a couple of critical tools to really start
> > > bringing designers in en masse; plasmate is a step towards addressing
> > > that, but certainly can't/won't be the whole answer.
> >
> > Plasmate won't solve the people problem, it just provides a more useful
> > design tool to work with UI elements than Qt Designer.
>
> the reason i brought it up is that if we bring in designers of various ilk,
> but have few or no appropriate tools for them to use, it becomes a lot
> harder to sustain any sort of activity. it's a lot more useful when people
> can get directly involved versus talk at the people who are empowered to be
> directly involved.

Open source tools, right. There really aren't any and Plasmate will certainly 
be useful. However, there *are* other tools that most designers are using, so 
even if they aren't open source, they have resources. At the most basic level 
OO Presenter will do most of the work. High-level prototyping tools are 
useful, but not a necessary requirement to do useful design work. 

I rarely deliver high-level mockups to clients. I usually have no reason to 
paint something because a wireframe is usually enough to get the layout across 
and aesthetics are what the Oxygen team does (we had a good example of that 
this morning).

> > To me, Plasma
> > feels like a very exclusive team which is difficult to get in to.
>
> how does it feel that way?
>
> from my perspective, we have this plugin based system and a wide open
> playground where nobody has to ask permission to do anything.

That's technical participation. I'm talking community participation in the 
sense of getting involved in the design and decision-making process. 

> > There is
> > a small set of people working on an influential part of the environment,
> > but if you aren't developing Plasma widgets then you don't get to join.
> > If
>
> first, there will always be a small set of people. design does not work
> with 100 people sitting around the table searching for consensus all day.

I was not implying design by committee. We *are* discussing how to get more 
designers involved, no? All I'm saying that getting involved is difficult. I've 
been working with KDE for 5 years and I still think it is hard to participate. 
Imagine how difficult it must be for new designers, especially those with 
limited experience and exposure to open source developer culture.

> that said, which widgets do you feel "locked out of"? i mean, to be
> perfectly blunt, i haven't actually seen much input from others,
> particularly of the well informed sort, and that certainly isn't because
> there are barriers drawn around the widgets.

I'm not talking about the software (which I have been involved with), I'm 
talking about the design process on the conceptual level. 

> the tasks widget has had multiple authors that have taken it completely
> different directions. ditto for the system tray, and i'm sure there are
> other examples. that things can maintain some homogeneity in the process is
> a bit impressive, but it's not indicative of closed-walls dev.
>
> so there's evidently a human interface issue here (of the wetware sort).
> what are we doing to communicate to you that it's a closed city?
>
> > other people wanted to rethink high level concepts such as windows and
> > workflows, how do they do that when all of the creative thinkers are
> > locked in a room together?
>
> plasma isn't a room. it's a practical project for a bigger mindset.
> practical projects are absolutely required, otherwise nothing useful
> happens. reinventing every KDE app is just too big of a project to chew on;
> some would say we barely made it with just "reinvent the desktop code
> base".
>
> obviously, this isn't the "right place" to discuss, say, dolphin. there are
> some natural limits to the scope here, but they do extend to pretty much
> anything that's "desktop shell".
>
> so that said, if you want to rethink high level concepts such as windows
> and workflows, you are welcome to do that here.

So to get back on track here. Discussion begins about bringing more UX to KDE, 
namely how to do that. Plasma obviously has been doing that, but now it needs 
to get out to the greater project. So discussing things such as windows and 
workflows here is not appropriate because all it does is propagate the idea 
that Plasma is trying to take over the UX of KDE. (Which is a problem to a 
point you make later). 

The point of my statement was that Plasma is pretty much the only place with 
creative thinkers (plus Oxygen of course). Sure, people can subscribe to the 
list and maybe take an out of context tidbit away, but that doesn't work. Just 
because the information is free doesn't make it useful. 

So I guess there are 2 problems:

1) how to get more designers involved
2) how to propagate the high-level thinking necessary to do UX throughout KDE

> > Lately, I've been feeling there is Plasma on one side of the wall, and
> > then there is me with what's left of the usability project on the other,
> > with Nuno and the Oxygen team straddling the wall for random bits of UX.
> > I do my
>
> can you describe this wall a bit more? (so that we can address it)

I don't see where I can fit in, yet as the design hub of KDE, you would expect 
this is the place to be for an interaction designer. Plasma has the 
developers, because they make things happen, and then there is Oxygen and they 
make things pretty, but where does interaction and interface design fit in? I 
haven't been able to figure that out.

Design also goes from the thought bubble conceptual level to the code level. 
There is no design stage, which is the only stage I can really do anything at 
except for maintenance. Which maintenance is terribly boring. Sure, widgets 
and labels need tweaked, but junior-level design is a waste of my time when it 
is something someone else can be doing and I can be doing something else. If 
there is a major conceptual problem with the app, by maintenance it is too 
late to do anything like a rewrite. People just try to patch it until a whole 
lot of users complain.

> > best to help the developers who come to be with help, but it's not too
> > creative and limiting without team members.
>
> you're looking for a UX team that's dynamic and growth driven like the
> plasma team?

Yes, isn't that the point of the thread? How to get more UX in KDE?

> > You've probably noticed my
> > involvement with Kubuntu has increased over the past year in addition to
> > my other KDE work. The simple reason is that it allows me to get involved
> > in shaping the user experience more than KDE does.
>
> on the one hand, there's often a lot more of a cavalier attitude downstream
> for such changes. after all, if they don't say anything, the users just
> blame us upstream. as such, there's rarely as much care or concern applied
> to changes in our downstreams. it's more like "sure, whatever, let's do it
> that way and ship it. why not?", while we tend to try and think through
> things a bit more thoroughly. that means we move a bit slower, though
> really not so slow as to be anywhere near annoying or counter productive.
>
> other than the pace of making these type of decisions, i'm not sure what
> the differences are. perhaps you can provide some more details.

The pace is certainly an issue, but it's also about how the vision of the 
project is managed. Although the group is smaller (which probably helps) we 
occasionally take on a role that sits at that high conceptual level and take a 
top-down look at how all the pieces are working together and how they can be 
improved.

For example, if we would want to look at something like printing, we would 
look at all of the components involved in printing, decide on a solution, 
implement it, and submit patches/software upstream. If there are problems to 
solve that are too difficult for us to solve, we will then contact upstream and 
see what they say. But the expectation is that entire printing experience 
evolves cohesively and we have control over any independent variables.

To do something like that in a distributed project like KDE is extremely 
difficult. Each of those components is virtually "owned" by a different group, 
and so you have to find the maintainer for all of those parts, talk with them 
about your changes, submit the patches or make changes depending on if they 
want to do what you decided, revise the top-level design if there are any 
changes in the component proposals, and hope to god that each project commits 
the proposed changes, otherwise you end up with a mish-mash of changes where 
some components got updated, others didn't, and the possibility for 
inconsistency or cognitive dissonance.. I hope you can see how that's much 
more difficult.

Another more positive example of down->upstream is that when you work in a 
distribution, it is easier to find problems that will have the greatest effect 
because you work with it in context every day. For example, Riddell recently 
proposed a patch to make the power management applet and kickoff labels and 
icons match. They just happened to both be Plasma projects, but if you pretend 
that kickoff was maintained by another group, you can see how it would be 
easier for us to make the change ourself than hope that both upstream groups 
can agree with how to fix the problem and then fix them in a timely manner.

Making high-level improvements like these should be a reasonable attainable 
goal upstream, yet they remain to be extremely difficult to accomplish. I would 
hope a UX team would provide guidance and management on how to get this sort 
of thing done. We need fresh and new ideas, but we also need to manage and fix 
what we already have.

> > I always try to push the
> > good stuff upstream afterwards, but that's not the point. I should be
> > doing it upstream to begin with so everyone benefits.
>
> .. and so you aren't working counter productively to other parallel
> efforts.

I never said I was disconnected from upstream and I hope my involvement with 
Kubuntu doesn't make it seem like that. I always try to find a solution 
upstream before settling on fixing it on the distribution level. I usually do 
some research to see who the maintainer is and what they are working on before 
we do anything. Today's discussion in #oxygen about the konqueror homepage is 
an example of that. Riddell poking #kde-devel and sending appropriate and 
expected patches upstream is another.

> > I guess is that Plasma has a lot of things going for it in terms of it's
> > philosophy for creative processes. It could be used as a model for
> > founding a more project-wide initiative. However, it doesn't seem like an
> > open environment which can be easily joined, either by fresh designers
> > who are interested in contributing or extended in to the rest of the KDE
> > project.
>
> i guess step one is having the rest of the project respect plasma a bit
> more. you may not have noticed, but we're not the most popular group of
> people. we're the ones who fucked up the panel in 4.0, after all, if you
> don't recall. (yes, that's dripping with cynicism and sarcasm.) we struggle
> for respect from others, even those who are doing "new" things like the
> kwin people. there's very little interest in actually thinking big and
> worrying about things like "user experience".

I disagree, I think there is probably a lot of interest in thinking about 
things on the UX level. Projects outside Plasma are probably wary of it 
because they don't want Plasma to dictate their experience. Why are they wary? 
Sure, because of a bad experience with 4.0, but probably also because they 
don't know of or understand the process Plasma goes through. UX can be pretty 
scary to people who are used to doing and discourage "talk". "Talk" -- defining 
and solving the problem before a single line is written -- is 80% of design. 
If you solve the problem at the conceptual level, the hard part is over and 
designing the interface level is easy.

No, you don't want 100 people involved in everything, but you might have 100 
people all working towards the same UX goals, just in smaller, more 
concentrated projects. Projects tied to problems, not to a project, so it 
doesn't appear to be "owned" by anyone. Kwin is a great example where it 
involves more than just Kwin devs or Plasma devs.

KDE is very distributed without much high-level management of issues. That's 
probably why the KDE Usability Project is failing as a project and why I still 
manage to help a lot of developers with usability issues. As a project, there 
just aren't enough people that the dev community trusts to have oversight. 
Also, KDE is just too big to know what is always going on. On a personal 
level, it is much easier for people to contact me directly, however that does 
nothing to help the KDE usability project. It is also much more productive 
than posting on that damn list. I've gotten more done over IRC in the past two 
months than the list has done in the past year. But that's not sustainable, 
nor does it have the potential to grow, and I'm limited at the level I can 
help people at because I'm not involved in the projects that have the most 
influence in UX.

> this is why i created my own little playground right here: so i could get
> on with things without struggling against the tide constantly.
>
> as things pay off more and more visibly, i expect others to take notice and
> start adopting some of what we're doing. if we don't succeed wildly with
> plasma, it likely won't ever happen. it's that simple. developers, as a
> broad group, are simply too pragmatic and unimaginative to have it happen
> in some spontaneous frenzy of "i get it!".

They need to know what you're doing in order to adopt it. It's not that no one 
wants to, they just don't know how.  Unless you are involved in Plasma, you 
have no idea how the magic happens. I had assumed the point of this thread was 
to figure out how to make that happen everywhere in KDE, not just Plasma. 
There's no reason to just address Plasma because you've already got it.

-- 
Celeste Lyn Paul
KDE Usability Project
usability.kde.org