Fabian Michael’s Blog https://fabianmichael.de/blog Kirby Sat, 12 May 2018 00:00:00 +0000 The latest updates from my blog Video Recommendation: How to Build an Atomic Bomb https://fabianmichael.de/blog/how-to-build-an-atomic-bomb blog/how-to-build-an-atomic-bomb r I started learning how to code websites around 2000 – that’s almost 20 years ago now. Back then, I was only 13 years old and pretty excited about the future of the web and all the marvellous oppor­tu­nities that digital technology promised to open for humanity. But in 2018, the web and the whole digital tech industry has lost a lot of its shine for me.

When I first attended to the Beyond Tellerrand conference last year, I felt a different vibe than this year. Although all the scandalous behavior of secret services and tech oligarchs in terms of surveillance and abusement of power was already well-known and has been discussed for some years now, the overall mood seemed to be much more positive and uncritial than now. I remember some discussions about Tesla’s latest car models, iPhones and stuff. And that’s okay of course, the latest technology has an important impact on our work at least. But this year, I got the impression that technology was discussed in a much more critial manner and I am really welcoming that. Some announ­cements about new tech during the last years already started to alienate me, because they often lacked any critical reflection on the topic or product by our community. But as the web industry matures and everyone can see the devas­tating effects of e.g. social media services being exploited by fascists we really need to talk about ethics — better sooner than too late! Although it might feel annoying sometimes; we must realize that being unpolitical about our work is not an option any more (has it ever been?). The web is not an isolated echo chamber and everything we build has an influence on the life of real people.

Mike Monteiro’s great talk reminds us that we cannot affort reducing ourselves to being mere service providers for building an apoca­lyptic future any longer. We are human beings at first, not designers, developers or engineers. We are more than just two hands with a bank account! And we do have a choice who and what we want to work for.

]]>
Campire Scene Print https://fabianmichael.de/blog/campire-scene-print blog/campire-scene-print r After a long break, I finally took the time to work on a new screen print. Though I have kept on drawing for the better part of the year, I haven’t done any printing (my inkjet does not count …). It almost felt like a shame to have brand-new screens and inks just catching dust in the corner without actually making good use of them. But now that the first test-run has been successfully completed, I’m looking forward for many more to come.

The workshop still needs a lot of love, because the primary focus of artge​rechtes​.de has been on producing organic/​fair-​trade fashion and thus the workshop is optimized for printing on clothes in high editions. Establishing the capabi­lities for handling paper still needs some more equipment to make the process somewhat more effective, but at least the foundation has been laid. My next project will be to improve the printing table.

If you’re interested in buying one of the print shown below, just send an E-Mail to hallo@​fabianmichael.​de or info@​artgerechtes.​de.

]]>
Another Year, Another Revision https://fabianmichael.de/blog/another-year-another-revision blog/another-year-another-revision r In my opinion, personal side projects are always a great way for trying out new things. However, the downside of that is always tht it takes a lot of time. As more of my work shifts towards design and conception, keeping up with the latest web techno­logies is often more than just a trivial side-task. Though I think that my CSS skills are quite good, JavaScript nowadays often feels a bit like rocket science to me. But that’s okay somehow in an industry, that constantly shifts towards more complex products and thus needs more specialists at some points. On the other hand, being a designer with some decent knowledge about web techno­logies is never a disad­vantage, especially not since the day we started to design responsive websites. But I guess the hardest thing to learn when working on personal projects, is how to cope with the non-existent deadline. I would say, the best result would be to end up with something between the minimal solution to accomplish your goal and that fancy result that tops everything comparable you had ever seen before. In the end, you should get something you can feel comfortable with and that suits your needs.

After finishing the overhaul of my website, I am happy to finally have a platform that fits my requi­rements better than ever before. When deciding to have a portfolio or a blog, there are a lot of things to consider. Eventually, everyone’s got his*her own way of writing or showcasing his*her work. Some people prefer colored, indivi­dually designed project pages, others prefer a rather plain gallery grid where they throw in a bunch of images and maybe videos. There is no right or wrong, it really depends on your content and in which way you want to prepare it for your portfolio or your blog. But finding that out can be another journey, which takes time and practice.

For projects pages, I kept the rather minima­listic approach of having two content areas, one that is primarily intended for putting images into it, but it could basically hold every type of content. The other one is the so-called Meta area, where projects infor­mation can be found. I also designed a new navigation, which allows me to add more menu items, if there is a need for that. The headline font Abril Fatface Bold Italic has been replaced by GT Sectra Bold Italic, because I started to feel that Abril Fatface – though it’s a beatutiful font – did not complement the archaic monospace theme of the site very well.

