My March 2017 Personal Publishing Thoughts

created Mar 21, 2017

updated May 18, 2018 to edit writing mistakes and to fix links.

Define owning content

This is about content creators owning their content, whatever that means.

If I pay a monthly fee to Digital Ocean to use a server that houses my web publishing software and the content that I create, do I own my content when it resides on someone else's system?

I backup my posts to my desktop Linux server by downloading the text markup files and the MySQL database dump files. At that point, I know that I own my content.

I upload my photos mainly to Flickr, which I use as an image storage system. I don't care about Flickr's community features. I store my images at Flickr, and then I embed them into my web posts, created by one of my web publishing apps.

I download my photos to a hard drive and burn them to DvDs. At that point, I know that I own my photos. Same for videos.

When I created a Tor .onion site on my Linux desktop computer, which resides in my home, then that's truly owning my content.

Customer or the product?

"If you aren't paying for something, then you aren't the customer. You're the product being sold."

I guess owning content could mean that the content and the author's actions are not re-purposed by the hosting service and used for advertising purposes.

Boghop is hosted, using Amazon Web Services. I don't think that Amazon is parsing this site and using my content as a product. Neither is Digital Ocean, which hosts my other websites, including sawv.org.

Open web vs silos

I would like to see more people post text onto their own corner of the web. If the service accepts video and photo uploads, then that's even better. But the debate is about silos vs the open web.

I assume Instagram and Flickr are silos. But what about Wordpress.com? I could blog by using Instagram. How is that any different than creating a blog site with the Wordpress hosted system at Wordpress.com?

The Wordpress.org site focuses on the Wordpress content management system that users can download and install on their server accounts.

But from a silo vs open web perspective is https://instagram.com/mywebpresence different from https://mywebpresence.wordpress.com?

I don't know. It requires too much thought energy to define silos vs the open web with all of the exceptions. As long as it's easy for the author to download the content and copy it to a thumb drive, hard disk, or to DvD for storage purposes, then the service is fine.

I'm unsure if Instagram meets those requirements. I think that Facebook permits users to download their content.

Think long and slow

If the system makes it easy for the author to publish, and if the system encourages the author to create content at a regular interval, then that process is the correct method, regardless of what anyone else thinks.

The author can upgrade or modify the publishing process if the author gets bored and wants a change, or if the author learns more about the web and becomes an advanced user.

It's not helpful to push a beginner to become an advanced user immediately. A long, slow, organic process is preferred.

The independent web means site owners, after careful deliberation, can decide for themselves how their sites should function.

Most site owners want a drop-dead simple way of creating and updating content without having to learn a lot of technical concepts. Most personal publishers do not want to be sys admins nor programmers.

If the publishing system is easy, then people might use it.

Beginners

For starting out, I would say creating an account at Blogger (or Google) and posting at yoursitename.blogspot.com is a good start. Then maybe later, if interest still exists, migrate to another platform or method of publishing, and use a personal domain name.

But keep it simple to start. The key is to publish every week. Not every day. That might be too much. But for starting out, publish any length at least once a week.

And just like with exercise, the goal is to be publishing five years from now at a regular interval with no major down periods.

Users should ignore political ideologies, regarding personal publishing on the web, including this page. Would-be personal publishers should seek out and absorb the many viewpoints, and then define their own web presences.

---

Suggestions

Domain names

Buy a domain name and use it for your website, or don't buy a domain name, since that's one fewer thing that needs to be renewed at regular intervals.

Publish at Blogger, Medium.com, Wordpress.com, Ghost, Svbtle, Tumblr, etc., and if owning a domain name, point the name at your hosted site, if the service offers domain name mapping.

Your domain name can point to a Wordpress account where the content is hosted on Wordpress's infrastructure, but the site name would be http://yoursitename.com instead of http://yoursitename.wordpress.com.

CMS-hosted sites

