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.
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.
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?
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.
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").
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.
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.
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.
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.
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.
It was a mess!
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.
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.
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.