When I think about what I want in a map on a blog, my needs are fairly basic: posts that have a location should show a map with an indicator where the post was made and if I'm unsure of the coordinates (a guarantee) , I should to be able to search and find it on a map.
If the location too new or uncommon, it may not show up. In that scenario finding the location on the map and selecting in manually isn't large ask.
While maps are a an important point of many posts: that new coffee shop I checked in at, the location of that cool bridge in a photo I shared, or that time status I posted looking out the window of the shinkansen – they're not central or even wanted in most posts.
Sharing a thought, a checkin, or a photo is the point.
One day there might be public facing features where maps play a prominent role and are the point of a post. But until then the big maps will be reserved for when you're authoring a post and can use the extra space to pan and zoom, and on the public side, they'll be smaller and out of the way – they're not the point.
I got a good question from Adam (@TalAdam) about why I have Tanzawa on a subdomain, rather than my main domain. While the answer is simple it's a good opportunity to discuss my plans for Tanzawa in the mid-term future.
To answer Adam's question:
- 1. When I started Tanzawa I didn't have a domain (or even a name), so I started with a domain I owned.
- 2. I need to build up my minimal feature parity of my current blog before I can switch my main domain from Wordpress to Tanzawa.
What's remaining for my minimal feature parity? Only three parts: bookmarks/likes, checkins (w/ maps), and photo posts. Technically four - but photo posts are lower on the list. Once that's done I'll need to figure out how to migrate my data and create a huge redirect map for nginx. Perhaps by the end of the month?
Once I migrate my main site to Tanzawa what's left for this blog? I plan to redirect it somewhere on the tanzawa.blog domain. From there, I'll continuing using this blog as a development blog as I polish Tanzawa for a proper release that other people can use.
I realized while I've been blogging about the development of Tanzawa, I haven't talked much about my overall goals for the system. This post will dive a bit into what my goals are for the system and how I envision it working.
My main goal for Tanzawa is to make a system that makes it enjoyable and easy to blog (be it micro, photo, articles, whatever) while maintaining ownership of your content. Yes, you can achieve this Wordpress, to a degree, but it's not made for it.
David Shanske and the other devs who've made the IndieWeb plugins for Wordpress have done fantastic work. It got me back into blogging and fighting for the open web. Tanzawa is my attempt to build upon the ideas in their work and push it forward.
Sustainability & Privacy
My other main goal for Tanzawa is to bring awareness and advocate for a sustainable web. Modern computer systems waste so many resources with poor design, unoptimized media, legacy formats - you name it. Tanzawa will always strive to have the lightest impact on your server, your network, and when rendered on your computer/phone.
To those ends Tanzawa uses minimal css styled with Tailwind - no large component frameworks. Image tags are written so browsers always choose the latest file format with the best compression so less data is transferred. What's more, we don't change file formats until it's first requested, saving your server from making and your disk from storing images that will never be served. We proudly use system fonts, avoiding megabytes of downloads.
A smaller, but still important goal for Tanzawa is to build a system that respects your privacy and the privacy of your visitors. We don't include any third-party libraries or scripts that track anything about you. We also strip all location and other exif from uploaded photos.
Own Your Data
One of the promises of the of POSSE and backfeeding is that you are in control. The current tooling works, but it feels too geeky. I either need to have a custom setup with a static site (which means writing Markdown and using a command line) or use Wordpress, and then you're stuck within the confines of Wordpress.
I want to make it simple to "tweet" from your blog. To backfeed from the silos into your blog. And I want to be able to remix this data together, to make new posts and pages, rather than having it locked in posts or behind an opaque API.
The recent resurgence of interest in blogging and RSS makes me hopeful that when Tanzawa is ready to general usage there's a chance it'll make a difference.
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.
Differentiating Replies and Bookmarks in Tanzawa
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.
The Slow WebWhat 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.
- The slow web is formulating your thoughts and expressing them fully.
- The slow web is about owning what you produce.
- The slow web is open.
- The slow web is yours.
The Slow Web in Practice
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.
SharingSo 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?
- Writing unique content that matters to you and like-minded people will find it via search
- RSS Feeds (standard in most all blogging systems)
- POSSE (Publish (on your) Own Site, Syndicate Elsewhere
Ignore the NumbersKnowing 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.
Don't Over EngineerAs 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 JumpMaking 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.
Previous 2 of 2