Navigation über große Tabellen

[_roro]

Annahme: Eine Tabelle mit name, phone, mobil, info (als Felder). Eine Tabelle mit 100 Records auf den Browser zu schicken, ist kein Thema.

Was aber, wenn es 1.000 Einträge gibt oder mehr? Welche Möglichkeiten zur Navigation sind denn benutzerfreundlich?

Ich hab folgende Ideen:
-die Tabelle wird häppchenweise im Browser ausgegeben, wobei der Benutzer festlegen kann, wieviele Einträge er sehen möchte (1-20, 21-30, 31-40 usw.), darüber hinaus kann nach Feldern sortiert werden,
-der Benutzer hat die Möglichkeit, mit einem Klick auf A | B | C usw. sich alle Einträge anzeigen zu lassen, wo der name mit A | B | C beginnt,
-der Benutzer hat die Möglichkeit, Einträge anzuzeigen wo der Anfangsbuchstabe eines bestimmten Feldes zwischen A und B (oder M und P oder sonstwo) liegen,
-der Benutzer hat die Möglichkeit der Volltextsuche (meier OR müller).

Gibts da noch mehr Möglichkeiten? Und wie bringe ich dem Benutzer die verschiedenen Möglichkeiten bei, ohne dass der beim ersten Aufruf der Seite überfordert ist?

roro

[King^Lully]

Ich hab folgende Ideen:
-die Tabelle wird häppchenweise im Browser ausgegeben, wobei der Benutzer festlegen kann, wieviele Einträge er sehen möchte (1-20, 21-30, 31-40 usw.), darüber hinaus kann nach Feldern sortiert werden,

Paging.

-der Benutzer hat die Möglichkeit, mit einem Klick auf A | B | C usw. sich alle Einträge anzeigen zu lassen, wo der name mit A | B | C beginnt,

Auch OK, wird oft kombiniert mit Paging.

-der Benutzer hat die Möglichkeit, Einträge anzuzeigen wo der Anfangsbuchstabe eines bestimmten Feldes zwischen A und B (oder M und P oder sonstwo) liegen,

Stichwort: data grids mit Filterfunktion

-der Benutzer hat die Möglichkeit der Volltextsuche (meier OR müller).

dito

Gibts da noch mehr Möglichkeiten? Und wie bringe ich dem Benutzer die verschiedenen Möglichkeiten bei, ohne dass der beim ersten Aufruf der Seite überfordert ist?

Das läuft alles unter data grids. Und der Nutzer hat das Steuerverhalten - eine gewisse Freundlichkeit des GUIs vorausgesetzt - so zu sagen von seinen Vorfahren geerbt (eine gewisse Verständigkeit des DAUs vorausgesetzt ;).

[Mathias Brodala]

Hallo _roro.

Annahme: Eine Tabelle mit name, phone, mobil, info (als Felder). Eine Tabelle mit 100 Records auf den Browser zu schicken, ist kein Thema.

Was aber, wenn es 1.000 Einträge gibt oder mehr? Welche Möglichkeiten zur Navigation sind denn benutzerfreundlich?

Ich hab folgende Ideen:
-die Tabelle wird häppchenweise im Browser ausgegeben, wobei der Benutzer festlegen kann, wieviele Einträge er sehen möchte (1-20, 21-30, 31-40 usw.), darüber hinaus kann nach Feldern sortiert werden,

Formular mit Auswahlfeld etwas oberhalb der Tabelle.

-der Benutzer hat die Möglichkeit, mit einem Klick auf A | B | C usw. sich alle Einträge anzeigen zu lassen, wo der name mit A | B | C beginnt,

Linkliste über der Tabelle.

-der Benutzer hat die Möglichkeit, Einträge anzuzeigen wo der Anfangsbuchstabe eines bestimmten Feldes zwischen A und B (oder M und P oder sonstwo) liegen,

