Werd I/O

Aaron Chimbel, over on PBS MediaShift:

At most universities, students are required to take English composition courses, and at many others speech and/or foreign language classes are also required. Yet in the debate about teaching code in journalism programs, code is often reduced to a shiny toy.

I've argued before that learning to code is not the same as being a coder, and that some degree of digital literacy is useful in a world that is slowly being eaten by software. Most recently, that was shown by the Silk Road trial, where a single investigator found the marketplace's founder using a simple Google search, two years into the investigation.

An understanding of how to put a live website together is handy. For a long time, I was a subscriber to the NICAR-L list, a mailing list full of journalists discussing computer-assisted reporting. It's often about things like embedding an OpenStreetMap map using Leaflet, or otherwise wiring up a simple dataset to a visualization. A little light JavaScript hacking, and perhaps some HTML and CSS.

It's actually pretty similar to the kinds of things Erin did when she visualized her Known checkins. (Known exports checkins as both KML and GeoRSS.) And while it's fun to do this kind of tinkering, and is quite a long way away from coding, I don't think it's good enough.

Journalists, and people like them, need better software, which makes these links more obvious. Taking location data from a platform like Known and bringing it into Google Maps or OpenStreetMap should be a one-click (or drag) operation. For us, that'll become more important later this year, when we release more data-centric tools. But it should be a given for everyone. You shouldn't need to know an arcane URL parameter, or understand that KML exists, to be able to manipulate your data in the way that you need.

We spend so much time talking about data that's locked in through business models and terms and conditions that sometimes we forget about data that's locked through design decisions. Letting your data flow freely is part of an open web.

Signing up for a service

30 seconds. And that 30 seconds includes initial customization: confirming your name and so on.

Installing something on a server

10 minutes. Ideally 5. Once again, that includes the initial customization: setting your site name in a Known instance, for example, uploading your profile photo, and choosing the theme. Tweaking the theme can take longer, of course.

Writing a plugin for an open source app

One hour to testing that you're on the right path, two hours to having an initial prototype fully working. This might be generous: it's possible that the bar for the "1 .. 2 .. 3 .. is this on ..?" testing phase is more like 10-15 minutes, and the prototype phase is an hour.

Implementing a web standard or format

One afternoon. RSS succeeded (at least for a while) because you can sit down after lunch to take a look at it blind, and have something working to show someone by mid-afternoon. I'm convinced this is true of HTML, too.

The indieweb technologies all also have this property: pick them up after lunch, do something with them by 3pm, and have something cool working by the time you go home.

Everything happens in a sitting

This also works with proprietary APIs. Twilio was wildly successful because using it was unbelievably straightforward - and it drove a lot of business for them. APIs are interfaces by definition, of course, and so are plugin hooks and format specs. These all have to be as simple and clear as possible.

Making things simple isn't dumbing them down; it's making them more useful. Nobody wants to spend time learning your technology or figuring out your service; they want to spend it on their own goals. The bar has to be that you can get to grips with something very quickly, so people can move onto what they were actually trying to do.

My love is like base64 encoding. Lossless and incomprehensible.

My love is like an alphanumeric URL variable. Easily escaped.

My love is like JPEG. It looks good at first but it's full of distortions.

My love is like GIF. Surprisingly hard to say out loud.

My love is like Prolog. Backwards.

My love is like git. My pull requests are often denied and rebasing is a mystery to me.

My love is like an unfixed bug. It just keeps escalating.

My love is like emacs. It's been around a long time and I guess I understand the attraction but, honestly, I think you should be looking elsewhere.

My love is like IPv4. Full.

My love is like TLS. A brief handshake and we're set.

My love is like an HTML document. Marked down.

My love is like XMPP. Noisy.

My love is like a legacy PHP function. It's hard to predict the parameters and it might yell some Hebrew at you for no reason.

My love is like an RSS reader. You've got to keep feeding it.

My love is like the web. This is for everyone.

As part of the Nieman Journalism Lab's Predictions for Journalism 2014, Jason Kottke writes:

Sometime in the past few years, the blog died. In 2014, people will finally notice. Sure, blogs still exist, many of them are excellent, and they will go on existing and being excellent for many years to come. But the function of the blog, the nebulous informational task we all agreed the blog was fulfilling for the past decade, is increasingly being handled by a growing number of disparate media forms that are blog-like but also decidedly not blogs.

He then goes on to discuss the death of the reverse-chronological stream, as well as the inevitable move to what he calls tightly-bound social media sites. Thematically, it's an interesting companion piece to Anil Dash's seminal The Web We Lost, which was published last year at about this time.

