[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Ergonomische Verzeichnisstruktur


reflum,

On Mon, 2011-06-06 at 13:35 +0200, Werner Holtfreter wrote:
> Am Montag, 06.06.2011 12:58:44 schrieb Werner Holtfreter:
> 
> > sollte man aus ergonomischer Sicht innerhalb eines Verzeichnisses
> > 
> > a) nur Dateien *oder* Verzeichnisse haben
> > b) Dateien und Verzeichnisse mischen?
> 
> Wie gewuenscht Erlaeuterungen zur Frage:

Huh? Ist meine mail nicht zur Liste vorvorgetrungen?

> Ja, technisch ist alles eine Datei und daher egal.

Ja, nur sah ich auch nicht technich keinen unterschied, deswegen die
Analogie. Aber s.u..

> Es macht aber ergonomisch einen Unterschied, ob eine lange Liste von 
> Unterverzeichnissen durch Dateien noch verlaengert wird oder ob, im 
> anderen Fall, der Zugriff auf eine Datei ueber eine weitere 
> Hierarchieebene fuehrt.
> 
> Keine grosse Sache, aber ich wollte halt mal wissen was sich 
> eingebuergert hat und was empfohlen wird fuer die Dateien unterhalb 
> /home, sowie im E-Mail und Bookmark-Verzeichnis. (Die sollten m.E. 
> alle (teil-)identisch aufgebaut werden, was man leider haendisch 
> machen muss, aber das ist wieder eine andere Sache.)

Ich denke ich verstehe dein Problem nun, nochmal zusammengefasst:
Es geht um (graphiche) umgebungen in denen lange listen als scrollbarer
bereich angeigt werden und immer im vollumfang (alle Datein im
Verzeichnis).

In diesem Falle sollte man sich in der Tat ueberlegen zusetzliche
aktionen wie scrollen zu vermeiden. Dazu haette ich folgende Ansaetze:

Der Flache Ansatz:
Man baut eine Hierachie mit N ebenen wobei auf ebene N-1 (der letzten)
alle Blatt-Knoten (flache Datein) liegen. Die Anzahl der Dateien pro
Ebene N-2 Knoten sollte dann (gleichverteilung) etwar N-1-te Wurzel der
Anzahl der Dateien sein. Sollen Maximal M Blatt-Knoten pro N-2 Knoten
vorhanden sein (also z.b. M=32 da etwar 32 Dateien in den Anzeigebereich
fallen) aus der menge aller Blatt-Knoten A (z.b. A=1024) so braucht man
N=ln(A)/ln(M) Ebenen.

Die durchnittliche Zugriffszeit ist nun also fuer alle Dateien gleich
(Nicht bereucksichtig dinge wie weg der mit der Maus zureuck gelegt
werden muessen). Dieses Verfahren ist sehr geignet wenn man viele
dateien die etwar gleichwertig sind speichern muss. Wird deswegen gerne
verwendet bei file servern. Z.B. in wikipedia URLs zu bildern.


Der Andere Ansatz ist die Zugriffs-Haeufigkeits-Sortirung:
Man Sortiert dabei Dateien nach Wichtigkeit, Unwichtige kommen in tifere
Ebenen und wichtige in hoehere Ebenen. Hier gibt ein mehre Verfahren und
verschiedene Ansetze. Die frage ist auch: Wie gut und Sauber ist sowas
in der praxis bestimmbar. Vermutlich ist ein Mathematich sauberer Ansatz
hier ehr nicht praktikabel sondern nur die Idee:
Z.b. dateien die selten benutzt werden weil sie alt sind in
Unterverzeichnisse auslagern (alte version,...).


Der Inhaltliche Ansatz (Was ich mache):
Der Versuch eine sauber normalisierte Struktur zu schaffen. Sollte in
einer Gruppe zu viele Blatt-Knoten liegen, so Runter brechen in
Unterverzeichnisse. Das fuert zu einer Mich struktur die mehr an den
zweiten Ansatz erinnert. Viele Verzeichnisse in denen Dateien landen die
man nicht Thematich untersortieren kann sind Archive und koennen z.B.
ueber den ersten, oder ueber Zusatz Informationen wie Zeitstempel
untersortirt werden.


Warum ich etwas verwirrt war zu Anfang und warum ich das Problem nicht
so extrem sehe: Ich arbeite fast ausschlliesslich auf der Befehlszeile
und meine Tastertur besitzt eine Tab-Taste. Das nimmt in der Tat das
Problem recht stark. Verzeichnisse bis rund tausend dateien sind kein
Problem in der Regel. Darueber hinaus ist es ehr ein Problem des ladens
des Verzeichnis inhalt (Ich habe gestern mit nem verzeichnis mit knapp
Hunderttausend Dateien zu tun gehabt. Da braucht das laden des
Verzeichnis index durchaus sekunden (weil ja auch zusatz informationen
(stat(2) gelesen werden (muessen)). Ich glaube in solchen Verzeichnissen
gibt es aber einfach keine gute Loesung.


So, und nun: Danke fuer's an den jenigen der das hier bis zum Ende
druchgehalten hat. :)

-- 
Philipp.
 (Rah of PH2)

-- 
UUGRN e.V. http://www.uugrn.org/
http://mailman.uugrn.org/mailman/listinfo/uugrn
Wiki: https://wiki.uugrn.org/UUGRN:Mailingliste
Archiv: http://lists.uugrn.org/