Thank you to our clients for working on great projects with us, for coming back, for recommending us to others and making all of this possible!

 

Translated from the introductory text on the BDG website:

Vanilla Web Design

Designing with Browser, Git and Kirby.

Why work with Git as designers? Why value the browser as the most important app? And why use Kirby as content managment system?

Johanna and Nils talk about how they use their tech stack of browser, text editor, Git and Kirby CMS for detail-oriented web design. They explore project workflows, processes and systems from design concept and drafts to sustainable implementation.

Watch

A recording of our February talk is now available on the BDG website and directly on Vimeo. Again, it’s in German – but do take a peek nonetheless!

 

I have been building websites since 1999 and thus my first designs included a lot of layout tables with spacer gifs. Over the years, CSS became more prominent and powerful but often it was still hacky to create interesting layouts. We used floats for positioning, which were created for something different, too, we used all sorts of creative solutions. More complex layouts required JavaScript for positioning, timing, animation.

Things changed fundamentally with the creation of CSS Flexbox and CSS Grid which finally gave us freedom to design in space. Oh boy, how I love CSS Grid! But while working on our form components, I noticed how hard it can be to overcome your muscle memory and to not fall back into old habits:

I wanted to build a menu component where the menu opens by clicking on a button and expands in either of the four cardinal directions, aligning itself to the start, center or end of the related axis. I first thought this would be very complicated, involving a lot of math to correctly position the menu. Checking existing libraries seemed to comfirm this as they relied on a lot of JavaScript with absolute positioning and complex distance calculations.

This felt wrong, because one of the strengths of CSS Flexbox and Grid is their ability to do complex calculations for us. They allow for easy alignment and justification (even element centering, my old web veterans!) which is exactly what I was looking for. After a bit of thinking, I found a surprisingly easy solution to my problem: zero space grid cells combined with smart overflow handling.

The invisible grid

To position the menu anywhere I wanted, I needed a three by three grid with the button in the middle and the menu in one of the outer cells, depending on the required placement and alignment:

.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 {
    /* placed below, aligned to the left */
    grid-column-start: 2;
    grid-row-start: 3;
    justify-self: start;
    align-self: start;
}

While this setup works great with the menu closed, the cells holding the menu start to expand to the size of said menu when it gets opened and the whole page layout starts to shuffle. Instead of this, we need the menu to float above the other content which is usually solved by absolutely positioning the menu in relation to the wrapper. Thus requiring script-based position calculation.

The great thing about CSS Grid is: it allows for overflowing content, by setting the outer cells’ size to 0. This makes the menu float above the outer content:

.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 {
    /* placed below, aligned to the left */
    grid-column-start: 2;
    grid-row-start: 3;
    justify-self: start;
    align-self: start;
}

Setting this up without absolute positioning, relying purely on standard CSS Grid aligment and justifications opens the way for an additional feature: applying position: sticky; to the menu. This will neatly stop the menu from exiting the screen on scroll before the button does.

menu {
    /* placed below, aligned to the left */
    grid-column-start: 2;
    grid-row-start: 3;
    justify-self: start;
    align-self: start;
    /* stick to the next scrollable parent */
    position: sticky;
    top: 0;
    left: 0;
    right: 0;
    bottom: 0;
}

The button, the menu and the need for ghost cells

This concept worked very well for the cells that did not share space with the menu button and I was very happy with the solution until I noticed that be page began to jump when opening the menu centered to the button. While the outer grid cells could shrink to zero space easily because they were not competing with any other element, the center cells were still set to min-content and thus in conflict with the button size. The browser recalculated the grid sizes when opening the menu which was then no longer floating on top of the page content.

This conflict seemed unsolvable until I noticed that there was a way to apply min-content and 0 width to the button at the same time by dividing it into multiple cells:

.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;
}

Now, we have a five by five grid with the zero width cells reserved for the menu and the button streching across the centered „ghost“ cells.

Demo

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

Of course, this is not everything needed for a working menu. There is JavaScript required to toggle the menu and to make sure everything is accessible, including keyboard navigation. But it’s a great start and a good example how modern CSS techniques can help us solve complex layout tasks without overcomplicating things. And that we should regularly rethink how we solve our web layout ideas.

Further reading

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

