Neuauflage von „Rosen – Garten – Kultur“ im Netz

Website – habe diese Website (deren Cascading Style Sheets, das Design) komplett neu geschrieben; dieses Flicken hier und da gefällt mir nicht.

Das Menü ist neu geordnet, das Gesamtbild wirkt möglicherweise etwas „moderner“.
Die Veröffentlichung erfolgte nach zwei Tagen Mammutsitzung am 22. und 27. November 2024.

Auf der Seite „Neuigkeiten der Gestaltung im World Wide Web 2024“ hatte ich eine erste Zusammenfassung geschrieben: Minimales Designdie wiederhole ich hier, damit alles kompakt bleibt.
Unter dem Link aber finden Sie allerlei weitere Themen rund ums Web; wer mag, stöbere auch ebenda …

Welche Gedanken mich umtreiben, wie (m)eine Website sein müsse und wie dies dann technisch umsetzbar wird, können Sie also hier lesen.

Übersicht

Logo Rose

Neues Design – erste Änderungen, Oktober 2024

Mein Handy kann telefonieren und SMS – kein Internet.
Auf den kleinen Bildschirmen aber der Internet-Handys sei es angenehmer, so eine Rückmeldung, wenn das Menü sich über den jeweils gesamten Bildschirm legt (ohne Blick auf die jeweils geöffnete Seite).
Dies spare „Bildschirm-Wischen“ – und man wolle ja ins Menü.
Finde ich einleuchtend. Habe ich entsprechend angepasst.

Den Menü-Button (den „klick-sensitiven“ Bereich) habe ich dezent farblich kenntlich gemacht [Farbe wieder entfernt, stiehlt mir den Focus auf den Inhalt] – ein großer Button, der sich den Bildschirmgrößen anpasst [dies ist geblieben, auch wenn Sie die Größe des Button nicht sehen … klicken Sie einfach beherzt rechts neben dem Wort „Menü“ (bis zum Logo) … klappt schon …].

Bekam zudem die Rückmeldung – auch mit Dank! – dass „Kontakt“ nicht leicht zu finden sei; habe es im Menü – und auch auf entsprechenden Seiten – kenntlicher gemacht.
Und im Kopf der „Startseite“ Kontakt, Telefon sowie meinen Namen aufgeführt; ebenso im Menü selbst: alle Kontaktdaten sind dort jetzt aufgeführt.
Jetzt wird’s bestimmt gefunden …

28.10.2024 – Button „zum Seitenanfang“ mehr aus dem Inhaltsbereich (Lesebereich) herausgenommen und dezenter gemacht [auf dem Handy im Längsformat erscheint dieser Button zentriert; sagen wir grob ab 800px Breite des Monitors sind diese Anpassungen gut zu sehen].

Minimales Design

… ist auch Design.

Ausgerechnet diejenige Website, die mit 38.000 Tausend Anweisungen ohne Gedöns sein will, regte mich an, den in 2013 gefassten Gedanken wieder aufzugreifen, den Inhalt ganz oben zu platzieren, am oberen Rand des Monitors.

Via float pappte mein Inhalt kurz ganz oben, das Logo und den Button fürs Menü umfließend.

Vielleicht etwas zu viel, gar die Luft zum Atem nehmende Fokussierung auf den Inhalt?
Und float wollte ich auch nicht wirklich verwenden …

Wie auch immer: Im ersten Augenschein mutete diese „38-Tausend-CSS-ganz-ohne-Gedöns-Website“ tatsächlich schlicht an – und zeigt den ersten Inhalt ganz oben. Dies gefiel mir schon immer – es entsprach aber nicht den damaligen „professionellen“ Empfehlungen für das Schreiben und für die Gestaltung einer Website; so spuckte meine ratlose Unkenntnis diesen frühen spöttischen Text in die Tastatur. Steht seit 10 Jahren da, bleibt jetzt einfach da stehen …

