A series of freetext notes, similar to a WebLog, but written within a software application designed primary for some other purpose, so logging happens within that context. A superset to this might be an AppWiki.

Examples:

• Contact Management (Sales Force Automation/[Sales Process Management], CRM), e.g. Salesforce Com

• Collaboration Ware, Project Management Software

• [File Server]: new and changed files in a folder

• software development process mgmt suite (e.g. Rational)

Why write a blogbit within the Apps instead of in a parallel dedicated WebLog app?

• pro-WebLog

  • richer blog-specific tools than other-targeted app might support

  • consistent interface for those tools

• pro-App

  • User/author is already in that app for another reason (updating task status, etc.)

  • blogbit is often just a Description for a structured record that needs to be created anyway (e.g. a sales-call note might be linked to the person/company being called on, might note whether it was a phone call or f2f meeting, etc.)

Is it better to read within the Apps, or via an Rss Aggregator (e.g. Radio Userland, PeerKat, Universal Inbox)?

• pro-RSS

  • easier to stay superficially current (e.g. manager, other third parties)

  • integrated view of all the things you've been involved in at a point in time (notes for self), richer time-anchoring may trigger richer memories and associations ("oh yeah, remember...") (Life Streams model)

  • can integrate into external-web content flow. I think (May'02) this is a fairly bogus idea, though I can think of a few exceptions (e.g. notes about a client prospect integrated with newsfeed about that client). Later (Oct'02) this is making more sense to me, within a Universal Inbox context, so that there's lots of real-work collaboration being promoted in the Universal Inbox.

• pro-App

  • reading is almost like a database report/view, so you can view a stream of notes filtered on a variety of criteria (only f2f meetings, only interactions with a given contact person, all interactions with all people at a certain client company) or levels of hierarchy (all notes for this project, all notes for this phase, all notes for this task, all notes from this person within this phase, etc.). You wouldn't want to try and treat each of those as a separate RSS feed. (Oct'02 thought - the design approach is that a view within an App is like a [URL] call with a set of parameters - just add an extra parameter to receive the results as RSS/XML instead of HTML!)

  • you may wish to follow security controls more easily managed within each App (e.g. if your law firm handles multiple clients in the same industry, you may not want staff to be able to read notes about clients they're not working for directly). (Though many internal controls like this are mostly pointless, just like overly complex publishing Work Flow controls. On the other hand, if you're opening this flow up to non-employees, like contractors, it becomes more important.) (If you follow the design of the previous point, the paramter-generated view handles the security control.) See Private Feed.

  • a blogbit can be packaged with other structured info and can link to related structured records (though it might be possible to pack such links into an RSS feed)

• compromise: have small number of broad feeds available via RSS, but most "do-ers" read within App.

I first wrote about this in Jan2002

Other possible terms: [Web App Log], [Collaboration Log], [ColLog], [Group Ware Log], [WareLog], [Group Log]

User Options Recent Changes Help Page