And, despite some hedging on his personal blog, it's clearly true. Almost none of you will have found this link through a feed reader (although my stats show that some of you are using Feedly, Digg Reader, and even Livejournal's RSS feature). Most links will have come through Twitter and Facebook, with a straggling number showing up through app.net and similar sites. If I'm lucky, someone might submit this post to an aggregator like Hacker News.

Note, though, that you're still reading it. The article isn't dying; you can think of the blog, or the stream, or the feed, as the container that the article sits in.

Medium exploits this in a clever way by presenting articles nicely, and then providing a magazine-style site for you to consume them in. Indieweb arguments about whether you should publish posts on a site that you control or on someone else's aside, there's no doubt that Medium's injected new life into long-form text on the web. That's great, and like Facebook and Twitter, you can choose to think of it as a well-executed proof of concept.

If you buy the idea that articles aren't dying - and anecdotally, I know I read as much as I ever did online - then a blog is simply the delivery mechanism. It's fine for that to die. Even welcome. In some ways, that death is due to the ease of use of the newer, siloed sites, and makes the way for new, different kinds of content consumption; innovation in delivery. Jason talks about the ephemerality of Snapchat (which is far from a traditional feed), and there are an infinity of other ways that content might be beamed to us on whichever device we happen to choose to be using at any particular moment. But these content forms are minor details.

The beauty of the independent web is that we can choose to represent ourselves online - and therefore, publish content - in a manner of our choosing. I happen to like the reverse-chronological feed, but if you prefer to publish in the form of an immersive 3D world, or a radio show, or full-screen autoplaying video with annotations, then, hey, that's up to you. It's all part of a rich, interlinking medium. Independence means not necessarily going with the flow.

