unity-design team mailing list archive

[Sohail Mirza <mirzmaster@xxxxxxxxx>]

Thank you, Diego, for your very well-articulated thoughts.

Your thoughts echo my own concerns (and I'm sure the concerns of many
others) regarding the challenges faced when design/experience changes aren't
qualified, aren't scoped adequately, or aren't communicated effectively.


2010/4/30 Diego Moya <turingt@xxxxxxxxx>

> 2010/4/30 Martín Soto :
> > The fact that human brains posses such a high plasticity, however, is no
> > excuse for us not getting our act together. Whenever you change a UI, you
> > will break someone's habituation to that UI.
>
> Not if you support both interactions, the old and the new. In many
> cases this is easier to do than it seems - just keep the old features
> as deprecated, instead of removing them.
>
>
> > Unfortunately, habituation is a
> > very complex issue: For example, people can be very creative while
> working
> > around a program's limitations, and this often involves using the program
> in
> > ways that were never taken into account by its original designers.
>
> You say that as if it was a bad thing.
>
> So, you're not going to support those users that create their own
> workflows? There will be only One True Way of using the system?
>
> You can design for simplicity, or you can design for flexibility. You
> can even do both at once, which I recognize is much harder to do. In
> any case, you must make very clear which one is the house manual of
> style. "We don't support that kind of users" is a valid reason to
> close a wishlist bug as wontfix, but only if you have a clear
> description of the supported users. This way people will know whether
> they fit in the target group and when to back off from a discussion
> about the system design.
>
>
> > This means that, given a large enough user base, even changes that appear
> > completely innocuous will likely end up irritating at least some users.
>
> Maybe, maybe not. That depends on how do you handle those changes. If
> you push changes down through their throats, surely you'll irritate
> them. Managing change means that you don't just "do things" without
> concern of how they will be received, only because someone will
> receive it badly. If you care about it, you'll reduce the number of
> users that get irritated.
>
> Explain the changes upfront and try to shield users from the negative
> effects of changes as much as possible. You can:
> - release new designs only when they are complete (no more "we're
> moving the window buttons so that in the future you'll get something
> awesome instead!")
> - release incomplete new designs as optional and opt-in, so it won't
> affect your less daring or willing users - only the early adopters.
>
> Benevolent dictatorship ("I do this way because it's what I think is
> good for the project") is a traditional management style in open
> software, but try to use it as a last resort if you don't want its
> side effects - people complaining about the dictated decisions.
>
>
> > Braking people's habituation will always cause problem, but absolutely
> necessary if you want to make progress.
> Is it progress when you're making people inconvenienced? You should
> take great care to distinguish progress from "change for the sake of
> change". And when in doubt, refrain from it.
>
> (Of course this won't matter if you keep those inconvenienced out from
> the project scope).
>
> _______________________________________________
> Mailing list: https://launchpad.net/~ayatana<https://launchpad.net/%7Eayatana>
> Post to     : ayatana@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ayatana<https://launchpad.net/%7Eayatana>
> More help   : https://help.launchpad.net/ListHelp
>



-- 
sfm