unity-design team mailing list archive

[Jim Rorie <jfrorie@xxxxxxxxx>]

On Tue, 2010-04-27 at 23:55 -0500, Diego Moya wrote:

> In the cases I've witnessed, the hyperbole works more like "we've
> broken the current workflow for some real existing users in benefit of
> some hypothetical newcomers that could or could not use the new
> feature. And we don't provide a way for advanced users to restore
> their previously used workflow because, well, options are always bad".
> You won't overcome this perception with better language, because users
> in this situation have a valid concern that won't go away with an
> explanation.
> 
> I'm the first one to defend a simplified design for entry-level to
> average users even if it doesn't support expert features. But this
> kind of design should be only for new features and never, ever be put
> in place of a previous design already in use. This is the golden rule
> of computing - if ain't broke, don't fix it.


I couldn't agree with this more. It's the core problem, IMO.

However, the "options are always bad" isn't really fair to the UX team.
The stated reason is to limit options for testability reasons, which I
respect.  But, it's badly communicated.  

The result is the same.  The advanced users have to rely on themselves
or the community to restore lost functionality.

Attachment: smime.p7s
Description: S/MIME cryptographic signature