A CMS-hosted setup removes the need to purchase server space, and you do not need to download, install, configure, secure, and update the publishing software. The hosted services, such as Svbtle, Wordpress.com, and Blogger.com, handle the sys admin and programming duties.

If not owning a domain name, then accept URLs, such as yoursitename.blogspot.com or yournsiteame.wordress.com, which are okay, at least for starting out.

Even http://yoursitename.blogspot.com is a unique URL that is more in the open web than a public-facing Facebook page because Facebook annoys logged-out users with a large banner, encouraging people to join the network.

I visit blog sites, hosted at .blogspot.com. The authors don't care that they aren't using a domain name, and neither do I. I visit those sites for the content.

The downside of this is preserving URLs if migrating content to a different CMS-hosted system or switching to a personal domain name.

Personal hosting

Pay for a virtual server and install web publishing software. Numerous small and large web publishing systems exist that can be downloaded and installed by users on their server accounts.

That's a geeky approach, which is probably beyond the capabilities of most non-techy people. It requires making security updates to the software and maybe tweaks to the code, which means acting like a sys-admin and programmer at times.

Static vs dynamic site

A static site means that the web server serves up HTML files. A dynamically-generated website means that with every web page request, the content is pulled from a database or the file system, and the HTML page is assembled on the fly before being sent to the reader.

Static site generating software does not rely on a database, which means one fewer item that needs to be maintained, regarding security and uptime. This is a simpler setup.

For static sites, the web posts are stored in text files on the file system, which can be easily downloaded for backup purposes.

Databases can be dumped for backups too. Databases make it easy to search content and to add dynamic features, such as a related articles section at the bottom of posts.

This debate applies mainly to users who buy server space and download and install a web publishing system. If hosting at Ghost, Medium, or Wordpress, then you don't have much of choice, regarding static vs dynamic.

If you host at GitHub Pages, then you will have a static site.

Your site vs social media

Publish on your own site first and then syndicate to your social media properties second.

Or publish on your own site and then to social media whenever and however. If you want to manually copy your social media posts to your personal site, that's fine. But if that's too much trouble or if you don't feel that it's worth backfeeding your social media content to your personal site, then that's fine too. But lengthy text posts that are publicly viewable on social media should be copied to your personal site too.

Follow the Indieweb principles or ignore them and do your own thing. The Indieweb concepts are technical and probably beyond most content producers. But it involves posting everything on your personal site, text, photos, replies, etc. and then programmatically, your content gets posted to your chosen social media sites.

The interactions on social media sites, such as likes and comments, are automatically posted back to your personal website. It's a good process, but for many authors, it might be too complex to implement and use. This might get easier with time. It could also become difficult if the social media silos become more closed, preventing syndication and backfeeding.

The Indieweb evangelists increase every year, and they are committed to making it easier for content producers to own their content while easily interacting with their social media friends. The Indieweb began around 2010. Their inspiration is rooted in the 1990s and early aughts, but they are adapting to the modern web.

The IndieWeb has proposed many useful but technical concepts, such as Webmention, Micropub, IndieAuth, Microformats, MicroSub, h-feed, etc. But to support the IndieWeb, a personal publisher only needs to adhere to this one idea that I bolded below.

The IndieWeb is a community of individual personal websites, connected by simple standards, based on the principles of owning your domain, using it as your primary identity, to publish on your own site (optionally syndicate elsewhere), and own your data.

Design

Design your website with a minimal HTML tag set from the early 1990s and no CSS and no JavaScript, or design your website as a JavaScript single page application that does not work if JavaScript is disabled.

Make your site serve static HTML files, or make your site serve dynamically-generated content.

Redesign your site once every five years or redesign every week.

Make each page appear differently if you desire. It's your site. Experiment and have fun.

Make your site's homepage display a stream of posts, ordered by creation date, youngest to oldest, or don't do anything close to this. Display any content that you want on your homepage. The top post could be from yesterday or from 10 years ago, followed by a post from two months ago, followed by a post from today.

