Anforderungen

Prinzipien

Bei der Entwicklung von Web-Anwendungen auf wien.gv.at sind ein paar Prinzipien grundlegend.

Content-First

Die Content Strategie für wien.gv.at folgt dem Content-First-Prinzip. Es sieht vor, dass aus Sicht der Wienerinnen und Wiener möglichst nützliche Inhalte angeboten werden und so aufbereitet sind, dass sie rasch gefunden werden - unabhängig vom gerade verwendeten Kanal (Websites, Apps, Google usw. …).

Alle bekommen noch schneller und einfacher die Information, die sie brauchen. Auf dem Kanal ihrer Wahl.

Um Content-First erfolgreich anwenden zu können, müssen Entwicklerinnen und Entwickler eng mit Redakteurinnen und Redakteuren sowie Designerinnen und Designern zusammenarbeiten. Unsere Patterns sind so konzipiert worden, dass der Content möglichst einfach und verständlich aufbereitet sit. Es ist wichtig zu verstehen: Besucherinnen und Besucher auf wien.gv.at kommen nicht in erster Linie aufgrund des Designs, sondern wegen der nützlichen Inhalte. Das responsive Design der Patterns unterstützt den Content auf allen Geräten und rundet eine zufriedenstellende User Journey für Nutzerinnen und Nutzer ab.

Für die Erstellung von Inhalten für wien.gv.at gilt, dass auch die Workflows nach dem Content-First-Prinzip ausgerichtet sind. Das bedeutet, dass zuerst analysiert wird, welche Inhalte nachgefragt werden und wie diese aufbereitet werden müssen, damit Nutzerinnen und Nutzer sie bestmöglich finden und lesenkönnen. Je nachdem können dann weitere Schritte in Konzeption, Entwicklung und Design gesetzt werden. Kurzum: „Form follows Content“.

Mobile-First

Alle Anwendungen auf wien.gv.at müssen nach dem Mobile-First-Prinzip konzipiert, entwickelt und gestaltet werden. Konkret besagt das Prinzip, dass User-Interfaces prioritär für die Nutzung auf Smartphones erstellt werden. Das betrifft die Gestaltung und Positionierung von Texten und Bedienelementen, sowie die Entwicklung in HTML, CSS und JavaScript.

In CSS bedeutet das beispielsweise, dass Stil-Definitionen zuerst für kleinere Bildschirme geschrieben werden und dann Breakpoints für größere Bildschirme gesetzt werden und nicht umgekehrt.

Mobile first (bevorzugt)

.block {
  padding: 1rem;
}

@media(min-width: 600px) {
  .block {
    padding: 2rem;
  }
}

Desktop first

.block {
  padding: 2rem;
}

@media(max-width: 599px) {
  .block {
    padding: 1rem;
  }
}

Rule of Least Power

In der Programmierung besagt die „Rule of Least Power“, dass stets die einfachste und schwächste Programmiersprache für einen Anwendungszweck verwendet werden soll. Für Web-Anwendungen und -Komponenten bedeutet das in der Regel HTML. Das heißt nicht, dass zusätzliche Sprachen wie CSS und JavaScript gar nicht verwendet werden sollen, wenn sich eine Aufgabe mit HTML allein lösen lässt, sondern, dass der Funktionsumfang Schicht für Schicht erweitert werden soll (siehe Progressive Enhancement).

Progressive Enhancement

Progressive Enhancement beschreibt die Umsetzung der Rule of Least Power mit zusätzlicher, progressiver Erweiterung der Funktionalität. Dabei werden Features schichtweise so hinzugefügt, dass untere Schichten immer noch funktionieren, selbst wenn obere Schichten wegfallen.
Man beginnt mit einem gut strukturierten und semantisch korrekten HTML-Dokument. Dieses wird optisch und funktional mit CSS angereichert, um die Bedienbarkeit zu verbessern. Kann CSS nicht geladen werden, ist das Dokument, aufgrund seiner starken Basis, immer noch zugänglich. Wenn es für die Besucherinnen und Besucher zusätzlichen Nutzen bringt, kann die Funktionalität mit JavaScript nochmals erweitert werden.

1. HTML - Semantisches Markup
2. CSS - Visuelle Verbesserungen
3. JS - Erweiterte Funktionalität

Interoperabilität / Browser

Anwendungen auf wien.gv.at müssen die folgenden Browser in der jeweils aktuellen Version unterstützen (bei Safari zusätzlich auch die vorhergehende Hauptversion von macOS beziehungsweise iOS).

