Condividi tramite

Will Intrablogging Succeed in the Enterprise?

  • Articolo

Post Edited ;-) at 1420 hours PST on 29/1/2004

Link to related post: The Semantic Bliki.

 

I don't think anybody can predict whether intrablogging will take off in the enterprise, or not. However, I have come to the conclusion that the blogging medium--as currently conceived--is not well-suited to iterative development. A blog is an easy-publish, no-edit scratchpad for half-baked ideas, announcements, and notes-to-self.  If you really stretch the concept, as technical blogs like this one do, it can be adapted to serial publication; assuming the role of an online newsletter. Again, easy-publish, no-edit. 

 

'So why is a blog a “no-edit scratchpad“', you ask. 'Can't you edit a blog entry after publishing it?' 

 

Well technically, yes. Realistically, it's unwise to do so. Here's why:  Imagine the Inbox from Hell... It's January, 2011 and you install the latest version of Microsoft Outlook. You read six emails. Outlook marks each item as 'Read'. The next day, mysteriously, four of the items appear as 'Unread'. Why? Because their senders each made a minor change. A minor change, sure. But as Yoda would say, 52 minor changes, an Inbox from Hell makes. 

 

Back in 2004... If I update a blog entry--at least given existing aggregator UI conventions AND user expectations--it appears as "Unread" in your aggregator. If I edit a blog entry enough times, you'll eventually stop reading it, right? More importantly, you'll probably lose confidence in the ability of your aggregator (if you have one) to reliably identify the blog entries you have and have not read.

 

Enter the IntraBliki. A Bliki could be the perfect publication vehicle and medium for design docs, product specs, help topics and other items requiring iterative development, inside the corporate firewall.

 

Bliki: easy-publish, edit-forever. 

 

A Bliki is a two-headed beast, the mutant lovechild of Blog and WikiWiki.  If implemented correctly, a bliki would allow me to publish first-draft help topics and product specs to the blog portion of my bliki and thereafter edit it in its Wiki form without affecting the blog. Thus, the Bliki promises to satisfy my desire to ANNOUNCE, allows my subscibers to READ ONCE, and enables me to PERFECT a piece of content, in isolation or with the help of my friends.

Comments

  • Anonymous
    January 29, 2004
    Sounds great. Please post the download link for said Bliki software. :-D
  • Anonymous
    January 29, 2004
    Yeah, some CMS systems like Frontier have a concept of stories vs. posts, where "stories" are permanent, and posts are time-sequenced. But the story features seem to be bolt-on functionality that is not nearly as nice as a Wiki. On the converse, some wikis provide feeds, but the functionality for feeds is weak. A combination like you describe is a good idea.
  • Anonymous
    January 29, 2004
    Seems to me another decent option would be to have smart aggregators. If the aggregator tracked changes (since multiple versions of the post if edited usually appear in the RSS), why not let the aggregator specify (using bold, red, strikethrough or whatever) the changes that were made.

    In this case, you aggregator can notify you that an update to the post occured and tell you exactly what the update was. SharpReader already does this partially. I think that NewsNetWire does as well.
  • Anonymous
    January 29, 2004
    hrm, I'm not using any Bliki tools although (!) it would be a great to connect two tools I do use: .Text and FlexWiki.
    Client-side feature for the .Text (http://scottwater.com/blog) blog editor and as a server-side feature for FlexWiki (http://www.flexwiki.com).)