nicht angemeldet
Matthias Scharwies
Henry
Matthias Scharwies
Gunnar Bittersmann
Henry
Henry
Gunnar Bittersmann
Henry
Servus!
Es hat wieder mal viel länger als geplant gedauert, aber heute morgen habe ich mit der Web-Visitenkarte das vorerst letzte Design der fertigen Layouts veröffentlicht.
Vielen Dank an @Henry, @marctrix, @Meowsalot, @Felix Riesterer und @Matthias Apsel für das Feedback.
Passend dazu habe ich im Self-Blog meine Erfahrungen kurz aufgeschrieben:
Die Layoutvorlagen waren 2013 mein Einstieg bei Selfhtml. Als es mit dem Veröffentlichen dauerte, begann ich die damals bestehenden Lücken im Wiki zu füllen. Nun, nach fünf Jahren, schließt sich der Kreis: Das Wiki ist im Bereich HTML5 und CSS umfassend und aktuell, der SVG-Bereich (den es vorher noch gar nicht gab) ebenfalls. JavaScript ist zumindest vorzeigbar, wenngleich es hier noch einige ToDos gibt.
@marctrix hatte sich schon angeboten, die fertigen Layouts 2019 noch einmal auf eventuelle Weiterentwicklungen zu überprüfen. Es wäre zu wünschen, wenn aus dem Kreis der Community weitere Layouts und auch Verbesserungsvorschläge kämen. Das Wiki kann nur kollaborativ entwickelt werden.
Herzliche Grüße
Matthias Scharwies
Hallo Matthias,
Find ich gut. Ich würde das gerne unterstützen, weiß nur noch nicht genau wie. Wenn es so sein soll, wie Zen-Garden, wäre wahrscheinlich eine Uploadmöglichkeit notwendig und in irgendeiner Weise eine Administration, damit niemand irgendeinen Blödsinn hochläd?
*nur als Anregung
Dann noch ein Vorschlag zum Designswitcher (funktioniert übrigens nicht im IE lokal, noch nicht zu gekommen das zu ergründen), vielleicht lässt sich der irgendwie anders integrieren und Defaultwert im CSS setzen, habe ich aber auch noch keinen genauen Vorschlag zu. Und, das HTML vielleicht noch was weniger vorgeben, tat mich etwas schwer mit dem Headerinhalt, besonders Logo/H1/IMG.
Ich hab's jetzt mal extern versucht und muss sagen, puhh… gar nicht so einfach, wenn man nur das CSS ändern möchte und keinen Einfluss auf HTML und JS hat. Dabei ging es mir bei meinem Versuch gar nicht ums Design sondern um den allseits beliebten und von Handynutzern gewöhnten Hamburger-Button. Nun gibt's zwar etliche Möglichkeiten, dass irgendwie hinzukriegen, aber mit minimalem Code und ohne Zugriff aufs HTML doch problematisch. Also habe ich ein wenig experimentiert und bin zu einer Lösung gelangt, deren Tauglichkeit ich noch nicht einschätzen kann, daher bitte Feedback von euch. Problem dabei war, display:none; wäre mir entgegengekommen aber nicht barrierefrei, mit visibility als Alternative machbar, aber der reservierte Platz war zuviel, so habe ich im hidden-modus die Textgrösse auf 1px gesetzt(hoffe das gilt noch als barrierefrei?).
Na ja, bevor ich hier noch lange schreibe, hier mal der erste Entwurf.
*edit: Habe zwar das standard-css geändert, aber gerade beim Testen gemerkt, manche (Handy)Browser benötigen wohl nochmal die Bestätigung, also auf der Hauptseite am besten nochmal Hamburger-Design auswählen, damit die anderen Seiten das übernehmen.
Gruss
Henry
Servus!
Hallo Matthias,
Find ich gut. Ich würde das gerne unterstützen, weiß nur noch nicht genau wie.
Kein Problem! Vielen Dank im Voraus!
Wenn es so sein soll, wie Zen-Garden, wäre wahrscheinlich eine Uploadmöglichkeit notwendig und in irgendeiner Weise eine Administration, damit niemand irgendeinen Blödsinn hochlädt?
Ja, und da haben wir die zweite Möglichkeit. Die erste (2014 realisierte) war das Hosten im Beispiel-Namensraum wie z.B. dieses noch nicht gelöschte Beispiel. Problem war hier, dass alle Links und Referenzierungen von Stylesheets und Grafiken an das Wiki angepasst werden mussten, sodass man alle Beispiele gegenüber den ZIP-Dateien umarbeiten musste. Diese Beispiele im Wiki darfst du jetzt ändern, bzw. neue erstellen.
Abweichend davon werden die Layoutvorlagen auf src.selhtml.org gehostet, sodass die Ordnerstruktur des Bespiels und des ZIP-Datei gleichbleibt:
JürgenB
Julius
Auge
Matthias Apsel/css
/img
index.html
kontakt.html
unterseite.html
Deshalb habe ich die Layoutvorlagen für den peer review privat gehostet und durch @Felix Riesterer und @marctrix korrigieren lassen. Erst wenn 3-5 fertige Layouts wirklich veröffentlichungswürdig waren, habe ich sie @Camping_RIDER geschickt, der neben @dedlfix den Zugang zu den Servern hat.
So würde ich auch weiterhin verfahren. Wenn es Änderungen gibt, 2-3 Layouts sammeln und dann wegschicken.
*nur als Anregung
*Dann noch ein Vorschlag zum Designswitcher (funktioniert übrigens nicht im IE lokal, noch nicht zu gekommen das zu ergründen), vielleicht lässt sich der irgendwie anders integrieren und Defaultwert im CSS setzen, habe ich aber auch noch keinen genauen Vorschlag zu.
Ja, evtl. sollte das localStorage rausgenommen werden und anfangs immer das Standard-Stylesheet geladen werden. Ich hatte teilweise nach 2 Wochen Pause das industrial-Theme drin gehabt und gleich Augenkrebs bekommen. Der Stylesheetwechlser in der Visitenkarte arbeitet nach dem Zufallsprinzip, bringt teilweise bei Klick auf den Button das gleiche Stylesheet noch einmal. Hier wäre eine auswahl "Ziehen-ohne-Zurücklegen" eine Option.
Und, das HTML vielleicht noch was weniger vorgeben, tat mich etwas schwer mit dem Headerinhalt, besonders Logo/H1/IMG.*
Das widerspricht ja der Idee des CSS-Garten. Andererseits muss ja nicht alles in diesem Beispiel realisiert werden, sondern es kann und sollte neben den 10 Designen-lassen-Entwürfen auch weitere geben. Die Wiki-Beispiele sollen halt nur ein Problem anschaulich zeigen; die fertigen Layouts sollen eine ganze Seite zeigen.
Ich hab's jetzt mal extern versucht und muss sagen, puhh… gar nicht so einfach, wenn man nur das CSS ändern möchte und keinen Einfluss auf HTML und JS hat. Dabei ging es mir bei meinem Versuch gar nicht ums Design sondern um den allseits beliebten und von Handynutzern gewöhnten Hamburger-Button.
Dein Beispiel ist sehr cool!!
Nun gibt's zwar etliche Möglichkeiten, dass irgendwie hinzukriegen, aber mit minimalem Code und ohne Zugriff aufs HTML doch problematisch. Also habe ich ein wenig experimentiert und bin zu einer Lösung gelangt, deren Tauglichkeit ich noch nicht einschätzen kann, daher bitte Feedback von euch. Problem dabei war, display:none; wäre mir entgegengekommen aber nicht barrierefrei, mit visibility als Alternative machbar, aber der reservierte Platz war zuviel, so habe ich im hidden-modus die Textgrösse auf 1px gesetzt(hoffe das gilt noch als barrierefrei?).
Im Wiki gibt's den von Chris Coyier (Link unter dem Artikel) entnommenen Code-Schnipsel:
.ohne-text {
border: 0;
font: 0/0 a;
text-shadow: none;
color: transparent;
}
Na ja, bevor ich hier noch lange schreibe, hier mal der erste Entwurf.
*edit: Habe zwar das standard-css geändert, aber gerade beim Testen gemerkt, manche (Handy)Browser benötigen wohl nochmal die Bestätigung, also auf der Hauptseite am besten nochmal Hamburger-Design auswählen, damit die anderen Seiten das übernehmen.
Nochmal, das gefällt mir sehr gut! Ich hatte mir 2010 angewöhnt, die Navigation an den Schluss zu setzen und dann absolut im Header zu positionieren. Mitterweile hat z.B. die Washington Post auch bei breiteren Viewports eine schmale, vertikale Leiste (links) mit Icons zu den einzelnen Sektionen (Finde ich jetzt aber grad nicht. 😟).
Herzliche Grüße
Matthias Scharwies
@@Matthias Scharwies
Dein Beispiel ist sehr cool!!
Unbedienbare Beispiele sind sehr uncool!!
Du solltest es besser wissen.
Ich hatte mir 2010 angewöhnt, die Navigation an den Schluss zu setzen und dann absolut im Header zu positionieren.
Schlechte Angewohnheit. Die Reihenfolge im DOM (genauer gesagt: im accessibility tree) – d.h. die Reihenfolge beim Durchtabben – sollte mit der visuellen Reihenfolge übereinstimmen. Das heißt: Wenn die Navigation oben auf der Seite ist, sollte sie auch vorne im Markup stehen. (Und per Skip-Link übersprungen werden können.)
Und absolute Positionierung der Navigation schafft auch haufenweise Probleme. Angefangen damit, dass man die für die Navigation benötigte Höhe nicht kennt.
LLAP 🖖
Lieber Gunnar,
Die Reihenfolge im DOM (genauer gesagt: im accessibility tree) – d.h. die Reihenfolge beim Durchtabben – sollte mit der visuellen Reihenfolge übereinstimmen.
warum?
Das heißt: Wenn die Navigation oben auf der Seite ist, sollte sie auch vorne im Markup stehen. (Und per Skip-Link übersprungen werden können.)
Warum nicht auf den Skip-Link verzichten und gleich den Inhalt notieren?
Und absolute Positionierung der Navigation schafft auch haufenweise Probleme. Angefangen damit, dass man die für die Navigation benötigte Höhe nicht kennt.
Wenn es eh ein Hamburger-Button werden soll, kann man das mit JavaScript ermitteln. Ohne JavaScript steht die Navi eben nach dem Content.
Ich verstehe nicht, warum das eine schlechte Angewohnheit sein sollte. Wo sind die Usability-Nachteile?
Liebe Grüße,
Felix Riesterer.
@@Felix Riesterer
Die Reihenfolge im DOM (genauer gesagt: im accessibility tree) – d.h. die Reihenfolge beim Durchtabben – sollte mit der visuellen Reihenfolge übereinstimmen.
warum?
Weil es Verwirrung stiftet, wenn der Fokus bei Tastaurnavigation wild auf der Seite umherspringen würde. Und das fokussierte Element womöglich erstmal auf der Seite gesucht werden müsste.
Das heißt: Wenn die Navigation oben auf der Seite ist, sollte sie auch vorne im Markup stehen. (Und per Skip-Link übersprungen werden können.)
Warum nicht auf den Skip-Link verzichten und gleich den Inhalt notieren?
Die Navigation erst am Ende in der Tab-Reihenfolge zu haben ist sicher nicht das, was man möchte. Kann man auf Seiten mit keinen Links o.a. interaktiven Elementen im Inhalt machen, sonst eher nicht.
LLAP 🖖
Lieber Gunnar,
Weil es Verwirrung stiftet, wenn der Fokus bei Tastaurnavigation wild auf der Seite umherspringen würde. Und das fokussierte Element womöglich erstmal auf der Seite gesucht werden müsste.
ach so, Du argumentierst aus der Sicht eines mit der Tastatur navigierenden. Jetzt verstehe ich.
Die Navigation erst am Ende in der Tab-Reihenfolge zu haben ist sicher nicht das, was man möchte.
Um die oben genannte Verwirrung zu minimieren, vielleicht schon. Gibt es belastbare Erhebungen, wer "man" ist und was "man" tatsächlich "möchte"?
Liebe Grüße,
Felix Riesterer.
hallo
Die Navigation erst am Ende in der Tab-Reihenfolge zu haben ist sicher nicht das, was man möchte.
Um die oben genannte Verwirrung zu minimieren, vielleicht schon. Gibt es belastbare Erhebungen, wer "man" ist und was "man" tatsächlich "möchte"?
Wir sind Augen und Finger-Menschen. Und das erzeugt einen Widerspruch zwischen dem Focus der Augen und jenem der Tastatur. Die Augen haben sich daran gewöhnt, den Header auszublenden und sofort nach einer Hauptüberschrift zu scannen, die dem Inhalt gehört.
Tatsächlich möchte ich, dass mein Tastatur-Focus möglichst schnell den Augenfocus erreicht. Dabei ist es wichtig, dass ich diesen Focus verfolgen kann.
Wenn Stylesheets eine andere Folge als das DOM nahelegen, wird mein Tastenfocus-Focus überraschender Weise die Seite scrollen. Das wäre aber eine negative Überraschung. Ich kann zwar damit Leben, dass der Focus nicht immer die Elemente so präsentiert, als wären es konsequente Worte eines Satzes. Aber Blättern geht gar nicht!
Wie geht man da mit Top-Navigationen um? Mein Ideal wäre, diese generell zu verbergen (dem Focus zu entziehen), und nur den Aktivierungsbutton zu zeigen.
Warum wir im Webdesign uns den Unsinn zugelegt haben, diese Navigationen als das wichtigste zu erachten, kann man wohl nur mit gedankenloser Nachahmerei begründen. Selbst ich pflege diese, gegen besseres Wissen.
@@beatovich
Wie geht man da mit Top-Navigationen um? Mein Ideal wäre, diese generell zu verbergen (dem Focus zu entziehen), und nur den Aktivierungsbutton zu zeigen.
Eine Runde Hamburger für alle?
Warum wir im Webdesign uns den Unsinn zugelegt haben, diese Navigationen als das wichtigste zu erachten, kann man wohl nur mit gedankenloser Nachahmerei begründen.
Oben auf der Seite ≠ das Wichtigste.
Man kann die Navigation ja so gestalten, dass sie in den Hintergrund tritt.
Screenreader-Nutzer kommen anhand von Shortcuts schnell zur Hauptüberschrift. (Vorzugsweise ist das die Überschrift des Hauptinhalts, also die Seitenüberschrift; nicht die Websitekennung im Seitenheader, der zwar üblicherweise oben, aber nicht das Wichtigste ist.)
Für Tastatur-Nutzer ist ein Skip-Link zum Überspringen der Navigation sinnvoll (nur sichtbar, wenn er den Fokus hat), der direkt zum Hauptinhalt führt.
LLAP 🖖
hallo
@@beatovich
Wie geht man da mit Top-Navigationen um? Mein Ideal wäre, diese generell zu verbergen (dem Focus zu entziehen), und nur den Aktivierungsbutton zu zeigen.
Eine Runde Hamburger für alle?
Es darf auch ein Link zur Navigation im Fussbereich sein.
Warum wir im Webdesign uns den Unsinn zugelegt haben, diese Navigationen als das wichtigste zu erachten, kann man wohl nur mit gedankenloser Nachahmerei begründen.
Oben auf der Seite ≠ das Wichtigste.
Für meine Augen eben schon. Sost gibts Werbeblocker.
Man kann die Navigation ja so gestalten, dass sie in den Hintergrund tritt.
Es gibt Navigation und Navigation. Weiterführendes sollte in der Tat nur weiterführendes sein.
Screenreader-Nutzer kommen anhand von Shortcuts schnell zur Hauptüberschrift. (Vorzugsweise ist das die Überschrift des Hauptinhalts, also die Seitenüberschrift; nicht die Websitekennung im Seitenheader, der zwar üblicherweise oben, aber nicht das Wichtigste ist.)
Ich möchte als Tastaturuser mir keinen Screenreader aktivieren. Ich möchte gerne einfach als Tastaturuser respektiert werden.
Für Tastatur-Nutzer ist ein Skip-Link zum Überspringen der Navigation sinnvoll (nur sichtbar, wenn er den Fokus hat), der direkt zum Hauptinhalt führt.
Ich würde halt dem Skiplink anders sagen: Die kleine Nav in Seitenbereiche.
@@Felix Riesterer
Gibt es belastbare Erhebungen, wer "man" ist und was "man" tatsächlich "möchte"?
Frag Marco Zehe, Eric Eggert, Kerstin Probiesch o.a.
LLAP 🖖
Servus!
Ich hatte mir 2010 angewöhnt, die Navigation an den Schluss zu setzen und dann absolut im Header zu positionieren.
Schlechte Angewohnheit.
Na ja, 2013 wurde das im Rahmen der peer review (Matthias Apsel) für die Layouts akzeptiert.
Und absolute Positionierung der Navigation schafft auch haufenweise Probleme. Angefangen damit, dass man die für die Navigation benötigte Höhe nicht kennt.
Unter anderem deswegen, weil man da pixelgenau arbeiten muss (und die einfache mobile Navigation erst später per media queries festgelegt wurde) haben wir es mittlerweile in den jetzt verfügbaren fertigen Layouts nicht mehr so gemacht. (Ich hab's allein umgebaut, aber die oben genannten haben es durchgeschaut)
Interessant ist nur, dass es neben der horizontalen Navigationsleiste, die in den letzten Jahren zum Quasi-Standard auf breiteren Viewports wurde, jetzt wieder vertikal-Navigationen gibt, die auch in der Desktop-Ansicht vertikal bleiben.
Herzliche Grüße
Matthias Scharwies
@@Matthias Scharwies
Ich hatte mir 2010 angewöhnt, die Navigation an den Schluss zu setzen und dann absolut im Header zu positionieren.
Schlechte Angewohnheit.
Na ja, 2013 wurde das im Rahmen der peer review (Matthias Apsel) für die Layouts akzeptiert.
Bevor’s noch jemand merkt und damit triumphierend hier aufschlägt, gestehe ich’s lieber selber: So ungefähr zu der Zeit hab ich das auf https://gunnarbittersmann.de/songs/ auch so gemacht. 🤫
Welcher von den vielen Knoten im Taschentuch war doch gleich dafür?
LLAP 🖖
Hallo Matthias,
Interessant ist nur, dass es neben der horizontalen Navigationsleiste, die in den letzten Jahren zum Quasi-Standard auf breiteren Viewports wurde, jetzt wieder vertikal-Navigationen gibt, die auch in der Desktop-Ansicht vertikal bleiben.
bei den breiten Panoramabildschirmen hat man eben mehr Breite als Höhe.
Gruß
Jürgen
Servus!
Mitterweile hat z.B. die Washington Post auch bei breiteren Viewports eine schmale, vertikale Leiste (links) mit Icons zu den einzelnen Sektionen (Finde ich jetzt aber grad nicht. 😟).
So, da isse:
Die vielen Icons zu den sozialen Netzwerken schockieren mich, bin halt noch kein "digital native".
Herzliche Grüße
Matthias Scharwies
Hallo Matthias,
Die vielen Icons zu den sozialen Netzwerken schockieren mich, bin halt noch kein "digital native".
Ich würde mich als Digital Native bezeichnen: Ich ärgere mich bei einer gedruckten Zeitung, dass Strg+F nicht funktioniert, oder Strg+Z beim Schreiben auf Papier. Voll ätzend.
Aber diese Buttons von besagten „sozialen“ Netzwerken sind das erste, was ich – besonders auf dem Handy – mittels meines Ad- und Trackingblockers (uBlock Origin) von Seiten entferne, sofern ich sie öfters zu besuchen gedenke (heise, golem).
Gruß
Julius
@@Henry
Na ja, bevor ich hier noch lange schreibe, hier mal der erste Entwurf.
So funktioniert das nicht:
nav ul { visibility: hidden }
nav:hover > ul { visibility: visible }
Merke: Wo immer :hover ist, sollte :focus nicht weit sein. Nicht jeder Nutzer schubst eine Maus; eine Webseite muss auch per Tastatur bedienbar sein.
Das Pseudoelement nav::before (einzig das Hamburger-Icon (dem eine Beschriftung wie „Menü“ fehlt) ist vom nav-Element bei Portrait-Viewport[1] sichtbar) ist aber gar kein interaktives Element – es kann nicht per Tastatur angesprungen werden. Zum Auf- und Zuklappen muss ein Button vorgesehen werden, wie in diesem Beispiel.
LLAP 🖖
Die Darstellung des Menüs sollte an der zur Verfügung stehenden Breite festgemacht werden, nicht daran, ob diese größer oder kleiner als die Höhe ist. ↩︎
Hallo Gunnar,
So funktioniert das nicht:
Merke: Wo immer
:hoverist, sollte:focusnicht weit sein. Nicht jeder Nutzer schubst eine Maus; eine Webseite muss auch per Tastatur bedienbar sein.
Ich habe es schon befürchtet, daher die Nachfrage. Es funktioniert mit Maus und Touch, aber Tastatur leider nicht.
Das Pseudoelement
nav::before(einzig das Hamburger-Icon (dem eine Beschriftung wie „Menü“ fehlt) ist vomnav-Element bei Portrait-Viewport[^1] sichtbar) ist aber gar kein interaktives Element – es kann nicht per Tastatur angesprungen werden. Zum Auf- und Zuklappen muss ein Button vorgesehen werden, wie in diesem Beispiel.
Das Problem ist, es soll ja nur durch Änderung der CSS Datei erzeugt werden, hättest du da auch eine Lösung?
Die Darstellung des Menüs sollte an der zur Verfügung stehenden Breite festgemacht werden, nicht daran, ob diese größer oder kleiner als die Höhe ist.
Das verstehe ich nicht ganz, darum habe ich mich ja für Portraitmode entschieden.
Gruss
Henry
hallo
Das Problem ist, es soll ja nur durch Änderung der CSS Datei erzeugt werden, hättest du da auch eine Lösung?
Das Problem ist, dass das html unvollständig ist. Jedes Klappmenu (und darum handelt es sich hier) braucht einen Aktivierungsbutton.
Hallo beatovich,
Das Problem ist, dass das html unvollständig ist. Jedes Klappmenu (und darum handelt es sich hier) braucht einen Aktivierungsbutton.
Auch das habe ich befürchtet, allerdings gehofft, dass es doch irgendwie machbar sein könnte. Hatte den Verdacht da vielleicht irgendwas mit before/after einbinden zu können, aber nichts passendes gefunden. Oder wäre das vielleicht doch denkbar?
Gruss
Henry
hallo
Hallo beatovich,
Das Problem ist, dass das html unvollständig ist. Jedes Klappmenu (und darum handelt es sich hier) braucht einen Aktivierungsbutton.
Auch das habe ich befürchtet, allerdings gehofft, dass es doch irgendwie machbar sein könnte. Hatte den Verdacht da vielleicht irgendwas mit before/after einbinden zu können, aber nichts passendes gefunden. Oder wäre das vielleicht doch denkbar?
Hier ist der Punkt:
Entweder man benutzt Javascript weil man die diversen aria-expanded und aria-hidden attribute umschreiben muss (soweit sind wir gekommen)
oder du schreibst einen statischen link und wertest :target aus. (focus ist zuwenig weil der verloren geht.) Bei einer Navigation können wir uns den schliess-Link eventuell sparen.
@@Henry
Das Problem ist, es soll ja nur durch Änderung der CSS Datei erzeugt werden, hättest du da auch eine Lösung?
Wenn kein Button im HTML (besser gesagt: im DOM) ist, dann kein Hamburger-Menü. Wenn man ein Hamburger-Menü will, dann muss man einen Button einfügen; entweder ins HTML oder per JavaScript.
CSS-only ist keine Lösung, wenn das nicht allgemein bedienbar ist.
Die Darstellung des Menüs sollte an der zur Verfügung stehenden Breite festgemacht werden, nicht daran, ob diese größer oder kleiner als die Höhe ist.
Das verstehe ich nicht ganz, darum habe ich mich ja für Portraitmode entschieden.
Warum sollte das Menü hinter einem Hamburger-Icon versteckt werden, wenn 80em in der Breite zur Verfügung stehen (und in der Höhe 82em)?
Der media query sollte einer mit max-width sein, wobei sich der breakpoint nach dem Inhalt des Menüs und dessen Darstellung (Schrifftart, -größe, Abstände) richtet, also eine magic number ist.
Warum sollte das Menü überhaupt hinter einem Hamburger-Icon versteckt werden? Nur „weil’s doch alle so machen“?
LLAP 🖖
Hallo Gunnar,
Warum sollte das Menü hinter einem Hamburger-Icon versteckt werden, wenn 80em in der Breite zur Verfügung stehen (und in der Höhe 82em)?
Verstehe nicht ganz wie du zu diesen Zahlen kommst, bzw. worauf sich die em hier referenzieren? Kann es nur mal umschreiben, wenn ich das mit dem Handy sehe, möchte ich nicht immer das Menu im Blick haben und runterscrollen müssen.
Der media query sollte einer mit
max-widthsein, wobei sich der breakpoint nach dem Inhalt des Menüs und dessen Darstellung (Schrifftart, -größe, Abstände) richtet, also eine magic number ist.
Die Sache ist nur, dass der Auflösungsurwald der Bildschirme keine verlässliche Identifizierung erlaubt, daher nutze ich am liebsten den portraimode, hat zwar den kleinen Nachteil, dass auf sehr großen Bildschirm die Mobilansicht entstehen kann, aber das ist unproblematisch, Hauptsache im Handy passt's wie es soll. Aber vielleicht meinst du das auch anders mit den Breakpoints?
Warum sollte das Menü überhaupt hinter einem Hamburger-Icon versteckt werden? Nur „weil’s doch alle so machen“?
Ja auch, es gibt eine Erwartungshaltung beim Besucher(den man nicht verwirren sollte) und weil es sich nicht ohne Grund etabliert hat, es ist praktisch.
Gruss
Henry
Servus!
Warum sollte das Menü hinter einem Hamburger-Icon versteckt werden, wenn 80em in der Breite zur Verfügung stehen (und in der Höhe 82em)?
Verstehe nicht ganz wie du zu diesen Zahlen kommst, bzw. worauf sich die em hier referenzieren?
Das ist sein Monitor in der Arbeit - seufz! Neid!
Warum sollte das Menü überhaupt hinter einem Hamburger-Icon versteckt werden? Nur „weil’s doch alle so machen“?
Na ja, Reduzierung auf das Wesentliche, nämlich den Inhalt. Und wenn wer was anderes möchte kann er/sie links in der Leiste das Hamburger-Menü die Such-Lupe und sonst noch was anklicken.
@Henry Ich habe dir eine PN geschrieben - hast du die in den Einstellungen (rechts oben) aktiviert?
Man könnte das Beispiel ja mit einem veränderten HTML-Markup als Design 11 veröffentlichen. Wenn Du keine PNs willst, kann man ja über projekt@selfhtml.org schreiben.
Herzliche Grüße
Matthias Scharwies
@@Henry
Warum sollte das Menü hinter einem Hamburger-Icon versteckt werden, wenn 80em in der Breite zur Verfügung stehen (und in der Höhe 82em)?
Verstehe nicht ganz wie du zu diesen Zahlen kommst
Aus der Luft gegriffen. Ich hätte auch 73em Breite und 74em Höhe greifen können.
bzw. worauf sich die em hier referenzieren?
Auf die Basis-Schriftgröße. Wie man breakpoints angeben sollte.
Kann es nur mal umschreiben, wenn ich das mit dem Handy sehe, möchte ich nicht immer das Menu im Blick haben und runterscrollen müssen.
Es geistert die Ansicht umher, man müsse Platz sparen und alles Wesentliche above the fold anordnen. Nutzertests sagen: Alles Quatsch, there is no fold. Nutzer wissen zu scrollen bzw. zu swipen.
Es gibt eigentlich keinen Grund, das Menü hinter einem Icon zu verstecken. Wenn das Menü zu umfangreich ist, dann ist es das auch auf großen Bildschirmen und man sollte die Menüstruktur, wenn nicht gar die Informationsarchitektur nochmals überdenken.
Der media query sollte einer mit
max-widthsein, wobei sich der breakpoint nach dem Inhalt des Menüs und dessen Darstellung (Schrifftart, -größe, Abstände) richtet, also eine magic number ist.Die Sache ist nur, dass der Auflösungsurwald der Bildschirme keine verlässliche Identifizierung erlaubt
Es ist auch ziemlich sinnlos, breakpoints anhand gerade gängiger Geräte zu wählen. Der Inhalt bestimmt die breakpoints. Das hatten wir doch schon mal.
daher nutze ich am liebsten den portraimode, hat zwar den kleinen Nachteil, dass auf sehr großen Bildschirm die Mobilansicht entstehen kann
Auch auf kleinen oder mittelgroßen. Wenn der hochkant gedreht ist bspw. Oder wenn das Browserfenster nur einen Teil des Bildschirms einnimmt.
aber das ist unproblematisch
Für dich ja; für Nutzer nein.
Hauptsache im Handy passt's wie es soll.
?? Es sollte auf allen Geräten passen.
Warum sollte das Menü überhaupt hinter einem Hamburger-Icon versteckt werden? Nur „weil’s doch alle so machen“?
Ja auch, es gibt eine Erwartungshaltung beim Besucher(den man nicht verwirren sollte)
Ich als Benutzer erwarte, eine Navigation vorzufinden; nicht danach suchen zu müssen.
und weil es sich nicht ohne Grund etabliert hat, es ist praktisch.
Einen zweifelhaften „Grund“ hatte ich oben genannt. „Weil sich Cookie-Hinweise tabliert haben, sind diese äußerst praktisch.“ Merkste selber, dass die Argumentation unsinnig ist?
LLAP 🖖
Hallo Gunnar,
Es geistert die Ansicht umher, man müsse Platz sparen und alles Wesentliche above the fold anordnen. Nutzertest sagen: Alles Quatsch, there is no fold. Nutzer wissen zu scrollen bzw. zu swipen.
Wissen ja, wollen glaube ich nicht.
Es gibt eigentlich keinen Grund, das Menü hinter einem Icon zu verstecken. Wenn das Menü zu umfangreich ist, dann ist es das auch auf großen Bildschirmen und man sollte die Menüstruktur, wenn nicht gar die Informationsarchitektur nochmals überdenken.
5 oder 6 Links sind nicht umfangreich, aber auf Handy oft schon der halbe Bildschirm.
Es ist auch ziemlich sinnlos, breakpoints anhand gerade gängiger Geräte zu wählen. Der Inhalt bestimmt die breakpoints. Das hatten wir doch schon mal.
Ja das hatten wir schon, aber im Folgenden dort, hatte ich dich auch gefragt, warum dein (sehr schönes) Beispiel aber auch einen Breakpoint bei 400px setzt. Das passt dann nicht ganz zu an Inhalten orientieren. Vielleicht habe ich es auch nicht verstanden, aber da du nicht drauf eingegangen bist, viell. diesmal?
daher nutze ich am liebsten den portraimode, hat zwar den kleinen Nachteil, dass auf sehr großen Bildschirm die Mobilansicht entstehen kann
Auch auf kleinen oder mittelgroßen. Wenn der hochkant gedreht ist bspw. Oder wenn das Browserfenster nur rinrn Teil des Bildschirms einnimmt.
Ja.
aber das ist unproblematisch
Für dich ja; für Nutzer nein.
Also ich beschwere mich nicht, wenn ich auf dem Desktop die mobile Version zu sehen bekomme, oft gefällt sie mir sogar besser.
Hauptsache im Handy passt's wie es soll.
?? Es sollte auf allen Geräten passen.
Passen tut's ja auch auf den anderen, oder um es mit deinen bevorzugten Worten zu sagen (wenns um Browerkompatibilität geht) "Es funktioniert, muss ja nicht überall gleich aussehen" 😉
Ich als Benutzer erwarte, eine Navigation vorzufinden; nicht danach suchen zu müssen.
Ja du bist aber auch schon, wie viele hier (mich eingeschlossen), ein Dinosaurier 😉 Denke die jüngere Generation hat eine andere Erwartung. Und nur um dich mal zu schockieren, es findet, so habe ich zumindest den Eindruck, im Moment ein schleichender Prozess (langsam aber stetig) statt, immer mehr Templates machen sich gar nicht mehr die Mühe zu unterscheiden und nehmen für alle Devices einfach das Hamburgermenu. Und da ist noch ein Punkt, früher (lange her) gab es hier oft harsche Kritik (viell. sogar von dir? bin nicht sicher) wenn jemand Pulldowns oder andere typische Formularelemente verschönern wollte, ist heute völlig normal meckert keiner mehr.
und weil es sich nicht ohne Grund etabliert hat, es ist praktisch.
Einen zweifelhaften „Grund“ hatte ich oben genannt. „Weil sich Cookie-Hinweise tabliert haben, sind diese äußerst praktisch.“ Merkste selber, dass die Argumentation unsinnig ist?
Neee nee, da verdrehst du aber was ordentlich. Meine Aussage: "Hat sich etabliert, weil praktisch." Deine Aussage: "Praktisch, weil sich etabliert hat." Das ist ein Riesenunterschied.
Gruss
Henry
@@Henry
Nutzer wissen zu scrollen bzw. zu swipen. Wissen ja, wollen glaube ich nicht.
Natürlich will kein Nutzer scrollen bzw. swipen. Genauso wenig, wie ein Nutzer sich irgendwo anmelden/einloggen will.
Nutzer wollen an die Inhalte kommen, deshalb werden sie scrollen bzw. swipen – ohne dass dies ein besonderes Ärgernis darstellt.
5 oder 6 Links sind nicht umfangreich, aber auf Handy oft schon der halbe Bildschirm.
5 oder 6 Links sollten wenn nicht noch in eine, dann in zwei Zeilen passen.
Ja das hatten wir schon, aber im Folgenden dort, hatte ich dich auch gefragt, warum dein (sehr schönes) Beispiel aber auch einen Breakpoint bei 400px setzt. Das passt dann nicht ganz zu an Inhalten orientieren. Vielleicht habe ich es auch nicht verstanden, aber da du nicht drauf eingegangen bist, viell. diesmal?
Du meinst dieses Beispiel? Ich würde sagen, bei 400px wechselt die Darstellung der Bilder von 2 auf 3 nebeneinander. Wofür man heute mit CSS Grid übrigens keinen media query mehr braucht.
?? Es sollte auf allen Geräten passen.
Passen tut's ja auch auf den anderen, oder um es mit deinen bevorzugten Worten zu sagen (wenns um Browerkompatibilität geht) "Es funktioniert, muss ja nicht überall gleich aussehen" 😉
„Passen“ meint: Ausgabe soll zum jeweiligen Gerät passen; nicht zur Ausgabe auf anderen Geräten.
und weil es sich nicht ohne Grund etabliert hat, es ist praktisch.
Einen zweifelhaften „Grund“ hatte ich oben genannt. „Weil sich Cookie-Hinweise tabliert haben, sind diese äußerst praktisch.“ Merkste selber, dass die Argumentation unsinnig ist?
Neee nee, da verdrehst du aber was ordentlich. Meine Aussage: "Hat sich etabliert, weil praktisch." Deine Aussage: "Praktisch, weil sich etabliert hat." Das ist ein Riesenunterschied.
Erst vertauschst du Ursache und Wirkung, dann die Namen.
LLAP 🖖
Hallo
Es geistert die Ansicht umher, man müsse Platz sparen und alles Wesentliche above the fold anordnen. Nutzertest sagen: Alles Quatsch, there is no fold. Nutzer wissen zu scrollen bzw. zu swipen.
Wissen ja, wollen glaube ich nicht.
? Scrollen ist ein gängiges Konzept. Niemand, der das Konzept in allen möglichen Programmen und Apps tagtäglich benutzt, wird damit ein Problem haben. Also warum konstruierst du hier ein „nicht wollen“?
Wenn du meinst, bei deinen Produkten ohne scrollen auskommen zu wollen, bitteschön. Ach übrigens, alle Pfurz lang auf einen Weiter-Link klicken, der da ist, damit der Inhalt so aufgeteilt ist, dass alles auf jeweils einen Bildschirm passt, will ich nicht.
Es gibt eigentlich keinen Grund, das Menü hinter einem Icon zu verstecken. Wenn das Menü zu umfangreich ist, dann ist es das auch auf großen Bildschirmen und man sollte die Menüstruktur, wenn nicht gar die Informationsarchitektur nochmals überdenken.
5 oder 6 Links sind nicht umfangreich, aber auf Handy oft schon der halbe Bildschirm.
Ja und? Einmal wischen und ich bin unter der Navigation. Nein, das überfordert auch nicht die von dir herbeizitierte, junge, angeblich so andere Generation.
Ich als Benutzer erwarte, eine Navigation vorzufinden; nicht danach suchen zu müssen.
Ja du bist aber auch schon, wie viele hier (mich eingeschlossen), ein Dinosaurier 😉 Denke die jüngere Generation hat eine andere Erwartung.
Die junge Generation will den Aufwand eines zusätzlichen Klicks auf jeder Seite haben? Entschuldige, das kann ich mir bei bestem Willen nicht vorstellen. Klickt das Publikum? Ja, weil es nicht anders kann, da, wie du selbst schreibst, Autoren von Webseiten bzw. Templates und CMS das genauso lösen. Wenn ich als Anwender nicht anders kann, klicke ich halt, weil ich muss, wenn im Zweifelsfall auch unwillig. Wenn das Menü aber einfach da ist, ich mir also den zusätzlichen Klick sparen kann, bevorzuge ich das, schon, weil ich nicht erst schauen muss, wo und hinter welchem Symbol denn das Menü versteckt ist (und nein, es sind eben nicht immer die drei oder vier waagerechten Striche mit oder ohne Umrandung an immer der gleichen Stelle auf einer Seite).
„Müssen“ ist eben mitnichten mit „wollen“ identisch.
Tschö, Auge
Hallo Auge,
Ich meine, es gibt einen großen Unterschied zwischen vertikalem und horizontalem Scrollen. Ersteres ist sicher unvermeidbar, letzteres würde ich versuchen zu vermeiden.
Bis demnächst
Matthias
Hallo
Ich meine, es gibt einen großen Unterschied zwischen vertikalem und horizontalem Scrollen. Ersteres ist sicher unvermeidbar, letzteres würde ich versuchen zu vermeiden.
Sicher, von mir keine Gegenrede. Aber ging es hier um das Querscrollen?
Tschö, Auge
Hallo Auge,
Aber ging es hier um das Querscrollen?
Ich denke, ja. Bei einer Navigation in einer Zeile wäre es nicht schön, wenn einige Menüpunkte nicht zu sehen wären, zumal einige Handys die Scrollleisten erst bei Bedarf einblenden, der unsichtbare Menüpunkt also zu fehlen scheint.
Bis demnächst
Matthias
Hallo
Aber ging es hier um das Querscrollen?
Ich denke, ja.
Ich denke nicht. Vom eventuell nötigen Querscrollen habe ich keine Rede gefunden.
Bei einer Navigation in einer Zeile wäre es nicht schön, wenn einige Menüpunkte nicht zu sehen wären …
Natürlich nicht.
… zumal einige Handys die Scrollleisten erst bei Bedarf einblenden, der unsichtbare Menüpunkt also zu fehlen scheint.
Ja, aber weder finde ich bei Gunnar noch bei Henry einen Hinweis auf quer zu srollende Menüs. Gunnar meinte zwar, eine Menü mit fünf oder sechs Punkten in eine oder zwei Zeilen zu bekommen, so dass das Menü nicht „fast die ganze Höhe“ eines Smartphones einnimmt, aber mit dem „oder“ gehe ich von einem umbrechenden Menü aus.
Und wo wir gerade bei ausgeblendeten Scrolleisten sind, ein Rant hinterher. Mit dem Verstecken der Scrollleisten habe ich eh so meine Probleme (mit den drei „l“ in Scrollleiste aber auch 😉). Zumindest auf dem Desktop halte ich es für eine verurteilenswürdige Unsitte.
Ich will in einem Programmfenster auf einen Blick sehen, wo in einem Dokument, Formular, WasAuchImmer ich mich befinde. Die Stellung des Schiebers einer Scrollleite gibt mir dafür hinreichende Anhaltspunkte. Das Einblenden der Scrolleiste erst, wenn ich im Fenster den Cursor mit gedrückter Maustaste bewege, ist mMn grober Unfug, da ich den Inhalt des Fensters in diesem Moment oft gar nicht bewegen will. Vom eingesparten Platz muss mir auch keiner 'was erzählen. Die 20 Pixel (oder etwas weniger oder mehr) machen den Kohl keineswegs fett. Und dann noch die Programmautoren, die meinen, aus ästhetischen Gründen die Vorgaben der Betriebssysteme zu übergehen und es noch ganz anders als alle Anderen machen zu müssen … *garglarks!* … *dammichnochma!* …
Tschö, Auge
@@Auge
aber mit dem „oder“ gehe ich von einem umbrechenden Menü aus.
Ja, so war das gemeint.
Und wo wir gerade bei ausgeblendeten Scrolleisten sind, ein Rant hinterher. Mit dem Verstecken der Scrollleisten habe ich eh so meine Probleme (mit den drei „l“ in Scrollleiste aber auch 😉). Zumindest auf dem Desktop halte ich es für eine verurteilenswürdige Unsitte.
Gewöhnungssache. Ich find’s auf dem Mac OK, die Scrollleisten (mit drei l, alle vor dem ei) nicht ständig zu sehen. Aber wer sie ständig sehen will, kann sich das so einstellen.
LLAP 🖖
Hallo Gunnar, hallo Auge,
Und wo wir gerade bei ausgeblendeten Scrolleisten sind, ein Rant hinterher. Mit dem Verstecken der Scrollleisten habe ich eh so meine Probleme (mit den drei „l“ in Scrollleiste aber auch 😉). Zumindest auf dem Desktop halte ich es für eine verurteilenswürdige Unsitte.
Gewöhnungssache. Ich find’s auf dem Mac OK, die Scrollleisten (mit drei l, alle vor dem ei) nicht ständig zu sehen. Aber wer sie ständig sehen will, kann sich das so einstellen.
ich verwende Windows 10 und MacOS, manchmal stehen die Laptops sogar nebeneinander. Es kommt immer mal wieder vor, dass ich die Tastaturkürzel verwechsle. Beim Scrollen habe ich aber noch nie die ausgeblendeten Scrollbalken vermisst, dagegen versuche ich auf dem W10-Laptop oft mit wischen auf dem Touchpad zu scrollen.
Gruß
Jürgen
Hallo
ich verwende Windows 10 und MacOS, manchmal stehen die Laptops sogar nebeneinander.
Geht mir mit dem Arbeitsrechner (Windows 10) und meinem Laptop mit Ubuntu Mate ähnlich.
Beim Scrollen habe ich […] noch nie die ausgeblendeten Scrollbalken vermisst
Bitte vermische das nicht. Mir ging es nicht ums scrollen, sondern darum, von den Scrollbalken andere Informationen zu erlangen, was halt nur dann gut funktioniert, wenn sie auch angezeigt werden.
dagegen versuche ich auf dem W10-Laptop oft mit wischen auf dem Touchpad zu scrollen.
Auch so ein „Dingelns“, dass nach meiner Erfahrung an mehreren Laptops mehr schlecht als recht funktioniert. Ich habe daher immer einen Hamster im Rucksack.
Tschö, Auge