Intuitiv wohl kaum implementierbar. Ich könnte mir höchstens vorstellen, dass ein Shift-Klick auf einen der alphabetischen Links einen Markierungsmodus auslöst und ein zweiter Klick auf einen Buchstaben diesen beendet und Einträge in Bezug auf die eben getätigte Auswahl angezeigt werden. (Wäre so nur mit JavaScript umsetzbar.)

-der Benutzer hat die Möglichkeit der Volltextsuche (meier OR müller).

Suchbox, ebenfalls in oben genanntem Formular.

Gibts da noch mehr Möglichkeiten? Und wie bringe ich dem Benutzer die verschiedenen Möglichkeiten bei, ohne dass der beim ersten Aufruf der Seite überfordert ist?

Meiner Vorstellung nach müsste sich dies alles recht unaufdringlich implementieren lassen.

Einen schönen Mittwoch noch.

Gruß, Mathias

[_roro]

Meiner Vorstellung nach müsste sich dies alles recht unaufdringlich implementieren lassen.

Jow, denke ich auch Mathias.

Viele Grüße, Rolf

[King^Lully]

Nachtrag:

Wenn Du den CRUD-Datenzugriff benöigst:
1.Zeile: Filterfunktion
letzte Zeile: Datensätze hinzufügen
Zeilenende: "single dat set view", "delete" und "update"

Aufpassen, dass Nutzer identische Daten gleichzeitig editieren könnten.   ;)

[_roro]

moin,

Aufpassen, dass Nutzer identische Daten gleichzeitig editieren könnten.   ;)

Ja gut, Luddi, zwei Fälle:

1. Transaktionssichere Tabelle
2. nicht transaktionssichere Tabelle

Otto ändert den Eintrag zu Willis-Phone-Number. Fast zur gleichen Zeit editiert Erwin den Eintrag zu Willis-Phone-Number.

Was passiert im Fall 'Erwin macht den letzten Klick'

1. Erwins Eintrag ist dominant, weil nach dem Transaktionskonzept die Engine schön und brav wartet, bis Otto fertig ist
2. Otto ist zwar schneller fertig, aber Erwin kommt später und überschreibt.

Hmm. Was gibts denn nun wirklich zu beachten? Transaktionssichere Tabellen?

roro

[King^Lully]

[...], zwei Fälle:

1. Transaktionssichere Tabelle
2. nicht transaktionssichere Tabelle

Otto ändert den Eintrag zu Willis-Phone-Number. Fast zur gleichen Zeit editiert Erwin den Eintrag zu Willis-Phone-Number.

Was passiert im Fall 'Erwin macht den letzten Klick'

Dann hast Du den Salat, Otto wird unglücklich, hier böte sich:

• eine Ablehnung der Aktualisierung Edwins an
• alternativ Aktualisierung nur im "single dataset view", wobei eine entsprechende Meldung "Datensatz wird gerade (von Otto) bearbeitet" hochkommen sollte

1. Erwins Eintrag ist dominant, weil nach dem Transaktionskonzept die Engine schön und brav wartet, bis Otto fertig ist
2. Otto ist zwar schneller fertig, aber Erwin kommt später und überschreibt.

Ist derselbe Fall. Oder?

Hmm. Was gibts denn nun wirklich zu beachten? Transaktionssichere Tabellen?

Tabellen sind nicht "transaktionssicher", sondern gesperrt oder nicht gesperrt (hier würde sich eine handgemachte Sperre auf Datensatzebene anbieten). Transaktionen spielen hier m.E. keine Rolle bzw. sollten keine Rolle spielen.

Richtig giftig wird es, wenn Du combo boxen hast, die auf andere Entitäten verweisen, die selbst gerade editiert werden.
Hoffe mal, dass Du sowas nicht hast, aber es ist kein Fehler rechtzeitig bestimmte Überlegungen anzustellen (Datensatzowner-Konzepte, check out-Konzepte, "Konzepte über Konzepte" ;).

Viel Spass!

[_roro]

1. Erwins Eintrag ist dominant, weil nach dem Transaktionskonzept die Engine schön und brav wartet, bis Otto fertig ist
2. Otto ist zwar schneller fertig, aber Erwin kommt später und überschreibt.

