Context and Footnotes

There is no denying that footnotes play a prominent role on this site1. Rarely does a day go by where there isn't at least one sitting underneath the main body of a blog post, providing context or additional information to explain an idea in a fashion that is less obtrusive than an in-line aside or bracketed segue2. Footnotes have become so much a part of my writing that they even make an appearance in social posts, which may make this publishing platform the only place where a person can include these annotations in a "micro-blogging"3 format. One of the questions I've long had is why these useful notes are so rarely seen on other websites. It's not as through footnotes are a foreign concept and the quick-reference context they can provide might actually make reading about complex or contextual subjects a little easier for people who do not have a complete working knowledge of the subject4.

Footnotes on a Recent Post

The Problem with Footnotes on Websites

As with anything, footnotes are not a panacea5. On the printed page, a footnote is (generally) found only on the bottom of the page that carries the superscript hint. This makes it relatively easy for a reader to read more about something if they so choose. On a website there may be a little more work involved if a person needs to first scroll to the bottom, not losing their place, then go back. The moving screen would be a distraction that can break the flow of the article. There are a couple of solutions to this, of course, and I've used two on this very site in the past. Unfortunately they are not necessarily the best solutions6.

The first method I used was to have the super-script number act as an anchor link7. By clicking or tapping the number, a reader would be brought to the bottom of the page where the footnote existed. At the end of the footnote would be a "return" icon which, as one would expect, returns a person to the point where they left off. This is certainly better than requiring a person scroll down to the bottom of a post themselves, but the jumping content can be visually distracting. The abrupt changes, sliding past images or a wall of text, is not at all a good experience. What's worse is that a person still has to re-read segments to determine where exactly they left off and get back into the article8.

This is a sub-optimal solution to the problem.

A couple of years ago Chris Sauve released "Bigfoot" to the world9, which is a JavaScript library that mimics the footnote popovers that were first seen — to the best of my knowledge — in Instapaper. I liked this idea so much that I implemented it on 10Centuries almost immediately. This worked great on desktop machines and tablets, but proved to be a problem on phones when dealing with some of the more verbose asides on this site and others. In the end, I had to remove the feature and go back to the first implementation so that people could read articles without an unfortunate source of friction.

Neither of these features are found on the current version of the 10Centuries platform10. Instead I've opted for the least helpful method, which is expecting the reader to scroll to the bottom if they want to read more. The reasoning came down to ensuring feature parity with the RSS reader that is built into the 10C platform11, but this is a lazy answer. There must be a better solution.

Fortunately, as with so many things in life, there are a couple of options that might prove worth exploring.

Option One: Tangible Footnotes

A footnote is expected to be at the bottom of a page. With this in mind, if the screen is considered a page, then footnotes should always appear at the bottom of the screen and update as the visible content scrolls. Because some footnotes can be incredibly long on a small screen, it would be better to show just a compressed view with the option to expand and read everything. I see this working a little bit like Vivaldi when the browser tabs are set to appear at the bottom of the window, only less tabular.

Option Two: Anchor Links with Highlighting

The idea here is that a person would click a superscript number and be scrolled to the appropriate footnote, which would then be highlighted in a manner to make it easier to quickly identify and read. Clicking the return link would bring a person back to the part of the page where they were, with the superscript number highlighted so that there's no mistake where a person can pick up reading again.

Option Three: Ditch the Footnotes

This isn't really a valid option as it would mean providing less context to a point or learning how to weave longer, more complex stories that bring a reader along for the ride. While this would be nice from a literary practice point of view, it's not something I'm particularly keen on doing at this time. While I would love to write with such an artistic flurry that people cannot help but read and share my articles with the world because they evoke such vivid mental pictures, this would require me to invest more time into the craft than I have available at the moment. This may be an option at some point in the future, but not today. Of course, this option does nothing to help people using 10C who want to use footnotes12.

Of the first two options, which one is better? The first would require more complex code to be written while the second could probably be hammered out and deployed in a single morning. Are there other workable solutions?

Sometimes I wonder if I'm just overthinking every decision that goes into this platform in an effort to avoid trying something different and failing miserably. Not being able to code the right solution isn't something I worry about, as a lot of my code gets thrown away as ideas evolve and get refined. What worries me is releasing a feature that people detest, resulting in an ever-shrinking community as the tools I provide do not offer sufficient benefits to weather the rough spots. Maybe I'm overthinking this, too. I probably am.

