1. My focus is Design, HTML, and CSS.

2. Sometimes I write JavaScript, but my skills are more suited to Design, HTML, and CSS.

3. I like core technologies. Being close to the metal suits me (HTML, CSS, JS). I don’t particularly enjoy working with frameworks, especially in recent years, where core technology has matured. If someone asks me to take on a Vue project or use Tailwind, it's not for me.

4. Focus on the basics. What makes a site look great? Brilliant typography, sublime photography, and art direction.

5. Focus on one CMS. As I write this, I've journeyed through three content management systems: WordPress to Perch to Statamic.
   I haven't touched Perch for a couple of years now. Consequently, I can't even remember how to install it. Content management systems are deep and complex, and riding more than one horse is a path to mediocracy.

6. Stay away from gimmicks. Related to (4), in my experience, clients tend to focus on things that either ruin the basic experience of the web or add very little value to their site other than annoying users. Let's take scrolling, as an example. Clients and agencies fixate on this. Maybe because they think they need to stand out in some way? Parallax scrolling, full-page scrolling, scroll-snapping, infinite scrolling, crazy animation, etc. All of this is complex, terrible, and simply breaks too many things—hashtag anchors, page positions, or being able to flick through a page quickly to find something. Take cars—no one's ever thought, “wheels are boring, let's make them square”—because wheels fundamentally provide the best experience. Similarly, on the web, native and basic is the best fundamental experience.

7. I should try and control my part of the project. Before taking on a job, I should ask myself, “how much control will I get over the look and feel of the website?” I'm much happier—and it's a better website—when the client trusts me.

8. Always think about my focus. How much does the project stray out of my core area of focus? If it does stray, can I stick to my focus? For example, I don’t want to get involved in any e-commerce projects myself, but if I do, I only want to take on a design and CSS role for those projects. Don't blur the lines.

9. Stay away from “unbillable bollocks”. Related to the previous point, sometimes I lose half a day to figuring something out—typically outside my core focus area. This stuff is so obscure that it's almost impossible to bill it to clients. Ergo: code is complicated, and the only way to make a fruitful and stress-free living is to focus on things I can solve with high confidence.

Articles that align with my Principles

• No, Absolutely Not

• Great Designers Realign

• A Dao Of Web Design

• The Art of Not Thinking

• It's Easier to Revise than Create

• Declarative Design

• More Transparent UI Code

• Can CSS be too modular?

• Are You Single?

• HTML Semantics

• CSS Guidelines

• Introversion

• Creativity Petting

Quotes that align with my Principles

The Real Shortcut is to do it right the first time. Anything else is a welcome invitation to start again or clean up some cut corner. – Geoff Graham

2022 is the first year in memory that not only a single major technology ships, but a whole host of powerful technology. The result feels significant.

You see—the web typically moves slower than the 'app' world. But over the last few years, browser vendors—like Chrome, Safari, and Firefox—have been shipping behind experimental 'flags' that have enabled a more modular and faster approach to pushing out new tech.

What does this mean? These new technologies mean more expressive websites, from “scroll-linked” animation to eloquent magazine-like grids and sub-grid layouts.

This new tech is not only exciting for web developers but also for clients and, well… everyone who uses the web. For the rest of the article, I will be running through upcoming technology releases and translating what they mean into plain English.

Hat tips to Bramus Van Damme and Nicole Sullivan (both on the Google Chrome Developer Relations team).

A 26% More Colourful Web

If you're of a certain age and have ever dealt with a web developer, you might remember years ago web developers needed to design in “web-safe” colours.

At that time most consumer computer monitors could only display 256 colours, so if you designed in a broader range, most users wouldn't see the full spectrum of colours.

Colour Functions are kind of the same thing, except this time it's internet browsers holding things back, not monitors.

At the time of writing, most browsers can only access the "sRGB" (standard Red, Green, Blue) colour space, which is limited to a certain amount of colours.

There's a newer standard, known as the P3 (Protocol 3) colour space, where modern monitors and laptops can access a much richer range of colours.

If you can see all four spectrums (display-p3, lch, and lab), it means you have a P3-capable browser. If you can also notice a difference between the colours, it means you have a modern screen capable of displaying colours in this expanded spectrum.

Once all browsers support P3, web designs will gradually start looking a lot more vibrant and attractive as web developers start implementing P3 colours in designs.

I'm already looking forward to making my neon-infused black/white/blue website look 26% hotter.

Page Transitions

What are page transitions? Imagine you're on a hotel-booking app, and you click a thumbnail image of a hotel. In the next moment, information will probably slide across from the right, or maybe the hotel thumbnail will enlarge to fill the screen in one smooth motion.

You've just experienced a “page transition”—moving from one state (or page) to another in a smooth transition.

Page transitions are one of the few things that separate websites and 'apps'—apps providing a significantly smoother experience in this case.