Ist derselbe Fall. Oder?

So isses.

Richtig giftig wird es, wenn Du combo boxen hast, die auf andere Entitäten verweisen, die selbst gerade editiert werden.
Hoffe mal, dass Du sowas nicht hast, aber es ist kein Fehler rechtzeitig bestimmte Überlegungen anzustellen (Datensatzowner-Konzepte, check out-Konzepte, "Konzepte über Konzepte" ;).

Hab sogar mal einen Artikel darüber geschrieben ;-) Er fand wenig Beachtung aber ab und zu komme ich beim Scripten darauf zurück. Für meine Team-Telefonliste, die eh nicht mehr als 100 Einträge erwartet, ist das auch alles freilich nicht so wichtig...

roro

[_roro]

moin,

Tabellen sind nicht "transaktionssicher", sondern gesperrt oder nicht gesperrt (hier würde sich eine handgemachte Sperre auf Datensatzebene anbieten). Transaktionen spielen hier m.E. keine Rolle bzw. sollten keine Rolle spielen.

Meine handgemachte 'Sperre' geht so:
Jeder Record hat einen timestamp (last modified).

Achmed in Mannheim lädt einen Record in seinen Browser.
Bogumil in Stuttgart lädt denselben Record zum Bearbeiten in den Browser.

Was beide nicht gleich sehen: Sie laden auch den timestamp in ein hiddenField oder Cookie.

Achmed ist fertig und drückt enter. Es erfolgt ein Update des Records und auch der timestamp wird aktualisiert. Stunden später hat sich auch Bogumil ausgemährt und drückt enter.

Das Script merkt nun, dass Bogumil mit einem veralteten timestamp daherkommt und vergleicht auch die einzelnen Values. Sind es dieselben, braucht das Script nichts zu machen, allenfalls den timestamp ändern, falls dieser auch für andere Prozesse interessant sein sollte.

Sind die Values nicht dieselben, sieht Bogumil einen Hinweis im Browser und kann somit entscheiden, ob er _seine Values submitted oder nicht.

roro

[King^Lully]

Was beide nicht gleich sehen: Sie laden auch den timestamp in ein hiddenField oder Cookie.
[...]
Sind die Values nicht dieselben, sieht Bogumil einen Hinweis im Browser und kann somit entscheiden, ob er _seine Values submitted oder nicht.

Vorbildlich!

(Oder fast, nie wichtige Informationen beim potentiell unsicheren Client lagern. Das heisst Prüfungen und Datenhaltung haben serverseitig zu erfolgen, oder hat King^Lully da mit "Cookie" und so was falsch verstanden?)

[_roro]

Was beide nicht gleich sehen: Sie laden auch den timestamp in ein hiddenField oder Cookie.
[...]
Sind die Values nicht dieselben, sieht Bogumil einen Hinweis im Browser und kann somit entscheiden, ob er _seine Values submitted oder nicht.

Vorbildlich!

Fühle mich geschmeichelt ;-)

(Oder fast, nie wichtige Informationen beim potentiell unsicheren Client lagern. Das heisst Prüfungen und Datenhaltung haben serverseitig zu erfolgen, oder hat King^Lully da mit "Cookie" und so was falsch verstanden?)

Prüfung und Datenhaltung serverseitig, klaro.
Aber zum Bearbeiten werden die Daten auf einen CLient geholt. Auch der timestamp. Es ist nur eine Frage, _wo_ der timestamp, der für den Bearbeiter von untergeordneter Bedeutung ist, clientseitig gespeichert werden soll.

Zwei Möglichkeiten:
-im Bearbeitungsformular (hiddenField),
-im Browser (Cookie).

Beides ist manipulierbar, das darf hier nicht verschwiegen werden. Wenn Bogumil möchte, dass unbedingt _seine_ Daten 'reinsollen, kann er ja einen timestamp nehmen, der nahe an der Echtzeit ist.

Das allerdings ist ein bischen Glücksache.

roro

[King^Lully]

