Proposal // question:
Weird, but our architecture is weird.
[ETA: Please let me know if I got any current architecture details wrong. Sorry, this makes it worth 1,087 words instead.]
This asymmetry really bothers me:
I don’t have it quite right, I know, but that’s sort of the point. I feel like /wiki and /blog are the ones that are confusing and wrong, like we should offer multiple wikis and blogs per project. The glossary-of-terms wiki, the public site wiki, the admins’ notepad wiki; the news blog, the development blog … On the other hand, I don’t want task lists >> tasks in the future, though I do still want them to exist but in a very different form, so I don’t know whether that keeps the symmetry or not. Depends on how firm a definition “collection” has?
I want to note that I don’t *think* it’s entirely an aesthetic preference; I feel like the asymmetry might cause minor headaches if we try to, ah, “desilo” and integrate all content. (a wiki page has a task, a blog post has a task, a task has a wiki page, a task has a file, a wiki page has a file … ) Also if we ever try to offer all features equally. (which we currently don’t — wiki is “more fundamental” than lists, tasks and blogs.)
Yeah, ’cause what goes into those two empty cells in the table are really “PROJECT” and “PROJECT WITH /BLOG APPENDED” … but that’s not right, of course, because “PROJECT” should be above the whole table, uniformly, as the top row. I feel like I’ve just proven something but I’m kind of at a loss.
Hmm, on the other hand, in the same way that I now envision (thanks, Jeff!) that a task is simultaneously content (task data) and associations to other content (tasklist data), you can also describe a wiki page as content (the text of the document) and associations to other content (wiki links) … that feels shaky, though.