Changes to First Crack

In The One Where I Disavow Gaming I outlined two goals I wished to work towards using this newfound time of mine previously wasted “mindlessly tapping the W, A, S, and D keys for hours on end”: to write more regularly and code more frequently. A week later the former remains a work in progress, while I can happily report that the latter has gone so well I not only successfully fixed a number of outstanding bugs and implemented quite a few new features in the process, but went on to add some impressive functionality I hadn’t even considered before then as well. Although this focus only allowed for a single post most days last week, I couldn’t be happier with the results.

First and most obviously, any page that lists article previews now does so without a “save to Instapaper” link. Previously, I tacked on an “Open the full article or save to Instapaper” line to every post. Now that line merely reads “Open the full article”. Initially I chose to include this link with every single post as a way of implicitly endorsing Instapaper with each article I published. However, a year later adding content in this manner remains janky at best: given that I did not possess anyone’s Instapaper credentials save my own, and that I refused to use a pre-styled button, clicking my “save to Instapaper” link brought users to a page asking for confirmation before adding the article to their reading queue, at which point the site would redirect them back to the original article’s page on my website. While this process did manage to get the job done, it never did so very well, and so I removed the feature entirely. Now, Instapaper users can either use the official Chrome or Safari browser extension, a bookmarklet, or the brainchild of a third-party developer like Brett Terpstra’s Instapaper Beyond. Each and every one of these ways works much better than a series of redirects, so I have completely stopped advocating that route.

Out of all these improvements I devoted most of my time to a change very few users will ever see. Up until last week, clicking “Post Archives” opened a single page listing all but the latest twenty articles, which reside on the home page. As of today that would have meant more than 400 entries, and a nightmare for anyone needing a specific article. Compounding the problem for those seeking an article within a certain time period, nothing separated those entries by date: I did not display any sort of publication time stamp, posts from December abutted those from January, and nothing delineated articles published in 2012 from those published in 2013. This approach did, however, have one upside: using a browser’s local search on this page would match an article regardless of whether or not I published it this week, month, or year. With this single advantage in mind, I set out to bring much-needed improvement to this neglected portion of my website.

At first I intended to replicate OS X’s Finder by creating tables for each year and month I had made a post, associating those collections with classes and IDs, and using jQuery to tie everything together into one fluid portal. Conceptually, this interface would have allowed me to explore my archives just as one would a file hierarchy. With such complexity and so many moving parts though, I decided on a different route before this idea made it past the first round of testing. Instead, I opted for a system of static pages that would allow me to retain the one benefit of my previous approach while simultaneously improving the granularity at which users could search for articles using their browser’s in-page search feature.

Keeping the original “Post Archives” page intact, I added links to two more pages in its navigation bar: “2012 Archives” and “2013 Archives”. As I continue posting here that list will also grow. Whereas this page contains every post I have ever made save those on the home page, clicking either of these two links will open a page comprised of only articles published within that year. At the bottom of each page I also included a list of links for each month I had posted an article. Unsurprisingly, within these pages reside all the articles from their respective months. Under this new system if a user has a general idea as to when I released a particular article, he or she can drill down in specificity all the way to a particular month. If, on the other hand, someone just wants to find the last time I talked about Coin, a simple CMD+ or CTRL+F on the Post Archives page will suffice.

Last but by no means least in this list of major changes First Crack underwent since last week’s disavowal, I finally broke down and gave up on my aversion to using Javascript. In the past when faced with a challenge I could have solved with the popular scripting language I either found a way to accomplish a similar goal using only CSS or discarded the project entirely. Not because I dislike the language or don’t understand it, but rather out of a desire to adhere to a minimalist site design in every sense of the word, from back-end tasks to front-end aesthetics. Yesterday, though, Marco posted a short article talking about a jQuery plugin called Bigfoot created to provide Instapaper-like popovers for footnotes on the web. Although it took some getting used to, I eventually came around and spent this morning putting it into place. After a few tweaks, I shipped this update like I had all others — silently and without fanfare — earlier this afternoon, and then I sat down to write this post.

In addition to these improvements I also made a number of other more minor changes to both First Crack and this site. “Server-side”, so to speak, for in reality although First Crack could operate solely on a server I choose to run it on my home computer and use FTP to update my site, I added three new abilities to First Crack’s “Authoring” mode. Entered with the “-a” command line parameter, First Crack now supports the following commands:

“-t” for manually modifying a post’s update time.

“-T” for setting a post’s update time to that of its backup in a separate folder, new in this version.

“-r” for forcing First Crack to rebuild a single article, the home page, and the RSS feed.

“-R” for forcing First Crack to rebuild every site resource.

“-u” for uploading a specific article to the server, along with the updated home page, archive pages, and RSS feed.

“-U” for uploading the five most recent articles and the update home page, archive pages, and RSS feed.

“-V” for re-uploading the entire website from the local copy, new with this version.

“-B” for uploading all back-end files such as style sheets and Javascript documents, also new with this version.

“-h” to display the menu listing all accepted commands.

“exit” to quit First Crack’s prompt and check for new content files.

“!exit” to quit First Crack’s prompt and exit the program without taking any further action.

Client-side — that is, aspects of my website users will come into contact with — I made a few small tweaks to the design and implemented a neat trick to boost performance when scrolling using the “pointer-events: none;” css property. With most of the major features taken care of now, First Crack has taken one more giant step towards becoming feature complete. As I promised more than a year ago at this site’s debut, I plan to release First Crack as an open source project on GitHub in the very near future in the hopes that the indie software community will make First Crack even better than it already is.