Prüfung und Datenhaltung serverseitig, klaro.
Aber zum Bearbeiten werden die Daten auf einen CLient geholt. Auch der timestamp. Es ist nur eine Frage, _wo_ der timestamp, der für den Bearbeiter von untergeordneter Bedeutung ist, clientseitig gespeichert werden soll.

Dieser timestamp, der bewirkt, dass später dem "Zweiteditierer" die Meldung erscheint "Ersteditierer hat Datensatz nach dem Laden des Datensatzes durch Sie Herr Zweiteditierer aktualisiert, wollen Sie die Daten des Ersteditierers (werden ggf. angezeigt) überschreiben?", was macht der denn beim Client???

[_roro]

Prüfung und Datenhaltung serverseitig, klaro.
Aber zum Bearbeiten werden die Daten auf einen CLient geholt. Auch der timestamp. Es ist nur eine Frage, _wo_ der timestamp, der für den Bearbeiter von untergeordneter Bedeutung ist, clientseitig gespeichert werden soll.

Dieser timestamp, der bewirkt, dass später dem "Zweiteditierer" die Meldung erscheint "Ersteditierer hat Datensatz nach dem Laden des Datensatzes durch Sie Herr Zweiteditierer aktualisiert, wollen Sie die Daten des Ersteditierers (werden ggf. angezeigt) überschreiben?", was macht der denn beim Client???

Natürlich kann ich _den_ timestamp auch serverseitig halten, brauche dazu jedoch einen Mechanismus, der den Client identifiziert, damit die Zuordnung auf dem Server stimmt. Auch wenn ich diesem Mechanismus schon habe (bspw. AuthBasic oder Session-Cookie), warum sollte ich dieses Verfahren so verumständlichen? Eine extra Repository auf dem Server zu halten, wo drinsteht, wer wann welchen Record in seinen Browser geladen hat?

Schön und gut, wenn das so gewünscht wird, kann ich das machen, selbstverständlich, ja.

Aber es war nicht so gewünscht und wenn der Client ohnehin einen Datensatz lokal zu sich in den Browser holt, kriegt er auch den timestamp der letzen Bearbeitung mit.

roro

[King^Lully]

Schön und gut, wenn das so gewünscht wird, kann ich das machen, selbstverständlich, ja.

Es läuft im Prinzip auf die eher philosophische Frage hinaus "Kann eine SW-Entwicklungsanforderung richtig bzw. falsch bearbeitet werden?" und da sagen nicht wenige "nein".

Ich sage "ja", denn ich habe keinen Bock immer wieder quick&dirty Lösungen diskutieren zu müssen, d.h. ich spare die Kraft, die ich in Diskussionen investieren müsste.

[_roro]

Schön und gut, wenn das so gewünscht wird, kann ich das machen, selbstverständlich, ja.

Es läuft im Prinzip auf die eher philosophische Frage hinaus "Kann eine SW-Entwicklungsanforderung richtig bzw. falsch bearbeitet werden?" und da sagen nicht wenige "nein".

Ich sage "ja", denn ich habe keinen Bock immer wieder quick&dirty Lösungen diskutieren zu müssen, d.h. ich spare die Kraft, die ich in Diskussionen investieren müsste.

Ahmm, Du sagst "Ja" zur Frage "Kann eine SW-Entwicklungsanforderung richtig bzw. falsch bearbeitet werden?"? Oder ist das "Ja" Deine Anwort auf diese Frage?

Sag mal ;-)

[King^Lully]

Es läuft im Prinzip auf die eher philosophische Frage hinaus "Kann eine SW-Entwicklungsanforderung richtig bzw. falsch bearbeitet werden?" und da sagen nicht wenige "nein".

Ich sage "ja", denn ich habe keinen Bock immer wieder quick&dirty Lösungen diskutieren zu müssen, d.h. ich spare die Kraft, die ich in Diskussionen investieren müsste.

Ahmm, Du sagst "Ja" zur Frage "Kann eine SW-Entwicklungsanforderung richtig bzw. falsch bearbeitet werden?"?

Ich sagte "ja".

