The fifth edition of IndieWebCamp Brighton saw a good two dozen enthusiasts gather for a weekend of debating, brainstorming and prototyping the social web of the future.
Being run by a community committed to the development of alternatives to the walled gardens of corporate-owned social media services (aka. "silos") by developing new means of using the open web for social interaction, I expected a lot of food for thought and, if anything, was overwhelmed by just how much there is going on. Experiencing the hands-on combination of designing with doing, a trademark feature of the IndieWeb community, was a great pleasure - and a welcome diversion from the often rather academic "design thinking" I engage in in other contexts.
My own site (that you are reading right now) has long been supporting the core features of an IndieWeb site, with:
- a strict policy to publish only here and syndicate to social media silos where appropriate (POSSE, "post on own site, syndicate elsewhere"),
- mechanisms to follow discussions emerging around my content (cue: webmentions and backfeed), and
- specific efforts to integrate IndieWeb features to WordPress for my own purposes (referred to as "selfdogfooding": designing solutions for personal use first, then sharing them for others to build upon).
In addition, I have always tried to identify how the premise of "owning your content" could be taken further, made accessible to non-tech audiences and extended beyond the "personal blog" context it often appears in.
Amongst a myriad of random inspirations, many of which for sure will find their way into projects of mine in the near future, I would like to summarize three main takeaways from this memorable weekend in Brighton:
#1: IndieWeb is not just coding
This was not a surprise to me, but an important one to highlight: From the outside, the IndieWeb movement may at times appear like a bunch of hackers and programmers mainly talking code. The opposite is the case; while some discussions and projects undoubtedly were well beyond the capacities of this generally rather tech-savvy participant, almost every technical debate on the IndieWeb starts out from a design objective (see principles of the IndieWeb movement).
Two entire sessions were focusing on how to make IndieWeb practices available to the average silo user (session memo) and how to fill the gap between what silos offer and the IndieWeb doesn't/yet (session memo); I missed these as I was on another simultaneous track, but reading the notes afterwards, I was both surprised and happy to see the amount of overlap with my long-standing research on non-use.
Encouraging people to leave closed systems behind and engage on the open web inevitably raises questions of disconnection from social circles - a topic I consider crucial to tackle if these open alternatives are to become mainstream some day. It being raised here is probably a sign of maturation of the IndieWeb movement, which is still intentionally and rightfully focusing on individual solutions, but obviously may soon reach audiences that are interested more in using than developing it.
I took home a new concept/term as well: "weaning" as the process of slowly decreasing the rate of use of an online service (who says attending an unconference/hacking weekend could not feed back into your academic research?).
#2: Thinking "beyond the stream"
In my introductory presentation, I mentioned my ongoing considerations whether presenting personal web sites primarily as (reverse) chronological feeds of posts is really ultima ratio. It turned out that a lot of others have been thinking about this and - in true barcamp manner - we soon after decided to dedicate one afternoon session (session memo) to the question of alternatives to "the stream" (which, as was pointed out, most likely replicates itself so strongly on the current IndieWeb because of the effort to emulate and improve applications from the dominantely "stream"-based social media silos).
The discussion highlighted how most attendants actually have certain systems in place to filter their content's initial presentation to their readers. While the diary-like creation and handling of posts remains a core feature for almost everybody, considerations of the audience play an important role in how they are presented. Three approaches dominate the field:
- Filtering by category: not showing certain post categories in a default view, or liminting the amount of such posts shown, is one solution not to overload the reader with potentially irrelevant content,
- Summarizing less relevant categories: the presentation of certain post types as summaries, with a link to access more, show how diary-style IndieWeb users have a clear conception of their audience and know what posts are likely of interest to only themselves or a small share of readers.
- Highlighting recent posts of a certain type: some authors recognize particular interest in some forms of their content (often long-form articles) and provide a separate design element to feature these apart from the main "most recent" stream element.
To the reader of these notes, this must appear like discussing the 101 of designing a social interface (filter, summarize, feature/highlight, ...). However, the value of this debate reaches much deeper: thinking back to how personal web sites were designed before the big platforms raised "the news feed" to be the definitive solution for organising personal publishing (though also the evolution of blogging itself needs to be mentioned here as a source of the feed), traditional information architecture has always been the first principle, from the earliest days of GeoCities and beyond.
Having a movement who aims to free the individual from the restrictions of the social media corset (NB. "indie" does not just stand for independent, but also individual!) debate on the value of the news feed/stream is a wonderful example of critical engagement with current IxD principles for the benefit of both publishers and readers - this is what I refer to as Critical Interaction Design.
The second day of any IndieWebCamp is "hack day": participants work on improving their own sites, prototyping new ideas, and helping each other through knowledge exchange.
Apart from a small addition to my POSSE Wordpress plugin, now allowing me to also instantly share relevant posts on LinkedIn at a single mouse click (a separate blog post on this solution will follow), I had chosen to work on my bookmarking workflow. This had been the topic of another Saturday session; during the intro rounds, it turned out that - once again the richness of practices only independent web sites can provide - individuals have very distinct workflows of how and why they bookmark sites, what is their workflow for presenting them to their readers, and the techniques used "under the hood". Sharing personal practices, collecting tools available, and discussing whether a bookmark with added commentary is a "bookmark post" or rather a "reply" to the original author (the majority's and my preference being the former).
Saving URLs as I read on the internet is an important starting point for collecting material on interesting topics, for crafting future posts and articles, and for archiving relevant content for myself. Having self-hosted my bookmarks for several years, though mainly as private posts for my own use, I am currently looking at ways to make my readings more easily available to blog readers - who can be assumed to be interested in similar topics and hence may get a lot of value from sharing.
Unfortunately, one day is often too short to achieve more than baby steps, but here is what I did and will follow up on in a later blog post:
- I installed Wallabag, a self-hosted Pocket/Instapaper alternative, on my server ...with the goal to temporarily integrate it into my flow and evaluate whether it could be integrated with my WordPress-workflow to e.g. save the full text of bookmarked sites for later reference.
- Bookmark posts on this site now feature the recommended microformat markup for bookmarks, to communicate the nature of the posts.
- When publishing a bookmark, a webmention of type "bookmark" is going to be sent to the referenced website, enabling their author to receive a notification (not functional yet, to be finalized in the near future; ideally, I would also like to process and display incoming bookmark notifications).
- First updates to my bookmarking UI, in order to allow for a more streamlined publishing process and easier classification of my bookmarks by their purpose ("read later", "for reference", "to publish" etc.; as a matter of fact a good share of my hacking day went into analysis and design work around this workflow).
Another bookmark-related idea I took away from the concluding demo session was Jeremy Keith's implementation of using the bookmarking flow to ping archive.org's Wayback machine - ensuring that the service is aware of the bookmarked URL and keep a copy of it archived for the future.
When is the next IndieWebCamp?
With the growing interest in the IndieWeb, IndieWebCamps and their smaller siblings, Hombrew Website Clubs, are currently popping up around Europe and North America like mushrooms after the rain; schedule here.
Having an entire day dedicated to do under-the-hood work on my site that I otherwise never find the time to do was a great opportunity, but above all I enjoyed two days of social exchange with like-minded people who all share the passion to restore freedom and independence on the web, along with a constructively critical approach to mainstream practice and putting their money where their mouth is by "selfdogfooding" on their designs to prove the case.
...and I got to know a whole bunch of very nice people in the process! (Also posted on IndieNews)