roy

i want to apologize for this post. i was about to pass otu (lunesta induced), when i had an idea for deki wiki which i think needs to be captured now (in case i forgot tomorrow morning). so if this makes no sense ... sorry

abolish the site navigation. problems as i see them: we can't organize shit inside wiki.opengarden.org. it's hard. i'm not even relying on the nav pane most of the time. if i wanted the site navigation, i'd just push wiki.tree() out to skinning variable. 

it occured to me when i was thinking of our last blog post about an xml-rpc extension wrapper in php ... the location of the information is under a user page on our wiki ... not really the correct spot.

but who cares!

instead of having an automatically generated opt-in hierarchy, each new page should start from scratch. it should be forced to make it association to whomever it wants to generate that navigation.

could the freeform association ever mesh with the directory listing in a usable UI manner. i know i'm probably in the small minority of people who think the new link dialogs are actually awesome, but we've already done it there. two modes: search for freeform, and directory for listing.

this mentality is equally applicable when creating relationships between pages.

currently, the hierarchy is very strongly embedded inside deki wiki. but what if we took it step by step. 

first step, remove the existing nav pane from the UI... second step: create a new dialog called "associate page".  implicifit associations to parents, children, and siblings are already created (hierarchies aren't removed in this scenario).

the dialog has a similar view as the link search dialog, except it lets you make muitliple selections; each selection becomes an association. screw that; first iteration, you simply match all pages which have the same tags. you can choose to remove any of those pages from your list (wont' delete the tag, just store a ui state). 

these associations show up along the left side, where the old nav pane existed. you can move these around all over the place. oh snap, maybe you can even do an inline display title edit. that would be nasty. how the hell could this be done accesibility? i've gone ahead and created the js dream version ... but it needs to be accessible first.

i mean, for larger wikis, hierarchies break down incredibly. its impossible to get a few people to create correct hierarchies ... and then there's always overclassification of content to the point you need like 10 pages to find what you were looking for (a search would have performed remarkably better).

each additionally page could be sorted in any order, and you could make an ajax call to see subchildren and sort those, to

Pros: it demphasizes the hierarchical behavior for trying to organize content. people keep messing with hierarchies by organizing, organizing, organizing ... it becomes equivalent of trying to fit a  triangle into a smaller circle. It requires no API changes: this feature could be built in parallel with minimal API work - putting together a PHP prototype would be trivial. (Maybe my weekend activity if sober roy doesn't shit all over this idea). hierarchies are awesome when there's a clear path to follow to apply permissions, and delete files.

so maybe in the same we decoupled the display title and url title in the front-end, we can also ... shit shit shit lost the idea. this song is making me do a really gay dance in my chair. oh yeah, we can decouple the "relationships" between pages with the "organization of the pages". relationships = tags, hierarchy = organization

i'm working on the deuce skin (finally). this would be an intersting for me to try it out with the enterprise skin. woot.

cons: it's a whole knew paradigm for the users. do people understand tagging? right now, tagging sucks as a feature, so i don't even know if it will work. fortunatekly, it's on tap to be fixxed for the next big release, and i'm going to write the specs for it.

well, the freeform associations eventually lead to a wiki that's completely unmanagable (since everybody's doing whatever). the biggest question: will it even work? my mind, right now, says yes. although it refuses to let me see through the haze for the solution.

for the record, aaron had a similar idea to this, but since he never got it down in writing, i win! (that, and i'm spectangularly awesome.

good god, this lunesta really fucked me up. time to try to cral back to bed.[

please, p[lease make sense tomorrow morning