IndieWebCamp – Principles:
“Own your data.
Use visible data for humans first, machines second.
[…] Whatever you build should be for yourself. If you aren't depending on it, why should anybody else?
[…] The more your code is modular and composed of pieces you can swap out, the less dependent you are on a particular device, UI, templating language, API, backend language, storage model, database, platform.
[…] We should be able to build web technology that doesn't require us to destroy everything we've done every few years in the name of progress.”
Teresa Amabile and Steven Kramer for McKinsey – How leaders kill meaning at work:
“Trap 1: Mediocrity signals
[…] Many of the other 65 Karpenter professionals in our study felt that they were doing mediocre work for a mediocre company—one for which they had previously felt fierce pride. By the end of our time collecting data at Karpenter, many of these employees were completely disengaged. Some of the very best had left. […]
Trap 2: Strategic ‘attention deficit disorder’
[…] At another company we studied, strategic ADD appeared to stem from a top team warring with itself. Corporate executives spent many months trying to nail down a new market strategy. Meanwhile, different vice presidents were pushing in different directions, rendering each of the leaders incapable of giving consistent direction to their people. […]
Trap 3: Corporate Keystone Kops
[…] When coordination and support are absent within an organization, people stop believing that they can produce something of high quality. This makes it extremely difficult to maintain a sense of purpose.”
Facebook, Google+, Twitter, LinkedIn: Semi-closed networks have grown to capture most “social” interactions on the Web as well as a lot of content, and they own many people’s online identities. There’s an emerging trend in the software developer community to move out of these “walled gardens” or “silos” – for lots of good reasons (see the IndieWebCamp “Why” page and the xkcd “Instagram” comic): Freedom, ownership, control, longevity, avoiding censorship. (And “harder to spy on by hosting in Switzerland”, since the NSA/Snowden revelations.)
To get started, read Klint Finley’s Wired.com article Meet the Hackers Who Want to Jailbreak the Internet. You can also listen to Tantek Çelik talking about the Rise of the Indie Web (45 minutes audio).
The IndieWebCamp site seems to be the most comprehensive collection of resources on the topic. (“IndieWeb”, the Independent Web, is the term many people are using. As of today, there’s not even a Wikipedia entry for it…)
POSSE (Publish (on your) Own Site, Syndicate Elsewhere) is a cornerstone of this movement. You’ll usually need new or extended software that runs on your own server and elegantly connects with other Web sites (the protocols for these interactions are still evolving). MediaGoblin is an interesting small DAM system built on IndieWeb principles, idno a self-hosted social network platform, storytlr a micro-blogging tool. The Indie Web Camp has a list of software projects. See also: unhosted Web apps and PRISM BREAK.
And here’s some articles worth reading:
Bastian Allgeier – Let’s build a better web: “We need to make it easy, convincing and enjoyable to move our personal data away from the big players. We need great self-hosted applications, which we can use to manage our emails, personal pictures, documents, private messages with friends, blog posts, etc..”
Tantek Çelik – On Silos vs an Open Social Web [#indieweb]: “All the silos are pressured to clutter and corrupt their UX with ads, "stickiness", "engagement", and all kinds of other garbage in a never-ending hamster-wheel chase of ever more page views. You don't have that problem. Take their best stuff and make it simpler, more elegant by cutting out all that crap. And then iterate.”
Ben Werdmuller – The #indieweb as a minimum viable social web ecosystem: “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.”
Aral Balkan – Codename Prometheus: “We need open alternatives that are beautiful holistic experiences. Beautiful experiences that happen to be open and private; where you happen to own your own data. Beautiful experiences that you can hack if you so want to.”
Anil Dash – Rebuilding the Web we lost: “Privately-owned public spaces aren't real public spaces. They don't allow for the play and the chaos and the creativity and brilliance that only arise in spaces that don't exist purely to generate profit. And they're susceptible to being gradually gaslighted by the companies that own them.”
Shane Becker – No More Sharecropping!: “Then as we published all of our content on other services, we became dependent on them. We became digital sharecroppers.”
Marco Arment – Own your identity: “If you care about your online presence, you must own it. I do, and that’s why my email address has always been at my own domain, not the domain of any employer or webmail service. […] I’ve always built my personal blog’s content and reputation at its own domain, completely under my control.”
Jon Udell – Networks of first-class peers: “It is possible for various of our avatars — our websites, our blogs, our calendars — to represent us as first-class peers. That means: They use domain names that we own, they converse with other peers in ways that we enable and can control, they store data in systems that we authorize and can manage. Your Twitter and Facebook avatars are not first-class peers on the network in these ways.”
Will Norris – No one cares about your URLs (so buy a domain): “The only way for you to ensure the integrity and longevity of your content is for you to take ownership of how it is accessed. Do yourself a favor and go buy a domain that you use for publishing your content.”
Julien Genestoux – Independence day on the web: “This starts with owning your presence online: a domain name is cheaper than a phone number, easier to remember and will stay with you for as long as you renew it.”
Laurent Eschenauer – What the hell happened to Federated Social Networks?: “The idea is simple: get your own domain, host your site there, and slowly work towards federating with others. […] You get immediate value out of it (you got a blog) and you make exciting progress with a community of likeminded folks.”
Update: Matthias Pfefferle has also written a nice post – The rise of the IndieWeb [in German].
Update (2017-05-05): Matthias Ott – Going Indie. Step 2: Reclaiming Content.
David Diamond – DAM Beauty and Usability:
“Beauty and usability are typically not words associated with digital asset management software, and for good reason. Have you seen the user interfaces of most DAMs?
[…] DAMs should be as close to invisible as possible. No one learns to create digital content just to spend time in a DAM. Let the digital assets be the stars.
[…] Don’t buy the “it can look like anything you want!” excuse. That just means it’s a DAM you can’t afford. Something must be available out of the box. See it. If the UI is ugly or it makes no sense to you, consider that Strike One against the system.”
I love David’s writing, opinionated and funny, and he’s usually right. There’s so much mediocrity in the DAM software market. Let’s point it out and raise the bar. (If you’re writing on the Web, please dare to have an opinion as well, and voice it clearly – this helps to not bore your readers.)
I’m trying to find a good “elevator pitch” for building hypermedia APIs with HTML. How about this:
Don’t build an API – publish your data instead: easy to read for both humans (not just developers) and software, and easy to link to.
After providing read access, the next step is to enable others to modify your data, manually as well as through software. That’s what we would call an API, of course. But I think it helps if you focus on making your data available instead of starting with “let’s build an API”. (I’m tired of APIs, as explained in my Linked Data for better image search blog post.)
Once the data is out there, everyone can “surf your Web of content” (including search engines if you let them). And developers can write code to automate, to glue separate data sources together, to mash them up.
In my opinion, XHTML+RDFa is the best way to reach that goal. But even if you disagree with my choice of format, I hope you can agree with the general point.
Making data more visible has long been a favorite topic of mine. A decade ago, I wrote a simple PHP script that made it easy to browse an Oracle database, because I hated how my valuable data was hidden behind arcane Oracle tools or the sqlplus command line. (Apparently, some people are still using that script. I guess I should start working on it again, and add RDFa and JSON to it.)
Update: Mike Amundsen comments “don't just tell them what's there (data), show what they can do (actions)”. He’s right, this is missing from my pitch. Don’t stop at publishing your data – let people work with it, and make the actions as easy to discover as the data itself!
Update: See also Ruben Verborgh’s The lie of the API.
One year ago, I wrote on Twitter that “my next API will be semantic XHTML”. Since then, I’ve been thinking a lot about Hypermedia APIs with HTML (and have done some prototyping). My dream API would use XHTML with RDFa, link to Atom feeds and offer an alternative JSON-LD representation.
Here’s a few articles on that topic that made me think:
Combining HTML Hypermedia APIs and Adaptive Web Design by Gustaf Nilsson Kotte is also a great read.
Then watch the full talk (53 minutes) by Jon Moore on Building Hypermedia APIs with HTML.
If you’ve got some time left, I highly recommend the RESTful Web Services book by Leonard Richardson and Sam Ruby. It already said this, back in 2007: “It might seem a little odd to use XHTML […] as a representation format for a web service. I chose it […] because HTML solves many general markup problems and you’re probably already familiar with it. […] Though it’s human-readable and easy to render attractively, nothing prevents well-formed HTML from being processed automatically like XML.” (By the way, the follow-up RESTful Web APIs is going to be published next month.)
I haven’t read the book Building Hypermedia APIs with HTML5 and Node by Mike Amundsen yet, but it sounds interesting.
Please let me know if I missed out on something important…
Update (2017-12-01): See my follow-up post Publish your data, don’t build APIs.
The Typo3 Neos 2017 WCM Forecast has experts predict the future of Web content management, with some great quotes.
Karen McGrane: “First, organizations will realize that WCMS doesn’t always support true multi-channel publishing. They will need to invest in new systems to decouple the authoring and storage layer from the presentation and publishing layer. This might mean adding middleware, developing new APIs or even choosing an entirely new CMS. […]”
Perttu Tolvanen: “I believe that in the future our “content management system” will have dozens of different pieces (for photos, for videos, for publications, for people, for projects, for services) and the purpose of our “strategic web content management system” is more about moderating those different sources and streams between different sites than managing the master content for those services. […]”
Martin Goldbach Olsen: “Intranets will be big again […].”
Jacob Floyd: “The latest trend in CMS development has been to make WYSIWYG inline-editing a first-class feature […]. That trend serves content editors very well, however it does not meet the needs of content creators and content authors.”
Mikkel Staunsholm: “We need to find a way to easily navigate and present any information available from a single centralised content hub, spanning all digital platforms.”
I’m reading this with the convergence between WCM and DAM in mind…
(Minor complaint: Let’s hope that in 2017, such an important document will be published as an HTML page instead of a not-too-accessible PowerPoint presentation on Slideshare.)
I’m currently learning/exploring RDFa (try searching my blog for “rdfa”). As a total newbie to the world of RDF and RDFa, these tools and resources have been helpful so far:
First, the W3C RDFa 1.1 Primer is easy reading, a great introduction to RDFa. And it links to the full specifications (which are also well-written).
The W3C RDFa 1.1 Distiller and Parser is a Web page where you enter a URL, then it summarizes the RDFa data it finds there. Good for verifying your own Web site’s RDFa. (Or try it with one of my blog posts or my home page, http://www.strehle.de/tim/ …)
If you’re like me and prefer to analyze your RDFa from the command line, install the pyRdfa distiller/parser library and run “scripts/localRDFa.py -p URL” (-p means RDF/XML output).
RDFa / Play is a Web page where you type in HTML+RDFa code and, as you type, see it turned into a pretty graph visualization. Nice for playing around with the RDFa syntax.
I’m trying to use common vocabulary if possible, often from the schema.org hierarchy.
Of course, the nice thing about RDFa is that you can always “view source” on other’s pages to see what they’re doing.
Are you into RDFa? Please let me know if I’m missing out on something!
A week ago, I wrote on Twitter: “A bit harsh, but: CxOs tend to fantasize, salespeople to lie, developers to underestimate. Poor project managers (and customers).”
This wasn’t intended as a rant: These are common pitfalls which contribute to software projects not being finished on time (or not at all).
It’s a well-known fact that software developers are bad at estimating how much time they need to implement some functionality. There’s an abundance of articles written about estimation (examples: Liz Keogh, Joey Shipley, Anders Abel).
Salespeople have a difficult job; sometimes they’ve got to sell something that doesn’t actually exist but they think can be delivered. And many requested features leave room for interpretation – they get into the habit of saying yes. It’s tempting to remain vague or bend the truth a little just to close the deal.
The CxO’s job is strategic long-term thinking. The potential trap is to become detached from day-to-day business operation. Then she might confuse yesterday’s strategic plans with what little of them development actually managed to implement until today.
There’s traps for everyone to fall into (including project managers and customers). Just because the problems and failures of developers are more widely and openly discussed doesn’t mean others have less responsibility for a successful project. (My theory: As engineers, developers are more likely to look for problems, honestly analyze them and publish their solutions.) If we want to do dramatically better, we need to improve on everyone’s role!