Linktipp: Die 10 häufigsten Webdesign-Fehler des Jahres 2005

[Heiner]

Hallo,

http://www.usability.ch/Alertbox/20051003.htm

Grüße
Heiner

[Ashura]

Hallo Heiner.

http://www.usability.ch/Alertbox/20051003.htm

Da war doch was...

Einen schönen Dienstag noch.

Gruß, Ashura

[flashnfantasy]

Wenn ich deinen Link im Opera aufrufe kriege ich folgendes:

"Opera has modified the JavaScript on www.usability.ch (Milonic fix). See browser.js for details."

Persönlich mag ich keine Designer-Seiten, die nur auf dem IE laufen.
Ist dür mich Webdesign-Fehler Nummer 11.

Gruß,
Flash

[Ashura]

Hallo flashnfantasy.

Persönlich mag ich keine Designer-Seiten, die nur auf dem IE laufen.

Persönlich mag ich keine Designer-Seiten, welche nur mit JS funktionieren.

Ist dür mich Webdesign-Fehler Nummer 11.

Obiges ist für mich Fehler Nummer 1, der Autor sollte sich mit dem Begriff „Zugänglichkeit“ befassen.

Dies werde ich ihm auch mitteilen.

Einen schönen Mittwoch noch.

Gruß, Ashura

[flashnfantasy]

Persönlich mag ich keine Designer-Seiten, welche nur mit JS funktionieren.

Wenn du den wahren Character eines Web-Designers erkennen will, dann gib ihm Javascript.

• Cbraham Linkeln

Auf JavaScript möchte ich nicht verzichten.
Und diese Seite nutzt sie ja wohl auch für die Drop-Down-Menüs.

Aber bei JS gilt ganz besonders, die Versuchung, damit Mist zu bauen ist sehr groß.

Gruß,
Mathias

[Der Martin]

Hallo Mathias,

Wenn du den wahren Character eines Web-Designers erkennen will, dann gib ihm Javascript.

• Cbraham Linkeln

Schreibfehler oder Absicht?  ;-)
  Abraham sprach zu Bebraham:
  Kann i mal dei Zebra ham?
  Weil Ashrahat mei Fahrrad hat.

Auf JavaScript möchte ich nicht verzichten.

Ich schon. Für Anwendungen mit einem genau überschaubaren Nutzerkreis und bekannten Randbedingungen (Intranet oder lokaler PC) finde ich den Einsatz in Ordnung. Aber "draußen im wilden Internet" lasse ich kein Javascript an meine Browser ran. Da wird leider viel zuviel Unsinn getrieben.

Aber bei JS gilt ganz besonders, die Versuchung, damit Mist zu bauen ist sehr groß.

Eben, und es zeigt sich immer wieder, dass der Anteil der Webautoren, der dieser Versuchung erliegt, leider sehr groß ist.
Das geht von harmlosen Nervensägen wie Bildertausch und Uhren, die am Mauszeiger kleben, bis hin zu Usability-Killern wie focus() & blur(), Ändern der Fenstergröße oder gar arglistiger Täuschung wie Manipulationen der Statuszeile. Wobei man einen Teil dieser Effekte in gängigen Browsern verhindern kann.

Ich stehe trotzdem auf dem Standpunkt, dass eine Webseite auch ohne JS vollständig "funktionieren" muss und verzichte gern mal bei einer Seite auf bestimmte Komfortmerkmale, wenn ich dafür auf zehn anderen Seiten von Störenfrieden verschont bleibe.

Schönen Tag noch,

Martin

[Richard Rüfenacht]

Hallo Ashura,

Obiges ist für mich Fehler Nummer 1, der Autor sollte sich mit dem Begriff „Zugänglichkeit“ befassen.
Dies werde ich ihm auch mitteilen.

zu der site gibt es auch noch andere Zugänge - ohne JavaScript und für Sehbehinderte

http://www.usability.ch/
http://www.usability.ch/Alt_nav/frameset.htm
http://www.usability.ch/D_Textonly/Ihverz_T.htm
http://www.usability.ch/Alt_nav/Alertbox/NJ_20051003.htm

mich würde deine Meinung dazu interessieren. Es handelt sich immerhin um einen Usability-Spezialisten. Mich stört, dass die Umstellung nur auf der Startseite möglich ist. Mal abgesehen von der unnötigen Verwenung von JavaScript für das Menü.

Beste Grüsse
Richard

[Ashura]

Hallo Richard.

zu der site gibt es auch noch andere Zugänge - ohne JavaScript und für Sehbehinderte

Ja, auf diese hat mich der Autor mittlerweile auch hingewiesen.
Die zugänglichen Versionen jedoch „nur“ als Alternativen anzubieten, ist in meinen Augen ebenso unsinnig.

http://www.usability.ch/

Wie bekannt; JS-Navigation, furchtbares Markup.
(Geringfügig strukturierende Elemente, ja.)

http://www.usability.ch/Alt_nav/frameset.htm

Ein Frameset. Ebenso problematisch, wenn auch nicht ganz so schlimm.

http://www.usability.ch/D_Textonly/Ihverz_T.htm

Diese wurde mir als Textversion angeboten.
Dass es sich faktisch hier eigentlich nur um die Navigation ohne target-Attribute handelt, ist hier offenbar nicht von Belang.

