ruben: Datensätze, die der Reihe nach angezeigt werden sollen.

Hallo,

ich arbeite an einem Vokabelprogramm und überlege grade, wie ich folgendes optimal konstruiere:
Vokabel-Datensätze sind ausgelesen.
Sie sollen abgefragt werden: D.h. man sieht das bekannte Wort, soll das Fremde eingeben und dann wird das Fremde Wort (im Moment per JS) angezeigt und es wird überprüft, ob die eingegebene Lösung und die gespeicherte übereinstimmen.
Der Nutzer kann dann bestimmen, ob es richtig gelöst wurde.
Das wird in die Datenbank gespeichert und die nächste Vokabel wird abgefragt.

Im Moment habe ich es so konstruiert, dass die Datensätze im Javascript gespeichert sind, dass nachdem man einen Button gedrückt hat, der Vergleich durchgeführt wird (JS, nicht PHP), dann mit Ajax gespeichert wird und mit JS die nächste Vokabel nachrückt.

Das ist nicht barrierefrei und außerdem machen die Datensätze eigentlich den Inhalt der Seite aus und sollten nicht nur im JS stehen.

Die Nur-HTML-Lösung, die ginge, wäre halt die Anzeige der Vokabel, woraufhin die Eingabe erfolgt, die Seite neu lädt, dem Benutzer die Möglichkeit gegeben wird, seine Eingabe als richtig oder falsch zu verifizieren und dann erneut abzusenden.
Problem: 2x neuladen machen dieses Unterfangen bei Mengen von 10-200 Vokabeln am Tag unglaublich nervig.

Lösung, die mir bei der Problembeschreibung einfiel:
Der Benutzer könnte erst für alle Vokabeln oder meinetwegen für 10 Stück die Antwort eingeben, dann absenden und dann überprüfen, wo es richtig war.
Das ist lerntaktisch nicht so gelungen, weil man das richtig oder falsch nicht direkt mit der Vokabel in Zusammenhang bringt.

Ich hätte gerne die barrierefreie Seite so, dass ich sie dann per JS in die schnelle Version modifizieren kann. Bei der obengenannten Lösung könnte ich dann einfach die übrigen verstecken, so dass es bei einem Eingabefeld bliebe.

Wie findet ihr die Lösung in Hinblick auf Barrierefreiheit? Mich ärgert sie, weil das Javascript, dass ich nutzen werde, eigentlich nichts ist, dass Behinderte nicht gebrauchen könnten, es ist kein visueller Schnickschnack, sondern sorgt einfach nur dafür, dass die Seiten nicht so oft neu geladen werden müssen und ein Workflow möglich wird. Außerdem ist es wie gesagt lerntaktisch etwas synapsenbrechend, schätze ich.

