What’s the minimum viable blog feature set these days?

  • Rich text posts (output; the source can be anything)
  • Titles
  • Permalinks
  • Tags/categories
  • Navigation
  • RSS feed
  • Images hosted locally
  • Media embed (remote or local?)
  • Author info for multi-author blogs

I won’t back down on RSS/Atom, because there’s SO MUCH you and subscribers can do with it.

I also think images should to be built-in and not something you bolt on clumsily afterward.

Not sure if I’d consider comments part of the base level.

What else am I missing?

Candidate Software

Looking for something lighter weight than WordPress.

The last time I tried Plume and WriteFreely, they didn’t support images, though IIRC you could embed remote images in at least one.

Static site generators I’ve tried like Jekyll require you to bolt on separate commenting systems like Disqus, or jump through hoops to roll your own in a way that will re-generate the site when someone comments…and you still have to reinvent spam filtering.

I use extensive filters on Gmail to categorize mail the way I want. I pre-filter some things to look at later, prioritize some lists (like allergy or uptime alerts), and pre-categorize things that I may want to file away after looking at them.

The problem is, I can only change filters on the desktop site. When I’m reading on my phone, I need to remind myself not to archive or delete messages that I want to start filtering.

It occurred to me: I can label those messages “Change Filter.” I could even do it right away – there’s a “Manage labels” option on the Android app!

Nope!

I can’t add labels in the app, just change the download and notification settings for each.

So, website then…

Except I can’t get at the full Gmail website on my phone. Or my tablet. Google insists on showing a stripped-down mobile site, which has even fewer capabilities than the app.

I can’t fault them for starting with the mobile site. It is helpful to focus on the features that work best on small touchscreens, under-powered processors, and high-latency, low-bandwidth networks, and can be done by someone on the go, rather than someone sitting at a keyboard with a big screen and a mouse.

But if someone wants to use the functionality you’ve left out, and is willing to slog through the desktop site on their phone or tablet, you should at least let them get at it!

In this case I waited until I could log in on a desktop, then added the label. But not everyone with a phone has a desktop or a laptop. And as the balance keeps shifting towards phones as people’s primary internet access device, that’s going to be more and more common.

I figured out exactly what bugs me about Twitter and Facebook showing your friends’ “likes” in the timeline. It’s not just that they’re public — that’s true on Tumblr or Flickr or Instagram too, but you only see them when you choose to look for them.

It’s that broadcasting likes in the newsfeed blurs your intent.

  • A “like” is a message to the original post’s author (and a bookmark for yourself).
  • A retweet or share is a message to your friends or followers.

Putting them in your followers’ feeds turns a “like” into a message to them as well, even though it’s not what you intended. (If you wanted to share it, you would have shared it, right?) It’s a step above completely frictionless sharing, but it still messes with the signal/noise ratio of the timeline.

The cost of implementing HTTPS on your own site is a lot lower now than it used to be. For instance:

  • Let’s Encrypt offers free certificates for any site, and some web hosts have software integration that make ordering, verifying and installing a certificate as simple as checking a box and clicking a button. (I’m impressed with DreamHost. I turned on secure hosting for some of my smaller sites a few months ago by just clicking a checkbox. It generated and installed the certs within minutes, and it’s been renewing them automatically ever since.)
  • Amazon now has a certificate manager you can use for CloudFront and other AWS services that’s free (as long as you don’t need static IP addresses, anyway) and only takes a few minutes to set up.
  • CloudFlare is offering universal HTTPS even on its free tier. You still need a cert to encrypt the connection between your site and CloudFlare to do it properly, but they offer their own free certs for that. They’ll also let you use a self-signed certificate on the back end if you want. (It’s still not perfect because it’s end-to-Cloudfront-to-End instead of end-to-end, but it’s better than plaintext.)

You may not need a unique IP address anymore. Server Name Indication (SNI) enables HTTPS to work with multiple sites on the same IP address, and support is finally widespread enough to use in most cases. (Unless you need to support IE6 on Windows XP, or really old Android devices.)

Now, if you want the certificate to validate your business/organization, or need compatibility with older systems, you may still want to buy a certificate from a commercial provider. (The free options above only validate whether you control the domain.) And depending on your host, or your chosen software stack if you’re running your own server, you may still have to go through the process of generating a request, buying the cert and going through the validation process, and installing the cert.

But if all you want to do is make sure that your data, and your users’ data, can’t be intercepted or altered in transit when connecting to reasonably modern (2010+) software and devices, it’s a lot less pain than it was even a year ago.

The hard part: Updating all your old links and embedded content. (This is why I’m still working on converting Speed Force and the rest of hyperborea.org in my spare time, though this blog is finally 100% HTTPS.)

And of course dealing with third-party sources. If you connect to someone else’s site, or to an appliance that you don’t control, you have to convince them to update. That can certainly be a challenge.

Expanded from a comment on Apple: iOS to Require HTTPS for Apps by January at Naked Security.

Infinite scroll is like finishing a sandwich, and the server plops another one in front of you without asking what you want on it, or if you want it at all. If you’re full, or you don’t like what they chose? Too bad, it’s on your plate now! To make matters worse, sometimes if you put the sandwich down for a moment to eat some chips, they’ll think you’re done and swap your sandwich for a different one!

Slate just replaced pagination with infinite scroll on their articles. Yes, pagination sucks. A multi-page article on the web is like a burger that’s been sliced up into wedges, and you only get one wedge at a time, forcing you to go back to the counter every few bites. But infinite scroll isn’t an improvement.

Both approaches impose the wrong structure on a single unit. Search results and timelines are one thing, but for an individual piece of content, the best way to map it to a web page…is to just map it to a web page.

Update (Sep 2016): Combined with giant images and complex layouts that slow down browser rendering (*cough* CBR), it’s even worse. To continue the lunch analogy:

  1. You order a sandwich with a cup of soup and a side salad.
  2. After an interminable wait, you get the sandwich and soup, but no salad, and no spoon. The waiter rushes off before you can say anything.
  3. Eventually you’re able to flag someone down and ask for the spoon and the salad.
  4. You munch on the sandwich by itself, which is at least a decent sandwich.
  5. Finally the waiter comes back with a whole pizza, and takes away your half-eaten sandwich.
  6. You still don’t have a spoon, but that doesn’t matter because the waiter took the soup too.