The counterpart to that is how you read content. In the past, we've been very stream-heavy: RSS readers, Twitter feeds, Facebook timelines, and so on. But there's no need for that to be the case. Part of the joy of a diverse web is that while I might choose to read in the form of a feed or a newspaper, you might want to mash your reading list up in entirely new ways. You could have a robot announcer read to you while you drive to work in the morning (wouldn't that be better than the radio?), or mash related articles up to provide new kinds of content that provide better insight than the sum of their parts. And I can choose to use a completely different form to you. Each one of us can have a completely different experience.

That's a tough concept to get across to an audience that's used to mass media, where everyone consumes the same content in the same form. But we don't need that anymore. Not only can content be personalized, but the form of the content can be personalized. Facebook might agonize over the algorithm that decides which posts are surfaced, but in the future we can each have our own algorithms. Form and content will be separated.

These new kinds of readers will begin to appear in 2014, powered by simple web technologies like HTML and microformats. They will eventually be as easy to use as Twitter and Facebook. And they will make us all more empowered readers and creators, once again connecting us all, but this time on our terms.

This piece was submitted as a position paper for the W3C's Workshop on Social Standards: The Future of Business, due to be held on August 7-8, 2013, in San Francisco.

Really interoperable interoperability

Much has been written about both the power of APIs to connect social applications in powerful ways, and vendor lock-in in the context of those APIs. Rather than usher in a new era of interoperability and open computing, APIs have allowed vendors to create new ways to lock users into their ecosystems.

In many verticals, simply gaining access to a product’s API documentation is enough to require complicated licensing arrangements, vendor evaluation of your business intent for the API, and often, an asymmetric Non-Disclosure Agreement. “Open” is the new closed: too often, the API is a proprietary product in itself. This is as true in social software as it is elsewhere.

This proprietary nature carries multiple business risks. Not only does it require that customers invest heavily in a particular vendor’s products, but should that vendor subsequently decide to discontinue those products – as happened recently in the case of Google Reader and a number of Yahoo! products – the customer must repeat that investment in another platform. Finally, recent surveillance revelations must be food for thought for any business using proprietary services to host sensitive data.

Sophisticated open API standards mitigate these risks, but developing support for these can require a significant expenditure, and the business case may not yet be clear to most vendors. There is no doubt that they occupy an important place in the emerging social landscape, but not all vendors, or their customers, can justify the level of technical expense currently required to “buy in”. Indeed, given a high enough barrier to entry, even ostensibly open APIs may inadvertently have the same ill effects as closed ones.

Proving it

Although there have been significant advances in the field over the last five years, there remains a need to prove the business value of decentralized web technologies. To many of us involved in both the industry and the movement, this seems silly: after all, the business value of other decentralized technologies, like email and the phone system, are hardly questioned. Nonetheless, in a world where centralized data siloes regularly receive multi-billion-dollar valuations, the onus is on those of us who are building more open technologies to demonstrate their worth. Note, it is not enough to argue their worth: we must build, ship, and actively demonstrate a profitable product or service with a business model where the decentralized social web is an inextricable component.

I believe that these compelling business models exist, and that they are most easily discoverable in the enterprise. However, belief is not demonstration: we must continue to test and iterate them. During this exploration phase, this means that, our software and underlying protocols must be easy to write, adapt and change. Ease of development is more important than sophistication; we must not create our own technical lock-in before we even ship.

The IndieWeb

The “IndieWeb” movement was founded by Tantek Çelik, Amber Case and Aaron Parecki, around their annual IndieWebCamp event. Although it was originally created to encourage participants to self-host their own web presences (a laudable goal in itself), over the last year it has also begun to incubate a number of simple social web protocols based around Microformats 2 and Webmention.

At its simplest level, assets on the web are marked up with appropriate Microformats 2 classes, so that any parser may obtain a consistent JSON representation of their content. Linked targets on the page are then pinged using Webmention (or pingbacks), which alerts them to the presence of that content. They may then go back and parse the source of the ping, discovering content like comments, replies, event RSVPs and favorites. Adding more content types would be trivial, and indeed, more are emerging every week. If a content type is not registered, the target page may simply register that the source “mentioned” it.

An obvious further implementation incorporates signed HTTP requests for both parsing and Webmention pings, allowing for lightweight authentication so that protected resources can be selectively revealed.

The protocols and standards under development within the IndieWeb community offer some unique advantages for testing decentralized social models:

1. They piggyback on top of an open, decentralized system that everyone has already bought into: the web itself. Indeed, on the IndieWeb, where possible, the web is the API.
2. They are extremely simple to develop for, allowing you to concentrate on building well-designed tools that meet human use cases instead of building support for social protocols.
3. Social software need not be “monolithic”. Suites can be constructed out of small, compatible pieces, loosely joined.
4. Major search engines support Microformats, so marking pages up to be IndieWeb-compatible may also yield SEO benefits.
5. The IndieWeb community actively embraces participation in existing closed networks through a process called POSSE, minimizing the potential business impact for entities transitioning to a decentralized model.

POSSE - Publish (on your) Own Site, Syndicate Everywhere, as coined by Tantek Çelik – accepts that your friends, contacts or customers are easier to reach on the social platforms they’re already using. Therefore, content on your own, independently-hosted platforms syndicate out to your audience across the networks they already use; links point back to the originals. In the short term, it becomes immediately possible to experiment with decentralized social models without losing your existing audience. Over time, it may be possible to transition those audiences to consume and interact with your web presences in a more decentralized way, ensuring that you can post on your terms, and they can consume on theirs.

While most implementations of POSSE concentrate on consumer social tools like Twitter, Facebook, Flickr and Foursquare, there is no reason why the same principle could not be applied to commercial platforms like Yammer, Avid Interplay, GitHub, Salesforce or SocialText – or any proprietary service used internally inside any enterprise, APIs permitting.

Idno as an experimental testing ground

Idno is one embodiment of an IndieWeb-compatible open source platform that can be installed across many hosting environments. It was originally designed as a replacement for older open source networking platforms, but rapidly evolved into a testbed for many of the ideas the IndieWeb community was proposing.

At the time of writing, decentralized social web activities supported by Idno include:

• POSSE posts to Twitter, Facebook, Flickr and Foursquare, and replies on Twitter
• The ability to comment on, or reply to, a post (or multiple posts) on another IndieWeb-compatible site
• The ability to “like” a post on another IndieWeb-compatible site
• The ability to RSVP to events posted on other IndieWeb-compatible sites
• The ability to post content, including status updates, blog posts, bookmarks, photos, geographic “check-ins” and events that other people with IndieWeb-compatible sites may comment on, reply to, “like” or RSVP as appropriate

Due to its framework origins, Idno allows developers to easily build new post types. Indeed, support for events and RSVPs – at the time unsupported by any other IndieWeb-compatible software – were built in a single evening, with one developer, directly after an IndieWebCamp event. Other software produced by IndieWeb developers began to support events and RSVPs the next day. By the end of the week, at least three separate software platforms supported the content type. There is no doubt that the barrier to entry is low for individuals and businesses alike.

Conclusion

The rapid development that IndieWeb standards make possible is perfect for testing business models relating to the decentralized social web. This does not undermine the technologies and successes of the wider federated social web movement, or of other open social software projects; however, it does allow models to be tested much more quickly.

The relatively low barrier to entry of the IndieWeb also may encourage more developers to take part (as has already been shown), and as such, it seems likely that the standards that community is developing may find themselves in wide use for some time to come. An obvious analogy is RSS, which is not a sophisticated syndication standard, but saw widespread use due to its ease of implementation.

Many of the prevalent models for social software are hostile to the needs of both businesses and individual users. The IndieWeb aligns software developers with their users, while providing simpler tools for development, and encouraging both wider participation and more experimentation. I believe the result will be accelerated innovation in social software, and a much faster path to validating business models for the decentralized social web.

#indieweb #w3c #socialweb #business #idno

Syndicated to IndieNews

This site runs on idno: an open source social publishing platform that I've been working on for the past few months in my own time.

You may know that I co-founded Elgg, the open source social networking engine, which is used by the likes of Oxfam, NASA, the World Bank and several national governments as a social intranet and learning platform. The original thinking around Elgg happened a decade ago. Given that, you shouldn't be surprised to learn that my original thought experiment was: What decisions would I make if I was building Elgg today, in 2013? What would I do the same way, and what would I do differently?

Some technical decisions

I knew that I could make a faster social networking platform, with a better templating engine, and a much smaller codebase - even while sticking to PHP as an underlying scripting language. Partially that's because PHP 5.3+ is a much better development platform than earlier versions. It's also because there are now some well-tested, intelligent back-end frameworks, like Symfony 2, and front-end frameworks, like Bootstrap.

One of the major decisions I made when we built Elgg 1.0 was that not only was it a hassle for plugin developers to write their own database schemas - it was undesirable to the point of being dangerous. We effectively faked a NoSQL schema in MySQL by creating a data model around entities (first-class objects like users and blog posts), metadata, annotations and relationships. People were taken aback, and it was row-intensive, but it worked, and it continues to work today.

Nonetheless, today we have NoSQL, so #idno is based around MongoDB. This means there are far fewer database transactions involved - and adding new data to an object is incredibly easy. Together with a plugin architecture based on lazy loading, and Symfony's excellent observer pattern support, as well as the framework code I've built, I'm able to write a new plugin in an hour or two. That's important for a system I'm building in my spare time!

Meanwhile, all of the things about #Elgg that were great - a plugin architecture, granular access permissions - are intact. And on top of that there's a faster framework, and a responsive front-end that works really well in a mobile browser. Great!

But that's not the end of the story.

The #indieweb community has existed for years as a force to advance the state of the independent web, and to promote ownership of our own spaces. IndieWebCamp is an annual event for creators to discuss their platforms, technologies and ideas.

One of the big concepts to come out of #indieweb has been #POSSE: Publish (on your) Own Site, Share Everywhere. The idea is that your friends or followers shouldn't have to join your site to engage with you; you should be able to post on your own site and be read on Twitter, Facebook, Foursquare, or wherever they happen to be. idno has built-in plugins for status updates, blog posts, images, checkins and events. Correspondingly, it also has plugins to #POSSE this content to Twitter, Facebook, Foursquare and Flickr - and writing more would be trivial.

That's just as well, because I've committed to only post on my own site and copy to third parties (where that's possible).

Reinventing the social web

This year, though, something else happened. Using Microformats 2 (a way to very simply embed meaningful markup into any web page) together with Webmention (a way for any web page to lightly ping the pages it references), the community participants created the first indieweb decentralized comments thread.

Using nothing more than the markup on their own web pages and a very simple protocol, the participants created the basics of a decentralized social community, where each comment is hosted on its owner's own site, but nonetheless forms a coherent, easily-readable narrative.

This is a very big deal.

It's a completely different model to traditional social networking, where content typically doesn't bleed outside the walls of a specific social site. It's also different to previous decentralized social networking efforts, which have been in many ways more sophisticated, but much harder to join in with. Because a simple IndieWeb-compatible social tool can be built in an afternoon, just as a simple RSS-compatible tool can be built in an afternoon, these concepts have a much greater chance of succeeding.

Needless to say, idno is now a first-class participant in the decentralized IndieWeb social community. I've implemented IndieWeb comments, and moved immediately to also implement decentralized events that anyone can RSVP to, as well as decentralized likes. It also integrates with Firefox's brand new Social API.

You can browse the web and reply to any page, on a site that you truly own.

As more sites and platforms implement the IndieWeb social standards, those interactions will become correspondingly more social. For now, though, you can go ahead and interact with the web already.

Beyond that, idno will continue to develop over time as a community platform in itself. I'm using it here on my own site as a single-person publishing platform, but it doesn't have to be that at all, and all those Elgg-style features will continue surface as time goes on. But there's a big, wide web out there, and it's important to embrace that as widely as possible.

idno's homepage is here. Meanwhile, I continue to do work I'm proud of in my actual job, working for latakoo to facilitate media storage and transfer for video professionals and the broadcast news industry. We're talking about using decentralized social networking there too - but more on that another time.