Mit dem Entwurf heute, 22. November 2024, bin ich ziemlich zufrieden! Vorher war ich es nie – aber ich konnte nicht umsetzen, was mir im Sinn war. So betrachte ich das Ergebnis heute weiterhin als „Entwurf“, weil ich von mir selbst vermute, dass auch dieses Seiten-Design nicht für alle Zeiten bleiben wird …

Und eine persönliche Lehre ist mir für diese Einschätzung meiner eigenen Person sehr hilfreich: heute pfeife ich auf alle Empfehlungen des „professionellen Webdesigns“!

Webdesign damals … heute …

Damals hieß es, das Logo gehöre links oben, die Navigation links am Rand, allenfalls oben der Seite entlang gezogen, wenn wenige Menüeinträge vorlagen (aufklappbare, umfangreiche Menüs waren ein Problem!) … die empfohlenen Schriftgrößen waren irgendwie gern „minimalistisch“, also viel zu klein … und dieses ewiges Gerede über das Angeln im Netz, dieses der Köder muss dem Fisch schmecken, nicht dem ….

Und heute? Webdesign heutzutage?

Das Brötchen einer Fastfood-Kette stellt das Vorbild für DAS Menüsymbol unser Tage, all überall in diversen Variationen samt Animationen diese drei kleinen Striche – selbst auf dem Desktop! Auch dies war mit Aufkommen des „Hamburger Symbols“ zunächst verpönt, dieses Menüsymbol solle doch vorwiegend oder ausschließlich für „Handyformate“ eingesetzt werden. Auch daran hält sich heute kein Designer mehr … wie auch die Navigation heute überall steht und auch nach Belieben ausschaut … bis experimentell herausfordernd sein will.
Auch der (einst eher ungeliebte, geringgeschätzte) footer, bei dem nichts mehr so ist, wie es (mir) einst gelehrt wurde, mutiert heute mitunter gern einmal zum Fetisch …

Focus … worauf?

Der Inhalt einer Website, er gehört in den Focus, der sogenannte content – als ob dies zu lehren wäre? Gern als theoretisch verlautbarte Weisheit Content first … und sodann heute Handy (Mobil) first, da bummelig mehr als 50 % der Menschen mit diesen kleinen Dingern im Netz unterwegs seien. Nun ja, bleiben immer noch – zappelig gedacht – sagen wir es grob: 40 % übrig, die (noch oder auch oder nur) mit dem Desktop „unterwegs“ sind … Zum Beispiel ich.

Wie auch immer! In 2013 und davor galt schon die Regel, eine Website sollte auf allen Geräten nutzbar sein – und „gut aussehen“; was immer dies dann für die Macher und Betrachter einer Website sei …

Cascading Style Sheets (CSS) und „@media only screen

Für meine Rosen-Website habe ich jetzt 66 Cascading Style Sheets (CSS)-Anweisungen verwendet [Stand Dezember 2024]. Betrachte meine Website im Vergleich als „minimalistisch“, sowohl in der Ansicht als auch unter der Haube.[*]

[*] 66 CSS-Anweisungen auf der Rosen-Website; auf dieser Seite hier und auf anderen Seiten dieser „Gestaltungsseiten“ kommen „Spielereien / Experimente“ hinzu.
Bei der Seite des Kontaktformulars stehen ebenfalls zusätzliche Anweisungen für diverse Browser.
Alle diese zusätzlichen CSS werden nur bei Aufrufen der jeweiligen Seiten abgerufen – und streng genommen könnten die auch alle weg …

@media only screen“-Anweisungen hatte ich zuvor zwei, heute keine mehr, die Seiten passen sich auch so den Monitoren an, sind also responsiv.

Flex und Grid sowie clamp und rem für die Gestaltung, also für die Darstellung der Bilder sowie für die Anpassungen der Schriften und am Ende ein auf den Inhalt konzentrierter, „schlichter“ Aufbau der Website machen es möglich.