http://www.usability.ch/Alt_nav/Alertbox/NJ_20051003.htm

Hier drängt sich mir der Verdacht auf, dass es sich lediglich um eine überflüssige Druckversion handelt.

Mich stört, dass die Umstellung nur auf der Startseite möglich ist.

Ganz Recht. Mich stört, dass eine Umstellung *überhaupt erforderlich* ist.
Was spricht dagegen, die gesamte Seite erst einmal sauber strukturiert und ohne CSS / JavaScript und Co. zu erstellen und erst *danach* diese beiden Faktoren *hinzuzufügen*.
Damit könnte eine enorme Verbesserung der Zugänglichkeit erzielt werden.
Bedauerlicherweise ist den wenigsten bewusst, dass diese Punkte bereits bei der erstmaligen Planung einfließen sollten.
Damit könnte man sich auch später größere Umstellungsarbeiten ersparen beziehungsweise erleichtern.

Mal abgesehen von der unnötigen Verwenung von JavaScript für das Menü.

Das wohl derzeitig größte Manko.

Ich habe den Autor auf die Mängel bzgl. Navigation und Struktur hingewiesen und ihn auch auf die WAI aufmerksam gemacht.
Dass sich niemand daran halten *muss* sollte klar sein.
Doch wenn es lediglich einen kleinen Aufwand bedeutet, HTML-Dokumente für eine weitreichendere Benutzergruppe zugänglich zu machen, ist dieser aus meiner Sicht in allen Belangen vertretbar.
Einmal abgesehen davon, dass diese Denkweise dem ursprünglichen Gedanken des WWW entgegen kommt, dürften auch Unternehmen davon profitieren, wenn mehr potentielle Kunden die Möglichkeit erhalten, auf ihre Internetpräsenz in vollem Umfang zuzugreifen.
Zugänglichere Zweitversionen bereits bestehender HTML-Dokumente versuchen lediglich, die Symptome zu beseitigen.
Die Ursachen könnten jedoch gleich beseitigt werden, indem *von Anfang an* eine wohl durchdachte Planung vollzogen wird.

Einen schönen Mittwoch noch.

Gruß, Ashura

[Ingo Turski]

Hi,

Die zugänglichen Versionen jedoch „nur“ als Alternativen anzubieten, ist in meinen Augen ebenso unsinnig.

ganz genau. Wenn ich z.B. über google auf eine Seite komme, dann will ich bestimmt nicht erst auf die Suche nach einer für mich zugänglichen Seite gehen. Und wenn es sich gar um eine Seite von einem "Institut für Software-Ergonomie und Usability" handelt, dann erwarte ich hier *volle* Usability natürlich erst recht. Zumindest erwarte ich eine Navigation und nicht, daß ich manuell in der Adreßleiste den Seitenpfad weglöschen muß, um zur Startseite zu kommen und hier diese merkwürdigen alternativen Zugänge zu sehen. Die einzigen Links auf den Seiten sind die winzigen zum Disclaimer und zur AGB im Footer.

Ich habe den Autor auf die Mängel bzgl. Navigation und Struktur hingewiesen und ihn auch auf die WAI aufmerksam gemacht.
Dass sich niemand daran halten *muss* sollte klar sein.

Nunja, von einem Usability-Institut würde ich das schon erwarten. Wenn dies eine neue Seite der deutschen Bundesregierung wäre, dürfte die so gar nicht veröffentlcht werden.

Davon abgesehen ist auch der Quellcode grausig und im Stil nicht weit von Frontpage entfernt.

freundliche Grüße
Ingo

[Richard Rüfenacht]

Hallo Ashura,

Die zugänglichen Versionen jedoch „nur“ als Alternativen anzubieten, ist in meinen Augen ebenso unsinnig.

Ja, sehe ich natürlich auch so. Ausgeschaltetes JavaScript ist in der Praxis aber auch noch eher selten und die site deshalb überwiegend zugänglich. Mir ist mehr der Hinweistext auf die Sicherheit aufgefallen. Mein Gedankengang bezog sich aber eigentlich gar nicht konkret auf diese site, sondern auf ein generelles Problem von mir. Es geht um sehr komplexes eLearning bei dem JavaScript sehr wichtige Funktionen hat. Wenn ich nun auf jemand treffe, der JavaScript aus Sicherheit- oder sonstigen Gründen ausgeschaltet hat, muss ich erklären, was dadurch verloren geht und die Gründe für den Einsatz von JavaScript erklären.

Wie bekannt; JS-Navigation, furchtbares Markup.
(Geringfügig strukturierende Elemente, ja.)
Ein Frameset. Ebenso problematisch, wenn auch nicht ganz so schlimm.

Bei deaktiviertem JavaScript kein Menü zu haben, mag in der Tat schlimmer sein, aber den Teufel mit dem Belzebub austreiben?

Diese wurde mir als Textversion angeboten.

Funktioniert im Original so nicht, ich habe den Pfad zum Frame kopiert, in der site erscheint der Text neben der Navigation.

Ganz Recht. Mich stört, dass eine Umstellung *überhaupt erforderlich* ist.

Ja, sicher. Vermutlich wurde diese Möglichkeit aber erst später eingefügt, als reklamiert wurde.

Was spricht dagegen, die gesamte Seite erst einmal sauber strukturiert und ohne CSS / JavaScript und Co. zu erstellen und erst *danach* diese beiden Faktoren *hinzuzufügen*.

