Bewertung Design Datenmaske

[oki]

Hallo,

da heute bei Luckie der Umfragetag ist und sowas auch anstecken kann mache ich hier mal auch so einen Thread auf.

Ich habe die Datstellung von DB-Daten zum Bearbeiten mal etwas anders gelöst.

Meine Frage ist jetzt mal ganz allgemein. Wie finden andere Leute diese Darstellungsform und was könnte man im Design besser machen.

Das Grundprinzip soll sein, dass mann für die Übersicht der Datensätze kein List-Element sondern einen Tree benutzt. Hierbei geht es mir nicht darum, ob es sowas schon gibt!!!! Ich bin von selbst drauf gekommen und möchte jetzt nur wissen wie ihr das findet und ob man in der Übersichtlichkeit was verbessern kann.

Dank voraus und Gruß oki

[Stanlay Hanks]

Also meiner Meinung nach hat ein Treeview Vor und Nachteile.
Natürlich, es erspart Platz, weil man nicht 3 Listboxen nebeneinander benötigt. Andererseits finde ich Listboxen wieder etwas übersichtlicher, denn wenn so ein "Baum" von einem Treeview mal weit "verzweigt" is, wird das, finde ich, auch mal schnell unübersichtlich.

[Hansa]

Hi oki,

ich machs kurz: Treeviews sind was für Programmierer, verwende die deshalb nicht. Dasselbe gilt für den DBnavigator. Die Menschheit würde ich nicht an so was dran lassen. 8)

[Luckie]

Zitat von Hansa:

Treeviews sind was für Programmierer

Wie bist du denn drauf? Mein Vater ist kein Programmierer und kommt wunderbar mit dem Explorer zurecht. Also so einen unqualifizierten Beitrag habe ich schon lange nicht mehr gesehen.

@oki: So ein Treeview lohnt sich nur, wenn sich mit dem Selektieren der Unterknoten auch der Inhalt auf der rechten Fensterhälfte ändert, denke ich.

[APP]

Hallo,
ich verwende mit DBs auch einen Treeview, aber
wie Luckie schon bemerkte, nur dann, wenn sich
die rechte Seite mitverändert.
Außerdem habe ich über dem Treeview eine Combobox,
mit der man Filter auswählen kann (zur Laufzeit per SQL)

z.B. alphabethisch nach Namen:

--A
..+- Assi, Arminger
..|
..+- Arbeiter, Klaus
--B

oder z.B. nach KundenNummern, usw...

[Marco Haffner]

Eine ListView oder ein Grid als Gesamtübersicht mit allen Namen, nach doppelklick auf den Namen ein neues Fenster oder ein neues TabSheet mit den Personen/Firmendaten und Versicherungsorte.
Über die Listview dann ein Edit zum suchen, ist was eingegeben wird nur noch das angezeigt das dem Suchkriterium entspricht.
Die Personendaten wirken auch noch etwas unübersichtlich, da noch sehr viele Informationen angezeigt werden, die vielleicht nicht alle auf den ersten Blick benötigt werden. Zum Beispiel Telefon und Bankverbindungen, nur ein Grid das bearbeitet werden kann, beim klick auf neu eine Eingabemaske öffnen. So wirkt es glaub ich weniger überfrachtet.

[oki]

Hi Leute!

Erst mal herzlichen Dank für die Antworten. Ich war schon in leichter Sorge, dass so ne Wertungsanfrage nicht so richtig interessiert.

Nun auch gleich ein paar Antworten.

Für Stanlay Hanks. Ich gebe Dir Recht mit der Erfahrung, dass Trees irgentwo unübersichtlich werden können. Das läuft dann so nach dem Explorer-Motto "Irgentwo habe ich die Datei hingelegt; Nur sie ist nicht mehr zu finden.
Das resultiert dann aber immer daraus, dass das Ablagesystem nicht ordentlich strukturiert ist. Ich versuche dieses Problem durch eine vorgegebene Struktur zu erschlagen. Wenn ich Trees für Datenbestände verwende (so wie hier) gibt es bei mir kaum die Möglichkeit für den Anwender Knotenverzweigungen selbst zu definieren.
Somit lege ich ein "Strukturfeld" fest, welches für die Knotenhirarchie relevant ist. Zum Bsp. für Kunden eine Klassifizierung in Privat, geschäftl. usw. Damit Entstehen dann Ordner "Privat", "Geschäftl." usw., die dann ausschließlich Einträge enthalten. Ob das so toll ist, keine Ahnung! Aber deshalb frage ich auch.

Nun zu Hansas Antwort. Auch wenn ich Hansas Meinung schätze (da schon öfter mit ihm zu tun gehabt) denke ich genauso wie Luckie. Ich glaube gerade das Trees für Nichtprogrammierer das ideale Mittel sind Strukturierungen in Datenbeständen zu visualisieren und damit übersichtlicher zu machen. Also hier würde ich echt streiten.

Für Luckie zur Bestätigung. Natürlich reagiert die rechte Seite auf Selektion im Tree. Ich hab jetzt so gar nicht daran gedacht das zu erwähnen. Alles andere halte ich für Stuß. Wenn man im Tree etwas auswählt will man "links" ja die Details dazu sehen. So muß es sein.
In diesem speziellen Fall funktioniert das auch umgekehrt. Navigiert man über den Navigator wird der Tree automatisch aktualisiert, also der Betreffende Eintrag selektiert.
Mit dem Navigator bin ich übrigens auch nicht so recht glücklich, aber irgentwie schummelt er sich immer wieder rein.

Das von APP angesprochene Thema Filterung oder Suche von Einträgen ist ein ganz spezielles. Das es dazu gehört ist unstrittig. Zum Anfang habe ich in der Kopf- oder Fußzeile des Trees eine Combobox und ein Editfeld für Suchfeld und Sucheintrag eingefügt. Da es aber sehr praktisch ist gerade einen Tree mit einem Splitter zur Größenänderung auszustatten kann man tun was man will, irgentwie paßt die Optik nie. In der Regel benötigt man mehr Platz für diese Felder als man dem Tree in der Breite zugestehen möchte.
Nun bin ich teilweise dazu übergegangen dem Tree im Kopf einen Suchbutton zu verpassen. Damit öffne ich dann ein seperates Fenster StayOnTop, für den Sucheintrag. Die Datenmaske im Hintergrund incl. Tree reagieren zeitgleich mit.
Ich sag gleich: Mit dieser Lösung bin ich auch nicht so richtig glücklich.

Gut, mal sehn was sich noch so ergibt,

Gruß oki

[Stanlay Hanks]

Also wenn der User kaum eine Möglichkeit hat, die Struktur zu ändern, dann kanns ja kaum unübersichtlich werden. Warum sollte man das dann also nicht verwenden.

[oki]

Hi Stanlay,

so seh ich das auch! Ich gehe davon aus, dass das in Ordnung geht den Anwender hier einzuschränken. Denkt ihr das auch?

Gruß oki

[Stanlay Hanks]

Der Anwender kann dir ja nicht vorwerfen, du hättest in eingeschränkt, nur weil es ihm nicht erlaubt ist, alles durcheinander zu bringen oder eine andere DatenStruktur zu "kreieren". So seh ich das.