W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 1997

RE: conservation of complexity in UI?

From: Paul Leach <paulle@microsoft.com>
Date: Fri, 24 Oct 1997 13:55:14 -0700
Message-ID: <771E1FEEEE41D111A95900805FFE658712AD72@RED-MSG-51.dns.microsoft.com>
To: w3c-dist-auth@w3.org, "'Larry Masinter'" <masinter@parc.xerox.com>, "'Jim Davis'" <jdavis@parc.xerox.com>

> ----------
> From: 	Jim Davis[SMTP:jdavis@parc.xerox.com]
> Sent: 	Friday, October 24, 1997 8:38 AM
> To: 	Paul Leach; w3c-dist-auth@w3.org; 'Larry Masinter'
> Subject: 	conservation of complexity in UI?
> At 07:04 PM 10/23/97 PDT, Paul Leach wrote:
> >If you can show me at least one UI design that hides this complexity,
> >I'll buy it. Until then, it will be true that I've never seen a UI that
> >can make anything simpler than the underlying intrinsic complexity --
> >it's the law of conservation of complexity.
> I can name two right off the top of my head.
> Numerous Windows applications provide means to set properties and defaults
> for the application.   Aren't these stored in the Windows Registry?  I
> consider that complex.  Certainly the interface abstraction is simpler, if
> by nothing else than hiding much detail.
I consider this an example of hiding a complex encoding scheme, which I
agree can be done. However, the options themselves are either conceptually
simple or complex, independent of the registry being used to store them, and
I've never seen a UI that masks the conceptual complexity of what it

> The Z39.50 search protocol is a nightmare of complexity but most search
> UIs
> by contrast are simple.  One way they gain simplicity is by providing a
> higher level abstraction.  You will the form, it displays the results.
> The
> other is by hiding  rarely used but powerful features, e.g. Boolean
> operations.  These confuse naive users.  The really good UIs have
> progressive disclosure, so that if you actually need the advanced features
> you can get to them, bit by bit.
I don't think this is a counterexample, either, at least not in the security
context. When a naive user looks at an ACL, they have to be able to tell
whether "the bad guy" can get access to the object it protects. If some more
sophisticated person set the ACL using a complicated feature, they have to
know what it does -- they have to know what the consequence would be of
changing it, for example.

This is yet another security principle -- "Users must be able to understand
the consequences of every security relevant action they take".

Your comments, and others, have convinced me that my comment on UI and
complexity was too general.  I agree that UI can hide encoding complexity,
and that UI can hide little used features, and even disclose them smoothly.
But I don't think that it can hide inherent complexity in things that it
does expose.

In the security context, the problem is that one _must_ expose more than in
many other contexts.

Received on Friday, 24 October 1997 16:55:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:12 UTC