Primary goals

• Base it on Git
  • This allows me to make updates to the website from any computer, without having constant SSH access (which is a corporate security violation in many places)
• Make it more attractive for others to read and navigate
  • Add some basic templating, so that there's a header for each page, that includes: 1) a title, 2) breadcrumbs, 3) a "history" link for that page
• Make it easier for others to separate the wheat from the chaff
  • Add YAML metadata to each page that notes that it's "high-polish", "low-polish", or "personal interest only"
  • Generate my own index pages. On the index pages, when the user hovers their mouse over a link, it should pop-up a brief description of the page. (this brief-description would also be part of the YAML metadata)
• Provide some minimal markup functionality
  • <h3>'s and such should be automatically given an <a name=...>
  • a <title> should be automatically generated from the YAML metadata, along with the same string wrapped in <h2> at the top
  • (optional) being able to link to wikipedia or search.cpan.org might be nice
• Display the last-modified date, on the page itself.
• Auto-link URLs within .txt files
• Make history easier to browse
  • History should be directly tied in to the Git log: 1) The front page should be generated from the git log, and should only be updated when a git push happens. 2) Each page should have a link to display that specific page's history.
  • The ability for users to view individual-page-history is important. The bliki concept means that it's not always clear to readers HOW MUCH content has changed on a recent update; it could be as trivial as tweaking punctuation, or as large as an entire page rewrite.

things that may not make the cut, because of amount of work reqiured, or the technical details haven't been nailed down

• have the ability to track page moves and directory renames, and point the user to the new page
  • presumably, the final output would be a list of mod_rewrite rules, or similar? Or a 404 CGI handler? Or a 404 Javascript handler.
    • 404 JS handler — that's the way to go

things that may not make the cut, because of bloat, but are fairly easy to implement

• Use a template that works seamlessly on both desktop browsers, and mobile phones (resolution-dependent stylesheets)

nice features that come automatically with a "baked" setup

• able to compile SASS/Less and CoffeeScript (to CSS and JS, respectively)

Optional goals

• Provide some way to generate HTML tabular information from .yaml data files. (see these examples)
• I'm currently heading towards using more and more client-side jQuery-based transformations... is there a good way to move these server-side?
• I regularly resort to the command-line to search for things. These search features should be available to ALL readers.
  • ...how do I do this?...