Die einzige Designer-Sünde verzeihe ich mir still: das Details-Element fürs Menü zu nutzen …

Für mich allerdings ist es bald eine Sünde, dieses wunderbare Element nicht fürs Menü zu nutzen!

Öffnen des Menüs kann der Designer-Mensch auch animieren – nur das Schließen halt nicht (wozu auch, es soll ja dann weg …).

Schritte Richtung barrierefrei

<a aria-current="page" href=""> im Menü hinzugefügt – geöffnete Hauptseiten werden innerhalb des Menüs mit dem Wort „geöffnet“ gekennzeichnet (in der Design-Ansicht nicht zu sehen, also versteckt) – dieses Wort aber sieht man – und wie ich finde, ist dies nützlich – wenn man das CSS bei den Hauptseiten des Menüs ausschaltet, also ohne Design surft, surfen muss.

visibility: hidden; hinzugefügt um den Text zum Logo aus dem Focus der Tastatur beziehungsweise vor den Vorlesegeräten (Screenreader) zu verstecken, die ja nicht ständig den Nutzern denselben Logo-Text vorlesen müssen.

(Versteckte) Anker-Links (sogenannte Skip Links) am Kopf jeder Seite biete ich keine mehr an, habe sie entfernt, da die (semantischen) Elemente nav (Haupt-Navigation), main (Beginn Inhaltsbereich) direkt und ohnehin via Sprung erreicht werden können.

Hilfreich war die Seite von Tollwerk, Barrierefrei Verstecken (Beitrag vom 08. Januar 2023).

Farbkontraste, Möglichkeit der Vergrößerung der Schrift[*] beziehungsweise der Website insgesamt inklusive der Fotos und derlei passt eigentlich bei meinen Seiten – nur die Bildbeschriftungen (sogenannte Alt-Texte) pflege ich konsequent erst seit einigen Monaten – da ist „Nachholbedarf“ bei den älteren (Sorten-)Seiten, was ich Schritt für Schritt erledige …

[*] Farbkontraste auf und Vergrößerung der Ansicht von Websites

Die Tasten Strg gedrückt mit + (plus) vergrößert, mit - (minus) verkleinert und mit 0 (Null) setzt wieder den Standard. Bei einer Vergrößerung von 170-200 % sollte die Website bedienbar, nutzbar bleiben.

Die Farben und deren Kontraste auf der eigenen Website lassen sich gut prüfen unter anderem mit Hilfe von: web accessibility in mind (WebAIM); die Schreibweise für Farben sind in Hexadezimal einzufügen. Es wird sofort angezeigt, ob die ausgewählten / gewünschten Farben (für Links, Fließtext und Hintergrund) den Vorgaben der Web Content Accessibility Guidelines (WCAG) entsprechen; nur sperrig zu lesen, in englischer Sprache.
Die Seite WebAIM ist diesbezüglich sehr hilfreich und an der Praxis orientiert.

Umfangreicher ist die Untersuchung der eigenen Seiten bezüglich Barrierefreiheit auf den Seiten von WAVE (web accessibility evaluation tool). Empfehlenswert für einen tieferen Einblick.

Generelles

Links fängt der abendländische Mensch an zu lesen.

Also oben und links beginnt im idealen Fall der Inhalt. – Was auch immer darunter verstanden wird, unter „Inhalt“ … und unter „Lesen“ … und unter „Diagonales Lesen“

Das obligatorische Logo habe ich jetzt endlich links von der Seite weggeschoben – nach rechts, zwischen dem Menü-Button und der Scrollbar. Der Menü-Button steht auch auf der rechten Seite, während das geöffnete Menü (für die Lektüre) tendenziell links steht. Dies ist eher unmerklich bei Handy-Formaten, aber auf größeren Monitoren – sozusagen ab iPadOS Querformat – wird es hinsichtlich des Lesens der Textteile richtig gut für den Nutzer …