Trailed by a creepy shadow, the two main characters Ajema and Dehe set out on an adventurous search for a safe haven. The short story is a quick read, but I still can’t put the booklet down right away. The colorful, detailed drawings of landscapes and characters keep me flipping the pages back and forth over and over.

At first, the lettering puzzles me: Why does the f have a double crossbar? The chosen typeface seems a bit exalted to me, almost too attention-catching in the illustrations’ context. Suddenly it all falls into place: The typeface “Inky Hands” is actually created by Jonas and based on his own handwriting.

The 32-page comic in A5 size is printed on cream white, uncoated paper, which I appreciate both haptically and visually. For an even book-ier appearance, I could see a slightly thinner paper for the inner pages – and enhancing the saddle-stitching with a pressed back! As a result, the closed brochure could lie flat nicely without bulging.

I discovered the comic through Jonas’ Mastodon announcement, “The Shadow” can be obtained as printed booklet or eBook via his website. For everyone who needs to start reading right now, the comic can also be read as a PDF directly on his website, free of charge.

Jonas and I studied together and I value him as an illustrator and designer. Jonas lives and works both in Edinburgh and Lübeck, Germany and the comic has also been published in both Englisch and German. Schön!

Maybe, in the future, there’ll be more to read and see of Ajema and Dehe. I would be thrilled. Until then, I’ll continue to ponder the hidden question posed to me as a reader …

We set three goals for the redesign of our website:

• Content of our existing sites – the studio website and our dated blogs – should be merged when applicable.
• Texts and language should be clearer and more concise, services described more thoroughly.
• Editing and adding content should become easier. Our existing site was a smart static one-pager that turned out to be too inflexible in this regard.

Design process

When working on the overall design concept, it was essential to us to create general constrains. Therefore, we started a twofold process of gathering ideas: First, we looked at design elements within our existing sites which we wanted to move to the new site. Second, we collected layout ideas that could be implemented with CSS Grid1 and Flexbox, allowing us to make use of space. In this matter, editorial design found in print magazines was our main inspiration.

Our old blogs, formerly residing at johannahoerrmann.de and nilshoerrmann.de, made use of a twin layout that differed in its respective color scheme. The navigation featured an amplitude-like animation on interaction with a pointer device.

When trying to transfer this element to our new design concept, we repeatedly ran into the issue of the amplitude covering up too much content information within the image. After many variations, this element developed into a fixed header without animation, keeping the playful language switcher as a reference to the former design.

Regarding the new website typography, we opted for a change: Having used “FF Tisa” by Mitja Miklavčič (Fontshop) on the web since establishing our studio, we switched to “Skolar Sans” by David Březina and Sláva Jevčinová (Rosetta) as our new main typeface. As an addition, we brought in “iA Writer Duo” by iA, a variant of “IBM Plex”, for data-like content.

Implementation

When we started working on our site’s new design, we were already in the process of transitioning client projects to a new content management system. After having successfully used Symphony for years, the system’s development stagnated. Therefore, the development of Kirby 3 caught our interest. Foremost, because the system focusses on concepts that are essential to us: content structures and input fields can be designed freely, there are no restrictions with regard to the general site organisation. This flexibility is reflected by the front-end, posing no constraints for markup output.

A big plus offered by Kirby was storing content in text files on the server. This proved to be a real simplification in comparison to database systems, where content is stored abstractly. Text files can be opened, edited and moved on every computer – with no special knowledge or apps required. The abbility to adjust files by search and replace was especially helpful in the context of moving and updating existing content.

The one thing that made switching systems hard was templating. Kirby templates use a mix of PHP and HTML, which was contrary to the clear separation of concerns we knew from using XSLT in Symphony. Kirby’s templating system offers a wide range of possibilities as soon as you get into it, but it still is a complexity factor for us.

Conclusion

For us, moving to Kirby has proven to be a good decision. It’s a fast, flexible and versatile system that can be used for small and large sites alike and is in continuous development. The developer team and the open community excel by their friendlyness and cooperativeness, which really helped us make the switch.2. With the site now running on Kirby, we reached our goal of making our content easier to maintain.

With regards to content, the design process of our website provided clarity. Further ideas to develop the site have been sketched, but not implemented yet – be it detailed case studies or the introduction of link collection and recommendations.

Our goal is to incrementally extend our site and, especially, to get back into the flow of writing and publishing regularly. Now to decide what idea to pick up first … let’s just hire ourselves again and plot a plan.

