Category Archives: Weblogs

Micropub and the quiet IndieWebCamp revolution

There’s new activity at the W3C around independent blogging, with new proposals recently posted as working drafts. Helped by a push from the IndieWebCamp, two of the highlights include:

  • Micropub: Simple format for adding content to your site from native apps.
  • Webmention: Modern replacement for Pingback/Trackback, for handling cross-site replies.

I want to support these in my new web app. At launch, I hope to allow Micropub POSTs alongside the classic XML-RPC Blogger API (and my own native JSON API).

And of course the IndieWebCamp is also known for POSSE: publish on your own site, syndicate elsewhere. That strategy has helped me refine my own cross-posting.

I don’t think it’s my imagination that more and more people are blogging again. Now’s the time to resume your blog, start a microblog, and take back the future of the web from silos. If we can roll some of these new standards into what we’re building and writing about, the open web will be on the right track.

Inline links in microblog posts

When I was first trying to figure out how my microblog posts should look, I was thinking more like tweets and less like HTML. Eventually I settled on HTML for publishing and display, with Markdown for writing.

Here’s what a microblog post looks like in the timeline for my new web app:

screenshot

You can compare that to how it looks when cross-posted to Twitter. It’s not exactly a fair comparison since the tweet was truncated, but it’s still incredible to me how much better these posts look if you allow inline links and some more characters.

Tim Cook, Swift, and the return of blogs

Rob Rhyne wrote an essay last week that caught my attention, on Tim Cook and the incredible pace of new major OS versions at Apple:

“Still think Apple isn’t innovating enough under Tim Cook? Don’t let an app developer hear that talk—they want a vacation, and the end of 2015 showed no signs of relief.”

But I found it significant for another reason too: Rob hadn’t blogged on that site in over 2 years. He picked it up as if no time had been lost, hitting the ground running with a great post.

He’s not the only one starting to blog more. Matt Gallagher just rebooted Cocoa with Love after 4 years since his last post. Swift was a good excuse to resume writing, but he had wanted to continue the site anyway.

Most of my favorite blogs have new posts every day, or at least once a week. New posts bring more links and traffic, giving the blog life and momentum.

There’s no single correct way to blog, though. Blogs are forgiving. If you’ve neglected your blog for a while, you don’t owe anyone an apology. Just hit command-N in your favorite text editor and start writing.

Long-form writing as a filter

Soroush Khanlou, looking for more new blogs to read, makes a great point that the process of blogging leads to better writing:

“Opening my RSS reading and finding 30 unread items makes me happy. Opening Twitter and seeing 150 new tweets feels like work. I’m not sure why that is. I think Twitter has become more negative, and the ease of posting quick bursts makes posting negative stuff easy. With blogging, writing something long requires time, words, and an argument. Even the passing thought of ‘should I post this’ creates a filter that lets only better stuff through.”

I think there’s something to that. It’s often only after writing our thoughts down that we fully understand how we feel about a topic.

And here’s where I bring this back to microblogging. Because when starting a post, we don’t always know whether it will be long or short. How often have you seen a series of tweets that in hindsight even the author would agree should have been a blog post?

This is less of a problem if instead of tweeting you start out with the intention of posting to your own site. Short post can stay short, and posts requiring more words can naturally expand to a full essay.

I don’t think that our short-form, seemingly unimportant writing should exclusively be on centralized networks. If it’s worth the time to write something — whether a thoughtful essay or a fleeting one-off microblog post — then it’s worth owning and publishing at your own domain name.

Here’s a Twitter feed

Whenever someone says “I don’t read RSS”, I actually hear “I don’t read Manton’s blog”. I could give plenty of reasons why they’re missing out by ignoring RSS — it’s still the best way to keep up with bloggers you like who aren’t linked or retweeted often enough to bubble up on Twitter — but some people won’t be convinced.

Over three years ago I stopped posting to Twitter. I know it was the right move on principle because there was a real cost in exposure, with fewer people actively keeping up with what I’ve been working on. As I’ve said before: it wouldn’t mean anything if it didn’t cost me anything.