Talking about technology: I finally I got rid of jQuery in favor of vanilla JS. It was a lot of awful work, but I learned a lot and used the room to experiment on animations, transitions and special link underlines. I am very happy with a total of static resources of roughly 150 kB (includes font files, JS and CSS gzipped). I think speed is a core feature of each contem­porary website and should never be treated as a low-priority task in any project. I’m already excited about the new projects I will publish in the coming month and about the stuff I will write here.

]]>
The Void https://fabianmichael.de/blog/the-void blog/the-void r ]]> Marina T-Shirt https://fabianmichael.de/blog/marina-t-shirt blog/marina-t-shirt r Das Marburger Bekleidungs- und Siebdruck-Kollektiv Artge​rechtes​.de existiert seit knapp zehn Jahren und handelt ausschließlich mit fair und ökologisch gehan­delter Bekleidung. Gedruckt wird dabei komplett in Handarbeit in der eigenen Manufaktur. Ich freue mich, unserer erstes gemeinsam entstandenes T-Shirt präsen­tieren zu dürfen!

Das gute Stück mit dem Titel Marina kann absofort online bestellt oder direkt bei Artge​rechtes​.de im Laden gekauft werden.

T-Shirt kaufen

]]>
ImageKit for Kirby https://fabianmichael.de/blog/imagekit-for-kirby blog/imagekit-for-kirby r I’m proud to release the first public beta of my ImageKit plugin for Kirby today. Although the plugin may seem simple at first glance, this has been a long ride. It started about 2 years ago, when I was using WordPress for my private blog. Unhappy with the built-in thumbnail API, I decided to go for something better. After the work on my WordPress plugin was almost done, I switched to Kirby and decided to start from scratch. The plugin grew very quickly and became some kind of monster, including everything from a widget to an extensive image component with support for lazyloading.

After the large amount of API changes, that came with Kirby 2.3.0, I had to adapt a lot of my plugin’s code to keep it working. So I took only the best parts of it and decided to go for a more modular approach this time. Today, I released the first component – the asynchronous thumbs API – on GitHub. I also decided to make ImageKit a commercial plugin, so I will hopefully be able to provide better support for it. 

I’m excited to hear your feedback and hope you enjoy ImageKit!

]]>
Why I Switched from WordPress to Kirby https://fabianmichael.de/blog/from-wordpress-to-kirby blog/from-wordpress-to-kirby r I have to admit at this point, that I didn’t follow any proven method to get this project finished, it was rather created by playing with design and code. Usually, I tend to use Photoshop (yeah, I’m kinda old school sometimes) for web design, because I think that designing in the browser makes me see the design too much from the technical perspective, which limits my creativity. But in this case, It was completely clear that I wanted to have something that uses a monospace font and the least amount of decorative elements as possible. So designing with code seemed to be an acceptable option in this particular case.

Why I Had Choosen WordPress

Overcoming Limitations

Almost everyone has heard of WordPress and every web designer probably knows that it is a CMS software with a strong focus on blogging. I switched from REDAXO to WordPress the day I discovered the Advanced Custom Fields (ACF) plugin, because it allows the developer to create custom forms for different types of content. When I designed a my bachelor thesis using InDesign (2011), I was wondering all the time: »Why do most website layouts look so boring compared to print?« While there was and is no universal answer to this question, I think it is connected to the design of our technology. For example: The typical WordPress template only had a single content column at that time or used some ugly worka­rounds to create additional content areas like a header slideshow. But with ACF, WordPress becomes a very versatile system, that can surpass those limitations.

The Ugly Parts

Compared to other CMS software, the community of WordPress developers is rather large. In most cases, it’s easy find a solution for almost every question or problem you have when developing a website with WordPress. There are a ton of plugins, widgets, snippets and themes at your fingertips, but sadly, the quality of those resources varies a lot.