We go from one page to the next on the web in “pop” movements without any kind of soft landing.

Transitions, on the other hand, are not only smoother and more visually appealing, but they also show us where we're going. Think of all the animations on your smartphone; when you flick up from the bottom of a screen on an iPhone, iOS shows you what happened in one smooth movement.

For web developers, native page transitions could bring us one step closer to confidently saying to clients, “you probably don't need an app”.

For what it's worth, an older colleague (sorry, Dean) pointed out that we were here decades ago with Internet Explorer 5.5. That obviously didn't last, but I hope this time is different now that we have better browser standards and collaboration between browser vendors.

Scroll-linked Animations

Just about every client meeting I've had in the last few years can't end until a client smiles knowingly and asks for "parallax" effects.

However, implementing anything scroll-related has always been a bit hamfisted. You'll need to use some sort of script plugin to continually track where the user is on a page. The browser always struggles a little with this kind of stuff. Until now! (or the near-future, at least).

On the horizon is a “native” implementation of scroll-linked animation. “Native” means that the browser has it baked in so that you don't need to load a plugin.

Don't be fooled—this is not just developer convenience. Anything “Native” (baked into the browser) means performance will be significantly better and programming significantly simpler, leading to a much smoother and delightful implementation.

Systems and Components / not Pages

If you don't know what I'm talking about, Responsive Web Design was both a mental and technology shift to designing websites that worked on all sorts of different sized devices.

In the simpler days of web development, you'd just design a fixed-width page. With the advent of Responsive Web Design, we could suddenly query the device width. Developers started designing flexible layouts that could adjust to mobile phones, tablets, and various screen sizes.

Intrinsic Web Design

The web will always be an inherently flexible medium. Your website can be literally accessed by thousands of different device types with wildly different capabilities. Someone could access your site on anything from a computer at CERN, to a 2008 Blackberry, to a high-specced 2022 MacBook Pro. Layout and design need to be flexible and adjusted accordingly.

So what follows Responsive Web Design? 4 years ago, Jen Simmons gave a talk called Everything You Know About Web Design Just Changed. This was around the time web developers got access to modern layout models—namely CSS Grid and CSS Flexbox—two incredibly powerful layout technologies that enabled all sorts of wonderful Graphic Design-like layouts.

Fast-forward to 2022, and we're about to get something called Container Queries, which are the crowning jewel we've been waiting for in this era of new layout technology.

Container Queries allow web developers to query the surrounding space of the component. Querying contextual space was never previously possible. Instead, you had to query the area of the whole page. As container queries are released, we can design components that adjust based on context.

Jenn Simmons has suggested a new name to mark this paradigm shift: Intrinsic Design—which indicates that we're designing inherent systems rather than pages.

Web developers have been asking for this sort of expression for years to reflect the truly modular nature of designed components, allowing for more robust designs. Imagine brand guidelines for different components, where you can specify how things will look depending on the space available to them? The Responsive Logos project comes to mind.

Grids and Subgrids

Subgrid means developers can create a much more robust design ecosystem, allowing for more complex designs that stand up to the scrutiny of the ever-growing list of different screen sizes and devices.

Further Reading

I've tried to highlight the most visually understandable browser technology changes in this article, without making it too long. Still, the reality is there are far more technical things on the immediate horizon that only developers—including me!—are excited about.

I've listed more new technologies below to give readers an idea of how much is happening in the web browser space. 2022 is probably the best time there's ever been to be involved in web design and development.

For more technical reading including the below, I'd recommend Bramus Van Damme's blog post on CSS in 2022.

1. Colour Functions

2. Viewport Units

3. :has()

4. Overscroll Behaviour

5. Accent Color (for form elements)

6. Media Query Ranges

7. Nesting

8. Scoping

9. Mixins

10. Houdini

Cameron Moll's Good Designers Redesign, Great Designers Realign post has urged me to improve a design rather than throw it out. The more I practise this idea with my own sites, the more I'm convinced that re-alignment is not just the path to correcting things but also the path to self-improvement as a designer. This article is about taking the idea of design re-alignment and applying it internally. Reflecting on and improving my past work over the last couple of years has resulted in a deep satisfaction that's reinvigorated my approach to new work, and I wish you could feel this way too.

As a side note, I run a Discord group called Design Critique—please feel free to join and get free advice.

I Debug My Personal Sites

If you're looking to improve your design skills, I recommend starting with your own website. Designing for clients can undoubtedly help you improve, but it will never lead to significant development because you're restricted by the client's vision of what a website should be. I've lost count of how many times a client has referenced a boring site like BBC News as an “inspiration”. The truth is clients have no idea what's possible. Exploring without someone figuratively standing over your shoulder is both liberating and allows you to find your own style.