That said, which option will prove to be more correct?


  1. Over the last 24 months there have been 1,218 footnotes written for blog posts on this site alone. To say that footnotes play a prominent role is a bit of an understatement.

  2. Many years ago, when I was just starting to take blogging as a serious creative outlet, posts were written in a fashion similar to what I would see in the opinion section of various newspapers. Footnotes and references are generally handled quite a bit differently when columns are limited in length and width, so writers would often use an inline aside — such as this, which is marked by a double-width dash — or brackets (which is what I generally see in newspapers that were at one time owned by Conrad Black, "the millionaire who went to jail").

  3. When people started to think of posts consisting of a handful of words as a "micro blog", there was a bit of experimentation to see how additional context could be included in a post. The solution on microbloggling platforms such as Twitter was to reply to yourself to build a "Tweet storm", or a series of sentences that would hopefully form a cohesive paragraph if read chronologically and not taken out of context. As one would expect from someone as creative as a brick, I tended to write a longer blog post and just post a link to that on Twitter — or somewhere else — in the hopes that a less abridged explanation of an idea or opinion would foster a more nuanced dialog. Boy was I wrong.

  4. People are not stupid. We might call each other various synonyms of this word from time to time but, at the end of the day, I strongly believe that most of us want to expand our knowledge and understanding of the universe and the IDIC within. The Internet has often been referred to as the id of humanity, but I tend to see it as IDIC on display; Infinite Diversity in Infinite Combinations. Roughly half of the people on the planet are using the Internet to communicate and share ideas. Billions of people with different backgrounds, beliefs, ideologies, degrees of education, levels of cognitive understanding, and states of mind. With a little context behind an idea, it becomes that much easier to understand where a writer is coming from, even if we don't agree.

  5. No solution is going to magically solve all problems. That said, some solutions can gain wider traction and foster greater innovation from a community of thinkers.

  6. This is one of the reasons I dislike how people will market a product as "the best X for Y". There is no possible way any single solution is going to work for everyone. How many text editors are there available for download? How many different flavours of Linux? How many different laundry detergents? Best is, at best, a subjective term that can only apply to a handful of individuals. This won't stop people from trying, though.

  7. Anchor links are certainly a valid option to the problem of quick footnote seeking, but I'm reminded of the hassles from the early days of digital books. In the late 90s, there were a couple of competing file formats that tried to force a book to feel like a website. What this meant was that a textbook or published thesis might have anywhere between two and five dozen references at the back of the book. Clicking a link would trigger the jump to the page which, on a Palm handheld or very early Kindle meant waiting for the device to read to the end of the book, find the reference, then render the page on the screen. A process that would require five seconds on a good day. Clicking back would require just as much time and, if you changed the size of the font, then the page numbers were all wrong and you'd end up where you didn't want to be.

  8. It was a mess!

  9. When bigfoot.js was released, a lot of websites in the Apple blogger sphere snapped it up right away. This was a great solution for people who wrote short footnotes, but there was a problem for people who were unaccustomed to using the literary tool in that a number of CMSes did not natively support them. Now, almost six years after the JavaScript helper's release, it seems that there are just a handful of sites — that I visit — that use an occasional footnote in any capacity.

  10. Like a lot of current CMSes that abstain from WYSIWYG editors, 10C relies heavily on Markdown for its text formatting. When the text is rendered into HTML, tags are added to make posts IndieWeb friendly, but little is done to make the various post types really stand out.

  11. One of the core concepts behind 10Cv5, which I have eluded to at times, is that this current version of the platform is really more of an RSS reader with the ability to publish content to a domain you own. Comments can be made right from the reader, which will then result in a Quotation or Bookmark post on your own site. Webmentions are then sent out so that Indieweb-ready websites can visit the source post, read in the comment, and display it to future readers. This makes it possible for an author to have long-term control over the words they publish online and, if a commented-on post disappears at some point in the future, the comment continues to exist in a local database. That said, this feature is not yet fully released.

  12. This is the crux of the problem I face with personal projects, such as 10C. People are using the software. I really want the features to be things that people can use easily and rely on. The move to v5, however, was painfully messy. There are still records that have not yet been properly attached to the accounts of the authors, and some core site pages are still non-existent. The RSS feature is something that is being used transparently on a daily basis in the form of Nice.Social, but it's not quite ready to deal with the wild-west of RSS feeds that exist across the web. Every couple of days I'm spotting issues with malformed feeds that need analysis and better handling. Once the core features of v5 are in place and people have all of their data in an easily accessible fashion, I'll open up the RSS reader — and its API — to anyone who wishes to read and comment on content using the Google Reader-inspired web application.

Renaming and Rejuvenating

Over the last few years the name of the software powering the 10Centuries service was, for lack of a better name, 10Centuries. While this works fine for services that operate in isolation, it can make for a bit of confusion when talking about something. The next version of the software will be doing something I've wanted to offer for years with 10C and allowing people to host their own instance of the service. In order to keep things simple, I've decided to rename the software starting with the next version simply to v5.

For people who have been using or watching the development of the current site, the first question will undoubtedly be something like "what about all the half-written features in the existing software?" A valid question, too. I plan on completing a few more items for the current platform before putting more attention into v5. Photos and ToDos have some more updates coming, as does the long overdue Comments API, which is functional but has not yet been implemented across the various site themes. With these three key areas complete, it will then become possible to focus on the next version of the software while also seeing whether the newer updates are remotely popular.

