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: m...@ubuntu.com > To: holyknightjos...@gmail.com > CC: unity-design@lists.launchpad.net > 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@lists.launchpad.net > Unsubscribe : https://launchpad.net/~unity-design > More help : https://help.launchpad.net/ListHelp
-- Mailing list: https://launchpad.net/~unity-design Post to : unity-design@lists.launchpad.net Unsubscribe : https://launchpad.net/~unity-design More help : https://help.launchpad.net/ListHelp