While I really like the admin panel’s interface design and how fast it is keeping up with by imple­menting tidbits like drag-and-drop upload of image files or support for High-DPI screens, there are — on the other hand — a lot of downsides about WordPress:

  1. Image Resizing: WordPress resizes images only on upload by default. This might have been a good-enough solution in the days of desktop-only websites. But nowadays in the age of responsive design, there is a need for a lot different-sized versions of every image. For example, this site has roughly 3 – 4 sizes for every image file plus a High-DPI-version for each of those.1 It is possible in WordPress to define additional image sizes, but if you do that, uploading an image easily takes 30 seconds or more, which makes editing a pain in the ass. Additionally, a lot of those resized images are never used and only eat space on your server. If you change one of those sizes or switch to a different theme, you need an additional plugin to recreate all resized images.
  2. i18n: There is no support for multi-language websites out of the box. This can be fixed by … guess what? Another plugin! I used WPML, which works somehow, but is neither pretty nor free. And it also adds a meta tag to your frontend code, telling its version to the client without asking.
    Though the admin panel of WordPress is available in a variety of languages, choosing anything else but English comes at the cost of a heavy performance drop.2
  3. Security: Due to the fact that WordPress is the most popular CMS software, it also attracts a lot of attackers. This forces you to update it very frequently. And also, WordPress includes its version by default in a meta–tag, which makes it even easier for some assholes bad guys/​girls, to hack your site.
  4. Bloat: Using WordPress always feels like using bloatware. In a recent release, it startet to include some JavaScript-Code on every page for Emoji-support. While this may be nice for some blogging-contexts, for most users this is certainly unnecessary. Also, almost every plugin you install loads another JavaScript and CSS file on every page. You can tweak those things here and there, but it does not feel right to include a lot of code into your functions.php3 to turn off features, instead of enabling them.
  5. Performance: Well, this results in the most awful thing about WordPress: its poor performance (especially when keeping in mind that is used by a lot of hobbyists who are on cheap hosting plans). Sure, there are a lot of caching plugins, whose settings pages often contain dozens of optionas and seem to be overly complicated. I know WordPress very good and I still don’t get how exactly most of those plugins work — if they work at all. For every page request, WordPress initializes a lot of stuff I never use, from widgets to comments. On shared hosting, the server’s response time often exceeds 500 ms.

Final thoughts on WordPress

While the preceding lines may sound like a rant, I don’t hate WordPress. When I was studying Design, I gave tutorials to other students and taught them how they can make their own portfolio with WordPress using custom themes. And while none of them had ponderable experience in programming, most of them were able to achieve good results in comparably short time.

I think, the problems listed and described above are resulting from the fact, that WordPress ist just made for a different group of users. Although, Automattic (the company behind WordPress) makes money with their hosted platform WordPress​.com. Obviously, the software follows their business needs, which may differ from my needs and my philosophy as a web designer/​developer doing client work.

Hello Kirby

Because of the reasons listed above, I had been searching for an alter­native to WordPress for some time already, when I finally stumbled upon Kirby. The philosophy behind the CMS could be described like the complete opposite of WordPress in many aspects. When setting up a project with it, one does realize very quickly: Kirby is not for everyone. To work effec­tively with the software, you need at least some basic programming skills in HTML, CSS, PHP and probably in JavaScript. While WordPress tries to provide as much as possible without touching any code, Kirby acts more like a boilerplate or framework, intended as a solid foundation for your website. There is no real default theme, just a simple demo site, which serves as a starting point.

Never­theless does it provide a nice and clean API, which looks similar to jQuery. Whenever you’re working on a typical website for a small company, this allows you to stay focussed on your design and your frontend code. Synchro­nizing with a staging server is also quite easy, because there is no database you need to take care of. Everything is just stored in a folder structure. In my daily routine, this became very handy, because editing can be much faster sometimes, if you open content files directly from the Finder (or, if you’re a command line hero, you can use nano or vim). For sure, there is also an admin panel, you can use!

Custom Fields for Custom Websites

Except for a page title, there is no mandatory field for any page in kirby. The fields for every template are described in so-called blueprints. That means, you can, for example define title, text, thumbnail for a portfolio page or title, text, publishing date and excerpt for a blog post. This allows great flexi­bility, although it is not so advanced like WordPress in conjunction with ACF. But in most cases, it will suit all your needs. There are also fields for repeating content, if you want to implement a slideshow or something else more advanced. My approach changed from striving for a layout builder to fit every use-case to customized templates for particular content pages.

When it comes to content-editing, Kirby is not too opinionated and allows you to choose between a bunch of different options. I bet most Kirby users prefer Kirbytext, an extension of Markdown with additional and completely custo­mizable tags, so-called Kirbytags. IMHO, the best writing experience is achieved when installing the Visual Markdown Editor plugin, which provides a decent interface for editing. But If you prefer, there is also a WYSIWYG editor available.

Exten­si­bility & Confi­gu­ration

Kirby supports multi-language websites out of the box, so there is no need for an additional plugin for this case. The included field types reach from a simple text inputs to select boxes, date-pickers and many more. There are also a lot of additional third-party fields available. All in all, there are far less plugins available, than for WordPress. As the current version (2.2) does not support custom admin pages yet, confi­gu­ration happens mostly within a confi­gu­ration file. Another handy feature at this point: You can have a global confi­gu­ration file and specialized ones for your test server and your production server, which are automa­tically loaded depending on your site’s domain name.

