Wir möchten uns bei allen bedanken, mit denen wir in den vergangenen Jahren tolle Projekte machen durften, die wiedergekommen sind, uns weiterempfohlen haben und all das möglich gemacht haben!

 

Aus dem Ankündigungstext auf der Website des BDG:

Vanilla Web Design

Gestalten mit Browser, Git und Kirby.

Wieso als Designer:in mit Git arbeiten? Weshalb den Browser als wichtigste App schätzen? Und warum Kirby als Redaktionssystem nutzen?

Johanna und Nils sprechen darüber, wie sie als Designteam ihren Tech Stack aus Browser, Text Editor, Git und Kirby CMS für detailorientiertes Gestalten im Web nutzen. Sie beleuchten Projektabläufe, Prozesse und Systeme von Konzeption und Entwurf zu nachhaltiger Realisierung.

Anschauen

Die Aufzeichnung unseres Vortrags ist jetzt auf der BDG-Website und direkt auf Vimeo verfügbar, schaut gerne rein!

 

Ich gestalte seit 1999 Websites, weshalb meine ersten Designs vor allem Layouttabellen und Spacer-Gifs enthielten. Im Laufe der Jahre wurde CSS wichtiger und funktionsreicher, aber oft war es immer noch hacky, interessante Layouts zu erstellen. Wir haben Floats zur Positionierung verwendet, die ursprünglich für etwas anderes gedacht waren, wir haben alle möglichen kreativen Lösungen entwickelt. Aber komplexere Layouts erforderten stets JavaScript für Positionierung, Timing, Animation.

Die Dinge änderten sich grundlegend mit der Einführung von CSS Flexbox und CSS Grid, die uns endlich die Freiheit gaben, im Raum zu entwerfen. Kinners, wie ich CSS Grid liebe! Aber während der Arbeit an unseren Formularkomponenten fiel mir auf, wie schwer es sein kann, die gewohnten Pfade zu verlassen und nicht in alte Denkmuster zu verfallen:

Ich wollte eine Menükomponente erstellen, die sich durch Klicken auf einen Button in eine der vier Himmelsrichtungen öffnet und das Menü dabei am Anfang, in der Mitte oder am Ende der zugehörigen Achse ausrichtet. Ich dachte zunächst, dass die Positionierung des Menüs komplizierte Berechnungen mit sich bringen würde. Ein Blick auf bestehende Bibliotheken schien dies zu bestätigen, da sich diese stets auf umfangreiches JavaScript mit absoluter Positionierung und komplexen Entfernungsberechnungen stützten.

Das fühlte sich falsch an, denn eine der Stärken von CSS Flexbox und Grid ist die Fähigkeit, komplexe Berechnungen für uns durchzuführen. Sie ermöglichen eine einfache Ausrichtung (selbst Zentrierungen sind leicht, meine alten Web-Veteranen!), also genau das, was ich für mein Menü brauchte. Mit etwas Nachdenken fand ich eine überraschend einfache Lösung für mein Problem: Zellen ohne Breite und Höhe in Kombination mit intelligenter Overflow-Handhabung.

Das unsichtbare Raster

Um das Menü überall dort zu positionieren, wo ich wollte, brauchte ich ein Drei-mal-drei-Raster mit der Schaltfläche in der Mitte und dem Menü in einer der umlaufenden Zellen, abhängig von der erforderlichen Platzierung und Ausrichtung:

.wrapper {
    grid-template-columns: min-content min-content min-content;
    grid-template-rows: min-content min-content min-content;
}
button {
    grid-column-start: 2;
    grid-row-start: 2;
}
menu {
    /* unten platziert, nach links ausgerichtet */
    grid-column-start: 2;
    grid-row-start: 3;
    justify-self: start;
    align-self: start;
}

