640x480.de

The Guardian – jetzt nicht mehr Beta

Nach fast einem Jahr der Beta-Phase ist die neue Websites der britischen Zeitung „The Guardian“ am 28. Januar 2015 offiziell zur einzigen Website geworden

Im letzten Jahr bin ich mehrfach auf dieses Projekt gestoßen worden – nicht zuletzt durch Oliver Reichensteins Vortrag bei der beyondtellerrand in Berlin.

Aus Entwicklersicht birgt dieses Projekt viele spannende Aspekte, schon wegen der Bekanntheit der Site, wegen ihres Umfangs, weil der Relaunch mit einem internen Team durchgezogen wurde usw.

Interessant auch, dass sie einen anderen Ansatz zum Aufbau von Websites wählt. Weg vom Denken in „Bäumen“ und Hierarchien, hin zu einer flexiblen, flachen Struktur – näher an die Realität des Surfverhaltens. Geteilter Content, z.B. über Twitter, ist ja immer ein Direktlink auf Einzelseiten. Jede Seite wird damit zur Startseite: „Every article should be a homepage“.

Dieses Ziel wird durch den Seitenaufbau mit Hilfe von Containern umgesetzt. Ich will versuchen, das zu erklären: Eine Website wird linear aus Seitenabschnitten zusammengesetzt, die von links nach rechts die gesamte Seitenbreite füllen. Diese Seitenabschnitte sind aber nicht einfach „Textabschnitt“, „Bild“, „Werbeblock“, „Video“, sondern können in sich komplexe Inhalte oder Funktionen enthalten. Wichtig dabei ist – so wie ich das verstanden habe, dass Inhalt und Funktionalität eines Containers zusammengehören. Der Hintergedanke wird sofort deutlich, wenn man an responsive Websites denkt. Bei einer Spaltenstruktur (die genau aus diesem Grund seltener wird) hat man ja das Problem, dass in der linearen Umsetzung beispielsweise erst der Inhalt (ein Artikel) und dann später, ganz weit unten, zusätzliche „Rand“-informationen kommen, die auf einem breiten Display nebeneinander stehen würden. Im Containermodell wird versucht, diese räumliche Nähe der Inhalte beizubehalten.

Wie so viele Sachen hört sich das erstmal nicht sehr spektakulär an, in der Konsequenz der Umsetzung macht es dann aber doch einen Unterschied. Ich stelle mir vor, dass dieser Grundgedanke die Redakteure vom festen Gerüst des Template-Denkens befreit und dazu zwingt, sich jeweils passende Zusammenstellungen von Inhalten und Teaser und anderen Elementen zu überlegen.

Das führt mich dann auch zum nächsten interessanten Punkt an diesem Projekt: Spezielle Aufgaben bedürfen spezieller Werkzeuge. Für die Guardian-Website wurde eigens ein CMS entwickelt, welches dann sicherlich diesen Workflow und das Layoutmodell nahtlos unterstützt. Zum Back-End habe ich bis auf einen Mini-Screenshot in [3] keine Bilder gefunden. Im Entwickler-Blog [1] findet man dagegen Infos zum verwendeten Editor scribe, der ebenfalls für dieses Projekt entwickelt wurde.

Die neue Website wurde von einem hausinternen Team entwickelt, welches sich für Workshops externe Kollegen dazuholte. „As part of our product discovery process the team ran several ideation workshops with colleagues in editorial and commercial, as well as involving Information Architects, a design agency with experience in digital news. It was during these workshops with Oliver Reichenstein and Konstantin Weiss of iA where the concept of containers and the container model really came to life.“ [2]

Ich bin gespannt, wie sich die Website im Laufe der Zeit weiterentwickelt. Wenn ich mal vier zufällig aus verschiedenen Ressorts herausgepickte Artikelseiten vergleiche, dann sehe ich schon, dass es natürlich ein Repertoire an mehr oder weniger festen Blöcken gibt, die immer wieder – auch in ähnlicher Anordnung – benutzt werden. Ich nehme an, die Leser sollen auch nicht durch zu viel Vielfalt verunsichert werden.

Quellen und weiteres Material:

• [1] 20. MAR 2014 Über das Guardian CMS im Developer Blog http://www.theguardian.com/info/developer-blog/2014/mar/20/inside-the-guardians-cms-meet-scribe-an-extensible-rich-text-editor
• [2] 06 JUN 2014: http://next.theguardian.com/blog/container-model-blended-content/
• [3] 28 JAN 2015: https://www.journalism.co.uk/news/key-principles-behind-the-new-guardian-website/s2/a563921/
• [4] http://www.designweek.co.uk/analysis/guardian-launches-new-website-to-complete-multi-platform-redesign/3039716.article
• [5] http://www.theguardian.com/help/insideguardian/2015/jan/28/welcome-to-the-new-guardian-website