Da juckt es mich doch tatsächlich an diversen Körperstellen. Reden wir von semantischem Markup? Ich beschäftige mich seit Jahren mit dem SCORM-Standard, da stammt die Idee nicht nur her, sondern ist auch weit konsequenter umgesetzt. Also ich möchte den Web-Entwickler sehen, der in der Lage ist, eine semantische Struktur zu erstellen ohne sich dabei eine Vorstellung vom Aussehen der site zu machen.

Bedauerlicherweise ist den wenigsten bewusst, dass diese Punkte bereits bei der erstmaligen Planung einfließen sollten.
Damit könnte man sich auch später größere Umstellungsarbeiten ersparen beziehungsweise erleichtern.

Da bin ich mit dir wieder vollkommen einer Meinung. Nur sind viele sites halt älteren Datums und dauernde Baustellen.

Doch wenn es lediglich einen kleinen Aufwand bedeutet, HTML-Dokumente für eine weitreichendere Benutzergruppe zugänglich zu machen, ist dieser aus meiner Sicht in allen Belangen vertretbar.

Der überwiegende Teil der HTML-Dokumente wird für genau bekannte Zielgruppen erstellt, die Anforderungen an die Zugänglichkeit sind damit bekannt. Es sollte niemand ausgeschlossen werden, das ist der entscheidenede Punkt und es sollten gezielt Möglichkeiten für Behinderte geschaffen werden.

Einmal abgesehen davon, dass diese Denkweise dem ursprünglichen Gedanken des WWW entgegen kommt,

Der ursprüngliche Gedanke des WWW war der schnelle und einfache Austausch wissenschaftlicher Arbeiten, ans Aussehen, an semantisches Markup und an Barrierefreiheit dachte da noch kein Mensch.

dürften auch Unternehmen davon profitieren, wenn mehr potentielle Kunden die Möglichkeit erhalten, auf ihre Internetpräsenz in vollem Umfang zuzugreifen.

Oder anders gesagt, wenn die denn schon auf die site zugreifen, sollten sie zuvorkommend behandelt werden.

Vielleicht interessiert dich diese Information: nächste Woche bin ich in Zürich im Technopark auf einer Ideenmesse über Think Tanks, möglich, dass es dabei so nebenbei zu einem Kontakt kommt mit der Firma, der die hier diskutierte site gehört. Spezialthema ist übrigens: «Deutschland nach der Wahl - die Rolle der Think Tanks»

Beste Grüsse
Richard

[Ashura]

Hallo Richard.

Ausgeschaltetes JavaScript ist in der Praxis aber auch noch eher selten und die site deshalb überwiegend zugänglich.

Das mag in den meisten Fällen zutreffen, aber sicher sein kann man sich eben nicht.
Und wenn mutwillig jemand ausgesperrt werden soll, kann man die Internetpräsenz gleich offline gehen lassen.

Es geht um sehr komplexes eLearning bei dem JavaScript sehr wichtige Funktionen hat.

Wobei geht es hierum? Beziehst du dich auf etwas Bestimmtes?

Wenn ich nun auf jemand treffe, der JavaScript aus Sicherheit- oder sonstigen Gründen ausgeschaltet hat, muss ich erklären, was dadurch verloren geht und die Gründe für den Einsatz von JavaScript erklären.

Nein, im Grunde musst du nichts erklären. Ist das Dokument in seiner Grundform ohne JS benutzbar, wird den aufgrund deaktiviertem / nicht vorhandenem JS eingeschränkt nutzbaren Seiten gewohnten Surfer alles weitere weniger interessieren. Wenn du dich dagegen auf zusätzliche Gimmicks beziehst, welche den Umgang mit dem Dokument vereinfacht, aber leider nur per JS verwirklicht werden konnte, ist der Surfer vielleicht eher bereit, JS einmal zuzulassen, sofern es zur Verfügung steht.

(Geringfügig strukturierende Elemente, ja.)
Ein Frameset. Ebenso problematisch, wenn auch nicht ganz so schlimm.

Bei deaktiviertem JavaScript kein Menü zu haben, mag in der Tat schlimmer sein, aber den Teufel mit dem Belzebub austreiben?

Keineswegs.
Aber wenn ich eine lediglich bei aktiviertem JS verfügbare Navigation einem Frameset gegenüber stelle, wovon jeder Frame einzeln durchaus abrufbar ist, dürfte ersichtlich sein, welches von diesen beiden das geringere Übel ist.

Sowohl JS als auch Framesets haben durchaus ihre Berechtigung und vielleicht sogar sinnvolle Anwendungsgebiete (JS kommt ja offenbar allmählich wieder in „Mode“), doch meist werden beide eingesetzt, weil schlicht und ergreifend die Kenntnis über bessere Techniken für den jeweiligen Anwendungsfall fehlt.

Reden wir von semantischem Markup?

Ich vermeide diesen Begriff gerne, da er im Grunde recht schwammig ist und oft frei ausgelegt wird.
Wenn ich mich auf einen Teil der Semantik beziehe, bezeichne ich ihn nach Möglichkeit auch direkt.

Ich beschäftige mich seit Jahren mit dem SCORM-Standard, da stammt die Idee nicht nur her, sondern ist auch weit konsequenter umgesetzt.