Während dieser Aufbau gut funktioniert, wenn das Menü geschlossen ist, beginnen sich die Zellen, die das Menü halten, auf die Größe des Menüs zu erweitern, wenn es geöffnet wird, und das gesamte Seitenlayout beginnt dadurch zu springen. Eigentlich sollte das Menü jedoch über den umliegenden Inhalten schweben, was für gewöhnlich mittels absoluter Positionierung gelöst wird und skriptbasierte Lageberechnungen erfordert.

Das Tolle an CSS Grid ist: Es erlaubt überlaufenden Inhalt, wenn die Größe der äußeren Zellen auf 0 gesetzt wird. Dadurch schwebt das Menü – ganz ohne Zutun – über dem umliegenden Inhalt:

.wrapper {
    grid-template-columns: 0 min-content 0;
    grid-template-rows: 0 min-content 0;
}
button {
    grid-column-start: 2;
    grid-row-start: 2;
}
menu {
    /* unten platziert, nach links ausgerichtet */
    grid-column-start: 2;
    grid-row-start: 3;
    justify-self: start;
    align-self: start;
}

Der Verzicht auf absolute Positionierung und das Vertrauen auf die automatische Ausrichtung mittels CSS eröffnet eine zusätzliche Möglichkeit: das Anwenden von position: sticky; auf das Menü. Dadurch können wir sicherstellen, dass es beim Scrollen nicht ungewollt den sichtbaren Fensterbereich verlässt, bevor nicht auch der Button hinausgescrollt wird.

menu {
    /* unten platziert, nach links ausgerichtet */
    grid-column-start: 2;
    grid-row-start: 3;
    justify-self: start;
    align-self: start;
    /* stick zum nächsten scrollbaren Elternteil */
    position: sticky;
    top: 0;
    left: 0;
    right: 0;
    bottom: 0;
}

Die Schaltfläche, das Menü und die Geisterzellen

Dieser Ansatz funktionierte wunderbar für die Zellen, die sich keinen Platz mit der Schaltfläche teilen, und ich war sehr zufrieden, bis ich bemerkte, dass die Seite beim Öffnen des Menüs in der Mitte der Schaltfläche zu springen begann. Während die äußeren Rasterzellen leicht auf Null schrumpfen konnten, weil sie nicht mit einem anderen Element konkurrierten, waren die mittleren Zellen immer noch auf min-content eingestellt und standen daher im Konflikt mit der Buttongröße. Der Browser berechnete die Zellgrößen beim Öffnen des Menüs neu, wodurch es dann nicht mehr über dem Seiteninhalt schwebte.

Dieses Problem schien unlösbar, bis ich bemerkte, dass es eine Möglichkeit gab, min-content und 0 Breite gleichzeitig auf die Schaltfläche anzuwenden, indem man sie in mehrere Zellen unterteilt:

.wrapper {
  grid-template-columns: 0 min-content 0 min-content 0;
  grid-template-rows: 0 min-content 0 min-content 0;
}
button {
  grid-column: 2 / -2;
  grid-row: 2 / -2;
  align-self: center;
  justify-self: center;
}

Jetzt haben wir ein Fünf-mal-fünf-Raster mit minimierten Zellen, die für das Menü reserviert sind, und einer Schaltfläche, die sich zentriert über alle innenliegenden Geisterzellen hinweg erstreckt.

Demo

http://labor.hananils.de/menu/index.htm

Natürlich ist dies nicht alles, was für ein funktionierendes Menü benötigt wird. Es ist JavaScript erforderlich, um das Menü auf- und zuzuklappen und sicherzustellen, dass alles zugänglich ist, einschließlich der Tastaturnavigation. Aber es ist ein gutes Beispiel dafür, wie moderne CSS-Techniken uns helfen können, komplexe Layout-Aufgaben zu lösen, ohne die Dinge unnötig zu verkomplizieren. Und auch dafür, bekannte Pfade bei der Umsetzung von Layouts regelmäßig zu hinterfragen und zu überdenken.

Weiterführende Links

