potential features

Think of this page as a suggestion box — none of the features in the list below are in vcki yet, but some may make it eventually.

Tagging — free us from the confines of hierarchical navigation.
Bayesian (overkill?) navigation paths — rather than explicitly assign default paths for nodes to expand on, gather data on most desirable pages (either automatically by explicit URL requests, or by reddit-style voting up/down) and use that to determine default nav-paths.
- if not necessarily an automatic navigation guide, perhaps use colors, font-size, or other creative means to indicate popularity/desirability of nodes/leaves
Node/leaf relocating — rather than having to remove a node/leaf, allows to simply relocate to a different part of the nav-tree
- scan other pages for references to old location?
- automatically update out-of-sync links?
Bad link detection — if a link goes to another vcki page that doesn't exist, show something special notifying viewers of broken-ness.
Syndication — RSS(/Atom?) feeds for new/changed pages.
Node display options — give the option of showing the first page under a node by default, showing the concatenated contents of that node (with configurable depth), or some other style.
“Tumblelog” — no, seriously, each edit could easily be an entry in a rolling, dynamically-generated tumblelog feed-type-thingy.
- tumblelogs are fundamentally/conceptually consistent with vcki's free-wheeling, free-form philosophy

“radical” departure for content storage idea

Store page contents (e.g. markdown) in flat repository with unique hashed ids.
- <SHA256-unique-id>[.vcki?]
Store site structure/hierarchy in master XML file for (hierarchical-)indexing purposes
- i.e. tree.xml
Introduce XML files for other indexing schemes as necessary...
- i.e. {tags|tagging}.xml, bayesian.xml, wikinames.xml, ...the list of possibilities goes on.

Why? 1.5 words: {Flexibil,Simplic}ity