Matthias Apsel: Wiki-Push im Mai

2 133

Wiki-Push im Mai

  1. 5
    1. 0
      1. 0
      2. 0
        1. 0
          1. 0
          2. 0
            1. 0
              1. 0
                1. 0
          3. 1
          4. 0
            1. 1
        2. 0
          1. 3
            1. 0
              1. 0
                1. 0
                  1. 0
                    1. 0
                    2. 0
                      1. 0
                        1. 0
                          1. 1
                            1. 0
                              1. 0
                                1. 0
                                  1. 0
                                    1. 0
                                      1. 0
                                        1. 0
                                          1. -1
                                            1. 1
                                        2. 0
                                          1. 0
                                            1. 1
                                            2. 1
                                              1. 0
                                      2. 3
                                        1. 0
                                        2. 0
                                          1. 0
                                            1. 0
                            2. 0
                              1. 0
                              2. 0
                              3. 1
                                1. 0
                                  1. 1
                                    1. 0
                                      1. 0
                                        1. -1
                        2. 1
                  2. 0
                    1. 1
                      1. 0
                        1. 1
            2. 0
              1. 1
                1. 0
                  1. 2
                    1. 0
                      1. 0
                2. 0
                  1. 0
              2. 0
                1. 1
                  1. 0
                    1. 0
                      1. 0
          2. 3
            1. 1
              1. 1
                1. 0
                2. 0
              2. 0
        3. 1
          1. 0
            1. 0
            2. 1
        4. 0
          1. 0
            1. 0
              1. 0
                1. 0
    2. 0
      1. 0
    3. 0
      1. 1
        1. 0
    4. 3
      1. 0
        1. 0
          1. 0
            1. 0
              1. 0
                1. 0
                  1. 0
                    1. 0
                    2. 0
                      1. 0
                        1. 0
                          1. 0
                            1. 1
                              1. 1
                2. 0
              2. 0
                1. 0
                  1. 0
                    1. 0
                      1. 0
                        1. 0
                2. 0
            2. 0
              1. 0
                1. 0
                2. 0
              2. 0
                1. 0
                2. 0
                  1. 1
                    1. 0
                      1. 3
                        1. 1
                        2. 0
                          1. 0

                            RESTful pattern

                            1. 0
  2. 3
    1. 1

      PHP/Anwendung und Praxis/Formulardaten auswerten

      1. 0
        1. 0
        2. 0

Hallo alle,

nachdem der Monat Mai schon ein wenig frotgeschritten ist und @Matthias Scharwies immer wieder versucht, neue Mitstreiter am Wiki zu finden, möchte ich das auch einmal probieren:

In der Liste der Tutorials fehlt eines zur Formulargestaltung. Es ist im Wiki zwar alles zu finden, angefangen von der Definition eines Formualars bis hin zur Validierung der Daten und zum Absenden der name-value-Pärchen, aber doch für einen Anfänger recht mühsam zu erreichen.

Außerdem kann man gerade bei Formularen auch aus usability-Sicht eine Menge falsch machen: Fehlende Label, falsch verwendete placeholder, unpassende Eingabe-typen.

Es wäre schön, wenn hier ein Leitfaden entstehen könnte, der zeigt, wie man ein einfaches Formular aufbaut, … (und die Daten schließlich entgegennimmt?)

Bis demnächst
Matthias