Performance & Caching

One of the most stunning »features« of Kirby is it’s amazing performance. A simple page only needs a couple of milli­seconds, a more complex page like this one is still delivered in under 200 ms on my local machine. If you turn on page cache, it becomes even faster, almost like serving static HTML pages. Within the last years, performance has been a big topic within the web designer/​developer community. How much can the »best« website be worth, if a slow CMS lets your users have to wait several seconds for a page to load?

Conclusion

I am a big fan of using tools, that empower people who publish content on their own webspace to keep make the web as decen­tralized as possible. If you visit the website of Kirby’s creator Bastian Allgeier and read his thoughts, you notice that he has a similar attitude towards the evolution of the WWW, as I have. While a self-hosted WordPress site fulfills the same demands, I prefer the structure of Kirby which doesn’t lock you in. Everything is stored trans­pa­rently, so you are able to move your content to another platform without too much hassle.

Writing frontend code for responsive websites is already complicated enough, so if you’re a typical web designer — with some decent knowledge about how to code — a CMS like Kirby allows you to stay focussed on the things that really matter to you (…and which are probably design and frontend code). The documen­tation is still in development and could be more complete, but as far as I know, the team behind Kirby is constantly working on this. I am very excited about the developments we are going to witness within the next months and years and which direction Kirby will go. For every upcoming project, where I think Kirby is suitable for, I’m going to suggest it to the client as Kirby is now my CMS of choice.

Last, but not least: Creating and editing websites with Kirby made web design and especially development an enjoyable task for me again. It always feels like I am in control of what I am creating. when you look at Kirby’s showcase, you see a lot of great websites. Most of them feel like developers and designers enjoyed the process of creating them as I did with this site.


  1. I serve retina-optimized versions of all images with a higher compression, than the "regular" version. On high-density screens, pixels are so small, artifacts are harder so recognize, so JPEGs can be saved at lower quality to save lots of kilobytes, resulting in faster websites — especially on mobile.
    Further reading:
    Daan Jobsis (2012): Retina revolution, Scott Jehl (2012): Compressive Images, Hugh Spiller (2012): Can bigger images be smaller? 

  2. WordPress uses gettext for trans­lation. That means, that the original language strings are included directly into the code. I compared the performance by changing the interface language: When set to German, page generation became much slower, while gettext took about 30% of total script execution time. 

  3. In every WordPress theme, there is a file called functions.php. This file usually contains a mix of theme-specific confi­gu­ration instructions combined with additional theme-specific template functions. 

]]>
Neue Visitenkarten https://fabianmichael.de/blog/neue-visitenkarten blog/neue-visitenkarten r

Seit dem Wochenende habe ich endlich neue Visiten­karten. Danke an Studio Akkord für den Druck!

Druck­details

Vorderseite Rückseite
Gmund Cotton New Grey, 300 g Gmund Colors 63 Matt, 100 g
Letterpress, 1-farbig Siebdruck, 1-farbig
]]>
Lesbare CSS-Klassen durch Trennzeichen https://fabianmichael.de/blog/lesbare-css-klassen blog/lesbare-css-klassen r Bei der Arbeit an Websites gibt es mehrere Möglich­keiten, den CSS-Code zu struk­tu­rieren. Während ein Ansatz darin besteht, möglichst nur eine Klasse pro Element zu verwenden und alles Weitere im Stylesheet zuzuordnen, besteht ein oft gebräuch­licher Ansatz darin, mehrere generische Klassen pro Element zu verwenden. In diesem Artikel geht es darum, wie der Ansatz mehrerer Klassen möglichst übersichtlich verwendet werden kann.

Warum mehrere Klassen pro Element?

Ein typisches Beispiel für eine Klasse pro Element in BEM-Namens­kon­vention:

<article class="article">
  <div class="article__content"></div>
</article>

Für einzelne Widgets mag das vollkommen ausreichen, sobald aber Frameworks wie Twitter Bootstrap zum Einsatz kommen, kann es oft komfor­tabler sein, deren Helfer­klassen zu verwenden, z.B. für das Raster­system. Ich persönlich finde den Code so übersicht­licher, als wenn alles nur im Stylesheet geregelt würde. Darüber hinaus lassen sich somit Wieder­ho­lungen im CSS-Code vermeiden. Mit dem Einsatz von Helfer­klassen werden class–Attribute aber schnell sehr lang und Klassen verschiedener Aufga­ben­be­reiche vermischen sich:

<article class="article row">
  <div class="article__content col col-md-6 col-xl-6"></div>
</article>