Ich habe eben einmal einen Blick darauf geworfen, da mir dies bisher kein Begriff war.
Vom Aufbau her erinnert mich SCORM an OASIS.
Irgendwas scheint da auch dran zu sein.

Also ich möchte den Web-Entwickler sehen, der in der Lage ist, eine semantische Struktur zu erstellen ohne sich dabei eine Vorstellung vom Aussehen der site zu machen.

Dies ist in der Tat ein schwieriges Unterfangen aber nicht grundsätzlich unmöglich. Ein gewisses Abstraktionsvermögen und eine gute Auffassungsgabe sollten gegeben sein.
Ich bemühe mich beim Erstellen von HTML-Dokumenten, diesem Wege zu folgen, kann aber nicht ausschließen, dass ich mich nicht doch hier und da von der späteren Optik mit leiten lasse.

Der überwiegende Teil der HTML-Dokumente wird für genau bekannte Zielgruppen erstellt, die Anforderungen an die Zugänglichkeit sind damit bekannt. Es sollte niemand ausgeschlossen werden, das ist der entscheidenede Punkt und es sollten gezielt Möglichkeiten für Behinderte geschaffen werden.

Warum eigentlich immer nur Behinderte?
Was ist mit Menschen ohne Einschränkungen, die dennoch mit vielen Internetpräsenzen nicht zu Recht kommen?
Man muss keine Verminderung der Sehfähigkeit haben, um auf Seiten mit 5px großer Schrift nichts zu erkennen; man muss auch nicht unter motorischen Störungen leiden, wenn sich wieder einmal jemand ein eindrucksvolles Aufklappmenü gebastelt hat, was nun einmal über keinen Toleranzbereich verfügt. Ebenso wenig muss man farbenblind sein, wenn auf einer Internetpräsenz denkbar ungünstige Farben gewählt wurden und damit kaum Kontrast zum Erfassen von Text existiert.
Ich persönlich beziehe meine Gedanken bezüglich Zugänglichkeit möglichst auf *alle Menschen*, ungeachtet dessen, ob sie an einer Behinderung leiden oder nicht.

Der ursprüngliche Gedanke des WWW war der schnelle und einfache Austausch wissenschaftlicher Arbeiten, ans Aussehen, an semantisches Markup und an Barrierefreiheit dachte da noch kein Mensch.

Ja, korrekt.
Ich bezog mich auf den Gedanken des freien Austausches von Informationen im WWW, welcher durch die Vermeidung von Barrieren erleichtert wird.

dürften auch Unternehmen davon profitieren, wenn mehr potentielle Kunden die Möglichkeit erhalten, auf ihre Internetpräsenz in vollem Umfang zuzugreifen.

Oder anders gesagt, wenn die denn schon auf die site zugreifen, sollten sie zuvorkommend behandelt werden.

Nein, warum? Sie sollten ebenso wie alle Anderen behandelt werden.
Wenn nun diese Benutzergruppe wiederum bevorzugt wird, kommen wir wieder da an, wo wir angefangen haben.
Die Internetpräsenzen sollten für Jederman gleichermaßen verfügbar und nutzbar gemacht werden. Dass dies bei zielgruppenorientierten Präsenzen nur schwerlich umsetzbar ist, bestreite ich nicht.
Dennoch sollten auch hier Möglichkeiten geboten werden, das Angebotene ohne die erwarteten technischen oder humanistischen Vorraussetzungen der Zielgruppe zu erreichen.

Vielleicht interessiert dich diese Information: nächste Woche bin ich in Zürich im Technopark auf einer Ideenmesse über Think Tanks, möglich, dass es dabei so nebenbei zu einem Kontakt kommt mit der Firma, der die hier diskutierte site gehört.

Diese Information finde ich in der Tat erwähnenswert, danke.
Du kannst ja vielleicht dann einmal berichten, wie es war.

Spezialthema ist übrigens: «Deutschland nach der Wahl - die Rolle der Think Tanks»

Bezüglich Verbesserungsvorschläge und Einflussnahme auf Entscheidungen in der Politk nehme ich an?

Einen schönen Donnerstag noch.

Gruß, Ashura

[Richard Rüfenacht]

Hallo Ashura,

Nein, im Grunde musst du nichts erklären. Ist das Dokument in seiner Grundform ohne JS benutzbar, wird den aufgrund deaktiviertem / nicht vorhandenem JS eingeschränkt nutzbaren Seiten gewohnten Surfer alles weitere weniger interessieren. Wenn du dich dagegen auf zusätzliche Gimmicks beziehst, welche den Umgang mit dem Dokument vereinfacht, aber leider nur per JS verwirklicht werden konnte, ist der Surfer vielleicht eher bereit, JS einmal zuzulassen, sofern es zur Verfügung steht.

Es geht um Alternativen zu einer bisher gängigen Praxis. Es existieren Dokumente mit Lerninhalten, die JavaScript-Funktionen nutzen (etwa Auswahlfragen mit Drag&Drop). Nun wird gesagt: "Um diese Dokumente nutzen zu können, muss auf Ihrem Computer JavaScript aktiviert sein." Wer das nicht will, kann in der vorgesehenen Weise nicht lernen. Punkt. Es war bisher offenbar kein Problem, könnte aber künftig eines werden.

