Re: [Usability]URI's

[Ernst De Ridder <hnridder informatik uni-rostock de>]

On Wed, Jan 29, 2003 at 09:11:46PM -0800, Seth Nickell wrote:
> On Tue, 2003-01-28 at 15:29, Dave Bordoley wrote:
> > On Tue, 2003-01-28 at 18:20, Seth Nickell wrote:
> > > We desperately need a user solution to accompany the technical
> > > "solution" that URIs are trying to address. A lot of possibilities

Question: What is the "solution" precisely that URIs try to address, and
what are the problems encountered? To me as a user, an URI is some sort of
magical path consisting of a protocol (file, http,ftp,...) followed by a
path. The protocol tells me what program I can use to retrieve the file, and
the path says where it is. The error message present in the original mail,
about the 'burn:///' location, is not un-understandable because an URI is
used, but because nobody ever heard of that 'burn' thing. Would they have
written 'file:///home/you/filestoburn' it would have appeared less
frustrating. I would prefer the program to write just the path without the
file:// in such a case though.

> > > present themselves to my mind, from a sort of "mounting" system (this is
> > > roughly what OS/X uses for network filesystems of all sorts, and it
> > > automatically shows hardware devices) to some sort of "resource
> > > browser". It would be really nice if a lot of them could be merged into
> > > the standard user view of the filesystem cleanly with NO HOLES, for
> > > example having ~/Network or DESKTOP/Network or something.
> > > 
> > > -Seth
> > 
> > The one thing that I would find really nice, is to abstract the users
> > view of the system so that it appears that the desktop (or whatever the
> > doc refers to it as :) ) appears as the "root" of the system, similar to
> > the pre-osX mac.
> 
> Though systems like this are very confusing if the "truth" ever pops
> through. Right now, that would happen all the time because of non-GNOME
> apps (and "gnome" apps that don't use VFS).

Three thoughts on this:
First, it sounds very progressive and cool to talk about 'abstracting the
users view of the system', but in fact the unix view of a system is already
very abstract: A bunch of data is called a file, and those files are
organized hierarchically in a file system. A file system also stores
meta-information on a file like permissions, owner etc. Things like disks
are totally transparent to the user: you make them accessible using mount
and then they're part of the big hierarchy. There's nothing inherently
undoable about mounting the network on /network, see NFS, Coda and the like.
See also the way the system parameters in /proc work. Very abstract and
extremely convenient.

Secondly, taking the 'desktop' as the root is IMHO a bad idea.
It does not correspond to the way the system is actually organized, which
makes it difficult for the user to understand the system he's working on. It
also doesn't correspond to the users view of the world: My desk is not the
centre of the universe (well, it doesn't correspond to the way he _should_
view the world:-). And where do you put system files in such a case? Create a
directory 'system' under the 'desktop' and wait until users start
complaining 'I have these strange system/lib/*.so.6.4.2.1 files under my
desktop and I can't delete them'?
	The nice thing about home directories is that users know precisely
where they're boss (in $HOME), and where not. It's very intuitive that when
I go out of my $HOME I'm not allowed to move the furniture around anymore.
Please don't loose this clarity by perturbing reality in attempt to copy a
system which was not designed with multi-user and networking in mind.

Ernst

-- 
Ernst de Ridder - hnridder informatik uni-rostock de
Universitaet Rostock - Lehrstuhl fuer Theoretische Informatik
Albert Einstein Str. 21 - D-18051 Rostock - Germany
http://wwwteo.informatik.uni-rostock.de/~hnridder