Die Maus muss nicht über den Inhalt fahren, um irgendein links platziertes Menü bedienen zu können, derlei Bedienkonzepte ich damals schon befremdlich fand, heute sogar als vollkommen überholt ansehe.

Die Platzierung des Menü-Button zart rechts (wozu auch das auf die Startseite zu verlinkende Logo gehöre), wenigstens tendenziell rechts, nahe der ebenfalls der Bedienung dienenden Scrollbar, hält die Bedienelemente einer Website beisammen, verringert das Suchen und Springen mit den Augen und das Huschen über die Seiten mit der Maus; dies erscheint mir dem Lesen entgegenzukommen – oder schreiben wir allgemein: dieses ordnende Design kommt dem Betrachten und dem Bedienen einer Website entgegen.

Texte

Ein auf dem Monitor gern zentrierter Text erscheint nur auf dem ersten Blick gut und hübsch; Blocksatz behindert gar das Lesen. Irgendwelche irgendwie und irgendwo in irgendwelchen Kästchen auf dem Monitor verteilte Inhalte sehen allenfalls „interessant“ aus, solange der Mensch nicht liest. Im zweiten Blick aber rückt der Kopf oder gar der gesamte Körper leicht nach rechts oder nach links, weil das Verrücken des Desktops nur schwer geht – also eine gute Sitzposition suchen und einnehmen mit dem Ziel, besser lesen zu können.

Hier kann der Designer-Mensch den Nutzer-Menschen entgegenkommen?

Die Frage mag sich stellen, wie man „Content“ auf den Seiten für die Nutzer gut ordnet. Auf dem Handy und auf dem Desktop.

Also wenigstens bei Seiten mit Text, mit viel Text, was wir hier einfach mal als „Inhalt“, als viel Inhalt interpretieren.

Texte stehen bei der Lektüre leicht links vom Auge, wenigstens halte ich diese leicht nach links tendierende Platzierung von Text für zweckdienlich und angenehm, für eine Freundlichkeit dem Nutzer gegenüber – notfalls halt für die verbleibende Handvoll Desktop-Nutzer … wie ich es bin.

Die Breite des Textblocks? Vielleicht ist die gewohnte Breite eines DIN-A4 Blattes ein gutes Maß (für den Desktop) – fürs Netz vielleicht etwas breiter … oder (im Zeitungsartikel-Stil) deutlich schmaler … sozusagen in der mittleren Breite der Handys …?

„Desktop first“ … „CONTENT-FIRST“

Mein Maß war das Lesen vor dem Desktop – die mobilen Geräte sind mal so, mal so – und wer auf seinem Handy viel liest, hat sein gewohntes Maß.
Meine Seiten scheren hier nicht aus …

Aber: Meine Texte sind mitunter lang. Aber sie werden gelesen, was mir zahlreiche Rückmeldungen unverhofft mitteilen. Und diese Lektüren gehen nun mal besser auf einem größeren Monitor.

Deswegen erscheint mir Mobil first besser generell umzuschreiben zu einem „CONTENT-FIRST“ – für Desktops und Handys …

Serife … Zeilenabstände … Schriftgrößen

Und ich bleibe dabei: Serife ist auch im Web mindestens dann besser zu lesen, wenn die Texte lang sind – mit viel „Content“ halt …
Auch hier findet sich ein Hin und Her der Empfehlungen, welche Schriften und Schriftfamilie die „richtigen … besten“ fürs WorldWideWeb seien … und welcher Zeilenabstand!
Und diese Diskussionen zeitigen für meinen Geschmack und meine Lesekultur mitunter bizarre Ergebnisse des Designs:
Zeilenabstände, jenseits irgendeines Gesetzes der Nähe, die Augen hüpfen vom Ende der ersten Zeile zum Anfang der zweiten Zeile und so fort, wie sie schon von der Überschrift zum Text hüpfen müssen … wer will so längere Texte lesen?