Sowohl JS als auch Framesets haben durchaus ihre Berechtigung und vielleicht sogar sinnvolle Anwendungsgebiete (JS kommt ja offenbar allmählich wieder in „Mode“), doch meist werden beide eingesetzt, weil schlicht und ergreifend die Kenntnis über bessere Techniken für den jeweiligen Anwendungsfall fehlt.

Im eLearning-Bereich werden zur Erstellung von Inhalten meist spezielle Tools eingesetzt. JavaScript ist dabei neben diversen PlugIns nur ein Aspekt. Es ist ein kompliziertes Abwägen von sehr verschiedenen Möglichkeiten unter Zeit-, Technik- und Kostenaspekten. Es wäre schön, zu Lösungen zu kommen, die clientseitig nur einen beliebigen Browser mit höchsten Sicherheitseinstellungen voraussetzen und den Rest serverseitig erledigen.

Reden wir von semantischem Markup?
Ich vermeide diesen Begriff gerne, da er im Grunde recht schwammig ist und oft frei ausgelegt wird.

Gut, es ist ein Modebegriff, der vielleicht bald durch einen anderen abgelöst wird. Der Sachverhalt bleibt aber bestehen und ist technisch eigentlich auch klar, in bestimmter Hinsicht jedenfalls. Schwammig wirkt er deshalb, weil eine Trennung von etwas verlangt wird, was das menschliche Gehirn nicht trennen kann. Kein Mensch kann sich die Semantik eines h1 Elementes vorstellen ohne an eine Überschrift mit konkretem Aussehen zu denken.

Vom Aufbau her erinnert mich SCORM an OASIS.
Irgendwas scheint da auch dran zu sein.

Oder umgekehrt ;-) Oasis beschreibt eine Vielzahl von Standards, SCORM ist einer davon. SCORM hat eine gewaltige wirtschaftliche Bedeutung, eLearning-Inhalte, die nicht SCORM kompatibel sind, sind unverkäuflich. Mit SCORM soll sicher gestellt werden, dass die mit unterschiedlichsten Techniken erstellten Lernmodule auf allen Lernplattformen einsetzbar sind und zu einheitlichen Kursen zusammengefügt werden können. Wenn du etwa einen Kurs in Bionik absolvieren willst, können die einzelnen Lernmodule von verschiedenen Autoren erstellt sein, auf verschiedenen Servern lagern, unterschiedliche Techniken benutzen und du hast auf deinem Useragent trotzdem den Eindruck eines in sich geschlossenen, logisch aufgebauten Kurses.

Warum eigentlich immer nur Behinderte?
Was ist mit Menschen ohne Einschränkungen, die dennoch mit vielen Internetpräsenzen nicht zu Recht kommen?
Ich persönlich beziehe meine Gedanken bezüglich Zugänglichkeit möglichst auf *alle Menschen*, ungeachtet dessen, ob sie an einer Behinderung leiden oder nicht.

Habe ich als selbstverständlich unterstellt. Auf Behinderte sollte aber darüber hinaus Rücksicht genommen werden.

Oder anders gesagt, wenn die denn schon auf die site zugreifen, sollten sie zuvorkommend behandelt werden.
Nein, warum? Sie sollten ebenso wie alle Anderen behandelt werden.

Nicht anders, sondern geich gut ;-)

Die Internetpräsenzen sollten für Jederman gleichermaßen verfügbar und nutzbar gemacht werden.

Nur wenn dies auch Sinn und Zweck der Internetpräsenz ist. Der Punkt ist ideologisch ziemlich kompliziert.

Spezialthema ist übrigens: «Deutschland nach der Wahl - die Rolle der Think Tanks»
Bezüglich Verbesserungsvorschläge und Einflussnahme auf Entscheidungen in der Politk nehme ich an?

Ich lass mich da einfach mal überraschen, den genauen Inhalt kenne ich nicht. Bei Think Tanks geht es mehr um Visionen, Ideen und das Aufzeigen von Möglichkeiten, als um konkrete Vorschläge und direkte Einflussnahme.

Beste Grüsse
Richard

[Ashura]

Hallo Richard.

Es geht um Alternativen zu einer bisher gängigen Praxis. Es existieren Dokumente mit Lerninhalten, die JavaScript-Funktionen nutzen (etwa Auswahlfragen mit Drag&Drop). Nun wird gesagt: "Um diese Dokumente nutzen zu können, muss auf Ihrem Computer JavaScript aktiviert sein." Wer das nicht will, kann in der vorgesehenen Weise nicht lernen. Punkt.

Wenn er JS aber mutmaßlich nicht aktivieren *will* aber die Option besteht, dann dürfte es ihn auch nicht stören, dass die Funktionen, die explizit JS benötigen, ihm nicht zur Verfügung stehen.

Es war bisher offenbar kein Problem, könnte aber künftig eines werden.

Weshalb? Soll die Nutzergruppe erweitert werden?

Es ist ein kompliziertes Abwägen von sehr verschiedenen Möglichkeiten unter Zeit-, Technik- und Kostenaspekten.

Besonders Ersteres und Letzteres haben meist leider das letzte Wort, weshalb oft suboptimale Lösungen heraus kommen.

Es wäre schön, zu Lösungen zu kommen, die clientseitig nur einen beliebigen Browser mit höchsten Sicherheitseinstellungen voraussetzen und den Rest serverseitig erledigen.