• Grid layout using line-based placement
• Inclusive Components: Menus & Menu Buttons

Verfolgt von einem unheimlichen Schatten machen sich die beiden Hauptfiguren Ajema und Dehe auf eine abenteuerliche Suche nach einem sicheren Ort. Die kurze Geschichte ist schnell gelesen, doch aus der Hand legen mag ich das Bändchen trotzdem nicht direkt. Die farbenfrohen, detailreichen Zeichnungen der Landschaften und Charaktere lassen mich immer wieder hin- und herblättern.

Das Lettering gibt mir zunächst Rätsel auf: Warum hat das f einen Doppel-Querstrich? Die gewählte Schriftart scheint mir etwas exaltiert, im Kontext der Zeichnungen zu aufmerksamkeitsstark. Doch dann macht plötzlich alles Sinn: Die Schrift „Inky Hands“ ist von Jonas entwickelt und basiert auf seiner eigenen Handschrift.

Der 32 Seiten starke Comic im A5-Format ist auf gelblichweißem Naturpapier gedruckt, was mir haptisch und visuell gut gefällt. Für einen noch buchigeren Gesamteindruck könnte ich mir auch ein etwas dünneres Papier für die Innenseiten vorstellen – und zur Drahtklammerheftung einen gepressten Rücken! Dadurch liegt die Broschüre schön flach und der Umschlag wölbt sich nicht hoch.

Aufmerksam geworden bin ich auf den Comic über Jonas’ Mastodon-Ankündigung, zu beziehen ist „Der Schatten“ als gedrucktes Heft oder eBook über seine Website. Ganz Ungeduldige können den Comic dort auch direkt kostenlos als PDF lesen.

Jonas und ich haben zusammen studiert und ich schätze ihn als Illustrator und Gestalter. Jonas lebt und arbeitet in Lübeck und Edinburgh, Schottland und auch der Comic ist sowohl auf Deutsch als auch auf Englisch erschienen. Nice!

Vielleicht gibt es ja in Zukunft noch mehr von Ajema und Dehe zu lesen und sehen. Ich würde mich freuen. Bis dahin denke ich weiter über die versteckte Frage an mich als Leserin nach …

Für die Neugestaltung unseres Internetauftritts hatten wir uns drei Ziele gesetzt:

• Unsere bestehenden Websites sollten zusammengeführt werden: Die Inhalte der bisherige Bürowebsite und die Beiträge unserer in die Jahre gekommenen Blogs, sofern diese inhaltlich passend schienen.
• Texte und Sprache sollten klarer und prägnanter, Leistungen ausführlicher beschrieben werden.
• Projekte und Textinhalte sollten einfacher bearbeitet und ergänzt werden können. Unsere bisherige Seite war ein pfiffig konsturierter statischer One-Pager, der sich hierfür als zu sperrig erwiesen hatte.

Designprozess

Für die Erarbeitung des Designs war es für uns essentiell, gestalterische Rahmenbedingungen zu setzen. Ausgangspunkt war ein zweiteiliger Sammlungsprozess: Zuerst suchten wir nach Gestaltungselementen unserer bestehenden Internetauftritte, die wir gerne in das neue Design überführen wollten. Danach begannen wir, Layoutideen zusammenzutragen, die den Möglichkeiten der technischen Realisierung mit CSS Grid1 und Flexbox Rechnung trugen und ein stärkeres Spiel mit Weiß- und Leerraum ausprobierten. Als Inspiration diente uns hierfür vor allem Magazingestaltung aus dem Printbereich.

Unsere bisherigen, nun offline geschalteten Blogs johannahoerrmann.de und nilshoerrmann.de, verwendeten ein Zwillingsdesign, das sich nur durch das Farbschema unterschied. Die Navigation reagierte mit einem Amplitudenausschlag auf die Mausinteraktionen der Seitenbesucher:innen.