One difference with how v5 will be developed compared to other projects I've worked on involves documentation. This is an area that I've been historically weak at, often writing a few pages only after being rightfully pestered by people who are showing an interest in the system. With v5 I plan on writing and updating the documentation with each and every commit. This will hopefully keep everything better aligned and up to date. More than this, the documentation will be part of the software package. This will make it possible for people to read about the tool while offline. A small thing, perhaps, but completely doable given the files will all be plaintext with standard Markdown formatting.

What's Going In v5?

v5 will have a number of features that I've not seen anywhere else. People will naturally be able to publish blog posts, podcasts, social streams, and other basic things that many publishing tools can already do, but it will also allow for automatic backups across servers. This can be to other servers that a person operates, servers operated by people they trust, or to the main 10Centuries service itself. By doing this, a person can safeguard their data from being lost forever if a server goes offline. The feature will be an opt-in service, of course, and encryption will be used at every level to ensure only authorized access to the data.

This distribution mechanism is also how the social feeds will be managed. Rather than have a social client that subscribes to different feeds like an RSS mechanism, the posts will be read into the same server pools, and distributed this way. People will still have the option to selectively subscribe to accounts on different services, of course. The pool would simply allow for a global timeline to exist.

Some other nice features that will go into v5 include:

  • IndieWeb support out of the box
  • JSONFeed support out of the box
  • Archive.org support out of the box
  • Podcast download stats
  • Simpler website templates
  • Bi-directional sync with other social networks
  • and quite a bit more

Why?

Why not? I've looked around at a number of the open options for a lot of the core and bonus features I'd like to see in a package like v5 and found some great work hidden behind incredibly complex configurations. v5 is going to me my attempt to simplify this stuff as much as possible. Software is still too complicated in 2017. I think we can do better.

Development of v5 will happen in the open via GitHub, and people are encouraged to participate if they choose. While it will be impossible to appease everybody, it shouldn't be improbably to satisfy many.

What (Real) Problem Am I Trying to Solve?

Over the last year or so, I've invested a good amount of time into learning about blockchain, JSON, encryption, and a myriad of other tools that could be used in the next big version of 10C. After a great deal of research, I've come to the conclusion that blockchain is not what I'm looking for as a means of message validation and will instead fall back on other methods that employ technologies that are much easier to explain and verify. In addition to this, I've been looking at a number of other projects that are quite active across the web such as IndieWeb and JSON Feed1 to make the next version of the platform something people might actually want to use themselves. Yet, despite the effort going into the research and pre-development, a lingering question remains: what real problem am I trying to solve here?

There are already a number of open-source blogging tools that are admittedly much better in terms of UI and web standards than 10C. Why am I not simply using one of these as part of the larger goal? The same is said for social networking, photo sharing, notes, todos, and just about everything else I've been slowly building into the 10Centuries platform. What could possibly make anything I make better than setting up a NextCloud instance with a bunch of plugins to fill in the gaps?

It's a problem I struggle with because, while I am very much interested in helping people keep the words and images they want to share with the world online for a millennia, do I need to do it with a software platform that I build rather than one assembled from various open projects around the web? What could possibly make 10C better than WordPress with a myriad of plugins? Despite what people might want from the 10C platform, it is a silo. Even in v5, which involves a globally distributed system of servers operated by anybody who might want to participate, the system is a silo. A silo that anybody could operate, but a silo nonetheless.

Is this what people actually want? Would I be better off investing my time contributing to open projects that already have large, vibrant communities and encouraging adoption of ideas rather than of software?

One of the reasons these thoughts have been rolling around in my head is because I'm downright exhausted, and any amount of free time I might have enjoyed in the past is all but gone as a result of expectations elsewhere. This tiny blog post right here required 8 separate attempts across three devices and 30 hours to complete. This right here. Which is the length of something I used to bang out on an iPod Touch with Evernote while on the train to work. Despite all of my best efforts I just feel as though I'm letting people down as a result of diverted attention, and I really dislike letting people down.

So what is the real problem I am trying to solve with future versions of the 10C platform? Automatic distribution of encrypted content across servers to act as a backup for friends/family when systems go down? Self-hosted community creation on minimal hardware? An API-driven system that is open enough for people to easily create their own tools that interact with the system? Yes on all counts. But does it need to be something that I've written top to bottom? Is absolute control over the software stack really that important to me? Is it important to others? This is the question I need to answer ….


  1. this one will make its appearance in the existing version of 10C quite soon

Ownership vs. Ownership

