Tip zu Anwenderfreundlichkeit gesucht

[Timo]

Moin,

ich möchte den User in Formularfelder Informationen eintragen lassen.

Das läuft in etwa so ab:

Es stehen z.b. 10 Zeilen je 4 Formularfelder zum Ausfüllen zur Verfügung. Eine Zeile ist ein Eintrag (bestehend aus 4 Formularfeldern).

90% der hier einzutragenden Informationen sind aber bereits in einer db hinterlegt.

Meine Frage zielt nun drauf ab, wie ich mit den Mitteln HTML/mysql/php/Javascript/CSS eine für den User anwenderfreundliche Lösung produziere, diese 10 Zeilen so einzutragen, dass er die 90% Datenbestand hierzu bequem nutzen kann oder auch die 10% "Selbsteintrag" vornehmen kann.

2 Lösungen habe ich hierzu bereits umgesetzt (beide gefallen mir nicht wirklich gut):

1. Ich generiere bei einem der 4 Formularfelder per Ajax eine Vorschlagliste. Das geht ganz gut bei bis zu 3000 Datensätzen, die in der db hinterlegt sind. Danach wreden die Vorschlaglisten einfach viel zu groß.

2. Ich lasse die Zeilen jeweils einzeln eintragen, also nicht alle 10 auf einmal. Dann kann ich die Seite in einen Suchteil und einen Eintrageteil teilen und die Suchergebnisse per Javascript in die Formulatfelder übernehmen lassen.

Das ist ok, wenn man nur 2-3 Zeilen einzutragen hätte.

Was mir vorschwebt, ist eine userfreundlichere Lösung. Am besten so eine Art "Suchframe", aus dem heraus man die Suchergebnisse durch Klick oder drag an drop zu Formulareinträgen machen kann?

Ich suche keine Lösung, ich sucher hier nur Vorschläge, event. mit Link auf bestehende Projekte, damit ich das mal "at work" anschauen kann.

'Hoffe, meine Frage/Intention ist einigermaßen verständlich beschrieben.

Viele Grüße, Timo

[Texter mit x]

Meine Frage zielt nun drauf ab, wie ich mit den Mitteln HTML/mysql/php/Javascript/CSS eine für den User anwenderfreundliche Lösung produziere, diese 10 Zeilen so einzutragen, dass er die 90% Datenbestand hierzu bequem nutzen kann oder auch die 10% "Selbsteintrag" vornehmen kann.

1. Hole die Daten aus der Datenbank
2. Erzeuge ein Formular in dem die vorhandenen Daten vorbelegt sind (-> selfhtml -> HTML -> Formulare -> Eingabefelder -> Textvorbelegung)
3. Liefere das Formular an den Nutzer aus.

2 Lösungen habe ich hierzu bereits umgesetzt (beide gefallen mir nicht wirklich gut):

1. Ich generiere bei einem der 4 Formularfelder per Ajax eine Vorschlagliste. Das geht ganz gut bei bis zu 3000 Datensätzen, die in der db hinterlegt sind. Danach wreden die Vorschlaglisten einfach viel zu groß.

Ich glaube, Du mußt deine Fragestellung konkretisieren. Was soll ausgewählt werden? Wieviele Daten pro Eingabefeld sind vorhanden? In welcher - hm - Verbindung stehen die Felder bzw. deren Daten?

Was mir vorschwebt, ist eine userfreundlichere Lösung.

Dann sollte die auch ohne javascript zu benutzen sein.

[Timo]

Hi,

1. Hole die Daten aus der Datenbank
2. Erzeuge ein Formular in dem die vorhandenen Daten vorbelegt sind (-> selfhtml -> HTML -> Formulare -> Eingabefelder -> Textvorbelegung)

Ich weiß zu diesem Zeitpunkt doch noch gar nicht, welche Daten der User eintragen möchte. Er hat neben den ca. 100.000 db-Einträgen, von denen er zu 90% genau einen (je Zeile) wählen wird, ja auch die Möglichkeit, etwas für die db völlig neues einzutragen.