And yet, many people get their news from Twitter. Since I started microblogging on my own site, I’ve had time to reflect on the role of indie microblogging and cross-posting. I think the IndieWebCamp has it right: publish on your own site, syndicate elsewhere. I wrote more back in July about cross-posting.

Most importantly, as I work on a microblog publishing platform of my own, how can I develop a solid cross-posting feature if I don’t actively use it myself? I’ve recommended IFTTT to beta testers, but only by using it myself can I know where the gaps in functionality are.

So I’ve been experimenting. All of my posts now go out to the Twitter account @manton2. This was an account I created 6 years ago for testing. Except for a few of the first tweets, I’ve cleared out the test content and given it a new life.

It’s worth noting some advantages and disadvantages to this:

  • I can write at my domain name and own my content, but have it automatically sent to Twitter for folks who are there. Unlike how I’ve been treating these cross-posts to App.net, I’m not sure whether I will stay engaged and answer replies on Twitter. We’ll see.
  • Most of my microblog posts are around 200 characters. These will get truncated on Twitter, with a link back to my site. Full essays get a nicer title and link. I’ll continue to improve this.
  • I’m effectively starting over with zero followers, compared to the 5000 followers I left @manton with. I have no plans to resume using my original account, though. Think of the “2” in @manton2 as a reminder that this is a mirror of my posts, and an imperfect one.

You can follow @manton2 on Twitter. Thanks for reading.

Silos as shortcuts

As a follow-up on Twitter and links, I want to point to this great post from Rian Van Der Merwe about platform silos as “shortcuts”:

“The point is that publishing on Medium and Twitter and Facebook gives you an immediate shortcut to a huge audience, but of course those companies’ interests are in themselves, not in building your audience, so it’s very easy for them to change things around in a way that totally screws you over (remember Zynga? Yeah, me either).”

My current thinking on Medium is that it’s a shortcut to building an audience for a single post, but doesn’t really help build a true audience. In other words, you will get more exposure, and maybe one of your posts will be lucky enough to be recommended and included in Medium’s daily email, but after someone finds it they aren’t as likely to read your other posts and subscribe to your entire site.

We can’t talk about silos like Twitter and Medium without talking about cross-posting. Noah Read says:

“While it is relatively easy to post to a blog, syndicating that content to Twitter, Facebook, or Medium still requires additional configuration, which many users won’t do. I think it would be in blogging software’s interest to make these POSSE features a standard part of their core product. In order for the open web to not lose ground, ironically they will need to play nicer with closed platforms than they are likely to receive in return.”

I’ve been thinking a lot about this too. For beta users of my new product, I’ve been telling people to use IFTTT to wire up cross-posting to Twitter. But that’s another step that will be confusing to people — an opportunity to lose interest and give up. Cross-posting should be a core feature.

Twitter and the cost of links

Federico Viticci covers the news that Twitter will expand from 140 characters to 10,000, nicknaming the feature Twitter Notes. His nickname is appropriate given this latest transformation to become more like Facebook, since Facebook’s Medium-like capability for long posts is also called Facebook Notes.

The tweets and blog commentary on this have really missed a key aspect and cause for concern, though. Many posts – including even my own first attempt – have focused on whether Twitter Notes would water down Twitter’s unique strength. They then conclude that it’s better to include a long-form text feature rather than the compromise hack of screenshot text and tweetstorms. Federico sums up this endorsement with the following:

“Unlike other recent additions to the service, I want to believe that third-party developers will be able to support the feature in their clients (Jack seems to suggest as much) and that the iPad won’t be left behind again. I may be disappointed when the day comes, but if done right (see Matthew’s points here) and as long as Twitter Notes are intended as attachments for regular tweets with real text, I don’t see why I would be against them.”

Here’s why this matters, and it gets back to my post last week about the hyperlink. Closed platforms want to trap all activity, not send it out. The danger in Twitter Notes isn’t that they will replace textshots, it’s that they will replace external blogs.

