Problems with "vfolder" URI things, was Re: Structure in $HOME

[Seth Nickell <snickell stanford edu>]

> > If you're want a list of fonts, I think most people already look in,
> > well, one of the font lists available in say AbiWord.
> 
> So to install a font you use the file manager, but to see a list you
> have to launch a word processor.

I'm predicting what people will do, not necessarily saying what should
be. 

What is the use case you are thinking of? I think most people don't
think "I wonder what fonts I have on my system?" and think to use a file
manager. A file manager, however, is a very natural tool for adding new
extensions to the system, which a font sort of is (in some vague
conceptual sense). 

So now... backtracking a little... My objections to fonts:/// are
different. It *does* allow use of the file manager, and it shows all the
available fonts. Both of which are good things. One problem with
fonts:/// is that it, like all the URIs, is difficult to fit into a
normal user's "conceptual model" (think of it as "How they understand
how things work"). Heirarchical filesystems (as in "nestable folders")
are already very complicated for many people to understand. URIs just
blow the top off the bottle ;-) 

Another problem with all the URIs right now is that you have to know the
magic, know they exist, etc to make them work. Putting big lists of them
places is not a very good solution. This can probably be worked around
somehow, but until such time as we have a good interface for this, its a
major issue.

So one way around this is to somehow automatically "mount" URIs into
specific points on the filesystem. So if you visit ~/.fonts you actually
end up viewing fonts:/// (but you never have to see the weird URI). This
always scares the crap out of me, because if the facade ever fails you
have some really confused users. If it were done perfectly it wouldn't
be a problem, but done imperfectly it creates more usability problems
than it solves.

This relates to the other major issue I have with things like
fonts:///... Which is that its hard for users to understand what they
are. Why is it that some fonts are deletable (user installed fonts) and
others are not? What happens when there's a system font called "Malta"
and I copy a new font called "Malta" into the directory? What happens if
I then delete or rename the file called "Malta"? Basically, there's all
these weird edge cases that make it clear that fonts:/// is not a normal
folder (maybe there's a way to solve these? that would remove my
objection). I think one of the most disastrous thing you can do is to
mislead the user...

-Seth