Beim Versuch, dieses Layoutelement zu übertragen, stießen wir immer wieder auf das Problem, dass der Amplitudenausschlag zu viele Bildinhalte verdeckte. Nach zahlreichen Variationen verwandelte sich dieses Element zur Kopfzeile ohne Animation, der verspielte Sprachumschalter ist als Referenz zum alten Design geblieben.

Typografisch entschieden wir uns für einen Wechsel: Nachdem wir seit Gründung unseres Büros im Web auf die “FF Tisa” von Mitja Miklavčič (Fontshop) gesetzt hatten, stiegen wir mit dem neuen Design auf die “Skolar Sans” von David Březina und Sláva Jevčinová (Rosetta) um. Ergänzt wird diese durch die “iA Writer Duo” von iA, einer Variante der “IBM Plex”, die wir für stärker datenorientierte Inhalte einsetzen.

Umsetzung

Als wir anfingen, das Design unser Website auszuarbeiten, befanden wir uns bereits für Kundenprojekte in einem Neuorientierungsprozess bei der Wahl des Content-Managment-Systems. Nachdem wir jahrelang erfolgreich Symphony eingesetzt hatten, war das System in die Jahre gekommen und dessen Weiterentwicklung ins Stocken geraten. Die Entwicklung von Kirby 3, die als private Beta stattfand, weckte daher unser Interesse. Vor allem, weil das System auf wesentliche Konzepte setzt, die uns wichtig sind: Inhaltsstrukturen und Eingabefelder lassen sich frei gestalten, es werden keine Vorgaben für den Seitenaufbau gemacht. Diese Flexibilität trägt sich ins Frontend fort, wo keine Einschränkungen für die Gestaltung des Markups bestehen.

Ein großes Plus, das bei Kirby hinzukam, war die Speicherung aller Inhalte in Textdateien auf dem Server. Dies empfanden wir als große Vereinfachung im Vergleich zu einem datenbankgestützten System, bei dem alle Inhalte abstrakt gespeichert werden. Textdateien lassen sich auf jedem Computer öffnen, verschieben und bearbeiten – es sind keine Spezialkenntnisse oder -programme erforderlich. Die Möglichkeit, alle Dateien per suchen und ersetzen schnell anpassen zu können, erwies sich insbesondere während des Übertrags der bestehenden Inhalte schnell als großer Vorteil.

Schwerer taten wir uns beim Umstieg mit den Kirby-Templates, die aus einer Mischung aus PHP-Befehlen und HTML bestehen. Hier waren wir mit XSLT in Symphony eine saubere Trennung von Datenlogik und Markup gewöhnt. Kirbys Templatesystem bietet – wenn man sich darauf einlässt – viele Möglichkeiten, es ist und bleibt aber ein Komplexitätsfaktor für uns.

Zusammenfassung

Für uns hat sich der Schritt zu einem neuen CMS gelohnt, denn Kirby ist für einfache ebenso wie für komplexe Internetauftritte gleichermaßen zu empfehlen. Das System ist schnell, flexibel, vielseitig und wird kontinuierlich entwickelt. Sein Entwicklerteam und die offene Community, die sich durch Freundlichkeit und Hilfsbereitschaft auszeichnen, haben uns den Einstieg sehr erleichtert.2 Unser gesetztes Ziel, alle Seiteninhalte leichter bearbeiten zu können, haben wir erreicht.

Der Designprozess unserer Website hat für uns inhaltlich für Klarheit gesorgt. Dabei sind bereits Ideen für die Weiterentwicklung entstanden, die skizziert, aber noch nicht umgesetzt sind – seien es ausführliche Projektstudien oder die Einbindung von Linksammlungen und Empfehlungen.

Unser Ziel ist es, die Seite im Laufe des Jahres schrittweise zu erweitern und auszubauen und vor allem wieder in ein regelmäßiges Schreiben und Veröffentlichen von Textbeiträgen einzusteigen. Jetzt müssen wir nur entscheiden, mit welcher Idee wir weitermachen. Am besten geben wir uns wieder selbst einen Auftrag und machen einen Plan.

