unity-design team mailing list archive

[nick rundy <nrundy@xxxxxxxxxxx>]

All this talk about design research etc reminded me of an interesting book that talks a lot about what people like, how research measures what people like (and how poorly designed studies that only take a snapshot can get it wrong), and how when people do like something they can't always articulate why they like it.

so far I think the ubuntu research is proving invaluable.

Book:  Blink by Malcolm Gladwell


> Date: Wed, 15 Feb 2012 10:54:37 +0000
> From: mark@xxxxxxxxxx
> To: holyknightjoshua@xxxxxxxxx
> CC: unity-design@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Unity-design] 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.
> 
> Mark
> 
> -- 
> Mailing list: https://launchpad.net/~unity-design
> Post to     : unity-design@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~unity-design
> More help   : https://help.launchpad.net/ListHelp