Unterstützte Browser für Anwendungen auf wien.gv.at

Legende

1: Volle Unterstützung
Weitgehend gleiche Darstellung, Bedienung und gleiches Verhalten der Anwendung auf allen Browsern dieser Kategorie. Geringe Unterschiede sind möglich.

2: Bedingte Unterstützung
Alle Inhalte der Anwendung sind zugänglich, wobei Darstellung, Bedienung und Verhalten der Anwendung gegenüber anderen Browsern abweichen können.

Performance

Die serverseitige Reaktionszeit („Time to First Byte“) einer beliebigen Website in Österreich soll bei zirka 200ms liegen, niemals über 400ms. Die Website muss im „Google Page Speed Insights“-Test sowohl bei Desktop als auch Mobil ein grünes Rating aufweisen.

Barrierefreiheit

Für Inhalte auf wien.gv.at ist die Einhaltung der Richtlinien für ein barrierefreies Webdesign nach  WCAG 2.1 Level AA Pflicht.

Die Zugänglichkeit von Web-Anwendungen muss ausreichend getestet werden. Das bedeutet, dass die Bedienbarkeit zumindest mit folgenden Eingabemodalitäten und Programmen gewährleistet sein muss:

• Tastatur oder ähnliche Eingabegeräte
• Gängige Screenreader Software: NVDA und Jaws auf Windows, VoiceOver auf macOS und iOs, Talkback auf Android.
• Geräte- und browserunabhängig ohne JavaScript

Ein Score von 100 in Lighthouse oder 0 Fehler in anderen automatisierten Testprogrammen wie axe oder WAVE sind erwünscht, sagen allein aber nichts über die Barrierefreiheit einer Website aus. Es muss jedenfalls auch manuell getestet werden.

SEO

Etwa die Hälfte der Nutzerinnen und Nutzer auf wien.gv.at kommt über Google. Damit die Wienerinnen und Wiener dort unsere offiziellen Infos finden, braucht es eine zeitgemäße Search Engine Optimization (SEO).

Redakteurinnen und Redakteuren können mit passendem Meta-Titel und Meta-Beschreibung, Keywords, Alt-Text, et cetera ihren Beitrag leisten.

Das allein ist aber nicht mehr ausreichend. Suchmaschinen interessieren sich immer stärker für den Kontext von Inhalten. Und: Die Gestaltung der Inhalte muss die zunehmende Verwendung von gesprochenen Suchanfragen und Sprachassistenten (vor allem bei Mobilgeräten) berücksichtigen. Texte in leicht verständlicher Sprache erhöhen somit nicht nur die Barrierefreiheit, sondern unterstützen auch ein gutes SEO-Ranking. Ebenso besteht mit gut strukturierten Textelementen die Möglichkeit, ein „Featured Snippet“ zu erzielen.

Mehr zu unseren SEO Richtlinien

Optimierung für mobile Endgeräte

Unsere Web-Anwendungen müssen für mobile Endgeräte optimiert sein. Sie sollen den aktuell gültigen Mobile Best Practices entsprechen und eine einfache Bedienbarkeit für die Benutzerinnen und Benutzer ermöglichen.

Als Kriterium gilt: Unsere Web-Anwendungen müssen beim „Google Mobile Friendly Test“ ein grünes Rating haben. Die Vorschau-Funktion des Tests muss die Website so zeigen, wie Userinnen und User sie erwarten würden.

Web-Performance

Wenn die Performance einer Website unter den gängigen Standard fällt, wird die Seite von Suchmaschinen Anbietern (allen voran Google) im Suchergebnis (PageRank) nach hinten gereiht. Web-Anwendungen müssen daher den gängigen Performance-Standards hinsichtlich Antwortzeit, First-Byte, Ladezeiten und dergleichen entsprechen.

Als Kriterium gilt: Die serverseitige Reaktionszeit („Time to First Byte“) eines Aufrufs aus Österreich einer beliebigen Webpage der Applikation soll bei zirka 200ms liegen, niemals über 400ms. Die Applikation muss im „Google Page Speed Insights“-Test sowohl bei Desktop als auch mobil ein grünes Rating aufweisen.

Sitemap.xml Distributions-Logik