Oder ist das "Ja" Deine Anwort auf diese Frage?

Richtig, als Antwort auf die Frage, die scheinbar eine bejahende oder verneinende Antwort auszuschliessen schien.

[_roro]

Es läuft im Prinzip auf die eher philosophische Frage hinaus "Kann eine SW-Entwicklungsanforderung richtig bzw. falsch bearbeitet werden?" und da sagen nicht wenige "nein".

Ich sage "ja", denn ich habe keinen Bock immer wieder quick&dirty Lösungen diskutieren zu müssen, d.h. ich spare die Kraft, die ich in Diskussionen investieren müsste.

Ahmm, Du sagst "Ja" zur Frage "Kann eine SW-Entwicklungsanforderung richtig bzw. falsch bearbeitet werden?"?

Ich sagte "ja".

Oder ist das "Ja" Deine Anwort auf diese Frage?

Richtig, als Antwort auf die Frage, die scheinbar eine bejahende oder verneinende Antwort auszuschliessen schien.

Das ist wiedermal typisch EDVler!

Btw., da ist ein EDVler Vater geworden und die Kollegen fragen:
Junge ODER Mädchen?

Klare Antwort eines EDVlers: Ja

Logisch ;-)

roro

[King^Lully]

Btw., da ist ein EDVler Vater geworden und die Kollegen fragen:
Junge ODER Mädchen?

Klare Antwort eines EDVlers: Ja

Es ist ja noch schlimmer, der Baby-Bringer EDVler meldet "Junge bzw. Mädchen" und der Baby-Empfänger EDVler sagt, "Ja, danke!".

[_roro]

Moin,

Es läuft im Prinzip auf die eher philosophische Frage hinaus "Kann eine SW-Entwicklungsanforderung richtig bzw. falsch bearbeitet werden?" und da sagen nicht wenige "nein".

Ich hab es nicht gleich geschnallt, worauf Du hinauswolltest. Das liegt daran, dass ich bisher bei der Umsetzung meiner WebProjekte (Intranet) Freiräume hatte, von denen mancher Webdesigner nur träumen kann.

Ich kann mir des Weiteren gut vorstellen, dass manche Kunden die Begriffe 'Weg' und 'Ziel' verwechseln, so nach dem Motto 'Der Weg ist das Ziel'. Das mag für einen Urlaub durchaus die richtge Philosophie sein.

In einer einer Auftraggeber-Ausführender-Umgebung hingegen ist jedoch eben mal das Ziel, das Ziel zu erreichen und auch zu erreichen, dass der Auftraggeber wiederkommt und vielleicht auch Empfehlungen an weitere Kunden weitergibt. Wie das Ziel erreicht wird, liegt im Geschick des Ausführenden.

roro

[King^Lully]

Wie das Ziel erreicht wird, liegt im Geschick des Ausführenden.

Ohen jetzt in irgendeine Weise Dich, den ich sehr schätze, kritisieren zu wollen ist diese kleine "philosophische Frage zur SW-Entwicklung" eine der wichtigsten und darum durchaus kommentarfähig.

Wenn SW-Entwickler A mit SW-Entwickler B in Streit gerät bzgl. der ins Auge gefassten Umsetzung und SWE A wünscht eine saubere Lösung, während SWE B aus verschiedenen Gründen (oft ist es Inkompetenz, also Unverständnis, manchmal Performanceüberlegungen oder (zulässige) Systemvereinfachungen) eine q&d-Lösung wünscht, so besteht ein ernsthafter Konflikt, den typischerweise SWE B mit dem Argument der Wirtschaftlichkeit oft für sich entscheidet (er gewinnt den Konflikt in der Praxis bspw. indem er zu den Entscheidern der kaufmännischen Ebenen rennt oder einen IT-Entscheider mit kurzfristigem Planungshorizont für sich einnimmt).

SWE A hat dann also verloren und die Systeme auch, diese bleiben als wartungsunfreundlicher, weiterentwicklungsunfähiger und schlechter skalierbar zurück. Geschieht so etwas oft, gehen die Systeme kaputt, es entstehen teilweise auch so genannte Kathedralen (eine Code-Zeile ändern und das Mittelschiff bricht ein ;).