There is a growing movement online that has the wonderfully optimistic slogan "Own Your Content". This is a concept that I fully agree with, though I will admit to being incredibly confused for quite some time by the meaning of the first word in the sentence. What does it mean to "own" your content, and can the people who encourage others to take back control honestly say that they own the digital information they share online?

To the best of my understanding, "Own Your Content" is a movement by people who do not wish to keep their data in silos around the Internet. People have recorded well over a decade of events into Facebook, yet that data is not portable enough to be extracted for your own archives. Same with Twitter, Medium, and the vast majority of places where people congregate online to share words, pictures, and audio. If any of these services were to disappear, like App.Net or PicPlz, then vast swaths of a person's online history could disappear. More than this, a number of the big services that encourage us to share information through their networks earn money through our participation. We are essentially using our free time to create content for other people to profit on, while (arguably) seeing very little in return. We are not the customer, but the product to be sold.

It's easy to see why some people are opposed to this and combating the commoditization of their time, creativity, and identity with software and systems that they have more control over. Rather than blog with Medium, one can set up a site of their own on Amazon, Digital Ocean, or other vendors. Rather than rely solely on Twitter or Facebook, people can use that same site to distribute their messages. Often times this means "cross-posting" the information stored on their virtual server to the silos they've worked so hard to escape. For many people, this is content ownership.

I disagree. While this is a step in the right direction, having our words on a hosted WordPress installation is content management and little more.

If a person truly wants to own their content, they cannot rely on Amazon, RackSpace, Linode, or any other corporate provider to host their information. Otherwise they are just trusting another party to not take advantage of them or interfere with the distribution of the data. To own content, one must own the hardware and have it on-premisis1. This way, if a vendor decides they no longer wish to host your content or if a government entity decides to swoop in and take the out of the data centre, you still have the content.

But how many people can actually do this? How many people would even want to try to have a server at home as well as one that's openly accessible to the public and broadcasting content to Facebook, Twitter, and other services? Despite the marked improvements in server management and software installation, there is still a rather large learning curve people need to overcome. We need something simpler …

Which brings me to something I've been thinking about for roughly two years.

Ubuntu@Home

Over the last few years I've become quite acquainted with the ins and outs of Ubuntu, and I've seen a lot of what it can do when given the right hardware. This is where the idea of owning one's content becomes real, because there's no reason why a person could not have a tiny, pre-built computer at home running Ubuntu which then synchronizes with a machine that is open on the web. Ubuntu, despite all its strengths, is still very much Linux. This means that the software that the home computer ships with would need to be pre-installed and painfully simple to use and update. The standard LAMP2 stack cannot apply. Instead, something new would need to be used: Snaps.

A Snap is a universal Linux package that works on (just about) any distribution or device. Snaps are faster to install, easier to create, safer to run, and they update automatically and transactionally so the software is always fresh and never broken. What this means for a normal person is that a tiny computer the size of a Starbucks coffee could be shipped to them and run on their home network. This would then interface with another server they have running in "the cloud". Rather than SSH into a Linux machine and install a bunch of disparate software packages, fiddle with configuration settings, and rage at Apache misconfigurations, a person would instead type something like the following into the public web server:

sudo snap install 10centuries

From there the package would be downloaded from a trusted source and started. People would see a message like 10Centuries Node started. Visit http://{server_ip_address} to configure the server. and then be off to the races. The public node would synchronize with the private node in their home and, should a person decide they want to change VPS providers for whatever reason, they could do so and simply reinstall a snap then re-sync the node. More than this, people could connect their nodes to those run by friends and family in order to share encrypted backups so that, if a server did disappear from the web, the data would not be lost. The nodes would also be configured to communicate with each other when social interactions are taking place. This would, for all intents and purposes, create a mesh network where no single point of failure could take a person offline indefinitely.

This has been the long-term vision for 10Centuries, but the software just hasn't been there for the average person. The open projects I've worked on or lead in the past have all suffered from a staggeringly high learning curve, and it's resulted in many people giving up in frustration. We've got to do better, and Snaps appear to be the way forward. I've been doing a bunch of testing with packages, deployments, and node synchronization over the last few months. A shippable product is still quite a ways away, but it's not at all an impossible project. More than this, there's a possible revenue stream available in mini-server sales that would make the project financially tenable for a small group of people.

Imagine buying a small home server for $50 and having it synchronize automatically with a web server running the blogging and social services that you operate. Apps would be written that would interact with your servers rather than commercially-backed systems. If you're at home, you'd interact with the local machine reducing latency. If you're at the coffee shop or in a plane, the apps would use the public server. In every case, your data is synchronized and distributed just the way you want, all through a mesh network that can be configured to be more resilient to failure.

I've long considered the idea of content ownership implausible until the tools became simple enough for everyone to have their data safely stored in their own house. This idea makes it just a little more realistic.


  1. or be very, very strict with regards to data backups and automated collection and storage of that information

  2. Linux + Apache + MySQL + PHP