With support for articles shipped in Tanzawa (this is the first one! 🎉 ) I'm taking a day off coding and doing a day of thinking about the next post kind(s) I want in Tanzawa: bookmarks & replies.

Why group them? Well,  they're quite similar in my mind. A "reply" is a blog post that is a reply to some other page or post on the internet.  On my current Wordpress site they look like a note with a link to site and maybe an excerpt for which  we're replying.

Bookmarks look quite similar. Infact they're exactly the same, except I opted to put the link emoji for bookmarks.

Just looking at the two different post kinds the only difference is in the webmention that's sent. In replies there's a `u-in-reply-to` while in a bookmark there isn't. Part of the reason why they're the same is because how I treat bookmarks.

When I bookmark something publicly on my blog I've write a note as to why I'm bookmarking it. It's less of a reply and more of an aside. However, reflecting on this behavior while writing this post, I think I've been using bookmarks in this manner because I've been using Wordpress. The interface for posting bookmarks and replies (and statuses and articles) is the same and so you're encouraged to treat them the same.

Both bookmarks and replies will need a field for inputting the url that we're bookmarking or replying too. And both kinds will need to dynamically load the page, extract title / author / summary information. And in both types users should be able to correct the extracted information.

I think the major difference must be made in how they're displayed in a list. Bookmarks should be displayed completely differently than other post kinds. They should only display the page title / link / date bookmarked / post permalink. Each bookmark's detail page can show the extra meta information: a note, an excerpt, and so forth.

Replies will display much like status i.e. there's no post title. But it will begin with a link and excerpt for the reply to setup the context for the post followed by our note. RSS feeds for bookmarks and replies should be the same: linked site meta info followed by a note.

My bet is that bookmarks and replies display much differently in your streams on the site that even though the publishing interface may be similar, your usage will change.

It's been almost 5 years since I wrote Slow is not a Dirty Word. Reflecting on the sentiment in that article, that the best things in life take time and we needn't rush as society tries to force us, didn't quite go far enough. The concept of Slow should also be applied to the web.

What is the slow web? At it's core it's the idea that we shouldn't fill our mind with junk and we should connect with those around us. Social media is fast food for the mind. Consuming it feels in the moment, but when you look back you're not left with anything memorable. Moreover, because of the lack of nuance afforded by platforms, such as Twitter, it encourages behavior based on dopamine and adrenaline impulses.

Most people the slow web is best manifested as a blog. This could be a simple Wordpress blog, a micro.blog, a bunch of static files on a server somewhere, anything that works for you. The important part is that you have control of your content. That you can control how and when it appears.

So much of sharing on the web these days is based on these social media platforms. So how do you get the word out about your new latest pieces in the slow web?

Knowing the number of visits to your website or article only serves to feed disappointment when one article doesn't match your expectations. Avoiding that sense of failure will inevitability lead to a habit of not writing and only consuming.

The common methods of tracking visits can not only break your site, it also invites an invasion of privacy for your readers. Are there more privacy-minded ways to collect visitor statistics? Yes. Do you even need to collect the information in the first place? Probably not.

As technologies it's often easy to get caught up in nuts and bolts. We're want to build our websites to handle all the traffic the world can throw at it, so we setup database servers, build servers, deploy servers, proxy servers, and CDN caches. And for what? A trickle of traffic? All of this could be easily served off a single server, reducing operational complexity and reducing the places where things can break when you really just want to publish a blog.

Making the jump to the slow web doesn't mean you cannot participate in the social networks, you're just changing the terms of engagement. Instead of being the default place to collect your thoughts and ideas, it simply becomes another channel to link back to your site.

Because you no longer tweet every clever thought you have into the void, you're able to slow down your mind, formulate your thoughts, and take back control.