For all of Twitter’s problems, at least right now most of the good writing we see on Twitter is actually linked out to external blogs (and yes, increasingly Medium posts). To shift that to be stored more on Twitter itself would be a setback for the open web. It would slowly train a new generation of timeline surfers to prefer Twitter-hosted content instead of blogs.

I wrote the above in draft form, and then later saw Ben Thompson’s daily update about the Twitter news. His take is the first I had seen that directly covered the issues of linking, even suggesting that no one really clicks on links anymore. But while he’s worried about Twitter from a business standpoint, I’m more worried about the attack on the web.

Ben also mentioned the clever trick Jack Dorsey used in writing his response as a textshot. Daniel Jalkut pointed out the same thing in the latest Core Intuition. Jack could have posted it to a blog, or to Medium, but he deliberately picked the worst way to work around Twitter’s current 140-character limit, to underscore his point.

Now, Will Oremus writes for Slate about the potential new Twitter walled garden:

“What’s really changing here, then, is not the length of the tweet. It’s where that link at the bottom takes you when you click on it—or, rather, where it doesn’t take you. Instead of funneling traffic to blogs, news sites, and other sites around the Web, the ‘read more’ button will keep you playing in Twitter’s own garden.”

I know we can’t rewind the clock to the heyday of the blogosphere. But we can still do more. More to encourage bloggers, more to spread awareness about how the web is supposed to work, and more to value open APIs. I think it starts with 2 things:

  • Build tools for independent microblogging, to make blogging just as easy as tweeting. I’m trying to do this.
  • Make the web faster, so the cost of clicking on a link goes down. Google’s helping this with AMP.

I was encouraged when I saw that Known had added support for AMP. They have their doubts about AMP, but at least they were quick to try it. From the Known blog:

“We’ve shipped support for AMP because we see potential here, and recognize that something should be done to improve the experience of loading independently-published content on the web. But attempting to bake certain businesses into a web standard is a malformed idea that is doomed to fail. If this is not corrected in future versions of the specification, we will withdraw support.”

Maybe AMP ends up being too ad-friendly to become a good standard. I don’t know. But if so, we’ll move to the next idea, because the web has to be faster. Slow pages are like a disease for links.

Anyone with a blog should be concerned about what could happen with Twitter’s 10,000-character push. We won’t feel the effects right away, but years from now it will matter. We should do more not just to promote blogs and writing on the open web, but to also make it easier for Twitter alternatives to exist through independent microblogging.

Dave on short blog posts

Dave Winer gives 3 reasons why you should be posting short items to your blog, including:

“Maybe your blogging software doesn’t support short items? Don’t worry, if people post more short items the software will adjust.”

I’m counting on this. I have a separate RSS feed for microblog posts, and it doesn’t look great in some news readers because the title is blank. Some folks have asked whether I should include a fake title there — the first few words of the post, or a timestamp. But the RSS spec is clear that title is optional. Only by breaking things a little will RSS readers improve to gracefully support title-less short posts.

WordPress drafts workflow

Since moving to WordPress, I haven’t changed much with how I write blog posts. But there are more tools available now, so I thought I’d revisit my workflow.

The key is being able to work on a blog post from any device and any text editor. I have a Notes folder on Dropbox that I use for draft blog posts and notes about other projects. When I have an idea for a post, I create a new note there and either start writing it, or leave a link, quoted text, or a few topic ideas to come back to later.

On the iPhone, I use Editorial. On the iPad, I use Byword, since Editorial hasn’t been updated for the iPad Pro yet. And on my Mac, I use Justnotes. All of these sync from the same Dropbox folder. They are plain text files, so I can edit from anywhere and they’ll survive platform and hosting changes over the years.

If I’m on my Mac, when I finish a post I’ll preview it in Marked and then copy it into MarsEdit for posting. On iOS, I’ll copy it into the WordPress iOS app. For microblog posts from iOS, I use an unreleased iPhone app that’s part of the microblogging stuff I’ve been working on.

I’ve also been using the Calypso-based WordPress UI a lot lately. I usually work on several blog posts at once, and if a few are ready to go at once, I schedule them to go out later in the day or over the next couple of days. WordPress’s web UI makes keeping track of scheduled posts pretty nice.