Kommt es zu dem beschriebenen GAU, hat SWE B auch gute Karten unbeschadet aus dem nunmehr Mega-Konflikt herauszukommen, denn er hat ja bereits Entscheider in SW-Architekturfragen hineingezogen, die dann auch in der Not zu ihm stehen werden bzw. müssen.   LOL

das ist so zu sagen der Kernkonflikt zwischen Abnehmern aus den kaufmännischen Ebenen und (guten) SW-Entwicklern.

[_roro]

Helo Luddi,

Wie das Ziel erreicht wird, liegt im Geschick des Ausführenden.

Ohen jetzt in irgendeine Weise Dich, den ich sehr schätze, kritisieren zu wollen ist diese kleine "philosophische Frage zur SW-Entwicklung" eine der wichtigsten und darum durchaus kommentarfähig.

Sofern ich eine Kritik wünsche, signalisiere ich, dass ich auch bereit bin, eine solche einzustecken.

Hab aber auch schon Kritiken verarbeitet, die ich nicht explizit angefordert habe.

Btw., Deine Meinung schätze ich auch, genauso wie die aller Anderen hier. Das Forum ist hochinteressant.

=zum Thema

Wenn SW-Entwickler A mit SW-Entwickler B in Streit gerät bzgl. der ins Auge gefassten Umsetzung und SWE A wünscht eine saubere Lösung, während SWE B aus verschiedenen Gründen (oft ist es Inkompetenz, also Unverständnis, manchmal Performanceüberlegungen oder (zulässige) Systemvereinfachungen) eine q&d-Lösung wünscht, so besteht ein ernsthafter Konflikt, den typischerweise SWE B mit dem Argument der Wirtschaftlichkeit oft für sich entscheidet (er gewinnt den Konflikt in der Praxis bspw. indem er zu den Entscheidern der kaufmännischen Ebenen rennt oder einen IT-Entscheider mit kurzfristigem Planungshorizont für sich einnimmt).

SWE A hat dann also verloren und die Systeme auch, diese bleiben als wartungsunfreundlicher, weiterentwicklungsunfähiger und schlechter skalierbar zurück. Geschieht so etwas oft, gehen die Systeme kaputt, es entstehen teilweise auch so genannte Kathedralen (eine Code-Zeile ändern und das Mittelschiff bricht ein ;).

Kommt es zu dem beschriebenen GAU, hat SWE B auch gute Karten unbeschadet aus dem nunmehr Mega-Konflikt herauszukommen, denn er hat ja bereits Entscheider in SW-Architekturfragen hineingezogen, die dann auch in der Not zu ihm stehen werden bzw. müssen.   LOL

das ist so zu sagen der Kernkonflikt zwischen Abnehmern aus den kaufmännischen Ebenen und (guten) SW-Entwicklern.

Ich sehe in Deiner Beschreibung eher Konflikte zwischen Entwickler A und B, die aus unterschiedlichen beruflichen Entwicklungen/Erfahrungen resultieren. Das ist ganz normal.

Beispiel von mir, Entwicklungsumgebung in einer multikollegialen Umgebung:

Ich war es schon immer gewohnt, meine Scripts mit dem vi zu schreiben. Meine Kollegen jedoch benutzen xemacs, ja der mit der automatischen Einrückung.

Nach ein paar kurzen Schlagabtauschen like 'Dein vi verhunzt mir die Lesbarkeit der Scripts' versus 'Dein xemacs verhunzt mir die Lesbarkeit der Scripts' haben wir uns schließlich auf den xemacs geeinigt.

Was ich damit sagen will: Der Klügere gibt nach.

roro

[King^Lully]

Was ich damit sagen will: Der Klügere gibt nach.

In diesem Sinne, Cheers!

BTW - super Wetter wieder, da gehts dann am WE raus ins Freie. Im Schwarzwald liegt vielleicht noch Schnee.