Compiled Website > Reasoning
On Blogs and Blogging
Each blog post is a moment that's been captured in time. It's an online diary or journal.
I would say that a blog post is at its very best when it represents such a moment. Using the blog medium to create anything else, like an essay, feels inappropriate.
If one wished to create an article that's meant to be kept up-to-date, then it's better suited for a non-blog. A documentation engine perhaps, but not a blog.
Counting the number of blogs out there, the medium has certainly proved to be valuable. However, weblogs don't seem useful to me.
A writer can hone their skills through regular blogging, but whenever I write I find that I constantly refer to my earlier works. In doing so, I'm compelled to revisit and update them.
To me it seems wrong to write a new version of an article while leaving the old one to collect dust. Old crufty articles are just clutter that get in the way of searching for updated and actually-useful content.
In select cases there is value in having "old notes", as when referencing specific dates or versions of something. With such notes, one can look at a timeline of change and have some comment to make.
A lot of personality bleeds through into a blog post, which is nice. Sometimes I use them to vent. But I still can't understand what real value they have. For now, I simply don't care to write an online journal. I still think in terms of documents, so blogs aren't for me.
On Wikis .. and Wikiing?
Where blog posts tend towards being separate snapshots in time, or perhaps more of a timeline of posts, wiki articles are entangled with one another.
It's true that each wiki post will begin its life just like a blog post -- as a snapshot in time. However, wiki posts will tend to be be updated whenever visited. Also, where traditional documentation waits for large changes to be queued up before being applied, the smallest nuances tend to make it into wiki articles with no wait and no queue. The ease of updating is one of the hallmarks of the wiki; It changes the mindset of the maintainer such that a wiki article isn't so much a snapshot back in time from its creation as it's a snapshot of the maintainer's last visit.
But the wiki is much more than the maintainer's mindset change for the one article. Surfing through a wiki floats a huge number of related (and unrelated) closer to the surfer. A traditional website is like a pool of water with each document being like a stepping stone on the bottom. Surfing such a website is like wading into that pool and stepping from stone-to-stone. A wiki takes that pool and fills it with smaller articles less like stones and more like leaves. Some leaves have sunk to the bottom and some are floating at the top. When the user wades through from article to article, stepping from stone to stone, the movement constantly churns the collection of leaves. Instead of peering down and going from stone to stone, our user is both distracted and enthralled by a flurry of nearby leaves.
This same flurry of documents, of varying sizes and value, also becomes available to the maintainer as they surf. When intentionally updating one important document, the maintainer is constantly tempted into visiting and updating a huge number of semi-related documents. All of these articles become entangled in a way where each single one helps many others stay updated.
So a wiki article is even more than a snapshot back in time from its creation or a snapshot of the maintainer's last visit, it's like one single snapshot in a whole photo album of snapshots of the maintainer's last visit.
A traditional documentation system needs concise effort for each article revision. I find the buildup to that concise effort to be quite intimidating. In contrast, a wiki is a constant and compelling lure of my attention, and article-revision is trivial.
At least as far back as the 90s, the term for a person like me would have been "power user". That past persona which pushed and tested software constantly has survived to this day. When faced with an issue and with a set of tools, I will constantly try new tools. Even as the issue evolves my testing will continue.
The issue of how to organise my thoughts has burdened me since I was a child, and I expect it will be with me until my last breath. It's pretty obvious to use a computer in that toolkit, but the available software has never felt right.
I've used all sorts of systems and file formats and programs. If it mattered on a resume perhaps I might have kept a list of all the hassles I've gone through. But I don't care to impress upon a reader any sort of faux-credentials. I just want to relay that I have, and still, constantly work with new tools.
Perhaps I can never be happy with the tools of others, at least for something as central as organising my thoughts. I've tried and tried until it's come to the point that I'm simply unhappy with anything I use. So it's time I made something myself. Creating a piece of software to solve a common problem in the face of so many tools is a supremely arrogant thing to do. Of this I'm quite aware. But I'm doing it.
Doing It Myself
I've always wanted to be able to crack open any piece of software I use, just to fix little annoyances. Bad hotkeys, simple bugs, whatever. I also dreamed of making my own programs. But I never got off to a good start. My computer youth was that of a user and never a programmer. I had no significant schooling and no "spark" as a hobbyist programmer.
As I matured, I explored more and more programs and even dabbled in programming languages. But for programming, I only had the barest warmth and certainly no passionate fire like I've seen with so many others. I've always been that "power user". Sure I matured it into a reviewer, a tester and even a hardcore bug hunter. But "programmer" was never something I could call myself.
It's one thing to have an all-important problem to solve. It's another to have used a whole lot of tools and worked hard with them. Yet another to finally be able to turn and look the right direction with a programming language that might actually be usable. But doing it. That's a whole new game.
It's taken me years to get to the point where I'm comfortable enough with programming that I can actually solve real-world problems with it. It didn't just take a lot of time and a lot of hard work, it took a completely new perspective and philosophy on life. I'm still nowhere near where I will be, but I'm finally confident enough that a project as complex as this doesn't seem particularly hard. I feel strange writing that.
It would take a whole series of articles to talk about how I've actually gained more 'sense' and have become capable of things which were entirely out of the question before. It's not a child-versus-adult maturation thing either. I've been an adult for a long while now, and the gains I've had from that maturity are nothing compared to what I've been able to do with my own directed effort.
And so it comes to pass that I have the time and passion and skill all at the same time. I did find more and more applications, and kits whose components I could use which do bits of what I want. But at some point I just decided that it was time to plunge right in and do the whole damned thing from the ground up. From scratch. Myself.
The funny thing is that it's actually happening. I've laughed with glee at some of the things I've been able to accomplish, and in a time that's much shorter than I had ever imagined possible.
This project isn't just about solving a problem, it's the manifestation of a lifetime of personal progress. Programming is becoming one of my passionate outlets, and this is the perfect project for it.
About Specific Features
I never really thought about manually specifying links in my markup. I was quite used to <a href type links. Because of my typing speed there was no inconvenience.
But there was one wiki, whose name I cannot remember and which I only used for a short while, which automated linking. It was an idea that had never occurred to me. It was such a fresh new perspective on managing the "intra-wiki" linking.
The simplified markup was a primary reason for building my own engine, but it's this automatic linking which is by far the most significant working feature.
For an author to make the best use out of an automated linking system, they will change the way they name pages. Links are made automatically when natural language is used, but only if documents are named with that natural language.
This is a surprisingly difficult idea to explain, so I'll explain from an search engine optimisation (SEO) perspective. In SEO, I've heard that it's important to make links be a description of what their linking to.
I've also heard that it's important to make the actual HTML filename a reference to its content. So why not add both together?
With this advantage in mind, and with this functionality provided, a "lazy" author needs to shift the way they write in order to take full advantage of the automated linking. Making this shift breathes an interesting new life into the way pages are written and into the way the entire wiki is structured.
A document must be named in a way that flows within a sentence in order for it to be linked-to in future documents. Documents are now named after what they are and do, instead of using a more rigid title format found elsewhere.
Once acclimatized to this functionality, an author can separate themselves from the structure of the wiki. They can write completely freely without a mental database of topics and article titles. When articles are named correctly, everyday language will automatically build links.
If writing freely and expected links don't appear, then the odds are good that there's either a more general or more specific topic that's waiting to be written.. or perhaps the existing document can be named more effectively. The example that prompted me to write this section was my having a document called "Persian" when it's actually about Persian cooking.