<edition W3.de>

Hinweis: Bei der hier zur Verfügung gestellten BITV handelt es sich um eine nichtamtliche Fassung, die aufgrund ihrer thematischen Nähe zu Webstandards, insbesondere den Zugänglichkeitsrichtlinien für Web-Inhalte, zu Informationszwecken hier angeboten wird. Die amtliche Fassung entnehmen Sie bitte dem Bundesgesetzblatt oder anderen amtlichen Quellen.

Die hier angebotene Fassung enthält Hyperlinks auf entsprechende Stellen der HTML-4- und CSS-2-Spezifikation. Obwohl sich die BITV nicht ausdrücklich auf diese Versionen bezieht, sollen die Hyperlinks die Verständlichkeit der BITV verbessern, da HTML 4 (bzw. das inhaltlich äquivalente XHTML 1) und CSS 2 derzeit die verbreitetsten Versionen der jeweiligen Technik darstellen.

Aufbereitung: Stefan Mintert, Linkwerk

Verordnung zur Schaffung barrierefreier Informationstechnik nach dem Behindertengleichstellungsgesetz (Barrierefreie Informationstechnik-Verordnung - BITV)

BITV

Ausfertigungsdatum: 17.07.2002

Eingangsformel

Auf Grund des § 11 Abs. 1 Satz 2 des Behindertengleichstellungsgesetzes vom 27. April 2002 (BGBl. I S. 1467) verordnet das Bundesministerium des Innern im Einvernehmen mit dem Bundesministerium für Arbeit und Sozialordnung:

§ 1 Sachlicher Geltungsbereich

Die Verordnung gilt für:

  1. Internetauftritte und -angebote,

  2. Intranetauftritte und -angebote, die öffentlich zugänglich sind, und

  3. mittels Informationstechnik realisierte grafische Programmoberflächen, die öffentlich zugänglich sind,

der Behörden der Bundesverwaltung.

§ 2 Einzubeziehende Gruppen behinderter Menschen

Die Gestaltung von Angeboten der Informationstechnik (§ 1) nach dieser Verordnung ist dazu bestimmt, behinderten Menschen im Sinne des § 3 des Behindertengleichstellungsgesetzes, denen ohne die Erfüllung zusätzlicher Bedingungen die Nutzung der Informationstechnik nur eingeschränkt möglich ist, den Zugang dazu zu eröffnen.

§ 3 Anzuwendende Standards

Die Angebote der Informationstechnik (§ 1) sind gemäß der Anlage zu dieser Verordnung so zu gestalten, dass
  1. alle Angebote die unter Priorität I aufgeführten Anforderungen und Bedingungen erfüllen und

  2. zentrale Navigations- und Einstiegsangebote zusätzlich die unter Priorität II aufgeführten Anforderungen und Bedingungen berücksichtigen.

§ 4 Umsetzungsfristen für die Standards

(1) Die in § 1 dieser Verordnung genannten Angebote, die nach Inkrafttreten dieser Verordnung neu gestaltet oder in wesentlichen Bestandteilen oder größerem Umfang verändert oder angepasst werden, sind gemäß § 3 dieser Verordnung zu erstellen. Mindestens ein Zugangspfad zu den genannten Angeboten soll mit der Freischaltung dieser Angebote die Anforderungen und Bedingungen der Priorität I der Anlage zu dieser Verordnung erfüllen. Spätestens bis zum 31. Dezember 2005 müssen alle Zugangspfade zu den genannten Angeboten die Anforderungen und Bedingungen der Priorität I der Anlage dieser Verordnung erfüllen.

(2) Angebote, die vor Inkrafttreten dieser Verordnung im Internet oder im Intranet (§ 1 Nr. 2) veröffentlicht wurden, sind bis zum 31. Dezember 2003 gemäß § 3 dieser Verordnung zu gestalten, wenn diese Angebote sich speziell an behinderte Menschen im Sinne des § 3 des Behindertengleichstellungsgesetzes richten.

(3) Soweit nicht Absatz 2 gilt, sind die Angebote, die vor Inkrafttreten dieser Verordnung im Internet oder im Intranet (§ 1 Nr. 2) veröffentlicht wurden, bis zum 31. Dezember 2005 gemäß § 3 dieser Verordnung zu gestalten.

§ 5 Folgenabschätzung

Die Verordnung ist unter Berücksichtigung der technischen Entwicklung regelmäßig zu überprüfen. Sie wird spätestens nach Ablauf von drei Jahren nach ihrem Inkrafttreten auf ihre Wirkung überprüft.

§ 6 Inkrafttreten

Diese Verordnung tritt am Tag nach der Verkündung in Kraft.

Anlage (zu den §§ 3 und 4 Abs. 1)

Fundstelle des Originaltextes: BGBl. I 2002, 2655 - 2662

Anlage (Teil 1)

Dieses Dokument enthält keine Vorgaben zur grundlegenden Technik, die für die Bereitstellung von elektronischen Inhalten und Informationen verwendet wird (Server, Router, Netzwerkarchitekturen und Protokolle, Betriebssysteme usw.) und hinsichtlich der zu verwendenden Benutzeragenten. Die Anforderungen und Bedingungen beziehen sich allein auf die der Nutzerin/dem Nutzer angebotenen elektronischen Inhalte und Informationen.
Die Anforderungen und Bedingungen dieser Anlage basieren grundsätzlich auf den Zugänglichkeitsrichtlinien für Web-Inhalte 1.0 (Web Content Accessibility Guidelines 1.0) des World Wide Web Consortiums vom 5. Mai 1999.
Die in Teil 1 dieser Anlage enthaltenen, bei ihrem ersten Auftreten im Text durch Unterstreichung kenntlich gemachten, grundlegenden technischen Fachbegriffe sind in Teil 2 dieser Anlage (Glossar) erläutert.
Priorität I
Anforderung 1 Für jeden Audio- oder visuellen Inhalt sind geeignete äquivalente Inhalte bereitzustellen, die den gleichen Zweck oder die gleiche Funktion wie der originäre Inhalt erfüllen.
Bedingung 1.1 Für jedes Nicht-Text-Element ist ein äquivalenter Text bereitzustellen. Dies gilt insbesondere für: Bilder, graphisch dargestellten Text einschließlich Symbolen, Regionen von Imagemaps, Animationen (z. B. animierte GIFs), Applets und programmierte Objekte, Zeichnungen, die auf der Verwendung von Zeichen und Symbolen des ASCII-Codes basieren (ASCII-Zeichnungen), Frames, Scripts, Bilder, die als Punkte in Listen verwendet werden, Platzhalter-Graphiken, graphische Buttons, Töne (abgespielt mit oder ohne Einwirkung des Benutzers), Audio-Dateien, die für sich allein stehen, Tonspuren von Videos und Videos.
  1.2 Für jede aktive Region einer serverseitigen Imagemap sind redundante Texthyperlinks bereitzustellen.
  1.3 Für Multimedia-Präsentationen ist eine Audio-Beschreibung der wichtigen Informationen der Videospur bereitzustellen.
  1.4 Für jede zeitgesteuerte Multimedia-Präsentation (insbesondere Film oder Animation) sind äquivalente Alternativen (z. B. Untertitel oder Audiobeschreibungen der Videospur) mit der Präsentation zu synchronisieren.
Anforderung 2 Texte und Graphiken müssen auch dann verständlich sein, wenn sie ohne Farbe betrachtet werden.
Bedingung 2.1 Alle mit Farbe dargestellten Informationen müssen auch ohne Farbe verfügbar sein, z. B. durch den Kontext oder die hierfür vorgesehenen Elemente der verwendeten Markup-Sprache.
  2.2 Bilder sind so zu gestalten, dass die Kombinationen aus Vordergrund- und Hintergrundfarbe auf einem Schwarz-Weiß-Bildschirm und bei der Betrachtung durch Menschen mit Farbfehlsichtigkeiten ausreichend kontrastieren.
Anforderung 3 Markup-Sprachen (insbesondere HTML) und Stylesheets sind entsprechend ihrer Spezifikationen und formalen Definitionen zu verwenden.
Bedingung 3.1 Soweit eine angemessene Markup-Sprache existiert, ist diese anstelle von Bildern zu verwenden, um Informationen darzustellen.
  3.2 Mittels Markup-Sprachen geschaffene Dokumente sind so zu erstellen und zu deklarieren, dass sie gegen veröffentliche formale Grammatiken validieren.
  3.3 Es sind Stylesheets zu verwenden, um die Text- und Bildgestaltung sowie die Präsentation von mittels Markup-Sprachen geschaffener Dokumente zu beeinflussen.
  3.4 Es sind relative anstelle von absoluten Einheiten in den Attributwerten der verwendeten Markup-Sprache und den Stylesheet-Property-Werten zu verwenden.
  3.5 Zur Darstellung der Struktur von mittels Markup-Sprachen geschaffener Dokumente sind Überschriften-Elemente zu verwenden.
  3.6 Zur Darstellung von Listen und Listenelementen sind die hierfür vorgesehenen Elemente der verwendeten Markup-Sprache zu verwenden.
  3.7 Zitate sind mittels der hierfür vorgesehenen Elemente der verwendeten Markup-Sprache zu kennzeichnen.
Anforderung 4 Sprachliche Besonderheiten wie Wechsel der Sprache oder Abkürzungen sind erkennbar zu machen.
Bedingung 4.1 Wechsel und Änderungen der vorherrschend verwendeten natürlichen Sprache sind kenntlich zu machen.
Anforderung 5 Tabellen sind mittels der vorgesehenen Elemente der verwendeten Markup-Sprache zu beschreiben und in der Regel nur zur Darstellung tabellarischer Daten zu verwenden.
Bedingung 5.1 In Tabellen, die tabellarische Daten darstellen, sind die Zeilen- und Spaltenüberschriften mittels der vorgesehenen Elemente der verwendeten Markup-Sprache zu kennzeichnen.
  5.2 Soweit Tabellen, die tabellarische Daten darstellen, zwei oder mehr Ebenen von Zeilen- und Spaltenüberschriften aufweisen, sind mittels der vorgesehenen Elemente der verwendeten Markup-Sprache Datenzellen und Überschriftenzellen einander zuzuordnen.
  5.3 Tabellen sind nicht für die Text- und Bildgestaltung zu verwenden, soweit sie nicht auch in linearisierter Form dargestellt werden können.
  5.4 Soweit Tabellen zur Text- und Bildgestaltung genutzt werden, sind keine der Strukturierung dienenden Elemente der verwendeten Markup-Sprache zur visuellen Formatierung zu verwenden.
Anforderung 6 Internetangebote müssen auch dann nutzbar sein, wenn der verwendete Benutzeragent neuere Technologien nicht unterstützt oder diese deaktiviert sind.
Bedingung 6.1 Es muss sichergestellt sein, dass mittels Markup-Sprachen geschaffene Dokumente verwendbar sind, wenn die zugeordneten Stylesheets deaktiviert sind.
  6.2 Es muss sichergestellt sein, dass Äquivalente für dynamischen Inhalt aktualisiert werden, wenn sich der dynamische Inhalt ändert.
  6.3 Es muss sichergestellt sein, dass mittels Markup-Sprachen geschaffene Dokumente verwendbar sind, wenn Scripts, Applets oder andere programmierte Objekte deaktiviert sind.
  6.4 Es muss sichergestellt sein, dass die Eingabebehandlung von Scripts, Applets oder anderen programmierten Objekten vom Eingabegerät unabhängig ist.
  6.5 Dynamische Inhalte müssen zugänglich sein. Insoweit dies nur mit unverhältnismäßig hohem Aufwand zu realisieren ist, sind gleichwertige alternative Angebote unter Verzicht auf dynamische Inhalte bereitzustellen.
Anforderung 7 Zeitgesteuerte Änderungen des Inhalts müssen durch die Nutzerin/den Nutzer kontrollierbar sein.
Bedingung 7.1 Bildschirmflackern ist zu vermeiden.
  7.2 Blinkender Inhalt ist zu vermeiden.
  7.3 Bewegung in mittels Markup-Sprachen geschaffener Dokumente ist entweder zu vermeiden oder es sind Mechanismen bereitzustellen, die der Nutzerin/dem Nutzer das Einfrieren der Bewegung oder die Änderung des Inhalts ermöglichen.
  7.4 Automatische periodische Aktualisierungen in mittels Markup-Sprachen geschaffener Dokumente sind zu vermeiden.
  7.5 Die Verwendung von Elementen der Markup-Sprache zur automatischen Weiterleitung ist zu vermeiden. Insofern auf eine automatische Weiterleitung nicht verzichtet werden kann, ist der Server entsprechend zu konfigurieren.