Heißt also, ich muss dem User eine wie auch immer geartete Suchfunktion einräumen.

Was mir vorschwebt, ist eine userfreundlichere Lösung.

Dann sollte die auch ohne javascript zu benutzen sein.

Darf man drüber streiten. Ich selber akzeptiere Javascript, bin aber auch mit einer Javascriptfreien Lösung einverstanden.
Da aber mein Projekt ohnehin nicht javascriptfrei ist, würde auch eine kavascripthaltige Lösung für mich in Ordnung sein.

Grüße, Timo

[Texter mit x]

Ich weiß zu diesem Zeitpunkt doch noch gar nicht, welche Daten der User eintragen möchte.

Und wie erfährst Du es?

Er hat neben den ca. 100.000 db-Einträgen, von denen er zu 90% genau einen (je Zeile) wählen wird, ja auch die Möglichkeit, etwas für die db völlig neues einzutragen.

Mein Glaube, daß es nötig ist, daß Du deine Fragestellung konkterisierts, festigt sich. Ich habe kein Vorstelluhng davon was wie in welcher Abhängigkeit geschehen soll.

Darf man drüber streiten. Ich selber akzeptiere Javascript, bin aber auch mit einer Javascriptfreien Lösung einverstanden.

Das eine schließt das andere nicht aus, ich schrieb es sollte auch ohne javascript nutzbar sein.

[Timo]

Mein Glaube, daß es nötig ist, daß Du deine Fragestellung konkterisierts, festigt sich. Ich habe kein Vorstelluhng davon was wie in welcher Abhängigkeit geschehen soll.

Dann stell es Dir einfach wie folgt vor:

Der User soll z.B. 10 Szenarien auswählen, zu denen jeweils eine SzenariennummerNummer, eine SzenariennummerBezeichnung, eine interne Bezeichnung, ein floatwert (z.B. Preis) gehört. Zudem darf er eine Menge wählen.

Nummer, bezeichnung, interne Bezeichnung und Floatwert gehören natürlich je db-Eintrag zusammen.

Ich möchte ihm nun die Möglichkeit geben, aus den x-tausend db-Einträgen die 10 Szenarien zusammenstellen zu können. (1 Szenario = 1 Zeile mit den o.g. Kriterien) oder einfach ein eigenes Szenarion (mit eigenen Werten zu kreieren).

Meine bisherigen Lösungen funktionieren sehr gut, aber ich habe auch erst eine kleine db. Wenn nun aber anstelle von 3000 Szenarien 150.000 Szenarien hinterlegt sind, wird meine Ergebnissmenge (z.b. bei der Ajax-Suchhilfe) so groß, daß sie keine Hilfe mehr darstellt.

Grüße, Timo

[Vinzenz Mai]

Hallo,

Mein Glaube, daß es nötig ist, daß Du deine Fragestellung konkterisierts, festigt sich. Ich habe kein Vorstelluhng davon was wie in welcher Abhängigkeit geschehen soll.

Der User soll z.B. 10 Szenarien auswählen, zu denen jeweils eine SzenariennummerNummer, eine SzenariennummerBezeichnung, eine interne Bezeichnung, ein floatwert (z.B. Preis) gehört. Zudem darf er eine Menge wählen.

Es ist eine sehr schlechte Idee, für einen Preis *Float* zu verwenden. Dafür gibts DECIMAL() und Konsorten. Ein wunderbarer exakter Datentyp, mit dem sich wunderbar rechnen läßt.

Nummer, bezeichnung, interne Bezeichnung und Floatwert gehören natürlich je db-Eintrag zusammen.

Ich verstehe Dein Problem ebenfalls nicht. Auch jetzt noch nicht.