At first sight, there didn’t seem to be anything conspicuous about our previous website’s construction. There was an introduction, a project overview and filtered sub pages. Yet, under the hood, this is the point that differed from most other websites we’ve designed: actually, there were no sub pages. The entire site was a single static HTML page – no CMS, no templates, all sub pages were just a clever trick.

The concept was quite simple: each project had categories and meta information stored in data attributes in the markup that allowed the generation of virtual overviews. Using JavaScript, the general view was cloned and filtered by category, the navigation was operated and views switched with animations. Still, the website was fully functional without any scripts, just lacking the filters in that case. A magic trick with safety net.

Backstage

A project’s markup looked like this, for example:

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

The attribute data-categories contained one or more categories that were used to create the navigation and the subpages:

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);
    });
}

So, one last screenshot. What a great time we had!

While refreshing an old project, we came back to Symphony just to find out again how great it is. It doesn’t reinvent the wheel, it just works although it of course has its quirks as well. And it’s still a good choice for modern website and webapps.

So what’s the state of the system?

The Symphony team underwent a lot of changes over the past years: core developers moved on to other projects, some rejoined the team later on. While the forum is very quiet these days, there is still an active group on Github and Gitter.

Just a few days ago, Brendan Abbott posted a Gist of ideas how to modularise and modernise the system while keeping its core strengths:

I think, these ideas should be shared and discussed with a wider audience:
A modular approach for Symphony

This is an adventure.

On March 28, 2014 I will embark on a journey. I’ll say good-bye to my husband and son in Braunschweig, Germany, step on a train to Marburg, meet up with my mother, catch a train to Frankfurt, board an airplane to Toronto, greet my sister, board a plane to Chicago together with both of my ladies two days later, cross the border to the U.S. for the first time in my life, get on yet another plane and land in Los Angeles, California.

Each day, for 24 days, I will write a postcard and send it off to someone special.

Here’s why.

This is my family history.

My mother grew up in Covina, just east of L.A. She came to Germany as a student, went back home for a year during her studies and returned to Germany for good in 1972. My grandparents and one of my aunts moved to Ontario, Canada shortly after, and that’s where my English speakin’ home base has been ever since.

California. I’m at peace with our German weather when I step out of the cold stairway in the middle of the summer, open the front door and am finally met with heat on my skin. I am told I sound like MTV by English folks. I love ice cream, year round. My spelling was corrected in English class at school. I introduced my friends to tacos and tortillas, corn on the cob and avocados. I get a strange feeling of home-sickness looking at pictures taken by total strangers, overlooking the city from one of the trails. I find it utterly unbelievable that other people have actually been there, when I have not.

It’s my Californian blood!, I happily exclaim whenever the chance arises.

I remember writing in one of my first journals: Next year we’ll fly to California. I was six. Now I’m thirty. That makes 24 years of dreaming, scheming and planning this trip – talk about build-up! Now, it is happening, and I am beyond excited to live this adventure.

This is an experiment.

Here’s my plan. It’s pretty simple:

Find a penpal for each day from March 28 to April 21. Write a postcard every day while I’m away from home. Take a photo of the front, and a photo of the back. Mail the card and share the photos on instagram to document my travel documentation.

This is about writing. Sharing. Celebrating. Connecting. Experimenting. Daring. Reaching out. Penpals. Offline blogging. Analogue blogging. Exploring. Creating. Sending. Lettering. Addressing. Storytelling. Documenting. Letting go. Surprising. Souvenirs. Tangible memories.

Hop on.

I am truly looking forward to this journey, and I’d love to take you along for the ride. Follow me on Instagram to read the postcards and peek into my life on the road.

You are a local or have sightseeing tips you’d like to share? Send me an e-mail to get in touch, I’d be delighted to hear from you!

Thank you.

Lisa and Ma – this adventure could not be happening without you. Thank you so very much for taking me along!

Pa – thank you for more than three cases of slides from California along with meticulous notations. What an incredible treasure.

Nils and Max – I love you guys. Thank you for keeping up the good work at home. You know I’m travelling for the three of us, really.

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.

