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

[Sean Middleditch <elanthis awesomeplay com>]

On Sun, 2003-01-12 at 20:03, Seth Nickell wrote:
> > > 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). 

I'd think I'd use a font manager program... something that does better
abstraction and specialized UI for the task at hand.  Just like I'd use
Galeon/Mozilla/etc. to browse the web, not my file-manager.

> 
> 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 ;-) 

Here the problem may be that we display the URI's to people.  If we're
going to use a file-manager for things that very well aren't files, we
should at least abstract a little better.

For example, the applications:/// URI - even if they are stored as files
in the system, that doesn't make sense to a user - they are menu
entries, not files.  The file browser concept works in that we use
browser navigation (up a directory, into a child directory, go back to
last location, etc.) *not* in that we are browsing
/some/folder/in/a/folder/with/cryptic/uris/and/unix/names.  Changing the
Nautilus location selector to something that better abstracts this could
go a long way here (as per the other e-mail I sent to list "user
friendly uri names")

Take the tree structure we have - make the location box in Nautilus a
drop-down menu with items like "System", "Media", "Desktop", etc.  Going
to system gives the system:/// uri (altho it should be displayed as
"System" in the location box with a nice icon), and it has varies
entries, possibly including "Installed Fonts".

I'm trying to remember how Windows does this - I think it does something
like have a drop-down box of the main URI's/locations (as per above),
and another with text entry for entering sub-locations (i..e, if I'm in
"Fonts", entering "/usr/share" will look for sub-folders in the Fonts
uri, which wouldn't exist).  That's a bit of a usability kludge,
perhaps; something more inventive and better could probably be thought
up...

> 
> 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.

Having the know URI's, having to know folder names... Having organized
lists of URI links, organized lists of folders... either way looses.

> 
> 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.

~/.fonts sounds  alot scarier than fonts:///.  That's a personal opinio
but, either way, the user has to type something in.

> 
> 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...

Which is why this information should be very clearly given to the user. 
Perhaps using a special icon/emblem for system fonts (the
non-writable/deletable emblem, for example).  Don't even put in an
uninstall/delete/move-to-trash context item for system fonts.  When you
have both a local and system font, that is a bit more complex.  I'm sure
a good solution could be fond, tho.  Perhaps again marking them
specially (an emblem for over-ridden fonts) and changing the "remove"
option to "remove local font" or "revert to system font".

The advantage of using a uri vfolder magic is that is helps to make the
point that it is not a normal folder, but a special location.  Making it
act special and not like a folder would help, too.  A real font manager
could probably do a much, much better UI to the whole thing.  But with
the Nautilus/file-manager craze everyone has, that's apparantly not how
it's gonna work (I guess eventually *every* app will just run inside
Nautilus, and look like Nautilus, and act like Nautilus... "ugh", so far
as I'm concerned...)

One of the advantages of having fonts:/// uri, or a ~/.fonts folder, is
that you can drop fonts into it to "install" the font.  Drag-and-drop
versus menues is probably a holy war along the lines of vi vs. emacs,
but I would think that you could just as easily have a font viewer and
installer be the default mime handler for fonts (click on font, viewer
opens, and if the font isn't installed already, have a "Install Font"
button), or setup a context menu entry (context-click, select "Install",
be done with it).  or perhaps have both these methods and the fonts:///
uri.

Really, *not* having a mime handler would be a very bad idea; imagine
the confusion that could set in if a user clicks on a font and gets a
weird "Nautilus has no handler for this file type" error, but yet is
able to context-click and install, or drop into a magic folder/uri to
install.  In the bare least, a tiny app should pop up asking the user if
they want to install the font.

> 
> -Seth
> 
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
-- 
Sean Middleditch <elanthis awesomeplay com>
AwesomePlay Productions, Inc.