Digital sozialisiert, Denker, Macher und Angel Investor.

Technische Qualität von Webanwendungen: Die Kriterien

T

Seit ein paar Jahren bin ich Jury-Präsident des Best of Swiss Web Awards und zwar in der Kategorie Technologie-Qualität. Bei der Bewertung der Projekte nutzt die Jury einen Kriterienkatalog, den ich bereits 2005 einmal publizierte. In der Zwischenzeit wurde der Katalog (zu Beginn jedes Bewertungsjahres) von der Jury bereits dreimal diskutiert und leicht angepasst. Es ist wiedermal an der Zeit, diesen zu zeigen. Und vor allem nehme ich gerne Vorschläge und Änderungen entgegen.
0. Mindestanforderungen (K.O.-Kriterien)
– Hauptleistung der Eingabe stammt aus dem Bewertungsjahr gem. Dokumentation
– Eigenleistung bei der Implementierung (gegenüber Standardprodukt)
– Anspruchsvoller Umfang und/oder Funktionalität
1. Performance / Verfügbarkeit
– Ladezeit (Server Wait Time, Seitengrösse [Codemenge relativ zu Inhalt], Auslagerung von Libraries) und/oder sonstige gute Tricks
– Nutzung von Standard Caching, Kompression und/oder HTTP keep-alive (resp. diese nicht unterbinden)
– Verfügbarkeit und Stabilität der Lösung (während der Jurierung)
2. Moderne Umsetzung
– Endgeräteunabhängige Umsetzung: Formate/Alternativen, Schriftgrössen, Textspalten, WAI etc.
– Moderner, valider Clientcodes, Einsatz von CSS
– Stateful URLs, REST wo sinnvoll
– Crossbrowser: Pro Zielplattform zwei wichtigsten User Agents unterstützt
3. Fehlertoleranz
– Angemessener Einsatz von JavaScript und/oder Cookies und/oder Plugins resp. angemessene Fehlerbehandlung bei Abschalten?
– Seitenübergreifende Prozesse: Validierung, Reload, Back Button, Enter bei Formular, – Fehlertexte und Erlenbarkeit (Konsistenz)
– Verhindern von Fehleingaben durch Beispiele, Erklärung, Hilfestellung etc.
4. Handwerk
– Fehler: Broken Links, Downloads (mime type, save as), Umgang mit Pop-Up Blocker etc.
Produktionsqualität der graphischen Seitenelemente: Visuell, Gewicht, Format etc.
– Korrekter Einsatz der HTTP Methoden (insb. GET / POST)
– Indexierbarkeit durch Suchmaschinen-Crawler (wo sinnvoll), Ranking und Titelzitat in Trefferlisten
5. Sicherheit
– Angemessener Login-Mechanismus: Gegenseitige Authentisierung (Phishing), Nicht-Wiederholbarkeit, Resistent gegen Brute Force etc.
– Schutz des Datenaustauschs: SSL/https, Sniffing / Lesen über DOM / JavaScript, Cache, Man in the Middle, Secure Flag bei Cookie, etc.
– Resistenz bei Manipulation der URL, Cookies, hidden fields (Session Highjacking, XSS, Injection) etc.
6. Angemessenheit
– Gute Kombination aus Innovation und Pragmatismus
– Flexibilität und Erweiterbarkeit
– Angemessene Wahl der Technologie (Erwartungskonform und Effizient); Technologie für Nutzer «unsichtbar»
Danke für Feedback!

2 Kommentare

  • Zur Performance gibt es ja noch einige Forschungsergebnisse von Yahoo!, die sich als Best Practices übernehmen ließen:

    • CSS und JavaScript als externe Dateien und cachebar
    • CSS im head, JavaScript am Codeende unmittelbar vor dem </body>
    • JavaScript aggregiert und komprimiert
    • Nicht zu viele CSS-Dateien, Einbindung per link, nicht mit dem langsameren @import
    • Möglichst keine 301/302 Redirects
    • Möglichst keine CSS expressions

    Ansonsten wären Human Readable URLs noch ein Bonus. Semantisch korrektes Markup wäre für mich ebenfalls ein technisches Qualitätskriterium, auch wenn es sich mit Barrierefreiheit überschneidet.

    Die Sinnhaftigkeit von AJAX wäre ein weiterer Punkt. Bei verwandt.de gibt es z.B. im Profil so eine Art Brotkrumenpfad, wie mein Ahne mit mir verwandt ist. Das ginge effizienter serverseitig; es gibt keinen ersichtlichen Vorteil oder Grund, warum dies clientseitig gelöst werden muß. Im Gegenteil, dadurch entstehen weitere HTTP-Requests, und dabei ist deren Server ohnehin überlastet.

  • Hi Martin und danke für die Rückmeldung.
    Ein «Human Readable ULRs» haben wir als «REST» drin (aber es sind ja nicht alle Anwendungen mit State).
    Die Yahoo-Kriterien finde ich (auch) gut und wären tatsächlich eine nützliche Erweiterung des Katalogs… Meist kleben die getesteten Anwendungen aber bei Server Wait Time rum und Y! käme dann viiiel später 😉
    Über die Sinnhaftigkeit lässt sich gut nach ein paar Bier diskutieren… Dein Beispiel ist wohl so, dass die Base Page statisch ausgeliefert wird, der Breadcrumb aber dynamisch (wäre in Deinen Beispiel zwar unsinnig). Da der dynamische Request lahm ist, verstecke die diesen mit einem asynchronen Aufruf… aber wie Du sagt: Sinnhaftigkeit.

Von Jürg Stuker
Digital sozialisiert, Denker, Macher und Angel Investor.