Alex: Nachdem ich bereits zehn Jahre in Weimar wohnte, habe ich zufällig erfahren, dass eine ganze Häuserzeile, die ich immer als historisch betrachtet hatte, eine Rekonstruktion aus den späten Achzigerjahren war. Das war die Initialzündung einmal genauer hinzuschauen, was alles in der Stadt vernichtet worden ist. Dabei fiel mir auf, dass nicht nur die Nazibauten und der Krieg, sondern auch die rigorosen “DDR-Sanierungen” durch Abriss große Lücken in die Stadt gerissen haben. Ich wollte mehr darüber erfahren und begann, historische Fotos von Weimar zu sammeln.

Beim Anblick der alten Aufnahmen fragt man sich immer sofort, wie das wohl heute aussieht. Da habe ich mich an die Vorher-nachher-Überlagerungen erinnert, die es zu verschiedenen Themen im Netz gibt, und versucht die historischen Motive aus gleicher Perspektive nachzuschießen. Das klappt bei manchen Motiven auf Anhieb, bei manchen ist es zum Verzweifeln.

Daraus ist die Idee zur Zeitsprung-Webseite geboren, die seitdem langsam aber sicher wächst.

Alex: Der Grundantrieb des Zeitsprungprojektes ist der Wunsch, die Bilder, die Veränderungen, im Prinzip die Vergangenheit an sich, auf eine neue Art erfahrbar zu machen. Die Vorher-nachher-Überlagerungen waren ganz pragmatisch die unkomplizierteste Methode, schnell zu schönen Ergebnissen zu kommen. Die Schiebebilder funktionieren sehr intuitiv und es gab auch ein paar fertige Skripte dazu im Netz, die ich mittlerweile aber durch ein einfacheres Konzept ersetzt habe.

Die anderen Ideen kamen erst später dazu, als aus den wenigen Bildern und Karten langsam mehr und mehr wurden. Diese sind allerdings zumeist sehr viel aufwändiger zu realisieren. Das vielleicht spannendste potentielle Projekt wäre, die gesamte Stadtentwicklung in einem zeitlich animierbaren Stadtmodell von ca. 1820 bis in die Gegenwart umzusetzen. Das grenzt jedoch an eine Lebensaufgabe, selbst wenn man Vollzeit daran arbeiten würde. Auch als 2D-Stadtplan ist das denkbar, was wesentlich einfacher umzusetzen, aber zugleich weniger anschaulich wäre.

Ein anderes, etwas kleiner gestecktes Projekt könnte die 3D-Rekonstruktion eines nicht mehr vorhandenen Stadtviertels sein. Das hat bereits jemand anderes mit der von den Nazis zerstörten Jakobsvorstadt versucht, leider ist er nicht zu erreichen, und ich kann nicht herausfinden wie weit er tatsächlich gekommen ist.

Alex: Ich habe anfangs erst einmal versucht, Material zu benutzen, welches frei verwendbar ist, zum Beispiel historische Postkarten. Der Hunger nach mehr Bildmaterial hat mich (über die Vermittlung des befreundeten Fotografen Alexander Burzik) zum Stadtarchiv Weimar geführt. Der Leiter des Stadtarchivs Dr. Jens Riederer war von Anfang an sehr hilfsbereit und so habe ich die Möglichkeit bekommen, in einer sehr großen Schatzkiste zu fischen, wovon ich bisher nur sehr wenig tatsächlich für die Zeitsprünge genutzt habe. Dazu kommen diverse bei Flickr gefundene Bilder. Dort konnte ich mich jeweils direkt mit den Urhebern absprechen, die eigentlich immer sehr nett und entgegenkommend waren. Eine weitere Quelle sind eigene Bilder aus der näheren Vergangenheit, sowie nicht zuletzt die schönen Bilder des Weimarer Fotografen Claus Bach, die er netterweise zur Verfügung stellt.

