← Back to team overview

unity-design team mailing list archive

Re: No more dodge windows in Unity?


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.


Follow ups