27.02.2015 | Noch keine Kommentare

Responsive Tables – Flexibel reagierende Tabellen

Um breite bzw. komplexe Tabellen auch auf kleinen Monitoren zugänglich zu machen, gibt es verschiedene Möglichkeiten. In einem unserer Projekte haben wir vor einiger Zeit eine reine CSS-Lösung angewendet, die hier kurz dokumentiert wird.

Wie der Kulturbanause in einem Beitrag so schön zusammengefasst hat, kann man das Problem auf verschiedenen Wegen lösen:

1. Zoom ermöglichen
2. Scrolling mit festem Tabellenkopf anbieten
3. Platz sparen – was man sowieso für kleine Monitore machen sollte
4. Inhalte abkürzen/ zusammenfassen
5. Inhalte umstrukturieren (mit CSS und/oder Javascript)

Wir haben uns für Option 5 auf reiner CSS-Basis entschieden, hier der Quelltext:

<table>
  <thead>
    <tr>
      <th>Datum</th>
      <th>Ort</th>
      <th>Veranstaltung</th>
      <th>Sachgebiet</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>20.08.2014</td>
      <td>Düsseldorf</td>
      <td>Architektenkammer Nordrhein-Westfalen<br>Bauüberwachung und Recht</td>
      <td>Rechtliche Aspekte</td>
    </tr>
    <tr>
      <td>20.08.2014</td>
      <td>Düsseldorf</td>
      <td>Architektenkammer Nordrhein-Westfalen<br>Brandschutzkonzept – Trainingsseminar – Veranstaltungsreihe Brandschutz</td>
      <td>Sachverständigenwesen</td>
    </tr>
    <tr>
      <td>20.08.2014</td>
      <td>Düsseldorf</td>
      <td>Architektenkammer Nordrhein-Westfalen<br>Die neue HOAI 2013 – Was Sie bei Vertragsgestaltung und Honorarabrechnung beachten müssen</td>
      <td>Kaufmännische Grundlagen/ Büroorganisation</td>
    </tr>
  </tbody>
</table>

Desktop first :)

Mittlerer Screen

@media only screen and (max-width:640px) {
	table, thead, tbody, th, td, tr { 
		display:block; 
	}
	thead {
		/* optisch versteckt, 
		aber für Screenreader zugänglich */
		tr {
			border:0;
			clip:rect(0 0 0 0);
			height:1px;
			margin:-1px;
			overflow:hidden;
			padding:0;
			position:absolute;
			width:1px;
		}
	}
	td { 
		position:relative;
		padding-left:50%; 
	}
	td:first-child {
		padding-left:50%;
	}
	td:before { 
		position:absolute;
		top:0.5em;
		left:0;
		width:45%; 
		padding-right:5%;
		white-space:nowrap;
	}
	td:nth-of-type(1):before { content:"Datum"; }
	td:nth-of-type(2):before { content:"Ort"; }
	td:nth-of-type(3):before { content:"Veranstaltung"; }
	td:nth-of-type(4):before { content:"Sachgebiet"; }
}

Kleiner Screen

@media only screen and (max-width:480px) {
	td { 
		padding-left:0; 
	}
	td:first-child {
		padding-left:0;
	}
	td:before { 
		top:0;
		width:0; 
		padding-right:0;
	}
	td:nth-of-type(1):before { content:""; }
	td:nth-of-type(2):before { content:""; }
	td:nth-of-type(3):before { content:""; }
	td:nth-of-type(4):before { content:""; }
}

Fazit

Für diese kleine Tabellen-Umorganisation war die CSS-Lösung ganz gut, ließ sich schnell implementieren und funktioniert auch, soweit ich das bisher gesehen habe, überall. Für wirklich große Tabellen würde ich aber auf eine komfortablere Lösung mit Javascript setzen – am besten natürlich so, dass der Nutzer sich selbst aussuchen kann, welche Spalten er in welcher Reihenfolge braucht, welche ausgeblendet werden sollen, ob der Tabellenkopf links oder oben steht und so weiter.

Projekt

Fortbildungsportal der Architektenkammern der Länder
Auftraggeber: Bundesarchitektenkammer, Berlin
www.architekten-fortbildung.de

Links

zu jQuery-basierten Javascript-Lösungen, die ich aber beide nicht ausprobiert habe:

• github.com/bradvin/FooTable
• github.com/paulopmx/Flexigrid

20.08.2014 | 1 Kommentar

Bildbehandlung in flexiblen Layouts

Unser Ansatz zum Thema adaptive/responsive images