It hasn’t been all perfect switching between multiple apps, though. I noticed today that some of my new posts, which I always write in Markdown, were converted to HTML for publishing (likely by Calypso on WordPress.com). But for the most part, no regrets switching over to WordPress. The added flexibility and future-proofing have been good.

Hyperlinks and saving the web

Hossein Derakhshan spent 6 years in jail in Iran because of his blog. Now, with the clarity of seeing years of changes to the web and social networks all at once after his release, he’s written an important essay on the value of hyperlinks and the open web:

“When a powerful website – say Google or Facebook – gazes at, or links to, another webpage, it doesn’t just connect it , it brings it into existence; gives it life. Without this empowering gaze, your web page doesn’t breathe. No matter how many links you have placed in a webpage, unless somebody is looking at it, it is actually both dead and blind, and therefore incapable of transferring power to any outside web page.”

He mentions apps like Instagram, which have no way to link to the outside world. Too many apps are exactly like this: more interested in capturing eyeballs for ads than opening up their platform. The default for native mobile apps is to become silos, while the default for web sites is to be open and support linking.

There’s a second part to Hossein’s essay that I don’t agree with, though. He writes that “the stream” – a.k.a the timeline, a reverse-chronological list of short posts or links – is turning the web into television. But I think there’s a lot we can learn from the timeline. It’s a valuable user experience metaphor that we should take back from Twitter and social networks.

Building on the timeline is basically the whole point of my microblogging project. We should encourage independent microblogs by using a timeline interface to make them more useful. (Interested? Sign up on my announce list.)

Back to links. Dave Winer, who has been cross-posting recently to Facebook and Medium, posted about how Facebook doesn’t allow inline links in the text of a post. As a new generation grows up on these kind of posts instead of real blog posts, will people understand what they’re missing? Dave writes:

“I hope we don’t end up having to try to explain linking to future generations who have no recollection of an electronic writing environment where words could take you to a whole other place. But I suspect we’re going there. Unless somehow we can get Facebook to relent and make it easy to link from words in Facebook posts to other places on the web.”

This is a great challenge for 2016. Not specifically with Facebook, but with the larger idea of bringing back the web we lost, retrofitted for today’s app-centric internet. I hope to spend a good part of the year working on it.

ESPN sidebar microblog

I like what ESPN is doing in the sidebar on their NBA scores page. It’s a timeline of both tweets and short ESPN posts, integrated together with a clean design that fits the rest of the site.

This timeline is a great use of microblogging. The short posts aren’t limited to tweet-length — they’re often around 200 characters instead — so they can feel complete and informative while still being concise. I’ve suggested 280 characters as a guideline for microblogs, and having the extra characters to work with really makes a nice difference.

I took an example screenshot from ESPN and included it to the right of this post. The first two posts are these special ESPN microblog posts, and the third is a tweet. I don’t know what CMS-like system is driving this, but you can imagine using WordPress post formats, custom fields, or categories to achieve something similar.

WordPress podcast and Calypso

I’ve become quite the fan of WordPress and Automattic over the last year, since finally switching. WordPress still has some problems — mostly in self-hosted web admin performance, and the clunkiness of editing themes — but Automattic is a good company. Around web publishing and hosting, I think 2 platforms are going to last for decades: GitHub and WordPress.

There’s a great interview with Automattic founder Matt Mullenweg on the Post Status podcast:

“I had the opportunity to interview Matt Mullenweg about an ambitious project that included more than a year and a half of development to create an all new WordPress.com interface, both for the web and a desktop app. The project was codenamed Calypso, and we talked about many aspects of Calypso, as well as a variety of subjects that relate to it.”

After listening to this episode, I’ve subscribed to the podcast. Looking forward to being a little more aware of what is going on in the WordPress community.

A diverse community through writing

I read a lot of weblogs. RSS is a great way to keep up with sites that update infrequently, or that aren’t popular enough to bubble up on Twitter with dozens of retweets. But the Mac and iOS community has grown so much over the years. I know there are many new writers who haven’t been on my radar yet.