Alex: Ich suche mir daheim die Motive aus und lade Sie auf meinen iPod. Dann versuche ich, vor Ort den passenden Standpunkt zu finden. Entscheidend dabei ist es, Überlagerungen von Vorder- und Hintergrund des Bildes zu finden. Wenn man dann beispielsweise am rechten Bildrand eine Überlagerung gefunden hat, muss man idealerweise am linken eine weitere finden und sich so lange entsprechend bewegen, bis es dort auch passt. Das gleiche gilt für oben und unten. Oft schieße ich dann eine Reihe Bilder, damit ich daheim etwas Auswahl habe, wenn es nicht so ganz stimmt. In besonders schwierigen Fällen drucke ich mir das Bild etwas größer aus, da der iPod als Referenz schon etwas klein ist. Besonders hilfreich ist es, die Brennweite des Originalbildes zu kennen. Wenn man diese auf das Äquivalent einer modernen Kamera umrechnet, kann man mit einem Zoomobjektiv die entsprechende Brennweite einstellen. Wählt man dann den ungefähren Bildausschnitt des Originalbildes, so hat man schon relativ genau den Abstand des Originalfotografen zum Bild. Danach muss man dann wieder nach den besagten Überlagerungen schauen.

Alex: Durchweg positiv. Der Bekanntheitsgrad ist noch relativ gering, aber die Seite ist immerhin schon auf der offiziellen Stadtseite Weimars verlinkt. Leider halten sich die meisten Besucher mit Kommentaren bisher zurück, ich würde mir etwas mehr Diskussion wünschen. Vielleicht nimmt das aber zusammen mit dem generellen Bekanntheitsgrad zu. Ich muss auch wieder regelmäßiger neue Zeitsprünge einsetzen, das schleift in letzter Zeit leider etwas.

Alex: Ich finde das eigentlich alles gleichermaßen spannend. Weimar hat da viel zu bieten.

Da wären erst einmal die historischen Stadterweiterungen, besonders zur Gründerzeit. Dann die einschneidenden Bauten des Nationalsozialismus, die den Weimarern den nördlichen Teil des Jakobsviertels mitsamt einem Teil des Asbachgrünzuges geraubt haben. Das ist vielen heute gar nicht mehr bewusst. Auch das Hotel Elefant wirbt mit “klassischem Charme”, ist aber von den Nazis abgerissen und als kompletter Neubau im NS-Stil mitsamt “Führerwohnung” 1936/37 neu errichtet worden.

Dann die Zerstörungen im zweiten Weltkrieg, die vergleichsweise begrenzt waren, aber doch einige zum Teil immer noch vorhandene Schneisen in die Stadt gezogen haben. Das Nationaltheater (in dem die erste Deutsche Verfassung entstand) zum Beispiel brannte völlig aus und sogar Goethes und Schillers Wohnhaus wurden schwer beschädigt.

In der DDR wurden dann viele Häuser mangels Sanierungsexpertise und Material zerstört und nur teilweise als Neubau in alter Kubatur wieder hergestellt. Es hat mich besonders erschreckt wie viele Lücken dadurch entstanden sind, die ich eher dem Krieg zugeschrieben hatte. Ein großer Teil der restlichen Jakobsvorstadt, und nicht zuletzt fast das gesamte Bornbergviertel, sind dem Abriss oder langsamen Verfall zum Opfer gefallen. Kurz vor der Wende ist sogar noch das Parkhotel, ehemaliges Wohnhaus von Johann Sebastian Bach und Geburtshaus seiner Söhne, abgerissen worden. Das ist bis heute ein Parkplatz.

Das ganze endete dann leider auch nicht vollständig mit der Wende. Auch in den Neunzigern wurden einige erhaltenswerte Gebäude für Neubauten abgerissen. Prominentestes Beispiel ist vielleicht der Abriss der ohnehin schon entstuckten “HEKA” am Theaterplatz. Dafür steht hier nun ein modernes Einkaufszentrum.

Insgesamt finde ich besonders interessant wie sich kleine Details verändern. Sei es aufgrund von Sanierungen oder einfach der voranschreitende Zerfall von Fassaden. Also Veränderungen die man mit dem Auge nicht wahrnehmen kann, die aber durch einen “Zeitraffer mit zwei Einzelbildern” erfahrbar werden.

Alex: Vor allem, dass sie weiter wachsen und gedeihen und irgendwann mal eine breit gefächerte Übersicht über die Stadt und Ihre Geschichte zeigen. Dazu würde ich mir eine lebhafte Diskussion wünschen. Vielleicht könnten die Zeitsprünge sogar einmal zusätzliche Blickwinkel bei Diskussionen zu aktuellen Themen der Stadtentwicklung, wie zum Beispiel dem geplanten neuen Bauhaus-Museum, liefern.

Vielen Dank für das Gespräch, Alexander