Problematik: bestmögliche Bildqualität bei optimalen Ladezeiten. Auslieferung unterschiedlicher Bildgrößen für Desktop oder Smartphone.

Bildauslieferung im Grid-System (wie es bisher war)

Bei Seiten mit festen Layouts (z.B. www.architekten-thueringen.de, 24er-Grid nach dem 960 Grid System) ist von vornherein durch das Template klar, welche Bildgrößen benötigt werden, z.B: Projekt-Kurzansicht (grid6 = 230px), Projektdetailseite, Bild über ganze Inhaltsspalte (grid12 = 470px), Großansicht in der Lightbox (grid18 = 710px) und so weiter.

Diese Größen werden in der Projekt-Konfiguration festgelegt:

$GLOBALS['imageSizesReceiver']['grid_3'] = array(110,110);
$GLOBALS['imageSizesReceiver']['grid_4'] = array(150,150);
$GLOBALS['imageSizesReceiver']['grid_5'] = array(190,190);
$GLOBALS['imageSizesReceiver']['grid_6'] = array(230,230);
$GLOBALS['imageSizesReceiver']['grid_12'] = array(470,470);
$GLOBALS['imageSizesReceiver']['grid_18'] = array(710,710);
$GLOBALS['imageSizesReceiver']['grid_24'] = array(950,950);

Beim Hochladen eines Bildes in das CMS werden die entsprechenden Bildgrößen sofort berechnet und im Dateisystem abgelegt. Beim Ausliefern der Seite werden dann jeweils die richtigen Bildgrößen an der richtigen Stelle angezeigt.

Bildauslieferung im flexiblen Layout (das ist neu)

Für das Webdesign unserer flexiblen Layouts (z.B. www.baukultur-thueringen.de) gehen wir einen anderen Weg. Hier ändert sich die benötigte Bildgröße nicht nur nach der Stelle der Verwendung des Bildes im Template, sondern auch noch je nach Ausgabegerät.

Beispiel-Seite mit verschiedenen Bildgrößen und flexiblem Layout

Wir gehen vom Template für den großen Monitor aus und definieren Bildgrößen für die verschiedenen Layoutboxen (volle Breite, halbe, drittel, viertel, sechstel, usw.) Für die kleineren Bildschirme werden diese Breiten in die jeweilig gewünschte Breite übersetzt (so wird z.B. aus einer halben Box auf dem Desktop eine ganze Box auf dem Smartphone, aus einer Viertelbox eine Halbe, etc.)
Die entsprechende Tabelle in unserer Konfiguration sieht dann so aus:

$GLOBALS['imageSizes']['full']=array(1600=>960, 1024=>960, 768=>768, 480=>480);
$GLOBALS['imageSizes']['half']=array(1600=>480, 1024=>480, 768=>480, 480=>320);
$GLOBALS['imageSizes']['third']=array(1600=>768, 1024=>768, 768=>480, 480=> 320);
$GLOBALS['imageSizes']['twothirds']=array(1600=>768, 1024=>768, 768=>480, 480=>320);
$GLOBALS['imageSizes']['quarter']=array(1600=>240, 1024=>240, 768=>480, 480=>320);

Auch die Behandlung der Bilder im CMS (Akira) erfolgt nun anders. Beim Hochladen wird nur das Originalbild im Filesystem abgelegt. Die Skalierung erfolgt erst bei der Auslieferung einer Seite – das skalierte Bild bleibt im Filesystem liegen. Das hat jeweils beim ersten Aufruf eines Bildes in einer bestimmten Auflösung eine kleine Verzögerung zur Folge. Alle weiteren Aufrufe nutzen dann das vorgerechnete Bild.

Im Seitenheader ermitteln wir das Ausgabegerät über Javascript und legen diese Angabe in einem Cookie ab.

<script>document.cookie='resolution='+Math.max(screen.width,screen.height)+'; path=/';</script>


Damit wird also beim ersten Laden der Seite auf einem Gerät festgelegt, welche Bildgrößen ausgeliefert werden und das bleibt dann (auch trotz Änderung der Browsergröße erhalten). Der Desktop ist hier ein Sonderfall, weil nur dort Größenänderungen Sinn möglich sind. Auf Mobilgeräten lade ich die Seite ja immer mit der gleichen Auflösung.

Noch eine kleine Abgrenzung zum Schluss: Wir haben hier nicht nach einer Lösung für vollflächige Hintergrundbilder gesucht, die beim Browser resizing dynamisch nachgeladen werden. Im Vordergrund steht bei uns die effektive Darstellung und Auslieferung von Bildern im Seiteninhalt.

Weitere Ansätze für responsive images in einem Artikel bei speckyboy design magazin

26.11.2012 | 5 Kommentare