Brent Simmons has posted a great list of tech blogs by women that I’m going through now. There should be something there for anyone interested in development or design:

“I made a list of some blogs I already knew about, and then I asked my friends for more, and they totally came through.”

The list grew to include over 50 blogs as suggestions arrived to Brent via Twitter. I’ve already subscribed to a bunch and look forward to discovering even more.

One of my favorite new blogs is the travel blog complement to Natasha The Robot, which made Brent’s list. Natasha was recently hired at Basecamp, runs the This Week in Swift newsletter, and writes on her new blog about working remotely. From a post about taking her laptop to restaurants in Europe:

“The nice thing about this is that I get a really cool and inspiring office for a few hours – each cafe or restaurant has it’s own vibe, people, music and I don’t feel rushed internally knowing that I need to go back to my apartment or coworking space to actually work.”

When I quit my day job this year, it was partly so we could travel more without worrying too much about my work schedule, outside of when the kids are in school. In fact, just days after I finished writing my two weeks notice blog posts, we went to Europe and started a private family blog about the trip. So I’ve been inspired by Natasha’s blog as she shares her experience working in different cities.

And that’s a theme you’ll find in many of the developer-oriented blogs on Brent’s list. Wanting to get better, learning something new, and then sharing it with everyone else. Take this advice from Becky Hansmeyer, who wrote a daily series of posts about what she learned building her iPhone app, one post each day while she waited for her app to be approved by Apple. From day 4, on design and color:

“I think the biggest thing I learned in choosing colors and fonts for my app is not to get too hung up in making comparisons to other apps. I spent a lot of time looking at my favorite apps like Overcast and Tweetbot and thinking about the decisions the developers made, and as a result I wound up feeling like I had to make those same decisions. But that was stupid because my app is my own and is also designed for a much smaller market.”

Or this quote from Kristina Thai, who wrote a post about preparing to give a talk for the first time:

“My presentation didn’t flow, it was jagged and very rough around the edges, but I kept at it, made some changes and it got better. And better. And even better. And then I practiced it in front of a couple of friends who gave me even more feedback until I was ready.”

Kristina also gave a talk called Become a Better Engineer Through Writing. You can get a sense of the talk by downloading the slides. It covers the value to programmers in keeping a private journal, why you might write tutorials for your site, and makes a strong case for blogging.

Blogging isn’t difficult, but it’s still not yet as easy as tweeting. By creating a blog, you’re making a statement that you care about something. As I go through Brent’s list of bloggers, that’s what I’m looking for: what does the author care about, and what can I learn from or be inspired by in their writing? Because the more diverse our RSS subscriptions are — the more varied the opinions in what we read and share with others — the closer it gets us to a strong, healthy community.

Blips microblog

Jussi Pekonen has relaunched his weblog, with a new focus on microblogging:

“I want to own all content I produce. That way I can ensure that everything I write does not go the way of the dodo when the latest and coolest microblogging platform goes belly up.”

He calls the short posts “blips”. I call mine snippets, which I borrowed from Noah Read. I like both names, but even more importantly, I like Jussi’s approach to owning his own content and providing a simple RSS feed of microblog posts. (I wrote more about RSS and microblogs a couple weeks ago.)

RSS for microblogs

RSS is solid. It’s lasted a long time with very few changes, and forms the foundation for subscribing to weblogs and delivering podcasts. It’s huge and the open web is a much better place because RSS exists.

But even if RSS doesn’t need to change, some types of apps would be better off if we took a fresh look at the elements in an RSS feed. What is really needed, and when faced with multiple “correct” options, which should we choose? As more writers embrace microblogging, it’s an opportunity to simplify our feeds and tools.

This is my proposal for a bit of housekeeping around microblogging. It’s not a new format. It’s just a guide for producing the best RSS. I’d divided this proposal into 5 sections below.

Minimum viable elements

Look at the average RSS feed and there’s a lot of junk in it that most RSS readers ignore. While there’s nothing wrong with including extra XML elements, we should strive for a feed that is simple enough to be easily read. The fewer redundant and unused elements, the more consistently that different RSS readers will interpret it.