Im Zweifelsfalle entscheide der Nutzer über die Schrift (und dies wäre glücklich: über Zeilenabstände) – und diese Möglichkeiten der Nutzer sollte kein Seiteninhaber torpedieren.
Dies gelte auch für das Erscheinungsbild der Scrollbar und der Maus! Eine Frechheit, wenn „unbedingter Designerwille“ mir hier reingrätscht.

Die Texte heute erscheinen zwar unvermittelt in großen Schriften und in der Regel frei von Serifen, aber ganze Schriftfamilien werden bald maßlos nachgeladen für eine vermeintlich beste Lektüre …
und es bleibt etwas der fahle Geschmack, hier wird der erste Eindruck zählt bedient – nicht aber das Lesen des Inhaltes.

Schriftgrößen unterhalb 14px halte ich für eine Zumutung … bald im Charakter eines unseriösen „Kleingedruckten“ … bei mir wird es auch auf dem schmalen Handy nicht kleiner als 16px im Schriftbild.
Hier bin ich mir lieber selbst das beste Maß …

(…)

Am Ende des Tages sei ein Herr Jean-Claude Biver zitiert: Ich mache kein Marketing; ich mache, was mir gefällt und gehe davon aus, es gefällt auch Anderen.

So ist das … und so mache ich es seit über 10 Jahren.

Diese ewigen Geschichten rund um Fische und Angler im Netz sind auch nicht das Maß aller Dinge …

Ihnen viel Spaß und gute Lektüren im Netz …

Logo Rose

Tooltips, Abkürzungen sowie Akronyme

Im November 2024 habe ich alle Tooltips von meiner Website entfernt, respektive ersetzt – Tooltips lassen sich nicht via Touch abfragen („Handy“). Dies ist ein Grund.

Der zweite Grund ist, dass die Informationen im Tooltip entweder Sinn machen oder nicht. Machen sie Sinn, schreibt man sie doch besser innerhalb des unmittelbar sichtbaren Textbereiches, zum Beispiel als (meinetwegen unfeinen) Klammer-Text … oder als Fußnote … oder als kurzen aber vollständigen Satz im Fließtext.

Dies habe ich jetzt mal bei einigen hundert Tooltips auf meiner Website gemacht …

Die Frage, die ich mir also stellte, war: Kann das weg? Brauche ich den Textteil innerhalb des Tooltips? Wenn ja, wo gehört er hin, wenn nicht derart versteckt?

Abkürzungen und Akronyme habe ich ebenfalls überwiegend geprüft und fast alle entfernt.

Zahlreiche Abkürzungen mögen allgemein bekannt erscheinen, dennoch sollten solche Kürzungen mindestens einmal im Text in Vollfassung stehen – dann können die Abkürzungen ja durchaus im Textverlauf weiter verwendet werden.

Dieses übliche Verfahren ist verknüpft mit dem zuversichtlichen Gedanken, dass der Leser von der ersten Zeile bis Seitenende den Text dann auch liest und die Vollversion eines Wortes samt dessen Abkürzung gedanklich mitnimmt.

Kann man so denken, nur realistisch ist dies ja eher nicht: Wer liest schon jeden Text (im Netz) vollständig?

So ersetzte ich kurzerhand etwa i.d.R. mit „in der Regel“, z.B. mit „zum Beispiel“, sog. mit „sogenannte“ (beziehungsweise mit „sogenannter / sogenannten“) – und bzw. halt mit „beziehungsweise“ …

Auch Alt.Übers. ist wohl besser auszuschreiben, also „Alternative Übersetzung“, ebenso e.c. für exempli causa, dies rutscht mir gelegentlich noch aus der Tastatur, besser aber sind die Entsprechungen „beispielsweise“ oder halt „zum Beispiel“ oder „Beispiele“.

Da es sich gehört, verwendete Abkürzungen mindestens innerhalb eines <abbr>-Elements – das auch für Akronyme verwendet wird – zu erklären, ergibt sich eher mehr Schreibarbeit als wenn der Mensch im Fließtext die Dinge gleich ausschreibt.