Web-Anwendungen müssen Seiten, die in Google oder anderen Suchmaschinen gefunden werden sollen, mittels sitemap.xml Logik an die Suchmaschinen kommunizieren.Über die sitemap.xml können Änderungen an der Struktur schneller und effizienter an Suchmaschinen kommuniziert werden. Dies erhöht speziell in Folge von Änderungen das Such-Ranking der einzelnen Seiten und vermindert die Fehlerrate.

HTML-Seiten, die gefunden werden sollen (nicht aber HTML-Seiten, die nicht gefunden werden sollen) werden in einer anwendungsspezifischen sitemap.xml gelistet. Je nach Anzahl der HTML-Seiten kann es sein, dass mehrere Unterversionen der sitemap.xml benötigt werden. Diese werden dann in einer applikationsspezifischen Sitemap-Index.xml gelistet. Die finale Sitemap.xml oder Sitemap-Index.xml wird in der /robots.txt der ausliefernden Domain gelistet.

Vermeidung extensiver URL-Kombinationen

Dynamisch erzeugte URL-Variationen (die etwa bei Web-Anwendungen mit Suchfunktionalität vorkommen können) führen zu einer unüberschaubaren und nicht verwaltbaren Anzahl von für Suchmaschinen-Crawler als relevant eingestuften URLs. Dadurch steigt die Durchlaufzeit für einen kompletten Crawl der Domain, was negative Auswirkungen auf die Aktualität der Suchergebnisse haben kann.

Systematische Verlinkungen wie Navigation, Paginierung (Aufteilung der Inhaltsanzeige auf mehrere Seiten) sowie damit verbundene Parametrisierung wie etwa Suchergebnisse dürfen nicht dazu führen, dass eine große oder unbekannt wachsende Anzahl von verschiedenen URL-Kombinationen (zum Beispiel mit unzähligen Parameter-Variationen) erzeugt werden.

Jegliche URL-Kombination, welche im Markup einer Website (verlinkt oder im onpage JavaScript) aufscheint, wird von Google gecrawlt. Werden nun große Mengen oder eine unbekannt wachsende Anzahl dieser URLs systematisch aufgrund der Navigationslogik (Navigation, Paginierung und dergleichen) erzeugt, werden diese von Suchmaschinen automatisch gecrawlt, anstatt aktualisierte Pages zeitgerecht abzuholen.

Korrekte Anzeige von Contents bei deaktiviertem JavaScript

Web-Anwendungen müssen den textlichen und bildlichen Content sowohl auf der Startseite als auch auf Unterseiten bei deaktiviertem JavaScript im Browser anzeigen. Die Darstellung der Seite kann aufgrund der deaktivierten JavaScript-Funktionen verändert sein. Die Deaktivierung von durch JavaScript gesteuerten Elementen oder Funktionalitäten hat keine negative Auswirkung auf die Suchmaschinen-Optimierung, solange die Information der Seite ohne JavaScript zugänglich ist.

Darstellung der Seite durch Google (= Fetch as Googlebot)

Web-Anwendungen mit öffentlich zugänglichen Seiten müssen die Informationen auch bei der Abfrage als Googlebot (Fetch as Googlebot) vollständig darstellen.

Als Kriterium gilt: Mithilfe des "Abruf wie durch Google"-Tests in der Google Search Console (Dashboard > Crawling > Abruf wie durch Google) muss eine Auswahl an Seiten der Web-Anwendung getestet werden. Im „Render“-Modus muss der Content der Seite sichtbar und das Design der Seite wie erwartet dargestellt werden. Im Fehlerreport unterhalb der Screenshots dürfen weder „-“ noch „Mittel“ oder „Hoch“-Fehler angezeigt werden.

Meta-Title, Meta-Description, URL, Überschrift unabhängig voneinander editierbar

Die Elemente „Meta-Title“, „Meta-Description“, „URL“ und „Überschrift“ von redaktionell verwalteten Seiten müssen im CMS so implementiert werden, dass es möglich ist, sie getrennt voneinander zu bearbeiten. Insbesondere muss es möglich sein, dass ein Element verändert wird, ohne dass eines der anderen genannten Elemente dadurch "automatisch" mitgeändert wird. Auch darf die Änderung nicht zur Erzeugung einer neuen HTML-Seite (auch nicht mit nur geänderten URL-Parametern) führen.

Eine „Standard-Logik“, die zum Beispiel die Überschrift einer Seite als Meta-Title setzt oder einen Text-Bestandteil als Meta-Description, ist möglich, solange es die Möglichkeit gibt, die so eingetragenen Inhalte der Tags nachträglich und unabhängig voneinander zu bearbeiten.