--
Es gibt viel zu tun - packen wir's an: ToDo-Liste gewünschte Seiten --
aus aktuellem Anlass mit geklauter Signatur
  1. Lieber Matthias,

    In der Liste der Tutorials fehlt eines zur Formulargestaltung.

    OK, ich fange dann einmal damit an.

    Liebe Grüße,

    Felix Riesterer.

    1. problematische Seite

      OK, ich fange dann einmal damit an.

      [x] done

      Demnächst kann ich die Beispiele zum Frickln dazu bauen. Aber ihr dürft gerne alle zuerst herumkritisieren. ;-)

      Liebe Grüße,

      Felix Riesterer.

      1. problematische Seite

        Demnächst kann ich die Beispiele zum Frickln dazu bauen.

        [x] done.

        Liebe Grüße,

        Felix Riesterer.

      2. problematische Seite

        @@Felix Riesterer

        OK, ich fange dann einmal damit an.

        Aber ihr dürft gerne alle zuerst herumkritisieren. ;-)

        OK, ich fange dann einmal damit an.

        Du nennst völlig zurecht <label> zum Beschriften „unverzichtbar“.

        Aber was soll „Zwar wäre das Suchformular bereits technisch funktionstüchtig“? Was heißt „technisch funktionstüchtig“? Was auch immer das heißen mag, es ist IMHO nichts von Relevanz. Ohne Beschriftung ist ein Formularfeld nicht funktionstüchtig.

        <label> gehört bereits mit ins Grundgerüst. Das Tutorial sollte gerade Anfängern nicht vermitteln, dass die Beschriftung nicht zwingend dazugehört.

        LLAP 🖖

        --
        “You might believe there are benefits for the developer, but first of all, you should put those behind the interest of the user.” —Stefan Tilkov
        Selfcode: sh:) fo:} ch:? rl:) br:> n4:& va:| de:> zu:} fl:{ ss:| ls:# js:|
        1. problematische Seite

          Hallo,

          <label> gehört bereits mit ins Grundgerüst. Das Tutorial sollte gerade Anfängern nicht vermitteln, dass die Beschriftung nicht zwingend dazugehört.

          warum machen es dann die großen wie:

          • https://www.google.de/
          • https://duckduckgo.com/
          • http://www.bing.com/
          • http://www.ebay.de/ (hier ist es zwar vorhanden wird aber versteckt)
          • http://www.amazon.de/
          • https://www.youtube.com/

          vor, dass man es auch ohne Label umsetzten kann? Ich meine die von mir genannten Seiten haben jeden Tag mehrere Millionen User die sich zurechtfinden und zwar ohne Label höchstwahrscheinlich sind darunter auch Blinde Menschen mit dabei.

          Dieses soll jetzt nichts gegen dich sein nur mich würde es mal interessieren warum so mächtige Seiten nicht an das angebliche vorgeschriebene HTML halten, oder sehen wir deutsche dieses einfach so eng und wollen alles "konform" umsetzten? Oder sind wir in Deutschland einfach wie mit so vielen 10 Jahren hinterher und die Entwickler in Amerika wissen schon mehr wo der Trend hingeht?

          1. problematische Seite

            Nachtrag zu meinem ersten Beitrag, nicht nur die großen Webseiten verzichten auf das <label> sondern auch die kleinen:

            • http://www.deutsche-startups.de/
            • http://winfuture.de/
            • http://www.gruenderszene.de/
            • http://www.rtl.de/cms/index.html
            • http://www.berlin.de/
            • http://www.hamburg.de/portalsuche

            also so falsch kann es nicht sein, wenn man auf <label> verzichtet, oder?

          2. problematische Seite

            @@Thomas

            Schauen wir mal:

            • https://www.google.de/

            <input title="Suche" aria-label="Suche" >Beschriftung vorhanden.

            • https://duckduckgo.com/

            Keine Beschriftung. Meh.

            • http://www.bing.com/

            <input title="Suchbegriff eingeben" > – Beschriftung vorhanden.

            • http://www.ebay.de/ (hier ist es zwar vorhanden wird aber versteckt)

            Das ist OK. Screenreader lesen die Beschriftung vor. Für Sehende ist der Zweck des Eingabefeldes ersichtlich. (No pun intended.)

            Weniger OK ist die Art, wie sie die Beschriftung versteckt haben.

            • http://www.amazon.de/

            Keine Beschriftung zu sehen. Aber <form role="search">. Bin mir nicht sicher, ob das was bringt.

            • https://www.youtube.com/

            <input title="Suchen" aria-label="Suchen" > – Beschriftung vorhanden.

            Übrigens haben alle bis auf Bing type="text" anstatt "search" gesetzt.

            Dieses soll jetzt nichts gegen dich sein nur mich würde es mal interessieren warum so mächtige Seiten nicht an das angebliche vorgeschriebene HTML halten

            HTML-Kenntnisse sind überbewertet. :-(

            LLAP 🖖

            --
            “You might believe there are benefits for the developer, but first of all, you should put those behind the interest of the user.” —Stefan Tilkov
            Selfcode: sh:) fo:} ch:? rl:) br:> n4:& va:| de:> zu:} fl:{ ss:| ls:# js:|

            Folgende Beiträge verweisen auf diesen Beitrag:

            1. problematische Seite

              Hallo,

              danke für deine Aufschlüsselung und Erklärung.

              <input title="Suchbegriff eingeben" > – Beschriftung vorhanden.

              das heißt also, ein <label> muss nicht immer vorhanden sein, ein title reicht auch aus?

              1. problematische Seite

                @@Thomas

                das heißt also, ein <label> muss nicht immer vorhanden sein, ein title reicht auch aus?

                Wohl ja. Wobei ich aria-label vorziehen würde; man will die nicht sichtbare Beschriftung ja nicht unbedingt als Tooltip aufpoppen lassen.

                In einem Anfängertutorial würde ich aber trotzdem label erstmal festschreiben, anstatt gleich mit WAI-ARIA auf die armen n00bs loszugehen.

                LLAP 🖖

                --
                “You might believe there are benefits for the developer, but first of all, you should put those behind the interest of the user.” —Stefan Tilkov
                Selfcode: sh:) fo:} ch:? rl:) br:> n4:& va:| de:> zu:} fl:{ ss:| ls:# js:|
                1. problematische Seite

                  @@Gunnar Bittersmann

                  @@Thomas

                  das heißt also, ein <label> muss nicht immer vorhanden sein, ein title reicht auch aus?

                  Wohl ja. Wobei ich aria-label vorziehen würde; man will die nicht sichtbare Beschriftung ja nicht unbedingt als Tooltip aufpoppen lassen.

                  Aber reicht aria-label auch aus? Ich hab da mal nachgefragt.

                  Léonie Watson sagt: „Use title attrib for good old/current AT support. Be sure visible label isn't needed by anyone else though.

                  LLAP 🖖

                  --
                  “You might believe there are benefits for the developer, but first of all, you should put those behind the interest of the user.” —Stefan Tilkov
                  Selfcode: sh:) fo:} ch:? rl:) br:> n4:& va:| de:> zu:} fl:{ ss:| ls:# js:|
          3. problematische Seite

            Hallo Thomas,

            • https://www.google.de/

            „Suche“ wird vorgelesen

            • https://duckduckgo.com/

            nichts wird vorgelesen

            • http://www.bing.com/

            „Suchbegriff eingeben“ wird vorgelesen

            • http://www.ebay.de/ (hier ist es zwar vorhanden wird aber versteckt)

            Ja, aus dem Viewport geschoben
            „Geben Sie Ihren Suchbegriff ein“ wird vorgelesen

            • http://www.amazon.de/

            nichts wird vorgelesen

            • https://www.youtube.com/

            „Suchen“ wird vorgelesen

            Bis demnächst
            Matthias

            --
            Dieses Forum nutzt Markdown. Im Wiki erhalten Sie Hilfe bei der Formatierung Ihrer Beiträge.
          4. problematische Seite

            Hej Thomas,

            Hallo,

            <label> gehört bereits mit ins Grundgerüst. Das Tutorial sollte gerade Anfängern nicht vermitteln, dass die Beschriftung nicht zwingend dazugehört.

            warum machen es dann die großen wie:

            • https://www.google.de/

            Ist in diesem Falle irrelevant. Für vieles haben "die großen" ihre Gründe, die aber nichts mit dem Aufbau eines einfachen validen und sinnvollen html-formulars in einem Anfänger-Tutorial zu tun haben.

            Unter Umständen soll es nur ein paar Byte sparen (multipliziert mit ein paar Milliarden seitenaufrufen im Monat). Kein gutes Argument für Zugänglichkeit...

            Man kann vieles. Aber Label funktioniert immer. Title ist übrigens keine gute Alternative, da es vielen screenreader-nutzern nicht vorgelesen wird. Lässt sich nämlich abschalten und ist IMHO in vielen screenreadern standardmäßig ausgeschaltet, seit es modern geworden ist, title für keyword stuffing zu missbrauchen.

            Marc

            1. problematische Seite

              Hallo,

              <label> gehört bereits mit ins Grundgerüst. Das Tutorial sollte gerade Anfängern nicht vermitteln, dass die Beschriftung nicht zwingend dazugehört.

              warum machen es dann die großen wie:

              • https://www.google.de/

              Ist in diesem Falle irrelevant. Für vieles haben "die großen" ihre Gründe, die aber nichts mit dem Aufbau eines einfachen validen und sinnvollen html-formulars in einem Anfänger-Tutorial zu tun haben.

              Unter Umständen soll es nur ein paar Byte sparen (multipliziert mit ein paar Milliarden seitenaufrufen im Monat). Kein gutes Argument für Zugänglichkeit...

              und die „Großen“ haben Mitarbeiter, die bei oder sogar vor jedem Browserupdate die Funktionalität überprüfen.

              Gruß
              Jürgen

        2. problematische Seite

          Lieber Gunnar,

          irgendwie war mir klar, dass Du Dich darauf wie auf ein gefundenes Fressen stürzen würdest.

          Du nennst völlig zurecht <label> zum Beschriften „unverzichtbar“.

          Ich hatte mir schon gedacht, dass dieses Adjektiv in der Überschrift Deinen Beifall finden würde.

          Aber was soll „Zwar wäre das Suchformular bereits technisch funktionstüchtig“? Was heißt „technisch funktionstüchtig“?

          Ich sehe keinen Sinn darin, Anfängern Lügen aufzutischen. Wenn die Elemente in einem Dokument in der dargestellten Art enthalten sind, ist das ein (vielleicht nicht für jedermann) nutzbares Konstrukt, das die beschriebene Funktionalität erfüllt. Wenn Du aber schaust, diskriminiere ich diese Lösung dadurch, dass ich kein live-Beispiel dafür anbiete.

          Was auch immer das heißen mag, es ist IMHO nichts von Relevanz. Ohne Beschriftung ist ein Formularfeld nicht funktionstüchtig.

          Da lügst Du. Das halte ich in einem Tutorial für unzumutbar. Bitte unterlasse solche Falschaussagen außerhalb Deines Elfenbeinturms!

          <label> gehört bereits mit ins Grundgerüst. Das Tutorial sollte gerade Anfängern nicht vermitteln, dass die Beschriftung nicht zwingend dazugehört.

          Nochmal für Dich zum mitschnitzen: Die von mir nicht empfohlenen Konstrukte werden auch nicht mit live-Beispielen versehen. Desweiteren mache ich bereits in der Überschrift mit dem von Dir tatsächlich wohlwollend wahrgenommenen Adjektiv "unverzichtbar" eindeutig klar, dass aus Sicht der Zugänglichkeit dieses Element eine wesentliche Bedeutung hat. Aber: Der Artikel erstellt Schritt für Schritt logisch auf Vorhandenem aufbauend eine für jedermann nutzbare Konstruktion. Dass Du eine andere Logik benutzt und dass Du Deine Schritte in anderer Reihenfolge gehst, liegt zum einen an der Tatsache, dass Du kein Anfänger bist, also an Deinem Vorwissen, welches Du auch nicht aus pädagogischen Gründen auszublenden in der Lage bist, und zum anderen daran, dass Du die inhaltliche Entwicklung des Artikels nicht würdigen willst. Aber diese Diskussion hatten wir bereits andernorts erschöpfend geführt.

          Liebe Grüße,

          Felix Riesterer.

          Folgende Beiträge verweisen auf diesen Beitrag:

          1. problematische Seite

            @@Felix Riesterer

            irgendwie war mir klar, dass Du Dich darauf wie auf ein gefundenes Fressen stürzen würdest.

            „Ich bin der Geist, der stets verneint!“

            ein (vielleicht nicht für jedermann) nutzbares Konstrukt

            Nicht für jedermann nutzbar heißt im Web: nicht nutzbar. “[The Web] is for everyone!” —Tim Berners-Lee

            “This is for everyone!” bei der Eröffnungsversanstaltung der Olympischen Spiele 2012

            Foto: Nick Webb (CC-BY-2.0)

            “When designing for The Web, your users could be anyone. Make fewer decisions about them so they can make more for themselves.”Heydon Pickering

            Ohne Beschriftung ist ein Formularfeld nicht funktionstüchtig.

            Da lügst Du.

            Ja nee is’ klar. Genauso wie Kerstin Probiesch [1], Cordelia McGee-Tubb [2], David Bolter [3], David Storey [4], Heydon Pickering [5] – alles Lügner.

            Und ganz besonders Marcy Sutton, die da sagt: “It hurts more than it helps to put inaccessible examples out there on the Web. Developers will find it and copy it—we need to set a better example.”

            Das halte ich in einem Tutorial für unzumutbar.

            Für unzumutbar halte ich Tutorials, die falsches Halbwissen vermitteln.

            Dabei bedarf es in diesem Fall nur kleinen Änderungen, um den Missstand auszumerzen: Beschriftung mit ins Grundgerüst.

            Bitte unterlasse solche Falschaussagen außerhalb Deines Elfenbeinturms!

            Andere der Lüge zu bezichtigen dürfte einer sachlichen Diskussion kaum dienlich sein. Wenn du eine solche willst, bist du es, der hier etwas zu unterlassen hat.

            Nochmal für Dich zum mitschnitzen: […] Der Artikel erstellt Schritt für Schritt logisch auf Vorhandenem aufbauend eine für jedermann nutzbare Konstruktion. Dass Du eine andere Logik benutzt und dass Du Deine Schritte in anderer Reihenfolge gehst

            Tu ich doch gar nicht. Für mich hört nur das Grundgerüst an einer späteren Stelle auf: nach der Beschriftung. Kein Grundgerüst ohne.

            Und Beschriftung heißt erst einmal label-Element, wenn du die Leser nicht gleich mit Außer-wenn und title- und aria-label-Attribut überfordern willst. Da sind wir uns vermutlich einig, dass das an späterer Stelle seinen Platz finden sollte.

            dass Du die inhaltliche Entwicklung des Artikels nicht würdigen willst.

            Du missverstehst. (Irgendwer sagte mal, dass man nichts mit Boshaftigkeit begründen sollte, was sich auch mit Dummheit begründen lässt.)

            Aber diese Diskussion hatten wir bereits andernorts erschöpfend geführt.

            Scheinbar nicht.

            Waren es schon elf Mal?

            “The 11 in a11y stands for the number of times you have to tell developers that accessibility is important.”Ian Devlin

            Ich werde gewiss nicht locker lassen. Denn das ist meine Aufgabe:

            “Arguing with teammates over ‘bothering with accessibility’ makes me so angry. Every. Time. So. Angry. Yes. ‘Bother’. It’s your job.” —Jen Simmons

            LLAP 🖖

            --
            “You might believe there are benefits for the developer, but first of all, you should put those behind the interest of the user.” —Stefan Tilkov
            Selfcode: sh:) fo:} ch:? rl:) br:> n4:& va:| de:> zu:} fl:{ ss:| ls:# js:|

            1. „Grundproblem ist, dass Barrierefreiheit über Jahre als das ‚ganz andere zusätzliche‘ aufgebaut wurde.“Kerstin Probiesch ↩︎

            2. “Accessibility is like a blueberry muffin— you can’t push the berries in there afterward.”Cordelia McGee-Tubb ↩︎

            3. “The best time to consider accessibility is at the beginning, the second best time is now.”David Bolter ↩︎

            4. “Accessibility is fundamentally a design problem, not a disability problem.”David Storey ↩︎

            5. “When I see inaccessible code, my first thought isn’t ‘stupid developer’; it’s ‘dysfunctional company design culture’.”Heydon Pickering ↩︎

            1. problematische Seite

              Hallo Gunnar Bittersmann,

              Ohne Beschriftung ist ein Formularfeld nicht funktionstüchtig.

              Da lügst Du.

              Ja nee is’ klar. Genauso wie Kerstin Probiesch: „Grundproblem ist, dass Barrierefreiheit über Jahre als das ‚ganz andere zusätzliche‘ aufgebaut wurde.“

              Aber diese Diskussion hatten wir bereits andernorts erschöpfend geführt.

              Scheinbar nicht.

              Waren es schon elf Mal?

              “The 11 in a11y stands for the number of times you have to tell developers that accessibility is important.”Ian Devlin

              Im Gegensatz[1] zu den anderen elf Malen (Schnick-Schnack-Schnuck, äh Tic-Tac-Tuc) sehe ich es hier genau so wie du. Jedes Formular sollte eine Beschriftung haben.

              Bis demnächst
              Matthias

              --
              Wenn eine Idee nicht zuerst absurd erscheint, taugt sie nichts. (Albert Einstein)

              1. Gegensatz trifft es nicht ganz. ↩︎

              1. problematische Seite

                Lieber Matthias,

                Im Gegensatz zu den anderen elf Malen (Schnick-Schnack-Schnuck, äh Tic-Tac-Tuc) sehe ich es hier genau so wie du. Jedes Formular sollte eine Beschriftung haben.

                das Formular? Also das <form> selbst? Welche Beschriftung möchtest Du ihm denn geben? Zeige mir doch den dazu passenden Code-Ausschnitt, damit ich verstehe, was Du meinst!

                Liebe Grüße,

                Felix Riesterer.

                1. problematische Seite

                  Hallo Felix Riesterer,

                  Jedes Formular sollte eine Beschriftung haben.

                  das Formular? Also das <form> selbst?

                  Nein, ergänze „feld“ ;-)

                  Aus pädagogischer Sicht spricht nichts dagegen, bereits im ersten Beispiel, unmittelbar unter Eingabemöglichkeiten zu notieren:

                  <form action="https://google.de/search">
                    <label>Suchbegriff <input name="q"></label>
                  </form>
                  

                  und ebenso bei der Sache mit den Buttons:

                  <form action="https://google.de/search">
                    <label>Suchbegriff <input name="q"></label>
                    <button>finden</button>
                  </form>
                  

                  Und ganz bewusst würde ich die Reihenfolge bei der Erläuterung (name, button, label) so lassen, wie sie ist.

                  Dann könnte der Abschnitt zum Label ergänzt werden durch:

                  Wenn Sie aus gestalterischen Gründen die Beschriftung entfernen wollen, achten Sie darauf, dass Sie das auf eine Weise tun, die Nutzer assistiver Technologien nicht benachteiligt.

                  <form action="https://google.de/search">
                    <p>
                      <label for="q">Suchbegriff</label>
                      <input id="q" name="q">
                      <button>finden</button>
                    </p>
                  </form>
                  
                  label[for=q] {
                    font: 0/0 sans-serif;
                  }
                  

                  Damit legt man quasi nebenbei den Fokus auf das unverzichtbare Label.

                  Was hältst du davon?

                  Bis demnächst
                  Matthias

                  --
                  Wenn eine Idee nicht zuerst absurd erscheint, taugt sie nichts. (Albert Einstein)
                  1. problematische Seite

                    Lieber Matthias,

                    Aus pädagogischer Sicht spricht nichts dagegen, bereits im ersten Beispiel, unmittelbar unter Eingabemöglichkeiten zu notieren:

                    <form action="https://google.de/search">
                      <label>Suchbegriff <input name="q"></label>
                    </form>
                    

                    von mir aus gerne. Mein Ansatz war der, die technische Funktionalität in ihre Einzelheiten zerlegt zum Verständnis zu zeigen (aber aus Rücksicht auf best practices mit Zugänglichkeitsfokus) nicht zu demonstrieren. Es ist aus technischer Sicht nämlich tatsächlich möglich, ein Formular ohne jegliche Beschriftung oder Buttons mit nur einem einzigen Textfeld erfolgreich abzusenden!

                    Was wäre denn so schlimm daran, den "zusätzlichen Layer" mit Beschriftungen oder WAI-ARIA als das zu sehen, was er ist, nämlich eine zusätzliche Schicht an technischen Details, die eine Zugänglichkeit für alle User sicherstellt? Dass es eine zusätzliche Schicht ist, leugnen nur diejenigen, die in missionarischer Weise versteift argumentieren. Was nicht heißen soll, dass es keinen Grund für diesen missionarischen Eifer gäbe - ganz im Gegenteil.

                    und ebenso bei der Sache mit den Buttons:

                    <form action="https://google.de/search">
                      <label>Suchbegriff <input name="q"></label>
                      <button>finden</button>
                    </form>
                    

                    Wo hast Du den Button jetzt anders beschriftet als ich?

                    Und ganz bewusst würde ich die Reihenfolge bei der Erläuterung (name, button, label) so lassen, wie sie ist.

                    Warum? Was ist der Hintergedanke zu "ganz bewusst"?

                    Dann könnte der Abschnitt zum Label ergänzt werden durch:

                    Wenn Sie aus gestalterischen Gründen die Beschriftung entfernen wollen, achten Sie darauf, dass Sie das auf eine Weise tun, die Nutzer assistiver Technologien nicht benachteiligt.

                    Den füge ich sofort hinzu. Moment... done.

                    Was hältst du davon?

                    Sowie der missionarische Eifer die Sichtweite nicht einschränkt, kann man mit mir durchaus argumentieren und Einsichten verfeinern.

                    Liebe Grüße,

                    Felix Riesterer.

                    Folgende Beiträge verweisen auf diesen Beitrag:

                    1. problematische Seite

                      Hallo Felix Riesterer,

                      und ebenso bei der Sache mit den Buttons:

                      <form action="https://google.de/search">
                        <label>Suchbegriff <input name="q"></label>
                        <button>finden</button>
                      </form>
                      

                      Wo hast Du den Button jetzt anders beschriftet als ich?

                      Gar nicht. Auch dort ist nur das label-Element hinzugekommen.

                      Und ganz bewusst würde ich die Reihenfolge bei der Erläuterung (name, button, label) so lassen, wie sie ist.

                      Warum? Was ist der Hintergedanke zu "ganz bewusst"?

                      Deine Herangehensweise ist ja auch durchdacht. name ist wichtig für die Technik, button und label für die Zugänglichkeit.

                      Sowie der missionarische Eifer die Sichtweite nicht einschränkt, kann man mit mir durchaus argumentieren und Einsichten verfeinern.

                      :)

                      Bis demnächst
                      Matthias

                      --
                      Dieses Forum nutzt Markdown. Im Wiki erhalten Sie Hilfe bei der Formatierung Ihrer Beiträge.
                    2. problematische Seite

                      @@Felix Riesterer

                      Was wäre denn so schlimm daran, den "zusätzlichen Layer" mit Beschriftungen oder WAI-ARIA als das zu sehen, was er ist, nämlich eine zusätzliche Schicht an technischen Details, die eine Zugänglichkeit für alle User sicherstellt?

                      Wenn du unter „zusätzlichem Layer“ einfach nur einen anderen Layer verstehst: nichts.

                      Wenn du darunter einen optionalen Layer verstehst: alles.

                      Sowie der missionarische Eifer die Sichtweite nicht einschränkt, kann man mit mir durchaus argumentieren und Einsichten verfeinern.

                      Oder andersrum: Wenn du Argumenten aufgeschlossen wärst, müsste man nicht immer noch missionieren. >;-)

                      LLAP 🖖

                      --
                      “You might believe there are benefits for the developer, but first of all, you should put those behind the interest of the user.” —Stefan Tilkov
                      Selfcode: sh:) fo:} ch:? rl:) br:> n4:& va:| de:> zu:} fl:{ ss:| ls:# js:|
                      1. problematische Seite

                        Lieber Gunnar,

                        Wenn du unter „zusätzlichem Layer“ einfach nur einen anderen Layer verstehst: nichts.

                        Wenn du darunter einen optionalen Layer verstehst: alles.

                        wo habe ich jemals die Notwendigkeit dieses anderen Layers in Zweifel gezogen? Gerade diese Notwendigkeit stand in diesem Thread zu keiner Zeit zur Debatte, da wir uns darüber von Anfang an einig waren!

                        Oder andersrum: Wenn du Argumenten aufgeschlossen wärst, müsste man nicht immer noch missionieren. >;-)

                        Du verdrehst aus missionarischem Eifer die ursprüngliche Bedeutung von Wörtern. Damit verärgerst Du Dein prinzipiell Deinen Argumenten aufgeschlossenes Gegenüber bis zu dem Grad, an dem es Deine Beiträge nicht mehr ernst nehmen kann und will. Deshalb werfe ich Dir wiederholt vor, dass Du Dich in Deiner Art der Diskussionsführung (zumindest mir gegenüber, das aber in enormem Maße) regelmäßig unglaubwürdig machst und Dein eigentliches argumentatorisches Ziel verfehlst. In Deiner Twitterblase magst Du Dich da gerne dieser Kommunikationsweise bedienen, da seid ihr unter euch. Wenn Du Dich aber mit nicht-Twitterern auseinandersetzt, die diese Kommunikationskultur meiden, wirst Du auch in Zukunft immer wieder anecken, da Du einen inkompatiblen Sprachgebrauch pflegst - und das bei gleicher Muttersprache!

                        Ich habe meinen Standpunkt in diesem Forum hochgradig redundant dargelegt. Ebenso redundant hast Du Deine Weigerung zur Anerkennung desselben deutlich gemacht. Dessen bin ich nun müde und werde diesen Teil der Diskussion nicht mehr weiter führen.

                        Liebe Grüße,

                        Felix Riesterer.

                        1. problematische Seite

                          @@Felix Riesterer

                          Du verdrehst aus missionarischem Eifer die ursprüngliche Bedeutung von Wörtern.

                          Du meinst in dem Fall die Bedeutung des Wortes „funktionstüchtig“?

                          Etwas, was von Menschen nicht richtig bedient werden kann, erfüllt seine Funktion nicht. Wenn du einem unbenutzbaren Ding bescheinigst, „technisch funktionstüchtig“ zu sein, bist du es, der die Bedeutung des Wortes „funktionstüchtig“ verdreht.

                          LLAP 🖖

                          --
                          “You might believe there are benefits for the developer, but first of all, you should put those behind the interest of the user.” —Stefan Tilkov
                          Selfcode: sh:) fo:} ch:? rl:) br:> n4:& va:| de:> zu:} fl:{ ss:| ls:# js:|
                          1. problematische Seite

                            Hallo,

                            Du verdrehst aus missionarischem Eifer die ursprüngliche Bedeutung von Wörtern.

                            Du meinst in dem Fall die Bedeutung des Wortes „funktionstüchtig“?

                            nö.

                            Wenn du einem unbenutzbaren Ding bescheinigst, „technisch funktionstüchtig“ zu sein,

                            ja, um die Kombination zweier Worte geht es. Es geht nicht um Interaktion mit Menschen, wenn man etwas als "technisch funktionstüchtig" bezeichnet, es geht um die Technik "dahinter".

                            Du hast recht, ein Formular ohne Beschriftung ist weder empfehlenswert noch bedienbar. Aber Soft- und Hardware können damit etwas anfangen, wenn es ansonsten komplett ist. Das ist mit "technisch funktionstüchtig" gemeint und mit dieser Formulierung wird auch angedeutet, dass das Formular eben noch nicht komplett ist.

                            Gruß
                            Kalk

                            1. problematische Seite

                              Hallo Tabellenkalk,

                              Du hast recht, ein Formular ohne Beschriftung ist weder empfehlenswert noch bedienbar. Aber Soft- und Hardware können damit etwas anfangen, wenn es ansonsten komplett ist.

                              Nein. Können sie nicht. Was sollte ein Screenreader vorlesen oder eine Braille-Zeile transkribieren?

                              LG,
                              CK

                              1. problematische Seite

                                Hallo,

                                Nein. Können sie nicht. Was sollte ein Screenreader vorlesen oder eine Braille-Zeile transkribieren?

                                Einen Standard halt, so wie das nackte Eingabefeld im normalen Browser. "Input" oder "Eingabe" etwa. Das ist der Unterschied zwischen "bedienbar" und "technisch funktionstüchtig".

                                Gruß
                                Kalk

                                1. problematische Seite

                                  Hallo Tabellenkalk,

                                  Nein. Können sie nicht. Was sollte ein Screenreader vorlesen oder eine Braille-Zeile transkribieren?

                                  Einen Standard halt, so wie das nackte Eingabefeld im normalen Browser. "Input" oder "Eingabe" etwa. Das ist der Unterschied zwischen "bedienbar" und "technisch funktionstüchtig".

                                  Da werden wir nicht auf einen grünen Zweig kommen. Das sehe ich grundsätzlich und vollständig anders und deine Argumentation bleibt mir verschlossen.

                                  LG,
                                  CK

                                  1. problematische Seite

                                    Hallo,

                                    deine Argumentation bleibt mir verschlossen.

                                    Ein Browser kann ein Rechteck darstellen (Warum eigentlich rechteckig und nicht trapezförmig? Standard halt.) Ein Unwissender kann damit nix anfangen und daher nicht bedienen. Jemand mit entsprechender Information kann einen Wert eintragen und abschicken. Formular ist technisch funktionstüchtig.

                                    Ein Screenreader/eine Braillezeile könnte "Input!" auffordern und schon haben wir dasselbe in grün.

                                    Ich kann nicht nachvollziehen, warum etwas, das offensichtlich technisch funktionstüchtig ist, als „nicht funktionstüchtig“ bezeichnet werden soll.

                                    Gruß
                                    Kalk

                                    1. problematische Seite

                                      Hallo Tabellenkalk,

                                      Ich kann nicht nachvollziehen, warum etwas, das offensichtlich technisch funktionstüchtig ist, als „nicht funktionstüchtig“ bezeichnet werden soll.

                                      Und ich kann nicht nachvollziehen, warum etwas, was technisch offensichtlich nicht funktionstüchtig ist, als funktionstüchtig bezeichnet werden soll.

                                      Ich kann auch nicht nachvollziehen, warum man etwas, das nicht bedienbar ist, als „technisch funktionstüchtig“ bezeichnen möchte, das ist für mich völlig abwegig und wirklich fern jeglicher Erfahrung und Praxis. Ein User, der eine Seite nicht bedienen kann, wird ja auch nicht sagen „die Seite ist nicht bedienbar aber technisch funktionstüchtig“ sondern er wird sagen „die Seite ist kaputt.“ Und er hat ja auch recht damit.

                                      Und das, mein lieber Felix, hat überhaupt nichts mit Religion zu tun.

                                      Aber seis drum, mir ist meine Zeit zu schade für solche Diskussionen. Ich werde das nächste mal einfach nichts dazu sagen, man wird ja eh nur diffamiert und in Endlos-Diskussionen hinein gezogen.

                                      LG,
                                      CK

                                      1. problematische Seite

                                        @@Christian Kruse

                                        Aber seis drum, mir ist meine Zeit zu schade für solche Diskussionen. Ich werde das nächste mal einfach nichts dazu sagen …

                                        Hey, “Yes. ‘Bother.’ It’s your job.”

                                        Aber ich kann dich verstehen. Ich hab auch gerade Besseres zu tun. Bin auf Klassenfahrt, sitze neben PPK und lausche Jeremy Keith.

                                        LLAP 🖖

                                        --
                                        “You might believe there are benefits for the developer, but first of all, you should put those behind the interest of the user.” —Stefan Tilkov
                                        Selfcode: sh:) fo:} ch:? rl:) br:> n4:& va:| de:> zu:} fl:{ ss:| ls:# js:|
                                        1. problematische Seite

                                          Hallo Gunnar,

                                          Aber seis drum, mir ist meine Zeit zu schade für solche Diskussionen. Ich werde das nächste mal einfach nichts dazu sagen …

                                          Hey, “Yes. ‘Bother.’ It’s your job.”

                                          Nö? Mein Job ist Software-Entwicklung. SELFHTML ist Freizeit.

                                          Aber ich kann dich verstehen. Ich hab auch gerade Besseres zu tun. Bin auf Klassenfahrt, sitze neben PPK und lausche Jeremy Keith.

                                          Grüß mir die Bagage mal!

                                          LG,
                                          CK

                                          1. problematische Seite

                                            @@Christian Kruse

                                            Grüß mir die Bagage mal!

                                            Du meinst die Bagage, die den SELFHTML-Raum verlassen haben oder ihn nie betreten haben? (Aus Gründen.)

                                            Aufgabe für @Felix Riesterer: Versuch mal zu ergründen, warum.

                                            LLAP 🖖

                                            --
                                            “You might believe there are benefits for the developer, but first of all, you should put those behind the interest of the user.” —Stefan Tilkov
                                            Selfcode: sh:) fo:} ch:? rl:) br:> n4:& va:| de:> zu:} fl:{ ss:| ls:# js:|
                                            1. problematische Seite

                                              Hallo Gunnar Bittersmann,

                                              Aufgabe für @Felix Riesterer: Versuch mal zu ergründen, warum.

                                              Öl? Und Feuer? Und so? 😞

                                              Bis demnächst
                                              Matthias

                                              --
                                              Dieses Forum nutzt Markdown. Im Wiki erhalten Sie Hilfe bei der Formatierung Ihrer Beiträge.
                                        2. problematische Seite

                                          @@Gunnar Bittersmann

                                          … Bin auf Klassenfahrt, sitze neben PPK und lausche Jeremy Keith.

                                          Und was sagte der so?

                                          Jeremy Keith auf der beyond tellerrand Düsseldorf 2016

                                          1. Erkenne die Kernfunktionalität.

                                          2. Setze diese Funktionalität mit der einfachsten Technologie um. (Und das ist i.a.R. HTML – ohne irgendwelches JavaScript.)

                                          3. Verbessere! Erweitere!

                                          Und warum fällt mir da jetzt wieder das unrühmliche Tic-Tac-Toe-Beispiel ein?

                                          “When I say ‘this is an enhancement’, don’t think I’m saying ‘this is just an enhancement’.” —Jeremy Keith

                                          “There’s a lot of features on the Boston Globe that require JavaScript, but reading the news is not one of them.” —Mat Marquis

                                          In anderen Worten: Es gibt viele Dinge bei diesem Tic-Tac-Toe, die JavaScript verlangen; aber Kreuze und Kreise ins Spielfeld einzutragen gehört nicht dazu.

                                          “If I have the choice to make it the users problem or to make it my problem, I make it my problem. That’s why it’s called ‘work’.” —Jeremy Keith

                                          LLAP 🖖

                                          --
                                          “You might believe there are benefits for the developer, but first of all, you should put those behind the interest of the user.” —Stefan Tilkov
                                          Selfcode: sh:) fo:} ch:? rl:) br:> n4:& va:| de:> zu:} fl:{ ss:| ls:# js:|
                                          1. problematische Seite

                                            Lieber Gunnar,

                                            1. Erkenne die Kernfunktionalität.

                                            welche wäre das bei einem PKW?

                                            1. Setze diese Funktionalität mit der einfachsten Technologie um.

                                            Also bei einem PKW...?

                                            1. Verbessere! Erweitere!

                                            Klar, bei einem PKW kann man alles erweitern.

                                            Und warum fällt mir da jetzt wieder das unrühmliche Tic-Tac-Toe-Beispiel ein?

                                            Weil blinde Menschen keinen PKW steuern können. Ein PKW ist nicht funktionstüchtig, weil er Benutzergruppen ausschließt.

                                            SCNR

                                            Liebe Grüße,

                                            Felix Riesterer.

                                            1. problematische Seite

                                              Hallo,

                                              Weil blinde Menschen keinen PKW steuern können. Ein PKW ist nicht funktionstüchtig, weil er Benutzergruppen ausschließt.

                                              SCNR

                                              Flugzeug. Ich weiß nicht warum, aber als nachvollziehbares Beispiel musst du für Gunnar ein Flugzeug wählen.

                                              Gruß
                                              Kalk

                                            2. problematische Seite

                                              Hallo,

                                              Und warum fällt mir da jetzt wieder das unrühmliche Tic-Tac-Toe-Beispiel ein?

                                              Weil blinde Menschen keinen PKW steuern können.

                                              wer sagt denn sowas? Das ist ja Diskriminierung!

                                              Hast du noch nie gesehen, wie Al Pacino als blinder Kriegsveteran in "Der Duft der Frauen" mit einem Ferrari durch die Stadt rast und einen Riesenspaß dabei hat?

                                              "Da muss doch irgendwo noch'n Gang sein!"

                                              So long,
                                               Martin

                                              --
                                              Logik ist die Theorie, Chaos die Praxis.
                                              1. problematische Seite

                                                @@Der Martin

                                                Hast du noch nie gesehen, wie Al Pacino als blinder Kriegsveteran in "Der Duft der Frauen" mit einem Ferrari durch die Stadt rast und einen Riesenspaß dabei hat?

                                                Oder wie Richard Pryor als blinder Zeuge in „See No Evil, Hear No Evil“ zwangsweise am Lenkrad sitzt?

                                                LLAP 🖖

                                                --
                                                “You might believe there are benefits for the developer, but first of all, you should put those behind the interest of the user.” —Stefan Tilkov
                                                Selfcode: sh:) fo:} ch:? rl:) br:> n4:& va:| de:> zu:} fl:{ ss:| ls:# js:|
                                      2. problematische Seite

                                        Hej Christian,

                                        Ich kann nicht nachvollziehen, warum etwas, das offensichtlich technisch funktionstüchtig ist, als „nicht funktionstüchtig“ bezeichnet werden soll.

                                        Ich kann auch nicht nachvollziehen, warum man etwas, das nicht bedienbar ist, als „technisch funktionstüchtig“ bezeichnen möchte,

                                        Gerade um solch feine Unterscheidungen deutlich machen zu können, hat die herrliche deutsche Sprache dafür zwei unterschiedliche Wörter. - Und das sind in diesem Falle keineswegs Synonyme. ;-)

                                        Ich bin nun wirklich ein Freund von usabiliy und Accessibility - aber auch ein Linguist und Dozent. Darum will und muss ich auch den Unterschied zwischen einem Formular, dass unter bestimmten Vorausetzungen abgeschickt werden kann und einem das allen zugänglich ist deutlich machen.

                                        Und genau das ist der Unterschied zwischen "funktioniert" (irgendwie für irgendwen - was leider auf die meisten Webseiten zutrifft) und "accessible" nach einem Standard wie der wcag.

                                        Jedem der sich mit den Grundlagen von Accessibility beschäftigt sollte übrigens klar sein, dass es zugänglich für alle nicht gibt. Wir nähern uns nur immer weiter an...

                                        Marc

                                        1. problematische Seite

                                          Servus!

                                          Hej Christian,

                                          Ich kann nicht nachvollziehen, warum etwas, das offensichtlich technisch funktionstüchtig ist, als „nicht funktionstüchtig“ bezeichnet werden soll.

                                          Ich kann auch nicht nachvollziehen, warum man etwas, das nicht bedienbar ist, als „technisch funktionstüchtig“ bezeichnen möchte,

                                          Ich bin nun wirklich ein Freund von usabiliy und Accessibility - aber auch ein Linguist und Dozent. Darum will und muss ich auch den Unterschied zwischen einem Formular, dass unter bestimmten Vorausetzungen abgeschickt werden kann und einem das allen zugänglich ist deutlich machen.

                                          Und genau das ist der Unterschied zwischen "funktioniert" (irgendwie für irgendwen - was leider auf die meisten Webseiten zutrifft) und "accessible" nach einem Standard wie der wcag.

                                          Genau so habe ich das auch verstanden. Felix Einschränkung war ja im gleichen Satz schon da.

                                          Das Beispiel vom Flugzeug ohne Motor lebt ja auch davon, dass der Segelflug zwar funktioniert, es aber trotzdem nicht der erstrebenswerte Zustand ist.

                                          Herzliche Grüße

                                          Matthias Scharwies

                                          --
                                          Es gibt viel zu tun - packen wir's an: ToDo-Liste gewünschte Seiten
                                        2. Lieber marctrix,

                                          Deine Worte sind Balsam für mich.

                                          Ich bin nun wirklich ein Freund von usabiliy und Accessibility - aber auch ein Linguist und Dozent. Darum will und muss ich auch den Unterschied zwischen einem Formular, dass unter bestimmten Vorausetzungen abgeschickt werden kann und einem das allen zugänglich ist deutlich machen.

                                          Also lag ich mit meinem Vorwurf der Sprachverbiegung aus missionarischem Eifer nicht falsch. Indirekt ist das jetzt aus berufenem Munde bestätigt worden. Dafür vielen Dank!

                                          Liebe Grüße,

                                          Felix Riesterer.

                                          1. Hej Felix,

                                            Lieber marctrix,

                                            Deine Worte sind Balsam für mich.

                                            ;-)

                                            Ich bin nun wirklich ein Freund von usabiliy und Accessibility - aber auch ein Linguist und Dozent. Darum will und muss ich auch den Unterschied zwischen einem Formular, dass unter bestimmten Vorausetzungen abgeschickt werden kann und einem das allen zugänglich ist deutlich machen.

                                            Also lag ich mit meinem Vorwurf der Sprachverbiegung aus missionarischem Eifer nicht falsch. Indirekt ist das jetzt aus berufenem Munde bestätigt worden. Dafür vielen Dank!

                                            Grundsätzlich halte ich nichts von Vorwürfen, Schuldzuweisungen und usw, weil diese nie zielführend sind.

                                            Ich kann auch Gunnar verstehen, in seiner Idee. Aber es ist auch unfair einen Artikel danach zu bewerten, was ausdrücklich nicht als Kopiervorlage gedacht ist...

                                            Marc

                                            1. @@marctrix

                                              Aber es ist auch unfair einen Artikel danach zu bewerten, was ausdrücklich nicht als Kopiervorlage gedacht ist...

                                              Ich hab nicht den Artikel als ganzen bewertet, sondern eine Verbesserung in einem Detail aufgezeigt.

                                              Ich bin auch nicht der Ansicht, dass Felix das Beispiel ohne Beschriftung als Kopiervorlage gedacht hat. Der Punkt ist, dass Leser sich nicht um Felix‘ Gedanken scheren und das trotzdem als Kopiervorlage verwenden.

                                              Also besser erst gar keine falschen (unvollständigen) Beispiele geben.

                                              Oder sie deutlichlich als solche kennzeichnen: Hinweis in fetter Schrift, roter Hintergrund, rechte Maustaste sperren[1], …

                                              LLAP 🖖

                                              --
                                              “You might believe there are benefits for the developer, but first of all, you should put those behind the interest of the user.” —Stefan Tilkov
                                              Selfcode: sh:) fo:} ch:? rl:) br:> n4:& va:| de:> zu:} fl:{ ss:| ls:# js:|

                                              1. ;-) ↩︎

                            2. problematische Seite

                              @@Tabellenkalk

                              Wenn du einem unbenutzbaren Ding bescheinigst, „technisch funktionstüchtig“ zu sein,

                              ja, um die Kombination zweier Worte geht es. Es geht nicht um Interaktion mit Menschen, wenn man etwas als "technisch funktionstüchtig" bezeichnet, es geht um die Technik "dahinter".

                              „Liebe Fluggäste, hier spricht Ihr Kapitän. Ich habe zwei Nachrichten für Sie. Die gute: Die Ruder funktionieren. Die schlechte: Mir ist der Steuerknüppel abgebrochen.“

                              Du würdest das Flugzeug als nicht bedienbar, aber als „technisch funktionstüchtig“ bezeichnen?

                              Ich nicht. Es ist nicht funktionstüchtig.

                              Die Unterscheidung zwischen „funktionstüchtig“ und „technisch funktionstüchtig“ ergibt keinen Sinn.

                              LLAP 🖖

                              --
                              “You might believe there are benefits for the developer, but first of all, you should put those behind the interest of the user.” —Stefan Tilkov
                              Selfcode: sh:) fo:} ch:? rl:) br:> n4:& va:| de:> zu:} fl:{ ss:| ls:# js:|
                              1. problematische Seite

                                Hallo,

                                Du würdest das Flugzeug als nicht bedienbar, aber als „technisch funktionstüchtig“ bezeichnen?

                                ja, wenn er noch an die Seilzüge rankäme und sie per Hand betätigen könnte oder den Stumpf vom Steuerknüppel noch mit einer Zange kontrollieren könnte.

                                "Technisch funktionstüchtig" beinhaltet keinerlei menschliche Aktivität.

                                Gruß
                                Kalk

                              2. problematische Seite

                                Hallo,

                                Fluggäste, Kapitän, Flugzeug

                                Deine Argumentation krankt daran, dass du etwas sehr Komplexes im Betrieb kaputt gehen lässt, es also bereits funktioniert hat. Es ist so komplex, dass es eigentlich einen Kapitän zur Bedienung benötigt. Jetzt hat dieser Kapitän als noch alles ok war, die Passagiere eingeladen, auch mal zu steuern. Mit seiner Beschriftung, äh Anleitung, völlig easy. Leider bricht nun der vierte Passagier, nennen wir ihn Günni, den Steuerknüppel ab und behauptet, das Flugzeug kann gar nicht fliegen. Jetzt schickt der Kapitän alle Passagiere wieder auf ihre Plätze, öffnet die Wartungsdeckel und steuert das Flugzeug händisch mit den Steuerungsseilen heil nach hause.

                                Gruß
                                Kalk

                              3. problematische Seite

                                Hej Gunnar,

                                @@Tabellenkalk

                                Wenn du einem unbenutzbaren Ding bescheinigst, „technisch funktionstüchtig“ zu sein,

                                ja, um die Kombination zweier Worte geht es. Es geht nicht um Interaktion mit Menschen, wenn man etwas als "technisch funktionstüchtig" bezeichnet, es geht um die Technik "dahinter".

                                „Liebe Fluggäste, hier spricht Ihr Kapitän. Ich habe zwei Nachrichten für Sie. Die gute: Die Ruder funktionieren. Die schlechte: Mir ist der Steuerknüppel abgebrochen.“

                                Du würdest das Flugzeug als nicht bedienbar, aber als „technisch funktionstüchtig“ bezeichnen?

                                Mit Sicherheit würde er das nicht. Diese Implikation ist beleidigend und unnötig.

                                Die Unterscheidung zwischen „funktionstüchtig“ und „technisch funktionstüchtig“ ergibt keinen Sinn.

                                Aber die zwischen funktionstüchtig und bedienbar ist sehr wichtig und es ist sinnvoll sie klar zu machen!

                                Marc

                                1. problematische Seite

                                  @@marctrix

                                  ja, um die Kombination zweier Worte geht es. Es geht nicht um Interaktion mit Menschen, wenn man etwas als "technisch funktionstüchtig" bezeichnet, es geht um die Technik "dahinter".

                                  Du würdest das Flugzeug als nicht bedienbar, aber als „technisch funktionstüchtig“ bezeichnen?

                                  Mit Sicherheit würde er das nicht.

                                  Mit Sicherheit würde er das, da es ja „um die Technik ‚dahinter‘ [geht]“ und „nicht um Interaktion mit Menschen“.

                                  Diese Implikation ist beleidigend und unnötig.

                                  Man braucht nicht so viel Phantasie, um dem Vergleich mit dem Flugzeug mehr als Hinken abzugewinnen. Aber man braucht wohl sehr viel Phantasie, um da irgendeine Beleidigung erkennen zu wollen.

                                  Aber die [Unterscheidung] zwischen funktionstüchtig und bedienbar ist sehr wichtig und es ist sinnvoll sie klar zu machen!

                                  Klar.

                                  Und es ist sinnvoll klarzumachen, dass das Eine ohne das Andere genausowenig nutzbar ist wie das Andere ohne das Eine.

                                  LLAP 🖖

                                  --
                                  “You might believe there are benefits for the developer, but first of all, you should put those behind the interest of the user.” —Stefan Tilkov
                                  Selfcode: sh:) fo:} ch:? rl:) br:> n4:& va:| de:> zu:} fl:{ ss:| ls:# js:|
                                  1. problematische Seite

                                    Hej Gunnar,

                                    @@marctrix

                                    Diese Implikation ist beleidigend und unnötig.

                                    Man braucht nicht so viel Phantasie, um dem Vergleich mit dem Flugzeug mehr als Hinken abzugewinnen. Aber man braucht wohl sehr viel Phantasie, um da irgendeine Beleidigung erkennen zu wollen.

                                    Bei mir jedenfalls ist das so angekommen - Deine Postings sind fast ausnahmslos provokant. Da steckt immer schon die Bereitschaft zur Verletzung drin.

                                    Vergleiche hinken immer. Darum lässt man sie bleiben.

                                    Aber die [Unterscheidung] zwischen funktionstüchtig und bedienbar ist sehr wichtig und es ist sinnvoll sie klar zu machen!

                                    Klar.

                                    Klar. Dein einziger Beitrag während der stundenlangen Diskussion, in dem du die Unterscheidung machst und die Worte so verwendest, wie wir alle. Bisschen dürftig.

                                    Und es ist sinnvoll klarzumachen, dass das Eine ohne das Andere genausowenig nutzbar ist wie das Andere ohne das Eine.

                                    Na endlich. War das so schwer? ;-)

                                    Um nichts anderes ging es Felix doch. Er hat von Anfang an die Unterscheidung zwischen nutzbar und von einem Menschen oder Automaten abschickbar (aber nciht sinnvoll befüllbar) gemacht. Auch hat er von Anfang an bestätigt, dass ein unbeschriftetes Formular natürlich nicht sinnvoll ist, weil es nicht nutzbar ist.

                                    Auch hat er Deinem Vorschlag zugestimmt, ein solches Formular nicht als Kopiervorlage bereit zu stellen.

                                    Es ging nur darum, ob wir die Worte "nutzbar" und "funktionstüchtig" im Wiki so verwenden, wie es im deutschen Sprachgebrauch und in Fachkreisen üblich ist (um verstanden zu werden) - oder ob wir sie so verwenden, wie du es gern hättest. Du hast darauf beharrt, dass die Worte Synonyme sind. Das ist schlicht falsch (Felix hat das ebenfalls beleidigende Wort "gelogen" verwendet, weil er dir unterstellte, dass du den Unterschied durchaus kennst und absichtlich eine falsche Behauptung aufstellst).

                                    Marc

                                    1. problematische Seite

                                      @@marctrix

                                      Deine Postings sind fast ausnahmslos provokant.

                                      Das ist Absicht. Und das ist auch gut so.

                                      Da steckt immer schon die Bereitschaft zur Verletzung drin.

                                      Nein. Meine Postings sind vielleicht fachlich provokant, das sollte niemand persönlich nehmen.

                                      Vergleiche hinken immer. Darum lässt man sie bleiben.

                                      Vergleiche verdeutlichen. Darum stellt man sie an.

                                      Klar. Dein einziger Beitrag während der stundenlangen Diskussion, in dem du die Unterscheidung machst und die Worte so verwendest, wie wir alle.

                                      Von „wie wir alle“ kann keine Rede sein. CK versteht unter „funktionstüchtig“ dasselbe wie ich.

                                      Aber von mir aus nennen wir das eben „nutzbar“.

                                      Ein Formular, dass „technisch funktionstüchtig“, aber nicht nutzbar ist, ist wertlos.

                                      Auch hat er von Anfang an bestätigt, dass ein unbeschriftetes Formular natürlich nicht sinnvoll ist, weil es nicht nutzbar ist.

                                      Da hab ich nichts dagegen gesagt, sondern zugestimmt.

                                      Es ging nur darum, ob wir die Worte "nutzbar" und "funktionstüchtig" im Wiki so verwenden, wie es im deutschen Sprachgebrauch und in Fachkreisen üblich ist (um verstanden zu werden)

                                      Es ging ursprünglich darum, dass die nicht nutzbare Variante nicht als „Grundgerüst“ bezeichnet werden sollte. Ein Grundgerüst sollte bereits nutzbar sein. Eben weil Grundgerüste von anderen kopiert und so verwendet werden.

                                      LLAP 🖖

                                      --
                                      “You might believe there are benefits for the developer, but first of all, you should put those behind the interest of the user.” —Stefan Tilkov
                                      Selfcode: sh:) fo:} ch:? rl:) br:> n4:& va:| de:> zu:} fl:{ ss:| ls:# js:|
                                      1. problematische Seite

                                        Hej Gunnar,

                                        @@marctrix

                                        Deine Postings sind fast ausnahmslos provokant.

                                        Das ist Absicht.

                                        Das weiß ich.

                                        Und das ist auch gut so.

                                        Bittere Pillen lassen sich schlechter schlucken, als ein bittere Tropfen auf einem Stück Zucker ;-)

                                        Da steckt immer schon die Bereitschaft zur Verletzung drin.

                                        Nein. Meine Postings sind vielleicht fachlich provokant, das sollte niemand persönlich nehmen.

                                        Das hast du nicht in der Hand. ;-)

                                        Aber trotz dieser kleinen Sticheleien: zu allem anderen meine volle Zustimmung!

                                        Marc

                                        1. problematische Seite

                                          @@marctrix

                                          Bittere Pillen lassen sich schlechter schlucken, als ein bittere Tropfen auf einem Stück Zucker ;-)

                                          Es hat schon seinen Grund, warum Insulin nicht auf Zucker geträufelt eingenommen wird. ;-)

                                          LLAP 🖖

                                          --
                                          “You might believe there are benefits for the developer, but first of all, you should put those behind the interest of the user.” —Stefan Tilkov
                                          Selfcode: sh:) fo:} ch:? rl:) br:> n4:& va:| de:> zu:} fl:{ ss:| ls:# js:|
                        2. problematische Seite

                          @@Felix Riesterer

                          Deshalb werfe ich Dir wiederholt vor, dass Du Dich in Deiner Art der Diskussionsführung (zumindest mir gegenüber, das aber in enormem Maße) regelmäßig unglaubwürdig machst und Dein eigentliches argumentatorisches Ziel verfehlst.

                          „… Lügen aufzutischen … Da lügst Du. … Bitte unterlasse solche Falschaussagen außerhalb Deines Elfenbeinturms! … Nochmal für Dich zum mitschnitzen: …“

                          Auch ich sehe Mängel in der Art der Diskussionsführung – nur halt an anderen Stellen als du.

                          LLAP 🖖

                          --
                          “You might believe there are benefits for the developer, but first of all, you should put those behind the interest of the user.” —Stefan Tilkov
                          Selfcode: sh:) fo:} ch:? rl:) br:> n4:& va:| de:> zu:} fl:{ ss:| ls:# js:|
                  2. problematische Seite

                    Lieber Matthias,

                    Aus pädagogischer Sicht spricht nichts dagegen, bereits im ersten Beispiel, unmittelbar unter Eingabemöglichkeiten zu notieren:

                    <form action="https://google.de/search">
                      <label>Suchbegriff <input name="q"></label>
                    </form>
                    

                    das hast Du nun als neueste Änderung umgesetzt. Damit wird der Artikel an anderer Stelle aber inkonsistent. Es heißt dort später:

                    [...] aus Benutzersicht ist es aber unzugänglich, da nicht klar ist, welche Art von Datum das Textfeld verlangt.

                    Durch das von Dir einfach eingefügte aber nicht weiter erklärte oder zumindest kommentierte <label> ist das faktisch nicht mehr richtig. Deshalb finde ich diese Änderung nicht gut. Entweder man macht das wieder rückgängig, oder man arbeitet ausführlicher um, damit die inhaltliche Konsistenz wieder hergestellt wird!

                    Im Übrigen wird in diesem Artikel oft genug auf die Notwendigkeit von Beschriftungen hingewiesen, dass es für diese Änderung überhaupt keine Not hatte.

                    Liebe Grüße,

                    Felix Riesterer.

                    1. problematische Seite

                      Hallo Felix Riesterer,

                      das hast Du nun als neueste Änderung umgesetzt.

                      Deine Antwort war: von mir aus gerne.

                      Entweder man macht das wieder rückgängig, oder man arbeitet ausführlicher um, damit die inhaltliche Konsistenz wieder hergestellt wird!

                      Oder.

                      Bis demnächst
                      Matthias

                      --
                      Dieses Forum nutzt Markdown. Im Wiki erhalten Sie Hilfe bei der Formatierung Ihrer Beiträge.
                      1. problematische Seite

                        Lieber Matthias,

                        Oder.

                        OK. Vielleicht kürze ich den Artikel wieder auf ein erträgliches Maß zurück, damit er für Unbedarfte wieder überschaubar wird. Mal sehen.

                        Liebe Grüße,

                        Felix Riesterer.

                        1. problematische Seite

                          [X] done

                          Liebe Grüße,

                          Felix Riesterer.

            2. problematische Seite

              Lieber Gunnar,

              Du willst mich nicht verstehen. Das beweist Du immer wieder. Und es ist deshalb offensichtlich gut, dass Du kein Pädagoge geworden bist.

              Mein Ansatz ist, dass ich einen Lernenden führe. Am Ende des Weges, den ich ihn führe, ist er (hoffentlich) kompetent. Es liegt in der Natur des Lernens, dass man Schritt für Schritt gehen muss. Du willst anscheinend den Lernenden von Anfang an auf die Meta-Ebene setzen und über Zugänglichkeit philosophieren, wenn der Lernende noch nicht die Grundlagen hat, überhaupt zu verstehen, was Du willst.

              „Ich bin der Geist, der stets verneint!“

              Das trifft auf Dich nicht zu. Du kannst auch zustimmen.

              ein (vielleicht nicht für jedermann) nutzbares Konstrukt

              Nicht für jedermann nutzbar heißt im Web: nicht nutzbar. “[The Web] is for everyone!” —Tim Berners-Lee

              "Nutzbar" ist etwas völlig anderes, als technisch in einer gewissen Weise funktional. Bitte vermische nicht die Meta-Ebene ("Ich bestehe unter allen Umständen auf Zugänglichkeit, und zwar schon bevor irgend ein Grundstein gelegt ist!") mit den Grundlagen ("Also da gibt es Schlüssel-Wer-Paare, die der Server verstehen kann. Und ein Submit-Button schickt das Formular ab.").

              Du kommst mir wie ein katholischer Priester vor, der von einem grundsätzlichen Verbot von Verhütung spricht. Man mag ihm nicht mehr zuhören, da seine Position aufgrund ihrer Absolutheit jegliches Diskutieren von Nuancen vergiftet. Wir sind uns ja einig, dass ein Eingabefeld in einem Formular eine Beschriftung braucht. Aber das Versenden von Formularinhalten, also die Technik dahinter, braucht das nicht. Die Nutzer brauchen das. Und dass ein Formular nicht für Computer oder Software, sondern für Nutzer da ist, ist ja auch unbestritten. Aber die Grundlagen der Versands haben mit den Beschriftungen einfach keinen Zusammenhang!

              Ein Automotor funktioniert in der Werkstatt auch ohne Fahrer, wenn er in eine passende Maschinerie eingebettet ist und seine technische Funktionalität überprüft werden soll. Laborbedingungen eben. Das kann man auf ein Webformular auch übertragen.

              “When designing for The Web, your users could be anyone. Make fewer decisions about them so they can make more for themselves.”Heydon Pickering

              Und da ist er wieder, der Priester, dem man nicht mehr zuhören möchte, da seine Absolutheit mit meinem individuellen Fall einfach keinen Zusammenhang mehr hat.

              Ohne Beschriftung ist ein Formularfeld nicht funktionstüchtig.

              Da lügst Du.

              Ja nee is’ klar. Genauso wie Kerstin Probiesch [^1], Cordelia McGee-Tubb [^2], David Bolter [^3], David Storey [^4], Heydon Pickering [^5] – alles Lügner.

              Die von Dir genannten reden von Zugänglichkeit. Davon, dass technische Einrichtungen für Benutzer sind, und dass sie keinen Selbstzweck haben, sondern Werkzeuge zum Gebrauch. Ohne Zugänglichkeit sind sie schlechte Werkzeuge, weil nicht (für jedermann) nutzbar. Das ist aber eine völlig andere Aussage, als "Ohne Beschriftung ist ein Formularfeld nicht funktionstüchtig.". Du setzt das Wort "funktionstüchtig" gleich mit "für zwingend jedermann nutzbar". Du willst die Laborbedingung beim Lernen nicht zulassen, weil Dir Deine missionarische Sendung über alles geht. Deshalb habe ich Dich mit einem katholischen Priester verglichen, der gegen jede Form von Verhütung wettert. Und deshalb habe ich Dich auch der Lüge bezichtigt. Solltest Du "funktionstüchtig" anders verwenden, als das Wort bedeutet, dann ist das eben eine andere Form von Wahrheit, jedenfalls keine technische.

              Für unzumutbar halte ich Tutorials, die falsches Halbwissen vermitteln.

              Und wo tut das mein Tutorial?

              Dabei bedarf es in diesem Fall nur kleinen Änderungen, um den Missstand auszumerzen: Beschriftung mit ins Grundgerüst.

              Ist doch vorhanden! Du musst nur einen Lernenden den Weg auch gehen lassen! Das Lernen ist ein Prozess. Der dauert. Der will in allen notwendigen Schritten erlebt sein. Und das "Halbwissen" ist ein Zwischenstand, der leider unvermeidlich ist. Dafür steht aber am Ende eine Kompetenz, die fundiert ist.

              Andere der Lüge zu bezichtigen dürfte einer sachlichen Diskussion kaum dienlich sein. Wenn du eine solche willst, bist du es, der hier etwas zu unterlassen hat.

              Bitte verwende Vokabeln, wie sie allgemeinhin verstanden werden und nicht in einer bedeutungsverengenden weil missionierenden Form. Dann verstehen wir uns wieder. Dieser Vorfall ist in diesem Forum übrigens nicht er einzige oder gar erste dieser Art!

              Für mich hört nur das Grundgerüst an einer späteren Stelle auf: nach der Beschriftung. Kein Grundgerüst ohne.

              Man hat Dir in diesem Forum bereits attestiert, dass Du nicht willens oder vielleicht sogar fähig bist, Dich in einen Anfänger hinein zu versetzen. Auch, dass Du dazu neigst, nur Deine Ansicht "gebetsmühlenartig" zu wiederholen, ohne den Kern der Diskussion annehmen zu können.

              Du missverstehst. (Irgendwer sagte mal, dass man nichts mit Boshaftigkeit begründen sollte, was sich auch mit Dummheit begründen lässt.)

              Gerade musste ich Janosch zitieren. Du darfst Dir den dortigen Thread noch einmal in Gänze zu Gemüte führen und Deine Rolle in der Diskussion daraufhin prüfen, ob Du wirklich verstanden hast, was man Dir nahezulegen versuchte. Dass Janosch, ich und andere dort sehr wohl Deinen Standpunkt begriffen haben, wie ich auch hier Deinen (im Prinzip mit dem dortigen identischen) Standpunkt begriffen zu haben meine, legt den Verdacht nahe, dass das Missverständnis bei Dir liegt. Auch der Umstand, dass Du die fast identische Diskussion hier erneut startest, bekräftigt diesen Verdacht.

              Ach übrigens: Wo bleibt eigentlich Dein Folgeartikel auf das Tic-Tac-Toe-Tutorial? Du wolltest doch die Zugänglichkeit nicht nur preisen und bei anderen kritisieren, sondern aktiv zu Weltverbesserung beitragen! ... Naja, katholischer Priester (s.o.) halt...

              Aber diese Diskussion hatten wir bereits andernorts erschöpfend geführt.

              Scheinbar nicht.

              LOL

              Waren es schon elf Mal?

              Es waren jedenfalls n-1 Mal zu oft.

              “The 11 in a11y stands for the number of times you have to tell developers that accessibility is important.”Ian Devlin

              Ich werde gewiss nicht locker lassen. Denn das ist meine Aufgabe:

              “Arguing with teammates over ‘bothering with accessibility’ makes me so angry. Every. Time. So. Angry. Yes. ‘Bother’. It’s your job.” —Jen Simmons

              Ja. Ich habe verstanden. Du bist auf einem Kreuzzug. Kreuzzügler hatten sich noch nie besonders durch Verständnis und die Fähigkeit ausgezeichnet, sich in die Sichtweise anderer zu versetzen, um das eigene Verstehen zu fördern.

              Liebe Grüße,

              Felix Riesterer.

              1. problematische Seite

                Hallo Felix,

                Mein Ansatz ist, dass ich einen Lernenden führe. Am Ende des Weges, den ich ihn führe, ist er (hoffentlich) kompetent.

                soweit ist das gut. Das mag in der Schule gut funktionieren, wo die Lernenden teils aus Interesse und Überzeugung, zum größeren Teil aber wohl per Zwang bis zum Ende dabeibleiben.
                Was ist aber in freier Wildbahn wie hier, wo der Lernende jederzeit abspringen kann, sobald er den Eindruck hat, "genug" verstanden zu haben? Das sind die Fälle, in denen deine prinzipiell sinnvolle Strategie Leute mit (eventuell gefährlichem) Halbwissen am Wegesrand zurücklässt.

                Es liegt in der Natur des Lernens, dass man Schritt für Schritt gehen muss.

                Genau. Und deswegen finde ich deinen Ansatz auch grundsätzlich gut und in Ordnung. Aber ich würde dringend empfehlen, ihn zu ergänzen - nämlich um einen kurzen Überblick am Anfang, der in knapper Form die wesentlichen Meilensteine aufzeigt und deutlich macht, warum die Hälfte des Wegs möglicherweise nicht reicht, um nachher in der Praxis zu bestehen.
                Mir hat es in der Schule immer sehr geholfen, wenn der Lehrer zu Beginn einer Unterrichtseinheit einen kurzen Überblick gegeben hat, wo wir hinwollen und wofür man das später wieder brauchen kann. Leider haben das nur wenige Lehrer getan.

                Du willst anscheinend den Lernenden von Anfang an auf die Meta-Ebene setzen und über Zugänglichkeit philosophieren, wenn der Lernende noch nicht die Grundlagen hat, überhaupt zu verstehen, was Du willst.

                Ja. Gunnar will sofort alles auf einmal, glaube ich. Das ist das andere Extrem. Das mag funktionieren, wenn die Leute schon mit soliden Vorkenntnissen ankommen, aber wohl nicht bei Neueinsteigern.

                Du kommst mir wie ein katholischer Priester vor, der von einem grundsätzlichen Verbot von Verhütung spricht.

                Nur mit dem Unterschied, dass der katholische Priester eigentlich keine Ahnung von dem haben dürfte, was er da verbietet. Zumindest keine Praxiserfahrung ... ;-)

                Ja. Ich habe verstanden. Du bist auf einem Kreuzzug.

                Als militanter Missionar? Ja, ein bisschen schon ...

                Schönes Wochenende,
                 Martin

                --
                Logik ist die Theorie, Chaos die Praxis.
                1. problematische Seite

                  Lieber Martin,

                  Aber ich würde dringend empfehlen, ihn zu ergänzen - nämlich um einen kurzen Überblick am Anfang, der in knapper Form die wesentlichen Meilensteine aufzeigt und deutlich macht, warum die Hälfte des Wegs möglicherweise nicht reicht, um nachher in der Praxis zu bestehen.

                  wird gemacht! Vielen Dank für diesen konstruktiven Vorschlag. :-)

                  Liebe Grüße,

                  Felix Riesterer.

                  1. problematische Seite

                    wird gemacht!

                    [X] done.

                    Liebe Grüße,

                    Felix Riesterer.

                    1. problematische Seite

                      Hallo,

                      wird gemacht!

                      [X] done.

                      so ungefähr hatte ich mir das vorgestellt. :-)
                      Ich habe eben noch den Abschnitt über GET vs. POST etwas ergänzt und eine kleine Korrektur angebracht.

                      So long,
                       Martin

                      --
                      Logik ist die Theorie, Chaos die Praxis.
                      1. problematische Seite

                        Lieber Martin,

                        so ungefähr hatte ich mir das vorgestellt. :-)

                        :-)

                        Ich habe eben noch den Abschnitt über GET vs. POST etwas ergänzt und eine kleine Korrektur angebracht.

                        Herzlichen Dank!

                        Liebe Grüße,

                        Felix Riesterer.

                2. problematische Seite

                  Hej Martin,

                  Mein Ansatz ist, dass ich einen Lernenden führe. Am Ende des Weges, den ich ihn führe, ist er (hoffentlich) kompetent.

                  soweit ist das gut. Das mag in der Schule gut funktionieren, wo die Lernenden teils aus Interesse und Überzeugung, zum größeren Teil aber wohl per Zwang bis zum Ende dabeibleiben.

                  Ob jemand bis zum Ende zuhört kann man aber nie sicherstellen. Obwohl es didaktische Methoden gibt, die Rate zu verbessern (Felix macht das übrigens gut). Ich gehe als Autor eines Tutorials erst mal davon aus, auf interessierte Leser zu treffen.

                  Das mit dem Überblick ist eine gute Idee!

                  Marc

                  1. problematische Seite

                    Hallo,

                    soweit ist das gut. Das mag in der Schule gut funktionieren, wo die Lernenden teils aus Interesse und Überzeugung, zum größeren Teil aber wohl per Zwang bis zum Ende dabeibleiben.

                    Ob jemand bis zum Ende zuhört kann man aber nie sicherstellen.

                    das stimmt natürlich; ich kann auch aus meiner Schulzeit bestätigen, dass wir in manchen Fächern nicht viel mehr als die "Anwesenheitspflicht" erfüllt haben. Vor allem dann, wenn der Lehrer nicht bloß als Pädagoge eine Pfeife ist, sondern ihm auch noch egal ist, was die Schüler machen,

                    Wenn ich da so an meine Französisch-Lehrerin der 7. und 8. Klasse denke ... wenn wir bei der Klassenarbeiten geschrieben haben, konnte man den Begriff wörtlich nehmen. ;-)

                    Obwohl es didaktische Methoden gibt, die Rate zu verbessern (Felix macht das übrigens gut).

                    Das kann ich nicht beurteilen, glaube ich aber gern.

                    Ich gehe als Autor eines Tutorials erst mal davon aus, auf interessierte Leser zu treffen.

                    Die Annahme ist sicher richtig. Trotzdem liegt es IMO in der Natur des Menschen, die Aufmerksamkeit abzuziehen, sobald man meint, man hätte genug gesehen/gehört/verstanden.

                    So long,
                     Martin

                    --
                    Nothing travels faster than the speed of light with the possible exception of bad news, which obeys its own special laws.
                    - Douglas Adams, The Hitchhiker's Guide To The Galaxy
              2. problematische Seite

                @@Felix Riesterer

                Lieber Gunnar,

                Du willst mich nicht verstehen. Das beweist Du immer wieder. Und es ist deshalb offensichtlich gut, dass Du kein Pädagoge geworden bist.

                Lieber Felix,

                Du kannst mich nicht verstehen. Das beweist Du immer wieder. Und es ist deshalb offensichtlich gut, dass Du kein Webentwickler geworden bist.

                Du willst anscheinend den Lernenden von Anfang an auf die Meta-Ebene setzen

                Meta? Nein.

                Ich will den Lernenden von Anfang an auf den richtigen Weg bringen.

                „Ich bin der Geist, der stets verneint!“

                Das trifft auf Dich nicht zu. Du kannst auch zustimmen.

                Nein. 😈

                "Nutzbar" ist etwas völlig anderes, als technisch in einer gewissen Weise funktional.

                Richtig. „Nutzbar“ ist relevant; „technisch in einer gewissen Weise funktional“ ist irrelevant.

                Bitte vermische nicht die Meta-Ebene ("Ich bestehe unter allen Umständen auf Zugänglichkeit, und zwar schon bevor irgend ein Grundstein gelegt ist!") mit den Grundlagen ("Also da gibt es Schlüssel-Wer-Paare, die der Server verstehen kann.

                Meta? Nein.

                Ein Formular, das nicht benutzbar ist, taugt genausowenig wie ein Formular, das die Eingaben nicht verarbeitet/abschickt. Beides zusammen („vermischt“) macht ein funktionstüchtiges Formular aus.

                Du kommst mir wie ein katholischer Priester vor

                „Sag mal, dürfen Katholiken …?“

                Ein Automotor funktioniert in der Werkstatt auch ohne Fahrer

                Und erfüllt sogar die Abgasnorm.

                Du setzt das Wort "funktionstüchtig" gleich mit "für zwingend jedermann nutzbar".

                Ja. Sonst hieße es ja „eingeschränkt funktionstüchtig“.

                Du willst die Laborbedingung beim Lernen nicht zulassen, weil Dir Deine missionarische Sendung über alles geht.

                Du missverstehst.

                Ich will schlechte Lerninhalte nicht zulassen, weil mir der Lernerfolg der Lernenden über alles geht.

                Das Lernen ist ein Prozess. Der dauert.

                Ja. Ich werde deinen Lernprozess mit meinen Kommentaren begleiten …

                Der will in allen notwendigen Schritten erlebt sein. Und das "Halbwissen" ist ein Zwischenstand, der leider unvermeidlich ist.

                … auch wenn das schmerzhaft für dich ist.

                Man hat Dir in diesem Forum bereits attestiert, dass Du nicht willens oder vielleicht sogar fähig bist, Dich in einen Anfänger hinein zu versetzen.

                Du kannst gerne weitere Vertreter aus deiner Filterblase anführen – dadurch wird das „man“ aber noch nicht die Allgemeinheit.

                Dass Janosch, ich und andere dort sehr wohl Deinen Standpunkt begriffen haben …
                Ach übrigens: Wo bleibt eigentlich Dein Folgeartikel auf das Tic-Tac-Toe-Tutorial?

                Die Frage zeigt, dass du meinen Standpunkt nicht begriffen hast.

                Es sehe keinen Sinn darin, in einunddemselben Wiki zwei Artikel zum selben Thema zu haben, wobei der zweite eine Berichtigung des ersten ist.

                “Arguing with teammates over ‘bothering with accessibility’ makes me so angry. Every. Time. So. Angry. Yes. ‘Bother’. It’s your job.” —Jen Simmons

                Ja. Ich habe verstanden. Du bist auf einem Kreuzzug.

                Nichts hast du verstanden.

                Aber wie du sagtest: „Das Lernen ist ein Prozess. Der dauert.“

                LLAP 🖖

                --
                “You might believe there are benefits for the developer, but first of all, you should put those behind the interest of the user.” —Stefan Tilkov
                Selfcode: sh:) fo:} ch:? rl:) br:> n4:& va:| de:> zu:} fl:{ ss:| ls:# js:|

                Folgende Beiträge verweisen auf diesen Beitrag:

                1. problematische Seite

                  Hallo,

                  Du setzt das Wort "funktionstüchtig" gleich mit "für zwingend jedermann nutzbar".

                  Ja. Sonst hieße es ja „eingeschränkt funktionstüchtig“.

                  nein. Dann hieße es „eingeschränkt benutzbar

                  Du missverstehst.

                  [...]

                  Das Lernen ist ein Prozess. Der dauert.

                  Ja. Ich werde deinem Lernprozess mit meinen Kommentaren begleiten …

                  Du missverstehst, in diesem Fall absichtlich, was der "Diskussion" hier sehr abträglich ist. Es geht hier nicht um Felix Lernprozess.

                  Ja. Ich habe verstanden. Du bist auf einem Kreuzzug.

                  Nichts hast du verstanden.

                  Und was ist mit dir?

                  Gruß
                  Kalk

                  1. problematische Seite

                    @@Tabellenkalk

                    Du missverstehst, in diesem Fall absichtlich, was der "Diskussion" hier sehr abträglich ist. Es geht hier nicht um Felix Lernprozess.

                    Bislang nicht, jetzt ja. Warum sollte das der Diskussion abträglich sein? (Lernwilligkeit vorausgesetzt.)

                    LLAP 🖖

                    --
                    “You might believe there are benefits for the developer, but first of all, you should put those behind the interest of the user.” —Stefan Tilkov
                    Selfcode: sh:) fo:} ch:? rl:) br:> n4:& va:| de:> zu:} fl:{ ss:| ls:# js:|
                    1. problematische Seite

                      Hallo,

                      Du missverstehst, in diesem Fall absichtlich, [...] Es geht hier nicht um Felix Lernprozess.

                      Bislang nicht, jetzt ja.

                      Wie soll man dieses Rätsel nun deuten? Bisher hast du wirklich gedacht, es gehe um Felix' Lernprozess, aber ab jetzt nicht mehr, tust aber so?

                      Warum sollte das der Diskussion abträglich sein?

                      Manchmal kann absichtliches Missverstehen einer Diskussion förderlich sein, das mache ich auch gelegentlich so. Aber in dieser hier, halte ich diese Methode für unangebracht.

                      Gruß
                      Kalk

                      1. problematische Seite

                        @@Tabellenkalk

                        Wie soll man dieses Rätsel nun deuten?

                        Mir war schon klar, dass Felix den Lernprozess der Leser der Wiki-Artikel meinte.

                        Ich wollte die Diskussion umbiegen zu dem Lernprozess der Schreiber der Wiki-Artikel.

                        In dem Fall Felix, aber das betrifft alle Schreiberlinge, inkl. meiner Wenigkeit. Und ist auch nicht auf das hiesige Wiki beschränkt.

                        LLAP 🖖

                        --
                        “You might believe there are benefits for the developer, but first of all, you should put those behind the interest of the user.” —Stefan Tilkov
                        Selfcode: sh:) fo:} ch:? rl:) br:> n4:& va:| de:> zu:} fl:{ ss:| ls:# js:|
          2. problematische Seite

            Hallo Felix,

            irgendwie war mir klar, dass Du Dich darauf wie auf ein gefundenes Fressen stürzen würdest.

            Ich denke, du solltest die Beiträge von Gunnar weniger persönlich nehmen. Ich hatte nie den Eindruck, dass er etwas aus Bosheit oder um jemandem einen reinzuwürgen tut. Und letzlich habt ihr ja beide auch das gleiche Ziel.

            Aber was soll „Zwar wäre das Suchformular bereits technisch funktionstüchtig“? Was heißt „technisch funktionstüchtig“?

            Ich sehe keinen Sinn darin, Anfängern Lügen aufzutischen.

            Es ist keine Lüge zu behaupten, dass Formular-Elemente ohne Beschriftung technisch nicht funktionstüchtig sind. Wichtige Teile der Funktionalität fehlen. Und ich sehe hier nicht, inwiefern sie etwas verkomplizieren würden. Gleich den richtigen Weg liefern halte ich hier auch für sinnvoll.

            Was auch immer das heißen mag, es ist IMHO nichts von Relevanz. Ohne Beschriftung ist ein Formularfeld nicht funktionstüchtig.

            Da lügst Du.

            Das sehe ich nicht so. Mal abgesehen davon, dass man für eine Lüge willentlich, wissentlich und in böser Absicht die Unwahrheit behaupten muss, hat Gunnar hier IMHO recht.

            <label> gehört bereits mit ins Grundgerüst. Das Tutorial sollte gerade Anfängern nicht vermitteln, dass die Beschriftung nicht zwingend dazugehört.

            ACK.

            LG,
            CK

            Folgende Beiträge verweisen auf diesen Beitrag:

            1. problematische Seite

              Lieber Christian,

              Ich denke, du solltest die Beiträge von Gunnar weniger persönlich nehmen.

              ich nehme sie nicht persönlich. Ich verurteile seine Handlungsweise.

              Es ist keine Lüge zu behaupten, dass Formular-Elemente ohne Beschriftung technisch nicht funktionstüchtig sind. Wichtige Teile der Funktionalität fehlen. Und ich sehe hier nicht, inwiefern sie etwas verkomplizieren würden. Gleich den richtigen Weg liefern halte ich hier auch für sinnvoll.

              Welcher Teil der Funktionalität fehlt? Man kann einen Wert eingeben und diesen erfolgreich an die Zielseite übermitteln! Was also die nackte Grundfunktionalität angeht, ist das Beispiel zwar unzugänglich, aber funktional.

              Das sehe ich nicht so. Mal abgesehen davon, dass man für eine Lüge willentlich, wissentlich und in böser Absicht die Unwahrheit behaupten muss, hat Gunnar hier IMHO recht.

              Warum nur seht ihr nicht, dass die Beschriftung unmittelbar darauf hinzugefügt wird, um das Beispiel zu vervollständigen. Komisch, dass ihr beide euch an dem "leeren" <form> so überhaupt nicht stört... und an dem Beispiel ohne Button auch nicht... extrem seltsam, wenn man die Beharrlichkeit eurer Argumentationsweise anschaut.

              <label> gehört bereits mit ins Grundgerüst. Das Tutorial sollte gerade Anfängern nicht vermitteln, dass die Beschriftung nicht zwingend dazugehört.

              ACK.

              Ja, und der Button und das Eingabefeld auch. Alle drei! Und sie stehen darin! Wo ist also euer Problem??

              Mir scheint, ihr könnt euch von eurem Vorwissen nicht trennen und befürchtet insbesondere und vor allem, dass ein schlampiger dahergelaufener Anfänger sich das Tutorial bis zum dritten Beispiel (in welchem der Button hinzu kommt) durchliest, um sich dann als professioneller Webdesigner zu verdingen und internetverschmutzend quasifaschistisch für Firmen und Startups kaputte und diskriminierende Webseiten zu erstellen, ohne sich das (nun wirklich kurze!) Tutorial bis zum Ende gegeben zu haben. Dass man einen Anfänger Schritt für Schritt durch die Zusammenhänge führt und nicht gleich ins Zielfeld "beamt", um bei jedem Schritt die Möglichkeit zum Verstehen und Reflektieren zu geben, ist euch dermaßen fremd (geworden)? Irgendwie mag mir die Stimmigkeit eurer Einwände nicht ganz einleuchten, denn wir verbeißen uns an einem bestimmten Zwischenschritt, der ebenso wenig fertig ist, wie die beiden vor ihm - und alle drei heißen "Grundgerüst"!

              Eure Argumentation hat sowas von ceterum censeo...

              Liebe Grüße,

              Felix Riesterer.

              1. problematische Seite

                Hallo Felix,

                Es ist keine Lüge zu behaupten, dass Formular-Elemente ohne Beschriftung technisch nicht funktionstüchtig sind. Wichtige Teile der Funktionalität fehlen. Und ich sehe hier nicht, inwiefern sie etwas verkomplizieren würden. Gleich den richtigen Weg liefern halte ich hier auch für sinnvoll.

                Welcher Teil der Funktionalität fehlt? Man kann einen Wert eingeben und diesen erfolgreich an die Zielseite übermitteln! Was also die nackte Grundfunktionalität angeht, ist das Beispiel zwar unzugänglich, aber funktional.

                Zugänglichkeit ist Grundfunktionalität. Wenn das nicht bereit gestellt ist, ist es nicht funktional.

                Warum nur seht ihr nicht, dass die Beschriftung unmittelbar darauf hinzugefügt wird, um das Beispiel zu vervollständigen.

                Das habe ich gesehen, das halte ich aber für wenig. Und ich bin ja auch nicht der einzige, der das so sieht.

                Komisch, dass ihr beide euch an dem "leeren" <form> so überhaupt nicht stört...

                Warum auch? Ein leeres form macht nichts kaputt.

                und an dem Beispiel ohne Button auch nicht...

                Das macht auch nichts kaputt. Fehlende Beschriftungen dagegen schon, und das gleich für ganze Bevölkerungsgruppen.

                Mir scheint, ihr könnt euch von eurem Vorwissen nicht trennen und befürchtet insbesondere und vor allem [… Provokationen bzgl Anfängern, die nicht weiterlesen …]

                Das ist keine Befürchtung, das sind 20 Jahre Berufserfahrung, die genau das gelehrt haben. Du glaubst gar nicht, wie unglaublich oft ich genau das erlebt habe.

                Dass man einen Anfänger Schritt für Schritt durch die Zusammenhänge führt und nicht gleich ins Zielfeld "beamt", um bei jedem Schritt die Möglichkeit zum Verstehen und Reflektieren zu geben, ist euch dermaßen fremd (geworden)?

                Nein, aber auch nicht fremd ist mir das Konzept, Anfängern gleich bestimmte, wichtige Strukturen mitzugeben und sie gar nicht erst mit schlechten Angewohnheiten zu konfrontieren. So würde man in einem Programmier-Tutorial auch gar nicht erst globale Variablen in Beispielen verwenden. Es gibt einfach Sachen, die man vermeidet, um schlechte Angewohnheiten und häufige Fehler auszumerzen.

                Eure Argumentation hat sowas von ceterum censeo...

                Das kannst du natürlich sehen, wie du das meinst, aber ich finde es schon ziemlich dreist mir das zu unterstellen.

                LG,
                CK

                1. problematische Seite

                  Hallo Christian, @Felix Riesterer

                  Dass man einen Anfänger Schritt für Schritt durch die Zusammenhänge führt und nicht gleich ins Zielfeld "beamt", um bei jedem Schritt die Möglichkeit zum Verstehen und Reflektieren zu geben, ist euch dermaßen fremd (geworden)?

                  Nein, aber auch nicht fremd ist mir das Konzept, Anfängern gleich bestimmte, wichtige Strukturen mitzugeben und sie gar nicht erst mit schlechten Angewohnheiten zu konfrontieren. So würde man in einem Programmier-Tutorial auch gar nicht erst globale Variablen in Beispielen verwenden. Es gibt einfach Sachen, die man vermeidet, um schlechte Angewohnheiten und häufige Fehler auszumerzen.

                  Ich habe jedenfalls noch keine Einführung in PHP gesehen, in der als erstes goto[1] eingeführt und dann erklärt wird, dass man doch lieber if benutzen solle... Warum? – weil es goto in PHP erst seit 5.3 gibt!
                  ;-)

                  Gruß
                  Julius



                  1. php.net: goto ↩︎

                2. problematische Seite

                  Lieber Christian,

                  20 Jahre Berufserfahrung, die genau das gelehrt haben. Du glaubst gar nicht, wie unglaublich oft ich genau das erlebt habe.

                  meinst Du (u.a.) sowas?

                  Liebe Grüße,

                  Felix Riesterer.

              2. problematische Seite

                @@Felix Riesterer

                Ich verurteile seine Handlungsweise.

                ?? Welche denn genau? Du sagtest, wir „dürft[en] gerne alle … herumkritisieren.“ Das hab ich gemacht. Und das verurteilst du jetzt‽

                Wenn du meinst, wir dürften gerne alle herumlobhudeln, dann sag das doch so.

                Es ist keine Lüge zu behaupten, dass Formular-Elemente ohne Beschriftung technisch nicht funktionstüchtig sind

                Welcher Teil der Funktionalität fehlt? Man kann einen Wert eingeben

                Ja, kann man. Man weiß aber nicht, welchen Wert man dort eingeben sollte.

                ist das Beispiel zwar unzugänglich, aber funktional.

                Das widerspricht sich. Was nicht zugänglich ist, ist nicht funktional.

                Warum nur seht ihr nicht, dass die Beschriftung unmittelbar darauf hinzugefügt wird, um das Beispiel zu vervollständigen.

                Haben wir doch. (Ich jedenfalls.) Ich hab doch auch gesehen, dass auch du die Beschriftung für „unverzichtbar“ hältst.

                Mein Kritikpunkt war einfach nur, die Überschriften etwas anders zu setzen, so dass die unverzichtbare Beschriftung noch mit unter Grundgerüst steht.

                Mir scheint, ihr könnt euch von eurem Vorwissen nicht trennen und befürchtet insbesondere und vor allem, dass ein schlampiger dahergelaufener Anfänger sich das Tutorial bis zum dritten Beispiel (in welchem der Button hinzu kommt) durchliest, um sich dann als professioneller Webdesigner zu verdingen und internetverschmutzend quasifaschistisch für Firmen und Startups kaputte und diskriminierende Webseiten zu erstellen, ohne sich das (nun wirklich kurze!) Tutorial bis zum Ende gegeben zu haben.

                Genau dieses Vorwissen fehlt dir. Es ist sinnvoller, dass du dir das aneignest, als dass wir uns davon trennen.

                Dass man einen Anfänger Schritt für Schritt durch die Zusammenhänge führt

                Dass das im Web nicht so funktioniert wie in deiner Schule, hatte ich dir (euch Lehrern und denen, die es werden wollen) damals schon gesagt. Der Martin hat es hier nochmal bekräftigt.

                Eure Argumentation hat sowas von ceterum censeo...

                Da kannst du noch so Zeter und Mordio rufen …

                LLAP 🖖

                --
                “You might believe there are benefits for the developer, but first of all, you should put those behind the interest of the user.” —Stefan Tilkov
                Selfcode: sh:) fo:} ch:? rl:) br:> n4:& va:| de:> zu:} fl:{ ss:| ls:# js:|
        3. problematische Seite

          Hallo,

          Aber was soll „Zwar wäre das Suchformular bereits technisch funktionstüchtig“? Was heißt „technisch funktionstüchtig“? Was auch immer das heißen mag, es ist IMHO nichts von Relevanz. Ohne Beschriftung ist ein Formularfeld nicht funktionstüchtig.

          Vor Jahren bin ich mal bei jemandem im Auto mitgefahren. Älteres Modell, ich glaub VW. Plötzlich bricht das Kupplungspedal. Ich wäre hilflos gewesen, Auto nicht mehr bedienbar. Der Fahrer sagt, „ach, kein Problem.“ Er hatte gelesen, bei bestimmten Geschwindigkeiten kann man ohne zu kuppeln schalten. Das Auto war weiterhin technisch funktionstüchtig, wir sind ans Ziel gekommen, wieder nach Hause und am nächsten Tag zur Werkstatt.

          Soviel von mir zu den Begrifflichkeiten.

          Gruß
          Kalk

          1. problematische Seite

            @@Tabellenkalk

            Plötzlich bricht das Kupplungspedal. … Das Auto war weiterhin technisch funktionstüchtig

            Ich bin mir nicht sicher, ob ein TÜVer deine Definition teilt.

            „Liebe Fluggäste, hier spricht Ihr Kapitän. Wie Sie am gesunkenen Geräuschpegel schon gemerkt haben, sind all unsere Triebwerke ausgefallen und wir gehen in den Segelflug über. Wünschen Sie uns Glück bei der Suche nach einer geeigneten Wiese zum Landen. Aber keine Sorge, unser Flugzeug ist weiterhin technisch funktionstüchtig.“

            LLAP 🖖

            --
            “You might believe there are benefits for the developer, but first of all, you should put those behind the interest of the user.” —Stefan Tilkov
            Selfcode: sh:) fo:} ch:? rl:) br:> n4:& va:| de:> zu:} fl:{ ss:| ls:# js:|
            1. problematische Seite

              Moin,

              Plötzlich bricht das Kupplungspedal. … Das Auto war weiterhin technisch funktionstüchtig

              Ich bin mir nicht sicher, ob ein TÜVer deine Definition teilt.

              doch, tut er vermutlich schon: Das Auto ist durchaus noch "technisch funktionstüchtig", aber nicht mehr verkehrssicher. Und das auch nicht, weil die defekte Kupplung per se einen Sicherheitsmangel darstellt - aber die Handhabung, das vorsichtige Schalten des Getriebes, erfordert nun so viel Aufmerksamkeit und Konzentration, dass der Fahrer dadurch erheblich vom Verkehrsgeschehen abgelenkt ist.

              Die Geschichte mit der defekten Kupplung habe ich übrigens selbst auch schon erlebt. Bei einem VW-Bus in olivgrün. Das Schalten ohne Kuppeln ist gar nicht so schwierig, mit etwas Feingefühl kriegt man es sogar geräuschlos hin (aber nicht im hektischen Stadtverkehr). Aber das Anfahren mit dem Anlasser tut dem Techniker in der Seele weh.

              So long,
               Martin

              --
              Logik ist die Theorie, Chaos die Praxis.
            2. problematische Seite

              Hallo,

              all unsere Triebwerke ausgefallen

              wo schrieb ich davon, dass der Motor ausgefallen ist? Bitte begeben sie sich auf direktem Weg in die Obst- und Gemüseabteilung, und sehen sich vorort die Unterschiede zwischen Äpfel und Birnen an!

              Gruß
              Kalk

        4. problematische Seite

          Hej Gunnar,

          @@Felix Riesterer

          <label> gehört bereits mit ins Grundgerüst. Das Tutorial sollte gerade Anfängern nicht vermitteln, dass die Beschriftung nicht zwingend dazugehört.

          Um zum Anfang der Diskussion zurückzukehren:

          1.) mit der Begründung, dass es nicht funktionstüchtig ist (nicht sinnvoll bedienbar), kann man den Artikel über das html-grundgerüst aus dem Wiki schmeißen. 2.) Label gehören in jedes Anfänger-Formular. Alles andere (title, aria-Werte, for-id-verknüpfungen usw) sollten im weiteren Verlauf erklärt werden.

          Ich würde in dem Artikel gar nicht darauf eingehen, ob das Formular ohne Label technisch funktionsfähig ist oder nicht und welche Philosophie sich hinter den jeweiligen Behauptungen verbirgt.

          Im übrigen ist die Diskussion müßig, weil "nicht nutzbar" ist das Formular in jedem Fall. Und somit müssen die Beschriftungen rein.

          Warum das so ist, interessiert Anfänger nicht.

          Marc

          1. problematische Seite

            @@marctrix

            2.) Label gehören in jedes Anfänger-Formular. Alles andere (title, aria-Werte, for-id-verknüpfungen usw) sollten im weiteren Verlauf erklärt werden.

            Meinst du mit „im weiteren Verlauf“ in einem weiteren Artikel oder im Verlauf dieses Artikels?

            title und aria-Werte müssen nicht im Scope dieses Artikels sein. for-id-Verknüpfungen jedoch schon. Sie machen label ja erst funktionstüchtig, wenn das input-Element nicht innerhalb des labels steht.

            Und somit müssen die Beschriftungen rein.
            Warum das so ist, interessiert Anfänger nicht.

            Da würde ich widersprechen. Anfänger werden auch andere Quellen im Web lesen, wo womöglich Eingabefelder unbeschriftet sind. Da brauchen sie das Verständnis, warum das schlecht ist. Dieses Wissen sollte das SELFHTML-Wiki vermitteln.

            LLAP 🖖

            --
            “You might believe there are benefits for the developer, but first of all, you should put those behind the interest of the user.” —Stefan Tilkov
            Selfcode: sh:) fo:} ch:? rl:) br:> n4:& va:| de:> zu:} fl:{ ss:| ls:# js:|
            1. problematische Seite

              Hej Gunnar,

              @@marctrix

              2.) Label gehören in jedes Anfänger-Formular. Alles andere (title, aria-Werte, for-id-verknüpfungen usw) sollten im weiteren Verlauf erklärt werden.

              Meinst du mit „im weiteren Verlauf“ in einem weiteren Artikel oder im Verlauf dieses Artikels?

              Hängt von der Konzeption des Artikels ab (wie weit will ich in diesem ersten Überblick gehen, was ist thematisch "groß" genug für einen eigenen Artikel). Wenn man z. B. title erwähnt, muss man auf die damit vorhandenen Probleme hinweisen (wie weise ich auf die vorhandene Hilfe hin, wie stelle ich die Infos für Leute ohne Maus bereit, wie löse ich das Problem, dass die eigentliche Zielgruppe diesen Hinweis nicht erreicht, weil Screenreader title nicht ausgeben, obwohl es rein technisch funktioniert ;-) ...). Das ist dann wieder ziemlich viel Stoff/Text.

              aria finde ich ebenfalls erklärungsbedürftig. Wenn erst mal gesagt wird, dass das für die Barriefreieheit nötig ist, wird daraus schnell so etwas wie "Damit beschäftige ich mich erst später, wenn es jemand von mir verlangt". Und jemand könnte auf die Idee kommen, keine Beschriftung anzugeben, weil das Formulars aufgrund seiner Position (oben rechts) und seiner Gestaltung (Lupe o. ä.) von erfahrenen, sehenden Nutzern als Suchformular identifiziert werden könnte.

              Darum die Idee, das einfach als "So ist das. Macht es so und nicht anders!" hinzustellen und weitere Erklärungen in Folgeartikeln anzubieten.

              title und aria-Werte müssen nicht im Scope dieses Artikels sein. for-id-Verknüpfungen jedoch schon. Sie machen label ja erst funktionstüchtig, wenn das input-Element nicht innerhalb des labels steht.

              Ja, das vermutlich schon, obwohl ich es mir auch durchaus vorstellen könnte, es in einem ersten Schritt bei der Verschachtelung zu belassen. So wie bei dem Formular - oder man erklärt auch die Zuornung von inputs usw zu einem Formular in einem Aufwasch mit. - Kann man, muss man aber nicht alles in einen Artikel packen.

              Es hängt davon ab, wie klein die Häppchen sein sollen, die man vermitteln will.

              Man kann IMHO auch durchaus darüber reden, ob die Gestaltung von Formularen nicht einen eigenen Artikel verdient.

              @Felix Riesterer - ich fände Werte wie foo und bar besser, weil ein einzelner Buchstabe (in deinem Beispiel "q") zu leicht übersehen wird und nicht so leicht als Wort wahrgenommen wird. Meiner meinung nach sollten IDs sprechend sein und darum sollten sie nie aus einzelnen Buchstaben bestehen. foo und bar repräsentieren Worte besser als ein "q"...

              Und somit müssen die Beschriftungen rein.
              Warum das so ist, interessiert Anfänger nicht.

              Da würde ich widersprechen. Anfänger werden auch andere Quellen im Web lesen, wo womöglich Eingabefelder unbeschriftet sind. Da brauchen sie das Verständnis, warum das schlecht ist. Dieses Wissen sollte das SELFHTML-Wiki vermitteln.

              Meine Überlegung war, sie gar nicht auf die Idee zu bringen, dass Beschriftungen optional sind. Aber ein Hinweis darauf, dass Formulare ohne Beschriftung nicht sinnvoll befüllt werden können, sollte bei den meisten vermutlich ankommen. - Hängt von der Formulierung ab. Hier möchte ich auf jeden Fall wie du eine Wortwahl, die nicht als Option missverstanden werden kann!

              Marc

              1. problematische Seite

                Lieber marctrix,

                @Felix Riesterer - ich fände Werte wie foo und bar besser, weil ein einzelner Buchstabe (in deinem Beispiel "q") zu leicht übersehen wird und nicht so leicht als Wort wahrgenommen wird. Meiner meinung nach sollten IDs sprechend sein und darum sollten sie nie aus einzelnen Buchstaben bestehen. foo und bar repräsentieren Worte besser als ein "q"...

                sag das mal Google. Prinzipiell stimme ich Dir ja zu, im konkreten Fall nutzt Google aber als Bezeichner q (steht wohl für query, engl. für Anfrage), sicherlich auch um Traffic zu sparen. Für Google ist das ein zugkräftiges Argument! Um nun ein funktionierendes Beispiel zu haben (bei den ersten Versionen meiner Website hatte ich Suchformulare verschiedener Suchmaschinen zum direkten Benutzen), muss ich wohl oder übel Googles Bezeichner verwenden...

                Liebe Grüße,

                Felix Riesterer.

                1. problematische Seite

                  Hej @@Felix Riesterer,

                  Lieber marctrix,

                  @Felix Riesterer - ich fände Werte wie foo und bar besser, weil ein einzelner Buchstabe (in deinem Beispiel "q")

                  sag das mal Google.

                  Alles klar, habe ich erst später bemerkt - kannst du mit meinen Änderungen leben?

                  Marc

    2. Hallo Felix Riesterer,

      OK, ich fange dann einmal damit an.

      Das ging ja schnell :-) Damit zusammenhängend kann ich dann ja gleich den nächsten Wunsch nachschieben: Obwohl eigentlich hast du mich durch Glossar: URL-Parameter drauf gebracht: Glossar: Query String würde sich folgerichtig anschließen.

      Vielen Dank für deinen Fleiß.

      Bis demnächst
      Matthias

      --
      Wenn eine Idee nicht zuerst absurd erscheint, taugt sie nichts. (Albert Einstein)
      1. Lieber Matthias,

        gleich den nächsten Wunsch nachschieben: [...] Glossar: Query String würde sich folgerichtig anschließen.

        frühestens in 28 Tagen. Aber da lasse ich gerne zuerst jemand anderes dran. ;-)

        Vielen Dank für deinen Fleiß.

        Ich steuere gerne etwas bei, muss mich aber mit kleinen Portionen begnügen, da ich große andere Baustellen habe.

        Liebe Grüße,

        Felix Riesterer.

    3. problematische Seite

      Hallo,

      In HTML gibt es für Buttons zweierlei Möglichkeiten, die aus historischen Gründen beide noch existieren,...

      nämlich welche? Das geht aus dem Abschnitt und auch aus dem verlinkten Buttonartikel nicht (deutlich) hervor.

      Gruß
      Kalk

      1. problematische Seite

        Servus!

        habe eine Referenz auf den passenden Artikel im Blog eingefügt.

        Herzliche Grüße

        Matthias Scharwies

        --
        Es gibt viel zu tun - packen wir's an: ToDo-Liste gewünschte Seiten
        1. problematische Seite

          Lieber Matthias,

          habe eine Referenz auf den passenden Artikel im Blog eingefügt.

          Vielen Dank! Diese <input type="submit">-Kiste hatte ich völlig vom Radar verloren. Stimmt, da fehlte noch etwas.

          Liebe Grüße,

          Felix Riesterer.

    4. Hej @@Felix Riesterer,

      In der Liste der Tutorials fehlt eines zur Formulargestaltung.

      OK, ich fange dann einmal damit an.

      Ich würde gerne daran mitarbeiten, ohne dir dazwischen zu funken. Meine Idee: ich mache Dir einen Vorschlag mit Formulierungsvorschlägen und Du übernimmst, was dir gefällt...

      Hast du daran Interesse?

      Marc

      1. Lieber marctrix,

        Ich würde gerne daran mitarbeiten, ohne dir dazwischen zu funken. Meine Idee: ich mache Dir einen Vorschlag mit Formulierungsvorschlägen und Du übernimmst, was dir gefällt...

        Deine bisherigen Änderungen haben alle eine deutliche sprachliche Verbesserung gebracht. Genau so soll es in einem Wiki ja sein. Bei didaktischen oder Artikel-strukruellen Änderungen kannst Du im Zweifel ja hier im Forum nachfragen, wenn Du meinst, dass es Diskussionsbedarf gibt.

        Hast du daran Interesse?

        Natürlich! Machen!

        Liebe Grüße,

        Felix Riesterer.

        1. Hej Felix,

          Lieber marctrix,

          Ich würde gerne daran mitarbeiten, ohne dir dazwischen zu funken. Meine Idee: ich mache Dir einen Vorschlag mit Formulierungsvorschlägen und Du übernimmst, was dir gefällt...

          Deine bisherigen Änderungen haben alle eine deutliche sprachliche Verbesserung gebracht.

          Danke für die Blumen - lektorieren ist immer leichter als texten ;-)

          Den folgenden Abschnitt verstehe ich nciht und da ich nciht programmiere, will ich den nicht selber bearbeiten. Der UNterschied der Buttons besteht doch nciht im namen, sondern im value - hat sich da ein Fehler eingeschlichen?

          Manchmal möchte man einem Benutzer zweierlei Aktionen anbieten und verwendet dafür zwei verschiedene Buttons. Will man dem Server sagen, ob man z.B. den "löschen"- oder stattdessen den "bearbeiten"-Button benutzt hat, kann man einem Button ebenso einen Namen geben, welcher dann bei Betätigung als Schlüssel an den Server übertragen wird.

          Marc

          1. Lieber marctrix,

            Den folgenden Abschnitt verstehe ich nciht und da ich nciht programmiere, will ich den nicht selber bearbeiten. Der UNterschied der Buttons besteht doch nciht im namen, sondern im value - hat sich da ein Fehler eingeschlichen?

            Manchmal möchte man einem Benutzer zweierlei Aktionen anbieten und verwendet dafür zwei verschiedene Buttons. Will man dem Server sagen, ob man z.B. den "löschen"- oder stattdessen den "bearbeiten"-Button benutzt hat, kann man einem Button ebenso einen Namen geben, welcher dann bei Betätigung als Schlüssel an den Server übertragen wird.

            der Server empfängt prinzipiell Schlüssel-Wert-Paare. Ich kann meine Programmlogik so erstellen, dass sie das bloße Vorhandensein eines Schlüssels erwartet. Dann würde ein unterschiedlicher Name bei den Buttons genügen. Möchte ich (vielleicht aus programmiererischer Bequemlichkeit) in meiner Logik eine Variable task nutzen, die ich bei Vorhandensein eines passend übertragenen Schlüssels mit dessen Wert versehe, dann hat es einen Sinn, ähnlich wie bei Radio-Buttons, einen identischen name-Wert zu verwenden, um dann unterschiedliche value-Werte zur Unterscheidung einzusetzen.

            Verstehst Du folgendes PHP-Beispiel?

            $task = 'overview'; // default
            
            // <button name="delete-button"> benutzt?
            if (array_key_exists('delete-button', $_POST)) {
                $task = 'delete';
            }
            
            // <button name="edit-button"> benutzt?
            if (array_key_exists('edit-button', $_POST)) {
                $task = 'edit';
            }
            
            // <button name="task" value="irgendwas"> benutzt?
            // (oder <input name="task" value="irgendwas"> vorhanden?)
            if (array_key_exists('task', $_POST)) {
                $task = $_POST['task'];
            }
            
            // basierend auf $task etwas tun
            switch ($task) {
                case 'delete':
                    delete_something();
                break;
            
                case 'edit':
                    edit_something();
                break;
            
                case 'overview':
                    show_overview();
                break;
            }
            

            Liebe Grüße,

            Felix Riesterer.

            1. Hej Felix,

              Den folgenden Abschnitt verstehe ich nciht und da ich nciht programmiere, will ich den nicht selber bearbeiten. Der UNterschied der Buttons besteht doch nciht im namen, sondern im value - hat sich da ein Fehler eingeschlichen?

              Manchmal möchte man einem Benutzer zweierlei Aktionen anbieten und verwendet dafür zwei verschiedene Buttons. Will man dem Server sagen, ob man z.B. den "löschen"- oder stattdessen den "bearbeiten"-Button benutzt hat, kann man einem Button ebenso einen Namen geben, welcher dann bei Betätigung als Schlüssel an den Server übertragen wird.

              der Server empfängt prinzipiell Schlüssel-Wert-Paare. Ich kann meine Programmlogik so erstellen, dass sie das bloße Vorhandensein eines Schlüssels erwartet. Dann würde ein unterschiedlicher Name bei den Buttons genügen. Möchte ich (vielleicht aus programmiererischer Bequemlichkeit) in meiner Logik eine Variable task nutzen, die ich bei Vorhandensein eines passend übertragenen Schlüssels mit dessen Wert versehe, dann hat es einen Sinn, ähnlich wie bei Radio-Buttons, einen identischen name-Wert zu verwenden, um dann unterschiedliche value-Werte zur Unterscheidung einzusetzen.

              Verstehst Du folgendes PHP-Beispiel?

              Ja, verstehen geht schon - wenn es simpel genug ist ;-)

              Ich habe mir auch gedacht, wodrauf du hnaus willst - es aber aus dem zitierten Text nicht entnehmen können...

              Davon mal ab:

              Grundsätzlich halte ich es aus Usability-Gründen nicht sinnvoll, mehrere Buttons optisch einem Formular zu zuzuordnen.

              Der Löschen-Button ist wirklich überhaupt keine gute Idee und sollte IMHO auch raus aus dem Beispiel (wenn er nur die gemachten Eingaben aus den Feldern zurücksetzen soll).

              Ich kann mir jetzt auf Anhieb auch kein Formular vorstellen, wo zusätzlich zu Eingabe-Feldern (mit denen Daten hinzugefügt werden) und einem Submit-Button, noch "Löschen" und "Bearbeiten" Sinn machen.

              Bearbeiten ginge noch, wenn ein Formular mit Daten aus der Datenbank vorausgefüllt wäre - was aber sehr gefährlich ist, da man leicht mal größere Mengen Text markieren und unbeabsichtigt löschen kann (um nur ein Beispiel zu nennen).

              Hast du denn ein konkretes Beispiel, wo es Sinn macht, mehrere Buttons in einem Formular anzubieten? Wenn es nur Formulare betrifft, die keine Eingabefelder haben, kann ich mir natürlich Buttons zum Bearbeiten oder Löschen vorstellen, braucht man ja ständig (wobei die dann vielleicht besser als Link mit entsprechenden Parametern realisiert werden?).

              Bin noch nciht ganz durch, aber was mir noch einfällt: aufSicherheitsaspekte sollte auf jeden Fall verlinkt werden! Gibt sicher schon einen Artikel dazu?!? - Habe noch nicht nachgeschaut.

              Marc

              1. Hallo marctrix,

                http://wiki.selfhtml.org/wiki/Formnovalidate#formnovalidate

                via mobile, deshalb kurz, nicht unhöflich gemeint

                Bis demnächst
                Matthias

                --
                Dieses Forum nutzt Markdown. Im Wiki erhalten Sie Hilfe bei der Formatierung Ihrer Beiträge.
                1. @@Matthias Apsel

                  via mobile, deshalb kurz, nicht unhöflich gemeint

                  Das sollte ich vielleicht in meine Signatur setzen?

                  Inzwischen ist „mobile“ meine häufigste Art, Postings zu schreiben.

                  LLAP 🖖

                  --
                  “You might believe there are benefits for the developer, but first of all, you should put those behind the interest of the user.” —Stefan Tilkov
                  Selfcode: sh:) fo:} ch:? rl:) br:> n4:& va:| de:> zu:} fl:{ ss:| ls:# js:|
                  1. Hallo Gunnar Bittersmann,

                    @@Matthias Apsel

                    via mobile, deshalb kurz, nicht unhöflich gemeint

                    Das sollte ich vielleicht in meine Signatur setzen?

                    Inzwischen ist „mobile“ meine häufigste Art, Postings zu schreiben.

                    Wenn man mobile mit Handy übersetzt, könnte deutlich werden, dass ich eine vollwertige Tastatur und eine Maus vermisse.

                    Bis demnächst
                    Matthias

                    --
                    Dieses Forum nutzt Markdown. Im Wiki erhalten Sie Hilfe bei der Formatierung Ihrer Beiträge.
                    1. Hej Matthias,

                      Hallo Gunnar Bittersmann,

                      @@Matthias Apsel

                      via mobile, deshalb kurz, nicht unhöflich gemeint

                      Inzwischen ist „mobile“ meine häufigste Art, Postings zu schreiben.

                      Wenn man mobile mit Handy übersetzt, könnte deutlich werden, dass ich eine vollwertige Tastatur und eine Maus vermisse.

                      Nimm doch nen Lappen ;-)

                      Marc

                    2. @@Matthias Apsel

                      Wenn man mobile mit Handy übersetzt, könnte deutlich werden, dass ich eine vollwertige Tastatur und eine Maus vermisse.

                      Desöfteren ist die virtuelle Tastatur eines Smartphones für mich vollwertiger als die eines Laptops/PCs.

                      Emojis mit iPhone eingeben: Tastatur umstellen, fertig. Beim Mac muss ich mir die aus der Zeichentabelle raussuchen.

                      Außerdem bieten Smartphones Spracheingabe, da muss man (bestenfalls) gar nicht mehr tippen. (Aber kontrollieren.)

                      Wenn man aber nicht möchte, dass Google auch diese Daten für sich zu klingender Münze macht, wird man dieses Feature auf Androids nicht nutzen. Aber warum hat man dann ein Android?

                      LLAP 🖖

                      --
                      “You might believe there are benefits for the developer, but first of all, you should put those behind the interest of the user.” —Stefan Tilkov
                      Selfcode: sh:) fo:} ch:? rl:) br:> n4:& va:| de:> zu:} fl:{ ss:| ls:# js:|
                      1. Hallo Gunnar,

                        Emojis mit iPhone eingeben: Tastatur umstellen, fertig. Beim Mac muss ich mir die aus der Zeichentabelle raussuchen.

                        Nö.

                        Außerdem bieten Smartphones Spracheingabe, da muss man (bestenfalls) gar nicht mehr tippen. (Aber kontrollieren.)

                        Bietet der Mac auch ;-)

                        Wenn man aber nicht möchte, dass Google auch diese Daten für sich zu klingender Münze macht, wird man dieses Feature auf Androids nicht nutzen.

                        Das gleiche gilt für das iPhone und Apple. Sei dir bewusst darüber, dass Apple das auch mitschneidet.

                        LG,
                        CK, iPhone-User

                        1. @@Christian Kruse

                          Wenn man aber nicht möchte, dass Google auch diese Daten für sich zu klingender Münze macht, wird man dieses Feature auf Androids nicht nutzen.

                          Das gleiche gilt für das iPhone und Apple. Sei dir bewusst darüber, dass Apple das auch mitschneidet.

                          Bin ich. Nur hat Apple wohl kein Interesse daran, die Daten an andere zu verkaufen.

                          “The question isn’t ‘can they spy on you if they want to?’ but rather ‘is it in their interests to spy on you?’
                          For Google, the answer is yes, it is in their direct financial interests to spy on you. Selling you is the primary means by which Google makes money.
                          For Apple, the answer is no, it is not in their direct financial interests to spy on you. Selling you products is how Apple makes money.”

                          —Arala Balkan, Apple vs Google on privacy: a tale of absolute competitive advantage

                          LLAP 🖖

                          --
                          “You might believe there are benefits for the developer, but first of all, you should put those behind the interest of the user.” —Stefan Tilkov
                          Selfcode: sh:) fo:} ch:? rl:) br:> n4:& va:| de:> zu:} fl:{ ss:| ls:# js:|
                          1. Hallo Gunnar,

                            Wenn man aber nicht möchte, dass Google auch diese Daten für sich zu klingender Münze macht, wird man dieses Feature auf Androids nicht nutzen.

                            Das gleiche gilt für das iPhone und Apple. Sei dir bewusst darüber, dass Apple das auch mitschneidet.

                            Bin ich. Nur hat Apple wohl kein Interesse daran, die Daten an andere zu verkaufen. [...]

                            Das zitierst du immer wieder. Das halte ich für einen Fehlschluss (iAd anyone?). Aber selbst wenn wir annehmen, dass Apple deine Daten nicht verkauft, dann heisst das nicht, dass das auch so bleibt. Als Jobs gestorben ist hat sich bei Apple auch so einigen geändert. Wer sagt, dass das nicht spätestens nach Cook auch passiert?

                            LG,
                            CK

                            1. @@Christian Kruse

                              Aber selbst wenn wir annehmen, dass Apple deine Daten nicht verkauft, dann heisst das nicht, dass das auch so bleibt.

                              Wie Aral endet:
                              “So riddle me this: if you have an absolute competitive advantage – if you have something that you can do that your competitors cannot – would you throw it away?
                              Only if you’re an idiot.
                              And something tells me Tim Cook isn’t an idiot.”

                              Als Jobs gestorben ist hat sich bei Apple auch so einigen geändert. Wer sagt, dass das nicht spätestens nach Cook auch passiert?

                              Irgendwas sagt mir, dass auch der nächste CEO kein Idiot sein wird. Garantien dafür gibt’s natürlich keine.

                              LLAP 🖖

                              --
                              “You might believe there are benefits for the developer, but first of all, you should put those behind the interest of the user.” —Stefan Tilkov
                              Selfcode: sh:) fo:} ch:? rl:) br:> n4:& va:| de:> zu:} fl:{ ss:| ls:# js:|
                              1. Hallo Gunnar,

                                Aber selbst wenn wir annehmen, dass Apple deine Daten nicht verkauft, dann heisst das nicht, dass das auch so bleibt.

                                Wie Aral endet:
                                “So riddle me this: if you have an absolute competitive advantage – if you have something that you can do that your competitors cannot – would you throw it away?
                                Only if you’re an idiot.
                                And something tells me Tim Cook isn’t an idiot.”

                                Weniger nachplappern, mehr selber denken. Ist das ein Marktvorteil? Androids Marktanteil in 2015 in Deutschland: 76%. Nur ein Fanboi kann glauben, dass Apple hier einen Marktvorteil hat. Nicht umsonst sagt Cook, dass das Wachstum begrenzt ist und sein Ende erreicht und sie mehr in Diensten machen wollen und müssen.

                                Dieser Schluss von deinem Aral ist ein Fehlschluss. Das hat auch die Praxis mehrfach gezeigt; Firmen, die als Werbeargument Privacy verwendet haben, verkauften die Daten als es finanziell schlecht aussah.

                                Ich will nicht sagen, dass Apple deine Daten verkauft, denn das weiss ich nicht. Ich halte zur Zeit beides für gleich wahrscheinlich. Aber ich halte es für hochgradig naiv zu glauben, dass sie das prinzipiell nicht tun würden. Du musst zwangsläufig davon ausgehen.

                                LG,
                                CK

                2. Hej Matthias,

                  Hallo marctrix,

                  http://wiki.selfhtml.org/wiki/Formnovalidate#formnovalidate

                  via mobile, deshalb kurz, nicht unhöflich gemeint

                  alles gut, vielen Dank für den Link!

                  Marc

              2. Hallo,

                Grundsätzlich halte ich es aus Usability-Gründen nicht sinnvoll, mehrere Buttons optisch einem Formular zu zuzuordnen.

                was meinst du mit optisch zuordnen (btw: 1x "zu" zu viel)? Ein Button ist durch seine Position im Markup dem Formular zugeordnet, also durch die Tatsache, dass er Nachfahre des form-Elements ist. Der optische Aspekt ist hierfür nicht relevant.

                Der Löschen-Button ist wirklich überhaupt keine gute Idee und sollte IMHO auch raus aus dem Beispiel (wenn er nur die gemachten Eingaben aus den Feldern zurücksetzen soll).

                ACK.

                Ich kann mir jetzt auf Anhieb auch kein Formular vorstellen, wo zusätzlich zu Eingabe-Feldern (mit denen Daten hinzugefügt werden) und einem Submit-Button, noch "Löschen" und "Bearbeiten" Sinn machen.

                Aber mehrere Buttons, die unterschiedliche Aktionen auslösen, sind allgemein gesehen durchaus sinnvoll. Ein Beispiel siehst du hier im Antwortformular: Vorschau und Speichern.

                Wenn es nur Formulare betrifft, die keine Eingabefelder haben, kann ich mir natürlich Buttons zum Bearbeiten oder Löschen vorstellen, braucht man ja ständig (wobei die dann vielleicht besser als Link mit entsprechenden Parametern realisiert werden?).

                Nein! Funktionen, die potentiell Daten verändern können, sollte man nie per Link (oder Formular mit der Methode GET) ansprechen. Dann hat nämlich ruck-zuck irgendein Bot deine Artikel gelöscht, weil er mal einem Link folgt.
                Derartige Aktionen sollten immer über einen POST-Request ausgelöst werden.

                So long,
                 Martin

                --
                Nothing travels faster than the speed of light with the possible exception of bad news, which obeys its own special laws.
                - Douglas Adams, The Hitchhiker's Guide To The Galaxy
                1. Hallo Martin,

                  Ich kann mir jetzt auf Anhieb auch kein Formular vorstellen, wo zusätzlich zu Eingabe-Feldern (mit denen Daten hinzugefügt werden) und einem Submit-Button, noch "Löschen" und "Bearbeiten" Sinn machen.

                  Aber mehrere Buttons, die unterschiedliche Aktionen auslösen, sind allgemein gesehen durchaus sinnvoll.

                  In aller Regel nicht.

                  Ein Beispiel siehst du hier im Antwortformular: Vorschau und Speichern.

                  Das ist nicht wirklich eine unterschiedliche Aktion; es wird nur ein Schritt weg gelassen (technisch). Aber selbst wenn man das so sehen möchte, ist das eine absolute Ausnahme, IMHO.

                  Derartige Aktionen sollten immer über einen POST-Request ausgelöst werden.

                  Oder PUT oder PATCH oder DELETE.

                  LG,
                  CK

                  1. Hallo,

                    Aber mehrere Buttons, die unterschiedliche Aktionen auslösen, sind allgemein gesehen durchaus sinnvoll.

                    In aller Regel nicht.

                    ich will mich nicht auf Zahlen festlegen, aber Formulare mit mehreren Buttons, die unterschiedliche Aktionen auslösen, sind zumindest so häufig, dass sie (mir) nicht als ungewöhnlich auffallen.

                    Derartige Aktionen sollten immer über einen POST-Request ausgelöst werden.

                    Oder PUT oder PATCH oder DELETE.

                    Nur dass ein gewöhnlicher Webserver üblicherweise so konfiguriert ist, dass er nur GET, POST und HEAD bearbeitet (und ein Browser idR nur GET und POST unterstützt) und die anderen mit Method Not Allowed oder Bad Request beantwortet. Btw, PATCH kenne ich noch gar nicht.

                    So long,
                     Martin

                    --
                    Nothing travels faster than the speed of light with the possible exception of bad news, which obeys its own special laws.
                    - Douglas Adams, The Hitchhiker's Guide To The Galaxy
                    1. Hallo Martin,

                      Aber mehrere Buttons, die unterschiedliche Aktionen auslösen, sind allgemein gesehen durchaus sinnvoll.

                      In aller Regel nicht.

                      ich will mich nicht auf Zahlen festlegen, aber Formulare mit mehreren Buttons, die unterschiedliche Aktionen auslösen, sind zumindest so häufig, dass sie (mir) nicht als ungewöhnlich auffallen.

                      Du schriebst „sinnvoll,“ nicht „gewöhnlich.“ Natürlich wird das verwendet, das macht es aber nicht besser.

                      Derartige Aktionen sollten immer über einen POST-Request ausgelöst werden.

                      Oder PUT oder PATCH oder DELETE.

                      Nur dass ein gewöhnlicher Webserver üblicherweise so konfiguriert ist, dass er nur GET, POST und HEAD bearbeitet

                      Nö, alle Webserver verarbeiten diese Methoden und stellen sie in der Umgebung als weitere Information zur Verfügung:

                      <?php
                      var_dump($_SERVER['REQUEST_METHOD']);
                      
                      → ckruse@sunshine ~  % curl -X DELETE http://localhost/test.php
                      string(6) "DELETE"
                      → ckruse@sunshine ~  % 
                      

                      Apache in Default-Konfiguration.

                      Ich vermute, du willst darauf hinaus, dass der Apache bei statischen Dokumenten alles andere als GET ablehnt.

                      (und ein Browser idR nur GET und POST unterstützt)

                      Das stimmt leider. Browser sind aber nicht die einziger Clients :-)

                      LG,
                      CK

                      1. Hallo,

                        Aber mehrere Buttons, die unterschiedliche Aktionen auslösen, sind allgemein gesehen durchaus sinnvoll.

                        In aller Regel nicht.

                        ich will mich nicht auf Zahlen festlegen, aber Formulare mit mehreren Buttons, die unterschiedliche Aktionen auslösen, sind zumindest so häufig, dass sie (mir) nicht als ungewöhnlich auffallen.

                        Du schriebst „sinnvoll,“ nicht „gewöhnlich.“ Natürlich wird das verwendet, das macht es aber nicht besser.

                        naja, wo's verwendet wird, kam es mir bisher auch durchaus sinnvoll vor.

                        Ich vermute, du willst darauf hinaus, dass der Apache bei statischen Dokumenten alles andere als GET ablehnt.

                        Nein, sondern darauf, dass beim Apache 2.0 (das war der letzte, bei dem ich mich noch intensiv mit der Konfiguration befasst habe) über die Limit-Direktive in der Default-Konfiguration ausdrücklich nur GET und POST zulässig waren.
                        Mir kam das damals auch sinnvoll vordamit eben nicht ein x-beliebiger Client Schindluder treiben kann. Mag sein, dass das mittlerweile anders ist, das weiß ich nicht.

                        So long,
                         Martin

                        --
                        Nothing travels faster than the speed of light with the possible exception of bad news, which obeys its own special laws.
                        - Douglas Adams, The Hitchhiker's Guide To The Galaxy
                        1. Hallo Martin,

                          Ich vermute, du willst darauf hinaus, dass der Apache bei statischen Dokumenten alles andere als GET ablehnt.

                          Nein, sondern darauf, dass beim Apache 2.0 (das war der letzte, bei dem ich mich noch intensiv mit der Konfiguration befasst habe) über die Limit-Direktive in der Default-Konfiguration ausdrücklich nur GET und POST zulässig waren.

                          Die Default-Konfiguration im Apache 2.0 verwendet kein Limit.

                          Mir kam das damals auch sinnvoll vordamit eben nicht ein x-beliebiger Client Schindluder treiben kann.

                          Kann er ja nicht. DAV-Ressourcen gibt es in der Default-Konfiguration auch nicht.

                          LG,
                          CK

                2. Hej Der Martin,

                  Erst mal dank für die Erklärungen!

                  Auch ich habe jetzt das Handy in der Hand und versuche, mich kurz fassen...

                  Grundsätzlich halte ich es aus Usability-Gründen nicht sinnvoll, mehrere Buttons optisch einem Formular zu zuzuordnen.

                  was meinst du mit optisch zuordnen (btw: 1x "zu" zu viel)? Ein Button ist durch seine Position im Markup dem Formular zugeordnet, also durch die Tatsache, dass er Nachfahre des form-Elements ist. Der optische Aspekt ist hierfür nicht relevant.

                  Jein. Wenn der Button nicht optisch zugeordnet werden muss (aus Gründen des Verständnisses), kann ich mir solche Button leichter sinnvoll vorstellen - sogar ganz viele davon. Neben jedem Datensatz, den man löschen oder bearbeiten kann jeweils einen. Aber ich könnte mir keine Beispiel vorstellen, wo man zusätzlich noch Eingabe-Felder benötigt. Das hat der Link von Matthias geändert ;-)

                  War eher ein theoretisches (Verständnis-) Problem.

                  Ich kann mir jetzt auf Anhieb auch kein Formular vorstellen, wo zusätzlich zu Eingabe-Feldern (mit denen Daten hinzugefügt werden) und einem Submit-Button, noch "Löschen" und "Bearbeiten" Sinn machen.

                  Aber mehrere Buttons, die unterschiedliche Aktionen auslösen, sind allgemein gesehen durchaus sinnvoll. Ein Beispiel siehst du hier im Antwortformular: Vorschau und Speichern.

                  Jo, dat stimmt. :-)

                  Wenn es nur Formulare betrifft, die keine Eingabefelder haben, kann ich mir natürlich Buttons zum Bearbeiten oder Löschen vorstellen, braucht man ja ständig (wobei die dann vielleicht besser als Link mit entsprechenden Parametern realisiert werden?).

                  Nein! Funktionen, die potentiell Daten verändern können, sollte man nie per Link (oder Formular mit der Methode GET) ansprechen. Dann hat nämlich ruck-zuck irgendein Bot deine Artikel gelöscht, weil er mal einem Link folgt.
                  Derartige Aktionen sollten immer über einen POST-Request ausgelöst werden.

                  Auch hier habe ich wieder einen Mangel al Fantasie: setzt man solche Buttons überhaupt außerhalb von geschlossenen Umgebungen ein? Ich würde so was nur nach einer Autentifizierung und nach Erwerb entsprechender Rechte durch die Autentifizierung verwenden...!?!

                  Marc

            2. Hallo Felix,

              $task = 'overview'; // default
              
              // <button name="delete-button"> benutzt?
              if (array_key_exists('delete-button', $_POST)) {
                  $task = 'delete';
              }
              
              // <button name="edit-button"> benutzt?
              if (array_key_exists('edit-button', $_POST)) {
                  $task = 'edit';
              }
              
              // <button name="task" value="irgendwas"> benutzt?
              // (oder <input name="task" value="irgendwas"> vorhanden?)
              if (array_key_exists('task', $_POST)) {
                  $task = $_POST['task'];
              }
              
              // basierend auf $task etwas tun
              switch ($task) {
                  case 'delete':
                      delete_something();
                  break;
              
                  case 'edit':
                      edit_something();
                  break;
              
                  case 'overview':
                      show_overview();
                  break;
              }
              

              Ich denke nicht, dass es eine gute Idee ist, so etwas in einem Artikel als Beispiel zu verwenden. Das ist ein ziemliches Anti-Pattern und so überhaupt nicht REST…

              LG,
              CK

              1. Hej Christian,

                [Beispiel von Felix]

                Ich denke nicht, dass es eine gute Idee ist, so etwas in einem Artikel als Beispiel zu verwenden. Das ist ein ziemliches Anti-Pattern und so überhaupt nicht REST…

                Ich denke das war nur als Erklärung für mich gedacht…

                Allerdings sollte @Felix Riesterer vielleicht mal darüber nachdenken, ob er mehrere absenden Button tatsächlich in einem Artikel erklären will, der sich nach seiner Aussage explizit an Anfänger richtet… ;-)

                Marc

                1. Hallo marctrix,

                  Allerdings sollte @Felix Riesterer

                  Erwähnungen funktionieren mit nur einem @. Das doppelte ist eine Marotte von @Gunnar Bittersmann. Damit meint er, Suchergebnisse verfeinern zu können ;-)

                  Bis demnächst
                  Matthias

                  --
                  Dieses Forum nutzt Markdown. Im Wiki erhalten Sie Hilfe bei der Formatierung Ihrer Beiträge.
                2. Lieber marctrix,

                  Ich denke das war nur als Erklärung für mich gedacht…

                  richtig.

                  Liebe Grüße,

                  Felix Riesterer.

              2. Lieber Christian,

                Ich denke nicht, dass es eine gute Idee ist, so etwas in einem Artikel als Beispiel zu verwenden.

                darum ist es auch nicht enthalten. Dieses Beispiel hat sich ausschließlich im Kontext der hiesigen Diskussion als Erklärungsmodell ergeben.

                Das ist ein ziemliches Anti-Pattern und so überhaupt nicht REST…

                Und das sollte mich genau warum kümmern? Warum sollte ich (analog zu <label> in <form>) grundsätzlich REST-fähig schreiben?

                Liebe Grüße,

                Felix Riesterer.

                1. Hallo Felix,

                  Und das sollte mich genau warum kümmern? Warum sollte ich (analog zu <label> in <form>) grundsätzlich REST-fähig schreiben?

                  Mach, was du willst.

                  LG,
                  CK

                2. Nachtrag

                  Und das sollte mich genau warum kümmern? Warum sollte ich [...]

                  das war jetzt vielleicht agressiv (im Sinne von provozierend formuliert), war aber als ehrliches Interesse gemeint.

                  Liebe Grüße,

                  Felix Riesterer.

                  1. Hallo Felix,

                    Und das sollte mich genau warum kümmern? Warum sollte ich [...]

                    das war jetzt vielleicht agressiv (im Sinne von provozierend formuliert), war aber als ehrliches Interesse gemeint.

                    Es hat sich gezeigt, dass bestimmte Patterns problematisch sind, weil sie entweder den Grundprinzipien des Webs widersprechen oder sich als schwer wartbar erwiesen haben. Das „wir schicken alles via POST an eine Resource und entscheiden dann, was getan wird“ ist eins davon; das wurde bei den SOAP-Java-Webservices der frühen 2000er bis zum Exzess getrieben. REST-ful hat sich in dieser Hinsicht als überlegen erwiesen. Eine Kombination aus Request Method und URL mappt auf eine Aktion; das führt zu kleineren und weniger komplexen Methoden, zu einem saubererem Interface nach außen und damit insgesamt zu besser wartbarem Code.

                    LG,
                    CK

                    1. Lieber Christian,

                      oder sich als schwer wartbar erwiesen haben.

                      dieses trifft wohl auf mein Beispiel zu. Habe ich das richtig verstanden? Denn einem Grundprinzip des Web widersprechend erkenne ich dann doch nicht darin.

                      Das „wir schicken alles via POST an eine Resource und entscheiden dann, was getan wird“ ist eins davon; das wurde bei den SOAP-Java-Webservices der frühen 2000er bis zum Exzess getrieben.

                      Das finde ich per se nicht einmal schlimm. Auch mein CMS hat genau eine URL, von der aus die gesamte Administration geregelt wird - nur das Editieren von Seiten erfordert einen per GET übertragenen Parameter. Der Rest geschieht per POST.

                      REST-ful hat sich in dieser Hinsicht als überlegen erwiesen. Eine Kombination aus Request Method und URL mappt auf eine Aktion; das führt zu kleineren und weniger komplexen Methoden, zu einem saubererem Interface nach außen und damit insgesamt zu besser wartbarem Code.

                      Aha. Das habe ich zwar inhaltlich verstanden, sehe aber noch keinen Praxisbezug darin. Hast Du Beispiel-URLs, die das veranschaulichen könnten? Geht das in diese Richtung?

                      • https://example.org/admin/user/delete/12345/
                      • https://example.org/admin/user/edit/12345/
                      • https://example.org/admin/user/new/12345/

                      Liebe Grüße,

                      Felix Riesterer.

                      1. Hallo Felix,

                        oder sich als schwer wartbar erwiesen haben.

                        dieses trifft wohl auf mein Beispiel zu. Habe ich das richtig verstanden? Denn einem Grundprinzip des Web widersprechend erkenne ich dann doch nicht darin.

                        Ein Grundprinzip des Webs ist es, dass hinter einer URL sich eine Resource befindet. Dieses Prinzip weichst du auf, wenn du hinter einer URL n>1 Aktionen ausführen kannst.

                        Das „wir schicken alles via POST an eine Resource und entscheiden dann, was getan wird“ ist eins davon; das wurde bei den SOAP-Java-Webservices der frühen 2000er bis zum Exzess getrieben.

                        Das finde ich per se nicht einmal schlimm.

                        Es hat sich als problematisch erwiesen in Punkto Wartbarkeit und Komplexität. Außerdem ist es nicht besonders semantisch.

                        REST-ful hat sich in dieser Hinsicht als überlegen erwiesen. Eine Kombination aus Request Method und URL mappt auf eine Aktion; das führt zu kleineren und weniger komplexen Methoden, zu einem saubererem Interface nach außen und damit insgesamt zu besser wartbarem Code.

                        Aha. Das habe ich zwar inhaltlich verstanden, sehe aber noch keinen Praxisbezug darin. Hast Du Beispiel-URLs, die das veranschaulichen könnten? Geht das in diese Richtung?

                        • https://example.org/admin/user/delete/12345/
                        • https://example.org/admin/user/edit/12345/
                        • https://example.org/admin/user/new/12345/

                        Der REST-Weg für eine User-Verwaltung wären folgende URLs:

                        • GET https://example.org/users für den Index/die User-Liste
                        • GET https://example.org/users/1 zur Betrachtung eines einzelnen Users
                        • GET https://example.org/users/1/edit um das Formular zum Bearbeiten eines Users aufzurufen
                        • POST https://example.org/users um einen User tatsächlich auch anzulegen
                        • PATCH https://example.org/users/1 oder PUT https://example.org/users/1 um einen User zu verändern
                        • DELETE https://example.org/users/1 um einen User zu löschen

                        Solange die Browser noch keine anderen Methoden als GET oder POST können werden die anderen Methoden simuliert mit einem POST-Request und einer Art, die wahre Methode zu identifizieren; manche verwenden dazu einen request parameter _method (z.B. Rails), manche verwenden URL-Suffixe wie ;put.

                        Schau dir ansonsten mal die URLs dieses Forums an, die halten sich weitestgehend an das REST-Prinzip.

                        Das ist halt wie mit semantischem Markup. Muss man nicht, sollte man aber. Macht mans nicht, hat man Nachteile.

                        LG,
                        CK

                        1. Lieber Christian,

                          Danke! Wieder etwas dazu gelernt. :-)

                          Liebe Grüße,

                          Felix Riesterer.

                        2. Hallo Christian,

                          Der REST-Weg für eine User-Verwaltung wären folgende URLs:

                          • GET https://example.org/users für den Index/die User-Liste
                          • GET https://example.org/users/1 zur Betrachtung eines einzelnen Users
                          • GET https://example.org/users/1/edit um das Formular zum Bearbeiten eines Users aufzurufen
                          • POST https://example.org/users um einen User tatsächlich auch anzulegen
                          • PATCH https://example.org/users/1 oder PUT https://example.org/users/1 um einen User zu verändern
                          • DELETE https://example.org/users/1 um einen User zu löschen

                          Vergessen:

                          • GET https://example.org/users/new um das Formular zum anlegen eines neuen Users anzuzeigen.

                          LG,
                          CK

                          1. Lieber Christian,

                            • GET https://example.org/users/new um das Formular zum anlegen eines neuen Users anzuzeigen.

                            aber das widerspricht ja dem restlichen Schema! Unter dieser URL erwarte ich die Datenansicht (konkret eine Meldung, dass es diesen User noch nicht gibt) des neuen Users, der dann mit

                            • GET https://example.org/users/new/edit

                            bearbeitet werden kann, analog zu

                            • GET https://example.org/users/1/edit um das Formular zum Bearbeiten eines Users aufzurufen

                            Oder findest Du das zusehr konsequent?

                            Liebe Grüße,

                            Felix Riesterer.

                            1. Hallo Felix,

                              • GET https://example.org/users/new um das Formular zum anlegen eines neuen Users anzuzeigen.

                              aber das widerspricht ja dem restlichen Schema! Unter dieser URL erwarte ich die Datenansicht (konkret eine Meldung, dass es diesen User noch nicht gibt) des neuen Users, der dann mit [...]

                              /edit und /new sind Spezialfälle, die der Notwendigkeit geschuldet sind, dass man URLs braucht, um diese Ressourcen anzufragen. Streng genommen müsste /users/:id/edit ja auch eine Sub-Resource des Users sein (etwa wie hier die Nachrichten bei Threads). Ist es aber nicht wirklich.

                              Oder findest Du das zusehr konsequent?

                              Natürlich bilden sie einen Kompromiss. Aber mit der reinen Le(e|h)re hat noch keiner eine Software fertig bekommen ;-)

                              LG,
                              CK

  2. problematische Seite

    Lieber Matthias,

    Es wäre schön, wenn hier ein Leitfaden entstehen könnte, der zeigt, wie man ein einfaches Formular aufbaut, … (und die Daten schließlich entgegennimmt?)

    ja, das mit dem Entgegennehmen habe ich jetzt noch ergänzt. Der "Formularmonat Mai" sollte damit ausreichend vollständig sein.

    Liebe Grüße,

    Felix Riesterer.

    1. problematische Seite

      Servus!

      Lieber Matthias,

      Es wäre schön, wenn hier ein Leitfaden entstehen könnte, der zeigt, wie man ein einfaches Formular aufbaut, … (und die Daten schließlich entgegennimmt?)

      ja, das mit dem Entgegennehmen habe ich jetzt noch ergänzt. Der "Formularmonat Mai" sollte damit ausreichend vollständig sein.

      Vielen Dank für deine hochwertigen und anschaulichen Artikel. Da ist ja ganz schön was zusammengekommen.

      Herzliche Grüße

      Matthias Scharwies

      --
      Es gibt viel zu tun - packen wir's an: ToDo-Liste gewünschte Seiten
      1. problematische Seite

        Lieber Matthias,

        Vielen Dank für deine hochwertigen und anschaulichen Artikel. Da ist ja ganz schön was zusammengekommen.

        danke für Dein üppiges Lob!

        Liebe Grüße,

        Felix Riesterer.

        1. problematische Seite

          Hallo Felix Riesterer,

          danke für Dein üppiges Lob!

          Von mir gibts mindestens genauso viel :-)

          Bis demnächst
          Matthias

          --
          Dieses Forum nutzt Markdown. Im Wiki erhalten Sie Hilfe bei der Formatierung Ihrer Beiträge.
        2. problematische Seite

          Hej Felix,

          Lieber Matthias,

          Vielen Dank für deine hochwertigen und anschaulichen Artikel. Da ist ja ganz schön was zusammengekommen.

          danke für Dein üppiges Lob!

          Danke, dass deinen Geist du gibst... ;-)

          Marc