(Klammertexte) versus Popover

(Klammertexte) sind eigentlich nicht schön, aber (noch) nicht „verboten“ – und für eine zum Beispiel kurze Übersetzung eines Begriffs gewiss besser geeignet als eine Fußnote – und eben auch besser geeignet als ein Tooltip oder ein <abbr>-Element:

<span class="tooltip" title=
"Benutzerfreundlichkeit und Nutzererlebnis">
Web-Usability und User Experience</span>
(und weiter im Text …)

Für Touch nicht nutzbar. Und:

Dies ist zusätzliche Schreibarbeit, zusätzlich zum Fließtext; einfacher für Textschreiber und Leser ist:

„… Web-Usability (Benutzerfreundlichkeit) und User Experience (Nutzererlebnis) …“.

Geschweige bei Varianten mit Klassenzuweisung für Tooltip oder abbr-Element, um deren Design hinzubekommen … da kommen Schreibarbeiten der Cascading-Style-Sheets hinzu.

Popover lassen sich zwar klicken, taugen für mobile Touch-Geräte aber nur dann, wenn JavaScript verwendet wird, um das nach „Klick“ aufspringende Infoschildchen auch so positioniert zu bekommen, das es sichtbar bleibt, unabhängig von der Monitorgröße beim Nutzer.

Für eine zusätzliche „Kurz-Info“ ergibt sich am Ende derart viel Schreiberei im Quelltext, dass die Frage erlaubt ist, ob hier ein Spieltrieb und der Spaß an der Technik die Vernunft besiegt.

Bei SelfHtml finden Sie Beispiele, was Sie alles schreiben und berücksichtigen müssen, wenn sie derlei rundum „Popover“ nutzen wollen.

Spitz formuliert, solche (mit Verlaub) Quelltext-Aufblähungen für derlei wie etwa die Erklärung des im Fließtext verwendeten norddeutschen Wortes „büschen“, ist ziemlich unökologisch – da arbeiten Server, Browser und das Handy-Datenvolumen der Nutzer eigentlich für nix.
Ich fahre ja auch nicht die 20 Meter zum Bäcker mit einem Sportwagen …

Im Fließtext gehen Texterläuterungen, Ergänzungen und so weiter mit Klammer-Angabe oft gut, wenn nicht besser, in allen Fällen gewiss einfacher:

„… büschen (= bissken, bisserl, bisschen) …“

Hier stört die Klammerangabe den Lesefluss nicht. Der Sprung zu einer Fußnote wäre in diesem Fall wohl übertrieben, ein Popover stört dann schon eher, nervt vielleicht sogar, wenn ordentlich im Gebrauch …?

„… Web-Usability (Benutzerfreundlichkeit) und User Experience (Nutzererlebnis) …“

Hierfür muss ich nichts suchen (Fußnote), nichts an- und wieder wegklicken (Popover) …

Popover versus Fußnote, Details-Element

Bei längeren Texten innerhalb dieser Popover-Infoboxen (zum Beispiel mit Überschriften und Textabschnitten), lässt sich fragen, ob solche umfangreichen Popover-Informationen nicht doch besser stets in einer stets verfügbaren Fußnote aufgehoben wären – oder in einem Details-Element, das aufgeklappt gelassen und im Fließtext genutzt werden kann.

Popover halte ich weiterhin für mehr als entbehrlich – auch dann, wenn die technische Begeisterung mit einem reitet …

Möglicherweise in Tabellen mit zahlreichen Abkürzungen oder Variablen sind Popover noch hilfreich zu denken …

Klar, man kann im Fließtext „ERS, BfN, JKI“ schreiben und diese Abkürzungen als Popover alias Tooltip kenntlich machen, in denen steht dann: „Europa-Rosarium Sangerhausen, Bundesamt für Naturschutz, Julius Kühn-Institut“.