Vielen Dank für das Feedback,
Ruben

  1. Hi,

    Das ist nicht barrierefrei

    es ist lobenswert, dass Du so denkst. Aber das, was Du herstellen möchtest, hat (IMHO) eindeutig Applikations-Charakter. Hierdurch wird es Dir ermöglicht, allerhand Schweinereien einzuführen - von AJAX bis hin zu Frames. Die Kriterien einer solchen Anwendung sind andere als die, die für Webseiten im allgemeinen gelten.

    Die Nur-HTML-Lösung, die ginge, wäre halt die Anzeige der Vokabel, woraufhin die Eingabe erfolgt, die Seite neu lädt, dem Benutzer die Möglichkeit gegeben wird, seine Eingabe als richtig oder falsch zu verifizieren und dann erneut abzusenden.

    Jo.

    Der Benutzer könnte erst für alle Vokabeln oder meinetwegen für 10 Stück die Antwort eingeben, dann absenden und dann überprüfen, wo es richtig war.
    Das ist lerntaktisch nicht so gelungen, weil man das richtig oder falsch nicht direkt mit der Vokabel in Zusammenhang bringt.

    Richtig, so zu lernen erfordert einiges an Disziplin.

    Ich hätte gerne die barrierefreie Seite so, dass ich sie dann per JS in die schnelle Version modifizieren kann. Bei der obengenannten Lösung könnte ich dann einfach die übrigen verstecken, so dass es bei einem Eingabefeld bliebe.

    Also das klassische Vorgehen: Eine "pure" HTML/CSS/HTTP-Variante, die durch JavaScript komfortabel gemacht wird. Make it so. Oder definiere das Vorhandensein gewisser Techniken als Voraussetzung.

    Cheatah

    --
    X-Self-Code: sh:( fo:} ch:~ rl:° br:> n4:& ie:% mo:) va:) de:] zu:) fl:{ ss:) ls:~ js:|
    X-Self-Code-Url: http://emmanuel.dammerer.at/selfcode.html
    X-Will-Answer-Email: No
    X-Please-Search-Archive-First: Absolutely Yes
    1. es ist lobenswert, dass Du so denkst. Aber das, was Du herstellen möchtest, hat (IMHO) eindeutig Applikations-Charakter. Hierdurch wird es Dir ermöglicht, allerhand Schweinereien einzuführen - von AJAX bis hin zu Frames. Die Kriterien einer solchen Anwendung sind andere als die, die für Webseiten im allgemeinen gelten.

      Ja, es ist ganz klar eine Applikation, aber durchaus eine mit persönlichen Inhalten.
      Aber meine Denkweise ist klar: Auch Blinde können Vokabeln lernen, und sollten es können. Ist die Barrierefreiheit noch nicht so weit, dass sie mit Schweinerein umgehen kann? Du sprachst von anderen Kriterien, gibt es da offizielle Richtlinien oder de facto standards? Google Mail stellt eine nur HTML-Version zur Verfügung, da macht es aber auch noch mehr Sinn.

      Die Nur-HTML-Lösung, die ginge, wäre halt die Anzeige der Vokabel, woraufhin die Eingabe erfolgt, die Seite neu lädt, dem Benutzer die Möglichkeit gegeben wird, seine Eingabe als richtig oder falsch zu verifizieren und dann erneut abzusenden.

      Jo.

      Der Benutzer könnte erst für alle Vokabeln oder meinetwegen für 10 Stück die Antwort eingeben, dann absenden und dann überprüfen, wo es richtig war.
      Das ist lerntaktisch nicht so gelungen, weil man das richtig oder falsch nicht direkt mit der Vokabel in Zusammenhang bringt.
      Richtig, so zu lernen erfordert einiges an Disziplin.

      Würd ich noch nichtmal sagen, genauso viel wie das Vokabellernen an dem Programm überhaupt (was m.E. genauso Gewohnheit wird wie Stuhlgang). Aber auch wenn ich kein Hirnforscher bin, würde ich sagen, es ist einfacher zu lernen, wenn man sich immer auf eine Vokabel konzentriert und sie dann abhakt, statt erst einzugeben und dann eine Minute später nochmal drüber zu gucken. Aber kann genauso gut vorteilhaft sein, who knows.

      Ich hätte gerne die barrierefreie Seite so, dass ich sie dann per JS in die schnelle Version modifizieren kann. Bei der obengenannten Lösung könnte ich dann einfach die übrigen verstecken, so dass es bei einem Eingabefeld bliebe.
      Also das klassische Vorgehen: Eine "pure" HTML/CSS/HTTP-Variante, die durch JavaScript komfortabel gemacht wird. Make it so. Oder definiere das Vorhandensein gewisser Techniken als Voraussetzung.

      Das hab ich im Moment. Barrierefreiheit hat auch noch den Vorteil der Browser-Interoperabilität, Suchmaschinenfreundlichkeit usw. Außerdem darf man ja noch Ideale wie "Bildung für alle" haben.

      Gibt es irgendeine Bewegung, die darauf abzielt, inhalts-veränderndes JS von Schnickschnack und Darstellungs-JS abzugrenzen? Alles Schweinerei?

      Vielen Dank, öffnet Augen,
      Ruben

      1. Hallo Ruben,

        ich würde zuerst die Applikation ohne Javascript schreiben und auf eine semantische Auszeichnung achten. Alle Funktionalität stellt der Server zur Verfügung.

        Wenn diese Plattform steht, dann könntest Du _zusätzlich_ AJAX benutzen, um den normalen Seitenkomplettneuaufbau (schönes Wort, gell?) zu verhindern, indem Du den gleichen Request schickst, aber aus dem Serverscript als Response ein xhtml-Fragment übergibst und nur den veränderten Bereich mittels DOM durch diesen Baum ersetzt.

        Du könntest durch einen Parameter ajax=true eine Unterscheidung schaffen, damit das Script weiss, ob es eine komplette xhtml-Seite mit text/html oder ein Fragment mit text/xml übergeben soll.

        Gruß
        Olaf

        P.S.: Wie verwaltest Du eigentlich mehrdeutige Vokabeln? Wenn ich

        en: bar  |  de: ___________

        sehen würde, wüsste ich nicht, ob ich Bar, Latte oder (musikalischer) Takt eingeben sollte. Ich habe das Problem gerade bei norwegischen Vokabeln.

        1. ich würde zuerst die Applikation ohne Javascript schreiben und auf eine semantische Auszeichnung achten. Alle Funktionalität stellt der Server zur Verfügung.
          Wenn diese Plattform steht, dann könntest Du _zusätzlich_ AJAX benutzen, um den normalen Seitenkomplettneuaufbau (schönes Wort, gell?) zu verhindern, indem Du den gleichen Request schickst, aber aus dem Serverscript als Response ein xhtml-Fragment übergibst und nur den veränderten Bereich mittels DOM durch diesen Baum ersetzt.

          Du könntest durch einen Parameter ajax=true eine Unterscheidung schaffen, damit das Script weiss, ob es eine komplette xhtml-Seite mit text/html oder ein Fragment mit text/xml übergeben soll.

          Ja, das klingt gut. Ist nur schade, dass ich die Funktionalität (bzw. Geschwindigkeit) dadurch so einschränken muss. Das mit dem Parameter hatte ich eigentlich nicht vor, sondern einfach ein JS, dass abfragt, ob die erwünschten Methoden verfügbar sind.
          Ich werde Inhalt, JS und Design so gut wie mir möglich trennen. Das Problem ist halt, dass der Inhalt so dynamisch ist.

          P.S.: Wie verwaltest Du eigentlich mehrdeutige Vokabeln? Wenn ich
          en: bar  |  de: ___________
          sehen würde, wüsste ich nicht, ob ich Bar, Latte oder (musikalischer) Takt eingeben sollte. Ich habe das Problem gerade bei norwegischen Vokabeln.

          Das ist dem Nutzer selbst überlassen, da er die Vokabeln eingibt, bzw. importiert.
          Als ich Schwedisch (praktisch dasselbe in Schrift) gelernt habe, habe ich das gelöst, indem ich mir entweder das deutsche Wort mit der geringsten Mehrdeutigkeit genommen oder mir den Begriff nochmal in Klammern erläutert. Wenn du dir die Seite anguckst, siehst du das. Außerdem wird hier für gewöhnlich (ist wählbar) das Bekannte angezeigt und das Fremde eingegeben, d.h. multiple Bedeutungen können auch übernommen werden.
          Kannst es dir ja angucken, siehe URL.

          1. Hi,

            en: bar  |  de: ___________
            sehen würde, wüsste ich nicht, ob ich Bar, Latte oder (musikalischer) Takt eingeben sollte.

            Da gibt's noch wesentlich mehr Übersetzungsmöglichkeiten.

            "bar exam" ist ja kein Trinktest, sondern das Examen der Anwälte (in diesem Zusammenhang: bar = Anwaltschaft)

            Auch Schokoladenlatte klingt nicht ganz richtig, hier: bar = Riegel.

            bar kann aber auch Sperre oder Schranke bedeuten. Oder Strich (bar code). Oder Barren. Oder passend zum Themenbereich dieses Threads Barriere (obwohl da häufiger barrier als bar verwendet wird) ...

            cu,
            Andreas

            --
            Warum nennt sich Andreas hier MudGuard?
            Schreinerei Waechter
            O o ostern ...
            Fachfragen unaufgefordert per E-Mail halte ich für unverschämt und werde entsprechende E-Mails nicht beantworten. Für Fachfragen ist das Forum da.