Here’s an example of an RSS feed whittled down to its essential elements. Most feeds should look like this by default, and only add additional elements from the RSS spec or RSS extensions when it’s absolutely required (such as the enclosure element for podcasting).

<rss version="2.0">
    <channel>
        <title>Manton Reece</title>
        <description>Manton's weblog.</description>
        <link>http://www.manton.org/</title>
        <item>
            <title></title>
            <description><![CDATA[
                <p>Hello world.</p>
            ]]</description>
            <pubDate>Fri, 04 Sep 2015 15:32:32 +0000</pubDate>
            <guid isPermalink="true">http://www.manton.org/2015/09/3007.html</guid>
            <link>http://www.manton.org/2015/09/3007.html</link>
            <author>@manton</author>
        </item>
        <item>
            ...
        </item>
    </channel>
</rss>

Title is optional

The existing RSS spec says that title is optional. In fact, in the early days of blogging, tools such as Radio Userland and Blogger didn’t even have titles. We got away from that with the popularity of Movable Type and WordPress, even though some modern apps like Tumblr still look at a title as unnecessary for certain post types.

With microblogging, the title will frequently be empty or missing. Do tweets have titles? No, and neither should short microblog posts published through a traditional blog platform. Skipping the title removes some friction in the writing process, making it easier to write a quick post and send it out.

RSS readers must be prepared for a title-less RSS item. Instead of inserting “Untitled” as the placeholder title, think about how your reading UI can accommodate microblog posts gracefully. Blank titles (where the title exists but is an empty string) are equivalent to a completely missing title element.

HTML post text

The description XML element in RSS wasn’t originally intended to support HTML. It was often a text summary or opening paragraph of an article, rather than full text. With microblogging, you always want the full text inside the RSS feed, including any styled text or inline HTML links.

Some feeds will include the plain text version of a post in the description element, and the HTML version in a content:encoded element, as specified by this RSS namespace extension. This should be avoided in favor of a single description element with the full HTML, using CDATA syntax to avoid escaping characters.

In modern apps, rendering simple HTML is common. If an RSS reader can’t show HTML, it should strip out the HTML tags itself. It’s not up to the feed to provide multiple versions. If both description and content:encoded are present in a feed while parsing, for compatibility it’s acceptable to prefer whichever includes HTML.

JSON

I said this isn’t a new format, but we should have the option of expressing RSS in JSON instead of XML format. Back in 2012, Dave Winer wrote about producing a JSON-based RSS feed, with a very literal mapping of elements. If our goal is to cleanup some of the edge cases of RSS, though, we can further simplify it. I’d suggest collapsing a few of the elements, so that it isn’t overly nested like XML, and to JSON-ify the item elements into a simple items array:

{
    "channel": {
        "title": "Manton Reece",
        "description": "Manton's weblog."
        "link": "http://www.manton.org/"
    },
    "items": [
        {
            "title": "",
            "description": "<p>Hello world.</p>",
            "pubDate": "Fri, 04 Sep 2015 15:32:32 +0000",
            "guid": "http://www.manton.org/2015/09/3007.html",
            "link": "http://www.manton.org/2015/09/3007.html",
            "author": "@manton"
        }
    ]
}

This preserves the element names and overall feel of RSS, while being cleaner and more JSON-like. Note that it’s easy to embed HTML directly in the JSON description field. Because there’s no room for an isPermalink attribute, if the guid is a URL, it is always the permalink.

Authors

A feed for a microblog platform, or a group weblog, might include multiple items each from different authors. The RSS spec says that the XML “author” element is an email address, but that is very rarely used in real feeds.

Instead, the author element value should vary slightly from the original specification to include either a simple full name, or a username prefixed with the @-sign: <author>Manton Reece</author> or <author>@manton</author>.

What do you think? I’d love to hear any feedback via email. If you write on your own blog about this, send me the link.

The now page

