Re: New ideas

[Ken Fox <kfox vulpes com>]

Brooke and Nathaniel wrote:
> I find this article very intriguing.  The first half or so, about
> interface hardware, is a little silly, but the GUI portion of it,
> with the cobwebs and piles, is very interesting.

There seems to be a very stimulating feedback loop between GUI
design and hardware design. IMHO, the best designs are the ones
that have appeared when *everything* was on the table.

> I think the author's right in that instead of displaying lots of
> text, the UI should contain lots of "natural" visual cues that
> automatically tell you what you're looking at.  If designed and
> implemented properly, this could make GNOME a *real* winner.

Tog talks about yellowing the icons, adding cobwebs, etc. I've
played around a bit with this concept and it is extremely hard to
get right. It can also have side-effects -- yellowed/darkened
icons become more visible on white backgrounds which is exactly
the opposite of what happens on gray. Cracks and cobwebs have
similar problems and also make icons very hard to read.

I implemented last access times by fading the icon into the
background. This is simple and fast (and ideally could be done by
the X server during the XCopyArea of the icon to the window).
The cobweb suggestion was impossible for me to design so that
people could recognize it. Simple spider webs were sometimes
seen as connected to the world wide web. (A "web" document!)

File modification times are much harder IMHO. I ended up using
holes instead of cracks, like a moth-eaten cloth. They could
become hard to recognize, so I added smudges before moving to
holes. The smudges are easy to add algorithmically; holes almost
impossible. Also, holes work best when they are added to the
edges of the icon -- it changes the icon profile. Since most
file/folder icons use the standard base shape and add a little
graphic to the center, it should be possible to design several
base shapes and not have to invent a hole placing algorithm.
(I have the luxury/pain of designing all my own icons.)

Document size can be effectively implemented by stacks of
paper, i.e. instead of just one page showing, add pages
proportional to the log of the document size. 0-10K is one
page. 10-100K is two pages. 100-1000K is three pages. 1000+K
is four. I had to use less than the entire icon area for the
base page which makes it harder to design application graphics.

Folder size I never figured out, but that's probably because
I have a front-view folder. Moving to an isometric would allow
making the folder contents visible.

Adding information to icons is possible, but it requires
larger icons, which means less display density. I ended up
with 36x24 icons, which forced me to increase font size to
preserve the balance between icon weight and text weight.
About 20% of my users were happy -- they could finally read
the screen (which surprised me because very few people told me
this was a problem when I used 16x16 icons -- I guess they
were used to small displays and were embarrassed to complain).
Another 20% of my users were unhappy because they saw fewer
files at a time.

I haven't released the aged/sized icons yet, but my feeling
is that most of my users will not notice. The small pilot group
I've been working with is unfortunately self-selecting, and
they seem to care a lot more about details than my average user.

- Ken