Missing Chronology

Last month when someone wanted to find a specific post on my blog they would open the archives page, type in a few keywords, and let the incomplete search mechanism try to find the item they were looking for. If that didn't work, then clearing the filters and scrolling down would show every post in reverse chronological order going all the way back to April 1979. The default blogging theme on v5 works a little differently in that the search box is available on every page and, unlike the previous mechanism, will actually result in a database search. As people had a way to find items on a site, it never crossed my mind to build a page showing a site's table of contents until Larry reminded me.


Fortunately, building a page like this isn't incredibly complicated. The fact that the archives page does not need a search box also means it's possible to change how the page displays information. But how could the information be changed to show things that people might want to see? I thought about this question a bit this weekend and came up with this:

The Anri Archives Page

There were a couple of things that I liked about the previous design:

  1. posts were numered
  2. posts were grouped by month, with the month being a title
  3. grouping was done based on the time zone of the reader, not the author

These three features needed to be brought forward with the understanding that Bookmarks and Quotations would also appear on the archives page. Social posts, called notes, are not visible in the archives as this would be noise. Should there be a need to see all social posts in reverse chronological order, there is always the Notes page.

The previous version of 10C generally cheated with the archives page by presenting a blank page, querying the API for a list of posts with supporting meta data, then building the results. This works in most situations, but can cause some headaches for search engines that do not parse JavaScript or for people using a browser with JavaScript disabled. To help resolve this, archives are now presented in plain HTML and then modified after the fact.

One item I'm not too sure about at this point is the numbering. As the screen capture will show, the numbers count differently based on the kind of object. Articles, bookmarks, and quotations are all shown with an icon unique to their type, and the counter is for that type as well. Does this make sense? Does it matter whether these are split apart at all? Could everything have the same icon, or none at all, with the understanding that clicking the title will bring you to the author's page regardless of the type? I'm not 100% sure. Fortunately, the community on 10C will let me know when something doesn't quite work or needs improvement.

The archive theme was deployed with release 19D150 which is live on the server now. Every site with at least one article, bookmark, or quotation will see the "Archives" link in their navigation menu.

So Much For Simplicity

Earlier today I stumbled across bigfoot.js, a tiny little JavaScript library that does some wonderful things with footnotes. In an all-too-common moment of excitement, I decided to add it to 10Centuries. This little library would completely change the way people could use footnotes with the service, and usher in a better experience when people were reading longer posts in an RSS reader. Not adding this tool would have been silly. That said, at what point does adding "one more little thing" start to get in the way of speed and simplicity?

Bigfoot.js In Action

One of the goals I've had with 10Centuries since before the first line of code was written was to keep the system lean and mean. It has certainly grown a lot in the last few years as a result of changing technologies and changing needs, but the ultimate goal is to ensure that this software continues to remain lightyears ahead of the competition when it comes to things like page load times. Adding another 33KB to a request may not seem like a whole lot, but if I were to add five 33KB files, that would be noticeable on a slower data connection.

Very rarely will I jump on adding something to 10Centuries. A lot of the features and functions that are added exist mainly in the back where people don't see or directly interact with them. So, while bigfoot.js has been added to 10Centuries, it will initially be seen only in the RSS feeds. Optimisations will be made to the code over the next couple of weeks to make it as lean as possible and, at that point, the roll out will hit the main websites as well. One of my biggest questions is how the tool works with VoiceOver1.

  1. ideally people should be able to have their mobile devices read any 10Centuries site to them without any problems

Post via Email

Ten days isn't a long time, but a lot can happen in 240 hours. Last Wednesday Rossa imagined there was a feature in 10Centuries, Charl offered a solution, and I outright rejected any desire to even build the feature. A few hours later there seemed to be more demand for this little addition. I considered it in the grand scheme of 10Centuries rather than from my own perspective, and came to the conclusion that this is something people would want and would find easy enough to do. From this point on, the feature had to be built.

Being able to publish a blog post by sending an email somewhere is nothing new. WordPress and other blogging tools have had this feature for years. Evernote even allows us to send an email as a means of adding information to notebooks for later synchronisation. Email is, for better or worse, one of the most effective ways for people to send and share information. To deny people the ability to easily do with 10Centuries what they can do elsewhere would be stupid, and go against the ultimate principles I'm trying to uphold with the web service: People should be able to post what they want, how they want, when they want, in any language they want.

Post Via Email

Say "Hello" to Posting via Email, the newest 10Centuries feature that is available for both free and premium accounts.

One of the concerns that I had with regards to publishing content via email is the unfortunate reality that spam bots will do just about anything to get their message in front of as many people as possible. Most web services handle this sort of feature one of two ways.

  1. Offer an email address with some random jumble of characters in front of an easy-to-guess domain, and publish anything that is sent to the mailbox
  2. Have everyone email the same address, and determine where to publish content based on the source address

I didn't like either of these options. To that end, some combination of the two needed to be created … and here we have it.

People who want to share their website with multiple people can now do so simply by adding email addresses to the filter box. These addresses can be comma-separated, put on new lines, or separated by spaces. It really doesn't matter how the data is entered. There is also no (realistic1) limit to the number of addresses that can be granted permission to publish.

There are some technical limitations, though, and here they are:

  • there are some issues dealing with images of various types, sizes, and quantity. This will be addressed shortly, though
  • messages written in Asian or Sanskrit may have some encoding issues through the email provider. More testing is needed
  • videos and audio files cannot yet be shared through email

The function is still "in testing", though receives updates on a daily basis to resolve some edge case bugs that crop up from time to time. You can give this a try by signing in to your Web Dashboard and going to the Settings / Email tab. From there, simply enable the function and set the mail addresses that have permission to publish articles. Do let me know if there are problems, though.


  1. the actual limit is 4.2-billion email addresses