Last week, Derek Sivers had a great idea. We’re constantly writing about the things we care about and whatever we’re working on, but the nature of blogs is that posts are always falling off the home page. There’s rarely a single place to get the tl;dr summary of what someone is working on.

This idea hit home for me last week at Release Notes when several people asked how to sign up on my microblog project announcement list. I’ve linked to it several times in blog posts, but I didn’t have an easy place to point people to without asking them to dig through the archives. A /now page is the perfect place for that kind of thing.

Shawn Blanc linked to his page too, which reminded me to put my own /now page together. You can read mine here: manton.org/now.

Medium.com updates

Ev Williams announced a batch of new Medium features recently:

“There’s always another level. Another level of polish and power in our product. Another level of breadth to our content. Another level of dialogue and discussion. And another level of progress. Today, we are announcing a slew of updates to bring Medium to the next level and in the process make it more powerful, more fun, more democratic, and more essential.”

Those updates include new mobile apps, @-mention support, a publishing API, and editor improvements. There’s also a new logo. (I know they put a lot of thought into this, and it’s a strong idea, but to me the logo’s design is so clever it’s actually kind of distracting. A little more subtlety in how they’re using depth could improve future iterations.)

Daniel Jalkut blogs about what’s included (and what’s left out) in Medium’s new API:

“One of the most unique aspects to Medium’s API is the provision for specifying a canonical URL and license on a post being submitted to the service. The canonical URL refers to another web location that should be considered the original, or most authoritative version of a post, while the license designates whether the post’s copyright terms stipulate a post is sharable as public domain or under a particular Creative Commons license. These attributes together indicate that Medium expects and encourages users of the API to contribute content that is not intended to be exclusive to Medium.”

While I generally think the trend to centralized writing platforms is bad for the web, I’m happy to see these changes from Medium, especially the API and expanding custom domain support. Medium has grown very slowly and carefully. I expect we’ll see quicker iteration on these new features now that they’re officially out.

In the process of experimenting with Medium posting, Dave Winer shared his take on post title support:

“It seems they have arrived at what I think is the correct answer: posts can have titles or not, and the content system has to be prepared for either case. That’s where this blog was in 1999, before other blogging tools and Google Reader pushed the world toward requiring titles. And then Twitter came along not having titles at all, and the intersection between all the kinds of blog-consuming environments became almost empty.”

I’m very interested in this because microblogging shouldn’t include titles. While Medium is mostly traditional essays, clearly comments don’t need titles, and Medium’s quick-posting UI encourages short posts. I hope this approach will get more RSS readers to gracefully handle title-less posts.

Complete mirror of this blog

I’ve been blogging here for 13 years. If you take any random post from that first year, the majority of the links to other web sites are broken. The default outcome for any site that isn’t maintained — including the one you’re reading right now — is for it to vanish. Permanence doesn’t exist on the web.

We can solve this, but it will take time. For now I think mirroring our writing is a great solution, to guard against domain names expiring and other inevitable failures. But where to mirror to?

Only 2 companies keep coming to mind: WordPress.com and GitHub. I believe both will last for decades, maybe even 100 years, and both embrace the open web in a way that most other centralized web sites do not.

Even though I self-host this weblog on WordPress, I’ve chosen to mirror to GitHub because of their focus on simple, static publishing via GitHub Pages. It has the best chance of running for a long time without intervention.

I exported all of manton.org with the httrack command-line tool and checked it into GitHub, with a CNAME for mirror.manton.org. It works perfectly. I still need to automate this process so that it updates regularly, but I’m very happy to finally have a complete mirror for the first time.

Wrap-up thoughts on the TV web

I’m going to mostly let John Gruber have the last word on the Apple TV vs. the web debate, because I could write about this every day and my readers would run away before I run out of material. I’m glad John addressed the Mac vs. the command-line argument, though, because it didn’t seem quite right to me either. He says:

“The difference is that the command-line-less Mac was intended to replace command-line-based computers. The GUI relegated the command-line interface to a permanent tiny niche. Apple TV and Apple Watch aren’t like that at all — they’re not meant to replace any device you already use to access the open web.”