Es geht aber ja auch im Fließtext direkt: „Europa-Rosarium Sangerhausen (ERS), Bundesamt für Naturschutz (BfN), Julius Kühn-Institut (JKI)“ – und dann darf und kann man die eingeführten Abkürzungen im weiteren Verlauf durchaus ohne weitere Erläuterungen verwenden, was mir bei der Popover-Variante eher fragwürdig erscheint.

Über die Barrierefreiheit von Tooltips, Popover und Co. siehe bei SelfHtml oder anderweitig – auch bei diesem Thema erscheint mir ein weniger aufgeblähter Quelltext der erste und beste Weg zu sein …

Logo Rose

Semantik und Bildergalerien

Die Breite der Texte und die Breite von Bildern und Bildergalerien müssen nicht gleich sein – große Fotos oder Bildergalerien ragen über die Breite der Textblöcke hinaus. Dies ist schön anzusehen.

Für größere Monitoren ist dies natürlich gedacht, die Bildergrößen können auf dem Desktop mit dem jeweils verfügbaren Platz wachsen – auf dem Handy halt nur bedingt.
Und die Lesbarkeit der schmal gehaltenen Textblöcke bleibt gewahrt.

Textblöcke werden in <article> oder <section> eingefasst.

Nun sind die Bilder ja Teil des Inhaltes – also Teile von Textblöcken, von <article> oder <section>.

Gibt man aber im Design die Breite von <main> vor, ein umschließender Block, der alle <article> und <section> einfasst, würden auch die Bilder samt Galerien innerhalb diese Textblöcke die vorgegebene Breite von <main> (also von allen Textblöcken) einnehmen.
Vergibt man diese Textblockbreite nicht an <main>, sondern an <article> und <section> (sowie <header> und <aside>), können Bilder und Bildergalerien aus diesen „engen“ Textblöcken herausgenommen werden – und zeigen sich dann groß; wenn Sie so wollen: in voller Pracht.

Sie sehen den Unterschied, wenn Sie zum Beispiel bei den Rosenübersichten schauen, etwa bei den Gallica-Rosen. Öffnen Sie eine Sorten-Seite, zeigt sich die Variante: Bilder breiter als Textblock.

Die Größe der Bilder-Galerien ist auf den Übersichtsseiten also durch Breite der Textblöcke begrenzt. Will man nicht immer …

Die Lösung, die ich also wählte, war, die Bilder und Galerien bei Bedarf aus den Textblöcken herauszunehmen – und nach diesen Bildern und Galerien einen vermeintlich neuen Textblock aufzumachen.

Immerhin ist der gesamte Inhalt (Text und Bild) noch Teil von <main>.

Das Ergebnis des ganzen Prozedere sind also schmale Textblöcke, breite Bildergalerien.

Nur die Semantik stimmt nicht mehr wirklich: Als Teil des Inhaltes eines Artikels zum Beispiel „schweben“ die Galerien nun zwischen den Artikeln, also den Textblöcken. Dies aber will man ja eigentlich nicht!

Es gibt durchaus eine technische Lösung für dieses Dilemma, die ich hier und da schon vorstellte und auch vorsichtig einsetze:


.block-breiter-main {
  width: 90vw;
  position: relative;
  left: 50%;
  right: 50%;
  margin-left: -45vw;
  margin-right: -45vw;
}

Auf meiner kompletten Website aber will ich diese Anweisung nicht verwenden – sie funktioniert bei meiner Arbeitsumgebung, ob sie aber auch bei Ihnen funktioniert?

Die Betriebssysteme, Browser, Monitoren … die Implementierung solcher Cascading-Style-Sheets (CSS) (Design-Anweisungen) in den Geräten sind derart unterschiedlich, dass es mir nicht geheuer ist …

Also „schummele“ ich!

Alles im Fluss und semantisch fein wäre:

          | Textanfang |

Bild | Bild | Bild | Bild | Bild

          | Textende |

Geschummelt sieht es so aus:

          | Textanfang |

          | Textunterbrechung |