Ich brauche oft auch eine Klasse für HTML-Code, welcher von einem CMS wie WordPress oder Kirby über über einen WYSIWYG-Editor oder aus Markdown generiert wurde. Dieser ist meist sehr generisch und hat kaum Klassen. Von daher lässt es sich am meist am besten durch eine Klasse auf dem Container-Element und Kinds­e­lektoren stylen. Inzwischen nenne ich diese Container-Klasse meistens richtext. Ein Beispiel:

.richtext p  { margin-bottom: 1.5rem; }
.richtext h2 { font-size: 1.25em; […] }

Auf dieser Website kommt noch die Klasse hyphenate für Absätze hinzu, auf dessen Inhalt per JavaScript Silben­trennung angewendet werden soll. Die Klassenliste wird schnell sehr lang und unüber­sichtlich:

article__content richtext hyphenate col col-md-6 col-xl-6

Klassen mit Trenn­zeichen struk­tu­rieren

Abhilfe schaffen Trenn­zeichen zwischen den Klassennamen im HTML-Attribut. Klassen stellen laut Spezi­fi­kation eine durch Leerzeichen getrennte Liste dar. Die Integration zusätz­licher Zeichen stellt also für keinem Browser ein Problem dar, wie Harry Roberts in Grouping related classes in your markup zusam­menfasst. Ich habe mir folgendes Schema angewöhnt:

                    +--- Utility ----+
                    |                |
article__content  / hyphenate richtext [ col col-md-8 col-xl-6 ]
|              |                       |                       |
+- BEM / Name -+                       +-------- Grid ---------+
  • BEM / Name: Name des Elements, so wie eventuelle Modifier. Beispiele: article__content, article__content--feature etc.
  • Utility: Allgemeine Helfer­klassen, die durch das Framework vorgegeben werden. Beispiele: richtext (für Inhalte aus einem WYSIWYG- oder Markdown-Editor), text--small, no-select etc.
  • Grid: Layout­spe­zi­fische Klassen des Raster­systems.

Das folgende Beispiel zeigt, dass durch den Einsatz von Trenn­zeichen auch lange Klassen­listen sehr übersichtlich sein können:

<article class="page page--about [ container ]">
  <div class="article__body [ row ]">
    <div class="article__content / richtext hyphenate [ col col-md-8 col-xl-6 ]">
     [...]
   </div>
  </div>
  [...]
</article>

Fazit

Ich habe den oben beschriebenen Ansatz konsequent bei der Umsetzung dieser Website angewendet und bin sehr zufrieden mit der gestei­gerten Lesbarkeit meines Codes. Nachteile gibt es aus meiner Sicht keine bedeu­tenden, solange zwischen Trenn­zeichen und den eigent­lichen Klassennamen immer mindestens ein Leerzeichen ist. Sollte der Code mit Anderen zusammen bearbeitet werden, sollte aber zumindest vorher im Team darüber geredet werden, weil diese Syntax für die meisten Entwickler*innen (noch) sehr ungewöhnlich aussehen dürfte.



Dieser Artikel ist lizenziert unter einer Creative Commons Namens­nennung – Weitergabe unter gleichen Bedin­gungen 4.0 Inter­na­tional Lizenz.

]]>
There is no Final Version https://fabianmichael.de/blog/there-is-no-final-version blog/there-is-no-final-version r Grund dafür war auch, dass ich in letzter Zeit einigen Freund*innen bei der Umsetzung ihrer Portfolios geholfen und somit viele neue Ideen und Anregungen erhalten habe. Außerdem wollte ich gerne wieder einen Blog als eigene Plattform zur Veröf­fent­lichung meiner Gedanken zu haben. Dabei habe ich auch einige Artikel aus meinem alten Blog übernommen.

Nachdem ich schon lange Zeit mit WordPress gearbeitet hatte, entschied ich mich bei meiner Website zum ersten Mal für Kirby als CMS. Erste Erfah­rungen sprechen für das System, auch die Markdown–Syntax gefällt mir sehr gut. Im Gegensatz zu WordPress verhält sich Kirby jedoch mehr wie ein Framework, das zwar nahezu ohne ungewollte Funktionen und Neben­effekte daherkommt, dafür aber auch verlangt, dass Mensch fast jedes Feature selbst in die Hand nimmt, was – je nach Art und Komplexität einer Website – am Ende mehr Arbeit bedeuten kann. In meinem Fall ist das Ergebnis jedoch lohnenswert; meine neue Website läuft deutlich schneller, als die alte unter WordPress und die Erstellung der Inhalte macht auch mehr Spaß. Hinzu kommt, dass sich der Großteil des Codes als Basis für zukünftige Projekte verwenden lässt.

]]>