WikiLog
ThoughtStorms Wiki
Combination of a WebLog and a wiki.
See WeblogsAndWiki for other comparisons. This page for the issues of combining within one system.
- UseMod : http://www.usemod.com/cgi-bin/mb.pl?WikiLog
- WikiWeblogs are really cool, combinded! - http://sknkwrks.dyndns.org:1957/writewiki/wiki.pl?PublicWikiWeblogs
- Also see http://ourpla.net/cgi/pikie?WikiWeblogs
- BillSeitz:WikiLog
The problem with integrating wiki and weblogs isn't technical. We value both because they give different ways of thinking about information. I put stuff into my weblog but not my wiki when I think it's ephemeral and can safely be forgotten. (In my mindset, and on Blogger, things that are merely in archives aren't easily revisitable. (Update 2005 : this has changed since I created a RollYo search for all my blogs and wikis))
But then I discover that I was wrong. That they weren't so ephemeral. They are important and as relevant as some of the trivia that goes into the wiki. So how do I judge?
What I fear is that when I make the ephemeral judgement, I'm really saying that I don't know how to classify this fragment, and to fit it into the general pattern. The only way I can think of addressing it, is that it's now. On the other hand, the most insignificant word or two I can see how to classify and connect, goes immedietely into the wiki.
This is why even BillSeitz:FrontPage has an awkward distinction between those pages who's names are WikiWords, and those who's names are munged dates. You can have two different mindsets (WikiMind, BlogMind) when you enter the data.
- some reasons I did it this way (which may help you design another approach) –BillSeitz
** at the time the Zwiki engine didn't have it's own lastEditDate, but just used Zope's lastObjectChangeDate, which would have been fine except that various admin activities cause the latter date to become now() for all pages. So putting the date in the name gave me a more anchored time order
** I wanted blog "bits" to be fully rendered on the FrontPage, whereas that wouldn't make sense for many/most wiki pages
*** part of this is a matter of node length; so maybe an alternative model is to pick a threshhold size and fully render anything small than that
** I didn't want to think to hard about naming each blog bit
*** (This is the point I'm making. Even if all the technical problems are solved. This would remain. – PhilJones)
** I didn't want to worry about name uniqueness
This suggests the ideal Wikilog / Bliki technical functionality. The capacity to add posts NOW under a DateName, then rename those posts later (with all other links automatically updated of course ;-)
Update Sep 2, 2004
This NameSpace issue is the real key. As long as the name-spaces of blog entries and wiki-pages are distinct (as on BillSeitz:FrontPage) you don't get a full integration. Someone writing later can't just intuit the name of the page and make a link to it, they have to go and look it up. That breaks the flow of using wiki. It makes the blog-space a different media from the wiki-space.
Responses –BillSeitz
- True, though that's just the tradeoff in my particular design. Another approach might be to use a single style of naming but pretend to distinguish one type from another by page-length. Another approach might be to have a meta-property that you set as you create the item.
- But for a narrow data-bit, isn't the page name likely to be so long that you wouldn't be likely to guess it? Esp if you want that name to likely stay unique. Though maybe you don't care about that...
- My approach of making BackLink-s visible at the bottom of each page (sorted by mod-date) definitely is a key feature for me. If I'm looking for a bloggish entry, I just go to the page for a WikiName I know I would have referenced in the small item, then I look at my list of backlinks and have a good chance of picking it out from the list...
Compare :
- My discussions with ChrisDent on PurpleWiki