Auf den ersten Blick schien der Aufbau unserer vorherigen Website nicht weiter auffällig: Es gab eine Begrüßung, eine Projektübersicht, gefilterte Unterseiten. Doch genau hier kommen wir an einen Punkt, der unter der Haube anders war, als bei den meisten anderen Seiten, die wir gestaltet haben: Eigentlich gab es gar keine Unterseiten. Der gesamte Auftritt war eine einzige, statische HTML-Seite – kein CMS, keine Templates, alle Unterseiten waren ein pfiffiger Trick.

Das Prinzip war recht simpel: Im Markup jedes Projektes waren Kategorien und Metaangaben in data-Attributen hinterlegt, die es ermöglichten, virtuelle Übersichten zu generieren. Per JavaScript wurde die Gesamtansicht je Kategorie dupliziert und gefiltert, die Navigation gesteuert und per Animation von einer Ansicht zur nächsten gewechselt. Die Website war auch ohne JavaScript voll funktionsfähig, in diesem Fall fehlte lediglich die zuvor genannte Filterung. Ein Zaubertrick mit doppeltem Boden sozusagen.

Hinter den Kulissen

Das Markup eines Projektes sah beispielsweise wie folgt aus:

<section 
    id="stilbluete" 
    class="project block-stilbluete" 
    data-categories="Webdesign"
>
    <aside class="meta centered">
        <a href="#stilbluete">
            <span class="meta-designer">hn</span>
            <span class="meta-number">01/1</span>
        </a>
    </aside>
    <article class="text-slides">
        <p>
            <a href="http://stil-bluete.net">
                Stil-Blüte Handarbeit &amp; Co.
            </a>
            ist ein Wollgeschäft in Braunschweig, welches sich auf
            außergewöhnliche Handstrickgarne spezialisiert hat. Der
            Internetauftritt umfasst Onlineshop, Kursanmeldung und
            Informationen rund um das Ladengeschäft, bei denen auch
            Jack-Russel-Terrier Rudi seine Abenteuer als Ladenhüter mit
            den Lesern teilt. Die Gestaltung sollte sich in ihrer
            Klarheit bewusst von gängigen Onlineshops abheben. Für die
            Website entstanden ein eigenes Iconset sowie kleinere
            Illustrationen.
        </p>
    </article>
    <small class="text-center fineprint">
        <time class="uppercase" datetime="2009">seit 2009</time>
        Website, Shop, Icons, Illustration, Symphony
    </small>
    <div class="card centered grid">
        <div class="column size-12 ratio-3-2">
            <a 
                href="media/stilbluete-startseite.png" 
                class="image-placeholder" 
                data-alt="Screenshot stil-bluete.net" 
            >
                → Link zum Bild
            </a>
        </div>
    </div>
</section>

Das Attribute data-categories benannte eine oder mehrere Kategorien auf deren Basis dann die Navigation geschrieben und die Unterseiten erstellt wurden:

function createCategoryFilters() {
    var ul = document.querySelector('#footer .footer-filters');

    // Add category filters
    categories.forEach(function (category) {
        var li = document.createElement('li'),
            a = document.createElement('a'),
            text = document.createTextNode(category);

        // Set filter link
        a.setAttribute('href', 'kategorie/' + createHandle(category));
        a.setAttribute('class', 'footer-filter');

        // Append Elements
        a.appendChild(text);
        li.appendChild(a);
        ul.insertBefore(li, ul.firstChild);
    });
}