Nach Eingabe der Szenariennummer sollten doch alle Daten abrufbar sein?
Ich kann mir nicht vorstellen, dass einem Benutzer Szenariennummern etwas sagen. Er kann sich sie also auch nicht merken und wird sie nicht eingeben.

Welche 10% Daten könnten fehlen. Kann der Benutzer eigene Kombinationen von Nummer, Bezeichnung, interner Bezeichnung und Preis erstellen?

Insgesamt sieht es mir nach einer typischen Warenkorb-Anwendung aus - mit einem Warenkorb fest vorgegebener Größe. Lass Dich doch von erfolgreichen Online-Shops in der Benutzerführung inspirieren.

Frage Dich selbst, wie Du ein Szenario auswählen würdest. Gäbst Du eine Nummer und eine interne Bezeichnung ein - und den Preis noch vor?

Freundliche Grüße

Vinzenz

[Timo]

Hallo Vinzenz,

erstmal danke für Deine Beteiligung.

Es ist eine sehr schlechte Idee, für einen Preis *Float* zu verwenden. Dafür gibts DECIMAL() und Konsorten. Ein wunderbarer exakter Datentyp, mit dem sich wunderbar rechnen läßt.

Sorry, natürlich nehme ich DECIMAL (6,2) als Datentyp. Meine Funktion, die den Datentyp vor dem Eintrag auf ihren Kontext hin überprüft, hat den Parameter *float*, daher die Verwechslung.

Ich kann mir nicht vorstellen, dass einem Benutzer Szenariennummern etwas sagen. Er kann sich sie also auch nicht merken und wird sie nicht eingeben.

Genau so sehe ich das auch.

Insgesamt sieht es mir nach einer typischen Warenkorb-Anwendung aus - mit einem Warenkorb fest vorgegebener Größe.

Ok. Der Einfachheit halber nehmen wir das ab jetzt an. Es geht also um einen Warenkorb, den der User anlegt und mit dem infolge des Requests "was auch immer" passiert.

Im Frontend hat der User ein Formular, in den er (Beispiel Warenkorb) die Artikelnummer, die Bezeichnung, und 2-3 weitere Felder eintragen kann. In diesem Beispiel natürlich sinnvollerweise nicht den Preis ;-)

Bei diesem Formular würde ich (und muß ich auch, wegen der verbleibenden 10% Freieinträge) schon ganz gerne bleiben. Also benötige ich für den User eine Art Eingabehilfe, um das Formular auszufüllen, da er ja meine Produktpalette nicht auswenig kennt. Er sollte also eine Suchfunktion zur Verfügung haben, in das er die Bezeichnung oder die Artikelnummer eintragen kann und das ihm dann eine Ergenissmenge präsentiert, die passend auf seine Suchanfrage ist. Auf einen Klick hin muß dieser Artikel dann in die erste freie Zeile des Formulars.
Wenn der User das 5 mal so macht, stehen also 5 ausgefüllte Zeilen dort und er kann es abschicken.

Frage Dich selbst, wie Du ein Szenario auswählen würdest. Gäbst Du eine Nummer und eine interne Bezeichnung ein - und den Preis noch vor?

Nur über eine Suchmaske, die Bezeichnung oder Szenariennummern findet.

Viele Grüße, Timo

Freundliche Grüße

Vinzenz

[Beat]

Im Frontend hat der User ein Formular, in den er (Beispiel Warenkorb) die Artikelnummer, die Bezeichnung, und 2-3 weitere Felder eintragen kann. In diesem Beispiel natürlich sinnvollerweise nicht den Preis ;-)

Schlechtes Beispiel, denn das ist nicht die Art und Weise, Bestellungen aufzunehmen.

Eine Aufnahme beginnt auf der Beschreibungsseite zu einem Artikel durch ein Formular, das ganz wenige Feld enthält (Menge).
Ein Klick sollte schlicht den Warenkorb aufstocken.

