Filesystem helper, draft 1
- From: "Guillermo S. Romero / Familia Romero" <famrom infernal-iceberg com>
- To: gnome-gui-list gnome org
- Subject: Filesystem helper, draft 1
- Date: Sat, 12 May 2001 19:29:38 +0200
OK, lets start joining all in a way we can present to Nautilus people,
my notes go with [- -]. ;]
_- Filesystem helper -_
o Problem:
User, specially new ones, get confused with Unix dir names.
o Proposed solution:
Add a description near each dir in the tree, on by default, but
removable if user wants (advanced users, slow machines, small
screens). Coders will implement the system, and advanced user will
fill the descriptions (it is another way of documentation).
[-] / - Root of filesystem
[+] bin/ - Applications
[+] boot/ - System core
[+] dev/ - Hardware devices
...
[-] home/ - User homes
[+] barfoo/ - Bar Foo [- aka Full name -]
[-] foobar/ - Foo Bar
[+] desktop/ - On screen files [- Uum, complex description -]
...
[-] usr/ - Extra
[+] bin/ - Applications
...
[+] tmp/ - Temporal storage
...
vs
[-] /
[+] bin/
[+] boot/
[+] dev/
...
[-] home/
[+] barfoo/
[-] foobar/
[+] desktop/
...
[-] usr/
[+] bin/
...
[+] tmp/
...
o Reasoning:
Some systems create a virtual system on top of real one (Windows), or
hide parts of it (MacOSX). In both cases users will be happy until
something forces them to go outside of it, and that will happen sooner
or later. Better get real the thing right since day one.
Some people fear that users will wander due excesive options, and that
seems one reason to hide or virtualice. If the user knows what wants
and what does not want, it should not be a problem ("Do I want to poke
system or hardware things? No"), descriptions will guide the user ("I
need some place to store this for some time... uuum... tmp/ - Temporal
storage, this must be the place").
Descriptions should be short, and logical, so you can follow the path
and the descriptions, and then have some kind of phrase in mind. Next
list is a rough example:
/root/ -> Administrator home
bin/ -> Applications
sbin/ -> Administrative applications
lib/ -> Function libraries
lost+found/ -> Recovered after crash
man/ -> Manuals
doc/ -> Documentation
share/ -> Common
games/ -> Games
X11R6/ -> Graphic System
/dev/ -> Hardware devices
/proc/ -> System information
etc/ -> System configuration
/boot/ -> System core
/var/ -> System temporary storage
/mnt/ -> Removables and servers
/usr/ -> Extra (so you can read /usr/bin/ as Extra Applications)
local/ -> Local (Extra Local Applications ... rocket science ;] )
The descriptions could be based in a set of rules (regexp ie), that by
default try to cover most cases, but can be changed by admin and users
as needed. Access to env vars or files like /etc/passwd would be
great, so the system can write full user names and other things, not
just a fixed translation. IE, work fine when LC_* change.
This method centralizes changes, and actualizes as needed which is
great when system changes, ie a bin/ of a new network server mounted
as /mnt/servername/ will get Applications description if no rule was
created for it, but a global bin/ -> Applications rule is active, and
it could be read as Removables and servers Server name Applications
(read last to first and it make perfect sense).
It can be adapted to other views, and implemented as tooltips too (in
that case we think user should be able to choose among description,
tooltip and nothing).
The descriptions will be i18n, but the dirs will be kept as always,
thus systems are standard, users see what they really handle, but
explanations are clear. Long explanations go in help docs, so users
can get a long description of why there is a Extra (/usr/) ie, but the
system per se can be used without those explanations (maybe it slows
the users until they discover where preffered items are).
o Requirements:
Desktop should appear as a real dir (~/desktop/ or just ~/), so users
view it and can handle it like any other dir. Virtual solutions
confuse people. [- Coders had a thread about this, and I dunno how it
ended, I would vote for ~/desktop/ cos you do not have to put every
book you have at home over the table, only required ones, and you can
have "wires" or notes to others (symlinks) -]
o User testing:
TODO, but at least we avoid the already known basic problems: cryptic
names, hidden info and virtual system.
-_ End _-
Did I missed anything? Nothing virtual, configurable (at least on /
off, maybe more modes), translatable, tries to adapt to changes, does
not populate filesystem or leaves old configs arround.
GSR
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]