I became a better designer when I stopped hitting the reset button; I stopped redesigning my site. Instead, I started critiquing it; I dug into what was actually wrong with it. I threw my ego out and asked around, and when I saw Jack McDade offering 5-minute video critiques, I asked him to lay into my site too.

One of my favourite phrases ever is 'debugging design'. I first heard Laura Elizabeth mention it on Shop Talk Show Ep 317. Debugging design means trying to objectively understand why a design 'feels' good or bad.

I started looking at designs I liked—by my favourite designers—then I “debugged” them. I looked at individual components and tried to understand what made them effective objectively. I asked myself what made them effective on their own and then what made them more effective in the bigger picture.

The next bit was crucial—I decided that if I couldn't make any significant improvements to a component, I threw away that part of the design. “Part” is the significant word here. I became a better designer when I learned to throw things out. “In writing, you must kill all your darlings”, said William Faulkner. Well, the same applies to design.

You can see an earlier version of my own site from Jack's video critique. I'm not sure how well this post will age, but at the time of writing, you'll see some things from that video I've kept (colour scheme, intrigue section), some things I've since improved (typography, simplicity, scale), and other things I have thrown out completely (iconography, photo).

One of the reasons I love digital design so much is that you can revise it. Don't overthink things; instead, trust the process of experimenting, pausing, reflecting, and throwing away without consequence.

I Collect Things and Follow Weird People on Dribbble

Over the years, I've learnt to collect unexpected designs and things I like in a scrapbook. My scrapbook is simply a folder full of screenshots. Whenever I start a new project, I flip through these designs and find a design direction that might suit the new project.

At first, I worried this might result in copycat sites, but it never does in the end. Through rebuilding something similar with different goals in mind, there are inevitable deviations. Most often, large deviations. I'm going to be completely honest here and say that I absolutely loved the 10x18 site when it came out. I scrapbooked it in 2018 and found it again when I was redesigning the podcast site I co-host. I'm comfortable enough to share this inspiration because even though there are some similarities—the display typeface and graduated colours—I feel like the site I designed is significantly different. Everything's a remix, as Kirby Ferguson says.

The other thing I do is look through Dribbble. And let me quickly say the rubbish-ing of Dribbble annoys me. Things look good on Dribbble, and there is no shame in that. You should be aiming for things to look good.

People rubbish Dribbble because it tends to showcase pixel-perfect solutions—rather than problems and processes. Well, yes—this is what you'll see if you look through popular posts or conventional “inspiration”.

The fix? Follow weird people with different skills. If you're a web designer, don't follow people that make websites. I follow a craft beer maker and graphic designers that choose unusual typography, layout, and symbols, such as Bold Monkey or Bastien Allard.

Finding My Identity

As much as I admire particular designers, I realise it's essential to avoid becoming a carbon copy of them for my own self-validation. I've been trying to understand what sort of art direction produces the best results for me. What do I enjoy? What do I identify with?

Instead of seeing all these things as crutches, I am trying to embrace them as “my thing”.

Here's what I've written down…

1. I'm drawn to neon hues with high-contrast colours and confined textures

2. I like very stylised, abstract imagery

3. I love striking, slightly left-field display typefaces

4. I reach for “hairline” borders a lot. I think this is because they emphasise contrast.

Educating Myself on Design

With practice, I'm getting better at design debugging and realigning myself, but sometimes formal education and references also help.

Just leaving these here…three paradigm-shifting resources for me have been Typewolf's Flawless Typography Checklist, playing with type scales, and using HSL to design colour schemes. I leave these references cautiously because I dislike being confined to a scientific approach when it comes to design. For example, I like alignment, but I hate formal grids—they feel like spreadsheets to me. I find that great design tends to happen accidentally.

Despite this, design education has helped me. If I change something's defaults, I now understand the consequences—for example, I know opting for a higher line-height on my body text may “breathe” more but will result in poor readability.

Somewhat ironically, I've been sitting here for the last 15 minutes trying to find a way to wrap up this article elegantly. My list of references is a weak ending. But maybe that's OK. I'll step back, critique, and re-align this article at a later date.

Most of the video will cover spinning up a site and setting up blueprints. For the written article, here are the things you need to output for the RSS feed, which you'll need to give your podcast host.

1. Output a Link to a Podcast RSS Feed in Your <Head>

Add this to your head.antlers.html:

{{# RSS
=================================================== #}}
<link rel="alternate" type="application/rss+xml" title="Name of your podcast feed" href="{{ current_url }}/rss">

2. Create an RSS Template

Create a new file at resources/views/rss.antlers.html. Here is my specific implementation:

{{ xml_header }}

<rss xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd" version="2.0">
    <channel>
        <title>{{ brand:name | cdata }}</title>
        <itunes:title>{{ brand:name | cdata }}</itunes:title>
        <link>{{ config:app:url }}</link>
        <language>en-us</language>
        <copyright>{{ brand:authors | cdata }}</copyright>
        <itunes:author>{{ brand:authors | cdata }}</itunes:author>
        <itunes:summary>{{ brand:podcast_description | cdata }}</itunes:summary>
        {{# This should hold a concise, one-sentence description of your podcast. #}}
        <itunes:subtitle>{{ brand:podcast_subtitle | cdata }}</itunes:subtitle>
        <itunes:explicit>yes</itunes:explicit>
        <description>{{ brand:podcast_description | cdata }}</description>
        <itunes:owner>
            <itunes:name>{{ brand:podcast_owner | cdata }}</itunes:name>
            <itunes:email>{{ brand:podcast_email | cdata }}</itunes:email>
        </itunes:owner>
        <itunes:image href="{{ config:app:url }}{{ glide:brand:podcast_artwork square='1400' }}" />
        <itunes:keywords>Games</itunes:keywords>
        {{# https://www.podcastinsights.com/itunes-podcast-categories/ #}}
        <itunes:category text="Leisure">
            <itunes:category text="Video Games" />
        </itunes:category>
        <itunes:category text="News">
            <itunes:category text="Tech News" />
        </itunes:category>
        <itunes:category text="Technology"/>

        {{# PODCAST
        =================================================== #}}
        {{ collection:episodes as='posts' sort='date:desc' }}
            {{ partial:rss-post }}
        {{ /collection:episodes }}
    </channel>
</rss>

In the above we're linking to an item partial, which looks like this:

{{ posts }}
    <item>
        <title>Ep.{{ episode_number | cdata }} {{ title | cdata }}</title>
        <link>{{ config:app:url }}/episodes/{{ episode_number }}-{{ slug }}</link>
        <itunes:author>{{ brand:authors | cdata }}</itunes:author>
        <itunes:explicit>yes</itunes:explicit>
        <itunes:subtitle>{{ content | smartypants | striptags | cdata }}</itunes:subtitle>
        <itunes:summary>{{ content | smartypants | striptags | cdata }}</itunes:summary>
        {{# the Description tag is requested by some hosts e.g. https://podcasters.radiopublic.com/dashboard #}}
        <description>{{ content | smartypants | striptags | cdata }}</description>
        <itunes:image href="{{ config:app:url }}{{ if artwork }}{{ glide:artwork square='1400' }}{{ else }}{{ glide:brand:podcast_artwork square='1400' }}{{ /if }}" />
        <enclosure url="{{ audio }}" length="{{ size }}" type="audio/mpeg" />
        <guid>{{ episode_number }}</guid>
        <pubDate>{{ date format='D, d M Y H:i:s O' }}</pubDate>
        <itunes:duration>{{ duration }}</itunes:duration>
    </item>
{{ /posts }}

3. Create a Route

We need to define a route which removes the layout template and processes. Open routes/web.php and add the following: Route::statamic('/rss', 'rss', ['layout' => '', 'content_type' => 'xml']);

What we're saying here is—When these routes are matched, use our 'rss' Antler's template, skip layout processing (you'll notice we have a blank layout argument), then render the content as 'xml'—which is needed for podcast feeds.

4. Validate Your Podcast Feed

Podcast aggregators are fussy about how they receive content so it's best to be thorough. My favourites are Cast Feed Validator and Podbase

What if you want to offer multiple feeds on your own site? I was stuck with this question—since I write about a variety of things. I write music reviews, film reviews, posts about Statamic, and thought-pieces. I know not everyone cares for my music taste, so I decided to figure out how to offer different RSS feeds using Statamic since this is what my site is currently built on.

The result is my Subscribe page, where I've output all the possible RSS feeds on this site so fellow RSS-lovers can pick and choose. So how did I do this?

1. Conditionally Output an RSS Title in Your <head>

Adding a link to the head means that visitors can just dump the page URL in an RSS reader and it'll fetch the feed automatically. The minimum amount of code you’d need to link to an RSS feed would be like this:

<link rel="alternate" type="application/rss+xml" title="Jay's Blog feed" href="{{ current_url }}/rss">

This would work well for a blog, for example.

But since we want to offer different feed titles depending on the page, we'll need to use an if statement to understand which page we're on.

We can easily set variables in Statamic at the very top of the antlers file.

At the top of my resources/views/blog/index.antlers.html file I've added:

---
rss: blog
---

Subsequently at the top of my resources/views/listening/index.antlers.html file I have:

---
rss: listening
---

And at the top of my resources/views/watched/index.antlers.html file I have:

---
rss: watched
---

We now want an if statement in our head to detect the page and conditionally serve the relevant feed link. In my case I've broadly split RSS feeds into my Blog, Listening, and Watched. You could probably make this code a little leaner by simply outputting the title dynamically, but I wanted a little more control over the title so this is the way I did it.

{{ if view:rss == "blog" }}
    <link rel="alternate" type="application/rss+xml" title="Jay's Blog" href="{{ current_url }}/rss">
{{ elseif view:rss == "listening" }}
    <link rel="alternate" type="application/rss+xml" title="Jay George &ndash; Intrigue / Listening" href="{{ current_url }}/rss">
{{ elseif view:rss == "watched" }}
    <link rel="alternate" type="application/rss+xml" title="Jay George &ndash; Intrigue / Watched" href="{{ current_url }}/rss">
{{ /if }}

2. Create a Dynamic RSS Template

Create a new file called resources/views/rss.antlers.htmlThis is the file we'll use to generate a dynamic RSS feed depending on the URL. For reference, here is a simple static RSS feed:

<?xml version="1.0" encoding="UTF-8" ?>
<rss version="2.0">

<channel>
  <title>Your Page</title>
  <link>https://yoursite.com/blog</link>
  <description>Name of your blog</description>
  <item>
    <title>RSS Tutorial</title>
    <link>https://somesite.com/xml/xml_rss.asp</link>
    <description>New RSS tutorial on Some Site</description>
  </item>
  <item>
    <title>XML Tutorial</title>
    <link>https://somesite.com/xml</link>
    <description>New XML tutorial on Some Site</description>
  </item>
</channel>

</rss> 

What we need to do instead is dynamically construct a feed by testing the URL “segments”. This is best understood through looking at a code example. Here is my specific implementation. FYI I've used the standard HTML comments syntax here so they stand out a bit more in the example:

{{ xml_header }}

<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
    <channel>
        <!-- Construct RSS link by testing segments -->
        <atom:link href="{{ config:app:url }}/{{ segment_1 }}{{ if segment_2 }}/{{ segment_2 }}{{ /if }}{{ if segment_3 }}/{{ segment_3 }}/rss{{ /if }}" rel="self" type="application/rss+xml" />
        <title>{{ brand:name | cdata }} – {{ segment_1 | title }}{{ if segment_3 }} / {{ segment_3 | title }}{{ /if }}</title>
        <link>{{ config:app:url }}/{{ segment_1 }}</link>
        <description>{{ if segment_1 == 'blog' }}Thoughts and tutorials about web design.{{ /if }}</description>
        <language>en</language>
        <generator>{{ config:app:url }}</generator>

        {{# BLOG
        =================================================== #}}
        <!-- Test segments to determine which collections and taxonomies to pull into the feed -->
        {{ if segment_1 == 'blog' }}
            {{ if segment_3 }}
                {{ if segment_2 == 'categories' }}
                    { collection:blog as='posts' limit='10' taxonomy:categories="{segment_3}" }
                        {{ partial:rss-post }}
                    { /collection:blog }
                {{ elseif segment_2 == 'tags' }}
                    {{ collection:blog as='posts' limit='10' taxonomy:tags="{segment_3}" }}
                        {{ partial:rss-post }}
                    {{ /collection:blog }}
                {{ /if }}
            {{ else }}
                {{ collection:blog as='posts' limit='10' }}
                    {{ partial:rss-post }}
                {{ /collection:blog }}
            {{ /if }}
        {{ /if }}

        {{# LISTENING
        =================================================== #}}
        {{ if segment_1 == 'listening' }}
            {{ collection:listening as='posts' sort="date:desc" limit='10' }}
                {{ partial:rss-post-listening }}
            {{ /collection:listening }}
        {{ /if }}

        {{# WATCHED
        =================================================== #}}
        {{ if segment_1 == 'watched' }}
            {{ collection:watched as='posts' sort="date:desc" limit='10' }}
                {{ partial:rss-post-watched }}
            {{ /collection:watched }}
        {{ /if }}
    </channel>
</rss>

In the above we're linking to partials. As an example, here is the partial that's stored in /resources/views/_rss-post.antlers.html:

{{ posts }}
    <item>
        <title>{{ title | cdata }}</title>
        <link>{{ permalink }}</link>
        <guid >{{ permalink }}</guid>
        <description>
            {{ if hero_image }}
                <![CDATA[<img src="{{ config:app:url }}{{ glide:hero_image width="1920" height="1080" }}" width="1920" height="1080" alt="{{ hero_image:alt }}" />]]>
            {{ /if }}
            {{ main_content }}
                {{ if type == 'text' }}
                    {{ text | full_urls | cdata }}
                {{ elseif type == 'super_blockquote' }}
                    <blockquote>
                        {{ quote | full_urls | cdata }}{{ if attribution }}—{{ if attribution_link }}<a href="{{ attribution_link }}">{{ /if }}{{ attribution }}{{ attribution_link ?= '</a>' }}{{ /if }}
                    </blockquote>
                {{ elseif type == 'inline_image' }}
                    {{ caption ?= '<figure>' }}
                        <![CDATA[<img src="{{ glide:image }}" loading="lazy" width="{{ image }}{{ width }}{{ /image }}" height="{{ image }}{{ height }}{{ /image }}" alt="{{ image:alt }}" />{{ if caption }}<figcaption>{{ caption }}</figcaption>{{ /if }}{{ caption ?= '</figure>' }}]]>
                {{ elseif type == 'full-width_image' }}
                    {{ caption ?= '<figure>' }}
                        <![CDATA[<img src="{{ config:app:url }}{{ glide:image width="860" dpr="2" }}" loading="lazy" width="200" height="200" alt="{{ image:alt ?? caption }}" />{{ if caption }}<figcaption>{{ caption }}</figcaption>{{ /if }}{{ caption ?= '</figure>' }}]]>
                {{ /if }}
            {{ /main_content }}
        </description>
        {{ if categories || tags }}
            {{ if categories }}
                <category>
                    {{ categories }}
                        {{ title | cdata }}
                    {{ /categories }}
                </category>
            {{ /if }}
            {{ if tags }}
                <category>
                    {{ tags }}
                        {{ title | cdata }}
                    {{ /tags }}
                </category>
            {{ /if }}
        {{ /if }}
        <pubDate>{{ date format='D, d M Y H:i:s O' }}</pubDate>
    </item>
{{ /posts }}

3. Create a Route

We need to define a route that removes the layout template and processes since we simply want to output the feed as an 'atom' content type, which is the preferred content type for RSS.

You can create routes with Statamic through routes/web.php. This is the code I have in web.php:

// e.g. /blog/rss or /listening/rss
Route::statamic('{route_dir_1}/rss', 'rss', ['layout' => '', 'content_type' => 'atom']);
// e.g. /blog/categories/business or /blog/tags/dropbox
Route::statamic('{route_dir_1}/{route_dir_2}/{route_dir_3}/rss', 'rss', ['layout' => '', 'content_type' => 'atom']);

What we're saying here is—When these routes are matched, use our 'rss' Antler's template, skip layout processing (you'll notice we have a blank layout argument), then render the content as 'atom'—which is needed for RSS.

Some other things to note:

• We have two routes in my particular example.

• The order of the routes matters.

• Put less specific routes first. If the URL matches the first route, the second route will effectively be ignored.

• You can name the variables whatever you like, I just went with {route_directory_1}, etc. because it made it easy for me to understand

• We don't need to do it here but you can reference these route variable names in your templates if you like—although in this case, I find it easier to use the built-in Statamic's built-in {segment} tags

Tidying Up

1. Remember to clear the route cache, else the route won't work. Use the command php artisan route:clear to do this.

   1. Also, remember to run this command on your next deployment to your production server

2. Validate your RSS Feed using the W3C validator to check everything is OK.

General Tips for Designing

1. Pop your DevTools “out”—this is a personal preference of mine. It isn't easy to get a clear view of your design when pushed to the side and surrounded by code. You can change how DevTools are displayed by going in the top right > click the vertical dots > and selecting a different docking icon.

2. Use the Ruler tool—this can really help when trying to make sure elements line up.

   1. To enable the ruler tool, go to the Elements pane in DevTools, press shift + ? to access preferences > click the show rulers checkbox.

   2. A little trick I've learned is highlighting an element, so the rulers are displayed, then scroll vertically-only; without moving your mouse. DevTools will continue to draw rulers as you scroll to check elements beyond the viewport are lined up.

3. Maintain your own base CSS file—I personally keep a core.css file, and a non-core.css file. I know I'll use everything in core and quite a lot of things in non-core. This can help kick-start a project, and design in the browser immediately without any set-up.

Keyboard Shortcuts

A good metaphor for thinking about automation and keyboard shortcuts is using a well-known tool like Photoshop of a Word document. If you use these all day, you'll start to get used to some shortcuts. For example, Photoshop has single-key shortcuts for things like Brush tool (b), pen tool (p), Stamp tool (s), Switch colours (x). Word has things like Bold (b), Underline (u).

If you use these tools all day long, it's difficult to do without shortcuts. I feel the same way when designing in the browser—I want as many shortcuts as I can remember to get my ideas out fast.

Here are some convenient keyboard shortcuts that are baked into DevTools:

1. Incrementing—whenever you're keyboard is focused in a number field you can use the up/down arrows to increment by 1, and then combine with modifiers like shift to increment by 10, or alt to increment by 0.1. This works slightly differently in the Elements panel vs the Sources panel—the Elements panel being slightly superior since there is also the option to increment by 0.1.

   1. Incidentally, you can also use your scroll wheel to go up and down values, again using the modifier keys to change the way the numbers increment.

2. Previous/Next edit points—Use alt & - and alt & + to get to where you were editing previously, or most recently. I find this one particularly useful when working with larger CSS files (like my core.css!) where I'm editing variables at the top of the file and need to get to where I was.

3. Switching between inspecting and editing—you can use cmd + 1-9 to jump between different panels (you can also rearrange panels to whatever order you want by dragging them around).

   1. This is not turned on by default. To enable this, go to the Elements pane in DevTools, press shift + ? to access preferences > click the Enable cmd + 1-9 shortcut to switch panels checkbox.

   2. I use these shortcuts to switch between inspect mode (the Elements panel) and authoring CSS (the Sources panel).

Automating With Keyboard Maestro

There are a few different automation tools around. TextExpander is probably the most famous. I really like Keyboard Maestro (macOS only, unfortunately – apparently the closest thing on Windows is AutoHotkey). Keyboard Maestro is similar to TextExpander, but its feature set is much much larger, and it pretty much lets you automate whatever you can dream up.

Keyboard Maestro is incredibly handy when it comes to speeding up the authoring experience in DevTools, and you can get a free trial from their website if you're not sure. I have macros that deal with different aspects of authoring:

1. Text expansions that speed up typing property/value pairs, for example, I might type ptt to have Keyboard Maestro type out padding-block-start: var(--spacing-somevalue), and place my cursor in the correct position so that DevTools presents me with a list of possible variables.

2. Utilities such as deleting a line, moving lines up/down, commenting shortcuts, or maybe typing out a media query.

I've attached a sample of my macros below which may help you understand how to speed things up, before tailoring them to your needs.

If you'd like to understand a particular macro included in the attachment, hit me up on Twitter. Also, let me know if you have issues with any macros.

I'm writing this post mostly because I think there is a perceptual misunderstanding when it comes to designing in the browser—typically that it's slow and awkward.

How to “Live Design” In the Browser

These instructions are for Chrome, but the process should be very similar for any other Chromium-based browser like Microsoft Edge.

1. Open up DevTools on a local version of your site. A quick way to do this is by right-clicking anywhere on the page and selecting 'inspect'.

2. Press the keyboard shortcut shift + ? to open up the DevTools preferences.

3. Select Workspace from the left column, then select Add folder, then choose your site. At this point, I tend to dig a bit deeper and specifically select the folder where my CSS is housed since I don't want any other file results flagging up in DevTools. DevTools will ask your permission to map the folder at the top of the window; select Allow

That's kind of it! At this point when you look at the styles tab in the Elements pane, you'll see a load of green dots associated with the CSS files—this means that the file is successfully mapped.

Any changes you make in DevTools from now on will be automatically saved to disk.

NB you can also use a feature called local overrides to save HTML changes.

Advantages of This Workflow

• Preview as you type—No need to hit cmd + s to actually see live changes—DevTools updates the preview realtime.

• Inspect and edit in one sweep—Inspect, then click directly through to the line in the source. This is much easier and faster than remembering the line number, then looking it up in a text editor.

Feature Parity with Text Editors

Every developer loves their certain text editor for certain keyboard shortcuts or helpers. For CSS, however, DevTools should be a pretty comparable experience. Here are some of my favourite things.

• Context-sensitive autocomplete—DevTools will show you values that are context-sensitive, e.g. if you type dispay: it'll suggest display values.

• General autocomplete—You'll also be shown autocomplete when typing pretty much anything that is also in the same file like variables or properties.

• Keyboard shortcuts—there are some excellent shortcuts available. When in the Elements tab hit shift + ? then select shortcuts on the left to view them all. Some of my favourites are:

  • alt + up/down to increment and decrement value – You can also use the shift modifier to increase/decrease by 10.

  • cmd + p to go to another file in your mapped folder. Comparable to VS Code and Sublime Text's Go To File command.

  • cmd + shift + p to open a command. Here you can search for lots of things such as emulating print-media or a dark mode preference.

• Source Diff—If you're reading this at some time in the future this may be somewhere else, but for now, you can find this by going to the elements pane, pressing shift + ? to get to the preferences, then select Experiments and tick Source Diff

Advantages of Designing In the Browser Vs Using A More Visual tool

• Render differences—Remember that text (and even colour) renders differently in the browser vs what you may see in a graphics application.

• Version control—If you use Git designing in "code" is incredibly useful since you get a version control system built into your design.

• Design System—CSS custom properties—or CSS variables as they're commonly referred to—ensure your design system is consistent. For example, I predefine spacing values and use them consistently throughout a website. I know you could argue that something like Adobe XD could give you this, but remember—so does CSS!

General Ploi Settings

• Click your avatar (top right) > Profile

  • Settings > Theme mode > Dark —I'm not usually a big dark-mode fan but I like it here

  • Backup configurations > configure these as needed

  • Security > Enable 2FA here

• Server > Select your server > PHP

  • Manage Extensions (button)

    • Imagick (checkbox)

  • Enable OPcache (button). If we're using Statamic and have the default php7.4-fpm reload command in our deploy script, then we don't need to worry about the warning here

Editing File Backups

If you've spent some time setting up file backups (as above) you can edit or run them manually—but the settings are in a different place. Go to Sites > Your Site > Manage > File Backups

Notifications

• Click your avatar (top right) > Profile

  • Integrations

    • Set this up first with whatever service you'd like. Personally I use Google Drive for backups and Telegram for notifications, so I'll include instructions for them below.

  • Notification Channels

    • For Telegram I chose a label of “Telegram” and clicked “Create”

Setting Up Notifications for Sites

Once you've set up this base configuration you'll need to set up notifications on a site basis.

• Sites > Your Site > Notifications

  • Select your Telegram setup here from the dropdown

Setting Up Server Notifications

• Servers > Your Server > Monitoring > add a notification for anything over 80%. There's no basis for this number, but it felt like a good point at which I'd like to take action.

  • While you're here, click the channel notification to also send an alert through Telegram if this happens

• Server > Manage > Automatic update notifications > choose a service to be notified on e.g. Telegram. I tend to set up automatic server updates on a weekly basis here.

Password Protect a Site

I thought it was worth mentioning how to do this since it's a brilliant feature that's not easily discoverable. Password protection is desiable if you're working on a site that is under NDA or if maybe contains confidential information while under development.

To password protect a site go to Sites > Your Site > Manage > Authentication (button)

There are a few ways to use Statamic—workflow and licence-wise. This video may be useful if you're checking out Statamic with a solo licence and need to pull down some changes from your production environment, or you may just want to make sure your server can push to your repo via SSH if you're setting up Statamic Pro Git integration.

Make Sure You Have Your Repository Linked to Ploi Via SSH

One “Gotcha” with Ploi is if you link to a repository using the built-in “wizard” it will link to your repository using the OAuth protocol. Oath defaults to HTTPS, which means we won't be using SSH to push changes. This causes issues when trying to push back to the repository.

To solve this, when you link a site to a repository in Ploi, instead of selecting your provider, choose “Custom”. At this point, you need to ensure that you add your Ploi sever's SSH key to your account with your provider. Ploi will show you the SSH key to add when you select “Custom”. Copy the key, and (in Bitbucket, for example) go to your Personal Settings > SSH Keys > Add Key – paste in the copied SSH key and call it something like “Ploi - Name of your server”.

Go back into your repository in Bitbucket and click the “Clone” button in the top right. This will reveal the address of your Bitbucket repository. It will look something like this:

git@bitbucket.org:jaygeorge/jaygeorge.co.uk-statamic.git

Paste this into the Repository field in Ploi, select “Install composer dependencies” as usual and then click “Install Repository”. A huge thank you to Stephen Meehan for helping me out with this gotcha.

Check The Git Status On Your Server and Commit Changes to Git

1. SSH into your machine, using a command like ssh ploi@yourserveripaddresshere

2. Make sure you're in the correct directory—with Ploi that'll probably be a command like: cd yourdomainname.com

3. git remote -v this should now show you two SSH-style addresses—one for fetch and one for pull.

4. git status to see if there are any changes to the production site that you can push up to Git.

5. Go ahead and add your changes to production e.g.

   1. git add .

   2. git commit -m "Content changes"

   3. git push

You should now be able to pull your changes down to your site locally using the git pull command.

Adding Your Computer’s SSH Key to Ploi

You'll first need to add your computer's SSH key to Ploi. You'll also need to do this if you connect via SFTP using software that uses your computer's SSH key (Forklift is an example of this).

1. Copy your computer's SSH key. You can do this by running cat ~/.ssh/id_rsa.pub if you have a key with RSA encryption, or cat ~/.ssh/id_ed25519.pub if you have a key with ED encryption

2. Open Terminal and SSH into your server by running ssh ploi@youripaddresshere, which will look something like ssh ploi@178.128.35.22. You should now be logged into your server.

Making Your SSH Key Persistent

If you're running macOS 10.12 or later (you probably are) then you'll need to do a few things to make your SSH key persistent. Create a config file in your SSH directory (the same directory where your public key is, e.g., .ssh/) and in the config file add the text:

Host *
 AddKeysToAgent yes
 UseKeychain yes
 IdentityFile ~/.ssh/id_ed25519

If you're running with the older RSA encryption then it will look like this:

Host *
 AddKeysToAgent yes
 UseKeychain yes
 IdentityFile ~/.ssh/id_rsa

Finally, run the following in Terminal:

ssh-add -K ~/.ssh/id_ed25519

Or if you're running with the older RSA encryption:

ssh-add -K ~/.ssh/id_rsa

SFTP Details

This is a sample of what your SFTP details will look like:

Protocol: SFTP
Server: 46.101.80.111 (replace this with your server's ip address)
Username: ploi
Password: this will be the 'sudo' password you were sent when Ploi installed your server
Port: 22