function createCategoryPages() {
    // Setup pages
    categories.forEach(function (name) {
        var clone = slides.querySelector('.slide-all').cloneNode(true);

        clone.classList.remove('slide-all');
        clone.classList.remove('slide-active');
        clone.classList.add('slide-' + createHandle(name));
        clone.classList.add('slide-hidden');

        // Filter page by category
        [].forEach.call(clone.querySelectorAll('section'), function (project) {
            var currentCategories = project
                .getAttribute('data-categories')
                .split(', ');

            if (currentCategories.indexOf(name) == -1) {
                project.parentNode.removeChild(project);
            }
        });

        slides.appendChild(clone);
    });
}

Jetzt noch schnell einen Screenshot gemacht. Schön wars!

Dies ist ein Abenteuer.

Am 28. März 2014 begebe ich mich auf eine Reise. Ich werde bis bald zu meiner Familie in Braunschweig sagen, in einen Zug nach Marburg steigen, mich mit meiner Mutter treffen, einen Zug nach Frankfurt nehmen, ein Flugzeug nach Toronto besteigen, meine Schwester in die Arme schließen, zwei Tage später zusammen mit meinen beiden Mädels in ein Flugzeug nach Chicago steigen, zum ersten Mal in meinem Leben die Grenze zu den USA passieren, ein weiteres Flugzeug betreten, um schließlich in Los Angeles, Kalifornien, zu landen.

24 Tage lang werde ich jeden Tag eine Postkarte schreiben und sie an jemand Besonderes schicken.

Ich erzähl’ euch warum.

Dies ist meine Familiengeschichte.

Meine Mutter ist in Covina aufgewachsen, gleich östlich von Los Angeles. Während ihres Studiums kam sie nach Deutschland und ist, nach einem Jahr zurück zu Hause, 1972 endgültig hierher gezogen. Meine Großeltern und eine meiner Tanten zogen kurz darauf nach Ontario, Kanada, das für mich zur englischsprachigen Heimat wurde.

Kalifornien. Mit unserem kalten deutschen Wetter schließe ich Frieden, wenn ich im Hochsommer aus dem kalten Treppenhaus hinaus ins Freie trete und endlich Hitze auf meiner Haut spüre. Briten sagen mir, ich klänge wie MTV. Ich liebe Eiscreme, immer, das ganze Jahr. Im Englischunterricht wurde meine amerikanische Rechtschreibung korrigiert. Ich weihte Freunde in den Genuss von Tacos und Tortillas, Maiskolben und Avocados ein. Ein seltsames Gefühl des Heimwehs beschleicht mich beim Anblick von Bildern wildfremder Menschen, die die Stadt der Engel von einem der umliegenden Wanderwege aus zeigen. Mir ist es vollkommen unbegreiflich, dass andere Menschen bereits dort waren und ich noch nie.

Das ist mein kalifornisches Blut!, rufe ich bei jeder passenden Gelegenheit freudig aus.

In eines meiner ersten Tagebücher schrieb ich: Nächstes Jahr fliegen wir nach Kalifornien. Ich war sechs. Jetzt bin ich dreißig. 24 Jahre Zeit zu träumen, Pläne zu schmieden und in die Tat umzusetzen – welch ein Vorlauf! Jetzt ist es soweit, und ich bin mehr als nur ein bisschen aufgeregt, dieses Abenteuer zu entdecken.

Das ist ein Experiment.

So sieht mein Plan aus. Er ist ganz einfach:

Vom 28. März bis 21. April möchte ich für jeden Tag meiner Reise einen Brieffreund finden. Ich werde jeden Tag eine Postkarte schreiben, dabei ein Foto von der Vorderseite und eines von der Rückseite machen. Die Karte werde ich abschicken und die Fotos auf Instagram posten, um meine Reisedokumentation zu dokumentieren.

Es geht ums Schreiben. Teilen. Feiern. Verbinden. Experimentieren. Wagen. Rausgehen. Brieffreunde haben. Offline-Bloggen. Analog-Bloggen. Entdecken. Machen. Senden. Mit der Hand schreiben. Addressieren. Geschichten erzählen. Dokumentieren. Loslassen. Überraschen. Mitbringsel sammeln. Erinnerungen greifbar machen.