Strukturierung von redaktionellem Content via CMS-Editor

Bei der Eingabe von Content in einem CMS muss es möglich sein, die aktuell gültigen Regeln zur Content-Strukturierung einzuhalten.

Das CMS muss die Eingabe von Inhalten in Form von HTML-Tabellen, nummerierten oder ungeordneten Listen, Definitions-Listen, Zwischenüberschriften und Fließtext-Eingaben ermöglichen und diese auch am Frontend im richtigen semantischen Markup (tables, ul-li-lists, ol-li-lists, dt-dl-lists, h2, h3, ..., p) wiedergeben.

Kanonische Verlinkung (Meta-Tag Canonical)

Interne Verlinkungen sollen immer auf die kanonische (also die Haupt-)URL der verlinkten Ressource zeigen. Das bedeutet: Interne Links zeigen nicht auf Redirects oder auf URLs, welche unnötige Parameter beinhalten. Siehe dazu auch Kanonische URL-Logik.

Kanonische URL-Logik

Jede Seite einer Web-Anwendung setzt im HTML-Header die jeweils gültige, korrekte kanonische URL. Die kanonische URL muss im CMS editierbar sein und darf sich beispielsweise nicht vom Seitentitel ableiten.

Die kanonische URL ist im einfachsten Fall die URL der Seite ohne für die Content Darstellung nicht nötige Parameter.

<link rel="canonical" href="%%canonical URL%%" />

Noindex Meta Direktive

Es muss möglich sein, HTML-Seiten von der Indizierung durch Suchmaschinen-Crawler explizit mittels HTML-Tag im Header auszunehmen.
Im CMS ist es möglich einzelne HTML-Seiten auf

<meta name="robots" content="noindex">

als auch

<meta name="googlebot" content="noindex">

zu setzen.

Einfache URLs

Nur die Zeichen [0 bis 9], [a bis z], und [-] sind in URLs erlaubt.

In den redaktionell angelegten URLs sind nur Zeichen von [0 bis 9], [a bis z] und [-] erlaubt. Das beinhaltet, dass alle Bestandteile von URLs immer kleingeschrieben sind. Die Verwendung des Zeichens [-] am Anfang oder am Ende eines redaktionell gesetzten URL-Teils ist nicht erlaubt, auch können nie mehrere [-] hintereinander vorkommen. Wichtig: „underscores” [ _ ] sind in redaktionell gestalteten URL-Teilen nie erlaubt.

URL-Schema für Applikationen (Anwendungen)

• Dynamische Anwendungen können in kurzer Zeit Millionen von URLs erzeugen, was aus SEO-Perspektive ausgesprochen negative Folgen für das Portal hat
• Die URLs neuer außenwirksamer Anwendungen müssen daher mit der wien.gv.at Redaktion abgestimmt werden. Das gilt auch für Änderungen der Domain/URL bestehender wien.gv.at-Anwendungen
• Kleinere Formulare und Anwendungen werden unter der Subdomain https://anwendungen.wien.gv.at/namederanwendung/ veröffentlicht
• Für Anwendungen mit umfangreichen Funktionen oder Inhalten (zum Beispiel Kataloge) oder aus anderen technischen Gründen kann eine eigene Subdomain nach dem Schema applikationsname.wien.gv.at angefordert werden
• Für die Kommunikation kann ein „First Level Redirect“ verwendet werden

Mehr zur „Domain Policy“

Usability

Für eine erfolgreich umgesetzte Content Strategie ist eine kontinuierliche Zusammenarbeit der Redaktion, UX-Verantwortlichen, Designerinnen und Designern und Entwicklerinnen und Entwicklern notwendig. Gute User Experience bedeutet: Übersichtliche, gut strukturierte CMS-Elemente (Patterns), die von der wien.gv.at Redaktion mit leicht verständlichen Texten, aussagekräftigen Bildern und Videos gefüllt werden.

Da Web-Inhalte von den Nutzerinnen und Nutzern oft nur „gescannt“ werden, ist das entscheidend, damit die wichtigsten Inhalte rasch gefunden werden und die Wienerinnen und Wiener ein positives Erlebnis mit wien.gv.at haben.

Ob und wie gut das gelingt, wird laufend mit Analysetools (Siteimprove, Google Tools, et cetera) und unserer Test-Community überprüft.