Du aber hast zu beginn von einem Formular gesprochen, indem der Anwender quasi neue Feldinhalte (Artikel) erfinden kann.

Bei diesem Formular würde ich (und muß ich auch, wegen der verbleibenden 10% Freieinträge) schon ganz gerne bleiben. Also benötige ich für den User eine Art Eingabehilfe, um das Formular auszufüllen, da er ja meine Produktpalette nicht auswenig kennt.

Dann präsentiere ihm die Produktpalette, von führe von dort aus die Aufstockung des Warenkorbs aus.

Er sollte also eine Suchfunktion zur Verfügung haben, in das er die Bezeichnung oder die Artikelnummer eintragen kann und das ihm dann eine Ergenissmenge präsentiert, die passend auf seine Suchanfrage ist.

Ja Artikelsuche. Aber die ist doch separat von einer Präsentation des aktuellen Warenkorbinhalts zu behandeln.

Auf einen Klick hin muß dieser Artikel dann in die erste freie Zeile des Formulars.

Nein: Auf einen Klick hin muss die Bestellung an den Server, der serverseitig den Warenkorb aufstockt.

Wenn der User das 5 mal so macht, stehen also 5 ausgefüllte Zeilen dort und er kann es abschicken.

Nein. Jedes 'In den Warenkorb legen' führt einen Submit aus.

mfg Beat

[Timo]

Hi Beat,

ok. Punkt1 ist, Du hast meine Frage genau verstanden. Dafür erstmal Lob, denn sie scheint gar nicht so einfach zu verstehen zu sein. Ich gebe zu, ich frage etwas ungenau.

Schlechtes Beispiel, denn das ist nicht die Art und Weise, Bestellungen aufzunehmen.

Hm. Die Art und Weise?
Ich bin da nicht so sicher, ob ich Dir da zustimmen will. Denn bei mir geht es darum, in kurzer Zeit viel zu bestellen (um bei dem Beispiel Warenkorb zu bleiben).
Die User wissen genau, was sie wollen und müssen es nur schnell finden können. 10 Requests für 10 Teile im Warenkorb macht da schon einen zeitlichen Unterschied aus.

Eine Aufnahme beginnt auf der Beschreibungsseite zu einem Artikel durch ein Formular, das ganz wenige Feld enthält (Menge).
Ein Klick sollte schlicht den Warenkorb aufstocken.

Ja, ok. Da fängt das Beispiel "Warenkorb" etwas an, zu hinken.

Du aber hast zu beginn von einem Formular gesprochen, indem der Anwender quasi neue Feldinhalte (Artikel) erfinden kann.

Ja. So ist es.

Dann präsentiere ihm die Produktpalette, von führe von dort aus die Aufstockung des Warenkorbs aus.

Wie meinst Du das genau?

Er sollte also eine Suchfunktion zur Verfügung haben, in das er die Bezeichnung oder die Artikelnummer eintragen kann und das ihm dann eine Ergenissmenge präsentiert, die passend auf seine Suchanfrage ist.

Ja Artikelsuche. Aber die ist doch separat von einer Präsentation des aktuellen Warenkorbinhalts zu behandeln.

Hm. Deine Idee hat schon was, das muss ich zugeben. Und es scheint wohl eher mein Problem zu sein, dass die Programmierung längst steht und ich alles konzeptionell umschmeissen müsste. Das verstehst Du sicherlich...

Auf einen Klick hin muß dieser Artikel dann in die erste freie Zeile des Formulars.

Nein: Auf einen Klick hin muss die Bestellung an den Server, der serverseitig den Warenkorb aufstockt.

Und zuletzt wird der Warenkorb präsentiert, das meinst Du doch?

Wenn der User das 5 mal so macht, stehen also 5 ausgefüllte Zeilen dort und er kann es abschicken.

Nein. Jedes 'In den Warenkorb legen' führt einen Submit aus.

