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.

Filed September 13th, 2007 under Architecture, OpenPlans

No Comments

RSS

No comments yet.

Leave a comment