One of my personal long-term goals in the past couple of years has been having an app in the App Store. I'm not 100% sure why the idea of having my own app in the App Store appeals to me so much. Maybe it has something to do with touching and interacting with a native app on an iPhone, iPad or Apple Watch that feels more magical to me. Weirdly, it's a feeling that web-based applications (which I'm equipped to build) never gave me.

In the past, I tried to archive this goal multiple times. I tried to get familiar with Objective-C, back in the days when Swift wasn't a thing. After the introduction of Swift I was hyped but couldn't get over that hump of releasing an app. I always got stuck in an intermediate state.

After the introduction of SwiftUI last year, things changed. At the beginning of 2020, I familiarised myself more and more with Swift and SwiftUI.

This phase started as it always did. I was full of energy and couldn't think of anything else for weeks. The difference now was, that this phase never has ended and I'm still working on an app until now.

Work In Progress

The app I'm working on isn't fancy or original in any way. It's the kind of application I always wanted, but in a way that wasn't already on the App Store. What I'm talking about is a simple way of tracking progress while watching your favourite TV shows. In other words, I'm building a TV show tracking app.

The idea of this app, which is called CouchTimes, goes back years. To be honest, most of the time, when I gave iOS development a try, I started with CouchTimes as my first project. This iteration of CouchTimes is probably the fifth attempt of getting something out the door.

Scope and technology

While I have concrete ideas what I want CouchTimes to become, I also know that time is a limited resource. Focus is key and I don't want to get drawn away from my main goal, which is getting something in the App Store.

Therefore, I want to keep the scope for the first version as simple as possible. CouchTimes will focus on the essentials. To give you a basic idea what I'm talking about, here are some examples:

• Customers have a screen called Watchlist where all shows they are watching are listed
• Customers can search for shows they want to add to their Watchlist. Search will also offer some suggestions of popular shows or similar.
• Shows have a „Detail Screen“ with various information as well as seasons and episodes which can be marked as seen.
• And much more...

Building a TV show tracking app has some angles to it. First, I need a source of all the data customers want to access and interact with. One of the most prominent services in this space is Trakt.tv and CouchTimes is going to run on the data Trakt.tv provides.

SwiftUI is fun

Besides the data source, CouchTimes is running on SwiftUI. While SwiftUI is still very new and limited in some ways, it feels very magical. It offers ways to make CouchTimes more easily available on other platforms in the future. Looking at you, Apple Watch, iPad and Mac!

While iOS development sometimes makes me struggle, I enjoyed the past month working on CouchTimes and I learned so much. I fought with my networking layer multiple times (I rewrote it three times). I learned more about Combine and I'm more and more amazed about SwiftUI itself. Especially when we look at what happened during this year's WWDC. So many nice improvements and no earth-shattering changed from the first version to the second version like we experienced in the early days of Swift.

Next Steps

All in all, iOS development excites me very much. I love the new technologies Apple gave us in the past years and it will make development generally more approachable. My goals with CouchTimes is to finish the first version by the end of this year. I want to continue writing about it here or talking about it on one of my podcasts called Sprachnachrichten.fm (German).

If you want to learn a bit more about SwiftUI, I can recommend the WWDC sessions from this year. Besides that, here are some further resources:

• HackingWithSwift
• Swift with Majid
• Jordan Singer
• Thomas Ricouard
• Objc - SwiftUI
• Thinking in SwiftUI

Yesterday, a colleague of mine, asked me a question on Twitter about my typeface choices. To get everyone on the same page, here is his question:

I noticed you did serifs for headings and sans-serif for body text. My intuition is the other way around and I'll do that for my blog. Curious if there is some deeper reason?

I loved this question so much, that I decided to write something about it. So why did I do it this way?

The answer is a bit unusual for the type of design decisions I commonly do. To be honest, it's mostly based on personal taste and a more characteristic feeling I wanted to have for this website.

Picking the specific typefaces

When I started looking into styles I wanted to convey on this redesign, I looked at a lot of different typefaces. At some point, I saw Value Serif, which was created by Colophon, and it immediately clicked for me.

The characteristic appearance, combined with a rich set of OpenType features (e.g. the lowercase f or e are just beautiful) made me want to go with this typeface.

Based on the love for these little details of Value Serif, I needed to make them appear noticeable across the whole website. This was the reason for picking it as a heading font and making the heading design big and bold.

Because the headings are very characteristic, I wanted to do something more visually simple for the body text. That was the reason, why I finally bought and used Aperçu. Aperçu also has some grotesque flavours and characteristics in a way, but it feels simple and flexible enough for the use cases I had in mind.

But what's about readability?

In terms of readability, there is an ongoing debate about serif and sans-serif. Culturally, we know that serif typefaces are more common for long texts in areas like books or newspapers. The perception is that this benefits legibility.

There are studies and arguments for all different angels on this. I think in the end it comes down to setting the typefaces correctly and not the specific typefaces themselves.

With screens the argument, at least in the past, becomes a bit different. These arguments are mostly based on screen resolutions and the way typefaces are rendered on screens. In this area sans-serif was the preferred way to go. With better technology and screens in general, this will become less of a priority.

All in all, it's complicated and it probably boils down to the environment the typefaces live in. I can also see a future, where I change my current thinking. Maybe I move Aperçu more in the background for small details like captions and add a less stylistic body typeface sometime in the future.

I'm happy to share a little project I've worked on for the past weeks. It's called Photon 11ty and before we get into the details, here are the hard facts:

• It's a simple way of sharing & presenting photos on the web
• It's based on 11ty
• It's open source
• It's focused on being fast and easy to use
• It's not finished in any way, this is only the first version

Where it all started

To be honest, I didn't want to start this project at first. I didn't want to invest time in it, because I thought I already had what I wanted.

At the beginning of this year, I build my own little version of Instagram. It enabled me to share the photos I wanted to share with the world. Everything was happening on my website with my own domain - I was happy!

After building this little version for myself, a good friend of mine, Arne, was constantly bugging me about the fact that he wanted to do something similar, but decoupling my /photos section from the repository of my personal site would be painful. Sure, the code of this website is available on GitHub, but it would've been a bad experience for everybody who wanted to do the same. He was repeating himself for weeks.

Then there was another, similar project, called Photo Stream by Tim van Damme which was the final motivation for me to look into ways of decoupling my own /photos page from my personal site. Generally, alternatives are great and maybe separating the /photos section from my personal site was a good idea after all.

At some point, I started to sketch some ideas with my girlfriend. These ideas vastly extend the scope of the current version of Photon 11ty but they were enough to push me over the edge.

Where it is at

I started with some design in Figma. It was all about building a grid of photos and deciding what makes the cut and gets into a very simple MVP.

After some initial direction, I quickly boiled the visual design down to a bare minimum and tried to follow the basic idea of showing squares as an overview and going full-screen for every single view.

From that point going forward I started moving things into code. I quickly build my foundation with 11ty and focused to build the simple design in a basic and responsive manner.

Now I'm at a point were it makes sense to make this project public. Currently, the following features are available in this first version of Photon 11ty:

• Pre-optimized image resolutions: During build time, Gulp runs a task with gulp-responsive to generate a lot of different thumbnails based on the original uploaded images.
• Improved lazy loading of images: Photon uses the native browser loading="lazy" functionality.
• Every photo has its own URL: Everything is static. Every photo has its own HTML page. No JavaScript magic.
• Basic open graph support: Support for previews on other social media platforms and messaging apps.
• Support for light and dark themes: The designs adapt to the appearance (light or dark mode) of your operating system.
• Keyboard shortcuts: Users can navigate photos with ESC (close a photo) as well as the left/right arrow keys.
• RSS feed: Every photon site has RSS support.
• Option for adding other social media references: If you want to link to other social media accounts, you can configure this inside the config. Social media links will appear inside the page header.
• Support for Netlify deploy button: One-click deploy to Netlify

How can you use it

If you have a little bit of Git knowledge, you're the right person to give Photon 11ty a try. You can either use the Netlify deploy button (which is the fastest way of getting something up and running) or use anything that supports static-file hosting.

If you want to build a new version of your site, please use the yarn build command. A freshly generated version of your site will be created inside the _site directory.

When it comes to creating new posts, Photon has two simple rules:

• You need to put all images inside the /uploads directory.
• To show these images on your website, you need to create a markdown file inside the /posts directory. This markdown file handles everything from referencing the image you want to show as well as handling additional metadata for this specific post.

You can find more details regarding these steps as well as documentation about the functionality behind some content blocks inside the README.

Where it is heading

To be honest, I don't know for sure. I'm pretty happy about the current state but I'm also really interested in other options and open to suggestions.

I have some ideas floating around in my head, but I haven't decided yet if these ideas are right for this project. I was thinking about basic offline support or support for Webmention. These are all ideas I'm not sure about, but I know that I want to leverage the awesome web environment and see how new APIs and technologies can push this little project forward.

Besides that, I want to make smaller improvements regarding performance and maybe automate some more things.

Anything else

As I said earlier, I'm happy with the outcome so far. I'm totally aware that this solution is primarily focused on people with a bit of technical knowledge.

I think this is okay for the start, but there should also be something that everybody can use. Something that is build with the privacy, data ownership and the foundation of the web in mind.

I'm not talking about another open-source alternative to Instagram or another social network. I'm talking about an easy way of sharing visual creations, like photos. Maybe with some small social aspects, but without the constant run for likes, algorithms and other things that increase the pressure on humans and ultimately don't make us happy.

Maybe someday this will be available. For now, I hope Photon 11ty can also help in small ways.

P.S. I removed the /photos section from this website and moved everything over to photos.fruechtl.me running Photon 11ty.

During my searches through the 11ty documentation, I stumbled upon the official syntax highlighting plugin offered by 11ty. The beauty of this plugin is that it does everything during build-time. This means that there is no need for any client-side JavaScript. 🙌

As an example of how this new syntax highlighting looks for now, here you can see a case with the configuration for the syntax highlighting plugin itself:

const syntaxHighlight = require("@11ty/eleventy-plugin-syntaxhighlight");

module.exports = function (eleventyConfig) {
    eleventyConfig.addPlugin(syntaxHighlight);
};

After a short travel break, I wanted to continue with the process of building this new site. Usually, after a pause, it is always hard to come back. To make this process a little easier for me, I thought it would be a good idea to look for some typefaces I want to use for the site.

During the past years, I collected a library of links with beautiful typefaces I want to use on future projects. Besides that, I also went thought the recent posts on Typewolf to get some more inspiration.

My initial goal was to use variable fonts in this project. I heard a lot of positive things about this upcoming way of serving and using fonts on the web (if you want to see more about this topic, I recommend the talk Dynamic Typography with Variable Fonts from Jason Pamental). I looked through some references and searched on this awesome website called v-fonts, but I wasn't satisfied with anything. Don't get me wrong, there are beautiful typefaces out there that support the variable font format, but nothing felt right at home for me.

After some more research, I got back to Colophon, a London based type foundry. This foundry offers excellent typefaces, and for a long time, I was admiring their Aperçu typeface. With that in mind, I looked through their catalog again and found a typeface called Value Serif - this was the moment where it clicked for me.

I decided to buy Aperçu and Value Serif to power this new site I'm currently building. I love the vibe and beauty they bring to the site. The details offered by the Open Type features are incredible.

Despite the fact that these typefaces don't support the variable font format, I'm quite happy with my choice. Requirements change, especially for personal projects.

Last week I attended BeyondTellerand Berlin, which was, as always, a fantastic conference. This year, the opening talk was given by Jeremy Keith, who talked about The Layers Of The Web. This fantastic talk, which you should watch, got me thinking about my tech choice for this new personal site.

Is it essential to use such a massive tool like Gridsome to power this site and future playground? I love Vue, and it can be a fantastic tool for building web-based applications, but do I really need this kind of power, and do I want to make the people suffer who are visiting the website because of unnecessary bloat they need to download to get the Gridsome experience?

I don't think so. I want to have a lightweight, fast, and very dull foundation for this website. Because of that, I removed everything from the Gridsome side and replaced it with some 11ty love. Everything is entirely static and crazy fast now. Look at these two screenshots I took to compare Gridsome and 11ty from the Firefox Network Tab. 🔥 🚀

With a flexible data model, provided by Contentful, I’ve added a new date input to my blogpost model. At first, I tried to get something like an internal or predefined publishDate provided by Contentful. It turned out to be harder than I expected at first.

With a new date input in place, I was able to render a machine-optimized version of a date to my page. The next step was adding a proper <time> tag to every post. With a <time> tag and the corresponding date-time attribute, I have new opportunities. I now can render both a human-readable and a machine optimized version of a date to every post.

After that, I rendered the machine-optimized date from Contentful inside the datetime attribute. For the human-readable side of things, I’ve added moment.js to my project.

With the power of moment.js, I've added a moment(DATEFROMCONTENTFUL).format("dddd, MMMM Do YYYY") function call. With that in place, I can now also render an optimized date formatting for humans. The result of this specific formatting is now present in every post.

One thing I always struggled with, when it comes to static site generators, was the lack of visual editing experience. Up until now, I didn't come to terms with only writing and publishing in Markdown files.

This conclusion may seem weird because I love Markdown itself, and I usually choose this way of writing over any other option. The only part of this experience I hate is making all my final editing choices in VSCode, IA Writer, or what have you. It always felt hacky and not right to me for some reason.

Thankfully, in a world full of options, other solutions can bridge this gap for me. One option is a Headless CMS, and to my surprise, there are so many different kinds of Headless CMS solutions out there. 🤯

For the past couple of days, I've looked briefly at the following Headless CMS solutions:

• Contentful
• Strapi
• Storyblok
• Sanity
• Prismic

All of these seem quite functional and have their pros/cons. For the time being, I decided to go with Contentful. It is an established system in this area of content management, and the free plan seems manageable for me.

With this post, I successfully connected Contentful with my Gridsome instance. Next up: Dates and a proper RSS feed.

A week ago, I saw this tweet by Jonnie Hallman, which inspired me to revamp my personal website again. As Jonnie wrote in his initial post, he wants to capture his progress on this new personal website as he goes building it. I loved this idea and want to try the same thing, but maybe a bit different, we will see.

From where I see it now, my new website should be more focused on me, a bit more personal stuff, and a bit less "professional/portfolio" style. It should be more tailored towards me as a person and what I want to experiment with in the future.

For the first steps, I'm giving Gridsome a try. Gridsome is not my final decision in terms of technology yet, but I want to see if it can help me with the goals currently occupying my head.

And maybe, as a positive side effect, this way of capturing my progress will finally break my struggles of keeping a blog up-to-date.