[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Ergonomische Verzeichnisstruktur
[Thread Prev] | [Thread Next]
- Subject: Re: Ergonomische Verzeichnisstruktur
- From: Philipp Schafft <lion@xxxxxxxxx>
- Date: Mon, 06 Jun 2011 20:05:40 +0200
- To: uugrn@xxxxxxxxxxxxxxx
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/