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 <[email protected]> > 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 : [email protected] > Unsubscribe : https://launchpad.net/~ayatana<https://launchpad.net/%7Eayatana> > More help : https://help.launchpad.net/ListHelp > -- sfm
_______________________________________________ Mailing list: https://launchpad.net/~ayatana Post to : [email protected] Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
