The road to SoaPatrickTen (Part 3)

Welcome to the last part of this short series of my undertaking from WordPress to Kirby. First I focused on the migration process because that was the first thing I had to do, I had to have my content within this new CMS. Then I looked at how I had to structure this content and now I will finally talk about how I wanted this content to be presented.

Design

Anyone who follows this website knows that every new design so far was just a small iteration from the previous one. There was hardly ever a complete design overhaul because with so much content it’s hard to find a design that fits everything so I just took it step-by-step.

With my switch from WordPress to Kirby, there was first an idea to go in a completely new direction. In my first step, I recreated SoaPatrickNine with Kirby as close as possible (this was done to find out if Kirby is a good fit as my new CMS). Once the decision was done to fully commit myself to Kirby as my new CMS I was kinda exhausted and for a moment I even thought to just switch CMS and not add a redesign on top of it. But then I started to play around with some ideas in my head and from then on it was clear that there will be a new design iteration after all.

Usually in the past what I did was maybe do some rough design sketches on paper and then try some stuff out in Photoshop before I move over to the design-by-coding process where I just create the look of the website directly with HTML and CSS inside my code editor. But this time I thought I try something new. I mean I pay for the whole Adobe Creative Cloud Suite and Adobe has UX/UI design tool: Adobe XD.

So I started to put down my ideas from my head down in Adobe XD and it was a nice pace of change to move around elements quickly to try out something, or just copy something and try something else to see if this might work as well. By coding, you cannot compare different design ideas that easily so I think I saved a lot of time by finally using the proper tools.

SoaPatrickTen Color Scheme

New Color Scheme for SoaPatrickTen

But with all my design ideas I realized that I'm limited if I continue to use a simple color scheme with just a primary color and then a very dark grey and white and no additional accent color. Thanks to Adobe Color (previously known as Adobe Kuler) it has become easy to play around and discover new color schemes but in the end, it was google who helped me discover the color scheme you can see right now. With additional colors, it was easy to find some new variations in links, accents, background, and highlights. And by just inverting and adding different light versions it was also possible to add a proper dark/light mode to SoaPatrick.

Besides the color scheme, I also wanted to change the layout of the whole website. Since SoaPatrickSeven I moved the content from the center to the left side where it stayed from SP7 to SP9 and while I loved this unusual layout in these times what annoyed me was the way larger images were displayed.

empty alt text

SoaPatrickNine Layout

So I moved everything back to the center and made larger content blocks extend to the left instead of the right and move the navigation to the bottom right. That way I at least had an unusual element. Because of how I structured the website and because I knew I had to reduce the number of navigation items because of the mobile view I had to add a submenu and the obvious choice was on the right side but on top.

empty alt text

SoaPatrickTen Layout

This way the whole layout didn't feel it would fall over the right side because it looked a lot more stable and in harmony. Plus I loved the way larger images could extend to the left side with the caption positioned left to the regular content. I already did this once with SoaPatrickThree, it was a nice throwback for me.

Side Note:

I noticed during my migration process that I often mention design changes in my posts but don't share any visuals and then years later those mentions are kinda worthless, so I try to add a lot more visual elements to showcase what I mean.

When I had a single blog post it was easy to adapt this layout to other page elements as well and I knew I would keep certain things the way they are right now but whenever I could I would use the left side as a counterbalance to the main and sub-navigation. Just like the tag list on the factory and lab overview page. But why exactly is the Lab not part of the main navigation but instead only reachable by going to the factory first?

Well, I think it makes sense from a factory point of view. I always pictured the lab as a part of the factory, like a special division within the factory that produces weird stuff, and maybe once in a while, some of those weird things get produced in the factory. Yes, it makes sense but the main reason, the reason I mentioned earlier already is that the mobile navigation needed to change and I only could change that by reducing the number of main navigation items.

I removed the Privacy Page from the navigation and moved that to the footer (where it actually belongs) and moved the lab as a sub-navigation item to the factory. With that, I could move the mobile navigation from the left side (image on the left) to the bottom and the sub-navigation right on top of it (image on the right). That way everything could still be reachable with your thumb and also with just one click. There is no need to first click on a burger icon to expand the navigation, you just click whatever you want to see and because the Website has a perfect 100 score on the Google Lighthouse test, it loads the new page instantly. Plus, the content has more room because there is no navigation sidebar.

Side Note:

For a moment I had a very experimental mobile navigation with which you would drag an area at the bottom of the screen up and depending on how far you drag up, a different menu item is selected and once you release, you jump to that part of the website. It worked only partly but it was an interesting experience that was fun to implement.

So the design was done, I had a mobile and desktop view, I had a new color scheme and new layouts for different page views. Now I could implement the whole thing and as I mentioned in a previous post, I wanted to do everything with TailwindCSS.

Now Tailwind is awesome for quickly putting together a design without having to write HTML and CSS because you pretty much style your website by writing HTML and just adding CSS classes. This is fine as long as you don't need to write the same styling for the same component on various different templates. Changing the styling later down the road because you might have made a mistake can be tedious to go through all those files again and copy-paste the changes. This is definitely not a DRY implementation. Of course, this is different when you're using React.js and have a strict 'everything is a component' approach. But It's not that easy with PHP and Kirby or I haven't found the perfect way yet.

The general idea of Tailwind is actually very DRY because let's take this for example

css
.class1 {
  display: block;
}

.class2 {
  display: block;
}

So whenever a class needs the display: block; styling you repeat that over and over again and you quickly find yourself with hundreds of display: block; definitions in your CSS file. With Tailwind, there will only be one.

css
.block {
  display: block;
}

And then all you have to do is add this block class to any HTML that needs to be a block element. This is the basic approach of Tailwind, and the nice thing is that Tailwind, upon compiling your project, is purging the whole CSS file and leaves only the CSS rules you actually need for your project. This leads to a very small CSS file at the end. Now as I mentioned this is fine when your markup is DRY is as well.

Side Note:

Don’t repeat yourself [DRY] is a principle aimed at reducing repetition of software patterns, replacing it with abstractions or using data normalization to avoid redundancy. Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

Tailwind allows adding Tailwind classes to your CSS class names as well, but there is one drawback. If you have several self-written class names and you apply Tailwind classes, then upon compiling you still will end up with multiple CSS classes with the same CSS rules.

For future SP versions, I will definitely focus on improving this by going more modular and maybe writing PHP functions so that each element is actually written only once. But this is my first go with Kirby and there is still lots to learn.


Uff this was a long post and the last three combined posts made for a very comprehensive and detailed look into the process of moving from WordPress to Kirby and coming up with a design for SP10. But now it's time to leave all this behind and look forward, and maybe add smaller blog posts again because these long ones are a lot of work.

But I hope you enjoyed it and it gave me a chance to display some of the new block elements I created and what some basic ones look like. Now it's time to enjoy the rest of the weekend.