So, I’m sure that everyone who cared already has heard about Twitter’s shutdown of the APIs that third-party applications use. For me, this invokes the myth of Cortez burning the ships. I do not see a way for me to go back to Twitter.

I haven’t deleted or deactivated my account, as I had seen other users. Instead, I have deleted the Tweetbot application from my phone. Tweetbot was actually the reason that the Twitter service has stuck with me so long. The third-party applications were the only way that you could access the Twitter feed using a timeline instead of the curated feed that twitter wanted to give to you in addition to any ads. Tweetbot also allowed you to set up keywords to filter the stream. I used them primarily to block out media spoilers and when someone got a little too chatty about their latest multilevel marketing scheme business.

This, coupled with lists of individuals that I picked and reviewed, made twitter into what some would call an infinity pool for my attention. An infinity pool is defined as something that can endlessly supply you with entertainment/distractions.

Any time that I felt some stress, I could turn to Tweetbot to find something to occupy my mind. A little break before getting back to work. It was pretty easy to develop a dependency. I’m glad I never turned on notifications.

In the middle of last year, I took steps to move away from Twitter and I found the easiest way of doing that was to delete the application from my phone. If I wanted to get back on, I’d have to go through the process of downloading the app and logging in. Sure, not the biggest hurdle, but enough friction to stop me at those times when I needed to focus the most.

Well, now the API has been shutdown.

There’s no point in downloading the application.

And, without the customization that I’m used to, I don’t have as much desire to login.

And why should I log in?

Most of the content makers that I enjoyed are no longer on the service.

From what I hear, the site is filled with ads, and I’m already having enough trouble focusing that I don’t want to introduce more problems.

So.

That’s one less thing to distract me.

On to Ivory…

In the beginning of this series, we started off with an index page that was just a static page with one line that stated you were on the index page. When it comes to implementing this, I looked at the Hugo Themes Free as well as the theme gallery that Micro.blog provides.

Ultimately, I went with a simple structure that took advantage of the simplicity that I had in the Pure theme and the fact that we had already extracted the logic for articles into the partials.

{{- range ( .Paginate (where .Site.RegularPages "Type" "post")).Pages }}
{{ partial "article.html" . }}
{{ end }}

After that, we remove all the static <article> tags that we placed into our index to see how it renders. This looks ok, but the design that I have in mind calls for pagination¹(being able to go to older posts).

Paging the index

I admit that I went down a rabbit hole of different examples of how to create the navigation that you see at the bottom of the page. A lot of the examples that I came across where hard coded or I couldn’t understand.

Ultimately, I went with the example that I had from my previous theme. I took the code and placed it into a file name partial\site-navigation.html so that I can track it later.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

{{ "<!-- Site Pagination -->" | safeHTML }}
{{ $paginator := .Paginate (where .Data.Pages.ByDate.Reverse "Type" "post") (index .Site.Params "archive-paginate" | default 10) }}
<nav class="pagination">
	{{- if $paginator.HasPrev -}}
	<p class="nav_prev">
		<a href="{{ $paginator.Prev.URL }}" title="Previous Page" rel="prev">
		← Newer Posts
		</a>
	</p>
	{{- end }}

	{{ if $paginator.HasNext -}}
	<p class="nav_next">
		<a href="{{ $paginator.Next.URL }}" title="Next Page" rel="next">
		Older Posts →
		</a>
	</p>
	{{- end }}
</nav>

On the first line, I’m adding a line that will show up in the final output of the generated site so I can see where Hugo is inserting the code.

The second line calls the default paginator to go over all the posts that the site has by whatever parameter that is given. If none is given, it will use 10.

Line 3 defines our semantic element for the navigation and give it a class for styling it later.

Line 4-10 tests to see if there is a previous page and then creates a link to the page when it exists.

Line 12-18 tests to see if there is a next page and creates everything that’s needed.

Navigation

The navigation was another thing that I spent a lot of time looking into, but ultimately went with a simple ordered list of items.

The initial design did not have a link to the home page because I thought that anyone how came across the page would only be interested in that page and not the additional content, but after having to go to the address bar multiple times to navigate between the different pages, I decided to add it as the first item.

I placed this into a separate file called site-nav.html like I did for pagination for better tracking.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

{{ "<!-- site-nav.html -->" | safeHTML }}
<nav>
	<menu>
		{{ if ne .IsHome true }}
		<li><a href="{{ .Site.BaseURL }}" title="{{ .Site.Title }}">Home</a></li>
		{{ end }}
		{{- range .Site.Menus.main }} 
		<li><a href="{{ .URL | relLangURL | safeURL }}">{{ .Name }}</a></li>
		{{ end -}}
		<li><a href="{{ "feed.xml" | absURL }}" rel="feed" type="application/rss+xml" title="{{ $.Site.Title }}">RSS</a></li>
	</menu>
</nav>

On line 3, I used the <menu> semantic tag to give it some more meaning. It definitely felt that it took some time to On line 3, I used the <menu> semantic tag to give it some more meaning. It definitely felt that it took some time to get a consensus on whether I needed to add a <ul> or <ol> to make the syntax valid.

Line 4 does a test to see if the generated page is the home page. This is working to an extent, but fails when moving to the second index page.

Line 7 sorts through the different menu items. I had an issue trying to understand how Hugo puts together a menu on my local copy and what was being used in Micro.blog.

Line 10 gives a direct link to the RSS feed for the site. The RSS feed is inherited from the base blank theme that underlies of Micro.blog.