Höchste Sicherheitseinstellungen sind im Grunde doch gar nicht erforderlich sondern eigentlich nur ein Versuch, unbedarfte Nutzer vor folgenschweren Fehlern zu bewahren. (Siehe Vogelkäfig.)
Was du hier beschreibst, klingt für mich aber ein wenig nach AJAX. Hiermit erhält JS auch endlich einmal die Aufmerksamkeit, die ihm zusteht, nachdem es so lange ein Schattendasein als Klickibunti-Scriptkiddie-Sprache fristete.

[Begriff „Semantisches Markup“]

Schwammig wirkt er deshalb, weil eine Trennung von etwas verlangt wird, was das menschliche Gehirn nicht trennen kann. Kein Mensch kann sich die Semantik eines h1 Elementes vorstellen ohne an eine Überschrift mit konkretem Aussehen zu denken.

Auch Absolutismus vermeide ich gerne.
Ich schließe keinesfalls aus, dass es auf dieser Welt  Menschen gibt, die über das nötige Abstraktionsvermögen verfügen, um das von dir Beschriebene zu leisten.

Vom Aufbau her erinnert mich SCORM an OASIS.
Irgendwas scheint da auch dran zu sein.

Oder umgekehrt ;-)

Ja, natürlich.

SCORM hat eine gewaltige wirtschaftliche Bedeutung, eLearning-Inhalte, die nicht SCORM kompatibel sind, sind unverkäuflich.

Mich wundert, dass ich bisher noch nie etwas davon gelesen / gehört habe.

Mit SCORM soll sicher gestellt werden, dass die mit unterschiedlichsten Techniken erstellten Lernmodule auf allen Lernplattformen einsetzbar sind und zu einheitlichen Kursen zusammengefügt werden können. Wenn du etwa einen Kurs in Bionik absolvieren willst, können die einzelnen Lernmodule von verschiedenen Autoren erstellt sein, auf verschiedenen Servern lagern, unterschiedliche Techniken benutzen und du hast auf deinem Useragent trotzdem den Eindruck eines in sich geschlossenen, logisch aufgebauten Kurses.

Ein bemerkenswertes und positiv anzumerkendes Vorhaben.
Wenn sich dies nur auf Schulen verbreiten würde...

Auf Behinderte sollte aber darüber hinaus Rücksicht genommen werden.

Wenn die Möglichkeit besteht, natürlich.

Die Internetpräsenzen sollten für Jederman gleichermaßen verfügbar und nutzbar gemacht werden.

Nur wenn dies auch Sinn und Zweck der Internetpräsenz ist. Der Punkt ist ideologisch ziemlich kompliziert.

Ja, richtig. Der Autor muss schon einen gewissen Eindruck von Zugänglichkeit haben und eigenständig Intentionen hegen, diesbezüglich Modifikationen vorzunehmen.
Wären der Zeit- und der Kostenfaktor nicht vorhanden, wären sicher auch weitaus mehr Unternehmen bereit, in dieser Hinsicht zu arbeiten.

Ich lass mich da einfach mal überraschen, den genauen Inhalt kenne ich nicht. Bei Think Tanks geht es mehr um Visionen, Ideen und das Aufzeigen von Möglichkeiten, als um konkrete Vorschläge und direkte Einflussnahme.

Ah, also eher passiver Natur mit Beratungsfunktion.
Wenn etwas Nützliches dabei heraus kommt, gerne.

Einen schönen Donnerstag noch.

Gruß, Ashura

[Richard Rüfenacht]

Hallo Ashura,

Wenn er JS aber mutmaßlich nicht aktivieren *will* aber die Option besteht, dann dürfte es ihn auch nicht stören, dass die Funktionen, die explizit JS benötigen, ihm nicht zur Verfügung stehen.

Die Kurse sind dann insgesamt nicht nutzbar, JavaScript steuert die zentralen Lernfunktionen. Ein Student kann einen Pflichtkurs nicht per eLearning belegen, ein AZUBI (bei uns immer noch Lehrling), kann Teile der Berufsschule nicht erfüllen, Fernlehrgänge können trotz Bezahlung nicht richtig genutzt werden ...

Es war bisher offenbar kein Problem, könnte aber künftig eines werden.
Weshalb? Soll die Nutzergruppe erweitert werden?

Die Frage ist doch, was passiert, wenn immer mehr Leute JavaScript deaktivieren? Bis jetzt ist das eigentlich nur im SELF-Raum ein Thema, könnte sich aber ausbreiten ;-) Ein AZUBI, der sich weigert, auf seinem PC JavaScript zu aktivieren, kann keinen Lehrabschluss machen, das sollte doch einfach mal bedacht werden.

[Begriff „Semantisches Markup“]
Schwammig wirkt er deshalb, weil eine Trennung von etwas verlangt wird, was das menschliche Gehirn nicht trennen kann. Kein Mensch kann sich die Semantik eines h1 Elementes vorstellen ohne an eine Überschrift mit konkretem Aussehen zu denken.
Auch Absolutismus vermeide ich gerne.
Ich schließe keinesfalls aus, dass es auf dieser Welt  Menschen gibt, die über das nötige Abstraktionsvermögen verfügen, um das von dir Beschriebene zu leisten.