Anforderung 8 Die direkte Zugänglichkeit der in Internetangeboten eingebetteten Benutzerschnittstellen ist sicherzustellen.
Bedingung 8.1 Programmierte Elemente (insbesondere Scripts und (Applets) sind so zu gestalten, dass sie entweder direkt zugänglich oder kompatibel mit assistiven Technologien sind.
Anforderung 9 Internetangebote sind so zu gestalten, dass Funktionen unabhängig vom Eingabegerät oder Ausgabegerät nutzbar sind.
Bedingung 9.1 Es sind clientseitige Imagemaps bereitzustellen, es sei denn, die Regionen können mit den verfügbaren geometrischen Formen nicht definiert werden.
  9.2 Jedes über eine eigene Schnittstelle verfügende Element muss in geräteunabhängiger Weise bedient werden können.
  9.3 In Scripts sind logische anstelle von geräteabhängigen Event-Handlern zu spezifizieren.
Anforderung 10 Die Verwendbarkeit von nicht mehr dem jeweils aktuellen Stand der Technik entsprechenden assistiven Technologien und Browsern ist sicherzustellen, soweit der hiermit verbundene Aufwand nicht unverhältnismäßig ist.
Bedingung 10.1 Das Erscheinenlassen von Pop-Ups oder anderen Fenstern ist zu vermeiden. Die Nutzerin/der Nutzer ist über Wechsel der aktuellen Ansicht zu informieren.
  10.2 Bei allen Formular-Kontrollelementen mit implizit zugeordneten Beschriftungen ist dafür Sorge zu tragen, dass die Beschriftungen korrekt positioniert sind.
Anforderung 11 Die zur Erstellung des Internetangebots verwendeten Technologien sollen öffentlich zugänglich und vollständig dokumentiert sein, wie z. B. die vom World Wide Web Consortium entwickelten Technologien.
Bedingung 11.1 Es sind öffentlich zugängliche und vollständig dokumentierte Technologien in ihrer jeweils aktuellen Version zu verwenden, soweit dies für die Erfüllung der angestrebten Aufgabe angemessen ist.
  11.2 Die Verwendung von Funktionen, die durch die Herausgabe neuer Versionen überholt sind, ist zu vermeiden.
  11.3 Soweit auch nach bestem Bemühen die Erstellung eines barrierefreien Internetangebots nicht möglich ist, ist ein alternatives, barrierefreies Angebot zur Verfügung zu stellen, dass äquivalente Funktionalitäten und Informationen gleicher Aktualität enthält, soweit es die technischen Möglichkeiten zulassen. Bei Verwendung nicht barrierefreier Technologien sind diese zu ersetzen, sobald aufgrund der technologischen Entwicklung äquivalente, zugängliche Lösungen verfügbar und einsetzbar sind.
Anforderung 12 Der Nutzerin/dem Nutzer sind Informationen zum Kontext und zur Orientierung bereitzustellen.
Bedingung 12.1 Jeder Frame ist mit einem Titel zu versehen, um Navigation und Identifikation zu ermöglichen.
  12.2 Der Zweck von Frames und ihre Beziehung zueinander ist zu beschreiben, soweit dies nicht aus den verwendeten Titeln ersichtlich ist.
  12.3 Große Informationsblöcke sind mittels Elementen der verwendeten Markup-Sprache in leichter handhabbare Gruppen zu unterteilen.
  12.4 Beschriftungen sind genau ihren Kontrollelementen zuzuordnen.
Anforderung 13 Navigationsmechanismen sind übersichtlich und schlüssig zu gestalten.
Bedingung 13.1 Das Ziel jedes Hyperlinks muss auf eindeutige Weise identifizierbar sein.
  13.2 Es sind Metadaten bereitzustellen, um semantische Informationen zu Internetangeboten hinzuzufügen.
  13.3 Es sind Informationen zur allgemeinen Anordnung und Konzeption eines Internetangebots, z. B. mittels eines Inhaltsverzeichnisses oder einer Sitemap, bereitzustellen.
  13.4 Navigationsmechanismen müssen schlüssig und nachvollziehbar eingesetzt werden.
Anforderung 14 Das allgemeine Verständnis der angebotenen Inhalte ist durch angemessene Maßnahmen zu fördern.
Bedingung 14.1 Für jegliche Inhalte ist die klarste und einfachste Sprache zu verwenden, die angemessen ist.
Priorität II
Anforderung 1 Für jeden Audio- oder visuellen Inhalt sind geeignete äquivalente Inhalte bereitzustellen, die den gleichen Zweck oder die gleiche Funktion wie der originäre Inhalt erfüllen.
Bedingung 1.5 Für jede aktive Region einer clientseitigen Imagemap sind redundante Texthyperlinks bereitzustellen.
Anforderung 2 Texte und Graphiken müssen auch denn verständlich sein, wenn sie ohne Farbe betrachtet werden.
Bedingung 2.3 Texte sind so zu gestalten, dass die Kombinationen aus Vordergrund- und Hintergrundfarbe auf einem Schwarz-Weiß-Bildschirm und bei der Betrachtung durch Menschen mit Farbfehlsichtigkeiten ausreichend kontrastieren.
Anforderung 3 Markup-Sprachen (insbesondere HTML) und Stylesheets sind entsprechend ihrer Spezifikationen und formalen Definitionen zu verwenden.
Anforderung 4 Sprachliche Besonderheiten wie Wechsel der Sprache oder Abkürzungen sind erkennbar zu machen.
Bedingung 4.2 Abkürzungen und Akronyme sind an der Stelle ihres ersten Auftretens im Inhalt zu erläutern und durch die hierfür vorgesehenen Elemente der verwendeten Markup-Sprache kenntlich zu machen.
  4.3 Die vorherrschend verwendete natürliche Sprache ist durch die hierfür vorgesehenen Elemente der verwendeten Markup-Sprache kenntlich zu machen.
Anforderung 5 Tabellen sind mittels der vorgesehenen Elemente der verwendeten Markup-Sprache zu beschreiben und in der Regel nur zur Darstellung tabellarischer Daten zu verwenden.
Bedingung 5.5 Für Tabellen sind unter Verwendung der hierfür vorgesehenen Elemente der genutzten Markup-Sprache Zusammenfassungen bereitzustellen.
  5.6 Für Überschriftenzellen sind unter Verwendung der hierfür vorgesehenen Elemente der genutzten Markup-Sprache Abkürzungen bereitzustellen.
Anforderung 6 Internetangebote müssen auch dann nutzbar sein, wenn der verwendete Benutzeragent neuere Technologien nicht unterstützt oder diese deaktiviert sind.
Anforderung 7 Zeitgesteuerte Änderungen des Inhalts müssen durch die Nutzerin/den Nutzer kontrollierbar sein.
Anforderung 8 Die direkte Zugänglichkeit der in Internetangeboten eingebetteten Benutzerschnittstellen ist sicherzustellen.
Anforderung 9 Internetangebote sind so zu gestalten, dass Funktionen unabhängig vom Eingabegerät oder Ausgabegerät nutzbar sind.
Bedingung 9.4 Es ist eine mit der Tabulatortaste navigierbare, nachvollziehbare und schlüssige Reihenfolge von Hyperlinks, Formularkontrollelementen und Objekten festzulegen.
  9.5 Es sind Tastaturkurzbefehle für Hyperlinks, die für das Verständnis des Angebots von entscheidender Bedeutung sind (einschließlich solcher in clientseitigen Imagemaps), Formularkontrollelemente und Gruppen von Formularkontrollelementen bereitzustellen.
Anforderung 10 Die Verwendbarkeit von nicht mehr dem jeweils aktuellen Stand der Technik entsprechenden assistiven Technologien und Browsern ist sicherzustellen, soweit der hiermit verbundene Aufwand nicht unverhältnismäßig ist.
Bedingung 10.3 Für alle Tabellen, die Text in parallelen Spalten mit Zeilenumbruch enthalten, ist alternativ linearer Text bereitzustellen.
  10.4 Leere Kontrollelemente in Eingabefeldern und Textbereichen sind mit Platzhalterzeichen zu versehen.
  10.5 Nebeneinander liegende Hyperlinks sind durch von Leerzeichen umgebene, druckbare Zeichen zu trennen.
Anforderung 11 Die zur Erstellung des Internetangebots verwendeten Technologien sollen öffentlich zugänglich und vollständig dokumentiert sein, wie z. B. die vom World Wide Web Consortium entwickelten Technologien.
Bedingung 11.4 Der Nutzerin/dem Nutzer sind Informationen bereitzustellen, die es ihnen erlauben, Dokumente entsprechend ihren Vorgaben (z. B. Sprache) zu erhalten.
Anforderung 12 Der Nutzerin/dem Nutzer sind Informationen zum Kontext und zur Orientierung bereitzustellen.
Anforderung 13 Navigationsmechanismen sind übersichtlich und schlüssig zu gestalten.
Bedingung 13.5 Es sind Navigationsleisten bereitzustellen, um den verwendeten Navigationsmechanismus hervorzuheben und einen Zugriff darauf zu ermöglichen.
  13.6 Inhaltlich verwandte oder zusammenhängende Hyperlinks sind zu gruppieren. Die Gruppen sind eindeutig zu benennen und müssen einen Mechanismus enthalten, der das Umgehen der Gruppe ermöglicht.
  13.7 Soweit Suchfunktionen angeboten werden, sind der Nutzerin/dem Nutzer verschiedene Arten der Suche bereitzustellen.
  13.8 Es sind aussagekräftige Informationen am Anfang von inhaltlich zusammenhängenden Informationsblöcken (z. B. Absätzen, Listen) bereitzustellen, die eine Differenzierung ermöglichen.
  13.9 Soweit inhaltlich zusammenhängende Dokumente getrennt angeboten werden, sind Zusammenstellungen dieser Dokumente bereitzustellen.
  13.10 Es sind Mechanismen zum Umgehen von ASCII-Zeichnungen bereitzustellen.
Anforderung 14 Das allgemeine Verständnis der angebotenen Inhalte ist durch angemessene Maßnahmen zu fördern.
Bedingung 14.2 Text ist mit graphischen oder Audio-Präsentationen zu ergänzen, sofern dies das Verständnis der angebotenen Information fördert.
  14.3 Der gewählte Präsentationsstil ist durchgängig beizubehalten.

Anlage (Teil 2): Glossar

Applet Kurz für "Application". Meist in der Programmiersprache Java verfasstes, in ein Internetangebot eingefügtes Programm.
ASCII-Zeichnungen "American Standard Code For Information Interchange"; ein Zeichensatz, der es erlaubt, nummerischen Werten (Bytes) Zeichen der gebräuchlichen Schriftsprache zuzuordnen. ASCII-Zeichnungen sind Bilder, die durch die Kombination von Zeichen und Symbolen des ASCII-Zeichensatzes entstehen (z. B. Emoticons).
Assistive Technologien Software oder Hardware, die speziell entwickelt wurde, um behinderten Menschen bei ihren täglichen Aktivitäten zu helfen. Assistive Technologien sind z. B. Rollstühle, Lesegeräte, Geräte zum Greifen usw. Gängige assistive Technologien im Bereich der Vermittlung von Internetinhalten sind Screenreader, Bildschirmlupen, Sprachgeneratoren und Spracheingabe-Software, die in Verbindung mit graphischen Desktop-Browsern (neben anderen Benutzeragenten) eingesetzt werden. Assistive Hardware-Technologien sind u. a. alternative Tastaturen und Zeigegeräte.
Attributwert Befehle in Programmiersprachen können zusätzliche Angaben zur Beschreibung des Befehls in Form von Attributen enthalten. Diese Attribute können durch Wertangaben näher bestimmt werden.
Ausgabegerät Stellt der Nutzerin/dem Nutzer die verarbeiteten Daten zur Verfügung. Beispiele für Ausgabegeräte sind Monitore, Drucker, Lautsprecher oder Braille-Zeilen.
Benutzeragent Software zum Zugriff auf Internetinhalte; dies umfasst graphische Desktop-Browser, Text-Browser, Sprach-Browser, Mobiltelefone, Multimedia-Player und manche assistive Software-Technologien, die in Verbindung mit Browsern verwendet werden, wie etwa Screenreader, Bildschirmlupen und Spracherkennungssoftware.
Benutzerschnittstellen Ermöglichen Eingaben der Nutzerin/des Nutzers und legen deren Darstellung fest.
Browser Programm, das den Zugriff auf und die Darstellung von Angeboten im Internet erlaubt.
Button Mittels Graphiken dargestellte Schaltflächen.
Client, clientseitig Softwareprogramm in Netzwerken, in der Regel auf dem lokalen Computer der Nutzerin/des Nutzers, das von Servern bereitgestellte Dienste in Anspruch nimmt. Clients fordern entweder Daten von Servern an (z. B. Browser) oder versenden Daten an Server (z. B. E-Mail). Clientseitig ist eine Funktionalität dann, wenn sie auf dem Client ausgeführt wird.
Dynamische Inhalte Sammelbegriff für verschiedenartige Mechanismen, Inhalte während ihrer Anzeige dynamisch zu ändern, entweder automatisch oder durch Einwirken der Nutzerin/des Nutzers.
Eingabegeräte Ermöglicht die Interaktion mit dem elektronischen Medium. Beispiele für Eingabegeräte sind Tastaturen, Computer-Mäuse, Blindenschriftgeräte, Kopfstäbe oder Mikrophone.
Event-Handler "Ereignis-Behandler", werden meist als Attribute in Befehlen der HTML-Programmiersprache notiert und lösen bei Aktivierung durch die Nutzerin/den Nutzer eine vordefinierte Reaktion, in der Regel ein weiteres Programm (z. B. ein Script), aus.
Frames Definierbare Segmente, die den Anzeigebereich eines Browsers aufteilen. Jedes Anzeigesegment kann eigene Inhalte enthalten.
GIF "Graphics Interchange Format"; ein Dateiformat zur Darstellung von Graphiken. Animierte GIFs enthalten in einer Datei mehrere Graphiken, die nacheinander angezeigt werden und dadurch den Eindruck von Bewegung vermitteln.
HTML Siehe "Markup-Sprache".
Hyperlink Verweis in einem elektronischen Dokument auf ein beliebiges Verweisziel. Das Verweisziel kann sich in jeder über den elektronischen Datenaustausch erreichbaren Quelle befinden.
Imagemaps Verweis-sensitive Graphiken; Graphiken, die in Regionen mit zugeordneten Aktionen unterteilt wurden. Die Betätigung einer aktiven Region löst eine Aktion aus.
Linearisierte Tabelle Ein Verfahren der Tabellendarstellung, bei der die Inhalte der Zellen zu einer Folge von Absätzen werden. Die Absätze erscheinen in derselben Reihenfolge, in der die Zellen im ursprünglichen Dokument definiert sind.
Markup-Sprache "Auszeichnungssprachen"; Kategorie von Programmiersprachen, die z. B. HTML (Hyper Text Markup Language) oder XML (Extensible Markup Language) umfasst. Auszeichnungssprachen basieren auf der in der ISO-Norm 8879 festgelegten SGML (Standard Generalized Markup Language). Sie dienen, in ihren spezifischen Anwendungsgebieten, zur logischen Beschreibung von Inhalten, zum Datenaustausch oder zur Definition weiterer Auszeichnungssprachen.
Metadaten Informationen über die verwendeten Daten oder Inhalte.
Multimedia Die Verbindung mehrerer Medien wie Text, Bild, Ton oder dreidimensionaler Simulation zu einer geschlossenen elektronischen Präsentation.
Natürliche Sprache Gesprochene, geschriebene oder durch Zeichen dargestellte Sprachen wie Deutsch, aber auch Gebärdensprache oder Blindenschrift.
Pop-Ups Neu erscheinender Anzeigebereich bzw. Fenster. Durch die Nutzerin/den Nutzer in der Regel nicht zu steuernder Prozess.
Script In einer speziellen Programmiersprache ("Script-Sprache" wie z. B. JavaScript) verfasstes Programm.
Server, serverseitig Softwareprogramm, das auf einem Hostrechner ausgeführt wird und in Netzwerken anderen Rechnern, auf denen Clientsoftware ausgeführt wird, Dienste (z. B. Websites, E-Mail) zur Verfügung stellt. Serverseitig ist eine Funktionalität dann, wenn sie auf dem Server ausgeführt wird.
Sitemap Gesamtübersicht über den Aufbau eines Internetangebots.
Stylesheet, Stylesheet-Property-Wert CSS (Cascading Stylesheets) ist eine Ergänzungssprache zu HTML, die die Spezifizierung der Präsentation eines Dokumentes ermöglicht. Sie erlaubt das beliebige Formatieren einzelner HTML-Elemente oder das Definieren zentraler Formate in Dokumenten. Property-Werte enthalten Wertzuweisungen für die festgelegten Formate.
Tabellarische Daten Tabellen, die dazu verwendet werden, logische Beziehungen zwischen Daten zu repräsentieren, enthalten tabellarische Daten. Den Gegensatz hierzu bilden Tabellen, die nur der Formatierung bzw. Text- und Bildgestaltung von Dokumenten dienen.

Ein Linkwerk-Projekt

Webnews Feed Die wichtigsten Webfeeds auf einem Blick - zusammengestellt von <edition W3.de>

12. Sep 2014
This week's sponsor: Stack
<p><a href="http://synd.co/1rU5flH">Stack</a> is a simple task management system for devs and designers. <a href="http://synd.co/1rU5flH">Fully customizable and flexible to suit your workflow.</a></p><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/a7IcO0GUxWQ" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)
11. Sep 2014
Web Accessibility Tutorials on Images and Tables
The WAI Education and Outreach Working Group (EOWG) has published Web Accessibility Tutorials on Images and Tables. Additional tutorials will be announced soon. These tutorials show you how to create web content that is accessible to people with disabilities and that improves the user experience for all users. They include general guidance, and specific examples [&#8230;][mehr] (Quelle: W3C News)
11. Sep 2014
CSS Display Module Level 3 Draft Published
The Cascading Style Sheets (CSS) Working Group has published a Working Draft of CSS Display Module Level 3. This module describes how the CSS formatting box tree is generated from the document element tree and defines the display and box-suppress properties that control it. CSS is a language for describing the rendering of structured documents [&#8230;][mehr] (Quelle: W3C News)
11. Sep 2014
Rian van der Merwe on A View from a Different Valley: Work Life Imbalance
<p>I’m old enough to remember when laptops entered the workforce. It was an amazing thing. At first only the select few could be seen walking around with their giant black IBMs and silver Dells. It took a few years, but eventually every new job came with the question we all loved to hear: “desktop or laptop?”</p> <p>I was so happy when I got my first laptop at work. “Man,” I thought, “now I can work anywhere, any time!” It was fun for a while, until I realized that now I could work anywhere, any time. Slowly our office started to reflect this newfound freedom. Work looked less and less like work, and more and more like home. Home offices became a big thing, and it’s now almost impossible to distinguish between home offices of famous designers and the workspaces (I don’t think we even call them “offices” any more) of most startups.</p> <h2>Work and life: does it blend?</h2> <p>There is a blending of work and life that woos us with its promise of barbecues at work and daytime team celebrations at movie theaters, but we’re paying for it in another way: a complete eradication of the line between home life and work life. “Love what you do,” we say. “Get a job you don’t want to take a vacation from,” we say—and we sit back and watch the retweets stream in.</p> <p>I don’t like it.</p> <p>I don’t like it for two reasons.</p> <h3>It makes us worse at our jobs</h3> <p>There’s plenty of research that shows when employers place strict limits on messaging, employees are happier and enjoy their work more. <i>And</i> productivity isn’t affected negatively at all. Clive Thompson’s <a href="http://www.motherjones.com/environment/2014/04/smartphone-addiction-research-work-email">article about this for Mother Jones</a> is a great overview of what we know about the handful of experiments that have been done to research the effects of messaging limits.</p> <p>But that’s not even the whole story. It’s not just that constantly thinking about work makes us more stressed, it’s also that our fear of doing nothing—of not being productive every second of the day—is hurting us as well (we’ll talk about side projects another time). There’s plenty of research about this as well, but let’s stick with Jessica Stillman’s <a href="http://www.inc.com/jessica-stillman/bored-at-work-good.html">Bored at Work? Good</a>. It’s a good overview of what scientists have found on the topic of giving your mind time to rest. In short, being idle tells your brain that it’s in need of something different, which stimulates creative thinking. So it’s something to be sought out and cherished—not something to be shunned.</p> <figure class="quote"> <blockquote> <p>Sometimes when things clear away and you’re not watching anything and you’re in your car and you start going, oh no, here it comes, that I’m alone, and it starts to visit on you, just this sadness. And that’s why we text and drive. People are willing to risk taking a life and ruining their own because they don’t want to be alone for a second because it’s so hard.</p> </blockquote> <figcaption><a href="https://www.youtube.com/watch?v=5HbYScltf1c">Louis C. K.</a></figcaption> </figure> <h3>It teaches that boundaries are bad</h3> <p>The second problem I have with our constant pursuit of the productivity train is that it teaches us that setting boundaries to spend time with our friends and family = laziness. I got some raised eyebrows at work recently when I declined an invitation to watch a World Cup game in a conference room. But here’s the thing. If I watch the World Cup game with a bunch of people at work today, guess what I have to do tonight? I have to work to catch up, instead of spending time with my family. And that is not ok with me.</p> <p>I have a weird rule about this. Work has me—completely—between the hours of 8:30 a.m. and 6:00 p.m. It has 100 percent of my attention. But outside of those hours I consider it part of being a sane and good human to give my kids a bath, chat to my wife, read, and reflect on the day that’s past and the one that’s coming—without the pressure of having to be online all the time. I swear it makes me a better (and more productive) employee, but I can’t shake the feeling that I shouldn’t be writing this down because you’re just going to think I’m lazy.</p> <p>But hey, I’m going to face my fear and just come right out and say it: I try not to work nights. There. That felt good.</p> <p>It doesn’t always work out, and of course there are times when a need is pressing and I take care of it at night. I don’t have a problem with that. But I don’t sit and do email for hours every night. See, the time I spend with people is what gives my work meaning. I do what I do for <i>them</i>—for the people in my life, the people I know, and the people I don’t. If we never spend time away from our work, how can we understand the world and the people we make things for?</p> <figure class="quote"> <blockquote> <p>Of course, the remaking of the contemporary tech office into a mixed work-cum-leisure space is not actually meant to promote leisure. Instead, the work/leisure mixing that takes place in the office mirrors what happens across digital, social and professional spaces. Work has seeped into our leisure hours, making the two tough to distinguish.</p> </blockquote> <figcaption>Kate Losse, <cite><a href="http://aeon.co/magazine/culture/what-tech-offices-tell-us-about-the-future-of-work/">Tech aesthetics</a></cite></figcaption> </figure> <h2>Permission to veg out</h2> <p>So I guess this column is my attempt to give you permission to do nothing every once in a while. Not to be lazy, or not do your job. But to take the time you need to get <i>better</i> at what you do, and enjoy it a lot more.</p> <p>As this column evolves, I think this is what I’ll be talking about a lot. How to make the hours we have at work count more. How to think of what we do not as <i>the tech business</i> but <i>the people business</i>. How to give ourselves permission to experience the world around us and get inspiration for our work from that. How to be <a href="http://en.wikipedia.org/wiki/Flâneur">flâneur</a>: wandering around with eyes wide open to inspiration.</p><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/y5ED310PGQE" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)
9. Sep 2014
W3C Invites Implementations of Vibration API; HTML Media Capture
The Device APIs Working Group invites implementation of two Candidate Recommendations: Vibration API. This specification defines an API that provides access to the vibration mechanism of the hosting device. Vibration is a form of tactile feedback. HTML Media Capture. This specification defines an HTML form extension that facilitates user access to a device&#8217;s media capture [&#8230;][mehr] (Quelle: W3C News)
9. Sep 2014
W3C Invites Implementations of CSS Backgrounds and Borders Module Level 3
The Cascading Style Sheets (CSS) Working Group invites implementation of the Candidate Recommendation of CSS Backgrounds and Borders Module Level 3. CSS is a language for describing the rendering of structured documents (such as HTML and XML) on screen, on paper, in speech, etc. This draft contains the features of CSS level 3 relating to [&#8230;][mehr] (Quelle: W3C News)
9. Sep 2014
Last Call: Linked Data Platform Paging 1.0
The Linked Data Platform (LDP) Working Group has published a Last Call Working Draft of Linked Data Platform Paging 1.0. This document describes a HTTP-based protocol for clients and servers to be able to efficiently retrieve large Linked Data Platform Resource representations by splitting up the responses into separate URL-addressable page resources. Comments are welcome [&#8230;][mehr] (Quelle: W3C News)
9. Sep 2014
Efficient XML Interchange (EXI) Profile for limiting usage of dynamic memory is a W3C Recommendation
The EXI Working Group published the Efficient XML Interchange (EXI) Profile for limiting usage of dynamic memory as W3C Recommendation. EXI 1.0 is a very efficient format to represent an XML Information Set. It is highly customizable to fit the need of diverse use cases, ranging from B2B applications down to embedded-systems use. It satisfies [&#8230;][mehr] (Quelle: W3C News)
8. Sep 2014
Awkward Cousins
<p>As an industry, we’re historically terrible at drawing lines between things. We try to segment devices based on screen size, but that doesn’t take into account hardware functionality, form factor, and usage context, for starters. The laptop I’m writing this on has the same resolution as a 1080p television. They’d be lumped into the same screen-size–dependent groups, but they are two totally different device classes, so how do we determine what goes together?</p> <p>That’s a simple example, but it points to a larger issue. We so desperately want to draw lines between things, but there are often too many variables to make those lines clean.</p> <p>Why, then, do we draw such strict lines between our roles on projects? What does the area of overlap between a designer and front-end developer look like? A front- and back-end developer? A designer and back-end developer? The old thinking of defined roles is certainly loosening up, but we still have a long way to go.</p> <p>The chasm between roles that is most concerning is the one between web designers/developers and native application designers/developers. We often choose a camp early on and stick to it, which is a mindset that may have been fueled by the false “native vs. web” battle a few years ago. It was positioned as an either-or decision, and hybrid approaches were looked down upon.</p> <p>The two camps of creators are drifting farther and farther apart, even as the products are getting closer and closer. <a href="https://twitter.com/gruber">John Gruber</a> <a href="http://daringfireball.net/2014/04/rethinking_what_we_mean_by_mobile_web">best described the overlap that users see</a>:</p> <figure class="quote"> <blockquote> <p>When I’m using Tweetbot, for example, much of my time in the app is spent reading web pages rendered in a web browser. Surely that’s true of mobile Facebook users, as well. What should that count as, “app” or “web”?</p> <p>I publish a website, but tens of thousands of my most loyal readers consume it using RSS apps. What should they count as, “app” or “web”?.</p> </blockquote> </figure> <p>The people using the things we build don’t see the divide as harshly as we do, if at all. More importantly, the development environments are becoming more similar, as well. <a href="https://developer.apple.com/swift/">Swift</a>, Apple’s brand new programming language for iOS and Mac development, has a strong resemblance to the languages we know and love on the web, and that’s no accident. One of Apple’s top targets for Swift, if not the top target, is the web development community. It’s a massive, passionate, and talented pool of developers who, largely, have not done iOS or Mac work—yet.</p> <p>As someone who spans the divide regularly, it’s sad to watch these two communities keep at arm’s length like awkward cousins at a family reunion. We have so much in common—interests, skills, core values, and a ton of technological ancestry. The difference between the things we build is shrinking in the minds of our shared users, and the ways we build those things are aligning. I dream of the day when we get over our poorly drawn lines and become the big, happy community I know we can be.</p> <p>At the very least, please <a href="http://inessential.com/">start</a> <a href="http://betterelevation.com/">reading</a> <a href="http://www.marco.org/">each</a> <a href="http://shapeof.com/">other’s</a> <a href="http://indiestack.com/">blogs</a>.</p><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/EHHe_O6Fs_I" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)
4. Sep 2014
Watch: A New Documentary About Jeffrey Zeldman
<figure class="quote"> <blockquote>You keep it by giving it away.</blockquote><figcaption>Jeffrey Zeldman</figcaption> </figure> <p>It&#8217;s a philosophy that&#8217;s always guided us at <cite>A List Apart</cite>: that we all learn more—and are more successful—when we share what we know with anyone who wants to listen. And it comes straight from our publisher, Jeffrey Zeldman. </p> <p>For 20 years, he&#8217;s been sharing everything he can with us, the people who make websites—from advice on table layouts in the &#8216;90s to <cite>Designing With Web Standards</cite> in the 2000s to educating the next generation of designers today.&nbsp; </p> <p>Our friends at <a href="http://lynda.com">Lynda.com</a> just released a documentary highlighting Jeffrey&#8217;s two decades of designing, organizing, and most of all sharing on the web. You should watch it. </p> <figure> <iframe src="//player.vimeo.com/video/104641191" width="696" height="391" frameborder="0" webkitallowfullscreen mozallowfullscreen allowfullscreen></iframe> <p><a href="http://vimeo.com/104641191">Jeffrey Zeldman: 20 years of Web Design and Community</a> from <a href="http://vimeo.com/lyndavimeo">lynda.com</a>.</p> </figure><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/A3SQgQU507M" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)
2. Sep 2014
Make patent commitments for the URL standard
The WHATWG is starting down the road of getting patent commitments for its standards. You can be part of this! First, create an account with the W3C's community group system. Then, join the WHATWG community group. Then make the patent commitment by following the instructions on this page (pick the first radio button, then click [&#8230;][mehr] (Quelle: The WHATWG Blog)
2. Sep 2014
Git: The Safety Net for Your Projects
<p>I remember January 10, 2010, rather well: it was the day we lost a project&#8217;s complete history. We were using Subversion as our version control system, which kept the project&#8217;s history in a central repository on a server. And we were backing up this server on a regular basis—at least, we thought we were. The server broke down, and then the backup failed. Our project wasn&#8217;t completely lost, but all the historic versions were gone. </p> <p>Shortly after the server broke down, we switched to Git. I had always seen version control as torturous; it was too complex and not useful enough for me to see its value, though I used it as a matter of duty. But once we’d spent some time on the new system, and I began to understand just how helpful Git could be. Since then, it has saved my neck in many situations.</p> <p>During the course of this article, I&#8217;ll walk through how Git can help you avoid mistakes—and how to recover if they&#8217;ve already happened.</p> <h2>Every teammate is a backup</h2> <p>Since Git is a distributed version control system, every member of our team that has a project cloned (or &#8220;checked out,&#8221; if you&#8217;re coming from Subversion) automatically has a backup on his or her disk. This backup contains the latest version of the project, as well as its complete history.</p> <p>This means that should a developer&#8217;s local machine or even our central server ever break down again (and the backup not work for any reason), we&#8217;re up and running again in minutes: any local repository from a teammate&#8217;s disk is all we need to get a fully functional replacement.</p> <h2>Branches keep separate things separate</h2> <p>When my more technical colleagues told me about how &#8220;cool&#8221; branching in Git was, I wasn&#8217;t bursting with joy right away. First, I have to admit that I didn&#8217;t really understand the advantages of branching. And second, coming from Subversion, I vividly remembered it being a complex and error-prone procedure. With some bad memories, I was anxious about working with branches and therefore tried to avoid it whenever I could.</p> <p>It took me quite a while to understand that branching and merging work completely differently in Git than in most other systems—especially regarding its ease of use! So if you learned the concept of branches from another version control system (like Subversion), I recommend you forget your prior knowledge and start fresh. Let&#8217;s start by understanding why branches are so important in the first place.</p> <h3>Why branches are essential</h3> <p>Back in the days when I <em>didn&#8217;t</em> use branches, working on a new feature was a mess. Essentially, I had the choice between two equally bad workflows:</p> <p>(a) I already knew that creating small, granular commits with only a few changes was a good version control habit. However, if I did this while developing a new feature, every commit would mingle my half-done feature with the main code base until I was done. It wasn&#8217;t very pleasant for my teammates to have my unfinished feature introduce bugs into the project.</p> <p>(b) To avoid getting my work-in-progress mixed up with other topics (from colleagues or myself), I&#8217;d work on a feature in my separate space. I would create a copy of the project folder that I could work with quietly—and only commit my feature once it was complete. But committing my changes only at the end produced a single, giant, bloated commit that contained all the changes. Neither my teammates nor I could understand what exactly had happened in this commit when looking at it later.</p> <p>I slowly understood that I had to make myself familiar with branches if I wanted to improve my coding.</p> <h3>Working in contexts</h3> <p>Any project has multiple contexts where work happens; each feature, bug fix, experiment, or alternative of your product is actually a context of its own. It can be seen as its own &#8220;topic,&#8221; clearly separated from other topics.</p> <p>If you don&#8217;t separate these topics from each other with branching, you will inevitably increase the risk of problems. Mixing different topics in the same context:</p> <ul> <li>makes it hard to keep an overview—and with a lot of topics, it becomes almost impossible;</li> <li>makes it hard to undo something that proved to contain a bug, because it&#8217;s already mingled with so much other stuff;</li> <li>doesn&#8217;t encourage people to experiment and try things out, because they&#8217;ll have a hard time getting experimental code out of the repository once it&#8217;s mixed with stable code.</li> </ul> <p>Using branches gave me the confidence that I couldn&#8217;t mess up. In case things went wrong, I could always go back, undo, start fresh, or switch contexts.</p> <h3>Branching basics</h3> <p>Branching in Git actually only involves a handful of commands. Let&#8217;s look at a basic workflow to get you started.</p> <p>To create a new branch based on your current state, all you have to do is pick a name and execute a single command on your command line. We&#8217;ll assume we want to start working on a new version of our contact form, and therefore create a new branch called &#8220;contact-form&#8221;:</p> <pre> <code>$ git branch contact-form</code> </pre> <p>Using the <code>git branch</code> command without a name specified will list all of the branches we currently have (and the &#8220;-v&#8221; flag provides us with a little more data than usual):</p> <pre> <code>$ git branch -v</code> </pre> <figure> <img src="http://d.alistapart.com/402/branch-listing.jpg" alt="Git screen showing the current branches of contact-form."> </figure> <p>You might notice the little asterisk on the branch named &#8220;master.&#8221; This means it&#8217;s the currently active branch. So, before we start working on our contact form, we need to make this our active context:</p> <pre> <code>$ git checkout contact-form</code> </pre> <p>Git has now made this branch our current working context. (In Git lingo, this is called the &#8220;HEAD branch&#8221;). All the changes and every commit that we make from now on will only affect this single context—other contexts will remain untouched. If we want to switch the context to a different branch, we’ll simply use the <code>git checkout</code> command again.</p> <p>In case we want to integrate changes from one branch into another, we can &#8220;merge&#8221; them into the current working context. Imagine we&#8217;ve worked on our &#8220;contact-form&#8221; feature for a while, and now want to integrate these changes into our &#8220;master&#8221; branch. All we have to do is switch back to this branch and call git merge:</p> <pre> <code>$ git checkout master $ git merge contact-form</code> </pre> <h3>Using branches</h3> <p>I would strongly suggest that you use branches extensively in your day-to-day workflow. Branches are one of the core concepts that Git was built around. They are extremely cheap and easy to create, and simple to manage—and there are <a href="http://www.git-tower.com/learn/ebook/command-line/branching-merging/branching-can-change-your-life">plenty of resources</a> out there if you’re ready to learn more about using them.</p> <h2>Undoing things</h2> <p>There&#8217;s one thing that I’ve learned as a programmer over the years: mistakes happen, no matter how experienced people are. You can&#8217;t avoid them, but you can have tools at hand that help you recover from them.</p> <p>One of Git&#8217;s greatest features is that you can undo almost anything. This gives me the confidence to try out things without fear—because, so far, I haven&#8217;t managed to <em>really</em> break something beyond recovery.</p> <h3>Amending the last commit</h3> <p>Even if you craft your commits very carefully, it&#8217;s all too easy to forget adding a change or mistype the message. With the <code>&#8212;amend</code> flag of the <code>git commit</code> command, Git allows you to change the <em>very last</em> commit, and it’s a very simple fix to execute. For example, if you forgot to add a certain change and also made a typo in the commit subject, you can easily correct this:</p> <pre> <code>$ git add <b>some/changed/files</b> $ git commit --amend -m "The message, this time without typos"</code> </pre> <p>There&#8217;s only one thing you should keep in mind: you should never amend a commit that has already been pushed to a remote repository. Respecting this rule, the “amend” option is a great little helper to fix the last commit.</p> <p>(For more detail about the <code>amend</code> option, I recommend Nick Quaranto’s <a href="http://gitready.com/advanced/2009/01/12/fixing-broken-commit-messages.html">excellent walkthrough</a>.)</p> <h3>Undoing local changes</h3> <p>Changes that haven&#8217;t been committed are called “local.” All the modifications that are currently present in your working directory are &#8220;local&#8221; uncommitted changes.</p> <p>Discarding these changes can make sense when your current work is&#8230; well&#8230; worse than what you had before. With Git, you can easily undo local changes and start over with the last committed version of your project.</p> <p>If it&#8217;s only a single file that you want to restore, you can use the <code>git checkout</code> command:</p> <pre> <code>$ git checkout -- <b>file/to/restore</b></code> </pre> <p>Don&#8217;t confuse this use of the <code>checkout</code> command with switching branches (see above). If you use it with two dashes and (separated with a space!) the path to a file, it will discard the uncommitted changes in a given file.</p> <p>On a bad day, however, you might even want to discard all your local changes and restore the complete project:</p> <pre> <code>$ git reset --hard HEAD</code> </pre> <p>This will replace all of the files in your working directory with the last committed revision. Just as with using the checkout command above, this will discard the local changes.</p> <p>Be careful with these operations: since local changes haven&#8217;t been checked into the repository, there is no way to get them back once they are discarded!</p> <h3>Undoing committed changes</h3> <p>Of course, undoing things is not limited to local changes. You can also undo certain commits when necessary—for example, if you’ve introduced a bug.</p> <p>Basically, there are two main commands to undo a commit:</p> <h4>(a) git reset</h4> <figure> <img src="http://d.alistapart.com/402/reset-concept.jpg" alt="Illustration showing how the `git reset` command works."> </figure> <p>The <code>git reset</code> command really turns back time. You tell it which version you want to return to and it restores exactly this state—undoing all the changes that happened after this point in time. Just provide it with the hash ID of the commit you want to return to:</p> <pre> <code>$ git reset -- hard 2be18d9</code> </pre> <p>The <code>&#8212;hard</code> option is the easiest and cleanest approach, but it also wipes away all local changes that you might still have in your working directory. So, before doing this, make sure there aren&#8217;t any local changes you&#8217;ve set your heart on.</p> <h4>(b) git revert</h4> <figure> <img src="http://d.alistapart.com/402/revert-concept.jpg" alt="Illustration showing how the `git revert` command works."> </figure> <p>The <code>git revert</code> command is used in a different scenario. Imagine you have a commit that you don&#8217;t want anymore—but the commits that came afterwards still make sense to you. In that case, you wouldn&#8217;t use the <code>git reset</code> command because it would undo all those later commits, too!</p> <p>The <code>revert</code> command, however, only reverts the <em>effects</em> of a certain commit. It doesn’t remove any commits, like <code>git reset</code> does. Instead, it even creates a <em>new</em> commit; this new commit introduces changes that are just the opposite of the commit to be reverted. For example, if you deleted a certain line of code, <code>revert</code> will create a new commit that introduces exactly this line, again.</p> <p>To use it, simply provide it with the hash ID of the commit you want reverted:</p> <pre> <code>$ git revert 2be18d9</code> </pre> <h2>Finding bugs</h2> <p>When it comes to finding bugs, I must admit that I&#8217;ve wasted quite some time stumbling in the dark. I often knew that it <em>used</em> to work a couple of days ago—but I had no idea <em>where exactly</em> things went wrong. It was only when I found out about <code>git bisect</code> that I could speed up this process a bit. With the <code>bisect</code> command, Git provides a tool that helps you find the commit that introduced a problem.</p> <p>Imagine the following situation: we know that our current version (tagged &#8220;2.0&#8221;) is broken. We also know that a couple of commits ago (our version &#8220;1.9&#8221;), everything was fine. The problem must have occurred somewhere in between.</p> <figure> <img src="http://d.alistapart.com/402/bisect-01.jpg" alt="Illustration showing the commits between working and broken versions."> </figure> <p>This is already enough information to start our bug hunt with <code>git bisect</code>:</p> <pre> <code>$ git bisect start $ git bisect bad $ git bisect good v1.9</code> </pre> <p>After starting the process, we told Git that our current commit contains the bug and therefore is &#8220;bad.&#8221; We then also informed Git which previous commit is definitely working (as a parameter to <code>git bisect good</code>).</p> <p>Git then restores our project in the <em>middle</em> between the known good and known bad conditions:</p> <figure> <img src="http://d.alistapart.com/402/bisect-02.jpg" alt="Illustration showing that the bisect begins between the versions."> </figure> <p>We now test this version (for example, by running unit tests, building the app, deploying it to a test system, etc.) to find out if this state works—or already contains the bug. As soon as we know, we tell Git again—either with <code>git bisect bad</code> or <code>git bisect good</code>.</p> <p>Let&#8217;s assume we said that this commit was still &#8220;bad.&#8221; This effectively means that the bug must have been introduced even earlier—and Git will again narrow down the commits in question:</p> <figure> <img src="http://d.alistapart.com/402/bisect-03.jpg" alt="Illustration showing how additional bisects will narrow the commits further."> </figure> <p>This way, you&#8217;ll find out very quickly where exactly the problem occurred. Once you know this, you need to call <code>git bisect reset</code> to finish your bug hunt and restore the project&#8217;s original state.</p> <h2>A tool that can save your neck</h2> <p>I must confess that my first encounter with Git wasn&#8217;t love at first sight. In the beginning, it felt just like my other experiences with version control: tedious and unhelpful. But with time, the practice became intuitive, and gained my trust and confidence.</p> <p>After all, mistakes happen, no matter how much experience we have or how hard we try to avoid them. What separates the pro from the beginner is preparation: having a system in place that you can trust in case of problems. It helps you stay on top of things, especially in complex projects. And, ultimately, it helps you become a better professional.</p> <h2>References</h2> <ul> <li>Feel free to <a href="http://www.git-tower.com/learn/ebook/command-line/advanced-topics/undoing-things">learn more about amending, reverting, and resetting commits</a>.</li> <li>Make yourself familiar with &#8220;git bisect&#8221; with this <a href="http://www.metaltoad.com/blog/beginners-guide-git-bisect-process-elimination">detailed example</a>.</li> <li>A detailed <a href="http://www.git-tower.com/learn/ebook/command-line/branching-merging/branching-can-change-your-life">introduction to branching</a>.</li> </ul><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/QXYwqk3T2cE" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)
2. Sep 2014
Running Code Reviews with Confidence
<p>Growing up, I learned there were two kinds of reviews I could seek out from my parents. One parent gave reviews in the form of a shower of praise. The other parent, the one with a degree from the Royal College of Art, would put me through a design crit. Today the reviews I seek are for my code, not my horse drawings, but it continues to be a process I both dread and crave.</p> <p>In this article, I&#8217;ll describe my battle-tested process for conducting code reviews, highlighting the questions you should ask during the review process as well as the necessary version control commands to download and review someone&#8217;s work. I&#8217;ll assume your team uses Git to store its code, but the process works much the same if you&#8217;re using any other source control system.</p> <p>Completing a peer review is time-consuming. In the last project where I introduced mandatory peer reviews, the senior developer and I estimated that it doubled the time to complete each ticket. The reviews introduced more context-switching for the developers, and were a source of increased frustration when it came to keeping the branches up to date while waiting for a code review. </p> <p>The benefits, however, were huge. Coders gained a greater understanding of the whole project through their reviews, reducing silos and making onboarding easier for new people. Senior developers had better opportunities to ask why decisions were being made in the codebase that could potentially affect future work. And by adopting an ongoing peer review process, we reduced the amount of time needed for human quality assurance testing at the end of each sprint.</p> <p>Let’s walk through the process. Our first step is to figure out exactly what we’re looking for.</p> <h2>Determine the purpose of the proposed change</h2> <p>Our code review should always begin in a ticketing system, such as Jira or GitHub. It doesn&#8217;t matter if the proposed change is a new feature, a bug fix, a security fix, or a typo: every change should start with a description of why the change is necessary, and what the desired outcome will be once the change has been applied. This allows us to accurately assess when the proposed change is complete. </p> <p>The ticketing system is where you&#8217;ll track the discussion about the changes that need to be made after reviewing the proposed work. From the ticketing system, you’ll determine which branch contains the proposed code. Let’s pretend the ticket we’re reviewing today is 61524—it was created to fix a broken link in our website. It could just as equally be a refactoring, or a new feature, but I’ve chosen a bug fix for the example. No matter what the nature of the proposed change is, having each ticket correspond to only one branch in the repository will make it easier to review, and close, tickets.</p> <p>Set up your local environment and ensure that you can reproduce what is currently the live site—complete with the broken link that needs fixing. When you apply the new code locally, you want to catch any regressions or problems it might introduce. You can only do this if you know, for sure, the difference between what is old and what is new.</p> <h2>Review the proposed changes</h2> <p>At this point you&#8217;re ready to dive into the code. I&#8217;m going to assume you&#8217;re working with Git repositories, on a branch-per-issue setup, and that the proposed change is part of a remote team repository. Working directly from the command line is a good universal approach, and allows me to create copy-paste instructions for teams regardless of platform.</p> <p>To begin, update your local list of branches.</p> <pre> <code>git fetch</code> </pre> <p>Then list all available branches.</p> <pre> <code>git branch -a</code> </pre> <p>A list of branches will be displayed to your terminal window. It may appear something like this:</p> <pre> <code>* master remotes/origin/master remotes/origin/HEAD -> origin/master remotes/origin/61524-broken-link</code> </pre> <p>The <code>*</code> denotes the name of the branch you are currently viewing (or have “checked out”). Lines beginning with <code>remotes/origin</code> are references to branches we’ve downloaded. We are going to work with a new, local copy of branch <code>61524-broken-link</code>.</p> <p>When you clone your project, you&#8217;ll have a connection to the remote repository as a whole, but you won&#8217;t have a read-write relationship with each of the individual branches in the remote repository. You&#8217;ll make an explicit connection as you switch to the branch. This means if you need to run the command <code>git push</code> to upload your changes, Git will know which remote repository you want to publish your changes to.</p> <pre> <code>git checkout --track origin/61524-broken-link</code> </pre> <p>Ta-da! You now have your own copy of the branch for ticket 61524, which is connected (“tracked”) to the origin copy in the remote repository. You can now begin your review!</p> <p>First, let&#8217;s take a look at the commit history for this branch with the command <code>log</code>.</p> <pre> <code>git log master..</code> </pre> <p>Sample output:</p> <pre> <code>Author: emmajane <emma@emmajane.net> Date: Mon Jun 30 17:23:09 2014 -0400 Link to resources page was incorrectly spelled. Fixed. Resolves #61524.</code> </pre> <p>This gives you the full log message of all the commits that are in the branch <code>61524-broken-link</code>, but are not also in the <code>master</code> branch. Skim through the messages to get a sense of what&#8217;s happening.</p> <p>Next, take a brief gander through the commit itself using the <code>diff</code> command. This command shows the difference between two snapshots in your repository. You want to compare the code on your checked-out branch to the branch you’ll be merging “to”—which conventionally is the <code>master</code> branch.</p> <pre> <code>git diff master</code> </pre> <h3>How to read patch files</h3> <p>When you run the command to output the difference, the information will be presented as a patch file. Patch files are ugly to read. You&#8217;re looking for lines beginning with <code>+</code> or <code>-</code>. These are lines that have been added or removed, respectively. Scroll through the changes using the up and down arrows, and press <code>q</code> to quit when you’ve finished reviewing. If you need an even more concise comparison of what&#8217;s happened in the patch, consider modifying the diff command to list the changed files, and then look at the changed files one at a time:</p> <pre> <code>git diff master --name-only git diff master &lt;filename></code> </pre> <p>Let&#8217;s take a look at the format of a patch file.</p> <pre> <code>diff --git a/about.html b/about.html index a3aa100..a660181 100644 --- a/about.html +++ b/about.html @@ -48,5 +48,5 @@ (2004-05) - A full list of &lt;a href="emmajane.net/events">public + A full list of &lt;a href="http://emmajane.net/events">public presentations and workshops&lt;/a> Emma has given is available</code> </pre> <p>I tend to skim past the metadata when reading patches and just focus on the lines that start with <code>-</code> or <code>+</code>. This means I start reading at the line immediate following <code>@@</code>. There are a few lines of context provided leading up to the changes. These lines are indented by one space each. The changed lines of code are then displayed with a preceding <code>-</code> (line removed), or <code>+</code> (line added).</p> <h3>Going beyond the command line</h3> <p>Using a Git repository browser, such as gitk, allows you to get a slightly better visual summary of the information we&#8217;ve looked at to date. The version of Git that Apple ships with does not include gitk—I used <a href="http://brew.sh/">Homebrew</a> to re-install Git and get this utility. Any repository browser will suffice, though, and there are many <a href="http://git-scm.com/downloads/guis">GUI clients available on the Git website</a>.</p> <pre> <code>gitk</code> </pre> <p>When you run the command <code>gitk</code>, a graphical tool will launch from the command line. An example of the output is given in the following screenshot. Click on each of the commits to get more information about it. Many ticket systems will also allow you to look at the changes in a merge proposal side-by-side, so if you’re finding this cumbersome, click around in your ticketing system to find the comparison tools they might have—I know for sure GitHub offers this feature.</p> <figure> <img src="http://d.alistapart.com/402/gitk.jpg" alt="Screenshot of the gitk repository browser."> </figure> <p>Now that you&#8217;ve had a good look at the code, jot down your answers to the following questions:</p> <ol> <li>Does the code comply with your project&#8217;s identified coding standards?</li> <li>Does the code limit itself to the scope identified in the ticket?</li> <li>Does the code follow industry best practices in the most efficient way possible?</li> <li>Has the code been implemented in the best possible way according to all of your internal specifications? It&#8217;s important to separate your preferences and stylistic differences from actual problems with the code.</li> </ol> <h2>Apply the proposed changes</h2> <p>Now is the time to start up your testing environment and view the proposed change in context. How does it look? Does your solution match what the coder thinks they&#8217;ve built? If it doesn&#8217;t look right, do you need to clear the cache, or perhaps rebuild the Sass output to update the CSS for the project?</p> <p>Now is the time to also test the code against whatever test suite you use.</p> <ol> <li>Does the code introduce any regressions?</li> <li>Does the new code perform as well as the old code? Does it still fall within your project&#8217;s performance budget for download and page rendering times?</li> <li>Are the words all spelled correctly, and do they follow any brand-specific guidelines you have?</li> </ol> <p>Depending on the context for this particular code change, there may be other obvious questions you need to address as part of your code review.</p> <p>Do your best to create the most comprehensive list of everything you can find wrong (and right) with the code. It&#8217;s annoying to get dribbles of feedback from someone as part of the review process, so we&#8217;ll try to avoid &#8220;just one more thing&#8221; wherever we can.</p> <h2>Prepare your feedback</h2> <p>Let&#8217;s assume you&#8217;ve now got a big juicy list of feedback. Maybe you have no feedback, but I doubt it. If you&#8217;ve made it this far in the article, it&#8217;s because you love to comb through code as much as I do. Let your freak flag fly and let&#8217;s get your review structured in a usable manner for your teammates. </p> <p>For all the notes you&#8217;ve assembled to date, sort them into the following categories:</p> <ol> <li>The code is broken. It doesn&#8217;t compile, introduces a regression, it doesn&#8217;t pass the testing suite, or in some way actually fails demonstrably. These are problems which absolutely must be fixed.</li> <li>The code does not follow best practices. You have some conventions, the web industry has some guidelines. These fixes are pretty important to make, but they may have some nuances which the developer might not be aware of.</li> <li>The code isn&#8217;t how you would have written it. You&#8217;re a developer with battle-tested opinions, and you know you’re right, you just haven’t had the chance to update the Wikipedia page yet to prove it.</li> </ol> <h2>Submit your evaluation</h2> <p>Based on this new categorization, you are ready to engage in passive-aggressive coding. If the problem is clearly a typo and falls into one of the first two categories, go ahead and fix it. Obvious typos don&#8217;t really need to go back to the original author, do they? Sure, your teammate will be a little embarrassed, but they&#8217;ll appreciate you having saved them a bit of time, and you’ll increase the efficiency of the team by reducing the number of round trips the code needs to take between the developer and the reviewer. </p> <p>If the change you are itching to make falls into the third category: stop. Do not touch the code. Instead, go back to your colleague and get them to describe their approach. Asking “why” might lead to a really interesting conversation about the merits of the approach taken. It may also reveal limitations of the approach to the original developer. By starting the conversation, you open yourself to the possibility that just maybe your way of doing things isn&#8217;t the only viable solution.</p> <p>If you needed to make any changes to the code, they should be absolutely tiny and minor. You should not be making substantive edits in a peer review process. Make the tiny edits, and then add the changes to your local repository as follows:</p> <pre> <code>git add . git commit -m "[#61524] Correcting &lt;list problem> identified in peer review."</code> </pre> <p>You can keep the message brief, as your changes should be minor. At this point you should push the reviewed code back up to the server for the original developer to double-check and review. Assuming you&#8217;ve set up the branch as a tracking branch, it should just be a matter of running the command as follows:</p> <pre> <code>git push</code> </pre> <p>Update the issue in your ticketing system as is appropriate for your review. Perhaps the code needs more work, or perhaps it was good as written and it is now time to close the issue queue.</p> <p>Repeat the steps in this section until the proposed change is complete, and ready to be merged into the main branch.</p> <h2>Merge the approved change into the trunk</h2> <p>Up to this point you&#8217;ve been comparing a ticket branch to the master branch in the repository. This main branch is referred to as the &#8220;trunk&#8221; of your project. (It’s a tree thing, not an elephant thing.) The final step in the review process will be to merge the ticket branch into the trunk, and clean up the corresponding ticket branches.</p> <p>Begin by updating your master branch to ensure you can publish your changes after the merge.</p> <pre> <code>git checkout master git pull origin master</code> </pre> <p>Take a deep breath, and merge your ticket branch back into the main repository. As written, the following command will not create a new commit in your repository history. The commits will simply shuffle into line on the master branch, making <code>git log &#8722;&#8722;graph</code> appear as though a separate branch has never existed. If you would like to maintain the illusion of a past branch, simply add the parameter <code>&#8722;&#8722;no-ff</code> to the merge command, which will make it clear, via the graph history and a new commit message, that you have merged a branch at this point. Check with your team to see what&#8217;s preferred.</p> <pre> <code>git merge 61524-broken-link</code> </pre> <p>The merge will either fail, or it will succeed. If there are no merge errors, you are ready to share the revised master branch by uploading it to the central repository.</p> <pre> <code>git push</code> </pre> <p>If there are merge errors, the original coders are often better equipped to figure out how to fix them, so you may need to ask them to resolve the conflicts for you.</p> <p>Once the new commits have been successfully integrated into the master branch, you can delete the old copies of the ticket branches both from your local repository and on the central repository. It&#8217;s just basic housekeeping at this point.</p> <pre> <code>git branch -d 61524-broken-link git push origin --delete 61524-broken-link</code> </pre> <h2>Conclusion</h2> <p>This is the process that has worked for the teams I&#8217;ve been a part of. Without a peer review process, it can be difficult to address problems in a codebase without blame. With it, the code becomes much more collaborative; when a mistake gets in, it&#8217;s because we both missed it. And when a mistake is found before it&#8217;s committed, we both breathe a sigh of relief that it was found when it was. </p> <p>Regardless of whether you&#8217;re using Git or another source control system, the peer review process can help your team. Peer-reviewed code might take more time to develop, but it contains fewer mistakes, and has a strong, more diverse team supporting it. And, yes, I’ve been known to learn the habits of my reviewers and choose the most appropriate review style for my work, just like I did as a kid.</p><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/2RHB5rIvr6A" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)
1. Sep 2014
W3C Advisory Committee Elects Mark Nottingham to Technical Architecture Group
The W3C Advisory Committee has elected Mark Nottingham (Akamai Technologies) to the W3C Technical Architecture Group (TAG). The mission of the TAG is to build consensus around principles of Web architecture and to interpret and clarify these principles when necessary, to resolve issues involving general Web architecture brought to the TAG, and to help coordinate [&#8230;][mehr] (Quelle: W3C News)
9. Sep 2014
Encrypted Media Extensions; HTML Canvas 2D Context, Level 2 Drafts Published
The HTML Working Group has published two documents today: A Working Draft of Encrypted Media Extensions. This proposal extends HTMLMediaElement providing APIs to control playback of protected content. The API supports use cases ranging from simple clear key decryption to high value video (given an appropriate user agent implementation). License/key exchange is controlled by the [&#8230;][mehr] (Quelle: W3C News)
9. Sep 2014
Last Call: Battery Status API
The Device APIs Working Group has published a Last Call Working Draft of Battery Status API. This specification defines an API that provides information about the battery status of the hosting device. Comments are welcome through 2 October. Learn more about the Ubiquitous Web Applications Activity.[mehr] (Quelle: W3C News)
9. Sep 2014
Linked Data Platform Best Practices and Guidelines Note Published
The Linked Data Platform (LDP) Working Group has published a Group Note of Linked Data Platform Best Practices and Guidelines. This document provides best practices and guidelines for implementing Linked Data Platform servers and clients. Learn more about the Data Activity.[mehr] (Quelle: W3C News)
28. Aug 2014
Rachel Andrew on the Business of Web Dev: Getting to the Action
<p>Freelancers and self-employed business owners can choose from a huge number of conferences to attend in any given year. There are hundreds of industry podcasts, a constant stream of published books, and a never-ending supply of sites all giving advice. It is very easy to spend a lot of valuable time and money just attending, watching, reading, listening and hoping that somehow all of this good advice will take root and make our business a success.</p> <p>However, all the good advice in the world won’t help you if you don’t act on it. While you might leave that expensive conference feeling great, did your attendance create a lasting change to your business? I was thinking about this subject while listening to <a href="http://workingoutpodcast.com/2014/08/06/14-not-following-through.html">episode 14 of the Working Out podcast</a>, hosted by Ashley Baxter and Paddy Donnelly. They were talking about following through, and how it is possible to “nod along” to good advice but never do anything with it.</p> <p>If you have ever been sent to a conference by an employer, you may have been expected to report back. You might even have been asked to present to your team on the takeaway points from the event. As freelancers and business owners, we don’t have anyone making us consolidate our thoughts in that way. It turns out that the way I work gives me a fairly good method of knowing which things are bringing me value.</p> <h2>Tracking actionable advice</h2> <p>I’m a fan of the <a href="http://en.wikipedia.org/wiki/Getting_Things_Done">Getting Things Done</a> technique, and live by my to-do lists. I maintain a Someday/Maybe list in OmniFocus into which I add items that I want to do or at least investigate, but that aren’t a project yet.</p> <p>If a podcast is worth keeping on my playlist, there will be items entered linking back to certain episodes. Conference takeaways might be a link to a site with information that I want to read. It might be an idea for an article to write, or instructions on something very practical such as setting up an analytics dashboard to better understand some data. The first indicator of a valuable conference is how many items I add during or just after the event.</p> <p>Having a big list of things to do is all well and good, but it’s only one half of the story. The real value comes when I do the things on that list, and can see whether they were useful to my business. Once again, my GTD lists can be mined for that information.</p> <p>When tickets go on sale for that conference again, do I have most of those to-do items still sat in Someday/Maybe? Is that because, while they sounded like good ideas, they weren’t all that relevant? Or, have I written a number of blog posts or had several articles published on themes that I started considering off the back of that conference? Did I create that dashboard, and find it useful every day? Did that speaker I was introduced to go on to become a friend or mentor, or someone I’ve exchanged emails with to clarify a topic I’ve been thinking about?</p> <p>By looking back over my lists and completed items, I can start to make decisions about the real value to my business and life of the things I attend, read, and listen to. I’m able to justify the ticket price, time, and travel costs by making that assessment. I can feel confident that I’m not spending time and money just to feel as if I’m moving forward, yet gaining nothing tangible to show for it.</p> <h2>A final thought on value</h2> <p>As entrepreneurs, we have to make sure we are spending our time and money on things that will give us the best return. All that said, it is important to make time in our schedules for those things that we just <strong>enjoy</strong>, and in particular those things that do motivate and inspire us. I don’t think that <em>every</em> book you read or event you attend needs to result in a to-do list of actionable items.</p> <p>What we need as business owners, and as people, is <em>balance</em>. We need to be able to see that the things we are doing are moving our businesses forward, while also making time to be inspired and refreshed to get that actionable work done.</p><h3>Footnotes</h3><ul class="the-footnotes"><li id="note1">1. Have any favorite hacks for getting maximum value from conferences, workshops, and books? Tell us in the comments!</li></ul><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/VCIPQgTpPaQ" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)
1. Sep 2014
W3C Invites Implementations of CSS Masking Module Level 1
The Cascading Style Sheets (CSS) Working Group and the SVG Working Group invite implementation of the Candidate Recommendation of CSS Masking Module Level 1. CSS Masking provides two means for partially or fully hiding portions of visual elements: masking and clipping. Masking describes how to use another graphical element or image as a luminance or [&#8230;][mehr] (Quelle: W3C News)
1. Sep 2014
Last Call: CSS Counter Styles Level 3
The Cascading Style Sheets (CSS) Working Group has published a Last Call Working Draft of CSS Counter Styles Level 3. This module introduces the @counter-style rule, which allows authors to define their own custom counter styles for use with CSS list-marker and generated-content counters. It also predefines a set of common counter styles, including the [&#8230;][mehr] (Quelle: W3C News)
25. Aug 2014
10 Years Ago in ALA: Pocket Sized Design
<p>The web doesn’t do “age” especially well. Any blog post or design article more than a few years old gets a raised eyebrow—heck, most people I meet haven’t read John Allsopp’s “<a href="http://www.alistapart.com/articles/dao">A Dao of Web Design</a>” or Jeffrey Zeldman’s “<a href="http://www.alistapart.com/articles/tohell/">To Hell With Bad Browsers</a>,” both as relevant to the web today as when they were first written. Meanwhile, I’ve got books on my shelves older than I am; most of my favorite films came out before I was born; and my iTunes library is riddled with music that’s decades, if not centuries, old.</p> <p>(No, I don’t get invited to many parties. Why do you ask oh I get it)</p> <p>So! It’s probably easy to look at “<a href="http://alistapart.com/article/pocket">Pocket-Sized Design</a>,” a lovely article by Jorunn Newth and Elika Etemad that just turned 10 years old, and immediately notice where it’s beginning to show its age. Written at a time when few sites were standards-compliant, and even fewer still were mobile-friendly, Newth and Etemad were urging us to think about life beyond the desktop. And when I first re-read it, it’s easy to chuckle at the points that feel like they’re from another age: there’s plenty of talk of screens that are “only 120-pixels wide”; of inputs driven by stylus, rather than touch; and of using the now-basically-defunct <code>handheld</code> media type for your CSS. Seems a bit quaint, right?</p> <p>And yet.</p> <p>Looking past a few of the details, it’s remarkable how well the article’s aged. Modern users may (or may not) manually “turn off in-line image loading,” but they <em>may</em> choose to use a mobile browser that <a href="http://www.opera.com/turbo">dramatically compresses your images</a>. We may scoff at the idea of someone browsing with a stylus, but handheld video game consoles are <a href="https://speakerdeck.com/anna/playing-with-game-console-browsers">impossibly popular when it comes to browsing the web</a>. And while there’s plenty of excitement in our industry for the latest versions of iOS and Android, running on the latest hardware, most of the web’s growth is happening on <a href="http://www.cnbc.com/id/101910355">cheaper hardware</a>, over <a href="http://www.ericsson.com/res/docs/2014/ericsson-mobility-report-june-2014.pdf" title="Ericsson’s 2014 Mobility Report (PDF)">slower networks</a> (PDF), and via <a href="https://twitter.com/scottjehl/status/344183854698991616">slim</a> <a href="https://twitter.com/scottjehl/status/332875425804079104">data</a> <a href="https://twitter.com/scottjehl/status/344183854698991616">plans</a>—so yes, 10 years on, it’s still true that “downloading to the device is likely to be [expensive], the processors are slow, and the memory is limited.”</p> <p>In the face of all of that, what I love about Newth and Etemad’s article is just how sensible their solutions are. Rather than suggesting slimmed-down mobile sites, or investing in some device detection library, they take a decidedly standards-focused approach: </p> <figure class="quote"> <blockquote> Linearizing the page into one column works best when the underlying document structure has been designed for it. Structuring the document according to this logic ensures that the page organization makes sense not only in Opera for handhelds, but also in non-CSS browsers on both small devices and the desktop, in voice browsers, and in terminal-window browsers like Lynx. </blockquote> </figure> <p>In other words, by thinking about the needs of the small screen first, you can layer on more complexity from there. And if you’re hearing shades of <a href="http://www.abookapart.com/products/mobile-first" title="Luke Wroblewski’s book, Mobile First">mobile first</a> and <a href="http://alistapart.com/article/testdriven" title="Scott Jehl’s article for A List Apart, “Test-Driven Progressive Enhancement”">progressive enhancement</a> here, you’d be right: they’re treating their markup—their <em>content</em>—as a foundation, and gently layering styles atop it to make it accessible to more devices, more places than ever before.</p> <p>So, no: we aren’t using <code>@media handheld</code> or <code>display: none</code> for our small screen-friendly styles—but I don’t think that’s really the point of Newth and Etemad’s essay. Instead, they’re putting forward a process, a <em>framework</em> for designing beyond the desktop. What they’re arguing is for a truly <a href="http://trentwalton.com/2014/03/10/device-agnostic/">device-agnostic</a> approach to designing for the web, one that’s as relevant today as it was a decade ago.</p> <p><i>Plus ça change, plus c’est la même chose.</i></p><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/zGr02UT5rdI" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)
28. Aug 2014
W3C Invites Implementations of HTML Canvas 2D Context
The HTML Working Group invites implementation of the Candidate Recommendation of HTML Canvas 2D Context. This specification defines the 2D Context for the HTML canvas element. The 2D Context provides objects, methods, and properties to draw and manipulate graphics on a canvas drawing surface. Learn more about the HTML Activity.[mehr] (Quelle: W3C News)
28. Aug 2014
Predefined Counter Styles Draft Published
The Internationalization Working Group has published a Working Draft of Predefined Counter Styles. This document describes numbering systems used by various cultures around the world and can be used as a reference for those wishing to create user-defined counter styles for CSS. Learn more about the Internationalization Activity.[mehr] (Quelle: W3C News)
19. Aug 2014
Dependence Day: The Power and Peril of Third-Party Solutions
<p>“Why don’t we just use this plugin?” That’s a question I started hearing a lot in the heady days of the 2000s, when open-source <abbr title="Content Management Systems">CMSes</abbr> were becoming really popular. We asked it optimistically, full of hope about the myriad solutions only a download away. As the years passed, we gained trustworthy libraries and powerful communities, but the graveyard of crufty code and abandoned services grew deep. Many solutions were easy to install, but difficult to debug. Some providers were eager to sell, but loath to support. </p> <p>Years later, we’re still asking that same question—only now we’re less optimistic and even more dependent, and I’m scared to engage with anyone smart enough to build something I can’t. The emerging challenge for today’s dev shop is knowing how to take control of third-party relationships—and when to avoid them. I’ll show you my approach, which is to ask a different set of questions entirely. </p> <h2>A web of third parties</h2> <p>I should start with a broad definition of what it is to be third party: If it’s a person and I don’t compensate them for the bulk of their workload, they’re third party. If it’s a company or service and I don’t control it, it’s third party. If it’s code and my team doesn’t grasp every line of it, it’s third party. </p> <p>The third-party landscape is rapidly expanding. Github has grown to almost <a href="https://github.com/about/press">7 million users</a> and the WordPress plugin repo is approaching <a href="https://wordpress.org/plugins/">1 billion downloads</a>. Many of these solutions are easy for clients and competitors to implement; meanwhile, I’m still in the lab debugging my custom code. The idea of selling original work seems oddly&hellip;old-fashioned. </p> <p>Yet with so many third-party options to choose from, there are more chances than ever to veer off-course. </p> <h2>What could go wrong?</h2> <p>At a meeting a couple of years ago, I argued against using an external service to power a search widget on a client project. “We should do things ourselves,” I said. Not long after this, on the very same project, I argued in favor of a using a third party to consolidate <abbr title="Really Simple Syndication">RSS</abbr> feeds into a single document. “Why do all this work ourselves,” I said, “when this problem has already been solved?” My inconsistency was obvious to everyone. Being dogmatic about <em>not</em> using a third party is no better than flippantly jumping in with one, and I had managed to do both at once! </p> <p>But in one case, I believed the third party was worth the risk. In the other, it wasn’t. I just didn’t know how to communicate those thoughts to my team.</p> <p>I needed, in the parlance of our times, a <em>decision-making framework</em>. To that end, I’ve been maintaining a collection of points to think through at various stages of engagement with third parties. I’ll tour through these ideas using the search widget and the RSS digest as examples. </p> <h2>The difference between a request and a goal</h2> <p>This point often reveals false assumptions about what a client or stakeholder wants. In the case of the search widget, we began researching a service that our client specifically requested. Fitted with ajax navigation, full-text searching, and automated crawls to index content, it seemed like a lot to live up to. But when we asked our clients what <em>exactly</em> they were trying to do, we were surprised: they were entirely taken by the typeahead functionality; the other features were of very little perceived value. </p> <p>In the case of the RSS “smusher,” we already had an in-house tool that took an array of feed URLs and looped through them in order, outputting <em>x</em> posts per feed in some bespoke format. They’re too good for our beloved multi-feed widget? But actually, the client had a distinctly different and worthwhile vision: they wanted <em>x</em> results from their array of sites in total, and they wanted them ordered by publication date, not grouped by site. I conceded. </p> <p>It might seem like an obvious first step, but I have seen projects set off in the wrong direction because the end goal is unknown. In both our examples now, we’re clear about that and we’re ready to evaluate solutions. </p> <h2>To dev or to download</h2> <p>Before deciding to use a third party, I find that I first need to examine my own organization, often in four particular ways: strengths, weaknesses, betterment, and mission. </p> <h3>Strengths and weaknesses</h3> <p>The search task aligned well with our strengths because we had good front-end developers and were skilled at extending our CMS. So when asked to make a typeahead search, we felt comfortable betting on ourselves. Had we done it before? Not exactly, but we could think through it. </p> <p>At that same time, backend infrastructure was a weakness for our team. We had happened to have a lot of turnover among our sysadmins, and at times it felt like we weren’t equipped to hire that sort of talent. As I was thinking through how we might build a feed-smusher of our own, I felt like I was tempting a weak underbelly. Maybe we’d have to set up a cron job to poll the desired URLs, grab feed content, and store that on our servers. Not rocket science, but cron tasks in particular were an albatross for us. </p> <h3>Betterment of the team</h3> <p>When we set out to achieve a goal for a client, it’s more than us doing work: it’s an opportunity for our team to better themselves by learning new skills. The best opportunities for this are the ones that present challenging but attainable tasks, which create <a href="http://www.reddit.com/r/incremental_games/comments/1xiiyp/mechanics_of_incremental_games_3_reward_frequency/">incremental rewards</a>. <a href="http://www.edutopia.org/blog/video-games-learning-student-engagement-judy-willis">Some researchers</a> cite this effect as a factor in gaming addiction. I’ve felt this myself when learning new things on a project, and those are some of my favorite work moments ever. Teams appreciate this and there is an organizational cost in missing a chance to pay them to learn. The typeahead search project looked like it could be a perfect opportunity to boost our skill level. </p> <h3>Organizational mission</h3> <p>If a new project aligns well with our mission, we’re going to resell it many times. It’s likely that we’ll want our in-house dev team to iterate on it, tailoring it to our needs. Indeed, we’ll have the budget to do so if we’re selling it a lot. No one had asked us for a feed-smusher before, so it didn’t seem reasonable to dedicate an <abbr title="Research and Development">R&amp;D</abbr> budget to it. In contrast, several other clients were interested in more powerful site search, so it looked like it would be time well spent. </p> <p>We’ve now clarified our end goals and we’ve looked at how these projects align with our team. Based on that, we’re doing the search widget ourselves, and we’re outsourcing the feed-smusher. Now let’s look more closely at what happens next for both cases.</p> <h2>Evaluating the unknown</h2> <p>The frustrating thing about working with third parties is that the most important decisions take place when we have the least information. But there are some things we can determine before committing. Familiarity, vitality, extensibility, branding, and Service Level Agreements (SLAs) are all observable from afar. </p> <h3>Familiarity: is there a provider we already work with?</h3> <p>Although we’re going to increase the number of third-party <em>dependencies</em>, we’ll try to avoid increasing the number of third-party <em>relationships</em>. </p> <p>Working with a known vendor has several potential benefits: they may give us volume pricing. Markup and style are likely to be consistent between solutions. And we just know them better than we’d know a new service. </p> <h3>Vitality: will this service stick around?</h3> <p>The worst thing we could do is get behind a service, only to have it shut down next month. A service with high vitality will likely (and rightfully) brag about enterprise clients by name. If it’s open source, it will have a passionate community of contributors. On the other hand, it could be advertising a shutdown. More often, it’s somewhere in the middle. Noting how often the service is updated is a good starting point in determining vitality. </p> <h3>Extensibility: can this service adapt as our needs change?</h3> <p>Not only do we have to evaluate the core service, we have to see how extensible it is by digging into its API. If a service is extensible, it’s more likely to fit for the long haul. </p> <p>APIs can also present new opportunities. For example, imagine selecting an email-marketing provider with an API that exposes campaign data. This might allow us to build a dashboard for campaign performance in our CMS—a unique value-add for our clients, and a chance to keep our in-house developers invested and excited about the service.</p> <h3>Branding: is theirs strong, or can you use your own?</h3> <p>White-labeling is the practice of reselling a service with your branding instead of that of the original provider. For some companies, this might make good sense for marketing. I tend to dislike white-labeling. Our clients trust us to make choices, and we should be proud to display what those choices are. Either way, you want to ensure you’re comfortable with the brand you’ll be using.</p> <h3>SLAs: what are you getting, beyond uptime?</h3> <p>For client-side products, browser support is a factor: every external dependency represents another layer that could abandon older browsers before we’re ready. There’s also accessibility. Does this new third-party support users with accessibility needs to the degree that we require? Perhaps most important of all is support. Can we purchase a priority support plan that offers fast and in-depth help? </p> <p>In the case of our feed-smusher service, there was no solution that ran the table. The most popular solution actually had a shutdown notice! There were a couple of smaller providers available, but we hadn’t worked with either before. Browser support and accessibility were moot since we’d be parsing the data and displaying it ourselves. The uptime concern was also diminished because we’d be sure to cache the results locally. Anyway, with viable candidates in hand, we can move on to more productive concerns than dithering between two similar solutions. </p> <h2>Relationship maintenance</h2> <p>If someone else is going to do the heavy lifting, I want to assume as much of the remaining burden as possible. Piloting, data collection, documentation, and in-house support are all valuable opportunities to buttress this new relationship. </p> <p>As exciting as this new relationship is, we don’t want to go dashing out of the gates just yet. Instead, we’ll target clients for piloting and quarantine them before unleashing it any further. Cull suggestions from team members to determine good candidates for piloting, garnering a mix of edge-cases and the norm. </p> <p>If the third party happens to collect data of any kind, we should also have an automated way to import a copy of it—not just as a backup, but also as a cached version we can serve to minimize latency. If we are serving a popular dependency from a CDN, we want to send a local version if that call should fail. </p> <p>If our team doesn’t have a well-traveled directory of provider relationships, the backstory can get lost. Let a few months pass, throw in some personnel turnover, and we might forget why we even use a service, or why we opted for a particular package. Everyone on our team should know where and how to learn about our third-party relationships. </p> <p>We don’t need every team member to be an expert on the service, yet we don’t want to wait for a third-party support staff to respond to simple questions. Therefore, we should elect an in-house subject-matter expert. It doesn’t have to be a developer. We just need somebody tasked with monitoring the service at regular intervals for API changes, shutdown notices, or new features. They should be able to train new employees and route more complex support requests to the third party. </p> <p>In our RSS feed example, we knew we’d read their output into our database. We documented this relationship in our team’s most active bulletin, our <abbr title="Customer Relationship Management">CRM</abbr> software. And we made managing external dependencies a primary part of one team member’s job. </p> <h2><abbr title="Do It Yourself">DIY</abbr>: a third party waiting to happen?</h2> <p>Stop me if you’ve heard this one before: a prideful developer assures the team that they can do something themselves. It’s a complex project. They make something and the company comes to rely on it. Time goes by and the in-house product is doing fine, though there is a maintenance burden. Eventually, the developer leaves the company. Their old product needs maintenance, no one knows what to do, and since it’s totally custom, there is no such thing as a community for it. </p> <p>Once you decide to build something in-house, how can you prevent that work from devolving into a resented, alien dependency?&nbsp; </p> <ul> <li><b>Consider pair-programming.</b> What better way to ensure that multiple people understand a product, than to have multiple people build it?</li> <li><b>“Job-switch Tuesdays.”</b> When feasible, we have developers switch roles for an entire day. Literally, in our ticketing system, it’s as though one person is another. It’s a way to force cross-training without doubling the hours needed for a task.</li> <li><b>Hold code reviews</b> before new code is pushed. This might feel slightly intrusive at first, but that passes. If it’s not readable, it’s not deployable. If you have project managers with a technical bent, empower them to ask questions about the code, too.</li> <li><b>Bring moldy code into light</b> by displaying it as <a href="http://www.phpdoc.org/">phpDoc</a>, <a href="http://usejsdoc.org/">JSDoc</a>, or similar.</li> <li><b>Beware the big.</b> Create hourly estimates in <a href="http://en.wikipedia.org/wiki/Planning_poker">Fibonacci increments</a>. As a project gets bigger, so does its level of uncertainty. The Fibonacci steps are biased against under-budgeting, and also provide a cue to opt out of projects that are too difficult to estimate. In that case, it&#8217;s likely better to toe-in with a third party instead of blazing into the unknown by yourself.</li> </ul> <p>All of these considerations apply to our earlier example, the typeahead search widget. Most germane is the provision to “beware the big.” When I say “big,” I mean that relative to what usually works for a given team. In this case, it was a deliverable that felt very familiar in size and scope: we were being asked to extend an open-source CMS. If instead we had been asked to <em>make</em> a CMS, alarms would have gone off. </p> <h2>Look before you leap, and after you land</h2> <p>It’s not that third parties are bad <em>per se</em>. It’s just that the modern web team strikes me as a strange place: not only do we stand on the shoulders of giants, we do so without getting to know them first—and we hoist our organizations and clients up there, too. </p> <p>Granted, there are many things you shouldn’t do yourself, and it’s possible to hurt your company by trying to do them—<a href="http://en.wikipedia.org/wiki/Not_invented_here">NIH</a> is a problem, not a goal. But when teams err too far in the other direction, developers become disenfranchised, components start to look like spare parts, and clients pay for solutions that aren’t quite right. Using a third party versus staying in-house is a <em>big</em> decision, and we need to think hard before we make it. Use my line of questions, or come up with one that fits your team better. After all, you’re your own best dependency.</p><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/ghdCO-iH_Kc" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)
19. Aug 2014
One Step Ahead: Improving Performance with Prebrowsing
<p>We all want our websites to be fast. We optimize images, create CSS sprites, use CDNs, cache aggressively, and gzip and minimize static content. We use every trick in the book. </p> <p>But we can still do more. If we want faster outcomes, we have to think differently. What if, instead of leaving our users to stare at a spinning wheel, waiting for content to be delivered, we could predict where they wanted to go next? What if we could have that content ready for them before they even ask for it?</p> <p>We tend to see the web as a reactive model, where every action causes a reaction. Users click, then we take them to a new page. They click again, and we open another page. But we can do better. We can be proactive with prebrowsing.</p> <h2>The three big techniques</h2> <p>Steve Souders coined the term prebrowsing (from <em>predictive browsing</em>) in one of his <a href="http://www.stevesouders.com/blog/2013/11/07/prebrowsing/">articles</a> late last year. Prebrowsing is all about anticipating where users want to go and preparing the content ahead of time. It’s a big step toward a faster and less visible internet.</p> <p>Browsers can analyze patterns to predict where users are going to go next, and start DNS resolution and TCP handshakes as soon as users hover over links. But to get the most out of these improvements, we can enable prebrowsing on our web pages, with three techniques at our disposal:</p><ul> <li>DNS prefetching</li> <li>Resource prefetching</li> <li>Prerendering</li> </ul> <p>Now let’s dive into each of these separately.</p> <h2>DNS prefetching</h2> <p>Whenever we know our users are likely to request a resource from a different domain than our site, we can use DNS prefetching to warm the machinery for opening the new URL. The browser can pre-resolve the DNS for the new domain ahead of time, saving several milliseconds when the user actually requests it. We are anticipating, and preparing for an action.</p> <p>Modern browsers are very good at parsing our pages, looking ahead to pre-resolve all necessary domains ahead of time. Chrome goes as far as keeping an internal list with all related domains every time a user visits a site, pre-resolving them when the user returns (you can see this list by navigating to chrome://dns/ in your Chrome browser). However, sometimes access to new URLs may be hidden behind redirects or embedded in JavaScript, and that’s our opportunity to help the browser.</p> <p>Let’s say we are downloading a set of resources from the domain cdn.example.com using a JavaScript call after a user clicks a button. Normally, the browser would have to resolve the DNS at the time of the click, but we can speed up the process by including a <code>dns-prefetch</code> directive in the <code>head</code> section of our page:</p> <pre> <code class="markup">&lt;link rel="dns-prefetch" href="http://cdn.example.com"&gt;</code> </pre> <p>Doing this informs the browser of the existence of the new domain, and it will combine this hint with its own pre-resolution algorithm to start a DNS resolution as soon as possible. The entire process will be faster for the user, since we are shaving off the time for DNS resolution from the operation. (Note that browsers do not guarantee that DNS resolution will occur ahead of time; they simply use our hint as a signal for their own internal pre-resolution algorithm.)</p> <p>But exactly how much faster will pre-resolving the DNS make things? In your Chrome browser, open chrome://histograms/DNS and search for DNS.PrefetchResolution. You’ll see a table like this:</p> <figure><img src="http://d.alistapart.com/401/fig1-o.jpg" alt="Histogram for DNS.PrefetchResolution"></figure> <p>This histogram shows my personal distribution of latencies for DNS prefetch requests. On my computer, for 335 samples, the average time is 88 milliseconds, with a median of approximately 60 milliseconds. Shaving 88 milliseconds off every request our website makes to an external domain? That’s something to celebrate.</p> <p>But what happens if the user never clicks the button to access the cdn.example.com domain? Aren’t we pre-resolving a domain in vain? We are, but luckily for us, DNS prefetching is a very low-cost operation; the browser will need to send only a few hundred bytes over the network, so the risk incurred by a preemptive DNS lookup is very low. That being said, don’t go overboard when using this feature; prefetch only domains that you are confident the user will access, and let the browser handle the rest.</p> <p>Look for situations that might be good candidates to introduce DNS prefetching on your site:</p><ul> <li>Resources on different domains hidden behind 301 redirects</li> <li>Resources accessed from JavaScript code</li> <li>Resources for analytics and social sharing (which usually come from different domains)</li> </ul> <p>DNS prefetching is currently supported on <a href="http://msdn.microsoft.com/en-us/library/ie/dn265039(v=vs.85).aspx">IE11</a>, <a href="http://www.chromium.org/developers/design-documents/dns-prefetching">Chrome</a>, Chrome Mobile, Safari, <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Controlling_DNS_prefetching">Firefox</a>, and Firefox Mobile, which makes this feature widespread among current browsers. Browsers that don’t currently support DNS prefetching will simply ignore the hint, and DNS resolution will happen in a regular fashion.</p> <h2>Resource prefetching</h2> <p>We can go a little bit further and predict that our users will open a specific page in our own site. If we know some of the critical resources used by this page, we can instruct the browser to prefetch them ahead of time:<br /></p><pre> <code>&lt;link rel="prefetch" href="http://cdn.example.com/library.js"&gt;</code> </pre> <p>The browser will use this instruction to prefetch the indicated resources and store them on the local cache. This way, as soon as the resources are actually needed, the browser will have them ready to serve.</p> <p>Unlike DNS prefetching, resource prefetching is a more expensive operation; be mindful of how and when to use it. Prefetching resources can speed up our websites in ways we would never get by merely prefetching new domains—but if we abuse it, our users will pay for the unused overhead.</p> <p>Let’s take a look at the average response size of some of the most popular resources on a web page, courtesy of the <a href="http://httparchive.org/interesting.php#responsesizes">HTTP Archive</a>:</p> <figure><img src="http://d.alistapart.com/401/fig2-o.jpg" alt="Chart of average response size of web page resources"></figure> <p>On average, prefetching a script file (like we are doing on the example above) will cause 16kB to be transmitted over the network (without including the size of the request itself). This means that we will save 16kB of downloading time from the process, plus server response time, which is amazing—provided it’s later accessed by the user. If the user never accesses the file, we actually made the entire workflow slower by introducing an unnecessary delay.</p> <p>If you decide to use this technique, prefetch only the most important resources, and make sure they are cacheable by the browser. Images, CSS, JavaScript, and font files are usually good candidates for prefetching, but HTML responses are not since they aren’t cacheable.</p> <p>Here are some situations where, due to the likelihood of the user visiting a specific page, you can prefetch resources ahead of time:</p><ul> <li>On a login page, since users are usually redirected to a welcome or dashboard page after logging in</li> <li>On each page of a linear questionnaire or survey workflow, where users are visiting subsequent pages in a specific order</li> <li>On a multi-step animation, since you know ahead of time which images are needed on subsequent scenes</li> </ul> <p>Resource prefetching is currently supported on <a href="http://msdn.microsoft.com/en-us/library/ie/dn265039(v=vs.85).aspx">IE11</a>, <a href="https://developers.google.com/chrome/whitepapers/prerender?csw=1">Chrome</a>, Chrome Mobile, <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Link_prefetching_FAQ">Firefox</a>, and Firefox Mobile. (To determine browser compatibility, you can run a quick browser test on <a href="http://prebrowsing.com">prebrowsing.com</a>.)</p> <h2>Prerendering</h2> <p>What about going even further and asking for an entire page? Let’s say we are <em>absolutely</em> sure that our users are going to visit the about.html page in our site. We can give the browser a hint:</p> <pre> <code>&lt;link rel="prerender" href="http://example.com/about.html"&gt;</code> </pre> <p>This time the browser will download and render the page in the background ahead of time, and have it ready for the user as soon as they ask for it. The transition from the current page to the prerendered one would be instantaneous.</p> <p>Needless to say, prerendering is the most risky and costly of these three techniques. Misusing it can cause major bandwidth waste—especially harmful for users on mobile devices. To illustrate this, let’s take a look at this chart, also courtesy of the <a href="http://httparchive.org/trends.php#bytesTotal&amp;reqTotal">HTTP Archive</a>:</p> <figure><img src="http://d.alistapart.com/401/fig3-o.jpg" alt="Graph of total transfer size and total requests to render a web page"></figure> <p>In June of this year, the average number of requests to render a web page was 96, with a total size of 1,808kB. So if your user ends up accessing your prerendered page, then you’ve hit the jackpot: you’ll save the time of downloading almost 2,000kB, plus server response time. But if you’re wrong and your user never accesses the prerendered page, you’ll make them pay a very high cost.</p> <p>When deciding whether to prerender entire pages ahead of time, consider that Google prerenders the top results on its search page, and Chrome prerenders pages based on the historical navigation patterns of users. Using the same principle, you can detect common usage patterns and prerender target pages accordingly. You can also use it, just like resource prefetching, on questionnaires or surveys where you know users will complete the workflow in a particular order.</p> <p>At this time, prerendering is only supported on <a href="http://msdn.microsoft.com/en-us/library/ie/dn265039(v=vs.85).aspx">IE11</a>, <a href="https://developers.google.com/chrome/whitepapers/prerender?csw=1">Chrome</a>, and Chrome Mobile. Neither Firefox nor Safari have added support for this technique yet. (And as with resource prefetching, you can check <a href="http://prebrowsing.com">prebrowsing.com</a> to test whether this technique is supported in your browser.)</p> <h2>A final word</h2> <p>Sites like <a href="http://googlewebmastercentral.blogspot.com/2011/06/announcing-instant-pages.html">Google</a> and <a href="http://blogs.bing.com/search/2013/10/14/a-deeper-look-at-task-completion/">Bing</a> are using these techniques extensively to make search instant for their users. Now it’s time for us to go back to our own sites and take another look. Can we make our experiences better and faster with prefetching and prerendering?</p> <p>Browsers are already working behind the scenes, looking for patterns in our sites to make navigation as fast as possible. Prebrowsing builds on that: we can combine the insight we have on our own pages with further analysis of user patterns. By helping browsers do a better job, we speed up and improve the experience for our users.</p><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/McnEJXwo09Q" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)
18. Aug 2014
Valediction
<p>When I first met <a href="http://bearskinrug.co.uk/">Kevin Cornell</a> in the early 2000s, he was employing his illustration talent mainly to draw caricatures of his fellow designers at a small Philadelphia design studio. Even in that rough, dashed-off state, his work floored me. It was as if <a href="http://www.charlesaddams.com">Charles Addams</a> and my favorite <cite>Mad Magazine</cite> illustrators from the 1960s had blended their DNA to spawn the perfect artist.</p> <p>Kevin would deny that label, but artist he is. For there is a vision in his mind, a way of seeing the world, that is unlike anyone else’s—and he has the gift to make you see it too, and to delight, inspire, and challenge you with what he makes you see.</p> <p>Kevin was part of a small group of young designers and artists who had recently completed college and were beginning to establish careers. Others from that group included <a href="http://v5.robweychert.com/about/">Rob Weychert</a>, <a href="http://mattsutter.com">Matt Sutter</a>, and <a href="http://jasonsantamaria.com">Jason Santa Maria</a>. They would all go on to do fine things in our industry. </p> <p>It was Jason who brought Kevin on as house illustrator during the <a href="http://alistapart.com/article/ala40"><cite>A List Apart</cite> 4.0 brand overhaul</a> in 2005, and Kevin has worked his strange magic for us ever since. If you’re an <cite>ALA</cite> reader, you know how he translates the abstract web design concepts of our articles into concrete, witty, and frequently absurd situations. Above all, he is a storyteller—if pretentious designers and marketers haven’t sucked all the meaning out of that word. </p> <p>For nearly 10 years, Kevin has taken our well-vetted, practical, frequently technical web design and development pieces, and elevated them to the status of classic <cite>New Yorker</cite> articles. Tomorrow he publishes his last new illustrations with us. There will never be another like him. And for whatever good it does him, Kevin Cornell has my undying thanks, love, and gratitude. </p><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/v0JRauu8zwQ" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)
18. Aug 2014
My Favorite Kevin Cornell
<p>After 200 issues—yes, <em>two hundred</em>—Kevin Cornell is retiring from his post as <cite>A List Apart</cite>’s staff illustrator. Tomorrow’s issue will be the last one featuring new illustrations from him.</p> <p>Sob.</p> <p>For years now, we’ve eagerly awaited Kevin’s illustrations each issue, opening his files with all the patience of a kid tearing into a new LEGO set.</p> <p>But after nine years and more than a few lols, it’s time to give Kevin’s beautifully deranged brain a rest.</p> <p>We’re still figuring out what comes next for <cite>ALA</cite>, but while we do, we’re sending Kevin off the best way we know how: by sharing a few of our favorite illustrations. Read on for stories from <cite>ALA</cite> staff, past and present—and join us in thanking Kevin for his talent, his commitment, and his uncanny ability to depict seemingly any concept using animals, madmen, and circus figures.<br /> —</p> <figure><img src="http://alistapart.com/d/thedisciplineofcontentstrategy/discipline-content-strategy.jpg" alt=""></figure> <p>Of all the things I enjoyed about working on <cite>A List Apart</cite>, I loved anticipating the reveal: seeing Kevin’s illos for each piece, just before the issue went live. Every illustration was always a surprise—even to the staff. My favorite, hands-down, was his artwork for “<a href="http://alistapart.com/article/thedisciplineofcontentstrategy">The Discipline of Content Strategy</a>,” by Kristina Halvorson. In 2008, content was web design&#8217;s “elephant in the room” and Kevin’s visual metaphor nailed it. In a drawing, he encapsulated thoughts and feelings many had within the industry but were unable to articulate. That’s the mark of a master.</p> <p>—Krista Stevens, <em>Editor-in-chief, 2006–2012</em></p> <figure><img src="http://alistapart.com/d/future-ready-content/future-ready-content.jpg" alt=""></figure> <p>In the fall of 2011, I submitted my first article to <cite>A List Apart</cite>. I was terrified: I didn’t know anyone on staff. The authors’ list read like a who’s who of web design. The archives were intimidating. But I had ideas, dammit. I hit send.</p> <p>I told just one friend what I’d done. His eyes lit up. “Whoa. You&#8217;d get a Kevin Cornell!” he said.</p> <p>Whoa indeed. I might get a Kevin Cornell?! I hadn’t even thought about that yet.</p> <p>Like Krista, I fell in love with Kevin’s illustration for “The Discipline of Content Strategy”—an illustration that meant the world to me as I helped my clients see their own content elephants. The idea of having a Cornell of my own was exciting, but terrifying. Could I possibly write something worthy of his illustration?</p> <p>Months later, there it was on the screen: little modular sandcastles illustrating my <a href="http://alistapart.com/article/future-ready-content">article on modular content</a>. I was floored.</p> <p>Now, after two years as <cite>ALA</cite>’s editor in chief, I’ve worked with Kevin through dozens of issues. But you know what? I’m just as floored as ever.</p> <p>Thank you, Kevin, you brilliant, bizarre, wonderful friend.</p> <p>—Sara Wachter-Boettcher, <em>Editor-in-chief</em></p> <figure><img src="http://alistapart.com/d/accessibilityseo/html_with_hat.jpg" alt=""></figure> <p>It&#8217;s impossible for me to choose a favorite of Kevin’s body of work for <cite>ALA</cite>, because my favorite Cornell illustration is the witty, adaptable, humane language of characters and symbols underlying his years of work. If I <em>had</em> to pick a single illustration to represent the evolution of his visual language, I think it would be the hat-wearing nested egg with the winning smile that opened Andy Hagen’s “<a href="http://alistapart.com/article/accessibilityseo">High Accessibility is Effective Search Engine Optimization</a>.” An important article but not, perhaps, the juiciest title <cite>A List Apart</cite> has ever run…and yet there’s that little egg, grinning in his slightly dopey way.</p> <p>If my memory doesn’t fail me, this is the second appearance of the nested Cornell egg—we saw the first a few issues before in <a href="http://alistapart.com/article/pdf_accessibility">Issue 201</a>, where it represented the nested components of an HTML page. When it shows up here, in Issue 207, we realize that the egg wasn’t a cute one-off, but the first syllable of a visual language that we’ll see again and again through the years. And what a language! Who else could make semantic markup seem not just clever, but shyly adorable?</p> <p>A wander through the <cite>ALA</cite> archives provides a view of Kevin’s changing style, but something visible only backstage was his startlingly quick progression from reading an article to sketching initial ideas in conversation with then-creative director Jason Santa Maria to turning out a lovely miniature—and each illustration never failed to make me appreciate the article it introduced in a slightly different way. When I was at <cite>ALA</cite>, Kevin’s unerring eye for the important detail as a reader astonished me almost as much as his ability to give that (often highly technical, sometimes very dry) idea a playful and memorable visual incarnation. From the very first time his illustrations hit the <cite>A List Apart</cite> servers he’s shared an extraordinary gift with its readers, and as a reader, writer, and editor, I will always count myself in his debt.</p> <p>—Erin Kissane, <em>Editor-in-chief, contributing editor, 1999–2009</em></p> <figure><img src="http://alistapart.com/d/what-i-learned-about-the-web-in-2011/what-i-learned-about-the-web-in-2011.jpg" alt=""></figure> <p>So much of what makes Kevin’s illustrations work are the gestures. The way the figure sits a bit slouched, but still perched on gentle tippy toes, determinedly occupied pecking away on his phone. With just a few lines, Kevin captures a mood and moment anyone can feel.</p> <p>—Jason Santa Maria, <em>Former creative director</em></p> <figure><img src="http://alistapart.com/d/ALA368_alaredesign_300.png" alt=""></figure> <p>I’ve had the pleasure of working with Kevin on the illustrations for each issue of <cite>A List Apart</cite> since we launched the latest site redesign in early 2013. By working, I mean replying to his email with something along the lines of “Amazing!” when he sent over the illustrations every couple of weeks.</p> <p>Prior to launching the new design, I had to go through the backlog of Kevin’s work for <cite>ALA</cite> and do the production work needed for the new layout. This bird’s eye view gave me an appreciation of the ongoing metaphorical world he had created for the magazine—the <a href="http://alistapart.com/article/putyourcontentinmypocket">birds</a>, <a href="http://alistapart.com/article/thedisciplineofcontentstrategy">elephants</a>, <a href="http://alistapart.com/article/semanticsinhtml5">weebles</a>, <a href="http://alistapart.com/article/audiences-outcomes-and-determining-user-needs">mad scientists</a>, <a href="http://alistapart.com/article/usable-yet-useless-why-every-business-needs-product-discovery">ACME products</a>, and other bits of amusing weirdness that breathed life into the (admittedly, sometimes) dry topics covered.</p> <p>If I had to pick a favorite, it would probably be the illustration that accompanied the unveiling of the redesign, <a href="http://alistapart.com/article/a-list-apart-relaunches-new-features-new-design"><cite>A List Apart</cite> 5.0</a>. The shoe-shine man carefully working on his own shoes was the perfect metaphor for both the idea of design as craft and the back-stage nature of the profession—working to make others shine, so to speak. It was a simple and humble concept, and I thought it created the perfect tone for the launch.</p> <p>—Mike Pick, <em>Creative director</em></p> <figure><img src="http://alistapart.com/d/ALA383_sustainabledesign_300.png" alt=""></figure> <p>So I can’t pick one favorite illustration that Kevin’s done. I just can’t. I could prattle on about <a href="http://alistapart.com/article/the-web-aesthetic" title="Paul Robert Lloyd’s “The Web Aesthetic”">this</a>, <a href="http://alistapart.com/article/everything-in-its-right-pace" title="Hannah Donovan’s “Everything in its Right Pace”">that</a>, or <a href="http://alistapart.com/article/orbital-content" title="Cameron Koczon’s “Orbital Content”">that other one</a>, and tell you everything I love about each of ’em. I mean, hell: I still have a print of the illustration he did for <a href="http://alistapart.com/article/whereourstandardswentwrong">my very first ALA article</a>. (The illustration is, of course, far stronger than the essay that follows it.)</p> <p>But his illustration for <a href="http://alistapart.com/article/sustainable-web-design">James Christie’s excellent “Sustainable Web Design”</a> is a perfect example of everything I love about Kevin’s ALA work: how he conveys emotion with a few deceptively simple lines; the humor he finds in contrast; the occasional chicken. Like most of Kevin’s illustrations, I’ve seen it whenever I reread the article it accompanies, and I find something new to enjoy each time.</p> <p>It’s been an honor working alongside your art, Kevin—and, on a few lucky occasions, having my words appear below it.</p> <p>Thanks, Kevin.</p> <p>—Ethan Marcotte, <em>Technical editor</em></p> <figure><img src="http://alistapart.com/d/orbital-content/orbital-content.jpg" alt=""></figure> <p>Kevin’s illustration for Cameron Koczon’s “<a href="http://alistapart.com/article/orbital-content">Orbital Content</a>” is one of the best examples I can think of to show off his considerable talent. Those balloons are just perfect: vaguely reminiscent of cloud computing, but tethered and within arm’s reach, and evoking the fun and chaos of carnivals and county fairs. No other illustrator I’ve ever worked with is as good at translating abstract concepts into compact, visual stories. <cite>A List Apart</cite> won’t be the same without him.</p> <p>—Mandy Brown, <em>Former contributing editor</em></p> <figure class="responsive-hero" data-picture data-alt=""> <div data-src="http://d.alistapart.com/_made/d/misc-images/rwd-1_2577_1165_60.jpg" ></div> <div data-src="http://d.alistapart.com/_made/d/misc-images/rwd-2_1400_761_60.jpg" data-media="(max-width: 1400px)"></div> <div data-src="http://d.alistapart.com/_made/d/misc-images/rwd-3_960_690_60.jpg" data-media="(max-width: 960px)"></div> <div data-src="http://d.alistapart.com/_made/d/misc-images/rwd-4_450_736_60.jpg" data-media="(max-width: 450px)"></div> <noscript><img src="http://d.alistapart.com/_made/d/ALA306_respdesign_300_960_439_10.jpg" alt=""></noscript> </figure> <p>Kevin has always had what seems like a preternatural ability to take an abstract technical concept and turn it into a <a href="http://alistapart.com/article/good-help-is-hard-to-find">clear and accessible illustration</a>.</p> <p>For me, my favorite pieces are the ones he did for the 3rd anniversary of the original “<a href="http://alistapart.com/article/responsive-web-design">Responsive Web Design</a>” article…the web’s first “responsive” illustration? <em>Try squishing your browser here to see it in action—Ed</em></p> <p>—Tim Murtaugh, <em>Technical director</em></p> <figure><img src="http://alistapart.com/d/12lessonsCSSandstandards/twelve_lessons.jpg" alt=""></figure> <p>I think it may be impossible for me to pick just one illustration of Kevin’s that I really like. Much like trying to pick your one favorite album or that absolutely perfect movie, picking a true favorite is simply folly. You can whittle down the choices, but it’s guaranteed that the list will be sadly incomplete and longer (much longer) than one.</p> <p>If held at gunpoint, however ridiculous that sounds, and asked which of Kevin’s illustrations is my favorite, close to the top of the list would definitely be “<a href="http://alistapart.com/article/12lessonsCSSandstandards">12 Lessons for Those Afraid of CSS Standards</a>.” It’s just so subtle, and yet so pointed.</p> <p>What I personally love the most about Kevin’s work is the overall impact it can have on people seeing it for the first time. It has become commonplace within our ranks to hear the phrase, “This is my new favorite Kevin Cornell illustration” with the publishing of each issue. And rightly so. His wonderfully simple style (which is also deceptively clever and just so smart) paired with the fluidity that comes through in his brush work is magical. Case in point for me would be his piece for “<a href="http://alistapart.com/article/the-problem-with-passwords">The Problem with Passwords</a>” which just speaks volumes about the difficulty and utter ridiculousness of selecting a password and security question.</p> <p>We, as a team, have truly been spoiled by having him in our ranks for as long as we have. Thank you Kevin.</p> <p>—Erin Lynch, <em>Production manager</em></p> <figure><img src="http://alistapart.com/d/content-modelling-a-master-skill/content-modelling-a-master-skill.jpg" alt=""></figure> <p>The elephant was my first glimpse at Kevin&#8217;s elegantly whimsical visual language. I first spotted it, a patient behemoth being studied by nonplussed little figures, atop Kristina Halvorson’s “<a href="http://alistapart.com/article/thedisciplineofcontentstrategy">The Discipline of Content Strategy</a>,” which made no mention of elephants at all. Yet the elephant added to my understanding: content owners from different departments focus on what&#8217;s nearest to them. The content strategist steps back to see the entire thing.</p> <p>When Rachel Lovinger wrote about “<a href="http://alistapart.com/article/content-modelling-a-master-skill">Content Modelling</a>,” the elephant made a reappearance as a yet-to-be-assembled, stylized elephant doll. The unflappable elephant has also been the mascot of product development at the hands of a team trying to <a href="http://alistapart.com/article/connected-ux">construct it from user research</a>, strutted its stuff as <a href="http://alistapart.com/article/content-strategist-as-digital-curator">curated content</a>, enjoyed the diplomatic <a href="http://alistapart.com/article/tinker-tailor-content-strategist">guidance of a ringmaster</a>, and been <a href="http://alistapart.com/article/seeing-the-elephant-defragmenting-user-research">impersonated by a snake</a> to tell us that busting silos is helped by a better understanding of others’ discourse conventions.</p> <p>The delight in discovering Kevin&#8217;s visual rhetoric doesn&#8217;t end there. With <a href="http://alistapart.com/article/avoidedgecases">doghouses</a>, <a href="http://alistapart.com/article/hattrick">birdhouses</a>, and <a href="http://alistapart.com/article/growing-your-design-business">fishbowls</a>, Kevin speaks of environments for users and workers. With <a href="http://alistapart.com/article/a-pixel-identity-crisis">owls</a> he represents the mobile experience and <a href="http://alistapart.com/article/smartphone-browser-landscape">smartphones</a>. With a team arranging themselves to fit into a group photo, he makes the concept of <a href="http://alistapart.com/article/responsive-web-design">responsive design</a> easier to grasp.</p> <p>Not only has Kevin trained his hand and eye to produce the gestures, textures, and compositions that are uniquely his, but he has trained his mind to speak in a distinctive visual language—and he can do it on deadline. That is some serious mastery of the art.</p> <p>—Rose Weisburd, <em>Columns editor</em></p><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/kLBd_yugW7w" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)
15. Aug 2014
Measure Twice, Cut Once
<p>Not too long ago, I had a few rough days in support of a client project. The client had a big content release, complete with a media embargo and the like. I woke up on the day of the launch, and things were bad. I was staring straight into a wall of red.</p> <figure><img src="http://alistapart.com/d/misc-images/Blog_images/crash.png" alt="A response and downtime report"></figure> <p>Thanks to <a href="http://en.wikipedia.org/wiki/No_Silver_Bullet">the intrinsic complexity of software engineering</a>, these situations happen—<a href="http://cognition.happycog.com/article/under-pressure">I’ve been through them before, and I’ll certainly be through them again</a>. While the particulars change, there are two guiding principles I rely on when I find myself looking up that hopelessly tall cliff of red.</p> <p>You can’t be at the top of your game while stressed and nervous about the emergency, so unless there’s an obvious, quick-to-deploy resolution, you need to give yourself some cover to work.</p> <p>What that means will be unique to every situation, but as strange as it may sound, don’t dive into work on the be-all and end-all solution right off the bat. Take a few minutes to find a way to provide a bit of breathing room for you to build and implement the long-term solution in a stable, future-friendly way.</p> <p>Ideally, the cover you’re providing shouldn’t affect the users too much. Consider beefing up your caching policies to lighten the load on your servers as much as possible. If there’s any functionality that is particularly taxing on your hardware and isn’t mission critical, disable it temporarily. Even if keeping the servers alive means pressing a button every 108 minutes like you’re <a href="http://en.wikipedia.org/wiki/Dharma_Initiative#Station_3:_The_Swan">Desmond from Lost</a>, do it.</p> <p>After you’ve got some cover, work the problem slowly and deliberately. Think solutions through two or three times to be sure they’re the right course of action.</p> <p>With the pressure eased, you don’t have to rush through a cycle of building, deploying, and testing potential fixes. Rushing leads to oversight of important details, and typically, that cycle ends the first time a change fixes (or seemingly fixes) the issue, which can lead to sloppy code and weak foundations for the future.</p> <p>If the environment doesn’t allow you to ease the pressure enough to work slowly, go ahead and cycle your way to a hacky solution. But don’t forget to come back and work the root issue, or else temporary fixes will pile up and eat away at your system’s architecture like a swarm of termites.</p> <p>Emergencies often require more thought and planning than everyday development, so be sure to give yourself the necessary time. Reactions alone may patch an issue, but thoughtfulness can solve it.</p> <p>&nbsp;</p><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/lA0mO7gh2u0" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)
26. Aug 2014
Media Accessibility User Requirements Working Draft Updated
The Protocols and Formats Working Group (PFWG) today published an updated Working Draft of Media Accessibility User Requirements, a planned W3C Working Group Note. This document describes the accessibility requirements of people with disabilities with respect to audio and video on the Web, particularly in the context of HTML5. It explains alternative content technologies that [&#8230;][mehr] (Quelle: W3C News)
26. Aug 2014
Wake Lock: Use cases Note Published
The Web and Mobile Interest Group has published a Group Note of Wake Lock: Use cases. This document illustrates the use cases a mechanism to control the power-saving state of a device would enable on the Web platform. Learn more about the Mobile Web Initiative Activity.[mehr] (Quelle: W3C News)
26. Aug 2014
Standards for Web Applications on Mobile: current state and roadmap
W3C has published the July 2014 edition of Standards for Web Applications on Mobile, an overview of the various technologies developed in W3C that increase the capabilities of Web applications, and how they apply more specifically to the mobile context. A deliverable of the HTML5Apps project, this edition of the document includes changes and additions [&#8230;][mehr] (Quelle: W3C News)
21. Aug 2014
W3C Invites Implementations of HTML5 Image Description Extension
The HTML Working Group has published a Candidate Recommendation of the HTML5 Image Description Extension, which defines the &#8220;longdesc&#8221; attribute that enables web authors to provide longer textual descriptions for complex images. This specification is part of W3C&#8217;s work to ensure that the Open Web Platform is accessible to people with disabilities. This publication addresses [&#8230;][mehr] (Quelle: W3C News)
14. Aug 2014
Workshop Report: W3C Workshop on the Web of Things
W3C published today the final report of the W3C Workshop on the Web of Things that was held on 25-26 June 2014, in Berlin (Germany). The workshop examined the opportunities for open Web standards for service platforms in the network edge and the cloud, along with the challenges for security, privacy and the integration with [&#8230;][mehr] (Quelle: W3C News)
21. Aug 2014
Tracking Compliance and Scope Draft Published
The Tracking Protection Working Group has published a Working Draft of Tracking Compliance and Scope. This specification defines the meaning of a Do Not Track (DNT) preference and sets out practices for websites to comply with this preference. Learn more about the Privacy Activity.[mehr] (Quelle: W3C News)
21. Aug 2014
First Public Working Draft: Referrer Policy
The Web Application Security Working Group has published a First Public Working Draft of Referrer Policy. This document describes how an author can set a referrer policy for documents they create, and the impact of such a policy on the referer HTTP header for outgoing requests and navigations. Learn more about the Security Activity.[mehr] (Quelle: W3C News)
14. Aug 2014
W3C Workshop Report: MultilingualWeb workshop in Madrid
A report of the MultilingualWeb workshop in Madrid is now available from the MultilingualWeb site. It contains a summary of each session with links to presentation slides and minutes taken during the workshop in Madrid. The workshop was a huge success, with approximately 110 participants, and with the aligned LIDER roadmapping workshop. The Workshop was [&#8230;][mehr] (Quelle: W3C News)
9. Sep 2014
W3C Updates Recommendation Track Process
W3C enacted today the 1 August 2014 W3C Process Document. This revision updates the chapter that defines the Recommendation Track, the steps and requirements followed by W3C Working Groups to standardize Web technology. The W3C technical report development process is designed to support multiple specification development methodologies: maximize consensus about the content of stable technical [&#8230;][mehr] (Quelle: W3C News)
14. Aug 2014
New Privacy Policy for W3C Site
W3C today updated its privacy policy to reflect current technology and W3C practices. The policy does not make material changes to what W3C does with information resulting from visits to our site. If you have questions, please write to site-policy@w3.org.[mehr] (Quelle: W3C News)
8. Aug 2014
Upcoming coordinated Workshop: Encouraging open data usage by commercial developers
W3C and its European host, ERCIM, announce the report from the first workshop in the Share-PSI 2.0 series. Share-PSI 2.0 is the European network for the exchange of experience and ideas around implementing open data policies in the public sector. It brings together government departments, standards bodies, academic institutions, commercial organisations, trade associations and interest [&#8230;][mehr] (Quelle: W3C News)
5. Aug 2014
How We Read
<p>I want you to think about what you’re doing right now. I mean <em>really</em> think about it. As your eyes move across these lines and funnel information to your brain, you’re taking part in a conversation I started with you. The conveyance of that conversation is the type you’re reading on this page, but you’re also filtering it through your experiences and past conversations. You’re putting these words into context. And whether you’re reading this book on paper, on a device, or at your desk, your environment shapes your experience too. Someone else reading these words may go through the same motions, but their interpretation is inevitably different from yours.</p> <p>This is the most interesting thing about typography: it’s a chain reaction of time and place with you as the catalyst. The intention of a text depends on its presentation, but it needs you to give it meaning through reading.</p> <p>Type and typography wouldn’t exist without our need to express and record information. Sure, we have other ways to do those things, like speech or imagery, but type is efficient, flexible, portable, and translatable. This is what makes typography not only an art of communication, but one of nuance and craft, because like all communication, its value falls somewhere on a spectrum between success and failure.</p> <p>The act of reading is beautifully complex, and yet, once we know how, it’s a kind of muscle memory. We rarely think about it. But because reading is so intrinsic to every other thing about typography, it’s the best place for us to begin. We’ve all made something we wanted someone else to read, but have you ever thought about that person’s reading experience?</p> <p>Just as you’re my audience for this book, I want you to look at your audience too: your readers. One of design’s functions is to entice and delight. We need to welcome readers and convince them to sit with us. But what circumstances affect reading?</p> <h2>Readability</h2> <p>Just because something is legible doesn’t mean it’s readable. <em>Legibility</em> means that text can be interpreted, but that’s like saying tree bark is edible. We’re aiming higher. <em>Readability</em> combines the emotional impact of a design (or lack thereof ) with the amount of effort it presumably takes to read. You’ve heard of <em>TL;DR</em> (too long; didn’t read)? Length isn’t the only detractor to reading; poor typography is one too. To <a href="http://bkaprt.com/owt/2/">paraphrase Stephen Coles</a>, the term readability doesn’t ask simply, “Can you read it?” but “Do you want to read it?”</p> <p>Each decision you make could potentially hamper a reader’s understanding, causing them to bail and update their Facebook status instead. Don’t let your design deter your readers or stand in the way of what they want to do: <em>read</em>.</p> <p>Once we bring readers in, what else can we do to keep their attention and help them understand our writing? Let’s take a brief look at what the reading experience is like and how design influences it.</p> <h2>The act of reading</h2> <p>When I first started designing websites, I assumed everyone read my work the same way I did. I spent countless hours crafting the right layout and type arrangements. I saw the work as a collection of the typographic considerations I made: the lovingly set headlines, the ample whitespace, the typographic rhythm (fig 1.1). I assumed everyone would see that too.</p> <figure> <img src="http://d.alistapart.com/400/OWT-fig1-1.png" alt="A normal paragraph of text"> <figcaption>Fig 1.1: A humble bit of text. But what actually happens when someone reads it?</figcaption></figure> <p>It’s appealing to think that’s the case, but reading is a much more nuanced experience. It’s shaped by our surroundings (am I in a loud coffee shop or otherwise distracted?), our availability (am I busy with something else?), our needs (am I skimming for something specific?), and more. Reading is not only informed by what’s going on with us at that moment, but also governed by how our eyes and brains work to process information. What you <em>see</em> and what you’re <em>experiencing</em> as you read these words is quite different.</p> <p>As our eyes move across the text, our minds gobble up the type’s <em>texture</em>—the sum of the positive and negative spaces inside and around letters and words. We don’t linger on those spaces and details; instead, our brains do the heavy lifting of parsing the text and assembling a mental picture of what we’re reading. Our eyes see the type and our brains see Don Quixote chasing a windmill.</p> <p>Or, at least, that’s what we hope. This is the ideal scenario, but it depends on our design choices. Have you ever been completely absorbed in a book and lost in the passing pages? Me too. Good writing can do that, and good typography can grease the wheels. Without getting too scientific, let’s look at the physical process of reading.</p> <h3>Saccades and fixations</h3> <p>Reading isn’t linear. Instead, our eyes perform a series of back and forth movements called <em>saccades</em>, or lightning-fast hops across a line of text (fig 1.2). Sometimes it’s a big hop; sometimes it’s a small hop. Saccades help our eyes register a lot of information in a short span, and they happen many times over the course of a second. A saccade’s length depends on our proficiency as readers and our familiarity with the text’s topic. If I’m a scientist and reading, uh, science stuff, I may read it more quickly than a non-scientist, because I’m familiar with all those science-y words. Full disclosure: I’m not really a scientist. I hope you couldn’t tell.</p> <figure> <img src="http://d.alistapart.com/400/OWT-fig1-2.png" alt="Paragraph showing saccades or the movement our eyes make as we read a line of text"> <figcaption>Fig 1.2: Saccades are the leaps that happen in a split second as our eyes move across a line of text.</figcaption></figure> <p>Between saccades, our eyes stop for a fraction of a second in what’s called a <em>fixation</em> (fig 1.3). During this brief pause we see a couple of characters clearly, and the rest of the text blurs out like ripples in a pond. Our brains assemble these fixations and decode the information at lightning speed. This all happens on reflex. Pretty neat, huh?</p> <figure> <img src="http://d.alistapart.com/400/OWT-fig1-3.png" alt="Paragraph showing the fixations or stopping points our eyes make as we read a paragraph"> <figcaption>Fig 1.3: Fixations are the brief moments of pause between saccades.</figcaption></figure> <p>The shapes of letters and the shapes they make when combined into words and sentences can significantly affect our ability to decipher text. If we look at an average line of text and cover the top halves of the letters, it becomes very difficult to read. If we do the opposite and cover the bottom halves, we can still read the text without much effort (fig 1.4).</p> <figure> <img src="http://d.alistapart.com/400/OWT-fig1-4.png" alt="Paragraph showing how the upper half of letters are still readable to the human eyes"> <figcaption>Fig 1.4: Though the letters’ lower halves are covered, the text is still mostly legible, because much of the critical visual information is in the tops of letters.</figcaption></figure> <p>This is because letters generally carry more of their identifying features in their top halves. The sum of each word’s letterforms creates the word shapes we recognize when reading.</p> <p>Once we start to subconsciously recognize letters and common words, we read faster. We become more proficient at reading under similar conditions, an idea best encapsulated by type designer Zuzana Licko: “Readers read best what they read most.”</p> <p>It’s not a hard and fast rule, but close. The more foreign the letterforms and information are to us, the more slowly we discern them. If we traveled back in time to the Middle Ages with a book typeset in a super-awesome sci-fi font, the folks from the past might have difficulty with it. But here in the future, we’re adept at reading that stuff, all whilst flying around on hoverboards.</p> <p>For the same reason, we sometimes have trouble deciphering someone else’s handwriting: their letterforms and idiosyncrasies seem unusual to us. Yet we’re pretty fast at reading our own handwriting (fig 1.5).</p> <figure> <img src="http://d.alistapart.com/400/1-5.jpg" alt="Three paragraphs of handwritten text"> <figcaption>Fig 1.5: While you’re very familiar with your own handwriting, reading someone else’s (like mine!) can take some time to get used to.</figcaption></figure> <p>There have been many studies on the reading process, with only a bit of consensus. Reading acuity depends on several factors, starting with the task the reader intends to accomplish. Some studies show that we read in <em>word shapes</em>—picture a chalk outline around an entire word—while others suggest we decode things letter by letter. Most findings agree that ease of reading relies on the visual feel and <em>precision</em> of the text’s setting (how much effort it takes to discern one letterform from another), combined with the reader’s own proficiency.</p> <p>Consider a passage set in all capital letters (fig 1.6). You can become adept at reading almost anything, but most of us aren’t accustomed to reading lots of text in all caps. Compared to the normal sentence-case text, the all-caps text feels pretty impenetrable. That’s because the capital letters are blocky and don’t create much contrast between themselves and the whitespace around them. The resulting word shapes are basically plain rectangles (fig 1.7).</p> <figure> <img src="http://d.alistapart.com/400/OWT-fig1-6.png" alt="Paragraph illustrating the difficulty of reading text in all caps"> <figcaption>Fig 1.6: Running text in all caps can be hard to read quickly when we’re used to sentence case.</figcaption></figure> <figure> <img src="http://d.alistapart.com/400/OWT-fig1-7.png" alt="Paragraph showing how words are recognizable by the shapes they form"> <figcaption>Fig 1.7: Our ability to recognize words is affected by the shapes they form. All-caps text forms blocky shapes with little distinction, while mixed-case text forms irregular shapes that help us better identify each word.</figcaption></figure> <p>Realizing that the choices we make in typefaces and typesetting have such an impact on the reader was eye-opening for me. Small things like the size and spacing of type can add up to great advantages for readers. When they don’t notice those choices, we’ve done our job. We’ve gotten out of their way and helped them get closer to the information.</p> <h2>Stacking the deck</h2> <p>Typography on screen differs from print in a few key ways. Readers deal with two reading environments: the physical space (and its lighting) and the device. A reader may spend a sunny day at the park reading on their phone. Or perhaps they’re in a dim room reading subtitles off their TV ten feet away. As designers, we have no control over any of this, and that can be frustrating. As much as I would love to go over to every reader’s computer and fix their contrast and brightness settings, this is the hand we’ve been dealt.</p> <p>The best solution to unknown unknowns is to make our typography perform as well as it can in all situations, regardless of screen size, connection, or potential lunar eclipse. We’ll look at some methods for making typography as sturdy as possible later in this book.</p> <p>It’s up to us to keep the reading experience unencumbered. At the core of typography is our audience, our readers. As we look at the building blocks of typography, I want you to keep those readers in mind. Reading is something we do every day, but we can easily take it for granted. Slapping words on a page won’t ensure good communication, just as mashing your hands across a piano won’t make for a pleasant composition. The experience of reading and the effectiveness of our message are determined by both <em>what</em> we say and <em>how</em> we say it. Typography is the primary tool we use as designers and visual communicators to speak.</p> <p>&nbsp;</p><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/C3Q4XTZD2ME" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)
30. Jul 2014
The Most Dangerous Word In Software Development
<p>“Just put it up on a server somewhere.”</p> <p>“Just add a favorite button to the right side of the item.”</p> <p>“Just add [insert complex option here] to the settings screen.”</p> <p>Usage of the word “just” points to a lot of assumptions being made. A few months ago, <a href="https://twitter.com/brad_frost">Brad Frost</a> <a href="https://the-pastry-box-project.net/brad-frost/2014-january-28">shared some thoughts</a> on how the word applies to knowledge.</p><figure class="quote"> <blockquote>“Just” makes me feel like an idiot. “Just” presumes I come from a specific background, studied certain courses in university, am fluent in certain technologies, and have read all the right books, articles, and resources.</blockquote> </figure> <p>He points out that learning is never as easy as it is made to seem, and he’s right. But there is a direct correlation between the amount of knowledge you’ve acquired and the danger of the word “just.” The more you know, the bigger the problems you solve, and the bigger the assumptions are that are hiding behind the word.</p> <p>Take the comment, “Just put it up on a server somewhere.” How many times have we heard that? But taking a side project running locally and deploying it on real servers requires time, money, and hard work. Some tiny piece of software somewhere will probably be the wrong version, and will need to be addressed. The system built locally probably isn’t built to scale perfectly.</p> <p>“Just” implies that all of the thinking behind a feature or system has been done. Even worse, it implies that all of the decisions that will have to be made in the course of development have already been discovered—and that’s never the case.</p> <p>Things change when something moves from concept to reality. As <a href="https://twitter.com/dwiskus">Dave Wiskus</a> said on a <a href="http://www.imore.com/debug-37-simmons-wiskus-gruber-and-vesper-sync">recent episode of Debug</a>, “everything changes when fingers hit glass.”</p> <p>The favorite button may look fine on the right side, visually, but it might be in a really tough spot to touch. What about when favoriting isn’t the only action to be taken? What happens to the favorite button then?</p> <p>Even once favoriting is built and in testing, it should be put through its paces again. In use, does favoriting provide enough value to warrant is existence? After all, <a href="http://gettingreal.37signals.com/ch05_Start_With_No.php">“once that feature’s out there, you’re stuck with it.”</a></p> <p>When you hear the word “just” being thrown around, dig deep into that statement and find all of the assumptions made within it. Zoom out and think slow.</p> <p>Your product lives and dies by the decisions discovered between ideation and creation, so don’t just put it up on a server somewhere.</p><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/Ei6wVulYF1M" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)
29. Jul 2014
Radio-Controlled Web Design
<p>Interactive user interfaces are a necessity in our responsive world. Smaller screens constrain the amount of content that can be displayed at any given time, so we need techniques to keep navigation and secondary information out of the way until they’re needed. From tabs and modal overlays to hidden navigation, we’ve created many powerful design patterns that show and hide content using JavaScript. </p> <p>JavaScript comes with its own mobile challenges, though. Network speeds and data plans vary wildly, and every byte we deliver has an impact on the render speed of our pages or applications. When we add JavaScript to a page, we’re typically adding an external JavaScript file and an optional (usually large) library like jQuery. These interfaces won’t become usable until all the content, JavaScript files included, is downloaded—creating a slow and sluggish first impression for our users. </p> <p>If we could create these content-on-demand patterns with no reliance on JavaScript, our interfaces would render earlier, and users could interact with them as soon as they were visible. By shifting some of the functionality to CSS, we could also reduce the amount of JavaScript needed to render the rest of our page. The result would be smaller file sizes, faster page-load times, interfaces that are available earlier, and the same functionality we’ve come to rely on from these design patterns. </p> <p>In this article, I’ll explore a technique I’ve been working on that does just that. It’s still a bit experimental, so use your best judgment before using it in your own production systems.</p> <h2>Understanding JavaScript’s role in maintaining state</h2> <p>To understand how to accomplish these design patterns without JavaScript at all, let’s first take a look at the role JavaScript plays in maintaining state for a simple tabbed interface.</p> <figure class="text full-width"> <p data-height="310" data-theme-id="0" data-slug-hash="aKbBf" data-default-tab="result" class='codepen'>See the demo: <a href='http://alistapart.com/d/399/1-javascript-tabs-no-aria/'>Show/hide example</a></p> <script async src="//codepen.io/assets/embed/ei.js"></script> </figure> <p>Let’s take a closer look at the underlying code.</p> <pre><code class="language-markup">&lt;div class=&quot;js-tabs&quot;&gt; &lt;div class=&quot;tabs&quot;&gt; &lt;a href=&quot;#starks-panel&quot; id=&quot;starks-tab&quot; class=&quot;tab active&quot;&gt;Starks&lt;/a&gt; &lt;a href=&quot;#lannisters-panel&quot; id=&quot;lannisters-tab&quot; class=&quot;tab&quot;&gt;Lannisters&lt;/a&gt; &lt;a href=&quot;#targaryens-panel&quot; id=&quot;targaryens-tab&quot; class=&quot;tab&quot;&gt;Targaryens&lt;/a&gt; &lt;/div&gt; &lt;div class=&quot;panels&quot;&gt; &lt;ul id=&quot;starks-panel&quot; class=&quot;panel active&quot;&gt; &lt;li&gt;Eddard&lt;/li&gt; &lt;li&gt;Caitelyn&lt;/li&gt; &lt;li&gt;Robb&lt;/li&gt; &lt;li&gt;Sansa&lt;/li&gt; &lt;li&gt;Brandon&lt;/li&gt; &lt;li&gt;Arya&lt;/li&gt; &lt;li&gt;Rickon&lt;/li&gt; &lt;/ul&gt; &lt;ul id=&quot;lannisters-panel&quot; class=&quot;panel&quot;&gt; &lt;li&gt;Tywin&lt;/li&gt; &lt;li&gt;Cersei&lt;/li&gt; &lt;li&gt;Jamie&lt;/li&gt; &lt;li&gt;Tyrion&lt;/li&gt; &lt;/ul&gt; &lt;ul id=&quot;targaryens-panel&quot; class=&quot;panel&quot;&gt; &lt;li&gt;Viserys&lt;/li&gt; &lt;li&gt;Daenerys&lt;/li&gt; &lt;/ul&gt; &lt;/div&gt; &lt;/div&gt; </code></pre> <p>Nothing unusual in the layout, just a set of tabs and corresponding panels that will be displayed when a tab is selected. Now let’s look at how tab state is managed by altering a tab’s class:</p> <pre><code class="language-css">... .js-tabs .tab { /* inactive styles go here */ } .js-tabs .tab.active { /* active styles go here */ } .js-tabs .panel { /* inactive styles go here */ } .js-tabs .panel.active { /* active styles go here */ } ... </code></pre> <p>Tabs and panels that have an active class will have additional CSS applied to make them stand out. In our case, active tabs will visually connect to their content while inactive tabs remain separate, and active panels will be visible while inactive panels remain hidden.</p> <p>At this point, you’d use your preferred method of working with JavaScript to listen for click events on the tabs, then manipulate the <code>active</code> class, removing it from all tabs and panels and adding it to the newly clicked tab and corresponding panel. This pattern is pretty flexible and has worked well for a long time. We can simplify what’s going on into two distinct parts:</p> <ol> <li>JavaScript binds events that manipulate classes.</li> <li>CSS restyles elements based on those classes.</li> </ol> <h3>State management without JavaScript</h3> <p>Trying to replicate event binding and class manipulation in CSS and HTML alone would be impossible, but if we define the process in broader terms, it becomes:</p> <ol> <li>User input changes the system’s active state.</li> <li>The system is re-rendered when the state is changed.</li> </ol> <p>In our HTML- and CSS-only solution, we’ll use radio buttons to allow the user to manipulate state, and the <code>:checked</code> pseudo-class as the hook to re-render.</p> <p>The solution has its roots in Chris Coyier’s <a href="http://css-tricks.com/the-checkbox-hack/">checkbox hack</a>, which I was introduced to via my colleague Scott O’Hara in his <a href="http://www.scottohara.me/article/css-morph-menu-button.html">morphing menu button</a> demo. In both cases, checkbox inputs are used to maintain two states without JavaScript by styling elements using the <code>:checked</code> pseudo-class. In this case, we’ll be using radio buttons to increase the number of states we can maintain beyond two.</p> <h2>Wait, radio buttons?</h2> <p>Using radio buttons to do something other than collect form submission data may make some of you feel a little uncomfortable, but let’s look at <a href="http://www.w3.org/TR/html5/forms.html#the-input-element">what the W3C says</a> about input use and see if we can ease some concerns:</p> <figure class="quote"> <blockquote>The <code>&lt;input&gt;</code> element represents a typed data field, usually with a form control to <strong>allow the user to edit</strong> the <strong>data</strong>. (emphasis mine)</blockquote> </figure> <p>“Data” is a pretty broad term—it has to be to cover the multitude of types of data that forms collect. We’re <em>allowing the user to edit</em> the <em>state</em> of a part of the page. State is just data about that part of the page at any given time. This may not have been the intended use of <code>&lt;input&gt;</code>, but we’re holding true to the specification.</p> <p>The W3C also states that inputs may be rendered wherever “phrasing content” can be used, which is basically anywhere you could put standalone text. This allows us to use radio buttons outside of a form.</p> <h2>Radio-controlled tabs</h2> <p>So now that we know a little more about whether we <em>can</em> use radio buttons for this purpose, let’s dig into an example and see <em>how</em> they can actually remove or reduce our dependency on JavaScript by modifying the original tabs example.</p> <h3>Add radio buttons representing state</h3> <p>Each radio button will represent one state of the interactive component. In our case, we have three tabs and each tab can be active, so we need three radio buttons, each of which will represent a particular tab being active. By giving the radio buttons the same name, we’ll ensure that only one may be checked at any time. Our JavaScript example had the first tab active initially, so we can add the <code>checked</code> attribute to the radio button representing the first tab, indicating that it is currently active.</p> <p>Because CSS selectors can only style sibling or child selectors based on the state of another element, these radio buttons must come <em>before</em> any content that needs to be visually manipulated. In our case, we’ll put our radio buttons just before the tabs <code>div</code>: </p> <pre><code class="language-markup"> &lt;input class=&quot;state&quot; type=&quot;radio&quot; name=&quot;houses-state&quot; id=&quot;starks&quot; checked /&gt; &lt;input class=&quot;state&quot; type=&quot;radio&quot; name=&quot;houses-state&quot; id=&quot;lannisters&quot; /&gt; &lt;input class=&quot;state&quot; type=&quot;radio&quot; name=&quot;houses-state&quot; id=&quot;targaryens&quot; /&gt; &lt;div class=&quot;tabs&quot;&gt; ... </code></pre> <h3>Replace click and touch areas with labels</h3> <p>Labels naturally respond to click and touch events. We can’t tell them <em>how</em> to react to those events, but the behavior is predictable and we can leverage it. When a label associated with a radio button is clicked or touched, the radio button is checked while all other radio buttons in the same group are unchecked.</p> <p>By setting the <code>for</code> attribute of our labels to the <code>id</code> of a particular radio button, we can place labels wherever we need them while still inheriting the touch and click behavior.</p> <p>Our tabs were represented with anchors in the earlier example. Let’s replace them with labels and add <code>for</code> attributes to wire them up to the correct radio buttons. We can also remove the <code>active</code> class from the tab and panel as the radio buttons will be maintaining state:</p> <pre><code class="language-markup">... &lt;input class=&quot;state&quot; type=&quot;radio&quot; title=&quot;Targaryens&quot; name=&quot;houses-state&quot; id=&quot;targaryens&quot; /&gt; &lt;div class=&quot;tabs&quot;&gt; &lt;label for=&quot;starks&quot; id=&quot;starks-tab&quot; class=&quot;tab&quot;&gt;Starks&lt;/label&gt; &lt;label for=&quot;lannisters&quot; id=&quot;lannisters-tab&quot; class=&quot;tab&quot;&gt;Lannisters&lt;/label&gt; &lt;label for=&quot;targaryens&quot; id=&quot;targaryens-tab&quot; class=&quot;tab&quot;&gt;Targaryens&lt;/label&gt; &lt;/div&gt; &lt;div class=&quot;panels&quot;&gt; ... </code></pre> <h3>Hide radio buttons with CSS</h3> <p>Now that our labels are in place, we can safely hide the radio buttons. We still want to keep the tabs keyboard accessible, so we’ll just move the radio buttons offscreen:</p> <pre><code class="language-css">... .radio-tabs .state { position: absolute; left: -10000px; } ... </code></pre> <h3>Style states based on <code>:checked</code> instead of <code>.active</code></h3> <p>The <code>:checked</code> pseudo-class allows us to apply CSS to a radio button when it is checked. The sibling selector <code>~</code> allows us to style elements that follow an element in the same level. Combined, we can style anything after the radio buttons based on the buttons’ state.</p> <p>The pattern is <code>#radio:checked ~ .something-after-radio</code> or optionally <code>#radio:checked ~ .something-after-radio .something-nested-deeper</code>:</p> <pre><code class="language-css">... .tab { ... } #starks:checked ~ .tabs #starks-tab, #lannisters:checked ~ .tabs #lannisters-tab, #targaryens:checked ~ .tabs #targaryens-tab { ... } .panel { ... } #starks:checked ~ .panels #starks-panel, #lannisters:checked ~ .panels #lannisters-panel, #targaryens:checked ~ .panels #targaryens-panel { ... } ... </code></pre> <p>Now when the tab labels are clicked, the appropriate radio button will be checked, which will style the correct tab and panel as active. The result: </p> <figure class="text full-width"> <p data-height="310" data-theme-id="0" data-slug-hash="domFD" data-default-tab="result" class='codepen'>See the demo: <a href='http://alistapart.com/d/399/2-radio-controlled-tabs-no-aria/'>Show/hide example</a></p> <script async src="//codepen.io/assets/embed/ei.js"></script></figure> <h2>Browser support</h2> <p>The requirements for this technique are pretty low. As long as a browser supports the <code>:checked</code> pseudo-class and <code>~</code> sibling selector, we’re good to go. Firefox, Chrome, and mobile Webkit have always supported these selectors. Safari has had support since version 3, and Opera since version 9. Internet Explorer started supporting the sibling selector in version 7, but didn’t add support for <code>:checked</code> until IE9. Android supports <code>:checked</code> but has a bug which impedes it from being aware of changes to a checked element after page load.</p> <p>That’s decent support, but with a little extra work we can get Android and older IE working as well.</p> <h3>Fixing the Android 2.3 <code>:checked</code> bug</h3> <p>In some versions of Android, <code>:checked</code> won’t update as the state of a radio group changes. Luckily, <a href="http://stackoverflow.com/questions/8320530/webkit-bug-with-hover-and-multiple-adjacent-sibling-selectors/8320736#8320736">there’s a fix for that</a> involving a webkit-only infinite animation on the body, which Tim Pietrusky points out in his <a href="http://timpietrusky.com/advanced-checkbox-hack">advanced checkbox hack</a>: </p> <pre><code class="language-css">... /* Android 2.3 :checked fix */ @keyframes fake { from { opacity: 1; } to { opacity: 1 } } body { animation: fake 1s infinite; } ... </code></pre> <h3>JavaScript shim for old Internet Explorer</h3> <p>If you need to support IE7 and IE8, you can add this shim to the bottom of your page in a script tag: </p> <pre><code class="language-javascript">document.getElementsByTagName('body')[0] .addEventListener('change', function (e) { var radios, i; if (e.target.getAttribute('type') === 'radio') { radios = document.querySelectorAll('input[name=&quot;' + e.target.getAttribute('name') + '&quot;]'); for (i = 0; i &lt; radios.length; i += 1) { radios[ i ].className = radios[ i ].className.replace( /(^|\s)checked(\s|$)/, ' ' ); if (radios[ i ] === e.target) { radios[ i ].className += ' checked'; } } } }); </code></pre> <p>This adds a <code>checked</code> class to the currently checked radio button, allowing you to double up your selectors and keep support. Your selectors would have to be updated to include <code>:checked</code> and <code>.checked</code> versions like this:</p> <pre><code class="language-css">... .tab { ... } #starks:checked ~ .tabs #starks-tab, #starks.checked ~ .tabs #starks-tab, #lannisters:checked ~ .tabs #lannisters-tab, #lannisters.checked ~ .tabs #lannisters-tab, #targaryens:checked ~ .tabs #targaryens-tab, #targaryens.checked ~ .tabs #targaryens-tab { ... } .panel { ... } #starks:checked ~ .panels #starks-panel, #starks.checked ~ .panels #starks-panel, #lannisters:checked ~ .panels #lannisters-panel, #lannisters.checked ~ .panels #lannisters-panel, #targaryens:checked ~ .panels #targaryens-panel, #targaryens.checked ~ .panels #targaryens-panel { ... } ... </code></pre> <p>Using an inline script still saves a potential http request and speeds up interactions on newer browsers. When you choose to drop IE7 and IE8 support, you can drop the shim without changing any of your code.</p> <h2>Maintaining accessibility</h2> <p>While our initial JavaScript tabs exhibited the state management between changing tabs, a more robust example would use progressive enhancement to change three titled lists into tabs. It should also handle adding all the ARIA roles and attributes that screen readers and other assistive technologies use to navigate the contents of a page. A better JavaScript example might look like this:</p> <figure class="text full-width"> <p data-height="310" data-theme-id="0" data-slug-hash="DazeL" data-default-tab="result" class='codepen'>See the demo: <a href='http://alistapart.com/d/399/3-javascript-tabs-aria/'>Show/hide example</a></p> <script async src="//codepen.io/assets/embed/ei.js"></script> </figure> <p>Parts of the HTML are removed and will now be added by additional JavaScript; new HTML has been added and will be hidden by additional JavaScript; and new CSS has been added to manage the pre-enhanced and post-enhanced states. In general, our code has grown by a good amount.</p> <p>In order to support ARIA, particularly managing the <code>aria-selected</code> state, we’re going to have to bring some JavaScript back into our radio-controlled tabs. However, the amount of progressive enhancement we need to do is greatly reduced.</p> <p>If you aren’t familiar with ARIA or are a little rusty, you may wish to refer to the <a href="http://www.w3.org/TR/wai-aria-practices/#tabpanel">ARIA Authoring Practices for tabpanel</a>.</p> <h3>Adding ARIA roles and attributes</h3> <p>First, we’ll add the role of <code>tablist</code> to the containing <code>div</code>.</p> <pre><code class="language-markup">&lt;div class=&quot;radio-tabs&quot; role=&quot;tablist&quot;&gt; &lt;input class=&quot;state&quot; type=&quot;radio&quot; name=&quot;houses-state&quot; id=&quot;starks&quot; checked /&gt; ... </code></pre> <p>Next, we’ll add the role of <code>tab</code> and attribute <code>aria-controls</code> to each radio button. The <code>aria-controls</code> value will be the <code>id</code> of the corresponding panel to show. Additionally, we’ll add titles to each radio button so that screen readers can associate a label with each tab. The checked radio button will also get <code>aria-selected=&quot;true&quot;</code>:</p> <pre><code class="language-markup">&lt;div class=&quot;radio-tabs&quot; role=&quot;tablist&quot;&gt; &lt;input class=&quot;state&quot; type=&quot;radio&quot; title=&quot;Starks&quot; name=&quot;houses-state&quot; id=&quot;starks&quot; role=&quot;tab&quot; aria-controls=&quot;starks-panel&quot; aria-selected=&quot;true&quot;checked /&gt; &lt;input class=&quot;state&quot; type=&quot;radio&quot; title=&quot;Lanisters&quot; name=&quot;houses-state&quot; id=&quot;lannisters&quot; role=&quot;tab&quot; aria-controls=&quot;lannisters-panel&quot; /&gt; &lt;input class=&quot;state&quot; type=&quot;radio&quot; title=&quot;Targaryens&quot; name=&quot;houses-state&quot; id=&quot;targaryens&quot; role=&quot;tab&quot; aria-controls=&quot;targaryens-panel&quot; /&gt; &lt;div class=&quot;tabs&quot;&gt; </code></pre> <p>We’re going to hide the visual tabs from assistive technology because they are shallow interfaces to the real tabs (the radio buttons). We’ll do this by adding <code>aria-hidden=&quot;true&quot;</code> to our <code>.tabs</code> <code>div</code>:</p> <pre><code class="language-markup"> ... &lt;input class=&quot;state&quot; type=&quot;radio&quot; title=&quot;Targaryens&quot; name=&quot;houses-state&quot; id=&quot;targaryens&quot; role=&quot;tab&quot; aria-controls=&quot;targaryens-panel&quot; /&gt; &lt;div class=&quot;tabs&quot; aria-hidden=&quot;true&quot;&gt; &lt;label for=&quot;starks&quot; id=&quot;starks-tab&quot; class=&quot;tab&quot;&gt;Starks&lt;/label&gt; ... </code></pre> <p>The last bit of ARIA support we need to add is on the panels. Each panel will get the role of <code>tabpanel</code> and an attribute of <code>aria-labeledby</code> with a value of the corresponding tab’s id:</p> <pre><code class="language-markup"> ... &lt;div class=&quot;panels&quot;&gt; &lt;ul id=&quot;starks-panel&quot; class=&quot;panel active&quot; role=&quot;tabpanel&quot; aria-labelledby=&quot;starks-tab&quot;&gt; &lt;li&gt;Eddard&lt;/li&gt; &lt;li&gt;Caitelyn&lt;/li&gt; &lt;li&gt;Robb&lt;/li&gt; &lt;li&gt;Sansa&lt;/li&gt; &lt;li&gt;Brandon&lt;/li&gt; &lt;li&gt;Arya&lt;/li&gt; &lt;li&gt;Rickon&lt;/li&gt; &lt;/ul&gt; &lt;ul id=&quot;lannisters-panel&quot; class=&quot;panel&quot; role=&quot;tabpanel&quot; aria-labelledby=&quot;lannisters-tab&quot;&gt; &lt;li&gt;Tywin&lt;/li&gt; &lt;li&gt;Cersei&lt;/li&gt; &lt;li&gt;Jamie&lt;/li&gt; &lt;li&gt;Tyrion&lt;/li&gt; &lt;/ul&gt; &lt;ul id=&quot;targaryens-panel&quot; class=&quot;panel&quot; role=&quot;tabpanel&quot; aria-labelledby=&quot;targaryens-tab&quot;&gt; &lt;li&gt;Viserys&lt;/li&gt; &lt;li&gt;Daenerys&lt;/li&gt; &lt;/ul&gt; &lt;/div&gt; ... </code></pre> <p>All we need to do with JavaScript is to set the <code>aria-selected</code> value as the radio buttons change:</p> <pre><code class="language-js">$('.state').change(function () { $(this).parent().find('.state').each(function () { if (this.checked) { $(this).attr('aria-selected', 'true'); } else { $(this).removeAttr('aria-selected'); } }); }); </code></pre> <p>This also gives an alternate hook for IE7 and IE8 support. Both browsers support attribute selectors, so you could update the CSS to use <code>[aria-selected]</code> instead of <code>.checked</code> and remove the support shim.</p> <pre><code class="language-css">... #starks[aria-selected] ~ .tabs #starks-tab, #lannisters[aria-selected] ~ .tabs #lannisters-tab, #targaryens[aria-selected] ~ .tabs #targaryens-tab, #starks:checked ~ .tabs #starks-tab, #lannisters:checked ~ .tabs #lannisters-tab, #targaryens:checked ~ .tabs #targaryens-tab { /* active tab, now with IE7 and IE8 support! */ } ... </code></pre> <p>The result is full ARIA support with minimal JavaScript—and you still get the benefit of tabs that can be used as soon as the browser paints them.</p> <figure class="text full-width"> <p data-height="310" data-theme-id="0" data-slug-hash="gbLev" data-default-tab="result" class='codepen'>See the demo: <a href='http://alistapart.com/d/399/4-radio-controlled-tabs-aria/'>Show/hide example</a></p> <script async src="//codepen.io/assets/embed/ei.js"></script> </figure> <p>That’s it. Note that because the underlying HTML is available from the start, unlike the initial JavaScript example, we didn’t have to manipulate or create any additional HTML. In fact, aside from adding ARIA roles and parameters, we didn’t have to do much at all.</p> <h2>Limitations to keep in mind</h2> <p>Like most techniques, this one has a few limitations. The first and most important is that the state of these interfaces is transient. When you refresh the page, these interfaces will revert to their initial state. This works well for some patterns, like modals and offscreen menus, and less well for others. If you need persistence in your interface’s state, it is still better to use links, form submission, or AJAX requests to make sure the server can keep track of the state between visits or page loads.</p> <p>The second limitation is that there is a scope gap in what can be styled using this technique. Since you cannot place radio buttons before the <code>&lt;body&gt;</code> or <code>&lt;html&gt;</code> elements, and you can only style elements following radio buttons, you cannot affect either element with this technique.</p> <p>The third limitation is that you can only apply this technique to interfaces that are triggered via click, tap, or keyboard input. You can use progressive enhancement to listen to more complex interactions like scrolling, swipes, double-tap, or multitouch, but if your interfaces rely on these events alone, standard progressive enhancement techniques may be better.</p> <p>The final limitation involves how radio groups interact with the tab flow of the document. If you noticed in the tab example, hitting tab brings you to the tab group, but hitting tab again leaves the group. This is fine for tabs, and is the expected behavior for ARIA tablists, but if you want to use this technique for something like an open and close button, you’ll want to be able to have both buttons in the tab flow of the page independently based on the button location. This can be fixed through a bit of JavaScript in four steps:</p> <ol> <li>Set the radio buttons and labels to <code>display: none</code> to take them out of the tab flow and visibility of the page.</li> <li>Use JavaScript to add <code>buttons</code> after each <code>label</code>.</li> <li>Style the buttons just like the labels.</li> <li>Listen for clicks on the <code>button</code> and trigger clicks on their neighboring <code>label</code>.</li> </ol> <p>Even using this process, it is highly recommended that you use a standard progressive enhancement technique to make sure users without JavaScript who interact with your interfaces via keyboard don’t get confused with the radio buttons. I recommend the following JavaScript in the head of your document:</p> <pre><code class="language-markup">&lt;script&gt;document.documentElement.className+=&quot; js&quot;;&lt;/script&gt; </code></pre> <p>Before any content renders, this will add the <code>js</code> class to your <code>&lt;html&gt;</code> element, allowing you to style content depending on whether or not JavaScript is turned on. Your CSS would then look something like this:</p> <pre><code class="language-css">.thing { /* base styles - when no JavaScript is present hide radio button labels, show hidden content, etc. */ } .js .thing { /* style when JavaScript is present hide content, show labels, etc. */ } </code></pre> <p>Here’s an example of an offscreen menu implemented using the above process. If JavaScript is disabled, the menu renders open at all times with no overlay:</p> <figure class="text full-width"> <p data-height="388" data-theme-id="0" data-slug-hash="wsbfC" data-default-tab="result" class='codepen'>See the demo: <a href='http://alistapart.com/d/399/5-and-7-radio-controlled-offscreen-menu/'>Show/hide example</a></p> <script async src="//codepen.io/assets/embed/ei.js"></script> </figure> <h2>Implementing other content-on-demand patterns</h2> <p>Let’s take a quick look at how you might create some common user interfaces using this technique. Keep in mind that a robust implementation would address accessibility through ARIA roles and attributes.</p> <h3>Modal windows with overlays</h3> <ul> <li>Two radio buttons representing modal visibility</li> <li>One or more labels for modal-open which can look like anything</li> <li>A label for modal-close styled to look like a semi-transparent overlay</li> <li>A label for modal-close styled to look like a close button</li> </ul> <figure class="text full-width"> <p data-height="388" data-theme-id="0" data-slug-hash="npsCd" data-default-tab="result" class='codepen'>See the demo: <a href='http://alistapart.com/d/399/6-radio-controlled-modal-window/'>Show/hide example</a></p> <script async src="//codepen.io/assets/embed/ei.js"></script> </figure> <h3>Off-screen menu</h3> <ul> <li>Two radio buttons representing menu visibility</li> <li>A label for menu-open styled to look like a menu button</li> <li>A label for menu-close styled to look like a semi-transparent overlay</li> <li>A label for menu-close styled to look like a close button</li> </ul> <figure class="text full-width"> <p data-height="388" data-theme-id="0" data-slug-hash="wsbfC" data-default-tab="result" class='codepen'>See the demo: <a href='http://alistapart.com/d/399/5-and-7-radio-controlled-offscreen-menu/'>Show/hide example</a></p> <script async src="//codepen.io/assets/embed/ei.js"></script> </figure> <h3>Switching layout on demand</h3> <ul> <li>Radio buttons representing each layout</li> <li>Labels for each radio button styled like buttons</li> </ul> <figure class="text full-width"> <p data-height="490" data-theme-id="0" data-slug-hash="gbehv" data-default-tab="result" class='codepen'>See the demo: <a href='http://alistapart.com/d/399/8-radio-controlled-layout-manipulation/'>Show/hide example</a></p> <script async src="//codepen.io/assets/embed/ei.js"></script> </figure> <h3>Switching style on demand</h3> <ul> <li>Radio buttons representing each style</li> <li>Labels for each radio button styled like buttons</li> </ul> <figure class="text full-width"> <p data-height="490" data-theme-id="0" data-slug-hash="ncAfK" data-default-tab="result" class='codepen'>See the demo: <a href='http://alistapart.com/d/399/9-radio-controlled-style-manipulation/'>Show/hide example</a></p> <script async src="//codepen.io/assets/embed/ei.js"></script> </figure> <h3>Content carousels</h3> <ul> <li>X radio buttons, one for each panel, representing the active panel</li> <li>Labels for each panel styled to look like next/previous/page controls</li> </ul> <figure class="text full-width"> <p data-height="350" data-theme-id="0" data-slug-hash="ioCaA" data-default-tab="result" class='codepen'>See the demo: <a href='http://alistapart.com/d/399/10-radio-controlled-carousel/'>Show/hide example</a></p> <script async src="//codepen.io/assets/embed/ei.js"></script> </figure> <h3>Other touch- or click-based interfaces</h3> <p>As long as the interaction does not depend on adding new content to the page or styling the <code>&lt;body&gt;</code> element, you should be able to use this technique to accomplish some very JavaScript-like interactions.</p> <p>Occasionally you may want to manage multiple overlapping states in the same system—say the color and size of a font. In these situations, it may be easier to maintain multiple sets of radio buttons to manage each state.</p> <p>It is also <em>highly</em> recommended that you use <code>autocomplete=&quot;off&quot;</code> with your radio buttons to avoid conflict with browser form autofill switching state on your users.</p> <h2>Radio-control the web?</h2> <p>Is your project right for this technique? Ask yourself the following questions:</p> <ol> <li>Am I using complex JavaScript on my page/site that can’t be handled by this technique?</li> <li>Do I need to support Internet Explorer 6 or other legacy browsers?</li> </ol> <p>If the answer to either of those question is “yes,” you probably shouldn’t try to integrate radio control into your project. Otherwise, you may wish to consider it as part of a robust progressive enhancement technique.</p> <p>Most of the time, you’ll be able to shave some bytes off of your JavaScript files and CSS. Occasionally, you’ll even be able to remove Javascript completely. Either way, you’ll gain the appearance of speed—and build a more enjoyable experience for your users.</p><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/2wXn4oMCOXo" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)
29. Jul 2014
Gardens, Not Graves
<p>The stream—that great glut of ideas, opinions, updates, and ephemera that pours through us every day—is the dominant way we organize content. It makes sense; the stream’s popularity springs from the days of the early social web, when a huge number of users posted all types of content on unpredictable schedules. The simplest way to show updates to new readers focused on reverse chronology and small, discrete chunks, as sorting by newness called for content quick to both produce and digest. This approach saw wide adoption in blogs, social networks, notification systems, etc., and ever since we’ve flitted from one stream to another like sugar-starved hummingbirds.</p> <p>Problem is, the stream’s emphasis on the new above all else imposes a short lifespan on content. Like papers piled on your desk, the stream makes it easy to find the last thing you’ve added, while anything older than a day effectively disappears. Solely relying on reverse-chronology turns our websites into graveyards, where things pile up atop each other until they fossilize. We need to start treating our websites as gardens, as places worthy of cultivation and renewal, where new things can bloom from the old.</p> <h2>The stream, in print</h2> <p>The stream’s focus on the <em>now</em> isn’t novel, anyway. Old-school modes of publishing like newspapers and magazines shared a similar disposability: periodic updates went out to subscribers and were then thrown away. No one was expected to hang onto them for long.</p> <p>Over the centuries with print, however, we came up with a number of ways to preserve and showcase older material. Newspapers put out <a href="http://en.wikipedia.org/wiki/New_York_Times_Index">annual indexes</a> cataloguing everything they print ordered by subject and frequency. Magazines get rebound into <a href="http://us.macmillan.com/theparisreviewinterviewsboxedsetiiv/TheParisReview">larger, more substantial anthologies</a>. Publishers frequently reach into their back catalogue and reprint books with new forewords or even chapters. These acts serve two purposes: to maintain widespread and cheap access to material that has gone out of print, and to ensure that material is still relevant and useful today.</p> <p>But we haven’t yet developed patterns for slowing down on the web. In some ways, access is simpler. As long as the servers stay up, content remains a link away from interested readers. But that same ease of access makes the problem of outdated or redundant content more pronounced. Someone looking at an old magazine article also holds the entire issue it was printed with. With an online article, someone can land directly on the piece with little indication of who it’s by, what it’s for, and whether it’s gone out of date. Providing sufficient context for content already out there is a vital factor to consider and design for.</p> <p>You don’t need to be a writer to help fix this. Solutions can come from many fields, from targeted writing and design tweaks to more overarching changes in content strategy and information architecture.</p> <p>Your own websites are good places to start. Here are some high-level guidelines, ordered by the amount of effort they’ll take. Your site will demand its own unique set of approaches, though, so recombine and reinvent as needed.</p> <h2>Reframe</h2> <p><em>Emma is a travel photographer. She keeps a blog, and many years ago she wrote a series about visiting Tibet. Back then, she was required to travel with a guided tour. That’s no longer the case, as visitors only need to obtain a permit.</em></p> <p>The most straightforward thing to do is to look through past content and identify what’s outdated: pieces you’ve written, projects you worked on, things you like. The goal is triage: sorting things into what needs attention and what’s still fine.</p> <p>Once you’ve done that, find a way to signal their outdated status. Perhaps you have a design template for “archived” content that has a different background color, more strongly emphasizes when it was written, or <a href="http://24ways.org/2008/geotag-everywhere-with-fire-eagle/">adds a sentence or two at the top of your content that explains why it’s outdated</a>. If entire groups of content need mothballing, see whether it makes sense to pull them into separate areas. (Over time, you may have to overhaul the way your entire site is organized—a complicated task we’ll address below.)</p> <p><em>Emma adds an <code>&lt;outdated&gt;</code> tag to her posts about her guided tour and configures the site’s template to show a small yellow notification at the top telling visitors that her information is from 2008 and may be irrelevant. She also adds a link on each post pointing to a site that explains the new visa process and ways to obtain Tibetan permits.</em></p> <p>On the flip side, separate the pieces that you’re particularly proud of. Your “best-of” material is probably getting scattered by the reverse-chronology organization of your website, so list all of them in a prominent place for people visiting for the first time.</p> <h2>Recontextualize</h2> <p>I hope that was easy! The next step is to look for old content you feel differently about today.</p> <p><em>When Emma first started traveling, she hated to fly. She hated waiting in line, hated sitting in cramped seats, and especially hated the food. There are many early blog posts venting about this.</em></p> <p>Maybe what you wrote needs additional nuance or more details. Or maybe you’ve changed since then. Explain why—lead readers down the learning path you took. It’s a chance for you to reflect on the delta.</p> <p><em>Now that she’s gotten more busy and has to frequently make back-to-back trips for clients, she finds that planes are the best time for her to edit photos from the last trip, catch up on email, and have some space for reflection. So she writes about how she fills up her flying time now, leaving more time when she’s at her destination to shoot and relax.</em></p> <p>Or expand on earlier ideas. What started as a rambling post you began at midnight can turn into a series or an entire side project. Or, if something you wrote provokes a big response online, you could gather those links at the bottom of your piece. It’s a service to your new readers to collect connected pieces together, so that they don’t have to hunt around to find them all.</p> <h2>Revise and reorganize</h2> <p>Hopefully that takes care of most of your problematic content. But for content so dire you’re embarrassed to even look at it, much less having other people reading it, consider more extreme measures: the act of culling, revising, and rewriting.</p> <p>Looking back: maybe you were <em>completely wrong</em> about something, and you would now argue the opposite. Rewrite it! Or you’re shocked to find code you wrote one rushed Friday afternoon—well, set aside some time to start from the ground up and do it right.</p> <p><em>Emma started her website years ago as a typical reverse-chron blog, but has started to work on a redesign based around the concepts of LOCATIONS and TRIPS. Appearing as separate items in the navigation, they act as different ways for readers to approach and make sense of her work. The locations present an at-a-glance view of where she’s been and how well-traveled she is. The trips (labeled Antarctica: November 2012, Bangkok: Fall 2013, Ghana: early 2014, etc.) retain the advantages of reverse-chronology by giving people updates on what she’s done recently, but these names are more flexible and easier to explain than dates and timestamps on their own. Someone landing directly on a post from a trip two years ago can easily get to the other posts from that trip, but they would be lost if the entries were only timestamped.</em></p> <p>If the original structure no longer matches the reality of what’s there, it’s also the best case for redesigning and reorganizing your website. Now is the time to consider your content as a whole. Think about how you’d explain your website to someone you’re having lunch with. Are you a writer, photographer, artist, musician, cook? What kind? What sorts of topics does your site talk about? What do you want people to see first? How do they go deeper on the things they find interesting? This gets rather existential, but it’s important to ask yourself.</p> <h2>Remove</h2> <p>If it’s really, truly <em>foul</em>, you can throw it out. (It’s okay. You officially have permission.) Not everything needs to live online forever, but throwing things out doesn’t have to be your first option when you get embarrassed by the past.</p> <p>Deploying the internet equivalent of space lasers does, I must stress, come with some responsibility. Other sites can be affected by changes in your links:</p> <ul> <li>If you’re consolidating or moving content, it’s important to set up redirects for affected URLs to the new pages.</li> <li>If someone links to a tutorial you wrote, it may be better to archive it and link to more updated information, rather than outright deleting it.</li> </ul> <h2>Conclusion</h2> <p>Everything we’ve done so far applies to more than personal websites, of course. Where else?</p> <p>Businesses have to maintain scores of announcements, documentation, and customer support. Much of it is subject to greatly change over time, and many need help looking at things from a user’s perspective. Content strategy has been leading the charge on this, from <a href="http://alistapart.com/article/content-modelling-a-master-skill">developing content models and relationships</a>, to <a href="http://alistapart.com/article/dont-poke-the-bear-creating-content-for-sensitive-situations">communicating with empathy in touchy situations</a>, to <a href="http://alistapart.com/column/responsive-design-wont-fix-your-content-problem">working out content standards</a>.</p> <p>Newspapers and magazines relentlessly publish new pieces and sweep the old away from public view. Are there opportunities to <a href="http://nprchives.tumblr.com">highlight</a> <a href="http://livelymorgue.tumblr.com">material</a> from their archives? What about content that can always <a href="http://www.theparisreview.org/interviews">stay</a> <a href="http://www.lettersofnote.com">interesting</a>? How can selections be best brought together to <a href="http://aworkinglibrary.com/writing/some-thoughts-on-the-anthology">generate new connections and meaning</a>?</p> <p>Museums and libraries, as they step into their digital shoes, will have to think about building places online for histories and archives for the long term. Are there <a href="http://snarkmarket.com/blog/snarkives/books_writing_such/paleoblogging">new roles and practices</a> that bridge the old world with the networked, digital one? How do they preserve <a href="http://www.aaronland.info/weblog/2013/07/25/verb">entirely new categories of things</a> for the public?</p> <p>No one has all the answers. But these are questions that come from leaving the stream and approaching content from the long view. These are problems that the shapers and caretakers of the web are uniquely positioned to think about and solve.</p> <p>As a community, we take pride in being makers and craftsmen. But for years, we’ve neglected the disciplines of stewardship—the invisible and unglamorous work of collecting, restoring, safekeeping, and preservation. Maybe the answer isn’t to post more, to add more and more streams. Let’s return to our existing content and make it more durable and useful.</p> <p>You don’t even have to pick up a shovel.</p><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/brzpjVbp608" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)
24. Jul 2014
Matt Griffin on How We Work: Being Profitable
<p>When I recently read <a href="http://alistapart.com/article/living-up-to-your-business-ideals">Geoff Dimasi’s excellent article</a> I thought: this is great—values-based business decisions in an efficient fashion. But I had another thought, too: where, in that equation, is the money?</p> <p>If I’m honest with myself, I’ve always felt that on some level it’s wrong to be profitable. That making money on top of your costs somehow equates to bilking your clients. I know, awesome trait for a business owner, right?</p> <p>Because here’s the thing: a business can’t last forever skating on the edge of viability. And that’s what not being profitable means. This is a lesson I had to learn with Bearded the hard way. Several times. Shall we have a little bit of story time? “Yes, Matt Griffin,” you say, “let’s!” Well OK, then.</p> <p>At Bearded, our philosophy from the beginning was to focus on doing great web work for clients we believed in. The hope was that all the sweat and care we put into those projects and relationships would show, and that profit would naturally follow quality. For four years we worked our tails off on project after project, and as we did so, we lived pretty much hand-to-mouth. On several occasions we were within weeks and a couple of thousand bucks from going out of business. I would wake up in the night in a panic, and start calculating when bills went out and checks would come in, down to the day. I loved the work and clients, but the other parts of the business were frankly pretty miserable.</p> <p>Then one day, I went to the other partners at Bearded and told them I’d had it. In the immortal words of <cite>Lethal Weapon’s</cite> Sergeant Murtaugh, I was getting too old for this shit. I told them I could put in one more year, and if we weren’t profitable by the end of it I was out, and we should all go get well-paid jobs somewhere else. They agreed.</p> <p>That decision lit a fire under us to pay attention to the money side of things, change our process, and effectively do whatever it took to save the best jobs we’ve ever had. By the end of the next quarter, we had three months of overhead in the bank and were on our way to the first profitable year of our business, with a 50 percent growth in revenue over the previous year and raises for everyone. All without compromising our values or changing the kinds of projects we were doing.</p> <p>This did not happen on its own. It happened because we started designing the money side of our business the way we design everything else we care about. We stopped neglecting our business, and started taking care.</p> <p>“So specifically,” you ask, “what did you do to turn things around? I am interested in these things!” you say. Very good, then, let’s take a look.</p> <h2>Now it’s time for a breakdown</h2> <p>Besides my arguably weird natural aversion to profit, there are plenty of other motivations not to examine the books. Perhaps math and numbers are scary to you. Maybe finances just seem really boring (they’re no CSS pseudo-selectors, amiright?). Or maybe it’s that when we don’t pay attention to a thing, it’s easier to pretend that it’s not there. But in most cases, the unknown is far scarier than fact.</p> <p>When it comes down to it, your businesses finances are made up of two things: money in and money out. Money in is revenue. Money out is overhead. And the difference? That’s profit (or lack thereof). Let’s take a look at the two major components of that equation.</p> <h3>Overhead Overheels</h3> <p>First let’s roll up our sleeves and calculate your overhead. Overhead includes loads of stuff like:</p> <ul> <li>Staff salaries</li> <li>Health insurance</li> <li>Rent</li> <li>Utilities</li> <li>Equipment costs</li> <li>Office supplies</li> <li>Snacks, meals, and beverages</li> <li>Service fees (hosting, web services, etc.)</li> </ul> <p>In other words: it’s all the money you pay out to do your work. You can assess these items over whatever period makes sense to you: daily, weekly, annually, or even by project.</p> <p>For Bearded, we asked our bookkeeper to generate a monthly budget in Quicken based on an average of the last six months of actual costs that we have, broken down by type. This was super helpful in seeing where our money goes. Not surprisingly, most of it was paying staff and covering their benefits.</p> <p>Once we had that number it was easy to derive whatever variations were useful to us. The most commonly used number in our arsenal is weekly overhead. Knowing that variable is very helpful for us to know how much we cost every week, and how much average revenue needs to come in each week before we break even.</p> <h3>Everything old is revenue again</h3> <p>So how do we bring in that money? You may be using pricing structures that are fixed-fee, hourly, weekly, monthly, or value-based. But at the end of the day you can always divide the revenue gained by the time you spent, and arrive at a period-based rate for the project (whether monthly, weekly, hourly, or project length). This number is crucial in determining profitability, because it lines up so well with the overhead number we already determined.</p> <p>Remember: money in minus money out is profit. And that’s the number we need to get to a point where it safely sustains the business.</p> <p>If we wanted to express this idea mathematically, it might look something like this:</p> <pre>(Rate × Time spent × Number of People) - (Salaries + Expenses) = Profit</pre> <p>Here’s an example:</p> <p>Let’s say that our ten-person business costs $25,000 a week to run. That means each person, on average, needs to do work that earns $2,500 per week for us to break even. If our hourly rate is $100 per hour, that means each person needs to bill 25 hours per week just to maintain the business. If everyone works 30 billable hours per week, the business brings in $30,000—a profit of 20 percent of that week’s overhead. In other words, it takes five good weeks to get one extra week of overhead in the bank.</p> <p>That’s not a super great system, is it? How many quality billable hours can a person really do in a week—30? Maybe 36? And is it likely that all ten people will be able to do that many billable hours each week? After all, there are plenty of non-billable tasks involved in running a business. Not only that, but there will be dry periods in the work cycle—gaps between projects, not to mention vacations! We won’t all be able to work full time every week of the year. Seems like this particular scenario has us pretty well breaking even, if we’re lucky.</p> <p>So what can we do to get the balance a little more sustainable? Well, everyone could just work more hours. Doing 60-hour weeks every week would certainly take care of things. But how long can real human beings keep that up?</p> <p>We can lower our overhead by cutting costs. But seeing as most of our costs are paying salaries, that seems like an unlikely place to make a big impact. To truly be more profitable, the business needs to bring in more revenue per hour of effort expended by staff. That means higher rates. Let’s look at a new example:</p> <p>Our ten-person business still costs $25,000 a week. Our break-even is still at $2,500 per week per person. Now let’s set our hourly rate at $150 per hour. This means that each person has to work just under 17 billable hours per week for the business to break even. If everyone bills 30 hours in a week, the business will now bring in $45,000—or $20,000 in profit. That’s 80 percent of a week’s overhead.</p> <p>That scenario seems a whole lot more sustainable—a good week now pays for itself, and brings in 80 percent of the next week’s overhead. With that kind of ratio we could, like a hungry bear before hibernation, start saving up to protect ourselves from less prosperous times in the future.</p> <p>Nature metaphors aside, once we know how these parts work, we can figure out any one component by setting the others and running the numbers. In other words, we don’t just have to see how a specific hourly rate changes profit. We can go the other way, too.</p> <h2>Working for a living or living to work</h2> <p>One way to determine your system is to start with desired salaries and reasonable work hours for your culture, and work backwards to your hourly rate. Then you can start thinking about pricing systems (yes, even fixed price or value-based systems) that let you achieve that effective rate.</p> <p>Maybe time is the most important factor for you. How much can everyone work? How much does everyone want to work? How much must you then charge for that time to end up with salaries you can be content with?</p> <p>This is, in part, a lifestyle question. At Bearded, we sat down not too long ago and did an exercise adapted from an IA exercise we learned from <a href="http://kevinmhoffman.com/">Kevin M. Hoffman</a>. We all contributed potential qualities that were important to our business—things like “high quality of life,” “high quality of work,” “profitable,” “flexible,” “clients who do good in the world,” “efficient,” and “collaborative.” As a group we ordered those qualities by importance, and decided we’d let those priorities guide us for the next year, at which point we’d reassess.</p> <p>That exercise really helped us make decisions about things like what rate we needed to charge, how many hours a week we wanted to work, as well as more squishy topics like what kinds of clients we wanted to work for and what kind of work we wanted to do. Though finances can seem like purely quantitative math, that sort of qualitative exercise ended up significantly informing how we plugged numbers into the profit equation.</p> <h2>Pricing: Where the rubber meets the road</h2> <p>Figuring out the basics of overhead, revenue, and profit, is instrumental in giving you an understanding of the mechanics of your business. It lets you plan knowledgeably for your future. It allows you to make plans and set goals for the growth and maintenance of your business.</p> <p>But once you know what you want to charge there’s another question—how do you charge it?</p> <p>There are plenty of different pricing methods out there (time unit-based, deliverable-based, time period-based, value-based, and combinations of these). They all have their own potential pros and cons for profitability. They also create different motivations for clients and vendors, which in turn greatly affect your working process, day-to-day interactions, and project outcomes.</p> <p>But that, my friends, is a topic for our next column. Stay tuned for part two of my little series on the money side of running a web business: pricing!</p><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/xNL_biRVME4" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)
23. Jul 2014
Ten CSS One-Liners to Replace Native Apps
<p><i>Håkon Wium Lie is the father of CSS, the CTO of Opera, and a pioneer advocate for web standards. Earlier this year, we published his blog post, “<a href="http://alistapart.com/blog/post/css-regions-considered-harmful">CSS Regions Considered Harmful</a>.” When Håkon speaks, whether we always agree or not, we listen. Today, Håkon introduces CSS Figures and argues their case.</i></p> <p>Tablets and mobile devices require us to rethink web design. Moused scrollbars will be replaced by paged gestures, and figures will float in multi-column layouts. Can this be expressed in CSS?</p> <p>Paged designs, floating figures, and multi-column layout are widely used on mobile devices today. For some examples, see <a href="https://flipboard.com/">Flipboard</a>, the <a href="http://www.ted.com/talks/mike_matas">Our Choice ebook</a>, or <a href="https://www.facebook.com/paper">Facebook Paper</a>. These are all native apps. If we want the web to win on these devices (we do), it&#8217;s vital that designers can build these kinds of presentations using web standards. If web standards cannot express this, authors will be justified in making native apps. </p> <p>Over the past years, I&#8217;ve been editing two specifications that, when combined, provide this kind of functionality: <a href="http://www.w3.org/TR/css3-multicol/">CSS Multi-column Layout</a> and <a href="http://figures.spec.whatwg.org/">CSS Figures</a>. I believe they are important to make sure the web remains a compelling environment for content providers. </p> <p>In this article, I will demonstrate how simple it is to write CSS code with these specs. I will do so through 10 one-liners. Real stylesheets will be slightly longer, but still compact, readable, and reusable. Here are some screenshots to give you a visual indication of what we are aiming for:</p><figure><img src="http://alistapart.com/d/misc-images/Blog_images/CSS_Figures/koster.jpg" alt="Three views of a web page demonstrating different numbers of columns for different window sizes"></figure> <h2>Building a page</h2> <p>The starting point for my code examples is an article with a title, text, and some images. In a traditional browser, the article will be shown in one column, with a scrollbar on the right. Using CSS Multi-column Layout, you can give the article two columns instead of one:</p> <pre class="language-css"> article { columns: 2 } </pre> <p>That&#8217;s a powerful one-liner, but we can do better; we can make the number of columns depend on the available space, so that a narrow screen will have one column, a wider screen will have two columns, etc. This is all it takes to specify that the optimal line length is 15em and for the number of columns to be calculated accordingly:</p> <pre class="language-css"> article { columns: 15em } </pre> <p>To me, this is where CSS code morphs into poetry: one succinct line of code scales from the narrowest phone to the widest TV, from the small print to text for the visually impaired. There is no JavaScript, media queries, or expensive authoring tool involved. There is simply one highly responsive line of code. That line is used to great effect to produce the screenshots above. And it works in current browsers (which is not yet the case for the following examples).</p> <p>The screenshots above show paged presentations, as opposed to scrolled presentations. This is easily expressed with:</p> <pre class="language-css"> article { overflow: paged-x } </pre> <p>The above code says that the article should be laid out as pages, stacked along the x-axis (which, in English, is toward the right). Browsers that support this feature must provide an interface for navigating in these pages. For example, the user may reach the next page by making a swiping gesture or tilting the device. A visual indication of which page you are reading may also be provided, just like scrollbars provide a visual indication in scrolled environments. On a tablet or mobile phone, swiping to the next page or document will be easier than scrolling.</p> <h2>Images</h2> <p>Adding images to the article creates some challenges. Lines of text can easily be poured into several columns, but if figures are interspersed with text, the result will be uneven; because images are unbreakable, they will cause unused whitespace if they appear at a column break. To avoid this, traditional paper-based layouts place images at the top or bottom of columns, thereby allowing other text to fill the whitespace. This can naturally be expressed in CSS by adding <code>top</code> and <code>bottom</code> to the <code>float</code> property. For example:</p> <pre class="language-css"> img { float: bottom } </pre> <p>The bluish harbor images in the screenshots above have been floated to the bottom of the page with this one-liner. CSS is used to express something that HTML cannot say; it is impossible to know how much textual content will fit on a screen in advance of formatting. Therefore, an author cannot know where to insert the image in the source code in order for it to appear at the bottom of the column. Being able to float figures to the <code>top</code> and <code>bottom</code> (in addition to the already existing <code>left</code> and <code>right</code>) is a natural extension to the <code>float</code> property.</p> <h2>Spanning columns</h2> <p>Another trick from traditional layout is for figures to span several columns. Consider this newspaper clipping:</p><figure> <img src="http://alistapart.com/d/misc-images/Blog_images/CSS_Figures/newspaper.jpg" alt="A newspaper clipping showing text in four columns and images in the lower-left, lower-right and upper-right corners"> <figcaption>Used with permission from the Bristol Observer</figcaption> </figure> <p>In the newspaper article, the image on the left spans two columns and is floated to the bottom of the columns. The code to achieve this in CSS is simple:</p> <pre class="language-css"> figure { float: bottom; column-span: 2 } </pre> <p>HTML5&#8217;s <code>figure</code> element is perfect for holding both an image and the caption underneath it:</p> <pre class="language-html"> &lt;figure&gt; &lt;img src=cats.jpg&gt; &lt;figcaption&gt;Isabel loves the fluffy felines&lt;/figcaption&gt; &lt;/figure&gt; </pre> <p>The newspaper article also has a figure that spans three columns, and is floated to the top right corner. In a previous version of the CSS Figures specification, this was achieved by setting <code>float: top-corner</code>. However, after discussions with implementers, it became clear that they were able to float content to more places than just corners. Therefore, CSS Figures introduces new properties to express that content should be <a href="http://figures.spec.whatwg.org/#deferring-page-floats">deferred</a> to a later column, page, or line. </p> <h2>Deferring figures</h2> <p>To represent that the cat picture in the newspaper clipping should be placed at the top of the last column, spanning three columns, this code can be used:</p> <pre class="language-css"> figure { float: top; float-defer-column: last; column-span: 3 } </pre> <p>This code is slightly less intuitive (compared to the abandoned <code>top-corner</code> keyword), but it opens up a range of options. For example, you can float an element to the second column:</p> <pre class="language-css"> .byline { float: top; float-defer-column: 1 } </pre> <p>The above code defers the byline, “By Collette Jackson”, by one. That is, if the byline would naturally appear in the first column, it will instead appear in the second column (as is the case in the newspaper clipping). For this to work with HTML code, it is necessary for the byline to appear early in the article. For example, like this:</p> <pre class="language-html"> &lt;article&gt; &lt;h1>New rescue center pampers Persians&lt;/h1> &lt;p class=byline>By Collette Jackson&lt;/p> ... &lt;/article&gt; </pre> <h2>Deferring ads</h2> <p>Advertisements are another type of content which is best declared early in the source code and deferred for later presentation. Here&#8217;s some sample HTML code:</p> <pre class="language-html"> &lt;article&gt; &lt;aside id=ad1 src=ad1.png> &lt;aside id=ad2 src=ad2.png> &lt;h1>New rescue center pampers Persians&lt;/h1> &lt;/article&gt; </pre> <p>And here is the corresponding CSS code, with a one-liner for each advertisement:</p> <pre class="language-css"> #ad1 { float-defer-page: 1 } #ad2 { float-defer-page: 3 } </pre> <p>As a result of this code, the ads would appear on page two and four. Again, this is impossible to achieve by placing ads inside the text flow, because page breaks will appear in different places on different devices. </p> <p>I think both readers and advertisers will like a more page-oriented web. In paper magazines, ads rarely bother anyone. Likewise, I think ads will be less intrusive in paged, rather than scrolled, media.</p> <h2>Deferring pull quotes</h2> <p>The final example of content that can be deferred is pull quotes. A pull quote is a quote lifted from the article, and presented in larger type at some predetermined place on the page. In this example, the pull quote is shown midway down the second column:</p><figure><img src="http://alistapart.com/d/misc-images/Blog_images/CSS_Figures/pullquote.jpg" alt="A picture of a pull quote in a print newspaper"></figure><p>Here&#8217;s the CSS code to express this in CSS:</p> <pre class="language-css"> .pullquote#first { float-defer-line: 50% } </pre> <p>Other types of content can also be positioned by deferring lines. For example, a photograph may be put above the fold of a newspaper by deferring a number of lines. This will also work on the foldable screens of the future.</p> <p>Pull quotes, however, are an interesting use case that deserve some discussion. A pull quote has two functions. First, it presents to the reader an interesting line of text to gain attention. Second, the presentation of the article becomes visually more varied when the body text is broken up by the larger type. Typically, you want one pull quote on every page. On paper, where you know how many pages an article will take up, it is easy to supply the right number of pull quotes. On the web, however, content will be reformatted for all sorts of screens; some readers will see many small pages, other will see fewer larger pages. To ensure that each page has a pull quote, authors must provide a generous supply of pull quotes. Rather than showing the extraneous quotes at the end of the article (which would be a web browser&#8217;s instinct), they should be discarded; the content will anyway appear in the main article. This can be achieved with a one-liner:</p> <pre class="language-css"> .pullquote { float-policy: drop-tail } </pre> <p>In prose, the code reads: if the pull quote is at the tail-end of the article, it should not be displayed. The same one-liner would be used to extraneous images at the end of the article; authors will often want to have one image per page, but not more than one.</p> <h2>Exercises</h2> <p>The studious reader may want to consult the <a href="http://www.w3.org/TR/css3-multicol/">CSS Multi-column Layout</a> and <a href="http://figures.spec.whatwg.org/">CSS Figures</a> specifications. They have more use cases and more knobs to allow designers to describe the ideal presentation of figures on the web.</p> <p>The easiest way to play with CSS Figures is to download <a href="http://www.opera.com/download/guide/?ver=12.16">Opera 12.16</a> and point it to <a href="http://www.wiumlie.no/2014/css-figures/koster/prefix.html">this document</a>, which generated the screenshots in Figure 1. Based on implementation experience, the specifications have changed and not all one-liners presented in this article will work. Also, <a href="http://www.princexml.com">Prince</a> and <a href="http://www.antennahouse.com">AntennaHouse</a> have partial support for CSS Figures—these are batch formatters that output <a href="http://www.wiumlie.no/2014/css-figures/koster/prefix-pr.pdf">PDF documents</a>. </p> <p>I&#8217;d love to hear from those who like the approach taken in this article, and those who don&#8217;t. Do you want this added to browsers? Let me know below, or request if from your favorite browser (<a href="https://input.mozilla.org/en-US/feedback">Firefox</a>, <a href="http://www.google.com/support/chrome/bin/static.py?page=suggestions.cs">Chrome</a>, <a href="http://forums.opera.com/categories/en-opera-next-and-opera-developer">Opera</a>, <a href="https://connect.microsoft.com/IE/feedback/">IE</a>). If you don&#8217;t like the features, how would you express the use cases that have been discussed?</p> <p>Pages and columns have been basic building blocks in typography since the Romans started cutting scrolls into pages. This is not why browsers should support them. We should do so because they help us make better, more beautiful, user experiences on mobile devices.</p><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/nueolZaWUro" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)
17. Jul 2014
Laura Kalbag on Freelance Design: I Don&#8217;t Like It
<p>“I don’t like it”—The most dreaded of all design feedback from your client/boss/co-worker. This isn’t so much a matter of <a href="http://alistapart.com/column/me-and-my-big-fat-ego">your ego being damaged</a>, it’s just not useful or constructive criticism.</p> <p>In order to do better we need feedback grounded in understanding of user needs. And we need to be sure it’s not coming from solely the client’s aesthetic preferences, which may be impeccable but may not be effective for the product.</p> <p>Aesthetics are a matter of taste. <a href="http://insideintercom.io/the-dribbblisation-of-design/">Design is not just aesthetics</a>. I’m always saying it, but it’s worth repeating: there are aesthetic decisions in design, but they are meant to contribute to the design as a whole. The design as a whole is created for an audience, and with goals in mind, so objectivity is required and should be encouraged.</p> <p>Is the client offering an opinion based on her own taste, trying to reflect the taste of the intended audience, or trying to solve a perceived problem for the user? Don’t take “I don’t like it” at face value and try to respond to it without more communication.</p> <h2>How do we elicit better feedback?</h2> <p>To elicit the type of feedback we want from clients, we should encourage open-ended critiques that explain the reasons behind the negative feedback, critiques that make good use of conjunctions like “because.” “I don’t like it because…” is already becoming more valuable feedback.</p> <figure class="quote"> <blockquote> <p><b>Designer:</b> Why don’t you like the new contact form design?</p> <p><b>Client:</b> I don’t like it because the text is too big.</p> </blockquote> </figure> <p>Whether that audience can achieve their goals with our product is the primary factor in its success. We need clients to understand that they may not be the target audience. Sometimes this can be hard for anyone close to a product to understand. We may be one of the users of the products we’re designing, but the product is probably not being designed solely for users like us. The product has a specific audience, with specific goals. Once we’ve re-established the importance of the end user, we can then reframe the feedback by asking the question, “how might the users respond?”</p> <figure class="quote"> <blockquote> <p><b>Designer:</b> Do you think the users will find the text too big?</p> <p><b>Client:</b> Yes. They’d rather see everything without having to scroll.</p> <p><b>Designer:</b> The text will have to be very small if we try to fit it all into the top of the page. It might be hard to read.</p> <p><b>Client:</b> That’s fine. All of our users are young people, so their eyesight is good.</p> </blockquote> </figure> <p>Throughout the design process, we need to check our hidden assumptions about our users. We should also ensure any feedback we get isn’t based upon an unfounded assumption. If the client says the users won’t like it, ask why. Uncover the assumption—maybe it’s worth testing with real users?</p> <figure class="quote"> <blockquote> <p><b>Designer:</b> Can we be certain that all your users are young people? And that all young people have good eyesight? We might risk losing potential customers unless the site is easy for everyone to read.</p> </blockquote> </figure> <p>How do we best separate out assumptions from actual knowledge? Any sweeping generalizations about users, particularly those that assume users all share common traits, are likely to need testing. A thorough base of <a href="http://alistapart.com/article/interviewing-humans">user research</a>, with evidence to fall back on, will give you a much better chance at spotting these assumptions.</p> <h2>The design conversation</h2> <p>As designers, we can’t expect other people to know the right language to describe exactly why they think something doesn’t work. We need to know the right questions that prompt a client to give constructive criticism and valuable feedback. I’ve <a href="http://alistapart.com/column/good-designers-good-clients">written before</a> on how we can pre-empt problems by explaining our design decisions when we share our work, but it’s impossible to cover every minute detail and the relationships between them. If a client can’t articulate why they don’t like the design as a whole, break the design into components and try to narrow down which part isn’t working for them.</p> <figure class="quote"> <blockquote> <p><b>Designer:</b> Which bit of text looks particularly big to you?</p> <p><b>Client:</b> The form labels.</p> </blockquote> </figure> <p>When you’ve zeroed in on a component, elicit some possible reasons that it might not be effective.</p> <figure class="quote"> <blockquote> <p><b>Designer:</b> Is it because the size of the form labels leaves less space for the other elements, forcing the users to scroll more?</p> <p><b>Client:</b> Yes. We need to make the text smaller.</p> </blockquote> </figure> <h2>Reining it in</h2> <p>Aesthetics are very much subject to taste. You know what colors you like to wear, and the people you find attractive, and you don’t expect everyone else to share those same tastes. Nishant wrote <a href="http://alistapart.com/column/good-taste-doesnt-matter">a fantastic column about how Good Taste Doesn’t Matter</a> and summarized it best when he said:</p> <figure class="quote"> <blockquote> good and virtuous taste, by its very nature, is exclusionary; it only exists relative to shallow, dull…tastes. And if good design is about finding the most appropriate solution to the problem at hand, you don’t want to start out with a solution set that has already excluded a majority of the possibilities compliments of the unicorn that is good taste. </blockquote> </figure> <h2>Taste’s great</h2> <figure class="quote"> <blockquote> <p><b>Designer:</b> But if we make the text smaller, we’ll make it harder to read. Most web pages require scrolling, so that shouldn’t be a problem for the user. Do you think the form is too long, and that it might put users off from filling it in?</p> <p><b>Client:</b> Yes, I want people to find it easy to contact us.</p> <p><b>Designer:</b> How about we take out all the form fields, except the email address and the message fields, as that’s all the information we really need?</p> <p><b>Client:</b> Yes, that’ll make the form much shorter.</p> </blockquote> </figure> <p>If you’re making suggestions, don’t let a client say yes to your first one. These suggestions aren’t meant as an easy-out, allowing them to quickly get something changed to fit their taste. This is an opportunity to brainstorm potential alternatives on the spot. Working collaboratively is the important part here, so don’t just go away to work out the first alternative by yourself. </p> <p>If you can work out between you which solution is most likely to be successful, the client will be more committed to the iteration. You’ll both have ownership, and you’ll both understand why you’ve decided to make it that way.</p><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/dOrEG9P8E7w" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)
15. Jul 2014
Kids 4–6: &#8220;The Muddy Middle&#8221;
<p>I call kids between ages 4 and 6 the “muddy middle,” because they’re stuck right in between the cute, cuddly preschool children and the savvy, sophisticated elementary-schoolers. They’re too old for games designed for toddlers, but they can’t quite read yet, so they struggle with sites and apps geared toward older kids. Unfortunately, you rarely see a digital product designed specifically for this age group, because they’re hard to pin down, but these little guys are full of ideas, knowledge, creativity, and charisma.</p> <p>Like the 2&#8211;4s, these children are still in the preoperational stage, but they present their own set of design challenges based on where they are cognitively, physically, and emotionally.</p> <h2>Who are they?</h2> <p>Table 5.1 shows some key characteristics that shape the behavior and attitudes of 4–6-year-olds and how these might impact your design decisions.</p> <p>You’ll find that 4–6-year-olds have learned “the rules” for how to behave, how to communicate, and how to play. Now they’re looking for ways to bend and break these rules. They understand limitations—angry parents, broken toys, and sad friends have taught them well—but they still take every opportunity to test these limitations. Digital environments provide a perfect place for these active kids to challenge the status quo and learn more about the world around them.</p> <figure> <table> <tr> <th width="26%">4–6 year-olds&#8230;</th> <th width="37%">This means that&#8230;</th> <th width="37%">You’ll want to&#8230;</th> </tr> <tr> <td>Are empathetic.</td> <td>They’re beginning to see things from other perspectives.</td> <td>Make interactions feel more “social,” even if the kids aren’t actually communicating with others.</td> </tr> <tr> <td>Have an intense curiosity about the world.</td> <td>They’re very interested in learning new ideas, activities, and skills, but may become frustrated when that learning takes longer than they would like.</td> <td>Set attainable goals for the tasks and activities you create. Provide context-based help and support so kids have an easier time processing information.</td> </tr> <tr> <td>Are easily sidetracked.</td> <td>They sometimes have trouble following through on a task or activity.</td> <td>Keep activities simple, short, and rewarding. Provide feedback and encouragement after milestones.</td> </tr> <tr> <td>Have wild imaginations.</td> <td>They prefer to create on their own rather than following strict instructions or step-by- step directions.</td> <td>Make “rules” for play/engagement as basic as possible and allow for a lot of invention, self-expression, and storytelling.</td> </tr> <tr> <td>Are developing increased memory function.</td> <td>Can recall complex sequences of events just by watching someone perform them.</td> <td>Include multi-step activities and games, with more than one main goal (for example, touch the red stars and green apples to get points of different values).</td> &nbsp; </tr> </table> <figcaption>Table 5.1: Considerations for 4–6-year-olds</figcaption> </figure> <h2>Make it social</h2> <p>When you think of social design for adults, you may think of experiences that let users communicate and interact with others. The same is true of social design for kids, but in this case, “others” doesn’t have to mean other kids or even other humans. It means that kids need to feel like part of the experience, and they need to be able to observe and understand the interactions of characters in the experience, as players and contributors. Kids at this age understand that individual differences, feelings, and ideas are important and exciting. Showcasing these differences within the experience and directly communicating with users allows this social aspect to come through and provide additional depth and context to interactions.</p> <p>Sometimes, making something feel social is as easy as presenting it in the first person. When characters, elements, and instructions speak directly to kids, it makes it easier for them to empathize and immerse themselves in the experience.</p> <p>Let’s take a look at an example from <em><a href="http://www.seussville.com/">Seussville</a></em>. The designers of this highly engaging site keep the uniqueness of Dr. Seuss’s characters vibrantly alive in their lovely character chooser. Every character (and I do mean <em>every</em>) from every Dr. Seuss book glides by on whimsical conveyor belts, letting the user pick one to play with (see Figure 5.1). </p> <p>This character chooser provides a strong social experience for kids, because it allows them to “meet” and build relationships with the individual characters. Kids can control the viewer, from a first-person perspective, to see the visual differences among the characters, as well as personality details that make the characters unique, much like how they’d go about meeting people in real life (without the conveyor belt, of course).</p> <p>When users choose a character, they are shown a quote, a book list, and details about the character on the pull-down screen to the right. On the left side of the screen, a list of games and activities featuring the character magically appears.</p> <figure> <img src="http://d.alistapart.com/398/fig05.01.jpeg" alt="Screenshot of the Seussville homepage"> <figcaption>FIGURE 5.1: <em>Seussville</em> presents a first-person perspective to kids.</figcaption></figure> <figure> <img src="http://d.alistapart.com/398/fig05.02.jpeg" alt="Screenshot of Seussville's games and activities page"> <figcaption>FIGURE 5.2: <em>Seussville</em> feels social, even though kids don’t interact with other humans.</figcaption></figure> <p>This social experience is carried through across most of the games on the site. For example, when users pick the “Horton Hears a Tune” game from Horton the elephant’s list of activities, they can compose their own melody on the groovy organ-like instrument under the supportive eyes of Horton himself. Then, in true social fashion, they can save their tune and share it with family and friends.</p> <figure> <img src="http://d.alistapart.com/398/fig05.03.jpeg" alt="Screenshot of “Horton Hears a Tune” on Seussville"> <figcaption>FIGURE 5.3: “Horton Hears a Tune” lets kids compose music and share it.</figcaption></figure> <h2>Make learning part of the game </h2> <p>As a designer, you know that providing help when and where your users need it works better than forcing them to leave the task they’re trying to complete to get help. This is especially true for 4–6-year-olds, who have a strong curiosity for why things are the way they are and want to know everything <em>right away</em>. Unlike the “school stinks” mentality of earlier generations, today’s kids are fascinated with learning and want to soak up as much information as possible. </p> <p>This new attitude could be because learning is more dynamic, more hands-on, and more inventive than it’s been in the past, or because computers, tablets, and other digital teaching tools make learning fun. However, younger kids still lack patience when learning takes longer than they’d like. You’ll want to provide short, manageable instructions to make learning fast, easy, and pleasurable, and to incorporate learning into the experience itself.</p> <p>The <em>Dinosaur Chess</em> app does a great job with structured teaching, as well as on-the-spot assistance to help kids learn how to play chess (see Figure 5.4). Upon launching the app, children get to choose what they want to do. The great thing about <em>Dinosaur Chess</em> is that it’s not just all about chess—kids can take lessons, check their overall progress, and even participate in a “dino fight!”</p> <p>One perk is how the app links the activities via a treasure-hunt-style map on the menu screen. It gently recommends a progression through the activities (which older kids will follow), but is subtle enough to allow exploration. This feature is great for kids who like to break the rules, because it establishes a flow, yet invites users to deviate from it in a subtle yet effective way.</p> <figure> <img src="http://d.alistapart.com/398/fig05.04.jpeg" alt="Screenshot of the Dinosaur Chess homescreen"> <figcaption>FIGURE 5.4: <em>Dinosaur Chess</em> offers many opportunities for learning.</figcaption></figure> <p>When users select the “learn” option, they are taken to a screen where an avuncular dinosaur (who, for some reason, is Scottish) talks kids through the mechanics of chess in a non-intimidating way. Since these kids are still learning to read, the designers used voice-overs instead of text, which works really well here.</p> <p>The lessons are broken up into short, manageable chunks—essential for learning via listening—which let the 4–6s learn a little at a time and progress when they are ready. The children can also try out various moves after learning them, which is particularly effective with younger users who learn by seeing and doing (see Figure 5.5).</p> <p>If this app were designed for an adult audience, the lessons would be a little longer and would probably include text explanations in addition to the audio, since a combination of listening and reading works best for grown-ups. However, the brief audio segments coupled with animated examples are perfect for younger users’ short attention spans and desire to learn as much as quickly as possible.</p> <figure> <img src="http://d.alistapart.com/398/fig05.05.jpeg" alt="Screenshot of a chess game"> <figcaption>FIGURE 5.5: <em>Dinosaur Chess</em> teaches kids how to play chess in short, informational chunks.</figcaption></figure> <p>My favorite aspect of <em>Dinosaur Chess</em> is its guided playing. At any point during the game, kids can press the “?” button for help. Instead of popping a layer, which many sites and apps do (even those designed for a younger audience), <em>Dinosaur Chess</em> uses subtle animation and voice-overs to show the users what their next moves should be, as shown in Figure 5.6.</p> <figure> <img src="http://d.alistapart.com/398/fig05.06.jpeg" alt="Screenshot of a chess game showing contextual help arrows"> <figcaption>FIGURE 5.6: <em>Dinosaur Chess</em> uses animation and voice-overs to provide contextual help.</figcaption></figure> <h2>Give feedback and reinforcement</h2> <p>As anyone knows who has dealt with this age group, 4–6-year-olds have short attention spans. This is particularly true of the younger ones, because kids ages 6 and up are able to pay attention for longer periods of time and absorb more information in a single session. What’s interesting (and challenging) about these younger ones is that they get frustrated at themselves for not being able to focus, and then they channel that frustration onto the experience.</p> <p>A common response to this from designers is: “Well, I’ll make my app/game/site super fun and interesting so that kids will want to play longer.” That’s not going to happen. A better approach is to identify opportunities within the experience to provide feedback, in order to encourage kids to continue. </p> <p>Here are some ways to keep children focused on a particular activity:</p> <ul> <li><b>Limit distractions</b>. With a child audience, designers tend to want to make everything on the screen do something, but if you want your 4–6s to complete a task (for example, finish a puzzle or play a game), then remove extra functionality.</li> <li><b>Break it up</b>. As when you’re designing for 2–4s, it’s best to break activities for 4–6s into manageable components. The components can be a bit bigger than ones you might design for a younger audience, but many clear, simple steps are better than fewer, longer ones. While adult users prefer to complete as few steps as possible, and scroll down to finish a task on a screen, 4–6s like finishing a step and moving to a new screen.</li> <li><b>Make it rewarding</b>. Provide feedback after each piece of an activity is completed, which will help your users stay motivated to continue. If you have the time and budget, use a combination of feedback mechanisms, to keep an element of surprise and discovery in the task-completion process.</li> </ul> <h2>Keep it free-form</h2> <p>The 4–6-age bracket gravitates toward activities that are open and free-form, with simple, basic rules (and lots of opportunities to deviate from the rules). This changes pretty dramatically when kids hit age 7 or so. At that point, they become quite focused on staying within boundaries and need a certain level of structure in order to feel comfortable. However, these younger kids like to break the rules and test limits, and digital environments are the perfect places to do this.</p> <p><em><a href="http://www.zoopz.com/">Zoopz.com</a></em> has a great mosaic-maker tool, which lets kids enhance existing mosaic designs or create their own from scratch (see Figures 5.7 and 5.8).</p> <figure> <img src="http://d.alistapart.com/398/fig05.07.jpeg" alt="Screenshot of a Zoopz.com mosaic"> <figcaption>FIGURE 5.7: An existing mosaic design from <em>Zoopz.com</em>, which lets kids experiment and test limits.</figcaption></figure> <figure> <img src="http://d.alistapart.com/398/fig05.08.jpeg" alt="Screenshot of a Zoopz.com mosaic being created"> <figcaption>FIGURE 5.8: <em>Zoopz.com</em> mosaic-creator enables kids to create their own cool designs.</figcaption></figure> <p>The nice thing about <em>Zoopz</em> is that it requires little to no explanation in order to make mosaics—kids can jump right in and start playing. This feature is important, as younger ones will get frustrated if they need to listen to detailed instructions before getting started and will likely move on to something else before the instructions are complete. Typically, 4- and 5-year-olds will leave websites and close apps that they can’t immediately figure out. Older kids will hang around and pay attention to directions if the perceived reward is high enough, but young ones abandon the site right away. So if your game allows for free exploration, make sure that it’s really free and doesn’t require lots of information in order to play.</p> <p>An important thing to note about open exploration/creation: If you’re designing something with a “takeaway,” as <em>Zoopz</em> is, make sure that kids can either print or save their creations. The only thing kids like better than playing by their own rules is showing their work to others. <em>Zoopz</em> misses an opportunity here, because it doesn’t offer the ability for kids to share their work, or print it out to show to friends and family. This feature becomes even more important as kids get older. We’ll talk at length about sharing, saving, and storing in Chapter 6, “Kids 6–8: The Big Kids.”</p> <h2>Keep it challenging</h2> <p>The worst insult from a child between the ages of 4 and 5 is to call something “babyish.” They’re part of the big-kid crowd now, and the last thing they want is to feel like they’re using a site or playing a game that’s meant for younger kids. Unfortunately, it’s hard to pin down exactly what “babyish” means, because the definition changes from kid to kid, but in my experience, children call something “babyish” when it’s not difficult or challenging enough for them. Since kids show increased memory function (and more sophisticated motor skills) starting at around age 4, adding multiple steps to games and activities helps keep them on their toes.</p> <p>As designers, we instinctively want to make stuff that users can master immediately. If you’re designing for elementary-school kids, you’ll want to move away from that mindset. While it’s true that children need to be able to easily figure out the objectives of a game or app right away, they don’t necessarily have to do it perfectly the first time. Instead, build in easier layers early on so that kids can complete them quickly, but throw in some extras that might be a little harder for them. For example, if you’re designing a game where kids have to shoot at flying objects, send in a super-fast projectile they have to catch to win extra points or add a harder “bonus round.” Kids will be less likely to call something “babyish” if it takes them several tries to master. And they’ll appreciate the vote of confidence you’re giving to their memory and agility.</p> <h2>Parents are users, too</h2> <p>When adding complexity to your game or app, you’ll still need to make the basic premise simple and clear. A little parental intervention is sometimes necessary, in order to explain rules and demonstrate interactions, but when parents or siblings have to become very involved in game mechanics, it’s frustrating for all parties. </p> <p>Try not to place too much emphasis on “winning” and keep the perceived “rewards” small and unexciting, if you have them at all. Kids tend to ask parents to step in and help with the trickier parts if the reward for winning is really high. While I believe that a parent should be in the room when kids are online and should check on kids frequently when they’re using a device, too much involvement takes away some autonomy from the kids and prevents them from learning as much as they could and should. </p> <h2>Chapter checklist</h2><p> <br /> Here’s a checklist for designing for 4–6-year-olds.</p> <p>Does your design cover the following areas?</p><ul> <li>Feel “social”?</li> <li>Break up instructions and progression into manageable chunks?</li> <li>Provide immediate positive feedback after each small milestone?</li> <li>Allow for invention and self-expression?</li> <li>Include multi-step activities to leverage improved memory function?</li> </ul><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/aaOoiPJBNsQ" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)
9. Jul 2014
Longform Content with Craft Matrix
<p>Jason Santa Maria recently shared some thoughts about <a href="https://the-pastry-box-project.net/jason-santa-maria/2014-june-15">pacing content</a>, and my developer brain couldn’t help but think about how I’d go about building the examples he talked about.</p> <p>The one fool-proof way to achieve heavily art-directed layouts like those is to write the HTML by hand. The problem is that content managers are not always developers, and the code can get complex pretty quickly. That’s why we use content management systems—to give content managers easier and more powerful control over content.</p> <p>There’s a constant tension between that type of longform, art-directed content and content management systems, though. It’s tough to wrangle such unique layouts and styles into a standardized CMS that scales over time.</p> <p>For a while, the best we could do was a series of custom fields and a big WYSIWYG editor for the body copy. While great for content entry, WYSIWYG editors lack the control developers need to output the semantic and clean HTML that make the great experiences and beautiful layouts we’re tasked with building.</p> <p>This tension leaves developers like myself looking for different ways to manage content. My attention recently has been focused on <a href="http://buildwithcraft.com">Craft</a>, a new CMS that is just over a year old.</p> <p>Craft’s solution for longform content is the <a href="http://buildwithcraft.com/features/matrix">Matrix field</a>. With Matrix, developers have the flexibility to <a href="http://buildwithcraft.com/docs/matrix-fields#settings">provide custom fields</a> to be used for content entry, and can <a href="http://buildwithcraft.com/docs/matrix-fields#templating">write custom templates</a> (using <a href="http://twig.sensiolabs.org/">Twig</a>, in Craft’s case) to be used to render that content.</p> <p>A Matrix field is made up of blocks, and each block type is made up of fields—anything from text inputs, to rich text, dropdowns, images, tables, and more. Here’s what a typical Matrix setup looks like:</p><figure><img src="http://alistapart.com/d/misc-images/Blog_images/matrix-config.jpg" alt="Configuring a Matrix field"></figure> <p>Instead of fighting with a WYSIWYG editor, content managers <a href="http://buildwithcraft.com/docs/matrix-fields#the-field">choose block types to add to the longform content area</a>, fill out the provided fields, and the content is <a href="http://buildwithcraft.com/docs/matrix-fields#templating">rendered beautifully using the handcrafted HTML</a> written by developers. I use the Matrix field to drive longform content on my own site, and you can see how much flexibility it gives me to create <a href="http://acolangelo.com/blog/unsung-success">interesting layouts</a> filled with images with captions, quotes with citations, and more.</p> <p>To pull back the curtain a bit, here’s how my blog post <a href="http://acolangelo.com/blog/unsung-success">Unsung Success</a> is entered into the Matrix field:</p><figure><img src="http://alistapart.com/d/misc-images/Blog_images/matrix-field.png" alt="Entering Content with the Matrix field"></figure> <p>Three block types are used in the post seen above—an image block, a quote block, and a text block. Notice that the text block is using a WYSIWYG editor for text formatting—they’re still good for some things!</p> <p>The Matrix field is endlessly customizable, and provides the level of flexibility, control, and power that is needed to achieve well-paced, art-directed longform content like the examples Jason shared. This is a huge first step beyond WYSIWYG editors and custom fields, and as we see more beautifully designed longform pieces, our tools will only get better.</p><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/c_Zwgi1tTcY" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)
3. Jul 2014
Nishant Kothary on the Human Web: In Pursuit of Facebook Happiness
<p>The outrage being directed at Facebook right now centers on its experiment in manipulating the emotions of 689,003 users in 2012.</p> <p>Regardless of where you stand on the issue, there’s no denying the phantasmagorical irony that we’re upset (and sad) about how Facebook affects our emotions thanks to learning about a study where Facebook affected our emotions through someone on Facebook. Maybe that, too, was <a href="http://www.theawl.com/2014/06/this-social-network-changed-how-news-works-but-then-it-made-some-news-of-its-own">to be expected</a>.</p> <p>One of the motivations for Facebook’s controversial study was to debunk the notion that seeing our friends’ happy posts in our news feeds actually makes us sadder. And according to <a href="https://www.facebook.com/akramer/posts/10152987150867796">a post by Adam Kramer</a>, the primary author of the study, it did exactly that, “We found the exact opposite to what was then the conventional wisdom: Seeing a certain kind of emotion (positive) encourages it rather than suppresses it.”</p> <p>But, how profound is this effect on users’ overall enjoyment while they’re using Facebook? That remains unknown, and in my experience, it’s not much at all.</p> <p>We already know that social media has a profound effect on our emotions. I’ve personally struggled with the emotional rollercoaster for years now. My Achilles’ heel used to be Twitter because I used to be a heavy user. I even <a href="http://visitmix.com/writings/dear-twitter">quit the service</a> for a whole year to regain my bearings. And while <a href="http://rainypixels.com/words/life-after-twitter/">the hiatus turned out to be very positive</a>, I didn’t quite get to the bottom of what inevitably turns me off about Twitter. And then, of course, there was Facebook.</p> <p>Facebook affected my mood so dramatically that I’d stopped using it entirely for years until a few months ago. I used to refer to Facebook as, “The place my Instagram pictures go to die.” This was partly in jest, partly serious. My Instagram account is dedicated to my dog, and it’s hard to not notice that a picture or video that can get a few hundred likes, spur over a hundred comments, and bring so much joy to both me and my followers is often met with dead silence or, worse, scorn on Facebook (and honestly, on Twitter as well). There are many reasons for this, several that I covered in one of my prior columns, <a href="http://alistapart.com/column/the-real-real-problem-with-facebook">The REAL Real Problem with Facebook</a>. But there is one above all: Not everyone is interested in pictures of my dog.</p> <p>*Blasphemy!*</p> <p>OK, so this isn’t really news, and it’s hardly blasphemous. It’s understandable that people wouldn’t want to see images of someone else’s dog every day. But then why the disparity between how enthusiastically my content is received on Instagram as opposed to Facebook (or even Twitter)? Therein lies the key to the puzzle.</p> <p>It’s really quite simple: people follow me on Instagram specifically for pictures of my Weimaraner (yes, it’s a <a href="http://www.johnnywander.com/files/comics/254.jpg">notoriously difficult to pronounce</a> dog breed).</p> <p>I never intended on turning my Instagram account into a dog account. It just happened. And in the process I met loads of Weimaraner (and dog) people from around the world (some whom, true story, I’ve subsequently met in real life). I now honor an informal contract to only post pictures of my dog. And what happens when I break that contract and post the occasional picture of something else? I’m rewarded with crickets in terms of engagement.</p> <p>What escaped me back when I quit Twitter or when I silently shunned Facebook was that the negativity or the positivity of the posts wasn’t even relevant to the compounding effect of the social network on my emotional well being. What was more to blame was the lack of engagement; the lack of feeling a connection. As much as we do in all life, online we want to meet, engage, and be engaged by others who share our passions and interests. And when that doesn’t happen, well, it can be a bummer.</p> <p>Over the past few months I’ve joined numerous groups related to my interests on Facebook (yes, including a Weimaraner group). The result is that my Facebook news feed is now flooded with content I enjoy far more. I’ve essentially hacked my Facebook world to feel a lot more like my Instagram world—more focused on my interests and pastimes. Sharing and talking with folks who care about the same things has made Facebooking infinitely more enjoyable. In an unexpected way, I think it has also helped me understand the mid-conversation exclamations I receive from some people about how much they love Pinterest.</p> <p>One would think that Pinterest would be the ideal social network for most of us, especially me. After all, on Pinterest you can follow someone’s Weimaraner board, and dodge all their gardening, baby, culinary, and political content. What’s not to like? Well, clearly something, because like loads of people, I’ve never quite gotten into Pinterest. I have some theories why that’s the case, but my disinterest is beside the point. What seems clear to me is that Pinterest is really onto something. We need a social network that acknowledges that we all have facets, and that it’s OK for us to pick and choose each other based on our interests. In my experience, the amount of happiness you feel on a social network seems to relate more closely to how much the content caters to your interests.</p> <p>So, if you&#8217;re looking to maximize your happiness on social networks, here&#8217;s the short-term solution: fill your account with content that&#8217;s interesting to you. Like or follow your favorite sports teams, TV shows, clubs, non-profits, news organizations, web design magazines, and anything else you&#8217;re into. In other words, make your feeds about things you genuinely like, happy or sad, instead of about your real-world social obligations.</p> <p>And that may also mean muting or unfollowing the people filling your feed with posts about their gardens, babies, food, or politics.</p> <p>Or, god forbid, their dogs.</p> <figure> <img src="http://d.alistapart.com/Column-Nishant/yoshi_happy.jpeg"> </figure><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/aLblbir20A4" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)
14. Oct 2013
CSS Books &amp; CSS Figures
Today we're happy to add two more specs to the WHATWG stable, Books and Figures! These are specifications focused on CSS features. Books provides ways to turn HTML document into books, either on screen or on paper. Using Books, authors can style cross-references, footnotes, and most other things needed to present books on screen or [&#8230;][mehr] (Quelle: The WHATWG Blog)
20. Jul 2012
Relationship update on HTML Living Standard and W3C HTML5
In an email to the WHATWG mailing list Ian Hickson explained how the relationship between the WHATWG and W3C effort around HTML has evolved. It is recommended reading if you want to know the details. In summary, we will remain focused on improving HTML and related technologies to address the needs of users, developers, and [&#8230;][mehr] (Quelle: The WHATWG Blog)
8. Jun 2012
Validator.nu HTML Parser 1.4 Available
A new release of the Validator.nu HTML Parser is available. The new version 1.4 contains minor adjustments to spec compliance and fixes for notable Java-specific problems (of the crash and infinite loop sort). Also, the parser is again available from the Maven Central Repository (groupId: nu.validator.htmlparser, artifactId: htmlparser, version: 1.4). Upgrading to the newest version [&#8230;][mehr] (Quelle: The WHATWG Blog)
26. May 2012
The Future of the Web: My Vision (May 23, 2012)
I apologize for the longer than expected wait for this article, but now, we may continue. The article below will pick up where Part 1 left off. Article 1: Websites and SectioningPart 2: Styling &#60;warning&#62;Warning: This article discusses the topic of &#60;semantics&#62;semantics&#60;/semantics&#62;&#60;/warning&#62; As we began with previously, we now have the basics down as to [&#8230;][mehr] (Quelle: The WHATWG Blog)
1. May 2012
The Future of the Web: My Vision (May 1, 2012)
Like probably many others who read this blog, I am a web design enthusiast, web standards advocate, and web designer by trade. I have been working with HTML since the early 2000s, and have enjoyed it ever since. Over the years, the web has evolved around me. I have watched it grow and adapt. And [&#8230;][mehr] (Quelle: The WHATWG Blog)
24. Apr 2012
Patent Policy
The WHATWG now has a patent policy, the WHATCG. We will keep using the same mailing list, the same IRC channel, the same web sites, but now sometimes we will publish through the WHATCG as well for patent policy purposes per the W3C Community Final Specification Agreement. If you could previously not join the WHATWG [&#8230;][mehr] (Quelle: The WHATWG Blog)
11. Apr 2012
WHATWG Weekly: Fullscreen dialog
Ian Hickson made a proposal to unify Web Intents with registerProtocolHandler() and registerContentHandler(). The Encoding Standard now has all its decoders defined. This is the WHATWG Weekly. The big news this week is the new dialog element. Introduced in revision 7050, along with a new global attribute called inert, a new form element method attribute [&#8230;][mehr] (Quelle: The WHATWG Blog)
29. Mar 2012
WHATWG Weekly: HTML canvas version 5 has arrived
The StringEncoding proposal is getting closer to consensus. It now consists of a TextEncoder and a TextDecoder object that can be used both for streaming and non-streaming use cases. This is the WHATWG Weekly. Some bad news for a change. It may turn out that the web platform will only work on little-endian devices, as [&#8230;][mehr] (Quelle: The WHATWG Blog)
14. Mar 2012
WHATWG Weekly: Path objects for canvas and creating paths through SVG syntax
Jonas Sicking proposed an API for decoding ArrayBuffer objects as strings, and encoding strings as ArrayBuffer objects. The thread also touched on a proposal mentioned here earlier, StringEncoding. This is the mid-March WHATWG Weekly. Revision 7023 added the Path object to HTML for use with the canvas element, and the next revision made it possible [&#8230;][mehr] (Quelle: The WHATWG Blog)
8. Jan 2010
BITV mit Links zu HTML und CSS
Die Barrierefreiheit von Webseiten wird in Deutschland durch die &#8220;Barrierefreie Informationstechnik-Verordnung&#8221;, kurz BITV geregelt. Wenngleich sich der Wirkungsbereich nur auf Seiten von Behörden erstreckt, hat die BITV auch eine große Bedeutung für Unternehmensseiten bekommen. Die BITV ist naturgemäß stellenweise abstrakt, ähnlich wie die verwandten englischen Texte des W3C. Um die Verständlichkeit zu erhöhen, haben wir [...][mehr] (Quelle: blog.linkwerk.com » edition W3.de)
7. Jan 2010
BITV auf <edition W3.de>

Als Ergänzung zu den Zugänglichkeitsrichtlinien für Web-Inhalte steht ab heute auch die BITV hier zur Verfügung.

(Quelle: <edition W3.de> Neuigkeiten)
11. Dec 2009
Cross-Browser: es wird immer besser – oder doch nicht?
Dem im März 2009 erschienenen Internet Explorer 8 wurde von Anfang an eine bessere Unterstützung von Webstandards bescheinigt. Wer Websites macht, wird das bestätigen können. Wer allerdings Javascript-Bibliotheken entwickelt, die von anderen auf ihren Seiten eingesetzt werden sollen, kann ein anderes Bild bekommen. Mit dem IE6 hat Microsoft die Unterscheidung in &#8220;Quirks Mode&#8221; und &#8220;Standard [...][mehr] (Quelle: blog.linkwerk.com » edition W3.de)
7. Dec 2009
ECMAScript 5 verabschiedet
Am 3. Dezember hat die Ecma die Verabschiedung von ECMAScript5 bekanntgegeben. Im Gegensatz zu manch anderem Standardisierungsgremium, bietet die Ecma ihre Standards kostenfrei zum Download auf der Webseite an: Für ECMAScript siehe Ecma-262. ECMAScript ist die standardisierte Form von Javascript und damit ein wichtiger Baustein für die Weiterentwicklung des Web. Über die wichtigsten neuen Features [...][mehr] (Quelle: blog.linkwerk.com » edition W3.de)
2. Dec 2009
XSLT-Schulung von Linkwerk – von Kunden ausgezeichnet
Einmal mehr dürfen wir uns über Bestnoten für unseren XSLT-Workshop freuen. In der vergangenen Woche haben wir eine XSLT-Schulung für einen neuen Kunden durchgeführt. Die Kundenbewertungen auf den Feedbackbögen zeichnet uns und unsere Leistung aus. In allen Punkten, von &#8220;Inhalt&#8221; über &#8220;Präsentation&#8221; und &#8220;Übungen&#8221; bis zur &#8220;Gesamtbewertung&#8221; bekommen wir sehr gute Noten. Darüber hinaus sagen [...][mehr] (Quelle: blog.linkwerk.com » edition W3.de)
2. Dec 2009
Relaunch von <edition W3.de>

Heute geht eine überarbeitete Version der <edition W3.de> online.

(Quelle: <edition W3.de> Neuigkeiten)
22. Nov 2009
Das neue JavaScript — EcmaScript 5 kommt
Zum Jahresende wird die Verabschiedung von EcmaScript 5 erwartet. In der aktuellen Ausgabe der iX schreibe ich über die wichtigsten neuen Features. Für alle Leser des Artikels oder diejenigen, die sich selbst einen Eindruck verschaffen möchten, stelle ich im Folgenden die Quellen zusammen. Wikipedia: ECMAScript Allen Wirfs-Brock: Steps Toward Creating Compatible ECMAScript 5 Implementations Allen [...][mehr] (Quelle: blog.linkwerk.com » edition W3.de)
20. Nov 2009
W3C sperrt Java aus
Heute habe ich bei der Arbeit mit einer XSLT-Engine an meinem Verstand gezweifelt. Die Aufgabe war einfach: Ein kleines Verarbeitungsskript für eine Webseite. Doch leider brach die Verarbeitung immer ab, weil der XSLT-Interpreter die DTD nicht vom Server des W3C laden konnte. Natürlich sollte man besser eine lokale DTD verwenden, dennoch war es überraschend, dass [...][mehr] (Quelle: blog.linkwerk.com » edition W3.de)
18. Nov 2009
Canonical Link
Die ursprüngliche Idee der Adressen im Web beinhaltet auch, dass man über eine Adressangabe eine Seite finden kann. Schließlich heißt der Fachbegriff nicht umsonst URI &#8212; Uniform Resource Identifier. Es gibt aber zahlreiche Beispiele, bei denen das nicht der Fall ist. Oft sind Session-IDs, Query-Parameter oder andere temporäre Informationen in der Adresse enthalten. Die machen [...][mehr] (Quelle: blog.linkwerk.com » edition W3.de)
3. Nov 2009
Talk Semantic Web, auf semanticoverflow.com
Es ist schön zu sehen, dass Semantic Web Technologien zunehmend zum Thema werden. Jüngster Zuwachs im Bereich der Semantic Web Community ist wohl semanticoverflow.com, eine Seite die sich ganz im stile ihres grossen Bruders stackoverflow.com der Aufgabe widmet Fragen rund um das Thema Semantic Web Community-basiert zu beantworten. Ich wünsche der Seite zumindest vergleichbaren Erfolg [...][mehr] (Quelle: blog.linkwerk.com » edition W3.de)
2. Nov 2009
Hilfe, mein Software-Agent hat Angst
Na ja, ganz so weit ist es noch nicht. Aber sollte ich mal einen persönlichen, autonomen und wirklich intelligenten Software-Agenten mein Eigen nennen, könnte er ja auch mal Angst haben, sich überlastet oder ausgebrannt fühlen. Das W3C arbeitet jedenfalls schon mal an der passenden Auszeichnungssprache: EmotionML. Wer jetzt glaubt, die Initiative sei genauso sinnvoll wie [...][mehr] (Quelle: blog.linkwerk.com » edition W3.de)
27. Oct 2009
GeoCities schließt…
&#8230;und der ein oder andere mag sich fragen, was ist &#8220;GeoCities&#8221;? In der Frage ist zumindest die Antwort auf die Frage zu finden, weshalb Yahoo die Site dicht macht. &#8220;Wow, eine geschlossene Website, das ist&#8217;n Blogartikel wert!&#8221; &#8212; Die Tatsache ist wohl nicht bemerkenswert, allerdings ist der Artikel der L.A. Times lesenswert für alle, die [...][mehr] (Quelle: blog.linkwerk.com » edition W3.de)