Frank Chimero spricht in einem Vortrag im Oktober 2017 bei der Mirror Conf in Braga über die steigende Komplexität in der Webentwicklung und wiederkehrende Verwirrtheit in Bezug auf technologische Neuerungen und Möglichkeiten. Seine Schilderung finde ich vor allen Dingen dahingehend spannend, dass es mir in vielerlei Hinsicht ähnlich geht.
Frank Chimero spricht in seinem Vortrag »Everything Easy is Hard Again« im Oktober 2017 bei der Mirror Conf in Braga über die steigende Komplexität in der Webentwicklung und wiederkehrende Verwirrtheit in Bezug auf technologische Neuerungen und Möglichkeiten. Seine Schilderung finde ich vor allen Dingen dahingehend spannend, dass es mir in vielerlei Hinsicht ähnlich geht.
Er erläutert die Veränderung bei der Entwicklung von Web-Layouts und von dem Gefühl, dass es sich alle fünf Jahre so anfühlt als würde man noch einmal von vorne beginnen,1 nachdem man sich gerade in die aktuelle Technologie eingearbeitet hat. Ab Mitte der 90er Jahre war die Gestaltung mithilfe von Tabellen üblich; später waren es Floats, Flexbox oder CSS Grid, welche auch in Kombination verwendet werden können.
Zudem spricht er von der Tatsache, dass Methoden, die Tabu waren plötzlich zu den Empfehlungen gehören. Hier nennt er das Beispiel, dass er einen Artikel gelesen hat, in dem es um die Vorteile geht, keine Stylesheets, sondern Inline-Styles zu verwenden.2 Ich selbst hing auch schon an diesem Punkt als ich das erste mal von »above the fold« hörte und eine Seite nach diesem Konzept verbessern sollte.
Ähnlich wie Chimero gab es bei mir immer wieder – wenn auch riesengroße – Lücken bei der Entwicklung von Webseiten. Nachdem ich meine ersten Webseiten im Jahr 2000 erstellte, habe ich mich jahrelang nicht mehr im Detail damit beschäftigt. Hier und da nur Versuche bis ich mich mit Beginn meiner Ausbildung 2007 wieder angenähert habe. Durch kleine statische Seiten oder die Betreuung von Seiten via Content Management Systeme wurde es wieder wärmer, doch den richtigen Sprung habe ich nicht mehr geschafft. Erst mit dem Beginn meines Studiums hatte ich immer wieder die Motivation, »das jetzt endlich richtig lernen zu wollen«. Es ging damit los, Floats richtig zu verstehen und plötzlich gab es dieses Responsive Webdesign, welches vieles durcheinander brachte: Pixel, em, rem oder Prozent? Fluid, Adaptiv, was? Und nach kurzer Pause gab es mit Flexbox plötzlich wieder etwas Neues. Ist das zusätzlich? Oder alternativ? Die meiste Zeit verbrachte ich wohl damit, zu verstehen, was wie und warum verwendet wird.
Mit meinen Kenntnissen war es bisher kein Problem, kleinere Webprojekte umsetzen, doch vor wenigen Wochen habe ich mich entschieden, tiefer eintauchen zu wollen. Ich habe damit begonnen bei #100daysofcode mitzumachen, um zu sehen, was passiert, wenn ich jetzt länger am Ball bleibe. Dabei geht es darum, sich eigene Ziele zu setzen und 100 Tage lang mindestens eine Stunde täglich zu üben und zu lernen. Es ist erstaunlich wie viel man in so kurzer Zeit lernen kann und ich hoffe trotz Master-Arbeit dran bleiben zu können. Vor allem wünsche ich mir, nicht wie bisher demotiviert zu sein, sobald es in JavaScript zu sehr ins Detail geht.
Der Vortrag von Frank Chimero inspiriert und motiviert mich dahingehend, dass es aus seiner Sicht egal sein könnte, ob man direkt aus der Schule kommt oder 20 Jahre Erfahrung mitbringt. Man könnte an der gleichen Stelle landen, nämlich im ersten Jahr, in dem man Webseiten erstellt.3 Und das ist immerhin ein hervorragender Anfang für viele weitere Jahre.
Gestern ging die Webseite Laws of UX (lawsofux.com) von Jon Yablonski online. Er präsentiert damit ein Regelwerk mit den wichtigsten Punkten, die ein Designer beim Erstellen von Benutzeroberflächen berücksichtigen sollte. Eine großartige Arbeit, die theoretische Inhalte hervorragend mit guter Gestaltung verbindet.
Gestern ging die Webseite Laws of UX (lawsofux.com) von Jon Yablonski online. Er präsentiert damit ein Regelwerk mit den wichtigsten Punkten, die ein Designer beim Erstellen von Benutzeroberflächen berücksichtigen sollte.
Meiner Ansicht nach punktet er dabei nicht nur mit den Inhalten bzw. den Regeln selbst, sondern setzt sie zusätzlich großartig in Szene.
Gelangt man auf die Seite sieht man bildschirmfüllend lediglich eine grafische Karte mit dem Titel der jeweiligen Regel, einen kurzen erklärenden Text sowie einen Button mit »Learn more«. Dezent im Hintergrund – Ton in Ton – erscheint die Ordnungsnummer der Regel sowie ein grafisches Element. In dieser Ansicht kann man sich durch die einzelnen Regel-Teaser scrollen. Eine seitliche Navigation verweist auf soziale Netzwerke, über das Burger-Menu erreicht man die Navigation, die alle Inhalte im Überblick zeigt.
Laws of UX – Fitt‘s LawIILaws of UX – Law of ProximityIIILaws of UX – Miller‘s LawIVLaws of UX – Serial Position EffectVLaws of UX – NavigationVI
Klickt man sich in eine Regel, sind – wieder bildschirmfüllend – eine Farbfläche im Hintergrund, der Titel, die Ordnungsnummer sowie dezente grafische Elemente zu sehen. Der Aufbau vollzieht sich dabei in zurückhaltenden, wirkungsvollen und meiner Ansicht nach visuell sehr ansprechenden Animationen.
Scrollt man nun weiter, erhält man einen bei allen Regeln den strukturell gleichen Überblick über sie. Die »Übersicht«, den »Ursprung« sowie weitere Leseempfehlungen.
Laws of UX – Fitt‘s LawVIILaws of UX – Miller‘s LawVIIILaws of UX – Miller‘s LawIX
Insgesamt halte ich das Projekt für eine großartige Arbeit, die zeigt wie man theoretische Inhalte visuell ansprechend inszenieren kann. Generell fällt mir auf, dass mir vor allem die Arbeiten im Gedächtnis bleiben, die sowohl mit theoretischen Inhalten als auch mit hervorragender Gestaltung bzw. Umsetzung hervorstechen. Dazu gehören beispielsweise auch »In Pieces« von Bryan James oder »Pulse« von Markus Kison. Mit »theoretischen Inhalten« meine ich dabei nicht allein Daten, die so auch auf Unternehmenswebseiten oder ähnlichen auftauchen können. Ich verstehe darunter ein gut recherchiertes Thema dessen Hauptinhalte durch gute Gestaltung fokussiert und in Szene gesetzt werden. So basiert »In Pieces« beispielsweise auf dem Wissen über bedrohte Tierarten, »Pulse« dagegen auf einer Emotionstheorie von Robert Plutchik aus dem Jahr 1980.
Diese Arbeiten sowie das aktuelle Projekt von Jon Yablonski verdeutlichen mir im Bezug auf meine Masterarbeit zunehmend, welche Schwerpunkte für mich immer bedeutender werden.
Abbildungen
Titelbild: Eigener Screenshot; Yablonski, Jon: »Laws of UX«, URL: http://lawsofux.com, abgerufen am 16.1.2018.
Eigener Screenshot; Yablonski Jon: »Laws of UX«, URL: http://lawsofux.com, abgerufen am 16.1.2018.
Mein Master-Projekt wird nun immer konkreter. Nach meiner bisherigen Recherche zur Entwicklung des World Wide Web, präzisiert sich meine Vorstellung, welche theoretische Auseinandersetzung und welche praktische Umsetzung Teil meiner Arbeit werden können.
Mein Master-Projekt wird nun immer konkreter. Nach meiner bisherigen Recherche zur Entwicklung des World Wide Web, präzisiert sich meine Vorstellung, welche theoretische Auseinandersetzung und welche praktische Umsetzung Teil meiner Arbeit werden können.
Die erste Fragestellung innerhalb meines Master-Studiums beinhaltet bereits erste Gedanken meines jetzigen Ansatzes. Nichtsdestotrotz habe ich sehr breit recherchiert, da mir auf meinem Weg unzählige spannende Themen begegnet sind, die mich stets in eine neue Richtung gelenkt haben. Ich hatte viele Ideen von zu plump bis zu komplex und habe enorm viel Kraft in die theoretische Arbeit gesteckt. Ich habe viel gelesen und recherchiert, viel geschrieben und verworfen.
Während meiner Master-Zeit hatte ich ab und an das Gefühl den Wagen fälschlicherweise von hinten aufzurollen. Habe mich aber aus Leidenschaft nicht davon abbringen lassen.
Ich habe mir kein Thema XY ausgesucht für das ich nun ein passendes Medium für die praktische Umsetzung suche, sondern ich beschäftige mich von Anfang an mit dem Medium selbst. So liebe ich beispielsweise Netzkunst, weil sie oft eine besondere Art hat mit dem Medium Web umzugehen und eine außergewöhnliche, visuelle Sprache spricht. Ich interessiere mich für die Auflösung virtueller und nicht-virtueller Grenzen, die Veränderung der Gesellschaft durch die virtuelle Welt und für die Theorien von beispielsweise Flusser und McLuhan. Ich bin überzeugt davon, dass sich Schnittstellen zunehmend auflösen und eine neue Art der Kommunikation entsteht. Ich bin begeistert von neuen Technologien und mich bewegen Projekte, die Theorie und Praxis lückenlos verschmelzen.
Letztendlich merke ich jedoch, dass meine Gedanken häufig um ähnliche Themen kreisen. Dazu gehören wiederkehrend die Anfänge und die Entwicklung des World Wide Web, die mich sowohl visuell, technologisch als auch kulturell interessieren. Das Medium selbst wurde lange wie eines behandelt, das ausschließlich die nicht-virtuelle Welt in die virtuelle überträgt. Webseiten waren »Schaufenster« des realen Lebens, Buttons waren zum Teil rote Knöpfe mit Schrift und Baustellenschilder zeigten, dass die Webseite noch in Bearbeitung ist. Das Verständnis für das Medium wächst zunehmend und wir wissen zwischenzeitlich, dass Webseiten so gut wie immer »under construction« sind. Zum einen kann aus meiner Sicht erst eine spezifische, visuelle Sprache für ein Medium entwickelt werden, sobald das Medium verstanden wird – sprich, dass das Web kein Buch ist. Auf der anderen Seite frage ich mich, ob nicht gerade dieser spielerische Umgang mit einem unbekannten Medium – wie er in den 90er Jahren stattfand – die unantastbarste und »originalste« Sprache von allen spricht.
In meiner bisherige Recherche zeigt sich, dass sich die visuelle Sprache immer weiter von der materiellen Welt entfernt und sich das Web zunehmend zu einem eigenen Medium entwickelt. Neben visueller und kultureller Veränderungen, halte ich hierfür auch die technologischen Entwicklungen für sehr wichtig. So nutzte man teils solange wie nötig die default styles für z.B. Buttons und ersetzt sie nach und nach mit Grafiken und letztendlich Code.
Der bisher stärkste Ansatz ist meiner Ansicht nach eine Ausstellung anlässlich des 25-jährigen Jubiläums des freien Webs. Dabei kann ich mir zum einen eine interaktive Webausstellung vorstellen, aber auch eine nicht-virtuelle Exhibition mit gebauten Räumen voller Sternenhimmeltapeten und MIDI-Sound. Die Ausstellung könnte die Entwicklung des Web zeigen. Dabei wären aus meiner Sicht die visuellen Veränderungen im Vordergrund.
Ich möchte zum einen schon zum Teil gesammelte und katalogisierte UI-Elemente zusammenführen, um grafische Veränderungen deutlich zu zeigen. Die Elemente stammen dabei von verschiedenen Unternehmen, die auch in der Wayback Machine des Internet Archive zu finden sind: https://archive.org/web/. Ein erster Ansatz der Auswahlkriterien ist in meinem Beitrag »Evolution der Webästhetik« zu finden. Dabei steht noch offen, ob diese – dem Plan nach mehrere tausend – Elemente im Zentrum stehen oder einfach nur ein Pattern für die Ausstellung darstellen könnten. Zudem soll eine inhaltlich-kulturelle Komponente hinzukommen, die ich noch erarbeiten muss und eine poetische Ebene enthalten kann. Eine weitere Komponente könnte die Frage nach dem Danach sein, da ich mir unter anderem die Frage stelle, ob grafische Benutzeroberflächen durch neue Technologien wie z.B. Voice Interfaces ersetzt werden können.
An dieser Stelle wird mein Titel »Digitale Primaten« wieder mit der anfänglichen Bedeutung belegt. Nämlich, dass Menschen der Technologie noch immer hinterherhinken und wohl auch nicht mehr aufholen werden. Mein gewählter Arbeitstitel ist »digital primates – evolution of a medium« in englischer oder deutscher Form.
Vor längeren bin ich bereits auf das Carbon Design System aufmerksam geworden. Da vor kurzem ein Interwiew mit Bethony Sonnenfeld, Design Lead bei IBM, veröffentlicht wurde, habe ich nochmals mit dem System auseinandergesetzt. Carbon ist ein Designsystem, das für die Produkte der IBM Cloud entwickelt wurde.
Vor längeren bin ich bereits auf das Carbon Design System aufmerksam geworden. Da vor kurzem ein Interwiew mit Bethony Sonnenfeld, Design Lead bei IBM, veröffentlicht wurde, habe ich mich erneut mit dem System auseinandergesetzt.
Carbon ist ein Designsystem, das für die Produkte der IBM Cloud entwickelt wurde. Nachdem anfänglich nur ein überarbeitetes System für IBM Bluemix eingeführt werden sollte, wuchs der Wunsch, dass Carbon ein allgemeines, produktunabhängiges System wird. Im März 2016 wurde mit dem Umbau begonnen, seit Juni 2016 gibt es die Version 6.0, im Oktober 2017 wurde die aktuelle Version 8 des Systems veröffentlicht.
Im Interview mit Jason Grant stellt Bethony Sonnenfeld die Herangehensweise bei der Überarbeitung bzw. Neugestaltung des Systems vor. Sie erläutert die Motivation und Denkweise, sowie den Prozess selbst. Zwei für mich wichtige Punkte sind dabei die Verhaltensregeln sowie die Dokumentation. Die Verhaltensregeln zeigen, auf welchen Wegen und in welcher Art und Weise bestenfalls kommuniziert wird. Das betrifft unter anderem die zwischenmenschliche Umgangsweise. So wird beispielsweise auf die Selbstverständlichkeit hingewiesen, dass man trotz unterschiedlicher Ansichten respektvoll miteinander umgehen sollte. Zusätzlich schafft eine Übersicht der möglichen Kontaktmöglichkeiten Klarheit und vermeidet eine chaotische Kommunikation auf diversen Kanälen.
Die Dokumentation klärt viele Fragen rund um das Carbon Design System. Zu jedem Element gibt es Informationen, so dass viele Fragen überflüssig werden und bestenfalls auf allen Seiten Zeit eingespart wird.1 Dabei ist nicht nur ein reibungsloser Arbeitsauflauf wichtig. Wie Alla Kholmatova in ihrem Buch »Design Systems – A practical guide to creating design languages for digital products.« schon festhält, ist es vor allem in größeren Teams wichtig, die Elemente eindeutig festzulegen. Das verhindert beispielsweise, dass doppelte Bausteine aus unklaren oder unvollständigen Vorgaben entstehen und das System inkonsistent wird.
Für einen weiteren wichtigen Punkt halte ich die Nutzung von GitHub. Der Prozess ist sehr kontrolliert festgelegt, es müssen stets zwei Designer Änderungen absegnen. Damit kann trotz der Zusammenarbeit vieler sichergestellt werden, dass das System konsistent bleibt und den Spezifikationen entspricht.
Bethony Sonnenfeld betont, dass die Auswahl eines vorhandenen Designsystems von der persönlichen Präferenz abhängt. Sie basieren beispielsweise auf verschiedenen JavaScript-Softwarebibliotheken und als Unerfahrene würde sie ein System auswählen, das eine gute, saubere Code-Basis besitzt sowie User Experience-Richtlinen anbietet. Viele Systeme zeigen laut ihr viel zu wenig Anwendungsbeispiele, so dass man es als Nicht-Designer in der Umsetzung sehr schwer hat.2 Wobei ich mir hier die Frage stelle, wie »einfach« solche Systeme wirklich angelegt werden müssen. Aus meiner Sicht sollen sie den Arbeitsablauf von Designern und Entwicklern effizienter und schneller gestalten, die Berufe an sich jedoch nicht völlig ersetzen.
Mir persönlich gefällt das Carbon Design System vor allem im Hinblick auf das synchronisierte Arbeitsmaterial für Designer und Entwickler. Für Designer gibt es beispielsweise eine Sketch-Datei, die alle Elemente enthält. Für Systeme bzw. Frameworks wie Bootstrap gibt es zwar unzählige Sketch-Dateien im Web zu finden, dabei sind aber sicherlich nicht alle vollständig, sauber angelegt und vor allem nicht stets synchron. Abschließend finde ich es sehr spannend einen näheren Einblick in den Prozess erhalten zu haben, da er verständlich macht wie lange die Entwicklung eines solchen Systems inklusive der einzelnen Versionen und Verbesserungen benötigen kann. Das wirkt zum einen abschreckend, da in dieser Zeit natürlich auch die nötigen Ressourcen bereitgestellt werden müssen. Auf der anderen Seite zeigt es den zwischenzeitlich standardisierten Ablauf vieler Produkte, die erst auf den Markt gelangen, um dann stetig verbessert zu werden.
Quellen
Vgl. Sonnenfeld, Bethony, Integral: »UX Design Interview With Bethany Sonnenfeld, Design Lead at IBM for Carbon Design System«, URL: https://www.youtube.com/watch?v=HI-hvAjQc4A, TC: 00:13:50–00:15:15, abgerufen am 27.12.2017.
Das WordPress-Theme »The Ark« wird als »Best Rated Theme of All Time« angepriesen – aus meiner Sicht nicht umsonst. Mich hat in den letzten Jahren kein Theme so sehr überzeugt, weshalb ich meine Erfahrung teilen möchte.
Heute möchte ich dem WordPress Theme »The Ark« einen Beitrag widmen. Warum? Jahrelang habe ich mal mit guten, mal mit schlechten Themes gearbeitet und bisher hat mich keins so sehr überzeugt. Ich denke, dass es nicht umsonst als »Best Rated Theme of All Time«1 angepriesen wird. Der Beitrag basiert dabei auf persönlichen Erfahrungswerten und soll kein Tutorial darstellen.
Zu Beginn sei gesagt: Das Frustrationslevel liegt erstmal sehr hoch. Der Aufbau ist – bis hierhin – sehr unüblich und man weiß nicht, wo man was ändern und einstellen muss, um zum gewünschten Ergebnis zu kommen. Zusätzlich hatte ich bei der ersten Website, die ich mit diesem Theme umgesetzt habe (literaturarchiv1968.de), große Probleme damit, dass die (tatsächlich nur gefühlte) Standard-Antwort des Supports die war, dass custom code benötigt wird. Das Problem war hier nicht, dass ich es nicht per Code lösen hätte können, sondern dass ich mich ständig gefragt hatte, wofür ich ein so umfangreiches Theme mit scheinbar unzähligen Elementen benötige, wenn ich ohnehin die Hälfte selbst coden muss. Zum einen weiß ich nun, dass die Seite nach sehr vielen individuellen Lösungen verlangt hat. Zum anderen hat sich seitdem sehr viel durch Updates getan. Das Entwicklerteam ist dabei ein besonderes Plus. Die Antwortzeiten sind unheimlich kurz, das Team unheimlich hilfsbereit und die Entwickler stehen im ständigen Dialog mit der Community, um das Theme stetig zu verbessern. Das bedeutet natürlich gleichermaßen, dass es an einigen Stellen noch Verbesserungsbedarf hat.
Benutzeroberfläche im Bereich Sitemap
Der Aufbau
Grundsätzlich baut das mobile-first-Theme auf Bootstrap auf, so dass zumindest die Logik sehr einfach zu verstehen ist. Des Weiteren arbeitet es mit dem »Fresh Builder« – einem sehr eingängigen page builder, mit dem man die Webseite via Klicks aufbaut. Dabei kann man nicht nur sehr schöne, sondern auch sehr gut funktionierende Websites in kürzester Zeit erstellen. Die Möglichkeiten sind dabei wohl unbegrenzt, da man sich die sections entweder selbst aus unzähligen Elementen zusammenstellt oder vorgefertigte section blocks als Vorlage verwendet. Jedes einzelne Element hat dabei viele, zusätzliche Einstellungsmöglichkeiten. Durch die global styles können ähnlich wie bei SketchApp Stile angelegt werden, die per Klick eingefügt werden. Zum Verständnis: Man kann sich damit beispielsweise eine große Headline anlegen, der wiederum durch Klicks einzelne, selbst zu erstellende Komponenten wie font-size, line-height, etc. zugeordnet werden. Dieses gesamte Headline-Element ordnet man nun den Überschriften zu, die so aussehen sollen. Zudem können zum einen Abschnitte wie Header, Footer oder die Titlebar mit dem Fresh Builder aufgebaut werden. Zum anderen Seiten, die man via Sitemap gestaltet. In der Sitemap können die einzelnen Seitentypen (Blog Archive, Blog Single, Page, …) global angelegt werden, so dass sie nicht wie in den meisten Themes über die PHP-Dateien geändert werden. Selbst die Übersetzungen durch das PlugIn WPML, eigene Felder durch das PlugIn ACF oder die Verwendung der sections für custom post types funktionieren hervorragend.
Auswahlmenü der Elemente
Das Grundprinzip Einfachheit
Vor allem die Funktionalität und Gestaltungsfreiheit spricht aus meiner Sicht für The Ark. Bisher hatte ich die Erfahrung, dass Themes häufig sehr eingeschränkt sind. So sehen sie auf den ersten Blick gut aus und spätestens beim mobilen Design müsste man die ganze Seite – aus visueller Sicht – neu schreiben. Ein weiteres Problem hatte ich häufig durch die Begrenztheit der Elemente. Zwar kann man bei der Entwicklung sehr viel selbst einbauen und z.B. für die einfache Bedienung durch den Kunden eigene Felder erstellen. Jedoch bin ich der Meinung, dass das Grundprinzip von WordPress Einfachheit bedeutet und die wird bei The Ark von Haus aus mitgeliefert.
Durch weitere Projekte wird mir das Theme immer zugänglicher und es ist erstaunlich, wie effizient man damit arbeiten kann. Alles in allem, trotz einiger Mankos, ein absolut empfehlenswertes Theme. Also ab, online mit euch: Klick Klick – Hallo Welt!
Im Anschluss an meinen Text »Von der No-Layout-Ära zur wiedergewonnenen Fluidität des Webs« möchte ich mich kurz und knapp mit einem Artikel von Ethan Marcotte aus dem Jahr 2010 beschäftigen. Marcotte, Begründer des Terminus »Responsive Web Design«, beschreibt darin seinen Ansatz, Webseiten unabhängiger von ausgewählten Endgeräten zu entwickeln.
Im Anschluss an meinen Text »Von der No-Layout-Ära zur wiedergewonnenen Fluidität des Webs« möchte ich mich kurz und knapp mit einem Artikel von Ethan Marcotte aus dem Jahr 2010 beschäftigen. Marcotte, Begründer des Terminus »Responsive Web Design«, beschreibt darin seinen Ansatz, Webseiten unabhängiger von ausgewählten Endgeräten zu entwickeln. Er verfolgt dabei den Vorschlag mit Media Queries zu arbeiten, auf welche ich an dieser Stelle nicht weiter eingehen möchte. Sie sind zwischenzeitlich zum Standard-Werkzeug responsiver Gestaltung geworden.
Viel reizvoller finde ich seine Verknüpfung zwischen »responsive architecture« und der Gestaltung im Web. Dabei geht es grundsätzlich um die Frage, »wie physische Räume auf die Anwesenheit von Passanten reagieren können«1. Mit Bezug auf das Buch Interactive Architecture von Michael Fox und Miles Kemp, kristallisiert er den feinen Unterschied heraus: Es geht nicht darum unveränderliche Räume zu schaffen, sondern darum, dass sich die Nutzer und die Struktur gegenseitig beeinflussen können.2 Das ist vor allen Dingen wichtig, da das Web ein vergängliches Medium ist. Innerhalb weniger Jahre ändern sich Fensterbreiten, Bildschirmauflösungen, Benutzereinstellungen oder installierte Schriftarten.3 Viel mehr spricht er sich dagegen aus, das Design auf immer mehr unterschiedliche Endgeräte zuschneiden zu wollen. Er ist überzeugt davon, dass wir als Webdesigner »ein optimales Seherlebnis entwerfen und standardbasierte Technologien in unser Design einbetten können, um sie nicht nur flexibler zu machen, sondern auch an die Medien anzupassen, die sie rendern«4. Nur so kann man effektiv mit der Tatsache arbeiten, dass sich die Landschaft an angebotener Betrachtungsmöglichkeiten enorm schnell ändert.5
Wichtig ist Marcotte dabei nicht nur das visuelle Ergebnis, sondern auch die Möglichkeit die Benutzerfreundlichkeit verbessern zu können. So kann beispielsweise Fitts’ Gesetz über Touch-Geräte besser umgesetzt werden.6
Die drei technischen Zutaten für RWD
Als primäre Zutaten zur Umsetzung von responsiven Webdesigns sieht Marcotte flüssige Raster, flexible Bilder und Medienabfragen. Zudem ist eine andere Denkweise in Bezug auf das Medium erforderlich,7 das sich letztendlich sehr stark vom Printdesign unterscheidet und somit sehr viele neue Herausforderungen an den Gestalter herangetragen hat.
Abschließend ist der Ansatz der Media Queries aus heutiger Sicht eine Selbstverständlichkeit. Im Jahr 2010 war die Einführung des »Responsive Web Design« jedoch eine massive Neuerung. Schon zuvor gab es z. B. verschiedene Bildschirmgrößen oder -auflösungen und schon durch das iPhone, das 2007 auf den Markt kam, ist das Bedürfnis gewachsen, flexibler reagieren zu können. Langfristig macht es bei der Masse an Geräten aber natürlich keinen Sinn für jedes separate Versionen zu gestalten. In der Übergangszeit und auch bis heute, sieht man zudem Webseiten, welche komplett abgekoppelt für mobile Endgeräte entwickelt sind und sogar mit einer eigenen Subdomain angesprochen werden. In manchen Fällen macht das sicher nach wie vor Sinn, doch insgesamt sollte im Vordergrund stehen, sich anpassende Seiten zu gestalten, die auch die nächsten Endgeräte überstehen.
In Bezug auf mein Thema finde ich es außerdem sehr spannend, wie sich erneut Technologie, Design und das Bedürfnis der Menschen gegenseitig beeinflussen und Schritt für Schritt in ihrer Evolution voranbringen.
Eines meiner persönlichen Ziele während des Masters ist, mich in den Bereichen HTML und CSS, bestenfalls auch in JS, weiterzuentwickeln. Zurzeit widme ich der noch etwas neueren Spezifikation CSS Grid. Im März habe ich bereits am Meetup »Grids and Glory« von Sven Wolfermann in den Räumen von sipgate in Düsseldorf teilgenommen. Als weitere Grundlage dient mir das Tutorial »CSS Grid First Look« von Morten Rand-Hendriksen aud lynda.com. Generell bin ich gespannt, wie sich die visuelle Ästhetik des Webs in den nächsten Jahren durch diese neue Spezifikation evolviert.
Eines meiner persönlichen Ziele während des Masters ist, mich in den Bereichen HTML und CSS, bestenfalls auch in JS, weiterzuentwickeln. Zurzeit widme ich mich der noch etwas neueren Spezifikation CSS Grid. Im März habe ich bereits am Meetup »Grids and Glory« von Sven Wolfermann in den Räumen von sipgate in Düsseldorf teilgenommen. Als weitere Grundlage dient mir das Tutorial »CSS Grid First Look« von Morten Rand-Hendriksen auf lynda.com.
Nach der ersten Einarbeitung bin ich begeistert von den Möglichkeiten, die CSS Grid mit sich bringt. Zunächst muss man sich an die neue Terminologie gewöhnen, die das CSS Grid mit ins Spiel bringt. So gibt es neben »grid cells«, eine einzelne Zelle eingeschlossen von vier »grid lines«, sogenannte »grid tracks«, die den Bereich zwischen zwei horizontalen oder vertikalen Linien darstellt. Zusätzlich gibt es »grid areas«, die im Grunde aus mehreren zusammenhängenden Zellen bestehen. Es gibt noch weitere Begriffe, die zum Teil aber schon aus bisherigen Rastern bekannt sind.
Benennung von template areas oder grid lines
Neben einer neuen Terminologie gibt es natürlich neue Selektoren. Doch die Beschreibung der Eigenschaften ist das Wesentliche, was für mich wirklich neu ist. So können beispielsweise template areas oder grid lines, in denen die grid cells eingeschlossen sind, benannt werden. Das führt zum einen dazu, dass mithilfe »unserer Sprache« der Code und die einzelnen Bereiche übersichtlicher dargestellt werden. Zum anderen halte ich es jedoch für sehr wichtig, die Freiheit nicht zu sehr auszukosten. Die Benennung sollte eindeutig sein, so dass auch nachfolgende Entwickler die einzelnen Bereiche eindeutig erkennen können und keine Unklarheiten auftauchen. Da aber zum einen schon immer Klassen bzw. IDs selbst benannt werden konnten und zum anderen bereits standardisierte Begriffe für Webseitenbereiche vorhanden sind, sehe ich das nicht als wirkliches Problem.
Zusätzlich zu der Benennung ist die Einführung der repeat()-Funktion eine fundamentale Änderung. Muster können so durch Wiederholungen erstellt werden.
Die neue Einheit fraction
Die Einführung der Einheit »fraction« (fr) ist eine weitere wichtige Neuerung durch CSS Grid. Neben dem Vorteil, dass die ein oder andere Rechenarbeit entfällt, halte ich es vor allem für spätere Anpassungen für enorm wichtig. Soweit mein erster Eindruck stimmt, kann das Grid dadurch sehr schnell nachträglich geändert und z. B. mit zusätzlichen Spalten erweitert werden. Wenn zunächst nur mit der Einheit fr gearbeitet wird, genügt es weitere frs hinzufügen oder die Spaltenzahl durch weniger frs zu reduzieren. Insofern nicht einzelne Spalten pixelgenau oder in Prozenten angegeben sind, entfällt hier jegliche Rechnerei.
Wenn es für das Layout infrage kommt, kann fr selbst mit Angabe von genauen Maßen genutzt werden, da die Einheit grundsätzlich den übrigen Platz in Anspruch nimmt.
Veränderung der semantischen Ordnung durch CSS
Die wohl mächtigste Veränderung ist die Möglichkeit, die semantische Ordnung einfacher durch CSS verändern zu können. Elemente können zielgenau im Grid positioniert und mobile Seiten intuitiver gestaltet werden. Zudem zeigt Morten Rand-Hendriksen ein Beispiel, indem die semantische Ordnung von wichtig nach unwichtig sortiert ist. Ein Promo-Inhalt wird am Ende des HTML-Dokuments platziert, da er für den Inhalt irrelevant ist. Visuell wird er jedoch an den Anfang der Website gesetzt, um die Anzeige prominent zu bewerben.
Ästhetische Evolution durch neue Spezifikationen
Insgesamt ist es erstaunlich wie flexibel CSS Grid funktioniert und ich halte die Spezifikation für eine der größten Neuerungen der letzten Jahre. Mit der Unterstützung von Codecademy, w3schools und CodePen versuche ich noch spezifische Fragen für mich zu beantworten, jedoch bin ich mir sicher, dass man mit einiger Einarbeitung, sehr viel schneller äußerst flexible Grids erstellen kann. Aus visueller Sicht erhoffe ich mir zunehmend flexiblere Layouts, weg von dem Einheitsbrei der letzten Jahre. Selbst mit Frameworks wie Bootstrap kann man natürlich abweichende Layouts entwickeln, doch landet man viel zu oft an der einheitlichen Aufteilung von 2 bis 4 Spalten in der Desktopansicht, sowie der 12-Spaltigkeit bei mobilen Ansichten. Zwar macht diese Einteilung in vielen Fällen Sinn, jedoch bin ich davon überzeugt, dass sich das visuelle Bild des Webs in den nächsten Jahren deutlich ändern wird. Abschließend bin ich zum einen gespannt, in welche Richtung sich sowohl die Spezifikation des CSS Grids als auch das generelle visuelle Erscheinungsbild in den nächsten Jahren evolviert. Zudem bin ich sehr motiviert durch Tutorials, Lernportalen und ähnlichem weiter in die Materie einzutauchen.
In der Episode »Hypercard Maker« von Computer Chronicles aus dem Jahr 1987 stellen Bill Atkinson und Dan Winkler das Hypertext-System HyperCard vor. Das World Wide Web erinnert mich in einigen Eigenschaften stark an HyperCard, weshalb ich das System näher kennenlernen möchte.
In der Episode »Hypercard Maker« von Computer Chronicles aus dem Jahr 1987 stellen Bill Atkinson und Dan Winkler das Hypertext-System HyperCard vor. Zusammen haben sie den Software-Baukasten innerhalb von Apple entwickelt, welcher 1987 veröffentlicht wurde. HyperCard ist eins der ersten funktionierenden Hypermedia-Systeme.
Das World Wide Web erinnert mich in einigen Eigenschaften stark an HyperCard, weshalb ich das System näher kennenlernen möchte.
HyperCard ist ein Informationssystem und besteht aus einzelnen Karten, welche Texte, Grafiken oder Buttons darstellen können. Die Buttons können dabei unter anderem zu weiteren Informationen führen, Anrufe tätigen oder Töne abspielen.1 Das wichtige ist laut Bill Atkinson, dass die Karten sowohl Informationen als auch Interaktionen beinhalten können.2
Die einzelnen Karten werden als »Stacks« gruppiert, die man über Floppy-Disks mit anderen teilen kann.3 Es gibt jedoch auch die Möglichkeit, eigene zu kreieren.4 Die mitgelieferten Templates, »Art Ideas« oder z. B. Button-Librariers unterstützen den Nutzer dabei, eigene Karten und Stacks anzulegen.5
Die Informationen können thematisch organisiert und die Verbindungen zwischen den Karten völlig frei definiert werden.6 So kann man beispielsweise auch Grafiken miteinander verbinden, indem man Buttons auf bestimmte Teile der Grafik legt und zur nächsten Karte mit dem gleichen Inhalt verlinkt. Als Beispiel zeigt Bill Atkinson eine Karte mit einer Pferdekutsche, die bei einem Klick auf das Rad wiederum auf die nächste Karte, die ein Rad enthält, wechselt.7 Durch diese freie Organisation, lassen sich Informationen laut Atkinson sehr eng miteinander verbinden. Auch To-Do-Listen mit Terminen und der Verlinkung zu der dazugehörigen Adresse werden als Beispiel genannt.8
Wichtig ist laut Dan Winkler, dass man für die Arbeit mit HyperCard keine Programmierkenntnisse benötigt, außer man möchte die Buttons selbst modifizieren. Möglichkeiten wären hier z. B. visuelle oder auditive Effekte.9 Sonst ist der unerfahrene Nutzer aber auch in der Lage, Buttons über die Benutzeroberfläche einzubauen.10 Für die Programmierung von Buttons wird die Sprache Apple HyperTalk benutzt. Über eine Box, die an das Terminal erinnert, können in dieser Sprache beispielsweise Kalkulationen oder Kommandos abgefeuert werden.11
HyperCard erinnert mich wie anfangs schon erwähnt sehr an die Struktur des World Wide Webs. Zwar ist es kein offenes System, doch die freie Organisation der Informationen fällt mir primär auf. Wie Tim Berners-Lee Ansatz, alles mit allem zu verlinken, kann man auch in HyperCard – innerhalb des Systems – alles mit allem verlinken. Zudem erklärt Atkinson, dass es eine besondere Home Card gibt, die aus allen Stacks heraus auf die Home-Seite führt. Von dort navigiert man wieder um in die Inhalte, wie z. B. das Adressbuch.12
Das wäre zumindest begrifflich sehr nah an Webseiten, da es auch dort Startseiten gibt. Weiter könnte man es mit den nativen Browser-Startseiten, die bei einigen Browsern die favorisierten Seiten anzeigen, vergleichen. Durch die lokale Speicherung und Anzeige der persönlichen Stacks, erinnert es mich auch sehr stark an den Schreibtisch auf dem Rechner.
Durch Atkinsons Präsentation einer Karte mit Keyboard und klickbaren Tasten, welche Töne erzeugen,13 wird auch deutlich, dass schon ein stückweit an Mini-Anwendungen innerhalb der Karten/Webseiten gedacht wurde, welche im World Wide Web erst später mit JavaScript verwirklicht wurden.
Abschließend kann ich mir vorstellen, dass HyperCard durchaus etwas ähnliches wie das World Wide Web hätte werden können, wenn das System komplett geöffnet worden und die Karten über das Netz verfügbar gewesen wären.
Quellen
Vgl. Public Broadcasting Service: »Computer Chronicles«, »Hypercard Maker«, URL: https://archive.org/details/CC501_hypercard, TC: 00:04:45–00:05:06, abgerufen am 13.4.2017.
Als Unterstützung für meine weitere Recherche, möchte ich mich nun auf die technische Entwicklung des Webs konzentrieren. Als Grundlage dient mir »Weaving the Web – The Original Design and Ultimate Destiny of the World Wide Web« von Tim Berners-Lee. In »Vision eines Visionärs« gehe ich näher auf Tim Berners-Lees Vorstellung des Webs ein, weshalb ich sie hier außen vor lassen möchte. An dieser Stelle möchte ich mich nur auf die technischen Fakten konzentrieren, welche ich im Buch finde und sie lediglich auflisten.
Als Unterstützung für meine weitere Recherche, möchte ich mich nun auf die technische Entwicklung des Webs konzentrieren. Als Grundlage dient mir »Weaving the Web – The Original Design and Ultimate Destiny of the World Wide Web« von Tim Berners-Lee. In »Vision eines Visionärs« gehe ich näher auf Tim Berners-Lees Vorstellung des Webs ein, weshalb ich sie hier außen vor lassen möchte. An dieser Stelle möchte ich mich nur auf die technischen Fakten konzentrieren, welche ich im Buch finde und sie lediglich auflisten.
Eine weitere Recherchequelle ist »A Little History of the World Wide Web« vom W3C, welche zum Teil zusätzliche Punkte enthält.
1980
ENQUIRE
Software-Projekt von Tim Berners-Lee aus dem Jahr 1980, welches schon erste Ansätze des World Wide Webs beinhaltet. ENQUIRE steht für »Enquire Within upon Everything«.1 Einzelne Informationen waren als »node« – als Knoten – abgelegt; neue konnte man durch eine Verlinkung des alten Knotens erstellen. Eine Information konnte man nur dann finden, wenn man die Suche von der Startseite aus beginnt. Links waren jeweils am Ende eines Knotens. Das System enthielt bereits interne und externe Links – externe jedoch nur in eine Richtung.2 Die Programmiersprache war Pascal, welche auf dem Betriebssystem »SINTRAN-III« von Norsk Data lief.3
1984
Tangle
Nachdem Tim Berners-Lee im September 1984 ans CERN zurückkehrt, schreibt er in seiner Freizeit ein weiteres Programm namens »Tangle«, um seine Idee in Bezug auf »Verbindungen« weiterzuführen, welche in seiner Vorstellung immer besonders hohen Stellenwert hatten. In einer extremen Sicht könnte man seiner Ansicht nach die ganze Welt nur aus Verbindungen bestehend sehen. Der Computer speichert dabei Informationen nur als Sequenz von Buchstaben, so dass die Verbindung der Buchstaben das wichtige ist. Wenn sich eine bestimmte Buchstaben-Sequenz wiederholt,4 erschafft Tangle einen neuen Knoten, die für diese Sequenz steht. Sollte diese Sequenz erneut auftauchen, verlinkt Tangle nur auf den ursprünglichen Knoten, anstatt sie erneut abzuspeichern. Tim Berners-Lee hatte die Idee auf diese Art und Weise eine Enzyklopädie zu erstellen, welche Fragen auf einzelne Knoten herunterbricht und eine Antwort liefert. Während Tangle die Frage »How much wood would a woodchuck chuck« noch verarbeiten konnte, lieferte eine weitere komplexere Frage eine Endlosschleife aus »How much wood would a woodchuck chuck if a woodchuck chuck wood chuck chuck chuck wood wood chuck chuck chuck …«. Da das Debuggen unendlich kompliziert gewesen wäre, fasste Berners-Lee das Programm nie wieder an.5
ENQUIRE
Neue Version von ENQUIRE mit ausschließlich internen Links. Jedes Netz war damit limitiert. Diese Einschränkung war für ihn eine sehr wichtige Erkenntnis.6
RPC
Um die Kommunikation zwischen Computern und Netzwerken zu vereinfachen, schrieb Berners-Lee ein RPC-Programm (remote procedure call).7
Bis 1988
Hypertext-Ansatz
Ansatz, dass sein System so wenig Regeln wie möglich besitzen sollte, damit jegliche Informationen ins System fließen können, ohne dass die Entwickler ihre Arbeit grundsätzlich überarbeiten müssen. Letztendlich wählt Berners-Lee Hypertext dafür.8
1988
Proposal
Mike Sendall, Tim Berners-Lees Boss, bat ihn um eine Ausarbeitung der Idee.9
TCP/IP
Das Hauptproblem war letztendlich, eine Basis zu schaffen, auf der verschiedene Computer mit verschiedenen Betriebssystemen miteinander kommunizieren können.10
Viele Physiker nutzten das VAX/VMS-Betriebssystem und DECnet Kommunikations-Protokolle, Unix nutzte dagegen Internetprotokolle. Berners-Lee favorisiert die Protokolle TCP/IP. Die Unix-Welt nutzt sie bereits und VAX-Welt könnte sie übernehmen.11
Adaption des RPC-Adress-Schemas, um Dateien zu adressieren und abzurufen.
1989
12.3.1989: »Information Management: A Proposal«
Dokument, dass das World Wide Web als globales, non-lineares Hypertext-System innerhalb von CERN vorstellt.12 Die Vorstellung des Informationssystems zielt unter anderem darauf ab, den Verlust von Informationen innerhalb der Organisation zu verhindern. Er präsentiert das Systems als große Hypertext-Datenbank mit Links, welche automatisch analysiert werden könnten.13
Grafik aus »Information Management: A Proposal«I
1990
Keine Reaktion
Keine Reaktion auf seine Ausarbeitung bis er sie im Mai 1990 nochmal David Williams (Boss von Mike Sendall) gab und sie erneut auf Eis gelegt wurde.14
Ideen zur Namensgebung
Mesh oder Information Mesh, MOI für »Mine of Information« oder TIM für »The Information Mine«. Letztere könnten zu egozentrisch wirken und Tim Berners-Lee entschied sich für »World Wide Web«.15
HT
Auf der Suche nach einem charakteristischen Akronym entschied er sich für »HT«. Jedes Programm, das ins System involviert war, sollte mit diesen Buchstaben starten.16
European Conference on Hypertext Technology
Besucht zusammen mit Robert Cailliau, einem alten CERN-Veteran, die Konferenz, um die Idee vorzustellen. Ian Ritchie und Leute von Owl Ltd. stellten ein Produkt namens »Guide« vor. Das Original von Peter Brown, das an der Universität von Southampton entstanden ist, sah im Grunde wie Tim Berner-Lees Vision aus.17 Es brachte alle Eigenschaften mit sich, nur das Internet fehlte. Er versuchte die Zuständigen zu überreden, es an das Internet zu schließen, aber sie waren von der Idee nicht überzeugt. Auch die anderen Teilnehmer konnten nicht vom World Wide Web überzeugt werden.18
Code des World Wide Webs
Tim Berners-Lee beginnt im Oktober damit, den Code für das World Wide Web auf dem NeXT zu schreiben:
· Web Client
· Hypertext Transfer Protocol (HTTP)
· Universal Resource Identifier (URI)
· Hypertext Markup Language (HTML)
· Web Server (nxoc01.cern.ch – Next, Online Controls, 1) – Alias: info.cern.ch
· Erste Hypertext Webseite mit Spezifikationen zu HTTP, URI, HTML und alle projektbezogenen Informationen
Der Client war Mitte November fertig und hieß »WorldWideWeb«, welcher ab Dezember mit HTML funktionierte. Bis dahin jedoch nur auf dem NeXT.18 HTML wurde dabei an SGML (Standard Generalized Markup Language) angelehnt – eine Sprache, die bereits bei einigen Dokumentations-Communities bevorzugt wurde.19
Bestehende Internetprotokolle wie z. B. NNTP oder FTP waren Berners-Lee zu langsam, weshalb er HTTP entwickelte.20
Um andere Systeme mit einzuschließen wurde der kleinste gemeinsame Nenner gesucht: Alle hatten die Tastatur als Eingabegerät und konnten ASCII produzieren. Der auf das wesentliche heruntergebrochene Browser hieß »line-mode Browser« und wurde an das Terminal angelehnt, welches jeweils eine Zeile zeigt.21
Via FTP stellte Tim Berners-Lee eine Verbindung zu Nachrichtenartikel und Newsgruppen im Internet her. So waren Inhalte aus dem Internet umgehend verfügbar.22
Merry Christmas
Tim Berners-Lee und Robert Cailliau hatten jeweils den Browser/Editor WorldWideWeb auf ihrem NeXT installiert, welche am Weihnachtstag 1990 über das Internet via info.cern.ch kommunizieren konnten.23
1991
Telefonbuch von CERN
Das Web ist noch nicht weit genug, um es als ultimatives Dokumentations-System zu verbreiten. Erstes kleines Ziel: Telefonbuch von CERN.24
Dokumentation auf info.cern.ch
Fortführung der Dokumentation auf info.cern.ch. Jede technische Entscheidung basiert auf der Idee, dass es ein Informationsraum sein sollte, der alle umfasst und einschließt.25 Sprich auch von jedem Computer und Betriebssystem zugänglich sein sollte.
Veröffentlichung WorldWideWeb
Im März 1991 wurde das Program WorldWideWeb innerhalb von CERN veröffentlicht. Jedoch nur limitiert an die Nutzer von NeXT Computern.26
Hypertext at CERN
Ausarbeitung »Hypertext at CERN«.27
Veröffentlichung
Im August veröffentlich Tim Berners-Lee drei Dinge: das WorldWideWeb für NeXT, einen line-mode Browser sowie den grundlegenden Server.28
comp.infosystems.www
Start von comp.infosystems.www als Newsgruppe zum Informationsaustausch.29
Telnet-Protokoll
Öffentlicher Telnet-Server auf info.cern.ch. Telnet ist ein Protokoll, wodurch ein Nutzer eine interaktive Kommandozeilen-Session öffnen konnte. Dadurch gelangten Menschen ins Web, welche keinen Browser installieren konnten.30
WorldWideWeb-Browser in C
Der Browser WorldWideWeb wurde erneut in der Sprache C geschrieben, um den Transport zu vereinfachen.31
Libwww
Libwww als Bibliothek – Veröffentlichung des webspezifischen Codes.32
Zwei Gateways
Installation von zwei Gateways zum Support-System VAX/VMS und WAIS.33
Mailing-Liste für technische Diskussionen
Start der Online-Mailing-Liste www-talk@info.cern.ch für technische Diksussionen.34
Hypertext 91’
Hypertext 91’ im Dezember. Das Projekt wird vorgestellt, findet jedoch kaum Zuspruch.35
1992
Erwise
Im April wird der Browser »Erwise« der Helsinki University of Technology für Unix mit dem Betriebssystem X-Windows veröffentlicht.36
ViolaWWW
Im Mai wird der Browser »ViolaWWW« von Pei Wei für Unix veröffentlicht.37
Samba
Entwicklung eines Webbrowser Samba für Macintosh von Tim Berner-Lees Kollegen.38
URL
Aus URI (universal resource document) wurde URL (uniform resource locator).39
MidasWWW
Tony Johnson entwickelt den Browser »MidasWWW« für X.40
1993
Es gab etwa 50 bekannte Server und die Browser Erwise, ViolaWWW und MidasWWW waren für X-Windows verfügbar, Samba für Mac.41
Diverse Browser
Dave Raggett entwickelt den Browser »Arena«.42
Die University of Kansas schreibt einen text-basierten Hypertext-Browser namens »Lynx«, der es als screen mode Browser erlaubt, durch das Dokument zu scrollen. Lynx 2.0 wurde als Web-Browser im März veröffentlicht43 und ist der älteste Browser, der noch immer in Betrieb ist.44
Marc Andreessen veröffentlicht im Februar den Browser »Mosaic« für X.45
Tom Bruce schreibt den Browser »Cello« für Microsofts Windows, welcher im März veröffentlicht wird. Erstmals konnten Windows-Nutzer das Web in verschiedenen Farben und Schriften sehen.46
Das freie World Wide Web
Am 30.4.1993 gab CERN das Web-Protokoll und den Code zur Nutzung frei.47 Dieser Tag wird heute als Geburtstag des freien World Wide Webs angesehen.
Veröffentlichung von Mosaic für UNIX, Windows und Mac im September.48
1994
Internet in a Box
Tim O’Reilly kündigt das Produkt »Internet in a Box« an, welches das World Wide Web in Privathaushalte bringen soll. Das Produkt wird jedoch überflüssig, da nun viele Internet-Service-Provider ihre Arbeit aufnahmen.49
Navipress
Navisoft Inc. veröffentlicht einen Browser namens »Navipress« für den PC und Mac.50
Netscape Navigator 1.0
Gründung des Unternehmens Mosaic Communications Corp. –, später Netscape –51, welches im Oktober desselben Jahres den Browser »Mozilla« auf den Markt bringt.52 Die kommerzielle Version wird im Dezember über das Internet herausgegeben und zu »Netscape Navigator« umbenannt. Der Browser ist mit Windows, X Window und Macintosh kompatibel.53
Woodstock of the Web
Erste internationale WWW-Konferenz – auch »Woodstock of the Web« genannt – im Mai.54 Hier entstand das Konzept von VRML (Virtual Reality Modellen Language).
W3C
Gründung des W3C.55
1995
Hardware mit Browser
Im April kündigt Compaq an, seine PCs mit dem Navigator auszustatten. Damit wird erstmals ein Browser direkt mit der Hardware ausgeliefert.56
Java
Im Mai wird die Programmiersprache Java eingeführt. Die Sprache vereinfacht es in vielerlei Hinsicht Inhalte veröffentlichen. So wird von nun an beispielsweise weniger Arbeitsspeicher beim Endnutzer benötigt, um Inhalte anzusehen. Sie können nämlich direkt im Webbrowser angezeigt werden.57
AOLpress
AOL kauft das Unternehmen Navisoft, welches Navipress entwickelt hatte. Das Produkt heißt von nun an AOLpress.58
Internet Explorer
Der Internet Explorer wird im August zusammen mit Windows 95 veröffentlicht.59
1996
Browser kommen und gehen
Netscapes Navigator 2.0 kommt auf den Markt.60
AOLpress stirbt, während AOL nun den Internet Explorer nutzt.61
PICS
PICS (Platform for Internet Content Selection) wird im März als mögliches Filter-Werkzeug für Webinhalte veröffentlicht.62
Amaya
Das W3C entwickelt ab 1996 den experimentellen Browser »Amaya«.63
1997
RDF
Ab 1997 erste Konzeption von RDF (Resource Description Framework) mit dem letztendlichen Ziel maschinenlesbare Daten für das semantische Web zu erhalten.64
1998
Open Source Policy
Netscape veröffentlicht im Januar den kompletten Quellcode seines Browsers.65
XML
XML (Extensible Markup Language) wird im Februar vom W3C veröffentlicht, um SGML abzulösen. XML ist die Basis von Sprachen wie HTML.66
DOM
DOM (Document Object Model) wird als Standard des W3C eingeführt.67
Quellen
Vgl. Berners-Lee, Tim; Fischetti, Mark (Hg.): »Weaving the Web – The Original Design and Ultimate Destiny of the World Wide Web«, New York 2000, S. 1.
Vgl. Berners-Lee, Tim; Fischetti, Mark (Hg.): »Weaving the Web – The Original Design and Ultimate Destiny of the World Wide Web«, New York 2000, S. 69.
Bereits Mitte letzten Jahres habe ich das Projekt »In Pieces« vorgestellt. Seitdem möchte ich mich etwas näher mit dem technischen Hintergrund auseinandersetzen, da mich das Projekt nachhaltend begeistert hat und ich es sehr interessant finde, dass es basierend auf CSS umgesetzt wurde.
Bereits Mitte letztens Jahres habe ich die interaktive Ausstellung »In Pieces« von Bryan James vorgestellt. Damals hatte ich fälschlicherweise noch den Titel »Species in pieces« verwendet.
Seitdem möchte ich mich etwas näher mit dem technischen Hintergrund auseinandersetzen, da mich das Projekt nachhaltig begeistert hat und ich es sehr interessant finde, dass es basierend auf CSS umgesetzt wurde.
Neben der Dokumentation, die auf der Projektseite selbst zu finden ist, bin ich auf »The Making Of ›In Pieces‹: Designing an Interactive Exhibition With CSS Clip Paths« auf Smashing Magazine gestoßen. Hier erklärt Bryan James ausführlich seine Vorgehensweise und auf welche Probleme er während des Prozesses gestoßen ist. Da die Dokumentation sowie das Making Of sehr detailliert sind, möchte ich den technischen Hintergrund nicht einfach wiedergeben, sondern lediglich die für mich spannenden Punkte herausgreifen.
Die Outlines des Pfeilgiftfrosches in IllustratorI
Zunächst finde ich es erstaunlich, dass die Polygone aus denen die Tiere zusammengesetzt sind mit der CSS-Eigenschaft clip-path generiert wurden. Ich bin mehr Designerin als Entwicklerin, so dass mir das breit gefächerte Verständnis fehlt. Jedoch war meine Vermutung die, dass mit SVG-Grafiken gearbeitet wurde, die dann via Code verändert und bewegt werden. Zur Erstellung der Formen stellt Bryan James das Tool Clippy » vor. Mit dieser Browseranwendung können eigene sowie vorgefertigte Masken ausgewählt werden. Der dazugehörige Code erscheint dabei direkt am unteren Rand des Browsers. Schade finde ich, dass man den Code nicht direkt im Browser ändern kann, um die erstellte Form selbst noch einmal im Detail zu ändern. Zwar ist ein klickbares Logo von Codepen zu sehen, dessen Sinn erschließt sich mir aber leider nicht ganz, da sich nichts ändert oder öffnet. Davon abgesehen, ist es aber ein einfaches, schönes Tool, um visuell die Formen zu erstellen. Den Code kann man nachträglich immerhin selbst ändern, so dass ich das nicht als sehr großen Nachteil empfinde.
Als weitere spannende Lösung stellt James eine Funktion vor, die ermöglicht die prozentualen Werte eines Punktes auszulesen. Er nutzt eine PNG-Datei als Unterstützung und durch einen Klick wird ein Fenster mit den Daten des jeweiligen Punkts zum Kopieren ausgegeben. Die Funktion ist im Making Of zu finden.
Aus grafischer bzw. konzeptioneller Sicht finde ich es zudem überraschend, dass die 30 Tiere jeweils aus etwa 30 Polygonen bestehen. Das war mir im Vorfeld nicht bewusst bzw. habe ich nicht darauf geachtet.
Eine weitere bemerkenswerte Herangehensweise sehe ich in der Maskierung von Bildern mit Zahlen durch die Polygone als Hilfestellung. Eine simple Methode, um die Ränder der Formen hervorzuheben, um sie anschließend zueinander passend zu verändern. So können feine Linien vermieden werden, die zwischen den Gebilden entstehen, wenn sie exakt aufeinander liegen.
Visuell ansprechend finde ich außerdem den von ihm verwendeten und erwähnten Schimmer-Effekt. Generell bin ich kein Fan von Schimmern, Schatten oder beispielsweise Verläufen. Doch der Einsatz im Web kann bei dosierter Anwendung sehr reizvoll sein. Im Vergleichsbild seiner Grafiken sieht man deutlich, dass sie durch den Schimmer-Effekt sehr viel hochwertiger wirken.
Schlussendlich finde ich es großartig, dass Bryan James das Projekt und den Prozess so ausführlich dokumentiert. Einen Einblick in die Arbeitsweise und die Problemlösungen machen deutlich, wie das große Ganze Schritt für Schritt und Hürde für Hürde gewachsen ist. Dass die Arbeit beinahe wegen zu großer Probleme beendet wurde, motiviert zudem sich an mancher Stelle weiter durchzubeißen. Denn das Ergebnis finde ich nach wie vor so imposant, dass es Mut macht dem ein oder anderen Hindernis zu trotzen. Zudem inspiriert mich die interaktive Ausstellung so sehr, dass ich mich nun mit mehr technischem Verständnis, selbst an einer erstmaligen Gestaltung durch Polygone versuchen möchte.
Abbildungen
James, Bryan: »The Making Of ›In Pieces‹: Designing an Interactive Exhibition With CSS Clip Paths«, Stand: 2.6.2015, URL: https://www.smashingmagazine.com/2015/06/the-making-of-in-pieces/, abgerufen am 2.3.2017.
Da ich mich auch auf technischer Ebene weiterentwickeln möchte, will ich die Zeit innerhalb meines Masters nutzen, um mich näher mit CSS-Animationen auseinanderzusetzen. Ich sehe in ihnen riesiges, gestalterisches Potenzial und bin überzeugt davon, dass es sich auszahlen wird, mehr darüber zu wissen.
Da ich mich auch auf technischer Ebene weiterentwickeln möchte, will ich die Zeit innerhalb meines Masters nutzen, um mich näher mit CSS-Animationen auseinanderzusetzen. Ich sehe in ihnen riesiges, gestalterisches Potenzial und bin überzeugt davon, dass es sich auszahlen wird mehr, darüber zu wissen. Zum einen sprechen mich dezente Animationen von Typografie oder grafischen Elementen sehr an. Zum anderen finde ich es großartig, dass Objekte komplett durch Code entstehen und animiert werden können. Bei meiner Recherche bin ich bereits auf gute Beispiele auf CodePen gestoßen, die mir als erste Grundlage dienen sollen. Ich habe mir für die ersten Versuche zwei Beispiele ausgesucht, die sich in Komplexität sehr unterscheiden. Beides sind nur Grafiken auf einer Farbfläche, jedoch scheint »Submarine with CSS« auf den ersten Blick sehr viel weniger komplex als der BB-8 zu sein.
Submarine with CSS von Alberto Jerez: CodePen »
Star Wars BB-8: Pure CSS Animation, Single Dev, 8Bit von Udith Ishara Madusanka: CodePen »
In »Interaktive Karten« habe ich mich mit Lösungen für Karten auseinandergesetzt, die innerhalb von WordPress umsetzbar sind. In der weiteren Recherche möchte ich mich mit drei weiteren PlugIns bzw. Libraries auseinandersetzen.
In »Interaktive Karten« habe ich mich mit Lösungen für Karten auseinandergesetzt, die innerhalb von WordPress umsetzbar sind. In meiner weiteren Recherche fiel das angekündigte PlugIn »wp google maps« direkt raus, da mir die Möglichkeiten doch sehr begrenzt schienen.
Leaflet Map für WordPress sowie die ursprüngliche Library leaflet.js sind weiterhin interessant für mich. Für Leaflet spricht vor allem die Tatsache, dass es eine weit verbreitete Library ist. Das halte ich mit Blick auf den Support oder auch die Arbeit in der Community für ein sehr wichtiges Kriterium.
Zufällig bin ich bereits auf PlugIns für Leaflet.js gestoßen, die Ansätze meiner Ideen beinhalten. So z. B. Leaftlet.Instagram und Leaflet.Photo. Ersteres platziert Fotos aus dem Instagram-Stream direkt in der Karte, zweiteres platziert sie mithilfe von Geotagging. Während Smartphone-Fotos normalerweise schon getaggt sind, trifft das auf Bilder, die mit einer analogen oder digitalen Kamera ohne GPS-Empfänger gemacht wurden, nicht zu. Hier möchte ich noch recherchieren, ob die Metadaten nachträglich geändert werden können, so dass sie als getaggt zählen.
Die Informationen zu leaflet.js sowie deren Funktionen sind sehr umfangreich. Ich habe noch immer keine endgültige Wahl getroffen, jedoch möchte ich mich zwischen leaflet.js und WP Google Map Pro entscheiden. Die abschließende Entscheidung richtet sich nicht danach, wie umfangreich die Tools sind, sondern nach der Frage inwieweit meine Kompetenz ausreicht. Leaflet setzt im Vergleich sehr viele Kenntnisse voraus. An diesem Punkt stehe ich aber regelmäßig vor der Frage, inwiefern ich mich ausschließlich auf das Design konzentrieren und wie weit ich mich im Bereich Webentwicklung weiterentwickeln möchte.
Das Websocket-Protokoll dient der Kommunikation zwischen Client (Browser) und dem Server. Mit einem kurzen Exkurs möchte ich die wesentlichen Punkte verstehen. Sollte ich es innerhalb meines Masterprojekts benötigen, macht jedoch eine Kooperation aus meiner Sicht am meisten Sinn.
Das Websocket-Protokoll dient der Kommunikation zwischen Client (Browser) und dem Server. Die bidirektionale Kommunikation ermöglicht es, die Daten in Echtzeit abzurufen, da der Server nicht erst auf eine Anfrage reagiert, sondern im ständigen Austausch steht.
Durch ein Tutorial »WebSockets (using Socket.io) Tutorial #2 – Creating an Express App« versuche ich die Nutzung sowie die Funktionsweise besser zu verstehen. Die Installation über node.js wird hier zwar ausführlich erklärt, jedoch merke ich schnell, dass es mein Interesse tief in die Programmierung einzusteigen schnell übersteigt.
Ich bin grundsätzlich motiviert, das Thema auch von Entwicklerseite zu verstehen, doch möchte ich meine Prioritäten an anderer Stelle setzen. Da ich mir sicher bin, dass das nicht mein beruflicher Alltag der Zukunft sein wird, reicht es mir an dieser Stelle, die Funktionsweise von websockets im Wesentlichen zu verstehen. Sollte ich es innerhalb meines Masterprojekts benötigen, macht eine Kooperation aus meiner Sicht am meisten Sinn.
Zur Zeit setze ich mich mit der Darstellung und Umsetzung interaktiver Karten auseinander, die man innerhalb von WordPress umsetzen kann. Dafür recherchiere ich PlugIns, die man möglicherweise verwenden kann.
Zurzeit setze ich mich mit der Darstellung und Umsetzung interaktiver Karten auseinander, die man innerhalb von WordPress umsetzen kann. Meine favorisierten PlugIns sind bisher WP Google Map Pro sowie Mapify.it.
In naher Zukunft möchte ich die Open-Source-Lösung Leaflet, wp google maps sowie Leaflet Map für WordPress genauer unter die Lupe nehmen.
Wichtig sind mir neben der individuellen Gestaltung der Karte, die Inhalte, die man bereits der Karte selbst entnehmen kann. Zum Beispiel möchte ich die Möglichkeit haben, ausgewählten Orten Bildergalerien hinzufügen zu können. Bisher habe ich keine eigenen Erfahrungen mit den PlugIns sammeln können, auf den ersten Blick scheint WP Google Map Pro aber sehr viel umfangreicher als Mapify zu sein. Zwar besitzt Mapify laut Beschreibung von Haus aus die Funktion Galerien anzuzeigen. Auf der anderen Seite kann man bei WP Google Map Pro unter anderem mit dem PlugIn ACF arbeiten, womit man theoretisch Galerien sowie unzählige andere Inhalte anzeigen lassen kann. Zudem werden Custom Post Types unterstützt, mit denen ich zur Unterscheidung der einzelnen Inhalte sehr gerne arbeite.
Die Darstellung kann bei letzterem durch snazzymaps beeinflusst werden, während man bei Mapify eigene Karten – ganz egal welcher Art – einbauen kann. Zwar besitzt WP Google Map Pro unzählige Funktionen von Routenführung über Street View bis zu den genannten Custom Post Types. Beim Testen der Demos fällt mir die Bedienung der Mapify-Karte jedoch deutlich einfacher, da sie sich mehr nach zeitgemäßen Web anfühlt. Man kann sicher auch die WP Google Map Pro mit mehr Dynamik ausstatten, jedoch möchte ich bei meiner aktuellen Recherche ausschließlich die Möglichkeiten in Betracht ziehen, die von Haus aus gegeben und in der Demo zu sehen sind.
Grundsätzlich gefällt mir das PlugIn WP Google Map Pro mit Blick auf die Funktionen deutlich besser. Einzig die Bedienbarkeit missfällt mir, so dass ich hier noch kein eindeutiges Ergebnis für mich gefunden habe. Diese Punkte werde ich im Vergleich mit den anderen oben genannten Lösungen besonders beachten und letztendlich werden mir wohl – trotz kostenpflichtiger PlugIns – nur ein Test und die eigene Erfahrung, die ich damit sammeln werde, weiterhelfen.
Zur weiteren Recherche mache ich einen kurzen Exkurs zum Thema API. Das »application programming interface« interessiert mich vor allem in Hinblick auf eine Nutzung von Daten in Medieninstallationen.
Zur weiteren Recherche mache ich einen kurzen Exkurs zum Thema API. Das »application programming interface« interessiert mich vor allem in Hinblick auf eine Nutzung von Daten in Medieninstallationen. Markus Kisons Projekt »Pulse« dient mir dabei als ursprüngliche Inspiration.
Grundsätzlich sind APIs Schnittstellen, die es ermöglichen, dass zwei Einheiten miteinander kommunizieren. Auf eine Anfrage erhält man über die API eine Antwort vom jeweiligen Server. Die Seite www.programmableweb.com gibt dabei einen guten Überblick, was APIs sind, aber auch einen ausführlichen Einblick, welche Anbieter solche Schnittstellen bereitstellen. Viele der bekannten APIs wie z. B. die Facebook oder Twitter API sind sogenannte Rest Apis – Rest steht dabei für representational state transfer.
Für mich sind vor allem Echtzeit-Daten interessant, da die Nutzung für eine Medieninstallation hier am spannensten ist. So könnten abstrakte Daten in einer Installation verständlich visualisiert werden.
Wie das im Detail funktioniert konnte ich leider noch nicht herausfinden, bin jedoch auf die weiteren Ressourcen streamdata.io, »WebSockets – Methods for Real-Time Data Streaming« und socket.io gestoßen. Ob mir das letztendlich weiterhilft, muss ich in den kommenden Wochen recherchieren und klären.
Eine weitere Möglichkeit des Real-Time Data Streaming bietet die Verwendung von WebSockets. Hier liefert Steve Schwartz einen guten, ersten Einblick.
Ein weiterer Fund in meiner Recherche bezüglich verwendbarer Technologien für eine Medieninstallation sind WebSockets. Neben der Tatsache, dass man das Wort mal gehört hat, sind mir WebSockets in ihrer Funktion gänzlich unbekannt. Eine auf den ersten Blick gute Zusammenfassung veröffentlicht Steve Schwartz auf seiner Seite, die ich zu Recherchezwecken durcharbeiten möchte: WebSockets.
Eine mögliche Engine könnte auf folgender Seite zu finden sein: socket.io.
Nach wie vor recherchiere ich bezüglich der Form und möglichen Technologie einer Medieninstallation . Während Markus Kisons Projekt »Pulse« unter anderem auf Processing und einer WordPress.com-API, stoße ich auch bei der Recherche regelmäßig auf die Verwendung von APIs, um Echtzeit-Daten auszulesen. Hierzu möchte ich in der kommenden Zeit weiterarbeiten und -recherchieren.
Nach wie vor recherchiere ich bezüglich der Form und möglichen Technologie einer Medieninstallation (Formsuche »). Während Markus Kisons Projekt »Pulse« unter anderem auf Processing und einer WordPress.com-API, stoße ich auch bei der Recherche regelmäßig auf die Verwendung von APIs, um Echtzeit-Daten auszulesen. Zwar ist mir die grundsätzliche Bedeutung und Nutzung von APIs bekannt, jedoch habe ich noch keine Erfahrung damit, in welcher Form sie in den eigenen Code eingearbeitet werden und in welcher Form, die Information wieder – aus technischer Sicht – ausgegeben werden kann. Aus diesem Grund möchte ich mich hier in der nächsten Zeit in die Nutzung von APIs einarbeiten, um solche möglicherweise in meinem Projekt nutzen zu können. Als erste, interessante Quelle finde ich folgende Seite, die eine kleine Übersicht über Real-Time-APIs liefert: Real Time APIs. Mit dieser Seite möchte ich mich erstmal grundsätzlich über diverse APIs informieren, um dann selbst mit den ersten zu experimentieren.
Das Erinnerungsnetzwerk resultiert ursprünglich aus dem Problem, meine Gedanken, Ideen und Recherchen bezüglich des Masterthemas klar zu ordnen und zu strukturieren.
Das Erinnerungsnetzwerk basiert ursprünglich aus dem Problem, meine Gedanken, Ideen und Recherchen bezüglich des Masterthemas klar zu ordnen und zu strukturieren.
Die Lösung war zunächst, alles niederzuschreiben, um aus dieser Sammlung neue Ansätze zu entwickeln. Da es schwierig ist die komplexen Zusammenhänge analog darzustellen, habe ich nach digitalen Lösungen gesucht. Auf eine Empfehlung hin war die erste Überlegung, die Software »the brain« zu nutzen, die es mittels Verknüpfungen ermöglicht ein komplexes Netzwerk der einzelnen Beiträge zu entwickeln.
Aus diesem Gedanken entstand die Fragestellung, wie viel verborgene Erinnerungen in unserem Gehirn lagern, sowie die Idee das eigene Gehirn zu visualisieren.
Nur ein kleiner Teil des Gehirns wird genutzt
Im Alltag denken wir nur an eine bestimmte Zahl von Menschen und Dingen, die uns wichtig sind und verbinden damit meist nur wenige Eigenschaften, Erlebnisse oder Ähnliches. Bei genauerem Nachdenken wird einem erst bewusst, wie viele Erinnerungen oder Fakten es tatsächlich gibt, wenn man an einem Strang weiter denkt. So wäre beispielsweise allein mein Hobby Fußball ein komplexes Konstrukt aus unzähligen Untersträngen mit Menschen, Erlebnissen, Eindrücken oder Strängen, die in einen anderen Lebensbereich reichen. Das macht mir erst bewusst, wie komplex und umfangreich so ein Gehirn tatsächlich ist.
»Weißt Du noch«-Momente
Eine weitere Grundlage ist etwas, dass ich in meiner Jugend – wenn auch selten – gemacht habe: Ich habe »Weißt Du noch«-Erlebnisse in meinen Kalender eingetragen. Dabei schreibt man beispielsweise ein Ereignis von heute als »Weißt du noch«-Moment ein paar Monate später in den Kalender. An diesem Tag wird man dann an das heutige Erlebnis erinnert.
Diese Ansätze habe ich gedanklich zum Erinnerungsnetzwerk weiter entwickelt. Das Grundsätzliche ist dabei nicht, einfach alles zu speichern oder zu visualisieren. Sondern das Anzeigen, sprich das Erinnern an das Vergessene.
Das Netzwerk beruht dabei zunächst auf Bildern, die sehr gut getaggt sein müssten, was ich jedoch ohnehin als zukünftigen Standard ansehe. Zudem besitzen schon jetzt, zum Teil sehr einfache, Bildarchivierungsprogramme die Möglichkeit der Gesichtserkennung. Das Programm findet sogar Fotos einer Person aus unterschiedlichen Lebensjahren. Zusätzlich könnten beispielsweise Anekdoten eine Rolle spielen. Das halte ich jedoch für zu viel Aufwand für den Nutzer, da er das selbst einpflegen müsste.
Das Netzwerk könnte daraufhin »Weißt Du noch«-Momente schaffen. Wie bei Blogs, die ähnliche Artikel anzeigen, könnte das Erinnerungsnetzwerk Fotos zeigen, die passend zum angezeigten Foto sind. Sprich ein angezeigtes Urlaubsfoto zeigt weitere Fotos aus einem anderen Urlaub an, das Bild einer Person andere Erlebnisse und Momente mit dieser Person.
Das Konzept des Erinnerungsnetzwerks möchte ich gern weiter entwickeln, da ich es für einen spannenden Ansatz halte. Technisch scheint es erstmal nicht sehr aufwändig zu sein, da es ähnlich wie ein Blogsystem im Web funktionieren könnte. Dieser einfache Start könnte jedoch noch weitaus komplexer sein.