Nur würde dabei das h1-Element seine Semantik verlieren und zur reinen Syntax degenerieren, Semantik wohnt dem Element nämlich nicht inne, sondern kommt durch den Gebrauch hinzu. Bevor ein h-Element notiert werden kann, muss bereits die Vorstellung von einer Überschrift vorhanden sein. Jedenfalls wenn es sinnvoll eingesetzt werden soll, und wenn es nicht sinnvoll eingesetzt wird, handelt es sich ja nicht um semantisches Markup.

Verwirrend und unklar wirkt der Begriff semantisches Markup doch nur, weil vielfach mit Begriffen operiert wird, die im normalen Sprachgebrauch andere Bedeutungen haben. Layout ist alltagssprachlich ein Entwurf für ein Design, nicht für eine Struktur. Für die Darstellung sei ausschließlich CSS da, greift zu weit. Auf der Ebene des Codes ist eine klare Trennung möglich, in HTML wird festgelegt, hier ist eine Überschrift, hier ein Text, hier ein Bild, im CSS wird bestimmt, wie diese aussehen sollen. Aber eine Überschrift, ein Text oder ein Bild können ja nicht etwas beliebiges sein, diese Begriffe bedeuten etwas, daher stammt doch die Semantik für das Markup.

SCORM hat eine gewaltige wirtschaftliche Bedeutung, eLearning-Inhalte, die nicht SCORM kompatibel sind, sind unverkäuflich.
Mich wundert, dass ich bisher noch nie etwas davon gelesen / gehört habe.

Ist ja auch nicht eine Angelegenheit des Webdesign. Falls es dich interessiert, hier findest du die aktuelle SCORM Dokumentation.

Mit SCORM soll sicher gestellt werden, dass [...]
Ein bemerkenswertes und positiv anzumerkendes Vorhaben.

Dies ist längst nicht mehr nur ein Vorhaben, es ist in weiten Teilen Realität. Es gibt Hochschulen, bei denen bereits über 30% des Ausbildungsbetriebs so abläuft. In vielen Unternehmen ist Online-Lernen längst wichtiger als traditionelle Seminare.

Wenn sich dies nur auf Schulen verbreiten würde...

Oooch ... die armen Lehrer ;-) ... denen wollen wir doch nicht beweisen, dass so ein strohdummer Computer besser unterrichtet als sie. Schliesslich gibt es keine unfähigen Lehrer, sondern nur dumme Schüler ... oder habe ich da was verwechselt?

Mit besten Grüssen
Richard

[Ashura]

Hallo Richard.

Die Kurse sind dann insgesamt nicht nutzbar, JavaScript steuert die zentralen Lernfunktionen. Ein Student kann einen Pflichtkurs nicht per eLearning belegen, ein AZUBI (bei uns immer noch Lehrling), kann Teile der Berufsschule nicht erfüllen, Fernlehrgänge können trotz Bezahlung nicht richtig genutzt werden ...

Natürlich. Wie gesagt ist sich der Lehrling dessen sicher bewusst, schließlich war es seine Entscheidung, JS nicht nutzen zu wollen, obgleich ihm bewusst war, dass es erforderlich ist.

Die Frage ist doch, was passiert, wenn immer mehr Leute JavaScript deaktivieren?

Dann wird JS wohl oder übel niemals das zu leisten vermögen, was ihm zusteht.

Ein AZUBI, der sich weigert, auf seinem PC JavaScript zu aktivieren, kann keinen Lehrabschluss machen, das sollte doch einfach mal bedacht werden.

Das sollte *er* bedenken, ja.

Nur würde dabei das h1-Element seine Semantik verlieren und zur reinen Syntax degenerieren, Semantik wohnt dem Element nämlich nicht inne, sondern kommt durch den Gebrauch hinzu.

Wir bewegen uns wieder in Richtung einer müßigen Diskussion, welche im Forenarchiv schon recht ausgiebig festgehalten ist.
Allgemein: ich stimme dir zu, dass die Semantik von Menschen für Menschen gemacht wurde, somit nur ein Medium unter vielen darstellt.
Eine Maschine kann nur schwerlich einschätzen, was eine Überschrift, was eine Teilüberschrift und was der eigentliche Text ist. Hierfür ist schlicht und ergreifend nach wie vor die menschliche Einschätzung erforderlich.
Beschränkt man das Ganze aber auf die eigentliche Trennung von Optik und Inhalt, ist eine Abstraktion in diesem Sinne durchaus machbar. Dass eine Abstraktion bis hin zur Syntax überflüssig ist, steht für mich außer Frage.

Aber eine Überschrift, ein Text oder ein Bild können ja nicht etwas beliebiges sein, diese Begriffe bedeuten etwas, daher stammt doch die Semantik für das Markup.

Absolut richtig. Den bestehenden Elementen den ihnen innewohnenden Sinn abzusprechen, halte ich auch für recht sinnfrei. In diesem Falle würden die beiden Elemente div und span vollkommen für jegliche Auszeichnung genügen; mit CSS könnten sie optisch (oder akustisch) eine Bedeutung gewinnen, welche aber beliebig austauschbar wäre.
Doch logische Auszeichnungen bleiben immer erhalten, sie sind fest im Dokument verankert und enthalten auch dann noch einen Sinn, wenn kein CSS zur Verfügung steht, oder eine andere Formatierungssprache darauf aufbauen soll.

Falls es dich interessiert, hier findest du die aktuelle SCORM Dokumentation.

