It occured to me after writing InfoCentricTargetUser, that even within the category of Information workers, there is a distinction between people who's main job is to worry about keeping on top of bits and pieces of information versus people who also obsess over ending up with a coherent, well-crafted corpus of documentation.

Bits and pieces are:

• Small in size
• Ephemeral
• Not really comprehensible taken out of context
• Reactive or provocative rather than explanatory
• ie. You know, that last meeting we had on whazzats really got me thinking that we should follow-up on wimples.

Documents are:

• Large in size
• Permanent
• Coherent, discrete units
• Explanatory
• ie. Documentation of the decision making process that led us to select Vendor B.

The problem is that most applications conflate the two, provide the same affordances for both use cases. Or rather PIMs are supposed to be for the former and things like wikis and Word are supposed to be for the latter.

The problem is that dividing up information by application doesn't make workflow sense, so users end up using the same tools to meet both needs.

• Bits and Pieces often times are collected in preparation for the crafting of a full-scale document
• Bits and Pieces often times provide valuable context for a document. (ie. Email thread conversations leading up to a document. Email thread conversations about a document before it is redrafted.)
• As a result, it is often useful for people to see their "coherent" documents in the context of the relevant bits and pieces that came before, during and after the document.

On the OSAF wiki, we've attempted to separate bits and pieces from documents by having the Journal wiki and the Chandler wiki. However, the stark separation makes it very hard to experience are mostly baked Chandler wiki documents within the context of the discussions and loose ideas in the Journal wiki. Conversely, sometimes, what starts out as a bits and pieces note in the Journal gets massaged into a full-fledged document, but is left within the wilds of the Journal simply out of inertia. As a result, the Chandler wiki is constantly being polluted with bits and pieces and the Journal is filled with valuable, explanatory information that gets lost in the noise. Both become pretty messy, incomprehensible places to store information. Which is ultimately what the wiki is: an information storage tool, as opposed to an information management tool. ChaoLam: Don't quite under this para, I think you're mangling your syntax

Does this distinction between bits and pieces and documents exist in David Allen? Sort of. I suppose documents are reference items? But it seems like in Chandler, it would be useful to "file" or "tag" non-reference items too...so that you can see a project-collection of all relevant documents within the context of related bits and pieces. ChaoLam: David Allen does distinguish between reference items and projects. I think what Chandler allows you to do is to tag something as both a reference item and belonging to a project which GTD doesn't allow for being a physical world system.

This is why we need to have a "Resource" kind. The ability to distinguish document items from bits and pieces. And both documents and bits and pieces are then taggable. ChaoLam: This make sense to me. Although, in the near-term, couldn't we just have a "reference" collection, and a project collections? Or is this confusing just as a mycalendar collection is confusing in your scheme of things? MimiYin Yes, I think this is another example of the importance of distinguishing between types of attributes so that not all attributes are thrown into a big soup of "tags". Labelling something as a calendar item or a reference item is semantically different from saying that something belongs to project x and should be reflected accordingly in the UI presentation of information.

This would help Information workers who deal with maintaining "coherent" long-term documentation differentiate between substantial resources and bits and pieces of information without forcing them to extricate documents from their bits and pieces context.