unity-design team mailing list archive

[Mark Shuttleworth <mark@xxxxxxxxxx>]

Josh, I'm happy to continue this thread, not to debate the merits of 
this particular feature so much as to help shape the way this team (and 
it needs to be a team, not a collection of individuals) thinks. If we 
want to build a broader team that helps with the design work, then that 
team needs a shared set of values and the guts to defend them.

Now, there are lots of different useful values. And Linux is lovely 
because it lets you do *anything*, which means we will have people come 
along who value just about *everything*. If we are going to shape a team 
here, that team needs to know what its values are and have the courage 
to defend them when folk show up asking them to value something 
different more highly.

I'm not saying my values are more important than anybody else's. In 
fact, I think I can appreciate the wonder of the diversity of open 
source more than most, since I am involved in many projects (other than 
Ubuntu) which celebrate different aspects of that co-operative, 
collaborative, take-it-and-do-amazing-things universe. So I'm not 
dissing those other cool things. What I'm saying is that here, in the 
Unity community (which is the default experience in the Ubuntu universe 
of experiences, many of which celebrate other things) we stand for and 
celebrate and value the challenge of making highly refined, easy to use, 
super productive experiences *on rails*.

The *on rails* bit means they are highly directed. We would rather have 
one super smooth way to get things done, than 50 rougher ways to get 
things done. This is a bit like the core design value of Python: have 
one clear way to get something done. It's why I called the company 
Canonical: find the cleanest, clearest way to do XYZ. And the project is 
called Ubuntu because it's about humanity in the mass, and the values 
which support that, rather than about individuals (who were empowered by 
Linux long before we came along).

"Highly directed" means they express opinion. If you can go with that, 
it should be amazing. If you desperately want to do it differently, it 
will feel like you are on a training winding its way through beautiful 
mountains, and all you want to do is get off the train and go hiking to 
explore. That's OK, and so is the train. I'm not going to ask all the 
trekkers to take horseback or walk the whole way just so some can 
explore the mountains - most want to get to the gold fields on the other 
side, quickly :)

On 14/02/12 20:52, Josh Strawbridge wrote:
> the people who are upset by this (myself included) feel like they've 
> had the most refined, highest quality option taken away from them in 
> favor of less refined options.

OK, so let's talk about that.

Picture the launcher as a piece of DNA. It will evolve over time, and 
there will be genes created that take it off in different directions or 
express different ideas. Imagine an evolutionary tree, with branches 
that survive and thrive, and branches that die off.

Code is like DNA, in this scenario.

So, we had an idea that it would be useful for the launcher to dodge 
windows. That is, to have a launcher in 'try to show' mode. We added 
some code (DNA) to express that behaviour. We essentially created an 
evolutionary branch for that DNA. And when we tested it, it failed. Badly.

It also caused all sorts of weird issues elsewhere. For example, we had 
to add code to Nautilus to move the desktop icons away from the edge of 
the screen, because if you can see the edge of the desktop, the dodging 
launcher would come out. So effectively, the edge of the desktop isn't 
there in the dodging scenario.

Now, we could have kept adding code to try and refine the dodge. The 
biggest issue was the interaction with maximisation. We could have added 
DNA to do stuff like the ideas expressed in this thread - jiggling the 
launcher when the setting is set, etc. I just don't think any of them 
would have fundamentally solved the problem, and that work would come at 
the expense of other work. It's open source, others are welcome to try 
and refine that behaviour, I just don't think it's salvageable. Even if 
it's a baby I cared for, I'm willing to let it go, it didn't work.

So, we went back to the earlier evolutionary branch, and we added a 
bunch of DNA to refine things like the heuristics of reveal under 
different circumstances for the simpler, autohiding case.

Now, you describe that as 'less refined'. Yes, it's missing an idea. But 
it's *much* more refined.

It's refined in its interaction with the pointer - it looks at how fast 
you are moving, how persistent you are. It has heuristics we can tweak 
to make it feel light - it shows quickly when you want it, and smart - 
it doesn't show when you don't want it. It has code to show a hint that 
it's coming - watch the edge closely as you move the pointer slowly and 
firmly against the edge.

In other words, that "simpler" branch of evolution has subsequently 
gained a whole bunch of subtle DNA. It's evolved. It's refined.

> it should be easy to see why we feel that way since a launcher that 
> gets out of the way when you are less likely to want it but ready and 
> waiting when you're more likely to want it is by nature a highly 
> refined option.

Err, no. It's an option that expresses one idea. It's a nice idea. But 
it fails testing, and causes complexity we don't want.

> for a number of us this would make the unity autohide the best 
> autohide on the planet and it might even make using always visible 
> bearable if not my preferred option as well.
> that way you've still got just the two codepaths but it adds at least 
> some of the refinement dodge windows offered back into the mix.

Well, we can agree that we both want the best auto-hide on the planet. 
For me, the number one criteria is that it is loved and appreciated by 
the most people who experience it. And we get that through rigorous 
testing. And dodge failed the testing. You need to accept that.

Beyond that, the number one autohide on the planet would:

 * launch quickly when you want it
 * not launch accidentally when you don't want it
 * provide cues that allow you to correct behaviour to avoid 
inadvertent launch
 * place things in a predictable fashion, so the same edge gives you 
the same launcher every time (this is important - you can't see the 
icons in the hidden launcher, so you have to guess where to send the 
pointer to invoke it, and it needs to be predictable)

Any other criteria you want to add?

Josh, from you email addy I take it you like the role of the crusader. 
Before you take out your sword on this one, spend a day thinking about it.

Mark