Monthly Archives: November 2015

Stars vs. hearts and Twitter’s decline

In an essay about Twitter written in 2014, Ben Thompson described why he believed in the service:

“I think this actually gets to the problem with Twitter: the initial concept was so good, and so perfectly fit such a large market, that they never needed to go through the process of achieving product market fit. It just happened, and they’ve been riding that match for going on eight years.”

I’ve always thought the same thing. That Twitter started out so good, with such strong core features, that those basic features have carried it through all the years of missteps and inaction. But it’s not just that the features are “good” (although they are); it’s that they are unique.

Listening to the Connected podcast the other day, Federico Viticci and Myke Hurley made the statement that only nerds care about Twitter changing stars to hearts, favorites to likes. I was nodding in agreement until I talked to my daughter. She also didn’t understand why they would change away from stars, and she’s been on Twitter less than a year.

It’s not just nerds. Many new Twitter users recognize the subtle difference implied with hearts. But I realized that there’s something even more important about what this change says. Why is my daughter even on Twitter, in addition to Snapchat, Instagram, Facebook, and Vine? Because — even if most people can’t pin down exactly what makes it special — everyone knows Twitter is different and interesting.

All Twitter has going for it is its uniqueness. The timeline user experience, the retweets and favorites, the hashtag, and the short 140 character posts. Changing any of those key strengths to be just like every other social network means they’re watering down their own potential impact. Eventually that approach will produce a bland product that has no unique qualities.

We’ve already seen the timeline experience significantly altered. Promoted tweets, “while you were away”, inline conversation threads, and Twitter cards. Twitter in 2015 looks a lot more like Facebook than it did a few years ago, to everyone not using third-party Twitter apps.

Growing the user base is fine. But making Twitter more accessible to new users won’t do any good if you lose the much larger base of passionate users who have loved the product for years because it’s unique. You’re not going to beat Facebook by becoming even more like Facebook. If that’s Twitter’s strategy, then the service is already in decline.

Going to drive downtown for lunch and a meeting today, so ready to queue up the first episode of Under the Radar, a new developer podcast from Marco Arment and David Smith. Looks great.

→ 2015/11/04 9:31 am

Changing stars to hearts seems like something to do when you’ve run out of new ideas. Maybe Jack Dorsey’s first misstep.

→ 2015/11/03 2:13 pm

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.

Accelerated Mobile Pages from Google

The project technical overview for AMP has the goals and basic info. In a nutshell, the new format encourages a return to more bare-bones HTML, with some added functionality for common web patterns. On the balance between bloated ad platforms and user experience:

“Embedding an ad or analytics often implies giving up control of what eventually happens to a site because they can typically inject any JavaScript they want into pages. AMP HTML does not allow this. We realize that both ads and analytics are an important element of monetization on the web, and so we need to support them: our goal is to realign monetization with great user experience.”

Instead, “tracking pixels” are used for analytics. These should be easily skipped by ad blockers, but apps that support AMP will need to use a custom web view anyway, where ad blockers on iOS aren’t allowed. This may continue to limit the appeal of Safari View Controller.

Wired covers the announcement and describes how AMP might be integrated into Twitter and other native apps:

“One surprise beneficiary of AMP may be Twitter. While it’s not a publisher per se, it’s becoming an increasingly important player in news, most recently with the launch of its Moments feature, which makes news easier to follow on Twitter by organizing Tweets in a chronological, coherent timeline. Now, Twitter will automatically load any articles that are compatible with AMP as AMP files, meaning they will benefit from the same speed inside the Twitter app.”

There’s more on GitHub. On the surface this seems like a more open approach than Facebook Instant Articles or maybe even Apple News Format (which is finally public). That WordPress is supporting AMP is a good sign.