Who cares except you. Maybe you order the posts on your homepage by YOUR favorites. Maybe your homepage is an "about" page, describing yourself, and your posts can be found in the archives section.

The amount of customization and choices could vary on whether you use a CMS-hosted solution like Svbtle, which provides hardly any customization options, and a server-hosted solution where you install a static site generator that permits maximum customization on every post if desired.

Feeds

Create feeds in one or more of the following formats: RSS, Atom, JSON, and Microformats, or create no feeds. If the latter and if people want to read your content, then they'll have to visit your website directly, instead of scarfing your feed in a reader app. If that's unacceptable to the feed-reading geeks, then too bad.

Most publishing systems produce at least one type of feed. The Indieweb promotes Microformats, which I find useful too. RSS is still heavily used.

Comments

Permit others to post comments on your site or prohibit comments by others. Same for the Indiweb's Webmentions, which I prefer over a comment system.

Webmentions force commenters to create their replies on their own public-facing web presences or sites.

But it's not a requirement for you, the site owner, to permit others to post their content on your site. Commenters can post their replies on their own websites, and then maybe you become aware of those replies and maybe you don't.

Here's a lo-fi commenting system, which requires displaying an email address on your site.

• Private comment : Readers send you emails.
• Public comment : Readers write their replies on their own websites. The reply posts should contain the URLs to your web posts that the readers are replying to. Then the readers can email you the URLs to their reply posts. You can link to the reply posts at the bottom of your articles, maybe excerpting some of the replies. Obviously, if the reply is trash, then you ignore it. Moderating.

If you want, you can take your discussions to Twitter, or you can engage in no discussions anywhere.

It's probably easier for a beginners to publish on their own sites, and that's it. Don't even provide an email for people to use for replying.

Over time when beginners become more comfortable, then maybe they will enable some kind of reply mechanism. Again, the thinking should be a long, slow, organic process.

http or https

Use SSL/TLS with https or don't use it and continue with http. If people dislike your use of http instead of https, then they don't have to read your site.

A brand new website with brand new content can start with SSL/TLS easily, especially with a CMS-hosted solution. You won't have a choice if hosting at Svbtle and other CMS-hosted services. SSL/TLS is enabled by default.

For a server-hosted solution, well, it's one more technical thing that you have to do. Let's Encrypt makes implementing SSL/TLS straightforward, and the certificate on your server can be updated automatically.

An old website that contains thousands of posts may need some updating to support SSL/TLS. Embedded images that rely on http will not display if an old site converts to SSL/TLS.

Public or private

Make the site public to the world or private to yourself or to a few select people.

Type of site

Label it a blog, wiki, journal, diary, E/N (Everything/Nothing). It's called whatever you want to call it. How others label your site is irrelevant.

Make your content narrowly focused, or post about everything imaginable.

My site http://toledowinter.com is a seasonal blog that runs from approximately Nov 1 to Apr 1, and it covers winter weather in the Toledo area.

But sawv.org will host my posts about weather, fishing, cycling, running, birdwatching, beer brewing, crocheting, art, sports, gardening, events, family, local politics, businesses, health, food, etc., etc., etc.

sawv.org will host everything that means something to me even though it probably means nothing to everyone else. It's an E/N site.

What to write about? Anything, regardless of how mundane the subject matter. With time, the boring posts become more important to you.

"Even nothing is something."

Excerpts from http://www.seinfeldscripts.com/ThePitch.htm with my additions surrounded by brackets:

GEORGE: I think I can sum up the show [WEBSITE] for you with one word: NOTHING.

RUSSELL: Nothing?

GEORGE: Nothing.

RUSSELL: What does that mean?

GEORGE: The show [WEBSITE] is about nothing [TO EVERYONE ELSE].

JERRY: But, even nothing is something. [ESPECIALLY TO THE WEB SITE AUTHOR]

GEORGE: What'd you do today?

RUSSELL: I got up and came to work.

GEORGE: That's a show [A WEB POST].