The next segment of this tutorial will be focused on the schema tags followed by accessibility and then a grab bag of different things.

Please let me know if you have any questions about the design so that I can make this better. I think I might put this all together in one LARGE post at the end.

In my initial design, I had footer that would show the categories, tags, date published, and date modified. All of these values are things, I had seen in previous sites and I could easily get to this information. I thought it would be 15-20 minutes to get this information. The fact that I felt that the footer deserves it’s own discussion should let you know that it ultimately wasn’t.

Start!

The first thing I did was move my current static footer from my example into it’s own template file partials/article-footer.html. I’m going to spare you the boring details of how I searched and searched through examples of what I thought it should look like versus what Hugo provides. A lot the issues that I ran into was whether I was using tag, tags, category, or categories. Do I write the code I write have to parse a comma separate list or an array?

My mental model originally had it so that a post could have one category and multiple tags.

Unfortunately, after a couple hours I realized that a lot of this was moot because I was going to send this template to Micro.blog and I didn’t know what they used.

Getting more information about Micro.blog

The ultimate goal for this theme is that I’d use it on the Micro.blog service. Although Micro.blog uses Hugo, it has a significant amount of customization that I do not know about. Honestly, I do not want to know exactly how it is put together, but I do want to know what it is sending to the theme to get rendered.

So, this is the point in the process where I deploy all the changes that I’ve made to GitHub and then use the instructions on how to set up with a custom theme.

I took some information from the  Hugo page on debugging a theme and then placed that in a <detail> item nested in the  footer. This made the article.html template pretty long, so I decided to make the footer into its own file (article-footer.html) for easier management.

Ultimately, this allows me to see if Micro.blog supports tags or categories and whether it’s stores in a string or array. I’m going to include the code in this post below.

{{ "<!-- Debugging Details --> " | safeHTML }}
	<details>
		<summary>Debug</summary>
		<h1>Site Properties</h1>
		<pre>
		{{ printf "%#v \n" $.Site  }}
		</pre>

		<h1>site.Params Properties</h1>
		<pre>
		{{ printf "%#v" site.Params }}
		</pre>

		<h1>Permalink</h1>
		<pre>
		{{ printf "%#v \n" .Permalink }}
		</pre>
		
		<h1>Params</h1>
		<pre>
		{{ printf "%s" $.Params }}
		</pre>

		<h2>All variables scoped to the current context</h2>
		<pre>
		{{ printf "%#v" . }}	
		</pre>
	</details>

After that, I’ll set the display of the debug information to hidden in the CSS.

article footer details {
    display: none;
}

I then deploy it to the test blog to see what is going on, I can see that categories is used in templates and is stored in an array.

If we parse through the debug information, we can find the information about whether Micro.blog uses tags or categories.

Categories and Tags

As you have seen, I spend a lot more time of what the different elements make up the different pages. From here, I borrowed¹ some code from the internet and rewrote it so that I can hopefully remember what it does in the future.

{{ with .Param "categories" }}
	Categories:

	{{ range $CategoryArray, $Category := (. | sort) }}
		{{ if gt $CategoryArray 0 }}
			<span>•</span>
		{{ end }}
		<a href="/categories/{{ $Category | urlize }}">{{ $Category }}</a>
	{{ end }}
	
{{ end }}

I also included code for tags that I saw in another example to future proof the theme in case we add tags later on with Micro.blog.

{{- with .Param "tags" }}
{{ with $.Param "categories"}}
<br />
{{ end }}
	Tags: <span itemprop="keywords">
  	{{ range $index, $tag := (. | sort) }} 
  		{{ with $.Site.GetPage (printf "/%s/%s" "tags" $tag) }}
  			<a href="{{ .Permalink }}" class="tag">{{ $tag | urlize }}</a>
  		{{ end }}
	{{ end }}
	</span>
{{- end }}

I didn’t do much with this portion because we don’t use them with Micro.blog, and I’ve got a lot of other things to get working before coming back to this.

Remember the time

Another piece of information that we can get from the debug output is date information from the post. We actually get three different dates: date, publishdate, and lastmod.

On my local server instance, I played with the different logic for if a date was different than another and learned about how Go did comparisons of dates for about an hour.

Then I found out that Micro.blog use the same time for all three…

You can then put this information into our template.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

<p>Published: 
	<a href="{{ .Permalink }}" class="u-url">
	<time class="dt-publised" itemprop="dateCreated datePublished"
		{{ 
		printf `datetime="%s"` (.Date.Format "2006-01-02T15:04:05Z07:00") 
		| safeHTMLAttr }}>
		{{- .Date.Format (default "January 2, 2006" .Site.Params.date_format) }}
	</time>
	</a>
</p>

On line 2, I create a link to the article because this footer will be used single pages and the index and we don’t know if every post will have a title.

Line 5 makes sure that the date is formatted in ISO 8601 so that it can be parsed properly.

Line 7 shows the date in a more human readable way. I made a mental note to look into how I can make it output “6th” but all the examples that I’ve seen do not show in like that.

Styling the footer

I wanted the footer to have two separate sections of information; one for categories and tags and the other for dates.

I used a css grid to make the two sections and made sure that the data I add was grouped in a <p> tags.

article footer {
    display: grid;
    grid-template-columns: 2;
}

article footer p:last-of-type {
    grid-column: 2;
    text-align: right;
}

After doing my testing and getting the debug information, I hid the details in the footer.

article footer details {
    display: none;
}

I plan to cover more css when I discuss accessibility later on in the series.