Bild   |   Bild   |   Bild   |   Bild   |   

          | Textfortsetzung |

          | Textende |

Da ich hier mit <article> oder <section> neu ansetzte, fehlt es mitunter an einer Überschrift – was der Validator nicht leiden mag …

Wenn Sie eine klügere Lösung wissen als „gewagte“ Design-Anweisungen oder unfeiner Schummel, bin ich für eine Info dankbar.

So bleibt es jetzt, lieber Validator, wie es ist. Denn zusätzliche Überschriften würden es nicht oder kaum besser machen … und mit einer „Verwarnung“ kann ich leben …

Neues Logo

Logo Rosenpark Stoltenberg, rosen-kultur.de

Nach fast 10 Jahren verträgt diese Website ein eigenes Logo. Die Domain dieser Website seit 2015 als Logo zu nehmen, es war „Bequemlichkeit“ (?) und nie wirklich passend oder schön.

Gut, also ein „richtiges“ Logo gegen Ende 2024. Und klar, wir finden es gelungen.

Die drei tragenden Begriffe sind mit Gedankenstrichen verbunden:

„Rosen – Garten – Kultur“.

Und eine Blüte der “Hundsrose” gibt den Schmuck.

Die “Hundsrose”

[Text in ein Details-Element verschoben – wer über Webdesign lesen will, liest vielleicht nur bedingt gern etwas über Rosen … und warum wir eine ins Logo aufgenommen haben.]

Logo Rose

Die Kreisform der Wörter

Die Kreisform – so dachten wir uns weiter – forme in Gedanken hübsche Gärten … und ist als Form organisch.
Und die drei Wörter unseres Namens mochten wir schon immer: bald beliebig „geschüttelt“, erlauben sie wundersam einende Sprachspiele:

  • Rosengarten
    Rosenkultur
  • Gartenkultur
    Gartenrosen
  • Kulturgarten
    Kulturrosen

Sonstiges

Eine Rosenfrucht zur Blüte wäre noch fein gewesen, ist die „Frucht“ doch die Schatzkammer des Gartens.

Meine Frau hat ein Gespür für Design und meinte wohl zu recht, Blüte und Frucht (und was noch so alles denkbar sei) wäre zu viel für ein Logo.

Ich mochte keine Effekte bei der Blüte, etwa „Stoff“ oder „Wasserlinse“ und derlei – und auch kein Symbol für Rose (obgleich es „professioneller“ sein mag).
Das Rosenbild ist schlicht aus unserem Garten.
Auch die Platzierung oben links gefällt uns besser als diverse Varianten; zweites Foto zeigt die Rose mit dem Effekt „Stofftextur“:

Logo mit Text, Blüte und Frucht Logo mit Stoff-Struktur der Blütet Logo mit Blüten-Symbol

Weitere Entwürfe erspare ich Ihnen …

Die Blüte ist „original“ von unserer Rosa canina, (mehr oder weniger sauber) zugeschnitten, Hintergrund ist transparent, so passt es sich den Monitoren an – fertig:

Logo Rosenpark Stoltenberg, rosen-kultur.de
Logo Rosenpark Stoltenberg, rosen-kultur.de

Die Sonnenstrahlen auf den Blütenblättern retuschieren wir auch nicht weg.
Ach ja, das „Flattrige“ der Blütenblätter (durch die Transparenz des Logos hervorgerufen) mögen wir auch – so sind die Blumen – mitunter – im Garten …

Als Scalable Vector Graphic (SVG) haben wir es auch geschrieben, so ist dieses Logo auch beliebig skalierbar, zum Beispiel für Druck.

Soweit und genug zu unserm neuen Logo. Wir sind eigentlich rundum zufrieden, sogar recht glücklich mit diesem hauseigenem, irgendwie „semiprofessionellem“ Designerkind.
Und unser neuer „Abstandshalter“ ist natürlich die Blüte aus dem Logo:

Logo Rose