Danke, darauf stieß ich bereits.
Momentan habe ich hierfür noch keinen Verwendungszweck, aber wer weiß, was die Zukunft bringt.

In vielen Unternehmen ist Online-Lernen längst wichtiger als traditionelle Seminare.

Dann hoffe ich--nicht der Rationalisierung von Arbeitsplätzen wegen, sondern wegen besserer und effektiverer Lernmöglichkeiten--dass sich dies weiter verbreitet.

Oooch ... die armen Lehrer ;-) ... denen wollen wir doch nicht beweisen, dass so ein strohdummer Computer besser unterrichtet als sie.

Dieser Beweis dürfte immer fehlschlagen, da eine pädagogische Ausbildung nicht von einer Maschine vermittelt werden kann. (Zumindest noch nicht...)

Schliesslich gibt es keine unfähigen Lehrer, sondern nur dumme Schüler ... oder habe ich da was verwechselt?

Alles eine Sache des Betrachtungswinkels, nicht wahr?

Einen schönen Samstag noch.

Gruß, Ashura

[Axel Richter]

Hallo,

Wenn ich deinen Link im Opera aufrufe kriege ich folgendes:
"Opera has modified the JavaScript on www.usability.ch (Milonic fix). See browser.js for details."
Persönlich mag ich keine Designer-Seiten, die nur auf dem IE laufen.

Du weißt, was diese Meldung aussagt bzw. woraus sie resultiert? Du hast wenigstens versucht, das herauszufinden _bevor_ Du ablehnend reagiert hast?

Persönlich mag ich keine ... [...] kannst Du selbst ergänzen.

viele Grüße

Axel

[flashnfantasy]

Habe ich gerade versucht...

Anscheinend handelt es sich um eine externe JavaScript-Datei der Firma Milonic

Es kann sein, daß so ein Hinweis im Opera immer dann kommt, wenn eine gecachte Datei aktuelisiert wird.
Aber ehrlich gesagt, ich habe keine Ahnung.

Bring mal Licht ins Dunkel.

Gruß,
Mathias

[Axel Richter]

Hallo,

Aber ehrlich gesagt, ich habe keine Ahnung.
Bring mal Licht ins Dunkel.

http://www.opera.com/support/search/index.dml?name=browser.js&maxhits=0&platform=winnew
http://www.opera.com/support/search/supsearch.dml?index=740
Klar, was passieren soll?

Das Menü in http://www.usability.ch benutzt http://www.usability.ch/mmenu.js
...
opera=(navigator.userAgent.indexOf("Opera")!=-1)?true:false
//Die Variable opera ist true, wenn als userAgent "Opera" gesendet wird.
...

Suche in Deinem lokalen Filesystem nach browser.js. In browser.js:
...
}else if(  name.indexOf('mmenu.js')>-1  ){
           // Milonic menu
           fixMilonicMenu(name);
        return;
...
function fixMilonicMenu(name){
      if(fixed){return;}fixed=true;
         // "opera" or "opra" true will cause no menu or garbled (Opera 6 pixel* -  compat)
         // ie55 true will use IFRAME shims
         // fixForm function will hide page content
         opera.defineMagicVariable('ie55', function(){ return false }, function(){ });
         opera.defineMagicVariable('opera', function(){ return false }, function(){});
         //Die Variable opera ist ab jetzt immer false.
         opera.defineMagicVariable('opra', function(){ return false }, function(){});
         opera.defineMagicFunction( 'fixForm' , function(){});
         opera.postError('Opera has modified the JavaScript on '+hostname+' (Milonic fix). See browser.js for details.');
}

Opera hat hier also etwas eingebaut, damit die bekannten JS-Menüs neuere Operas nicht mehr ausschließen. Das Menü funktioniert also im Opera8.5. Deine Kritik, es würde nur im IE funktionieren, war also unbegründet.

Ashuras Kritik hingegen ist begründet, denn natürlich ist es nicht notwendig, eine Navigation _nur_ auf JavaScript aufzubauen. Ein einfaches Verlinken der Hauptnavigationspunkte hätte die gesamte Extrawurst für Nutzer ohne JavaScript unnötig gemacht. Das, gerade bei einer Präsenz, die sich "usability" nennt, ist schon lächerlich.

viele Grüße

Axel

[Candid Dauth]

Heißa, Heiner,

http://www.usability.ch/Alertbox/20051003.htm

Zustätzlich zu dem, was die anderen schon gesagt haben, finde ich folgendes noch merkwürdig:

Erklären Sie, was die Leute am anderen Ende des Links vorfinden werden, und fügen Sie einige informative Schlüsselbegriffe in den Ankertext selbst ein.

Die Links im Punkt darüber verraten mir kein bisschen, was mich am anderen Ende erwartet.

Setzen Sie die Einfügemarke ins erste Feld, wenn das Formular erscheint. So ersparen Sie den Benutzern einen Klick.

Lieber die Reihenfolge per tabindex festlegen. Denn was hier erklärt wird, ist wie der Wechsel zwischen Fenstern per focus() etc. Wenn zum Beispiel die Seite lädt, ich gerade ins Adressfeld die URL einer anderen Seite, die ich aufrufen will, eintippe, und der Cursor plötzlich in ein Formularfeld springt, rege ich mich immer ziemlich auf. Und das passiert mir recht oft.

Gautera!
Grüße aus Biberach Riss,
Candid Dauth