This is the most hopeful part of the Apple ecosystem as it relates to the web. Apple’s other platforms really do have a great web experience. Remember when web sites were faster and worked better on a PC than a Mac? If anything, the opposite is true now.

One of the themes I keep hearing is that a “web browser” on a TV will make for a poor user experience, so don’t bother. I tried to correct that misunderstanding in this post; it’s not about standalone Safari, it’s about web technologies that could be used in native apps. But ignoring that, I think everyone too easily forgets what the mobile web was like before the iPhone.

Steve Jobs, from the original iPhone introduction:

“We wanted the best web browser in the world on our phone. Not a baby web browser or a WAP browser — a real browser. […] It is the first fully usable HTML browser on a phone.”

That was a breakthrough. I believe the same evolution is possible on tvOS — to include parts of the open web and do it with a great user experience. You can start by weaving it together inside native apps. (I filed a bug with Apple yesterday with a suggestion. It was marked as a duplicate.)

The web is at a fascinating, pivotal time right now. It has been shaken up by centralized publishing, closed platforms, and now content blockers. Users no longer value the concepts that made Web 2.0 special. The web can still have a strong future, but we have to try something, and we have to try it on every platform we can.

The web without HTML

On Twitter, Alex Fajkowski responded to my blog post about tvOS with this:

“They have access to the open web—NSURLSession exists. HTML rendering is inappropriate for the watch and tv.”

I disagree with both of those sentences. Maybe Alex didn’t read my full post, because I wrote that web services are not enough. HTML and links and URLs are equally important parts of the open web. NSURLSession gets you web services but nothing else.

(As an aside, HTML turns out to be a pretty useful format for styling text, too. Why wouldn’t you want to use it for iTunes movie descriptions on the TV, for example? That seems completely appropriate.)

Think about the full scope of the internet. What percentage of content is available via web services — that is, structured data that can be parsed and displayed with a custom, native UI — compared to all the traditional, HTML-based web sites? You’ll find that there is an almost unimaginably large number of that latter kind of web site, and the only way to access and display that content is with an HTML renderer.

Now imagine a world with only native apps. You’d need custom apps and web services for different kinds of content, just as we have native Twitter or Instagram apps today, but we’d need these for many thousands of categories: tvOS with TVML, recipe or cooking apps with FOODML, and so on. Eventually, having so many formats would get unmanageable. We’d need to invent a general purpose format that could accommodate many app formats, and (surprise!) that general format would look a lot like HTML. Why break old content and essentially reboot the web, when we already have a capable format in HTML?

Of course, there’s no immediate risk of getting to that hypothetical native-only future. But when a company with the size and influence of Apple has 4 major platforms and only 2 of them have access to the open web, that should give us pause. Let’s reflect on how this plays out, so we can get back on track if the web does become marginalized.

John Gruber commented that these new devices don’t need the web at all, comparing it to the original Mac shipping without a command line interface. I realized while reading his closing paragraph that my own blog post had been poorly titled, and so the whole point too easily misunderstood. John wrote:

“Or it could be that Apple has decided never to open WebKit to developers on Apple TV. Either way, it won’t affect Apple TV’s success, and everything will be OK.”

Apple TV’s success doesn’t change my argument. My Apple TV dev kit arrives on Friday, I’m going to build an app for it, and I can’t wait to watch Apple’s latest platform take off. When I wrote that the Apple TV “needs” the web I didn’t mean that it would be crippled and unsuccessful without it. I simply meant that the web should be there in some form, even if limited.

(It doesn’t even have to be Safari. There just needs to be enough web technologies to make some part of the open web possible. Again, that means web services, HTML, and links.)

Yesterday, John Gruber also wrote about web apps and native apps, and what each should focus on:

“Native apps can’t out-web the web, and web apps should embrace that.”

That’s good advice. There are plenty of important tasks for the web community that should be top priorities, such as encouraging a return to independent publishing and trying to fix the lack of redundancy. The web will always be playing catch-up with native apps for user experience, but the web will always be ahead as a distributed, open publishing platform. And that is such an important feature, it should be available on as many devices as possible.