<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>

17. Apr 2014
SVG Integration Draft Published
The SVG Working Group has published a Working Draft of SVG Integration. This specification details requirements on how SVG documents must be processed when used in various contexts, such as CSS background images, HTML ‘iframe’ elements, and so on. These requirements include which features are restricted or disabled, such as scripting and animation. A number [&#8230;][mehr] (Quelle: W3C News)
17. Apr 2014
The Death of the Web Design Agency?
<figure class="quote"> <blockquote> <p>Others have gone as far to say that the very concept of a user experience-focused agency simply isn’t a long-term play, largely because of what the big folks are up to. Facebook and Google went on a design/product buying spree specifically because they needed to figure out how to own this thinking themselves, and other tech companies have followed. And more traditional industries, like insurance, media, and retail? They’ll develop robust in-house capabilities soon, if they haven’t already.</p><p> Ready to pack up your things and start a landscaping business? Not so fast.</p> </blockquote><figcaption>Greg Hoy, <cite><a href="https://the-pastry-box-project.net/greg-hoy/2014-April-17">Differentiate or Die?</a></cite></figcaption> </figure> <p>In The Pastry Box Project today, Greg Hoy of Happy Cog talks honestly about why the first quarter of this year <em>sucked</em> for most web design agencies (including ours), assesses the new and growing long-term threats to the agency business model, and shares his thinking on what we in the client services design business can do to survive, and maybe even thrive.</p><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/gZNWImoycbg" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)
17. Apr 2014
Cennydd Bowles on UX & Design: Letter to a Junior Designer
<p>I admit it: you intimidate me. Your work is vivid and imaginative, far superior to my woeful scratchings at a similar age. The things I struggle to learn barely make you sweat. One day, you’ll be a better designer than me.</p> <p>But for now, I can cling to my sole advantage, the one thing that makes me more valuable: I get results. I can put a dent in cast-iron CEO arguments. I can spot risks and complications months in advance. In the wager that is design, I usually bet on the right color. People trust me with their stake.</p> <p>So, if you’ll humor me, maybe I can offer a few suggestions to speed you toward the inevitable.</p> <h2>Slow down</h2> <p>You’re damn talented. But in your eagerness to prove it, you sometimes rush toward a solution. You pluck an idea from the branch and throw it onto the plate before it has time to ripen. Don’t mistake speed for precocity: the world doesn’t need wrong answers in record time.</p> <p>Perhaps your teachers exalted The Idea as the gem of creative work; taught you The Idea is the hard part. I disagree. Ideas aren’t to be trusted. They need to be wrung dry, ripped apart. We have the rare luxury that our professional diligence often equates to playfulness: to do our job properly, we must disassemble our promising ideas and make them into something better.</p> <p>The process feels mechanical and awkward initially. In time, the distinction between idea and iteration will blur. Eventually, the two become one.</p> <p>So go deeper. Squander loose time on expanding your ideas, even if you’re sure they’re perfect or useless. Look closely at decisions you think are trivial. I guarantee you’ll find better solutions around the corner.</p> <h2>Think it through</h2> <p>We’d love to believe design speaks for itself, but a large part of the job is helping others hear its voice. Persuasive rationale—the why to your work—is what turns a great document into a great product.</p> <p>If you haven’t already, sometime in your career you’ll meet an awkward sonofabitch who wants to know why every pixel is where you put it. You should be able to articulate an answer for that person—yes, for every pixel. What does this line do? Well, it defines. It distinguishes. But why here? Why that color? Why that thickness? “It looks better” won’t suffice. You’ll need a rationale that explains hierarchy, balance, gestalt—in other words, esoteric ways to say “it looks better,&#8221; but ways that reassure stakeholders that you understand the foundations of your craft. Similarly, be sure you can explain which alternatives you rejected, and why. (Working this through will also help you see if you have been diligent or if you’ve been clinging to a pet idea.) This might sound political. It is. Politics is just the complex art of navigating teams and people, and the more senior you get, the more time you’ll spend with people. </p> <h2>Temper your passion</h2> <p>Your words matter: be careful not to get carried away. Passion is useful, but you’ll be more effective when you demonstrate the evidence behind your beliefs, rather than the strength of those beliefs. Softer language earns fewer retweets but better results. If you have a hunch, call it a hunch; it shows honesty, and it leaves you headroom to be unequivocal about the things you’re sure of.</p> <p>Similarly, your approach to your work will change. Right now design is an ache. You see all the brokenness in the world: stupid products, trivial mistakes, bad designs propped up with scribbled corrections. That stupidity never goes away, but in time you learn how to live with it. What matters is your ability to change things. Anyone can complain about the world, but only a good few can fix it.</p> <p>That fury, that energy, fades with time, until the question becomes one of choosing which battles to arm yourself for, and which to surrender. Often this means gravitating toward the biggest problems. As you progress in the field, your attention may turn from tools and techniques to values and ethics. The history of the industry is instructive: give it proper attention. After all, all our futures shrink with time, until finally the past becomes all we have.</p> <p>You’ll come to appreciate that it can be better to help others reach the right outcomes themselves than do it yourself. That, of course, is what we call leadership.</p> <p>Finally, there may come a point when you realize you’re better served by thinking less about design. Work and life should always be partially separate, but there’s no doubt that the experiences you have in your life shape your work too. So please remember to be a broad, wise human being. Travel (thoughtfully) as much as you can. Read literature: a good novel will sometimes teach you more than another design book can. Remind yourself the sea exists. You’ll notice the empathy, sensitivity, cunning, and understanding you develop make your working life better too.</p> <p>But you’re smart, and of course you realize this is really a letter to the younger me. And, alongside, it’s a lament at my nagging sense of obsolescence; the angst of a few grey hairs and the emerging trends I don’t quite understand. Which is mildly ridiculous at my age—but this is a mildly ridiculous industry. And you’ll inherit it all, in time. Good luck.</p> <p>Yours,<br /> Cennydd</p><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/liAX1LoO24E" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)
16. Apr 2014
This week's sponsor: Harvest
<p>Have you ever billed hourly? A List Apart is brought to you this week by Harvest, a beautifully crafted time tracking tool for creative shops. </p> <p><a href="http://bit.ly/1g7Fp58">Start a trial before the year slips away.</a></p><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/Gj7eOe7vcsI" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)
11. Apr 2014
Style Guides On Parade
<a href="http://susanjeanrobertson.com/code/style-guide-links/" style="font-size: 18px;">» Style Guides On Parade</a><br><br>If you loved this week’s “Creating Style Guides” piece by Susan Robertson, you’ll thrill to Susan’s follow-up posting, on her personal site, of style guide links galore! <br><br><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/yWMDiRNZoE4" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)
14. Apr 2014
XQuery 3.0, XPath 3.0, XQueryX 3.0, XDM 3.0, Serialization 3.0, Functions and Operators 3.0 are now W3C Recommendations
The XML Query Working Group published XQuery 3.0: An XML Query Language, along with XQueryX, an XML representation for XQuery, both as W3C Recommendations, as well as the XQuery 3.0 Use Cases and Requirements as final Working Group Notes. XQuery extends the XPath language to provide efficient search and manipulation of information represented as trees [&#8230;][mehr] (Quelle: W3C News)
10. Apr 2014
XML Entity Definitions for Characters (2nd Edition), and Mathematical Markup Language (MathML) Version 3.0 2nd Edition are W3C Recommendations
The Math Working Group has published two W3C Recommendations today: XML Entity Definitions for Characters (2nd Edition). This document defines several sets of names, so that to each name is assigned a Unicode character or sequence of characters. Each of these sets is expressed as a file of XML entity declarations. Mathematical Markup Language (MathML) [&#8230;][mehr] (Quelle: W3C News)
10. Apr 2014
Matt Griffin on How We Work: My Life with Email
<p>I’d like to take a moment to address something decidedly unsexy. We all do it. And it’s never pretty. You guessed it: I’m talking about email.</p> <p>No, I don&#8217;t mean responsive design approaches for email newsletter templates. Nope. Not even that much fun. I’m talking about reading and responding to that everyday, humdrum, never-ending stream of communication that flows through the inscrutable ether to your very own inbox.</p> <p>Staying in control of your life with email is a challenge (look no further than your friends’ triumphant cries of “inbox zero!”). When you run your own business, as I do, there is every motivation to always stay on top of these messages. It is, after all, your thing. You own it. Shouldn’t you be addressing every issue as it crops up, and responding with lightning speed?</p> <p>This lifestyle really caught up with me a year or so ago. It was affecting my sleep and productivity, and saddling me with all kinds of extra cognitive overhead. It was no fun at all. Over the course of several months, I worked at establishing rules and procedures for email that helped me regain my sanity and improve the quality of my workdays (not to mention my weekends). In no particular order, here they are:</p> <h2>We don’t need no stinking badges</h2> <p>One of the first and most obvious things I did was turn off notifications and badges for email. Turning on email notifications is like asking to be interrupted by anyone at any time, no matter what you’re doing. If you must have notifications, consider adding essential people to a <a href="http://support.apple.com/kb/TI32">VIP list</a>, and hiding all other notifications. Ask yourself, “who would I need to drop everything for, no matter how important my task is at that moment?”</p> <h2>Filters, filters, filters</h2> <p>OMG, filters, guys! Filters that route the endless stream of notifications (for instance Basecamp updates, or emails from your ticketing system) are great. They keep things organized neatly so that you can address like emails all at once. Since these sorts of emails will often be project-specific—this also makes it easier to remember to track your time while you’re doing it (hint, hint).</p> <h2>More apps!</h2> <p>On the weekend, I really don’t want to accidentally open a troublesome work email. To keep a clear distinction between my personal and work emails, I started using a separate app for personal email. Personally, I’m quite happy with <a href="http://www.mailboxapp.com/">Mailbox</a>, but I also know some smart folks who like <a href="http://www.getboxer.com/">Boxer</a>. I’m sure there are plenty of other great ones, too (reader comments, activate!).</p> <h2>Say when</h2> <p>Just like the ticket queue of tasks, you’re never really finished answering emails. To help me focus on my home life when I’m not at work, I use a timed <a href="http://support.apple.com/kb/HT5463">“do not disturb” setting in iOS</a> to make sure that I get no notifications of anything between 7 p.m. and 7 a.m.</p> <h2>Save your brainpower</h2> <p>I find that my mind is sharpest and I do my best work in the morning, and yet I used to start each work day with email—a task that arguably requires the least of my creativity and mental acuity. So now I set aside the first hour of my day for something challenging. I often write these columns during that time slot. Or tackle a particularly gnarly IA or design problem. But email? Email can wait till 10 a.m.</p> <h2>It’s all in the timing</h2> <p>And when you’ve finished that batch of email responses and are ready to return to your work? Close that email client, friend! Don’t open it back up until you’re ready to dedicate your attention to it again. Otherwise, it’s just a distraction. I find it useful to set times for checking my email throughout the day, for instance 10 a.m., 1:30 p.m., and 4 p.m.</p> <h2>Inaction leads to rumination</h2> <p>Ever check your email while you only have a few seconds or minutes to spare? You get some troublesome message, but don’t really have time to read through it carefully or respond. Then you spend the next few hours with that static buzzing around your brain, distracting from whatever it is you’re working on. I now have a simple rule: if I don’t have time to sit down and directly address whatever messages may be waiting for me, I don’t check my email. Making reading and responding to email a dedicated task keeps you out of that vague cognitive limbo, and can reduce the anxiety of opening the inbox.</p> <h2>Expectations for the medium</h2> <p>Remember: email is asynchronous communication. By its nature, it encourages a lag in response, and everyone expects that. If there’s a real emergency, someone will doubtless pick up a phone. Email can wait a few hours, even a day. The world won’t explode, and you won’t get fired. Give those messages their proper place in the hierarchy of your day.</p> <h2>And on and on</h2> <p>There are doubtless many other ways to keep the great beast email under control. These are the ones that have helped me hold on to my sanity and reduce email-induced anxiety. These little strategies make me happier and more productive every day.</p> <p>How about you? What are your email troubles? What have you tried that’s worked? Get in those comments, people, and share what you’ve learned. Something tells me we could all use a little help in this department.</p><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/0NszOq5XC_g" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)
9. Apr 2014
Easy Color Contrast Testing
<p>We have plenty of considerations to design for when crafting websites. Web accessibility is not a new design consideration, but is still very important, no matter the size or speed of device we’re testing on. The <a href="http://www.w3.org/TR/WCAG20/">Web Content Accessibility Guidelines</a> (WCAG) <a href="http://www.w3.org/TR/WCAG20/#visual-audio-contrast">tells us</a> our content should be distinguishable and requires we “[m]ake it easier for users to see and hear content including separating foreground from background.”</p> <p><a href="http://www.w3.org/WAI/WCAG20/quickref/#qr-visual-audio-contrast-contrast">We know</a> that our color contrast ratio should be 3:1 for non-decorative text, sized larger than 18 point or larger than 14 point if bold. Text smaller than that should meet a contrast ratio of at least 4.5:1.</p> <p>Maybe you have amazing eyeballs that can help you recognize contrast levels. If, like me, you do not have magical corneal calculators, then you probably have utilized one of the tools out there to check contrast, such as: <a href="http://webaim.org/resources/contrastchecker/">WebAIM’s color contrast checker</a>, <a href="http://www.snook.ca/technical/colour_contrast/colour.html">Snook’s contrast slider</a>, <a href="http://www.checkmycolours.com/">Check my colors URL input check</a>, or a <a href="https://addons.mozilla.org/en-us/firefox/addon/wcag-contrast-checker/">WCAG checker add-on for Firefox</a>.</p> <p>I recently switched to using Chrome’s <a href="https://chrome.google.com/webstore/detail/accessibility-developer-t/fpkknkljclfencbdbgkenhalefipecmb/reviews?hl=en">Accessibility Developer Tools</a> built in contrast checker and I love it. Take a look at the <a href="https://github.com/GoogleChrome/accessibility-developer-tools/wiki/Audit-Rules#-ax_color_01--text-elements-should-have-a-reasonable-contrast-ratio">audits</a> being run by the tools and let’s look at how to begin using it once installed.</p><figure><img src="http://alistapart.com/d/misc-images/ColorContrastStep1-slowed-lq.gif" alt="Animation showing a progression through step one"></figure> <p>Load up the website you’d like to check and bring up the Developer Tools. I’ll pick on myself and use my own site for this example. Once open, click over to the “Audits” tab and make sure “Accessibility” is checked. Click “Run.”</p><figure><img src="http://alistapart.com/d/misc-images/ColorContrastStep2-slower-lq.gif" alt="Animation showing a progression through step two"></figure> <p>Expand the “Text elements should have a reasonable contrast ratio” section. This will show you the HTML of the elements that don’t have sufficient contrast. Identify one to examine further.</p><figure><img src="http://alistapart.com/d/misc-images/ColorContrastStep3-slower-lq.gif" alt="Animation showing a progression through step three"></figure> <p>Select the chosen offender in the browser and inspect it. If you can’t see the contrast values, use the menu to pull up the “Accessibility Properties.” You’ll see the current contrast ratio of your element. You’ll also see a suggested color value pair to match the WCAG AA or AAA recommendation. Select the swatch to the right of those values to see the preview of that change. In this case, we’ll see what grey we’d have to adjust our background to in order to keep the white text.</p><figure><img src="http://alistapart.com/d/misc-images/ColorContrastStep4-slower-lq.gif" alt="Animation showing a progression through step four"></figure> <p>As you can see in this second example, I could make the date text darker to meet the guidelines, which is very helpful in making a fast change.</p> <p>When it’s this quick and simple to check contrast, there’s no reason not to add this accessibility test into our workflow.</p><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/ybfw4K66iZ4" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)
10. Apr 2014
W3C Track at WWW2014 in Seoul
At this year&#8217;s 23rd International World Wide Web Conference (WWW2014), W3C organizes W3C tutorial and W3C tracks where conference participants are invited to learn from, meet and discuss with our team of experts. With the conference located in Korea, the W3C track sessions also cater specifically for the Korean industry. The presentations and discussions are [&#8230;][mehr] (Quelle: W3C News)
8. Apr 2014
MBUI: Abstract User Interface Models, and Task Models Notes Published
The Model-Based User Interfaces Working Group has published two Group Notes today: MBUI &#8211; Abstract User Interface Models. Model-Based User Interface Design facilitates interchange of designs through a layered approach that separates out different levels of abstraction in user interface design. This document covers the specification of Abstract User Interface Models, by defining its semantics [&#8230;][mehr] (Quelle: W3C News)
8. Apr 2014
The Heartbleed Bug (or: You Should Consider SSL Unsafe for a While)
<p>If you run a server that uses SSL and the OpenSSL library, you need to update it. If you regularly visit a site that uses SSL (and I can&#8217;t imagine you don&#8217;t), you should try to limit your visits today. Once the dust has settled, we should all change our passwords. Pretty much <em>everywhere.</em></p> <p>In short, yesterday the OpenSSL Project <a href="http://www.openssl.org/news/secadv_20140407.txt">released an update</a> that addresses a vulnerability in the OpenSSL library. Officially named CVE-2014-0160, the Heartbleed bug has been around—and un-identified—for a long time. It&#8217;s not known if the vulnerability has been exploited, but it&#8217;s theoretically possible that someone has been snooping on transmissions we thought were secure. It&#8217;s <em>very likely</em> that bad guys are snooping on un-patched servers <em>now</em>, so be careful which services you log in to today.</p> <p>Visit <a href="http://heartbleed.com">Heartbleed.com</a> for a lot more information, and anyone running a server should consider these words from Cody Sorland:</p> <figure class="tweet"> <blockquote class="twitter-tweet" lang="en"><p>Ubuntu servers running nginx/SSL?&#10;&#10;sudo apt-get update &amp;&amp; sudo apt-get dist-upgrade&#10;sudo restart nginx&#10;&#10;Do it now. <a href="https://twitter.com/search?q=%23heartbleed&amp;src=hash">#heartbleed</a></p>&mdash; Cody Soyland (@codysoyland) <a href="https://twitter.com/codysoyland/statuses/453579357026406401">April 8, 2014</a></blockquote> <script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script> </figure> <p>Be careful out there.</p><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/oDtP5Lvn1WU" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)
8. Apr 2014
Creating Style Guides
<p>Several years ago, I was working on a large, complex application. It was a bit of a legacy project: many different designers and front-end developers had come and gone, each appending a new portion to the sprawling application. By the time I arrived, the CSS was huge, the styles were varied, and it took a lot of effort to find out if anything was reusable.</p> <p>During all this, I discovered style guides—a way to control markup and CSS so neither veered out of control or ballooned. In jobs since, I&#8217;ve seen firsthand how style guides save development time, make communication regarding your front end smoother, and keep both code and design consistent throughout the site. It has been a revelation, and in this article, I want to show you how to build and maintain them, too. </p> <h2>What is a style guide?</h2><p> </p> <p>To me, a style guide is a living document of code, which details all the various elements and coded modules of your site or application. Beyond its use in consolidating the front-end code, it also documents the visual language, such as header styles and color palettes, used to create the site. This way, it’s a one-stop place for the entire team—from product owners and producers to designers and developers—to reference when discussing site changes and iterations. Several companies have even put their guides online; Starbucks is the most well known of the bunch, but others exist. </p> <figure> <img src="http://d.alistapart.com/393/creating-style-guides/starbucks.png" alt="" /> <figcaption>Starbucks style guide.</figcaption> </figure><p> </p> <p>(I should also mention that what I call a <i>style guide</i>, some people call a <i>pattern library</i>. Many of the guides I reference use the term <i>style guide</i>, but <i>pattern library</i> is gaining in popularity.)</p> <p>When I started working at Editorially, one of the first things I did was tackle the style guide. Creating the guide was probably the most useful thing I’ve ever done when settling into a new job: it forced me to go through <i>every single line of CSS</i> and read it, digest it, understand how it was used, and then document it for my own, and the team’s, future reference. In addition to catching inconsistencies and errors by poring through the CSS, if I didn’t understand how certain pieces of code were being used, I annotated the guide with questions (which my teammates graciously answered).</p> <h2>Why should I use a style guide?</h2> <p>As your team grows and changes over time, your style guide will help you in several ways. First, creating your guide will take some time up front, but I’ve found that this pays off with faster build times for new sections and pages, because anyone joining an ongoing project can refer to the guide for the exact styles to use.</p> <figure> <img src="http://d.alistapart.com/393/creating-style-guides/south-tees-panel.png" alt="" /> <figcaption>Imagine starting a page build with information like this from the South Tees Hospital guide; a donation box would be done in seconds.</figcaption> </figure> <p>Second, a guide allows us to standardize the CSS, keeping it small and quick to load. By using the guide as an inventory of modules and code, both designers and developers can quickly see if new designs deviate from established standards, and decide as a team if it’s worth expanding the codebase or if something already written is easily extended. When you have no guide, this is impossible, which in my experience usually means that new styles are written—resulting in bloated CSS.</p> <p>Third, design consistency is easier to maintain, as the designer can look in one place to reference the site’s components and ensure a cohesive look and feel throughout. This is especially helpful on larger teams and at enterprise-level companies where you may have an entire team of designers working on the site. And when design consistency is maintained, the codebase is also kept smaller.</p> <figure> <img src="http://d.alistapart.com/393/creating-style-guides/yelp-buttons.png" alt="" /> <figcaption>Yelp clearly states how buttons are used, keeping button styles consistent across the site.</figcaption> </figure> <p>Fourth, communication becomes clearer as well. When I built out pages in a large-scale project and passed them off to the designer, she used the language of the various classes in the guide to ask for changes. This meant that we didn’t have any confusion on either of our parts as we sped through revisions. It also gave the entire team a shared vocabulary, like the names of modules, to use in talking about the designs once they were coded.</p> <p>The final benefit I’ve found is that you can use your guide to do a quick QA pass. The guide may not be identical to the pages you eventually build out, but it can point out issues you may have in various browsers. By tackling these early on, you&#8217;ll avoid them in later testing.</p> <h2>Steps to build out your guide</h2> <p>Below, I&#8217;ll take you through starting your own guide, based on my first few weeks at Editorially. (Because when I work on a project without a guide, I&#8217;m soon jonesing to make one—just ask my colleagues).</p> <h3>Assemble your site’s basics</h3> <p>Start your guide with some of your site’s foundations. A foundational element may include the color palette, your grid layout system, or the basic type styles for headers and body text: whatever you feel are the very basic elements to create a page. For Editorially, the most foundational part of our site was the color guide, so I began with that and went from there. I created an HTML document with the markup, linking to the application CSS, so any CSS changes would be automatically reflected in the style guide.</p> <p>When you look at the style guide created by Yelp, you can see how it starts with the basics: typography, grid, and colors, adding more patterns as it goes along.</p> <figure> <img src="http://d.alistapart.com/393/creating-style-guides/yelp.png" alt="" /> <figcaption>Yelp.</figcaption> </figure> <h3>Add in more patterns</h3> <p>A pattern is any self-contained set of markup and styles to make some of your site’s basic objects, like a call-out box used repeatedly, buttons, or the way you lay out a list of links horizontally. At Editorially I documented all the variations possible of button and link styles. So go ahead and add the exact markup you need for each element to your guide.</p> <p>For example, for a button in the Editorially guide, I simply put <code>&lt;label for=&quot;btn&quot; class=&quot;btn&quot; href=&quot;#&quot;&gt;.btn &lt;input type=&quot;submit&quot; name=&quot;btn&quot; value=&quot;.btn&quot; /&gt;&lt;/label&gt;</code>. And because we link to the same CSS as the application does, the CSS shows correctly in the style guide. Should we change the <code>.btn</code> style, the style guide would change as well.</p> <p>Keep going through your site and add in patterns as you see them; you may use particular layouts over and over, or a media-object pattern, or a vertical list pattern. Below is an another example from South Tees Hospital, showing some of their patterns for what they call feature blocks. Look for similar things on your own site to document in your guide.</p> <figure> <img src="http://d.alistapart.com/393/creating-style-guides/southtees.png" alt="" /> <figcaption>South Tees Hospital.</figcaption> </figure> <p>This is also a good time to ask your team what else would be helpful to have in the style guide. Share it, let them take a look, and hopefully they’ll help you fill out all the patterns and modules needed. Don’t forget to have <em>the entire team</em> help you round it out, as it’s a resource for everyone.</p> <h3>Document interactivity</h3> <p>If possible, add the bits of interactivity that your site uses, such as dropdowns, modals, or tooltips, which are small hovers with helpful text that gives the user more information. This lets your team see not just the static versions of these things, but the animations as well. So when you’re looking at the guide and hover over or click on items, they’ll actually act as they would on your site.</p> <figure> <img src="http://d.alistapart.com/393/creating-style-guides/ed-tooltips.png" alt="" /> <figcaption>Tooltips in the Editorially guide.</figcaption> </figure> <h3>Make maintenance easy</h3> <p>If you have to do extra work to update your style guide when making changes to your look and feel, the likelihood of it staying up to date is pretty slim. I’ve said it a few times now, but that’s why we linked the Editorially guide to the same CSS as the application—that way, we didn&#8217;t have to manually update the guide ourselves. It can be difficult to make updating the guide a priority, but maintenance is critical. Depending on how quickly you iterate on your site or application, you should check up on the guide as a regular task, whether it’s weekly or monthly. When you’re making changes to your site, update your style guide as part of the workflow.</p> <h3>Iterate your guide</h3> <p>Once you have the bulk of your site’s or application’s components listed in your guide, you’ve got a wealth of tools to make it even more handy. As I built out the style guide for Editorially, a colleague pointed out the fantastic tool by Filament Group, <a href="https://github.com/filamentgroup/X-rayHTML">X-rayHTML</a>, which is a small JavaScript library to help you build out documentation. X-rayHTML takes the styled objects on your page and generates a nicely formatted code block below them, without any further code from you. You can also add <a href="http://prismjs.com">prism.js</a> for syntax highlighting, which color-codes the code for greater readability.</p> <figure> <img src="http://d.alistapart.com/393/creating-style-guides/styleguide-06-Aug-messages.png" alt="" /> <figcaption>A look at the Editorially style guide with X-rayHTML at work.</figcaption> </figure> <p>If you&#8217;re interested in automation, there are other tools that can make creating the guide even smoother. Two of these include <a href="https://github.com/kneath/kss">KSS</a> and <a href="http://trulia.github.io/hologram/">Hologram</a>. Both tools use things like commenting or YAML inside your stylesheets in combination with something like Ruby to automatically generate your style guide. It would take some work to go back and retrofit your stylesheets with the appropriate comments or YAML for these approaches, but you&#8217;d save time in the long run, as these tools make maintenance much, much easier. In addition, <cite>A List Apart</cite> has put their pattern library on GitHub and featured a <a href="http://alistapart.com/blog/post/getting-started-with-pattern-libraries">blog post</a> on its creation, demonstrating yet another method of building a style guide. The possibilities of what you can do are far greater than what I’ve outlined here; you might poke around to see what may be most helpful for you and your team. </p> <h2>Using the guide</h2> <p>Phew. You’ve done all this work and you’ve created this guide, so now what? How do you get people to use it? The first step is to talk about it. If a new team member comes on board, introduce her to the guide as a way of orienting her with the site, since the guide encompasses so much of both the visual and code languages of your front end.</p> <p>As long as you’re iterating on a site or application, your style guide will never truly be finished. But having something documented early on, and showing it to teammates and getting their feedback, is a huge help. Involving the whole team in building the guide also makes it feel more like the <em>team’s</em> guide—and gets everyone invested in maintaining and using it on a regular basis.</p> <p>We’ve made the Editorially guide available as both a public repo on <a href="https://github.com/Editorially/styleguide">GitHub</a> and <a href="https://editorially.github.io/styleguide">online</a>. This was very much a work in progress and an internal team document, so we’ve also got notes, patterns, and a lot of messiness. But the reason for showing it is to reinforce the fact that a style guide doesn’t have to look perfect to be useful. Despite the mess, all of this was incredibly helpful for me and other team members as we continued to work on the application.</p> <p>So, are you convinced? Are you wishing you had a style guide for your site or application? It will be well worth the effort: make the time, get your team on board, start the build—and be rewarded with a document that speeds up the discussion and development of your site.</p><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/7XGdJPs-WfA" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)
8. Apr 2014
The Z-Axis: Designing for the Future
<p>For years we’ve thought about the web as a two-dimensional space filled with pages that sit side by side on a flat, infinite plane. But as the devices we design for take on an increasingly diverse array of shapes and sizes, we should embrace new ways of designing up and down. By building interfaces using a system of layers, we solve tricky design problems, flexibly adapt to a variety of screens, and create new patterns that will point the way to future interactions.</p> <p>In geometric terms, the z-axis is the vertex that measures space above and below the x- and y-axes. Translation for those of us who napped through geometry: it’s how we describe panels and layers that sit above or below one another.</p> <figure> <img src="http://d.alistapart.com/393/the-z-axis-designing-for-the-future/layers.jpg" alt="" /> </figure> <p>Designing on the z-axis simply means incorporating three-dimensional physics—as represented by the z-axis—into our interface designs. Not the faux-depth of skeuomorphic text shadows and button highlights, but an interface made of components that exist on distinct layers and move independently of one another.</p> <p>As <a href="http://stuffandnonsense.co.uk/blog/about/walls_come_tumbling_down_presentation_slides_and_transcript/">Andy Clarke has noted</a>, the page is an outdated metaphor for what we’re designing today. Unlike the permanence of ink on paper, a website is a series of dynamic views that can occur in many combinations. Applications require us to consider numerous happy and unhappy paths, and even static marketing sites need reusable design components that can adapt to different content needs.</p> <p>By using the z-axis to place interface elements above or below one another, we can create better design systems that are more flexible and intuitive to use.</p> <h2>Using the z-axis to solve design problems</h2> <p>While juggling the constraints of making an interface work across many different screens, I often encounter the same problems. <i>Where do I put this? How do I make this effective for touchscreens? What can I show right away, and what can I hide?</i></p> <p>The answers aren’t easy, but fortunately we can count on the z-axis to be there when extra pixels aren’t. Got an options panel that just won’t fit? Trying to add filters but the excess UI clutter doesn’t seem worth it? When you’re running out of space and searching for a clever solution, remembering that you have three dimensions to design in can save the day.</p> <p>Creating an interface that seamlessly works across the z-axis requires two important elements: layers and transitions.</p> <h2>1. Layers</h2> <p>Incorporating layers is the key to designing on the z-axis, since layers are the way we differentiate levels above and below one another. A layer might contain a single UI element that sits above the rest of the view, or it might be a full screen that appears and disappears as necessary. However you incorporate layers, each should have a purpose—a reason it exists—and be used consistently throughout your site in a way that helps users better understand your design.</p> <p>A panel that covers up the entire interface, for example, should be one of the most important functions on a site. On the other hand, an option in a secret panel that slides out from behind another object should relate to whatever sits above it, but be less important.</p> <h3>Menus</h3> <p>Generally speaking, the higher something sits on the z-axis, the more important it is. Primary navigation menus are usually placed on a higher level than other elements; they might pop over the rest of the view, they might stick to the top of the screen, or they might be accessed by zooming out to a larger menu presentation.</p> <figure> <video width="696" height="391" controls> <source src="http://d.alistapart.com/393/the-z-axis-designing-for-the-future/teehanlax.mp4" type="video/mp4"> <source src="http://d.alistapart.com/393/the-z-axis-designing-for-the-future/teehanlax.webmhd.webm" type="video/webm"> </video> </figure> <p>Teehan + Lax takes this to the extreme with the menu overlay on its website. It’s more than a popover; it’s like a page takeover. <em>Look at our menu!</em> it shouts. The sliding animation combined with a new screen layer grabs the user’s attention, while huge font sizes and a larger-than-usual menu of links deliver more content than a typical primary nav bar and (probably) justify the need for a separate layer.</p> <p>Do I love this bold menu presentation? Yes. Do I think it’s a best practice we should incorporate into every site we build? No way. Not every site needs that much dramatic flair.</p> <p>But I love how this inspires me to think about a menu as a piece of content in and of itself, and not just more interface cruft. Teehan + Lax highlights the act of presenting a menu to the user and how it can be more than popping up or sliding over from the left—it can be an opportunity for surprise and delight.</p> <h3>Action buttons</h3> <p>Primary action buttons, such as checking in or adding a new post, are often placed above other elements on the z-axis. It’s easy to tell what an app thinks is its most important feature when it’s sitting on top of everything else. Just take a look at Facebook’s chat heads.</p> <figure> <video width="450" height="798" controls> <source src="http://d.alistapart.com/393/the-z-axis-designing-for-the-future/facebook.mp4" type="video/mp4"> <source src="http://d.alistapart.com/393/the-z-axis-designing-for-the-future/facebook.webmhd.webm" type="video/webm"> </video> </figure> <p>Right now, Facebook clearly thinks that messaging is its most important feature. (If you’re unconvinced, Facebook also has a separate Messaging app, <em>and</em> recently paid $19 billion for <a href="http://www.whatsapp.com/">What’s App</a>.) Since layers allow elements to remain fixed in one place while everything else moves around them, floating action buttons are an easy way to make them more prominent without taking up a lot of valuable screen real estate.</p> <p>The z-axis gives Facebook an easy way to keep messaging front and center, and even if I don’t like tapping on the disembodied faces of my friends and family, <a href="http://allfacebook.com/zuckerberg-techcrunch-disrupt-sf-2013_b124924">it seems to be working</a>. For clients who want a button to “pop” a bit more, using the z-axis to give it its own layer is one of the more elegant possibilities.</p> <h3>Storytelling</h3> <p>Objects on different layers of the z-axis can move at asynchronous speeds during scrolling. This effect—usually called <em>parallax</em>—was pioneered in video games, but it’s become quite popular in interactive design. When objects move at different speeds, it creates the appearance of depth and simulates the passing of time, making parallax a powerful tool for online storytelling.</p> <figure> <video width="696" height="443" controls> <source src="http://d.alistapart.com/393/the-z-axis-designing-for-the-future/letsfreecongress.mp4" type="video/mp4"> <source src="http://d.alistapart.com/393/the-z-axis-designing-for-the-future/letsfreecongress.webmhd.webm" type="video/webm"> </video> </figure> <p>Superfluous use of parallax as a trendy eye-catcher has been rightfully criticized, but the ability to move layers independently of one another allows us to animate stories on the web in a way that hasn’t been as effective without the use of video. Sites like <a href="http://letsfreecongress.org/">Let’s Free Congress</a> and <a href="http://inception-explained.com/">Inception Explained</a> use asynchronous scrolling to turn what could have been flat infographics into visual narratives. By breaking elements apart using layers, each thread can unfold at its own speed while the user controls the pace of the action.</p> <p>Web designers have always worked within the confines of flat, pixel-based screens, forcing complex interactions onto two visual axes. Layers on flat screens are a hack, but an important one; they’re the first step toward the true multidimensional interactions that are only a few years away. By creating layered patterns in our interfaces now, we help prepare users—and ourselves—for what’s ahead.</p> <h2>2. Transitions</h2> <p>When you use layers in an interface design, it’s important to include animations that smooth the transitions between them. Animated transitions serve several important functions: they help soften what could otherwise be a jarring moment of change, they describe where you came from and where you’ve arrived, and they provide cues about how information on the new layer relates to everything else.</p> <h3>Sliding</h3> <p>Sliding is one of the most common animated transitions because it’s relatively easy to execute and simple to understand. Navigation menus, hidden panels—just slide them out quickly whenever you need them, right? But like anything “simple,” sliding requires more care than you might expect.</p> <figure> <video width="450" height="798" controls> <source src="http://d.alistapart.com/393/the-z-axis-designing-for-the-future/gmail.mp4" type="video/mp4"> <source src="http://d.alistapart.com/393/the-z-axis-designing-for-the-future/gmail.webmhd.webm" type="video/webm"> </video> </figure> <p>The ubiquitous left-hand menu, used in many mobile apps including Gmail, is a perfect example. When activated, Gmail’s menu doesn’t slide anywhere; it’s actually the main window that slides to the right, revealing the menu on the left underneath your inbox.</p> <p>The distinction is important, because the ability to see the first few words of each subject line keeps the inbox functional even when the menu is engaged; without that persistence, there’s little point to the inbox remaining there at all. Mobile websites that seek to mimic this interaction should take note—sliding a left menu over the top of a webpage usually feels clunky and intrusive compared to sliding the main view over instead.</p> <figure> <video width="450" height="798" controls> <source src="http://d.alistapart.com/393/the-z-axis-designing-for-the-future/tweetlist.mp4" type="video/mp4"> <source src="http://d.alistapart.com/393/the-z-axis-designing-for-the-future/tweetlist.webmhd.webm" type="video/webm"> </video> </figure> <p>You can also slide existing elements out of view to reveal hidden panels. Tweetlist slides the keyboard down to show additional tweet options like geotagging or attaching a photo. It’s a clever way to display secondary features that don’t need to be visible at all times, and using the back of the keyboard reinforces the relationship between these options and sending a tweet.</p> <h3>Zooming</h3> <p>Zoom animation has been around for a while, but its frequent use in Apple’s iOS 7 has increased both its popularity and its infamy. Some people have said the zooming used throughout the operating system—particularly when opening and closing apps—makes them nauseous. While this may be the case, it’s worth understanding the different ways we can use zooming to transition from one layer to another, and why some types of zoom may be more stomach-churning than others.</p> <p>Enlarging or shrinking single objects has been a common animation in the Apple universe since the release of Mac OS X and the introduction of the dock. It naturally found its way into the mobile world on the iPhone, and users quickly grew accustomed to tapping a photo and zooming into it to see more detail.</p> <p>In the case of photos, zooming is a simple illusion created by enlarging the image. Everything around the photo remains in place; only the photo itself moves.</p> <p>The zoom effect used in iOS 7 is more complex. It works by moving the “camera” in and out as you open and close apps so that everything on the screen changes, not just one object. When you close an app, for example, the app window shrinks down into its icon on the homescreen. Watch the background behind the window and you’ll see all the other homescreen objects zoom back into the view as well.</p> <figure> <video width="450" height="798" controls> <source src="http://d.alistapart.com/393/the-z-axis-designing-for-the-future/ios-close.mp4" type="video/mp4"> <source src="http://d.alistapart.com/393/the-z-axis-designing-for-the-future/ios-close.webmhd.webm" type="video/webm"> </video> </figure> <p>This key difference—zooming the camera rather than a single element—creates a much more immersive illusion. It shifts the viewer’s perspective to a new level on the z-axis. That simulated perspective-shift adds to the wow factor by introducing an element of super-realism: it mimics real-world physics, while producing an effect that would be impossible in real life. It’s no wonder designers are eager to take advantage of the possibilities it offers, in spite of <a href="http://www.livescience.com/40013-why-ios7-motion-sickness.html">the potential side-effects</a>.</p> <figure> <video width="696" height="522" controls> <source src="http://d.alistapart.com/393/the-z-axis-designing-for-the-future/creativedash-menu.mp4" type="video/mp4"> <source src="http://d.alistapart.com/393/the-z-axis-designing-for-the-future/creativedash-menu.webmhd.webm" type="video/webm"> </video> </figure> <p>This design experiment from Creative Dash shows how zooming the camera all the way out allows us to use the liminal space around a window. Our canvas is both deep and wide, and this takes advantage of both—though the extreme zoom depth would probably make quite a few users feel sick.</p> <figure> <video width="450" height="646" controls> <source src="http://d.alistapart.com/393/the-z-axis-designing-for-the-future/foursquare.mp4" type="video/mp4"> <source src="http://d.alistapart.com/393/the-z-axis-designing-for-the-future/foursquare.webmhd.webm" type="video/webm"> </video> </figure> <p>Foursquare has used a much more subtle version of zooming the camera to reveal map details. You don’t travel very far forward, but the zoom-in reinforces the notion that you’re going to a deeper level of information.</p> <p>Whether you apply zoom to a single object or an entire view, it’s important for the animation to be consistent with the information hierarchy you’re using. When you move the camera out, you should be at a higher level, while zooming in should provide more detail.</p> <h3>Other transitions</h3> <p>Sliding and zooming are two of the most common animated transitions used today, but there are other options, including flipping or folding.</p> <p>Three-dimensional objects have two (or more) sides, but most user interfaces are like the moon: they have a “light” side that’s always visible and a “dark” side we never see. Flipping an object over creates a new visual space that’s easy for users to understand. The only downside? Flipping is, well, <em>flipping slow</em>.</p> <figure> <video width="600" height="788" controls> <source src="http://d.alistapart.com/393/the-z-axis-designing-for-the-future/flipboard.mp4" type="video/mp4"> <source src="http://d.alistapart.com/393/the-z-axis-designing-for-the-future/flipboard.webmhd.webm" type="video/webm"> </video> </figure> <p>While flipping is sometimes applied to create a more magazine-like feel, 180 degrees is a big transition; it often feels slow and disruptive. In contexts where speed is critical, the time a flip adds to interactions usually isn’t worth it. That said, if deployed in the right place in the right way, it could be <em>flipping fantastic</em>. Card-based layouts offer plenty of opportunities to flip objects over and reveal additional information.</p> <h2>What comes next</h2> <p>Gesture-based command centers, holographic interfaces—whatever technology lies over the horizon, we’ll be better prepared to adapt our skills if we understand the principles of designing for information, not just visual tricks for laying things out with boxes and color. Just as print designers once learned to take their talents to the web, we need to learn to take our talents beyond the screen—and getting comfortable with the z-axis is a great place to start.</p><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/V30KH9bceLo" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)
7. Apr 2014
Network Performance Testing
<p>It’s extremely likely that sometime in 2014, the <a href="https://www.wolframalpha.com/input/?i=global+internet+users+2014">number of internet users</a> will pass 3 billion. Not surprisingly, the largest areas of growth are developing markets—predominantly Africa and the Asia-Pacific region. These markets are being flooded with mobile devices small and large, fast and slow, smart or otherwise.</p> <p>Connectivity in these regions is of great interest to <a href="http://www.wired.com/2014/02/facebook-plans-conquer-world-slew-low-end-handsets">large tech companies</a> <a href="http://www.google.com/loon/">scrambling for control</a>. Today, however, bandwidth is limited, reliability is questionable, and data plans <a href="http://www.wired.com/2014/02/facebook-plans-conquer-world-slew-low-end-handsets">are small</a>. Even in markets saturated with mobile usage, like the US and much of Europe, connections are often flaky and unreliable.</p> <p>For all those reasons and more, now is the time to test what you build in sub-optimal situations. Thankfully, there are a handful of tools that can help you do just that from the comfort of your high-bandwidth connection and favorite chair, rather than trekking out to a remote field with a Faraday cage.</p> <h2>Slow your roll</h2> <p>If you’re using Grunt or Node.js, there’s a fantastic <a href="https://github.com/tjgq/grunt-throttle">plugin</a> and <a href="https://github.com/tjgq/node-stream-throttle">module</a>, respectively, that can slow your local server’s connection down to a configurable speed. It’s a great start to network performance testing, but it’s fairly one-dimensional.</p> <p><a href="http://www.charlesproxy.com/">Charles</a> is a more robust throttler exposing a lot more control. In addition to amazing tools allowing complete insight to all network requests, Charles can throttle your entire connection, so when enabled, all traffic in and out of your machine is affected. Throttling isn’t the only factor of network performance, however. Latency is a major contributor, and Charles provides control over that aspect, as well.</p> <p>Unfortunately, these tools don’t expose control over the final, and potentially most important aspect of network performance—packet loss. It has always been the toughest aspect to simulate, but if you’re a Mac and/or iOS user, you have access to the <a href="http://nshipster.com/network-link-conditioner/">Network Link Conditioner</a>. With control over upstream and downstream transfer speeds, latency, packet loss, and even DNS delay, Network Link Conditioner is a super-powered system-level tool that will fundamentally change the way you build and test things.</p> <p>Apple provides the Network Link Conditioner through their <a href="https://developer.apple.com/">developer platform</a>, and luckily, it’s accessible through the free developer program, so you don’t have to pay to use it.</p> <p>The Network Link Conditioner comes with some built-in presets to match common connections, such as EDGE, 3G, and DSL. You can even create and save your own presets, allowing you to easily switch between connection levels for fast testing.</p> <p>All of these tools open up a new realm of testing and optimization available to us, and as the world changes, network performance testing becomes more and more important. Have you used any other tools or techniques for testing? Share them below in the comments!</p><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/0qI8oCh1VqU" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)
3. Apr 2014
CSS Line Grid Module Level 1, and CSS Scoping Module Level 1 Drafts Published
The Cascading Style Sheets (CSS) Working Group has published two Working Drafts today: CSS Line Grid Module Level 1. This module contains CSS features for aligning content to a baseline grid. CSS Scoping Module Level 1. This specification defines various scoping/encapsulation mechanisms for CSS, including scoped styles and the @scope rule, Shadow DOM selectors, and [&#8230;][mehr] (Quelle: W3C News)
3. Apr 2014
Review of apps that use network information Note Published
The Web and Mobile Interest Group has published a Group Note of Review of apps that use network information. The web platform currently lacks a means of exposing network-related information to web applications. Network information includes, but is not limited to, the type of network connection currently in use by a device (e.g., cellular, Wi-Fi, [&#8230;][mehr] (Quelle: W3C News)
3. Apr 2014
Laura Kalbag on Freelance Design: Me and My Big Fat Ego
<p>Designers are renowned for having egos. But we’re really not all big-headed prima donnas. It’s just that we can devote so much of our time and care to our work that it becomes entangled with our self-esteem.</p> <p>We’d all love our work to be perfect at the first draft. If we could solve all the potential problems in the project in one pass, without anybody else’s intervention, wouldn’t that make us perfect designers?</p> <p>Our desire for perfection sets us up for that crushing feeling when a client doesn’t love our work the first time. It creates anger, tears, condescension, bitterness: all the ugly things. Our ego doesn’t want us to see ourselves as flawed, so we’re tempted to see the client as foolish in order to have something to blame the flaws in the work on. That’s how this big fat fragile ego can really get in the way of a good client relationship. </p> <p>As with any working relationship, we need to be able to empathize with the other party, and understand the position that they’re coming from with their opinions. Design is nuanced; there’s far more to it than finding that one right way to solve a problem and rejecting all the “wrong” ways. Our ideas and the client’s are as likely to be conflicting as they are to be complementary. We can’t let ego get in the way of compromise.</p> <h2>But ego also gives us confidence</h2> <p>Bravado is ego’s younger, stupider brother. Most days I feel in control of my bravado, but sometimes I’m a little too vocal and critical of the work and actions of others. By showing off my supposed knowledge, I’m trying to mask my insecurity when my work doesn’t feel good enough. That pretty much explains my general attitude at art college and university… (Hey fellow RSAD and Bath Spa students and tutors, I’m sorry you had to put up with that!).</p> <p>But we need that spike of confidence that ego brings. How could we ever share our work if we didn’t think it was any good? We could spend forever revising our ideas until our designs feel “good enough.” We need a little bit of ego so we can share with others.</p> <h2>Let’s not let ego get the better of us</h2> <p>Striving for perfection without the input of others doesn’t just put pressure on our self-esteem, it also restricts the scope for a solution. Every time I get that downhearted feeling over client feedback, I remind myself of other projects where I felt that way. In the end, the solution on those projects was always far stronger after multiple iterations. Feedback from clients brought in valuable constraints and thoughtful ideas from someone who understands their context and goals far better than I do.</p> <p>Sometimes I just need to remind myself that I’m working on a solution <em>with</em> the client: we are both invested. And what we create together may be my adopted project for a few months, but it’s their product to own for many months or years to come.</p><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/-jPftfij5_U" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)
10. Apr 2014
Vocabularies for EmotionML Note Published
The Multimodal Interaction Working Group has published a Group Note of Vocabularies for EmotionML. This document provides a list of emotion vocabularies that can be used with EmotionML to represent emotions and related states. EmotionML provides mechanisms to represent emotions in terms of scientifically valid descriptors: categories, dimensions, appraisals, and action tendencies. Given the lack [&#8230;][mehr] (Quelle: W3C News)
1. Apr 2014
Bringing Responsive Images to Browsers
<p>After almost three years in pursuit of a standardized solution to the problem of responsive images, the Responsive Images Community Group is excited to announce that <a href="http://picture.responsiveimages.org">the <code>picture</code> element</a> is officially coming to a browser near you. Once it lands, we’ll see the trend toward massive, bandwidth-heavy responsive websites begin to slow—and hopefully, reverse—over time.</p> <p>Since starting out, the <a href="http://responsiveimages.org">Responsive Images Community Group</a> has evolved from a handful of passionate developers sending emails to an organization producing detailed specifications alongside WHATWG and HTML WG members and holding summits attended by representatives of all the major browsers. It took us a while to learn all the rules, but we’ve gotten pretty damn good at playing the web standards game.</p> <p>When a company is interested in seeing a feature added to the web platform—something that they feel stands to benefit developers and users alike—they <em>invest</em>. After getting a formal thumbs-up from browser representatives, they’ll contribute their employees’ hours to seeing that feature through—from writing the initial proposal to submitting the code that brings that feature to the browsers. Adobe’s work on the WebKit project is a great example of this process in action.</p> <p>Unfortunately, the last step is the one where we saw ourselves coming up short, for sheer lack of <em>time</em>: submitting the code to land the feature itself. The <code>picture</code> element specification came to life during evenings and weekends, thanks to the efforts of dozens of designers and developers just like you—mailing list conversations took place during desk lunches and Friday nights spent in front of a screen. Blog posts were—and are, in fact—written on crowded commuter trains. We can compete on determination and willingness to put in what time we have, but we just don’t have as much time as a dedicated team of employees. Writing browser patches takes that kind of time.</p> <p>For that reason, the RICG recently <a href="http://igg.me/at/picture">asked the community to sponsor Yoav Weiss’s</a> work on the Blink and WebKit implementations of <code>picture</code>, and together we’ve managed to raise over $10,000 in a little more than a week—enough to cover several months of full-time work on implementation.</p> <p>Having helped write <a href="http://picture.responsiveimages.org">the spec</a> and prototyped <code>picture</code> in Chromium before, Yoav will know many of the the <a href="https://github.com/ResponsiveImagesCG/picture-element/issues?page=1&amp;state=closed">potential gotchas</a> right out of the gate. In the meantime, the Blink team has plenty of work to do on their side, well beyond just <a href="https://codereview.chromium.org/user/Yoav%20Weiss">reviewing Yoav’s code</a>. This is a collaborative effort—adding the new code for the <code>picture</code> element means a lot of changes to Chrome’s internals, and those are best left to the experts on the Blink team. Blink developer <a href="https://twitter.com/cbiesinger">Christian Biesinger</a> is our <a href="https://groups.google.com/a/chromium.org/d/msg/blink-dev/9xIjDTOwbeI/rp2nmtwAeRcJ">point person</a> there, and he’s already working hard to <a href="https://codereview.chromium.org/200923002/">pave the way</a> for <code>picture</code>. Without Christian’s changes throughout the rendering engine, getting <code>picture</code> into the DOM wouldn’t be possible.</p> <p>Alongside Firefox’s upcoming implementation, spearheaded by Mozilla’s <a href="https://twitter.com/marcosc">Marcos Caceres</a>—of RICG fame himself—and <a href="https://twitter.com/Nephyrin">John Schoenick</a>, this will give us coverage in Firefox, Opera, Chrome, and hopefully soon, Safari. Our aim is to have <code>picture</code> land in the majority of common rendering engines within the year.</p> <p>We’re putting a lot on Yoav, I know—but I also know that he’s the right person for the job, and implementation is <a href="https://codereview.chromium.org/search?closed=1&amp;owner=Yoav+Weiss&amp;limit=25">already well underway</a>. Let’s clear the way for him, and together we’ll do something that has never been done before: introduce a feature to the web that was specced, tested, funded, and implemented by the community.</p> <p>Together we have an opportunity to contribute to the web in tremendously meaningful ways: by introducing a feature that could reverse the trend toward massive, resource-heavy responsive sites, and by further changing the role of web developers in web standards from spectators to active participants. We have a chance to provide a solution to our fellow developers and, above all else, provide a better experience to users—not just <em>our</em> users, but all users of the web.</p><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/7_mb5CAEfTk" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)
31. Mar 2014
Content-out Layout: the Resources
<p>The method I outlined in my recent article, &#8220;<a href="http://alistapart.com/article/content-out-layout">Content-out Layout</a>,&#8221; is actually the culmination of quite a few different influences. If you’re interested in a deep dive, I have compiled this list of the most useful thinking on the web about ratios, grids, and fluid design. Enjoy!</p> <h2>Grids</h2> <p>Grids, as we know them, are having to adapt to a fluid canvas. It helps, first, to have a strong understanding of how grids are built, how they’ve traditionally been applied in design, and how they work into responsive design:</p><ul> <li>“<a href="http://markboulton.co.uk/journal/five-simple-steps-to-designing-grid-systems-part-5">Five simple steps to designing grid systems</a>&#8221; by Mark Boulton</li> <li><a href="http://www.thegridsystem.org/">The Grid System</a> created by Anto­nio Caru­sone</li> <li>“<a href="http://alistapart.com/article/fluidgrids">Fluid Grids</a>&#8221; by Ethan Marcotte</li> </ul> <h2>Philosophy of Fluid Layout</h2> <p>As we stop designing pages on the web, and start designing systems to be applied across myriad viewports, it helps to have the right mindset:</p><ul> <li>“<a href="http://www.markboulton.co.uk/journal/anewcanon">A New Canon</a>&#8221; by Mark Boulton</li> <li>“<a href="http://www.markboulton.co.uk/journal/theinbetween">The In-Between</a>&#8221; also by Mark Boulton</li> <li>“<a href="http://alistapart.com/article/the-infinite-grid">The Infinite Grid</a>&#8221; by Chris Armstrong</li> </ul> <h2>Ratios in Nature and Design</h2> <p>Ratios are nothing new in design. The underlying mathematics of natural phenomena have inspired architects, sculptors and humans in general for centuries:</p><ul> <li><a href="http://en.wikipedia.org/wiki/Dynamic_rectangle">Dynamic rectangles</a> on Wikipedia</li> <li>“<a href="http://www.graphicdesignand.com/articles/you-do-the-math">You do the math!</a>&#8221; an interview with Peter Crnokrak</li> <li><a href="http://en.wikipedia.org/wiki/Mathematics_and_architecture">Mathematics and Architecture</a> on Wikipedia</li> </ul> <h2>Ratios in Web Design</h2> <p>Using ratios in web layouts has been explored before. I found these two very different posts inspirational in searching for a way to work with ratios in fluid design:</p><ul> <li>“<a href="http://v4.jasonsantamaria.com/articles/whats-golden/">What’s Golden</a>&#8221; by Jason Santa Maria</li> <li>“<a href="http://24ways.org/2011/composing-the-new-canon/">Composing the New Canon</a>&#8221; by Owen Gregory</li> </ul> <h2>Working with a Scale</h2> <p>Typographers will find working with scales familiar. There is lots of great thinking, here, that can be adapted for layout:</p><ul> <li>“<a href="http://webtypography.net/3.1.1">Don’t compose without a scale</a>&#8221; from <cite>The Elements of Typographic Style Applied to the Web</cite> by Richard Rutter</li> <li>“<a href="http://alistapart.com/article/more-meaningful-typography">More Meaningful Typography</a>&#8221; and <a href="http://modularscale.com">Modular Scale</a> by Tim Brown</li> <li>“<a href="http://typecast.com/blog/a-more-modern-scale-for-web-typography">A More Modern Scale for Web Typography</a>&#8221; by Jason Pamental</li> </ul> <h2>On Harmony in Book Design</h2> <p>I didn’t get the space to touch on this much in my article, but even in a fluid environment, it is ideal to think about the relationship of your content area and the viewport. Book designers have been exploring this idea since the 16th century:</p><ul> <li>“<a href="http://artequalswork.com/posts/form-of-the-book/">The Form of the Book, Digested</a>&#8221; a selection of excerpts from <cite>The Form of the Book</cite>, by Jan Tschichold, which is sadly out of print</li> <li>An excerpt from <cite><a href="http://books.google.co.uk/books?id=_Ri63jEKPfgC&amp;pg=PT12&amp;lpg=PT12&amp;dq=design+asymmetric+grids&amp;source=bl&amp;ots=E38qJ7RZWk&amp;sig=yB6y2xXzwvNa8Kn9YTh0fxpr1dI&amp;hl=en&amp;sa=X&amp;ei=flPlUfX_G4PF7Abz7IHQCg&amp;ved=0CIABEOgBMAw#v=onepage&amp;q=design%20asymmetric%20grids&amp;f=false">Book Design</a></cite>, by Andrew Haslam</li> </ul><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/l7ceeoKSxA0" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)
10. Apr 2014
CSV on the Web Use Cases and Requirements, and Model for Tabular Data and Metadata Published
The CSV on the Web Working Group published two First Public Working Drafts today: The CSV on the Web: Use Cases and Requirements collects use cases that are at the basis of the work of the Working Group. A large percentage of the data published on the Web is tabular data, commonly published as comma [&#8230;][mehr] (Quelle: W3C News)
27. Mar 2014
Rachel Andrew on the Business of Web Dev: Our Enclosed Space
<p>I speak fairly frequently at conferences, and I get to listen to a lot of web designers and developers giving their presentations at these events. I often have my laptop open on my knee to keep an eye on Perch support while I listen. What I hear from designers espousing the latest techniques in my conference circuit world jars with the queries I answer in support. An ever-widening gulf seems to be emerging between the “thought leaders” of the web, and the reality of people doing great work for clients on often extremely limited budgets.</p> <p>At one conference recently, a speaker was reminiscing about how we <em>used to</em> charge for websites by the page. Yet the fact that companies such as SquareSpace are doing so well shows that out there in the world, people <em>do</em> want to build a few web pages. There are many people who <em>do</em> see their sites as being a homepage and a collection of other pages. Perhaps design businesses are charging “by the page” because it makes sense to their customers.</p> <h2>The echo chamber</h2> <p>It is very easy—and I know because I’ve been there—to assume that everyone knows what we know, cares about the things that we care about, or has and wants the same business opportunities we do. We can end up participating in a Twitter echo chamber of people who have experiences similar to ours; who are at a similar stage in their career, and tend to think in a similar way. We attend conferences that have a high ticket price and so attract only those sent by companies—and therefore working in larger teams—or highly successful independent designers and developers.</p> <p>Unless you are sent by a company, speaking at a conference has a cost. If you are someone who charges an hourly rate, you will find that even where a speaker fee is paid, it doesn’t cover the time it takes to prepare the talk, travel, and attend the event. Writing web books is a money earner for only a very few authors. Therefore the voices we hear most frequently are from a particular segment of the industry—those who can afford to spare the time.</p> <p>We can find ourselves with a small segment of our industry speaking to the same small part of our industry. We can quickly forget that there is a much wider industry, and people working outside of our circle often have quite different challenges and concerns. </p> <p>Through supporting Perch, we encounter people who are the web designer for their local area. They operate in a “high touch” world, sitting down with their customers and working out how to best serve their business. They are often charging very little for their services, yet are making a huge difference to the businesses they develop sites for. They are doing great work, if we value that work by the difference it is making to those who benefit from it. Yet I rarely hear this type of work discussed outside of talking with our customers.</p> <p>It is important that best practice is discussed and strategies for working in large teams hammered out. We need thought leaders; we need the people who enjoy debating specifications; we need people who create new tools and ways of working and want to share them with us all. It’s important that there are people who have the time, energy, and space to do this—because people who are just working hard to make a living often don’t have time. The fact that it is perfectly normal on the web for companies to share the things they have learned, even releasing the source code of projects for other people to use, is one of the brilliant things about the world in which we work. It is something we all benefit from. </p> <h2>Like talking to a wall</h2> <p>My fear is that by allowing ourselves to believe that <em>everyone</em> knows certain things, or <em>everyone</em> is working in a certain way, we stop producing great materials for the generalists who create small websites, on their own, with a tiny budget. </p> <p>For example, when I see someone in support struggling with an issue that is front-end development and not related to our software at all, I want to be able to send them to a straightforward CSS or JavaScript resource. I know that at the point they post to our forum that person is stressed because they have to deliver a site by the end of the week. It would be completely unhelpful to preach at them about modern development techniques, or send them to a forum where everyone will tell them they should be using OOCSS techniques, a preprocessor, and installing Grunt. Learning all of these tools and practices may very well improve that person’s workflow, however the point at which they are just trying to get a simple thing done is not the point at which they will be receptive to learning them. Making assumptions such as that everyone is using Sass or everyone understands how to clone a project on Github makes potentially helpful resources useless to the person who just needs to achieve an end result today.</p> <p>When we assume that everyone is working in a similar place to us, we risk masking the important things behind a layer of opinion about the “right” way to do things. We risk creating a barrier to knowledge by bundling accessibility with workflow and solid good practice with personal preferences. It then can all be dismissed as irrelevant in one batch, by a person who builds a website a week for a few hundred dollars for a business who couldn’t afford anything else. That’s no way to encourage the wide adoption of modern methods of building the web.</p><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/q8kOgfPN0Jg" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)
3. Apr 2014
Last Call: CSS Flexible Box Layout Module Level 1
The Cascading Style Sheets (CSS) Working Group has published a Last Call Working Draft of CSS Flexible Box Layout Module Level 1. The specification describes a CSS box model optimized for user interface design. In the flex layout model, the children of a flex container can be laid out in any direction, and can &#8220;flex&#8221; [&#8230;][mehr] (Quelle: W3C News)
3. Apr 2014
Navigation Timing 2 Draft Published
The Web Performance Working Group has published a Working Draft of Navigation Timing 2. This specification defines a unified interface to store and retrieve high resolution performance metric data related to the navigation of a document. The Group also updated the Candidate Recommendation of Resource Timing, which defines an interface for web applications to access [&#8230;][mehr] (Quelle: W3C News)
3. Apr 2014
Last Call: Web Cryptography API
The Web Cryptography Working Group has published a Last Call Working Draft of Web Cryptography API. This JavaScript API performs basic cryptographic operations in web applications, such as hashing, signature generation and verification, and encryption and decryption. Additionally, it describes how applications can generate and/or manage the keying material necessary to perform these operations. Comments [&#8230;][mehr] (Quelle: W3C News)
25. Mar 2014
People Skills for Web Workers
<p>The web touches everything an organization does—marketing to customer service, product development to branding, internal communications to recruitment. This is the era of cross-platform digital services, fast networks, and mobile devices. Sounds like the ideal time to be a person who makes websites.</p> <p>So why do we feel frustrated so often? Why do we experience <a href="http://alistapart.com/article/burnout">burnout</a> or <a href="http://alistapart.com/article/a-moment-to-breathe">depression</a>? What makes it difficult to do work that has meaning, that satisfies us?</p> <p>The problem is that we need to collaborate, but we haven’t focused on developing our people skills.</p> <p>Back in the day, we could get by with technical skills alone. If you could get HTML and CSS to work across browsers, you’d find work, and you might even break new ground. Technical skills still matter, but today making digital services that meet users’ needs also depends on our ability to collaborate across many types of boundaries:</p> <ul> <li>Disciplines like interaction design, content, front-end and backend development, user research, and product management</li> <li>Departments in the organization like marketing, sales, IT, communications, and customer service</li> <li>Channels like websites, native apps, social media, print, and the call center</li> </ul> <h2>People skills are as difficult to learn as technical skills</h2> <p>Think back to when you first learned a technical skill like CSS or JavaScript. How did you feel? If you’re like most people, you felt scared and overwhelmed. And it never ends: however accomplished you are today, <a href="http://alistapart.com/column/never-heard-of-it">there’s always more to learn</a>. That’s why you read sites like <cite>A List Apart</cite>, follow discussions on social media, and attend conferences: to keep learning.</p> <p>The same is true of people skills—often called “soft skills” in business—like coaching, listening, facilitation, and leadership. There’s a myth that you either have these skills or you don’t—which Meri Williams calls “<a href="http://blog.geekmanager.co.uk/2013/11/17/rejecting-the-soft-skills-fairy/">the soft skills fairy</a>.” But that’s like saying, “You can either code JavaScript or you can’t.” You didn’t fall out of bed with technical skills, and the same is true of people skills.</p> <p>Learning people skills is challenging, but when you take the time to develop them, it’ll seem like you’ve gained a superpower—one that allows you to:</p> <ul> <li>find common ground with people who have different perspectives, like when marketing demands its latest campaign go on the homepage, regardless of the user experience;</li> <li>handle stressful situations—like difficult conversations between backend developers and content editors who need to use the CMS—with grace and compassion;</li> <li>feel confident about your contributions without criticizing others, e.g., when your product team implements an agile process and you’re concerned that your area of expertise might be sidelined.</li> </ul> <p>Behind each of these scenarios are collaboration problems. Let’s talk about four of the most common ones, and the people skills that can help with each.</p> <ol> <li>You don’t get appreciation for your contributions.</li> <li>You struggle to keep up and know everything.</li> <li>You experience conflict with people who are scared of change.</li> <li>Your organization can’t adapt.</li> </ol> <h2>1. You don&#8217;t get appreciation for your contributions</h2> <figure class="quote"> <blockquote>Judgments of others are alienated expressions of our own unmet needs.</blockquote> <figcaption>Marshall B. Rosenberg, <cite><a href="http://www.amazon.com/Nonviolent-Communication-A-Language-Life/dp/1892005034">Nonviolent Communication: A Language of Life</a></cite></figcaption> </figure> <p>Although it’s counterintuitive, the first person you need to look out for when you want to collaborate is yourself. Everyone needs appreciation for their contributions. When that need isn’t met, we feel frustrated or angry, and we start judging others.</p> <p>For example, imagine you’re presenting a prototype of a mobile application to your team. They seem to object, saying that the app would take too long to develop and isn’t “intuitive.” Your defensive instinct might be to tell them that they’re wrong—this is the way we “should” do it—while feeling frustrated because they’re rejecting your work. Notice the judgment? These judgmental behaviors lead to conflict, which prevents collaboration.</p> <h3>Learn to communicate without judgment</h3> <p>You can begin to spot this behavior by looking for language that implies people are “bad” or doing things “wrong,” or that tells people what they “should” do. You may also notice self-judgment, where you tell yourself you’re wrong, or that your work sucks. The jargon term is “negative self-talk” and we all do it.</p> <p>Rosenberg’s <a href="http://en.wikipedia.org/wiki/Nonviolent_Communication">Nonviolent Communication</a> (NVC) model helps us identify these moments before they lead to conflict by focusing on four steps: observations, feelings, needs, and requests. You can observe that your colleagues offered “feedback” (rather than “criticism,” which contains a judgment). Then you can identify your feeling, in this case frustration. (If you’re stuck on “angry” or “upset,” try the <a href="https://www.cnvc.org/Training/feelings-inventory">NVC list of feelings</a> to get more specific.) Next, figure out what you need: is it respect, appreciation, contribution, autonomy, growth? You may have several unmet needs: try <a href="https://www.cnvc.org/Training/needs-inventory">this list</a> for ideas.</p> <p>Finally, put it all together into a request. You could say, “You shared your feedback about the prototype. I’m feeling frustrated because I need appreciation for my contribution. Would you be willing to share areas where the prototype meets user needs, as well as those where it may not?” Notice that you’re taking responsibility for your own feelings and needs.</p> <p>NVC is difficult to pull off in the heat of the moment, so you need to practice. Get started by <a href="http://www.amazon.com/Nonviolent-Communication-A-Language-Life/dp/1892005034">reading Rosenberg’s book</a>.</p> <h2>2. You struggle to keep up and know everything</h2> <p>When we collaborate, everyone shares control and no one knows exactly where they’re going. It’s uncomfortable because we’re leaving what we know and stepping into discovery. We need trust to tolerate this discomfort together. When we aren’t confident about our expertise—when we feel insecure—we can’t build trust, so we find collaboration difficult.</p> <p>Your colleagues and clients look to you as an expert: someone who can tell them how to do digital “properly.” But technology changes fast. New mobile platforms, new ways of working (Mobile First, Content First, Lean UX), and new technologies (Sass, responsive images, server-side JavaScript) appear all the time.</p> <p>People want the “right” answer, the solution with proven return on investment, the fail-safe plan. Whether it’s a fixed budget, the “right” CMS for the corporate website, or the “best” mix of mobile platforms, people are asking you for certainty. You don’t have all the answers, so you can’t offer certainty without faking it. And you’re afraid that your colleagues won’t accept you unless you pretend to know everything. You feel insecure because you have an unmet need for acceptance, and it prevents you from building the trust you need with your team or client.</p> <h3>Learn to coach yourself and others</h3> <p>Instead of feeling insecure, you can choose to tell yourself that it’s okay not to have all the answers, and use coaching techniques to identify both your strengths and the areas you would like to develop. You can also learn to coach your colleagues. This will help you meet your need for acceptance because you’ll be providing real value to them, instead of pretending to have all the answers.</p> <p>Coaching others means acknowledging that we we can’t “fix” other people’s problems and instead supporting them to make decisions about their own development. This allows us to get real about skills and growth while also being kind.</p> <p>Get started with the <a href="http://en.wikipedia.org/wiki/GROW_model">GROW model</a>, which is a structured conversation based on a set of questions. Notice that the coach doesn’t offer their own ideas or fixes:</p> <ul> <li><i>Goal</i>: Where do you want to be, and how will you know when you get there?</li> <li><i>Reality</i>: Where are you now? How far away is the goal, and what are the challenges?</li> <li><i>Options</i>: How could you overcome these challenges to get nearer to the goal?</li> <li><i>Way forward</i>: What action steps will you take to carry out your preferred option?</li> </ul> <p>You can both learn to coach other people and ask for coaching yourself. For yourself, this means being honest about the areas you want to develop and being brave enough to ask for help. You can even buddy up with a colleague and coach each other using this tool.</p> <h2>3. You experience conflict with people who are scared of change</h2> <p>The internet is a symbol of disruption for many people: marketers are nervous of the shift from mass media to direct customer relationships, salespeople worry that websites make their skills obsolete, and publishers’ entire business models are threatened by the decline of print. We want to do digital work we can be proud of, but we’re on the front line of this disruption—a front line that’s thick with unmet needs and the feelings they create: anger, frustration, and fear.</p> <p>Our culture makes things worse. We try to avoid conflict, as if ignoring it will make it go away. We tiptoe around sensitive issues or send long emails that we hope nobody will read instead of engaging face-to-face. We agree to a spec we know will never work, because it seems easier than risking an honest conversation. We choose to avoid “difficult conversations” instead of doing what the project needs.</p> <h3>Learn to turn conflict into collaboration</h3> <p>Imagine a conflict situation: the IT director won’t approve the budget for your new cloud-based web server. Ask yourself what the other person is afraid of. What don’t they know? Why do they perceive the situation differently? To turn conflict into collaboration, you need to listen with empathy.</p> <p>Listening is a superpower. When you listen to someone with empathy, you meet their need for understanding, which makes them more likely to listen to <em>you</em>. When you see shared humanity—that is, when you realize the person you’re talking to is a human being—you can always find common ground.</p> <p>Web designers talk about having empathy for users. To overcome conflict, we need to have empathy for our clients and colleagues, too. When our needs for trust and respect are not met, we feel tense, as if we’re about to fight. That makes it difficult to listen with empathy. We can get better with practice. To get started, check out the <a href="http://en.wikipedia.org/wiki/Active_listening">active listening technique</a>, where you listen, reflect what you heard the other person say, and clarify your understanding.</p> <h2>4. Your organization can&#8217;t adapt</h2> <p>Our organizations are structured like industrial factories, with each department separated and optimized, working in isolation. Often digital work seems like diplomacy, as you try to get departments to collaborate instead of fighting over turf. If the team designing the mobile application won’t talk to the desktop website team, what hope do you have? You can’t change your organization’s structure on your own, so why even try?</p> <p>I’ve fallen into the trap of complaining about culture as a way to avoid leading. If I say, “The culture here is the problem,” that’s a version of, “You’re doing it wrong”—i.e., somebody else needs to change. Change only happens when individuals choose to lead. Even if your organization’s culture is blocking collaboration, you can help it to adapt by leading change on a small scale.</p> <h3>Learn to lead by being honest</h3> <p>You might think that to lead your colleagues through change, you need to present strength, crush opposition, and have a bullet-proof plan. You’ve probably seen managers behaving like this.</p> <p>But being aggressive is actually a defensive response to feeling insecure. You’re trying to build yourself up by putting other people down. This makes people feel resentful and afraid, which stops them from listening to you.</p> <p>In her book <cite><a href="http://www.amazon.co.uk/Daring-Greatly-Courage-Vulnerable-Transforms/dp/1592407331">Daring Greatly</a></cite>, Brené Brown teaches that showing vulnerability is the true indicator of courage. It takes courage to be yourself, to admit that you’re imperfect. If you admit that you don’t have all the answers, people will trust you, and you’ll inspire them to be brave, too.</p> <p>Being a leader often means being the first person to listen. Share your vision—e.g., designing a digital service that puts users’ needs ahead of organizational structure, and makes a profit too—and listen to your colleagues’ ideas, feelings, and needs. Overcome your insecurity, take a risk, and be brave. It could be as simple as proposing an agile process for your next project, admitting that you don’t know whether it will work, and convincing people to try it by building trust. Or you might bring together a multidisciplinary team from across the organization and work up a minimum viable product, while convincing various stakeholders to trust you. The outcome may surprise you.</p> <h2>People skills are web skills</h2> <p>As the web continues to transform our society—in ways that both excite us and scare us—we need more than new technologies to keep up. We need collaboration.</p> <p>Now that you understand how people skills can enable collaboration, you have an opportunity to change your work, and perhaps your organization. Invest your time in people skills and you might just change the world.</p><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/Eanvws77J-A" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)
25. Mar 2014
Content-out Layout
<p>Grids serve well to divide up a predefined canvas and guide how content fits onto a page, but when designing for the web’s fluid nature, we need something more… well, <em>responsive</em>. Enter ratios, which architects, sculptors, and book designers have all used in their work to help set the tone for their compositions, and to scale their material from sketch to final build. We can apply a similar process on the web by focusing on the tone and shape of our <a href="http://www.markboulton.co.uk/journal/anewcanon">content first</a>, then working outward to design fluid, ratio-based grid systems that invite harmony between content, layout, and screen.</p> <h2>Columns are boring. Build with relationships.</h2> <p>Layout choices can set the tone for our designs. As graphic designer Anne Burdick liked to teach, “the structure of the page can be seen as the embodiment of a particular philosophical perspective.&#8221;<sup data-footnote>1</sup> Do we favor order for our content? Or does it require a humanist touch? Should we tempt chaos? Whatever the tone, each can be successfully introduced in your layout through the use of a ratio: even (1:1), golden (1:1.618), or random proportions (no ratio), respectively.</p> <p>Our chosen ratio will be the DNA from which all of our layout decisions are formed. This one number will connect every element of our design, and by adjusting it, we will be able to dramatically affect the tone of our designs. Ratios with a lower proportion—or smaller difference between numbers—will yield subtler layout differences, and work well for nuanced, quieter content like personal blogs or long reads. Greater proportions energize a composition with dramatic size differences, perfect for more dynamic content.</p> <figure> <img src="/d/392/content-out-layout/Fig-1-even.jpg" alt="" /> <figcaption>An even-sized array of images is orderly and sturdy.</figcaption> </figure> <figure> <img src="/d/392/content-out-layout/Fig-2-golden.jpg" alt="" /> <figcaption>A golden ratio-based array feels organic and dynamic.</figcaption> </figure> <figure> <img src="/d/392/content-out-layout/Fig-3-chaotic.jpg" alt="" /> <figcaption>A chaotic array is interesting and a bit unnerving.</figcaption> </figure> <h3>Rational Ratios</h3> <p>A ratio can consist of any two numbers, giving us an infinite palette of possibilities, but to narrow things down it might be best to start with some familiar territory. Rational ratios are friendly enough, as the math isn’t too scary:</p> <figure> <table> <tr> <td>Even</td> <td>1:1</td> </tr> <tr> <td>Halves</td> <td>1:2</td> </tr> <tr> <td>Thirds</td> <td>1:3</td> </tr> <tr> <td>Fourths</td> <td>1:4</td> </tr> </table> </figure> <p>The <a href="http://en.wikipedia.org/wiki/Rule_of_thirds">Rule of Thirds</a> is a well-known example of the power of rational ratios in layout. Highly structured content—like arrays of images or videos, or text with a neutral or formal tone—is represented best by a rational ratio. These ratios work well when designing for symmetry, but can be used for asymmetrical layouts as well.</p> <h3>Irrational Ratios</h3> <p>In <cite>The Book of Rectangles, Spatial Law and Gestures of The Orthogons Described</cite> (1956), Czech designer and architect Wolfgang von Wersin compiled a set of <a href="http://en.wikipedia.org/wiki/Dynamic_rectangle">dynamic ratios</a> used by artists, architects, and calligraphers throughout history to guide their compositions. According to Wersin, it was believed that “nothing excels these proportions.” Not a bad place to start, then.</p> <figure> <table> <tr> <td>Quadrat (or Square/Even)</td> <td>1:1</td> </tr> <tr> <td>Hemidiagon</td> <td>1:1.118</td> </tr> <tr> <td>Trion</td> <td>1:1.154</td> </tr> <tr> <td>Quadriagon</td> <td>1:1.207</td> </tr> <tr> <td>Biauron</td> <td>1:1.236</td> </tr> <tr> <td>Penton</td> <td>1:1.272</td> </tr> <tr> <td>Diagon</td> <td>1:1.414</td> </tr> <tr> <td>Bipenton</td> <td>1:1.458</td> </tr> <tr> <td>Hemiolion</td> <td>1:1.5</td> </tr> <tr> <td>Auron (the golden ratio)</td> <td>1:1.618</td> </tr> <tr> <td>Hecton (or Sixton)</td> <td>1:1.732</td> </tr> <tr> <td>Doppelquadrat (Halves)</td> <td>1:2</td> </tr> </table> <figcaption>Wersin’s 12 “orthagons” with ratios (<a href="http://matthewmattingly.com/sites/default/files/hor-ratio%20instructions%2013.pdf">PDF</a>)</figcaption> </figure> <p>The most famous irrational ratio in design is, of course, the <a href="http://en.wikipedia.org/wiki/Golden_ratio">golden ratio</a> (the “Auron,” according to Wersin), which is derived from patterns in nature and the human form. Irrational ratios give us smaller increments in proportions, and their idiosyncratic relationships work best in asymmetrical layouts. </p> <h3>What else?</h3> <p>On its own, a ratio is not enough to create an engaging composition. Luckily, pure geometry is not our only guide here. I’ve always loved <a href="http://www.amazon.com/Elements-Typographic-Style-Robert-Bringhurst/dp/0881791326">Bringhurst’s concept</a> of choosing typefaces based on who designed them, and where. Perhaps a similar methodology can be applied to layout, where we derive ratios from tangential influences like <a href="http://blog.typekit.com/2014/02/26/deriving-layout-from-your-typeface/">type choices</a>, or even <a href="http://24ways.org/2011/composing-the-new-canon/">music</a>. </p> <h2>Working within a scale</h2> <p>Successful compositions use variety to create hierarchy and movement. Using our chosen ratio, we can extrapolate an array of sizes much like notes on a musical scale, then build our layouts using the “notes”—or widths—from that scale. We can then repeat and skip around the scale to create a kind of visual melody.</p> <p>To build our scale, we first select a base unit. I would suggest using your typography’s base font-size to further connect the proportions of your layout to your content. Let’s use 1em to keep the math simple. We then multiply our base unit by the number on the right side of our ratio to generate the next size up the scale, and repeat until we have enough size variants to build our layout. Eight should do.</p> <figure> <img src="/d/392/content-out-layout/Fig-5-golden-notes.jpg" alt="" /> <figcaption>Eight “notes” generated by the golden ratio.</figcaption> </figure> <p>By deciding sizes based on a scale, we can choose relationships that better fit the tone of our design. Large leaps across the scale can be dramatic. Small steps can be more nuanced than in traditional columnar layouts. No matter the size of the change, the result is geometrically connected by our ratio.</p> <figure> <img src="/d/392/content-out-layout/Fig-6-even-building.gif" alt="" /> <figcaption>An array of images on an even six-column grid.</figcaption> </figure> <figure> <img src="/d/392/content-out-layout/Fig-7-golden-building.gif" alt="" /> <figcaption>An array of images on a “golden” six-column grid.</figcaption> </figure> <h3>Lightening the cognitive load</h3> <p>When working with ratios and scales, your layout decisions will become more strictly defined. For example, if we were laying out the content of a blog with the common image-plus-copy pattern (I call this a “blurb”), three or more columns are needed in an even-column grid to give any size distinction between the elements.</p> <figure> <img src="/d/392/content-out-layout/Fig-8-even-blurb.gif" alt="" /> <figcaption>A blurb on an even three-column grid.</figcaption> </figure> <p>In a ratio-based grid, only two columns would be necessary here. Since blogs are intended to be a more personal expression, I think the golden ratio, with its humanist proportions, would be appropriate.</p> <figure> <img src="/d/392/content-out-layout/Fig-8a-golden-blurb.gif" alt="" /> <figcaption>A blurb on a golden two-column grid.</figcaption> </figure> <p>Each text width is 2.618 times larger than its corresponding image, or two steps up on our scale.</p> <p>Reducing columns helps us out in two ways, giving us:</p> <ul> <li>more layout clarity: hierarchy and alignment are strengthened by the restricted threshold options;</li> <li>fewer decisions when designing: constraints keep our minds free to focus on bigger issues like content and usability.</li> </ul> <p>Our simpler, ratio-based blurb grid codifies a relationship between two elements based on the shape of the content. Using this relationship as a start, we can now flesh out a fluid, content-based grid system.</p> <figure> <img src="/d/392/content-out-layout/Fig-9-golden-blurb.jpg" alt="" /> <figcaption>Our blurb grid.</figcaption> </figure> <h2>Grids within grids</h2> <p>We can now design simpler grids that build upon and within each other, sharing a common ratio to keep harmony between their various contexts. I call grids like the one used for our blurb example a “content grid.” Content grids define relationships within a portable piece of content and work well for articles, sidebar modules, and other reusable elements of a design system. </p> <p>To divide up the available viewport space, we can use a global “layout grid” that behaves more like the grids we’ve been using on the web for years now.</p> <h3>A system emerges</h3> <p>Continuing our blog example, we’ll use our scale to derive another content grid for our posts. In a typical blog post, we have a large image, the body of text, social media links, inline images, and some supporting content pulled out into the margins. By trying various arrangements from our scale, we can arrive at a grid that accommodates our content needs. </p> <figure> <img src="/d/392/content-out-layout/Fig-10-golden-article.jpg" alt="" /> <figcaption>A four-column article grid using 1 and 2 from our scale. The first, thinner column will house a social module, while all four columns give us the opportunity to align our posts’ elements as appropriate.</figcaption> </figure> <p>To convert these widths into fluid CSS percentages, we just need to total the corresponding widths from our scale, and then convert each column using <a href="http://alistapart.com/article/fluidgrids">Ethan Marcotte’s famous formula</a>:</p> <figure class="text"> <p>target ÷ context = result</p> </figure> <p>…with “target” being a column width and “context” being the sum of all columns used in the grid. (Or if you’re braving <a href="http://css-tricks.com/snippets/css/a-guide-to-flexbox/">flex-box</a> for layout, you can just use the exact ratio numbers from your scale.)</p> <p>We can build a simple three-section “layout grid” to accommodate our larger content sections: an area for branding and navigation, an area for the main body of content, and a third area for related and featured content links. Our main content area likely needs to be much wider to house our post content, and the navigation area much thinner. We’ll find column widths from our scale that feel right for our layout, giving the appropriate room for each section.</p> <figure> <img src="/d/392/content-out-layout/Fig-11-golden-layout.jpg" alt="" /> <figcaption>A symmetrical, three-column layout grid using 1 and 3 from our scale.</figcaption> </figure> <p>Finally, we place our content grids (the article grid and our blurb grid from earlier) into our layout grid, creating a layout that is both fluid and completely driven by our content. (<a href="/d/392/content-out-layout/demos/blog-golden.html">View the blog demo</a>.)</p> <figure> <img src="/d/392/content-out-layout/Fig-12-golden-blog.gif" alt="" /> <figcaption>Our new, golden ratio-based, content-out blog layout.</figcaption> </figure> <p>For comparison, I also built this same layout on Twitter Bootstrap’s 12-column grid. (<a href="/d/392/content-out-layout/demos/blog-even.html">View the Bootstrap blog demo</a>.) While fairly similar, the ratio-based layout holds up better at any random size.</p> <h2>Fitting to constraints</h2> <p>Adapting our layout to various viewports now becomes much simpler, as we have fewer variables to consider. For this process, we can build a fluid prototype in the browser, then scrutinize where the layout starts to falter when resizing the window. </p> <h3>Identifying the usual suspects</h3> <p>As the viewport stretches and narrows, our relationships will strain and crack, especially at sizes <a href="http://www.markboulton.co.uk/journal/theinbetween">in between typically targeted device sizes</a> like “tablet” and “desktop.” After exploring how fluid layouts crumble on many well-trafficked sites, I’ve isolated some common issues that signify where a <a href="http://alistapart.com/article/the-infinite-grid">change in grid</a> is needed:</p> <h4>7s</h4> <p>Sevens find an image shortened as its width is scaled down, and adjacent text squished to a tall, unreadable measure. The resulting form resembles a “7,” and creates a conspicuous square of white space beneath the image. This is especially distracting when repeated across a layout. </p> <figure> <img src="/d/392/content-out-layout/Fig-13-sevens.gif" alt="" /> <figcaption>Examples of the 7 pattern, and the negative space created.</figcaption> </figure> <h4>Drifts</h4> <p>Drifts are so far removed from their related content that they no longer have any relationship to anything. They may wind up paired with other disparate pieces of content flotsam, or just drift all by their lonesome. Across a layout, drifts destroy hierarchy and cause troubling rivers of negative space to creep in.</p> <figure> <img src="/d/392/content-out-layout/Fig-14-drifters.gif" alt="" /> <figcaption>Images have drifted away from content, forming their own column, while their headlines and meta content lose any visual relevance to each other.</figcaption> </figure> <h4>Pinches</h4> <p>Pinches happen as elements get too close to other pieces of content. Relationships are destroyed as the viewer makes incorrect associations: images pair with the wrong headline, links run into a list of their own creation. In extreme cases, content collides—at the cost of all readability.</p> <figure> <img src="/d/392/content-out-layout/Fig-15-pinchers.gif" alt="" /> <figcaption>Pinches cause visual hotspots that distract the eye and confuse relationships as proximity overpowers placement.</figcaption> </figure> <h3>Finding elemental constraints</h3> <p>After adjusting your layouts for fluidity, certain elements will need special attention. Paragraphs should maintain a readable measure, ads should maintain size and relative position, and images should not enlarge beyond what their resolution will allow. Setting a specific <em>width</em> is an easy fix, but does not truly embrace fluidity. Instead, we can set a <code>min-width</code> and/or <code>max-width</code> in our CSS to maintain the integrity of this content.</p> <h2>A fitter method</h2> <figure class="quote"> <blockquote>The use of the grid as an ordering system is the expression of a certain mental attitude inasmuch as it shows that the designer conceives his work in terms that are constructive and oriented to the future.</blockquote> <figcaption>Josef Muller-Brockmann</figcaption> </figure> <p>A ratio-based, modular approach to grids allows us to navigate a medium where we cannot know the container size, nor what type of content will flow into that container. We can build layout systems from our content, and rely on ratios to keep harmonious compositions from these disparate parts. From there, a keen understanding of how fluid designs fail can show us when to adapt these systems, and when to add constraints.&nbsp; </p> <p>In <a href="http://alistapart.com/article/fluidgrids">2009</a>, and again in <a href="http://alistapart.com/article/responsive-web-design/">2010</a>, Ethan Marcotte gave us the tools with which to respond. In <a href="http://www.markboulton.co.uk/journal/anewcanon">2011</a>, Mark Boulton gave us a guiding philosophy. By weaving these highly influential ideas together with a pliable method, we can move towards more sophisticated layouts tailored to the needs of our content, patterned with unique character, and perfectly suited to the nature of our ever-changing web.</p><h3>Footnotes</h3><ul class="the-footnotes"><li id="note1">1. Burdick, Anne, Stephen Farrell. “An interview with Stephen Farrell” <cite>Emigre</cite> 37 (1996). Print.</li></ul><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/DF9QAniypaA" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)
24. Mar 2014
Save Your Eyes with f.lux
<p>I never thought I felt eye strain from looking at big, bright screens all day—I thought my young eyes were invincible. Then I started getting sharp headaches at the end of every day, and I realized I needed to change something.</p> <p>I decided to finally take the jump and start using <a href="http://justgetflux.com">f.lux</a>. f.lux is an app that changes the color temperature of your display, adapting the light you see to the time of day, which helps to reduce eye strain. There&#8217;s a <a href="http://justgetflux.com/news/pages/mac/">new beta out for Mac</a> that brings some really fantastic improvements and enhancements (don&#8217;t worry, there&#8217;s <a href="http://justgetflux.com/news/2013/05/29/beta.html">a Windows version</a> too!).</p> <p>In the morning and afternoon, you&#8217;ll see the blue-ish colored light that your screen normally pushes out. As the sun sets, the light will shift to a more reddish color, and when night falls, it&#8217;ll become an even deeper red. Every color step is customizable, so you decide how red-shifted you&#8217;d like each phase to be—I like mine on the deeper end of the scale.</p> <p>It&#8217;s normal to see blue light during the day, but as it gets darker, that light is harsh on our eyes. Red light is <a href="http://justgetflux.com/research.html">easier on your eyes,</a> especially at night—it&#8217;s why <a href="http://en.wikipedia.org/wiki/Night_vision#Biological_night_vision">red lights are used to preserve vision at night</a>.</p> <p>When I tell people in our industry about f.lux, I often hear something like, &quot;But what if I&#8217;m doing color-sensitive work?&quot; The newest f.lux beta has a feature that allows you to disable f.lux in certain applications. As you switch into an application where you’ve disabled f.lux, your screen will slowly transition to normal colors. The smooth transition will help prepare your eyes for the blue wave of light you&#8217;re about to get hit with, so it&#8217;s not too jarring.</p> <p>For anyone who spends hours a day looking at a screen, f.lux is a must-have. We spend a lot of time and effort making sure we use ergonomically correct keyboards, chairs, and desks, so it&#8217;s time we gave our eyes a similar level of treatment.</p><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/UiSeEDmDa1Q" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)
23. Mar 2014
Cennydd Bowles Makes a Case for Android
<a href="http://www.cennydd.co.uk/2014/why-dont-designers-take-android-seriously" style="font-size: 18px;">» Cennydd Bowles Makes a Case for Android</a><br><br>Cennydd believes Android will be the dominant platform in the next decade, and has compiled his responses to the main arguments against his stance.<br><br><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/gULCdrjLWoI" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)
1. Apr 2014
CSS Lists and Counters Module Level 3 Draft Published, CSS Namespaces Module Level 3 Recommendation Updated
The Cascading Style Sheets (CSS) Working Group has published a Working Draft of CSS Lists and Counters Module Level 3. This draft contains the features of CSS level 3 relating to list styling. It includes and extends the functionality of CSS level 2 [CSS21]. The main extensions compared to level 2 are a pseudo-element representing [&#8230;][mehr] (Quelle: W3C News)
3. Apr 2014
W3C Invites Implementations of CSS Writing Modes Level 3, CSS Shapes Module Level 1
The Cascading Style Sheets (CSS) Working Group invites implementation of two Candidate Recommendations: CSS Writing Modes Level 3. CSS Writing Modes Level 3 defines CSS support for various international writing modes, such as left-to-right (e.g. Latin or Indic), right-to-left (e.g. Hebrew or Arabic), bidirectional (e.g. mixed Latin and Arabic) and vertical (e.g. Asian scripts). CSS [&#8230;][mehr] (Quelle: W3C News)
9. Apr 2014
Accessible Rich Internet Applications (WAI-ARIA) 1.0 is a W3C Recommendation
The Protocols and Formats Working Group (PFWG) today published Accessible Rich Internet Applications (WAI-ARIA) 1.0 and the WAI-ARIA 1.0 User Agent Implementation Guide as W3C Recommendations. WAI-ARIA is a technical specification for making dynamic, interactive Web content accessible to people with disabilities. WAI-ARIA and supporting documents are described in the WAI-ARIA Overview. See more information [&#8230;][mehr] (Quelle: W3C News)
20. Mar 2014
Laura Kalbag on Freelance Design: Inspiration
<p>“Where do you get your inspiration from?” It’s an odd question that designers ask each other. But it’s not asking what motivates us to do our work, or what makes us want to be designers in the first place.</p> <h2>What is inspiration?</h2> <p>When we’re asked where we get our inspiration from, we’re usually being asked where we find that little seed of an idea that grows into a creative solution to a problem.</p> <p>As a web designer, the expected answer is often a CSS or Responsive Web Design gallery website, and the underlying question is, Where do you pinch your best ideas from?</p> <p>When I was in high school, art class exercises were usually formed of slavishly copying an artist’s work. We’d use the tools and techniques the artist used in order to better understand how and why the work was created. This helped us experience the process the artist used to create such work.</p> <figure> <img src="http://d.alistapart.com/Inspiration-Kalbag/eyes-for-web.jpg"> <figcaption>A study of eyes in different paintings from my art class when I was 17.</figcaption> </figure> <p>Following these exercises, we would usually complete a piece of our own work, with subject matter of our choosing, but using the same tools and techniques as the artist. Here we were learning how to apply the artists’ thinking in the context of our own work.</p> <figure> <img src="http://d.alistapart.com/Inspiration-Kalbag/christo_mug.jpg"> <figcaption>A mug wrapped in paper and string, inspired by the style of Christo and Jeanne-Claude.</figcaption> </figure> <h2>Researching solutions</h2> <p>Every design problem is unique. The context, environment, audience, and goals will never be the same again. But the problems we’re solving can be <em>similar</em> to those that went before. These similarities are what we can use to research potential solutions. When we’re researching the solutions through the experience and ideas of others, it’s like being back in art class again. We’re learning how it feels to use other designers’ tools and techniques, so that we can discover what might suit our own processes. Our wide-ranging explorations lead us each to find inspiration in a different artist or technique. Just as every design problem is unique, there’s no single designer, book, or gallery site that can solve every design problem.</p> <p>Borrowing ideas isn’t a bad practice. We can research and learn from these resources, although to copy their aesthetics or functionality in their entirety <em>is</em> bad practice. If we copy other designers’ work, regardless of the context of their origins or our projects, we won’t have learned anything, and it will likely result in poor work and an inappropriate solution.</p> <h2>Evolving resources</h2> <p>I was discussing inspiration with my friend <a href="http://www.bevanstephens.com">Bevan Stephens</a> a few weeks ago. We talked about how, at some point in our design careers, we seemed to stop looking for ideas in galleries and similar resources. We didn’t realize it at the time, but somehow we’d gained confidence, and felt we didn’t need to actively search for ideas from aesthetic showcases anymore.</p> <p>When we start out, we are usually very conscious of every design decision we make. It takes time for us to familiarize ourselves with our preferred rules and patterns. The more experience we get, the more subconscious these design decisions become. We can make a decision without any conscious justification, although we can then unravel our reasoning in a perfectly clear way. I believe this confidence comes to all designers with time.</p> <p>A similar thing happens with the way we research solutions. We spend a huge amount of time interacting with other designers’ work; in our research and in the products we use. Sometimes a solution, or an element of the execution, will stand out to us. We may just absorb the effectiveness (or ineffectiveness). Or we’ll remind ourselves to save it for later, in a notebook, some kind of resources library, or just in our heads.</p> <p>The more experience we have, the greater the osmosis. The viewing and filing of the solutions becomes quicker, more automatic. We become more efficient at storing the information and ideas that we need.</p> <h2>The exceptions</h2> <p>Whilst I think I’m getting better at subconsciously storing ideas and potential solutions, occasionally I find myself returning to the design galleries. It’s not usually for a general browse, but more often for looking at a specific category, a particular type of website. I find myself needing to learn again. I seek out ideas from gallery sites when I’m feeling unsure. This usually happens when the context of a project is new to me. It’s a different type of site, product, audience, or approach. I need to supplement my mental library of ideas. I’m not blindly copying work like I might have done when I was starting out, I’m now better at identifying when I need more resources to help me understand a problem. I understand more about how to appropriate ideas and techniques without copying. Still, I need to bolster my confidence. I want to feel as though I know what I’m working with.</p> <p>Design as a practice and process stays constant, but the technology, audiences and other outputs change around us. We will always be able to apply our skills of seeing, solving problems and making decisions, but the industry standards and best techniques are always changing. The evolving web means we need to keep learning. Still, we need to be smart about how we learn, and understand the difference between learning and copying so we don’t fall back on the work of others when we should be innovating for ourselves.</p><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/SuBPLbaQW2U" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)
25. Mar 2014
Last Call: User Interface Security Directives for Content Security Policy
The Web Application Security Working Group has published a Last Call Working Draft of User Interface Security Directives for Content Security Policy. This document defines directives for the Content Security Policy mechanism to declare a set of input protections for a web resource&#8217;s user interface, defines a non-normative set of heuristics for Web user agents [&#8230;][mehr] (Quelle: W3C News)
25. Mar 2014
First Public Working Draft of Subresource Integrity Published
The Web Application Security Working Group has published a First Public Working Draft of Subresource Integrity. This specification defines a mechanism by which user agents may verify that a fetched resource has been delivered without unexpected manipulation. Learn more about the Security Activity.[mehr] (Quelle: W3C News)
27. Mar 2014
W3C Workshop on the Web of Things
W3C announced today a Workshop on the Web of Things, 25-26 June 2014, in Berlin (Germany). The event is hosted by Siemens. The Web of Things is expected to have broad and sweeping economic and societal impact. Open standards will be critical to enabling exponential growth of the kind we experienced with the early days [&#8230;][mehr] (Quelle: W3C News)
17. Mar 2014
A Q&amp;A on the Picture Element
<p><i>The revival of the <code>picture</code> element—the responsive images proposal that has seen the most support from the developer community—is exciting news, but there are still some outstanding questions about how the element will really work. <a href="http://twitter.com/marcosc">Marcos Caceres</a> and <a href="http://twitter.com/yoavweiss">Yoav Weiss</a> have put countless hours into the <a href="http://responsiveimages.org/">Responsive Images Community Group</a>’s efforts, and are now working toward <code>picture</code> implementations in Firefox and Chrome, respectively. Mat Marquis asked them some questions.</i></p> <p class="question"><b>So, we’re getting <code>picture</code> <em>and</em> <code>srcset</code>? I thought <code>srcset</code> was bad?</b></p> <p><b>MC:</b> <code>srcset</code> was never bad in itself—some parts of the syntax were just hard to understand, and it wasn’t able to handle an important use case: “<a href="http://usecases.responsiveimages.org/#art-direction">art direction</a>”. The <code>picture</code> element works in conjunction with <code>srcset</code>, giving developers a set of solutions for whatever problem they are trying to solve.</p> <p class="question"><b>What happened to the <code>src-n</code> proposal that was going around a short time ago?</b></p> <p><b>MC:</b> The <code>src-n</code> proposal (put together by Google’s Tab Atkins and John Mellor) elegantly solved a lot of problems, but introduced some weird markup (the numbered attributes bit), which would have made a mess of browsers’ internals. Some WebKit folks went so far as to call it “a grotesque perversion of the HTML language.”</p> <p><b>YW:</b> The biggest innovation in <code>src-n</code> was the <code>sizes</code> attribute. This attribute allows you to specify the dimensions for a set of images and lets the browser take care of the math behind all the resource selection. We’ve incorporated that feature into the latest <code>picture</code> proposal—the <code>src-n</code> proposal was an important step in getting the complete solution that we have today.</p> <p class="question"><b>I thought <code>picture</code> was done-for—what brought it back?</b></p> <p><b>MC:</b> It was really the rejection of <code>src-n</code> by WebKit that brought it back. By taking <code>picture</code> off the standardization table, there was a new sense of urgency to finding a solution for responsive images.</p> <p>Mozilla was quite keen on <code>src-n</code>, as we thought that, despite being hard to implement, it did a fair job of addressing the problems developers were facing. But, when the WebKit community said no to <code>src-n</code>, the Blink community backed out as well—the Blink folks weren’t sold on it to start with, so they weren’t apt to do something the WebKit folks were not keen on either. With Mozilla having rejected the original <code>srcset</code> proposal, this really only left <code>picture</code> on the table.</p> <p>Then, a clever dude from Opera software—Simon Pieters—had an epiphany: what if we flip the way that browsers <em>process</em> <code>picture</code>? If we used the <code>picture</code> element as sort of a controller for an old-fashioned <code>img</code> element, we could get all the same functionality with way less implementation overhead.</p> <p><b>YW:</b> The old proposal’s version of <code>picture</code> acted like a better featured version of <code>img</code> itself, in the new proposal the <code>picture</code> element is there only to contain possible resources for the <code>img</code> element, and assists it in choosing the right one.</p> <p><code>img</code> can keep doing what it does best: loading and displaying a resource, and the new element just handles the parts that <code>img</code> doesn’t excel at—namely, picking the most appropriate resource based on a combination of factors: viewport size, pixel density, and so on.</p> <p>This design enables browsers to avoid re-implementation and re-testing of <code>img</code>’s core functionality with <code>picture</code>, and reduces the maintenance costs of the feature significantly.</p> <p class="question"><b>Does <code>picture</code> need to land before we can do any real performance testing, or are there tests in place before the element officially hits browsers?</b></p> <p><b>MC:</b> I think <code>picture</code> will need to land before we can get any real numbers. However, given that <code>srcset</code> is already in Chrome 34, sites might already be seeing some of the benefits that come from a responsive image solution.</p> <p><b>YW:</b> <i>Some</i> of the performance benefits can be measured by using today’s polyfills. For example, the data savings from using <code>picture</code> are not likely to change significantly compared to the data savings benefits of using Picturefill, minus the actual polyfill download. One difference is that current polyfills have to work around browser-level optimizations—like prefetching sources—while a native solution will be able to take advantage of them.</p> <p class="question"><b>How does the current implementation in Chrome differ from implementations in existing polyfills? Do I need to change my code to get it working natively or will it integrate seamlessly?</b></p> <p><b>YW:</b> The Blink implementation is of <code>srcset</code>’s DPR syntax, which is a subset of the original <code>srcset</code> syntax. If the polyfill you use has implemented that syntax (the <code>x</code> variant of <code>srcset</code>), and does feature testing, it’s highly possible that you won’t have to modify your site’s syntax.</p> <p><b>MC:</b> As with any emerging standard, things can change quickly. There is always risk in prematurely adopting a solution before it becomes a standard. Fortunately, the high visibility and level of interest in this feature means the community is already updating their polyfills. For example, <a href="http://twitter.com/scottjehl/">Scott Jehl</a> is planning to <a href="https://github.com/scottjehl/picturefill/issues/125">update Picturefill</a> to support the new syntax and attributes of <code>picture</code> soon.</p> <p class="question"><b>Will the <code>type</code> attribute on <code>source</code> be supported when <code>picture</code> is implemented in Chrome and Firefox?</b></p> <p><b>MC:</b> I don’t see any reason why it wouldn’t be. An important part of a responsive images solution is having the ability to use emerging image formats like WebP, particularly if using these formats will benefit users without excluding those still using legacy browsers. As a community, we need to make sure there is a solid test suite to check for support of the <code>type</code> attribute—and we need to hold them accountable if the browsers don’t get it right!</p> <p><b>YW:</b> What Marcos said!</p> <p class="question"><b>How interoperable will <code>picture</code> be with <a href="http://lists.w3.org/Archives/Public/public-respimg/2013Sep/0036.html">MQ variables</a>?</b></p> <p><b>MC:</b> In most cases, as long as you can use the final MQ variable syntax anywhere you would use a media query normally, then it <i>should</i>“just work”.</p> <p><b>YW:</b> The latest <a href="http://tabatkins.github.io/specs/css-aliases/">MQ variable proposal</a>—dubbed “CSS aliases”—is still in its very early stages, but we’ve been thinking about how it might work with <code>picture</code> already. Interoperability with <code>picture</code> is going to be important for any MQ variable proposal.</p> <p class="question"><b>Is bandwidth a consideration right now, or is this all mostly about viewport sizes and densities?</b></p> <p><b>MC:</b> Bandwidth detection <em>itself</em> isn’t a relevant factor. Consider, when you go to a conference, the Wi-Fi you connect to has high bandwidth, yet you get slow speeds. Bandwidth is variable—particularly on cellular connections. Most of the time,what users care about is costs, particularly on mobile. I think what we want is for users to have the ability to tell the browser, “If I’m on my cellular plan, just give me the 1x images.”</p> <p>This is the beauty of the declarative <code>picture</code> solution: all developers have to do is provide a suitable set of images for the browser to choose from. It’s then on browsers to do the right thing, on behalf of the user.</p> <p>You can expect that minimizing the cost of browsing is something we browser vendors will be competing on—a definite win for our users.<p><b>YW:</b> Initial implementations likely won’t take network quality into account—but as Marcos said, the solution’s markup provides all the information the browser needs to <em>later</em> take that into account. All in all, the solution aims to give this control to the browsers, and through them, to the users themselves.</p> <p class="question"><b>Is it safe to use the <code>picture</code> element in a production site, once these implementations launch?</b></p> <p><b>MC:</b> I would wait a little bit—until there’s public confirmation from all the big browser vendors—before using <code>picture</code> on a production site. I’d hate to see people include this prematurely, and a change to the markup come along later. With that caveat: the really nice thing about the new <code>picture</code> markup is that developers must include an <code>img</code> element for it to work. This means that by default—and with no exception—the fallback for <code>picture</code> will work with legacy browsers. It’s then up to authors to include an optimized image for legacy browsers inside the <code>img</code> element.</p><p> </p> <p><b>YW:</b> In general I agree with Marcos, but I guess it also depends on the polyfills available and their support for the new markup. Once Picturefill and other polyfills support the markup, it might be possible to roll the new markup out to live sites that we control—like our own—as long as we make sure that we can adapt quickly in the unlikely event that the markup changes.</p> <p>&nbsp;</p><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/1hASEFZxm2U" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)
14. Mar 2014
Ten Years Ago in A List Apart: CSS Sprites – Image Slicing’s Kiss of Death
<p>My fellow old-time web designers may remember the joys of image swapping via JavaScript. Here’s how we did it back in 1998 (don’t hate me because I’m beautiful): </p> <ul><li><a href="http://web.archive.org/web/19981212034308/http://www.zeldman.com/">today-we’d-call-it-responsive homepage from 1998</a></li> <li><a href="http://web.archive.org/web/19980702052052/http://www.zeldman.com/">fixed-width homepage from 1998</a></li></ul> <p>Even when some of us figured out, the following year, that HTML was supposed to be for structured content, CSS for visual layout, and JavaScript for behavior—and even when browsers began supporting that separation of powers a couple of years later—for years, the web continued to be a hodgepodge of sliced and diced images and excessive http calls, all held together via inline JavaScript that turned HTML into a chocolate-and-peanut-butter soup. Sure, we all wanted our separation of presentation from structure—but we loved our glitzy visual effects more.</p> <p>And then in 2004, a wonderful man named Dave Shea—the same prophet who had launched the CSS Zen Garden just eight months earlier—helped our entire industry kiss all that goodbye with a single, deceptively simple <cite>A List Apart</cite> article. </p> <p>Rereading <a href="http://alistapart.com/article/sprites">CSS Sprites: Image Slicing’s Kiss of Death</a> from the comfort of today’s privileged position, it’s easy to miss how new and revolutionary Dave’s thinking was.</p> <p>Today we take sophisticated CSS for granted, and we expect our markup to be just that—clean and semantic, not oozing behavior and leaking layout. But in 2004, removing all that cruft from HTML took courage. And it was an act of absolute wizardry to conceive that a grid of images in a single master GIF or JPEG could replace all those http calls and subfolders full of tiny images thanks to CSS’s hover property and cropping ability. Admittedly, Dave couldn’t have done what he did without Petr Stanicek’s (Pixy) <a href="http://wellstyled.com/css-nopreload-rollovers.html">Fast Rollovers Without Preload</a>, an ingenious predecessor to CSS Sprites which Dave readily acknowledged in his groundbreaking ALA article.</p> <p>If you want to know how big an impact CSS Sprites: Image Slicing’s Kiss of Death had on our industry, consider that, ten years later, CSS Sprites are still web design&#8217;s standard best practice for adding non-textual interactive cues to a web page.</p> <p>As we celebrate <a href="http://alistapart.com/blog/post/were-nothing-without-you-the-web-at-25">25 years of the web</a>, let&#8217;s also admire the accomplishments of the last ten years by the brilliant members of our web design community. Congratulations and thank you, Dave Shea—and congratulations to us all.</p> <p>&nbsp;</p><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/GqudXthAoZ4" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)
25. Mar 2014
Metadata API for Media Resources 1.0 is a W3C Recommendation
The Media Annotations Working Group published a Recommendation of Metadata API for Media Resources 1.0. This document defines an API to access metadata information related to media resources on the Web. The overall purpose is to provide developers with a convenient access to metadata information stored in different metadata formats. The API provides means to [&#8230;][mehr] (Quelle: W3C News)
20. Mar 2014
W3C Invites Implementations of State Chart XML (SCXML): State Machine Notation for Control Abstraction
The Voice Browser Working Group invites implementation of the Candidate Recommendation of State Chart XML (SCXML): State Machine Notation for Control Abstraction. This document describes SCXML, or the &#8220;State Chart extensible Markup Language&#8221;. SCXML provides a generic state-machine based execution environment based on CCXML and Harel State Tables. Learn more about the Voice Browser Activity.[mehr] (Quelle: W3C News)
20. Mar 2014
Clipboard API and events Draft Published
The Web Applications Working Group has published a Working Draft of Clipboard API and events. This document describes APIs for clipboard operations such as copy, cut and paste in web applications. Learn more about the Rich Web Client Activity.[mehr] (Quelle: W3C News)
18. Mar 2014
Linked Data Platform Use Cases and Requirements Note Published
The Linked Data Platform (LDP) Working Group has published a Group Note of Linked Data Platform Use Cases and Requirements. To foster the development of the Linked Data Platform specification, this document includes a set of user stories, use cases, scenarios and requirements that motivate a simple read-write Linked Data architecture, based on HTTP access [&#8230;][mehr] (Quelle: W3C News)
18. Mar 2014
First Public Working Drafts of Annotation Use Cases, Requirements for Latin Text Layout and Pagination
The Digital Publishing Interest Group has published two First Public Working Drafts today: Annotation Use Cases, which describes the set of use cases generated for Annotation and Social Reading within the W3C Digital Publishing Interest Group, in coordination with the Open Annotation Community Group. Requirements for Latin Text Layout and Pagination, which describes requirements for [&#8230;][mehr] (Quelle: W3C News)
13. Mar 2014
Nishant Kothary on the Human Web: Good Taste Doesn&#8217;t Matter
<p>A couple of days after Macklemore took home this year’s Grammy for Best Rap Album, Slate pop critic Jack Hamilton wrote a scathing reaction titled <a href="http://www.slate.com/articles/arts/culturebox/2014/01/macklemore_grammy_wins_don_t_hate_the_thrift_shop_rapper_because_he_s_white.html">Don’t hate Macklemore because he’s white. Hate him because his music is terrible.</a> Somewhere between comparing Macklemore to Upworthy—“Macklemore is the rap game Upworthy: He hawks hip-hop that switches out faked emotion for real intellect and faked intellect for real emotion”—and putting anyone that enjoys Macklemore’s music in one of three categories—shallow, dull, or even immoral—Hamilton listed the reasons why Macklemore’s music was bad: his beats and melodies are cliché, his lyricism is weak, and Macklemore is blatantly profiting off his white privilege and hypocrisy. (I have to confess that I had no clue that Upworthy had already jumped the shark.)</p> <p>What was most interesting about Hamilton’s piece was the unfortunate, but abundantly common, message hidden between the lines: if you enjoy Macklemore, you have terrible taste in music.</p> <p>So, let’s talk about taste.</p> <h2>Anything you can do (I can do better)</h2> <p>Hamilton’s reaction is pretty representative of our individual attitudes toward subjectivity (or, if you prefer agnostic terminology, unknowability). We acknowledge that our tastes, whether they be religious, political, musical, aesthetic, and so on, are uniquely ours. But simmering just below the surface is the magma of reasons for why <em>my</em> tastes are better than yours. And given the right circumstances—such as an award ceremony that promises to determine the best music across today’s genres—the magma rages to the surface.</p> <p>Hamilton almost catches himself mid-eruption with his nod to “a Times piece far more levelheaded than this one,” but it’s short-lived. Once the eruption is underway, there’s not much you can do except watch its bubbly awesomeness incinerate rhyme and reason.</p> <p>I think we all could relate to Hamilton’s dormant rage, if not specifically for or against Macklemore or even with regards to musical selection. But when it comes to the <em>reasoning</em> provided, it doesn’t take a philosopher to deduce that his is circular and shaky, and barely makes a dent in trying to prove that Macklemore’s music is objectively terrible.</p> <p>What is abundantly clear, though, is that Hamilton sees no beauty in Macklemore’s music.</p> <p>And that’s OK. We are all entitled to <a href="http://alistapart.com/column/the-monster-within-us">our Celine Dions</a>.</p> <h2>Hume-r me</h2> <p>Beauty lies in the eye of the beholder is a notion that we take for granted. But often our words and actions give away our true feelings. Deep down (or actually, just below the surface), we don’t seem to really believe that beauty is subjective.</p> <p>Tomes have been written about this question across the arts and sciences. One of the most holistic, succinct, cited, and relevant analyses that has stood the test of time is an essay by the 17th century philosopher David Hume. Titled <a href="http://web.mnstate.edu/gracyk/courses/phil%20of%20art/hume%20on%20taste.htm#1">Of the Standard of Taste</a>, Hume’s essay was one of the first to explore the existence of an objective beauty. And it continues to lay the foundation for the debate even today.</p> <p>Like a brilliant politician, Hume managed to (almost) convincingly argue both sides of the debate—that beauty is subjective <em>and</em> it is objective—in one eloquent breath. “To seek in the real beauty, or real deformity, is as fruitless an enquiry, as to pretend to ascertain the real sweet or real bitter,” he wrote, just a few paragraphs before making the seemingly contradictory assertion, “A true judge in the finer arts is observed, even during the most polished ages, to be so rare a character; Strong sense, united to delicate sentiment, improved by practice, perfected by comparison, and cleared of all prejudice, can alone entitle critics to this valuable character; and the joint verdict of such, wherever they are to be found, is the true standard of taste and beauty.”</p> <p>The gist of Hume’s essay seems to be that beauty does lie in the eye of the beholder, but that <em>some</em> beholders are better able to identify that elusive, but existent, true beauty. Hume even provided a five-part litmus test—strong sense, united to delicate sentiment, improved by practice, perfected by comparison, and cleared of all prejudice—for identifying these truly skilled beholders.</p> <p>It’s the final condition that exposes the chink in his argument’s armor, even today: cleared of all prejudice.</p> <h2>The elephant in the room</h2> <p>Three centuries since its publication, what we do know for fact thanks to advances in too many fields to list (but <a href="http://rainypixels.com/thereadinglist/">here’s a sampling</a>), is that prejudice runs so deep that you’re never cleared of all of it. Sometimes our prejudices develop firm roots over time nurtured by the abundance of cognitive biases that affect our thoughts and actions every second. In other cases, <a href="http://www.upworthy.com/how-to-change-what-you-find-attractive-in-60-seconds?c=reccon1">as this excellent Upworthy video demonstrates</a>, you can change what you find beautiful in 60 seconds flat. The result in either case is the same: our reasoning, no matter how sound it may seem or eloquent it may sound, is always tainted.</p> <p>In <cite><a href="http://www.amazon.com/The-Righteous-Mind-Politics-Religion/dp/0307377903">The Righteous Mind</a></cite>, social psychologist Jonathan Haidt brings together research from a variety of fields to unequivocally conclude, “Reason is not fit to rule; it was designed to seek justification, not truth. Anyone who values truth should stop worshipping reason.”</p> <p>Taking it one step further, Haidt also provides a poignant metaphor for how our minds truly work:</p> <figure class="quote"> <blockquote> The mind is divided, like a rider on an elephant, and the rider’s job is to serve the elephant. The rider is our conscious reasoning—the stream of words and images of which we are fully aware. The elephant is the other 99 percent of mental processes—the ones that occur outside of awareness but that actually govern most of our behavior. </blockquote> </figure> <p>The implications of Haidt’s conclusion to the question at hand—Is there such a thing as <i>true beauty</i>?—is that the answer will never be a “yes” if supported only by reason.</p> <p>Ironically, to prove that something is objectively beautiful, you will need to furnish more than just reasoning. Whether it’s seemingly objective (like Hume’s) or suspiciously subjective (like Hamilton’s) is mostly irrelevant.</p> <h2>In conclusion: kill your idols</h2> <p>This brings us to the obvious question for product designers: what does all of this mean to me professionally? How does it apply to designing products that are aesthetically pleasing? <a href="http://alistapart.com/article/indefenseofeyecandy">Does it even matter</a>?</p> <p>Even though it doesn’t sound like it, I am a believer in the notion that taste is a supremely important characteristic of good product design. But it seems clear to me the effort to acquire <em>good taste</em>, something that we’re very enamored with in our current design culture, is a mostly futile enterprise. In fact, it’s downright counterproductive. This is because good and virtuous taste, by its very nature, is exclusionary; it only exists relative to shallow, dull, and apparently, immoral 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.</p> <p>Good taste is a myth. A story our rider creates to serve the needs of the elephant. And the sooner you kill your good taste idol, the sooner you’re going to give yourself a chance to be a better designer. It frees you up to add taste as another tool in your designer’s toolbox. Consequently, instead of focusing on <em>good</em> taste, your focus becomes the <em>right</em> taste for the problem at hand. There’s a subtle but profound difference.</p> <p>An added benefit of killing your good taste idol is one that’s characteristic of all types of idolatry homicide: it is emotionally freeing. Where you once spent your time protecting the fragile shrine you built for your preferred sensibilities, whether they are excited by flat colors, skeuomorphism, tight grids, loose grids, subtle shadows, three-dimensionality, or countless other things, you are now freed up to dedicate those brain cycles to the quest for solving your problem as broadly and well as possible. And the best part is that you don’t end up riding the emotional roller coaster that’s part and parcel of all idol worship. If someone doesn’t like something, you don’t take it personally because, well, it <em>isn’t</em> personal to you anymore. It’s just feedback, and most often, it’s useful.</p> <p>As for the Grammy for Best Rap Album? Here’s what’s fair in my opinion.</p> <p>If you tell someone that Kendrick Lamar should have won instead of Macklemore, that’s completely justified. But if you erupt with the reasoning that his music is <em>objectively</em> better than Macklemore’s, don’t be surprised when they respond with something along the lines of Lamar’s own lyric: <i>Bitch, don’t kill my vibe</i>.</p><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/_3UFyO4Yfew" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)
20. Mar 2014
Happy Birthday World Wide Web!
Today, around the world, people are joining Web inventor Tim Berners-Lee in wishing the World Wide Web a happy 25th birthday. To mark the occasion, everyone is encouraged to share birthday greetings on social media using #web25. Select greetings will also be posted on a virtual birthday card on the official anniversary site webat25.org. &#8220;The [&#8230;][mehr] (Quelle: W3C News)
18. Mar 2014
Updated Techniques for Web Content Accessibility Guidelines (WCAG) 2.0 and Understanding WCAG 2.0
The Web Content Accessibility Guidelines Working Group today published updates of two Notes that accompany WCAG 2.0: Techniques for WCAG 2.0 and Understanding WCAG 2.0. (This is not an update to WCAG 2.0, which is a stable document.) For information on these updates and links to blog posts, please see the WCAG Techniques &#38; Understanding [&#8230;][mehr] (Quelle: W3C News)
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)
7. Mar 2012
WHATWG Weekly: http+aes URL scheme, control Referer, …
Apple's Safari team provided feedback to the Web Notifications Working Group. That group, incidentally, is looking for an active editor to address that and other feedback. Opera Mobile shipped with WebGL support. This is March's first WHATWG Weekly. Simon Pieters overhauled much of HTML5 differences from HTML4 and the document now provides information on added/changed [&#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)