So gut ich Deinen Ansatz nachvollziehen kann und so viel Richtiges ich ihm abgewinne. Das krieg ich nicht hin, die konzeptionelle Umgestaltung wird dafür zu groß.

Nachdem Du meine Problematik anscheinend ja wirklich verstanden hast, siehst Di eine eventuelle Kompromisslösung am Ende des Horizonts?

Grüße, Timo

[Beat]

Nachdem Du meine Problematik anscheinend ja wirklich verstanden hast, siehst Di eine eventuelle Kompromisslösung am Ende des Horizonts?

OK, du hast einen etwas speziellen Warenkorb für Massenbestellungen.
Es bleibt aber grundlegend das Gleiche.
Ich Unterschied zu einem Einzelwaren-Warenkorb dürfte sich für die Lediglich die Seite unterscheiden, die Waren präsentiert, indem sie viel stärker tabellarisch gegliedert ist und weniger die Waren beschreibt.

Nehmen wir an, du hast ein Lager von H-Trägern, T- und L-Profilen.
Jede dieser drei Seiten präsentiert eine Warenrubrik.

Jetzt wähle ich T-Profile und bekomme eine Tabelle aller Querschnitte.

Dazu erhalte ich in der Tabelle jeweils ein Mengenfeld. Vorbelegt mit 0.
Nun ist das ein gesamtformular.
Ich lege die Mengen fest und Submitte.
Dein Server muss nun meinen Warenkorb füllen und er gibt mir die Übersicht und einen Warenkorbzwischenstand (nur summarisch)

Jetzt gehe ich auf die Rubrik H-Träger. Same Procedure...
Unterschied: Der Server addiert jetzt zum Warenkorb.

Ausser den mengen ist alles vorgegeben.
Übersicht gibt es durch Rubriken.
Sondermasse sind hier nicht möglich,
Jeden Parameter, den ich einstellen kann, bedarf natürlich ein zusätzliches Feld.

Nun nehmen wir mal das beispiel:
Ich Bestelle ein L profil 60x60
Problem ist: ich brauche 10 Stück zu 2Meter und 20 Stück zu 1m60.
Die Länge darf ich einstellen aber wenn zwei verschiedene Längen will, wie bekommt die Tabelle die neue Zeile?
Mit javascript könnte, sobald ich die Menge > 0 für eine Länge notiert habe, eine neue Tabellenreihe erzeugt werden, welche mir für das gleiche Profil eine andere Längenangabe und andere Mengenangabe erlaubt.

Du ahnst aber auch, was die Rubriken bestimmt: Die Art der einstellbaren Parameter.

mfg Beat

[Steel]

Moinsen!

Auch mir ist nicht wirkich bewusst, was Du eigentlich machen willst. Es klingt nach ner Art google fuer Formulare. Du moechtest, wie bei google, dass bei Eingabe passende Vorschlaege gemacht werden?

Du schreibst was von 150.000 Datensaetzen a 10 Felder. Selbst eine Liste mit Daten aus denen der User waehlen kann, wird bei theoretisch 1.500.000 Begriffen wohl extrem Userunfreundlich.

Solange Du nicht konkreter wirst, kann man Dir auch nur schlecht Tipps gegeben, denn sowas ist situationsgebunden.

Generell wuerd ich einfach mal vorschlagen, nicht alle moeglichen Eintraege anzubieten, sondern eine Auswahl der am Meisten gewaehlten.

[hotti]

hi,

Ich suche keine Lösung, ich sucher hier nur Vorschläge, event. mit Link auf bestehende Projekte, damit ich das mal "at work" anschauen kann.

Mein Vorschlag: Eine Textarea und ein Multiselect nebeneinander. Dazwischen zwei Buttons:

>> "Alles hinzu"
   >  "Auswahl hinzu"

Da das Zielfeld eine ganz normale Textarea ist, kann der Benutzer auch eigene Zeilen hinzufügen.

Javascript ist Toll!!! Perl auch ;-)

Hotti