Komm mit.

Ich freue mich ungemein auf dieses Abenteuer und ich würde dich gerne mit auf meine Reise nehmen. Folge mir auf Instagram, um die Postkarten zu lesen und eine Blick in mein Leben unterwegs zu werfen.

Falls du dich in Los Angeles und Umgebung auskennst und Tipps für mich hast, freue ich mich über eine E-Mail.

Danksagungen.

Lisa und Ma – dieses Abenteuer würde ohne euch nicht stattfinden. Habt tausend Dank, dass ihr mich mitnehmt!

Pa – danke für mehr als drei Kästen mit Dias aus Kalifornien samt akribischer Aufzeichnungen. Welch ein unglaublicher Schatz.

Nils und Max – ich hab euch lieb, meine Jungs. Danke für’s die Stellung halten. Ihr wisst, dass ich für uns alle drei auf Reisen bin.

Die folgenden Überlegungen sind als Antwort auf auf Brendan Abbotts Gist über einen modularen Ansatz für Symphony entstanden und stehen bisher nur auf Englisch zur Verfügung:

When I think about the modularisation of Symphony, I think of it from an enduser’s perspective where the enduser is someone just using the system without hacking it. Maybe this slightly different view can refine the proposed new project structure. For me, a modularised Symphony should be a series of consecutive blocks I can choose to use. These blocks are:

1. data management
2. output management
3. administration

1. Data management

The data block is everything from the core related to data management. In old words, there are fields, sections, entries, data sources and events. But there is no routing (pages) and no templating (XSLT). This block has no GUI but there is an API to manage data input and output (GET, PUT, POST, DELETE and such).

This data block can be used to build an API server without anything else. You’d administer it using a CLI.

If I’d like to use Symphony alongside front-end frameworks like Angular, React or Ember this is all I need.

Rethinking data sources and events

In this context, data sources and events would be advanced to API endpoint definitions. These files would describe

• which API endpoints exist,
• which authentication to use (none, Symphony, Members, oAuth, …)
• which output to return at an endpoint (data source like)
• which input to accept at an endpoint (event like)
• the content flavour (XML, JSON, …)

2. Output management

The output block integrates routing, filtering and templating and is only needed when relying on „traditional“ server-side templating like the XSL we are all used to. Similar to block 1, it doesn’t offer a GUI, all configuration is file-based and stored in the workspace.

Now that data sources and events have transformed into endpoints, you’d no longer attach those to your pages. You’d add API calls to your pages instead:

• /symphony/api/sections/entries/?flavor=xml&sort=desc&limit=20&filter=…
• /symphony/api/sections/comments/?flavor=xml&sort=asc&limit=10

The output block will retrieve this data based on a route and will call a transformer (e. g. XSL, Twig, Handlebars) to create the output. The pages store all this in a configuration file that also defines which template to use.

If I’m a developer, blocks 1 and 2 might be sufficient for me to build any site or app I need

3. Administration

This is what we called the backend up to now. It’s the GUI to access and manage Symphony’s data input and output. It should offer everything you need as a designer to create a website or app and should offer everything you need as an author. Although it might look completely different, the purpose of this block is exactly the same as the one of the current backend.

This block is only needed, if I’d like to use a graphical user interface.

Admin as a workspace

This is made for front-end users and therefore it should be built using technology the Symphony front-end folks are used to:

• XML
• XSLT
• HTML
• CSS
• JavaScript

This will help developing the admin interface continuously because extending and improving the backend works exactly as building a front-end site. There is no need to program.

The backend is just one additional workspace. A front-end app to access the Symphony API. Which means in reverse conclusion that anything that can be done in the backend can also be done in a custom front-end.

Multiple Workspaces

If you think this further, it would be logical to not have one workspace but multiple. This would simplify different use cases:

• different iterations of the same site could live side-by-side
• one install could server different sites

Extensions

As we are talking about a major version release there is no need to be nostalgic: decide in favour of one, go with the common composer.json.

Looking at things from the front-end perspective, I’d favour Symphony’s current opinionated approach of using convention over configuration. It’s one of the great strengths of the system in my eyes. Things just look and work similar across all extensions which helps a lot when you are not a backend developer but have to dive into the world of the core and its extensions.

John O’Nolan, the creator of Ghost, has written about their choice of Ember for the Ghost backend that accentuates the benefits of this approach:

Naming

I’d suggest to not use the plain word symphony for naming components but to keep up using symphony-cms in order to minimise confusion with Symfony.

Während wir dieser Tage ein altes Projekt auffrischten, kamen wir auf Symphony zurück und mussten feststellen, wie gut es nach wie vor ist. Es erfindet das Rad nicht neu, es funktioniert einfach, auch wenn es natürlich hier und da seine Schwierigkeiten hat. Es ist ist immer noch eine gute Wahl für moderne Websites oder Webapps.

Wie steht es um das System?

Das Symphony-Team hat sich in den vergangenen Jahren sehr verändert: Core-Entwickler sind zu anderen Projekten weitergezogen, einige kamen später wieder. Während das Forum dieser Tage sehr ruhig ist, gibt es noch immer eine aktive Gruppe auf Github und Gitter.

Vor wenigen Tage hat Brendan Abbot einen Gist mit Ideen gepostet, wie man das System modularisieren und modernisieren könnte ohne dabei die Stärken einzubüßen:

Ich denke, diese Ideen sollten geteilt und in größerer Runde diskutiert werden:
A modular approach for Symphony

Dies möchten wir gerne ändern.

In loser Folge möchten wir fortan zusammentragen, was uns bei der Arbeit und im Leben begegnet ist, als kommentierte und unkommentierte Linksammlung zu einem bestimmten Thema. Es geht los mit Entdeckungen und Entdeckungsreisen.

• Ethan Marcotte – The Map Is Not The Territory

Der Vortrag von Ethan Marcotte liegt bereits zwei Jahre zurück und ist immer noch zeitaktuell. Es geht um Verortung und die Wahrnehmung der Welt und was dies für uns, das Internet und Webdesign bedeutet.

Vorsätze

Das neue Jahr ist bereits einen Monat alt, trotzdem ist es interessant, sich einige Gedanken darüber zu machen, welche Themen in den kommenden Monaten wichtig werden und welche Tendenzen es geben könnte. Abzuwarten bleibt, was wir über die selben Themen in 12 Monaten denken:

• 2014: Bringing design to life
• What Screens Want
• CSS Blend Modes could be the next big thing in Web Design
• Your website should stop doing this right now

A propos Vorsätze. Wie wäre es, diese gegen ein einzelnes Wort als Begleiter für das Jahr zu tauschen?

• One Little Word, a concept by Ali Edwards

Schneegestöber

In diesem Zusammenhang ist auch ein Blick zurück interessant: Snow Fall, ein Gestaltungsexperiment der New York Times, hat in den vergangenen anderthalb Jahren Bewegung in das Online-Editorial-Design gebracht. Es gibt immer mehr Versuche, multimediale Erzählungen zu entwerfen und zu veröffentlichen: Die Zeit hat dies zu 100 Jahren Tour de France gezeigt, der britische Guardian erst kürzlich zum Thema Luftfahrtgeschichte, wobei sich Themenkomplexe von bloßen Artikeln zu keinen Apps und Fernsehstücken entwickeln. Die nachfolgenden Artikel befassen sich mit den Möglichkeiten und Schwierigkeiten dieser Versuche:

• Attention, rhythm & weight
• Snow Fail: Do Readers Really Prefer Parallax Web Design?

Interessante Konzepte und Projekte

• Rethink the Airline Boarding Pass
• Hello Processing