13 Oct 2004
Ideas for hooking frassle into Planet OSCOM's aggregator.
13 Oct 2004
Ideas for hooking frassle into Planet OSCOM's aggregator.
2 Sep 2004
30 Aug 2004
After much background thought, I believe I know how to best add file management to frassle. (This is a long-term goal, but has been getting some attention recently.) It's simple.
Each file is a blog post, just like any other content fragment in frassle.
The note body, when viewing the blog on a web page or RSS feed, shows an HTML representation of that content fragment. There is also a link to the original file. So if you uploaded a PDF, it would get converted to HTML for the note body. A photo would be represented as a thumbnail. An XML document would apply any appropriate XSLT transformations and display as XHTML or just a document tree. A text file would become preformatted HTML. An unknown format would just give you file name and size.
This approach has some significant advantages over email-style attachments. In no particular order:
On the other hand, if you're used to handling files as attachments, this seems a little weird. Some files just don't stand on their own: photos are part of an album; PDFs are final print-ready renderings of a long-term effort; source code files are parts of complicated projects. If we just treat them all like time-ordered blog posts, won't it just be chaos?
Yes. And that's a good thing.
See, this problem is orthogonal to file uploading. Any piece of content has a context that is more or less important to properly understanding what it means. Showing you that context is one of frassle's most fundamental goals. Time, categorizations, and inter-feed threading of conversations are the basic tools we use to accomplish that goal. Why not expand the challenge? Detecting and expressing more meaningful relationships between content will make all of frassle more powerful.
And hey, I have the feeling categories and timestamps will prevent a lot of chaos by themselves.
Example: One of the first applications of the multimedia post framework can be a tool to help you show posts in context. The scrapbook is a simple list of blog posts (notes in frassle parlance), chosen from any blog. Each note is identified by permalink, and can be included in whole, selectively excerpted, or simply referenced. You can also add text anywhere in the scrapbook. As you browse through frassle, each note has an "add to scrapbook" button.
I like the way this sounds. You could not only use the scrapbook to, say, collect a number of related discussions from around the web—you could actually build photo albums with it! The same concept—a binder with pages covered in taped-on papers in real life, a list of permalinks online—works to gather and share related pieces of content.
Still better, the scrapbook itself can be a piece of content. Under the multimedia post framework, we could represent the scrapbook as an XML document, probably in OPML. Then you can share scrapbooks easily, rename/delete/edit them in the standard way, and even incorporate one scrapbook into another!
27 Aug 2004
Jessica has some interesting thoughts on combining blogs with file management. I think she has the right idea, but she's finding it hard to elaborate the details of how it would work because she's so used to using software that was just built wrong.
Here's what I mean: the concept of a "file manager" as a business/collaboration tool is broken. A file manager focuses on files, which tend to have different formats and byte lengths and gobble up disk quotas and sit in one folder and can only be viewed by certain software. So the file manager's job is to help you navigate each of these things.
None of these capabilities, emphatically not a single one, belongs in frassle or any other blog community system.
Files contain information. Blogs are about sharing information. However, sharing files is a lot harder than sharing information in blogs. This is because:
1. Files come in a variety of incompatible formats.
2. If you have a file, it's difficult to find out:
3. Files expose you to some major risks and annoyances:
If you invert each item in this list, you see the major strengths of blogging over other information sharing approaches. Specifically:
So I think the requirements for integrating file management into a blog community system are simple. Take all the things that make blogging so valuable and easy, and support a few additional input formats.
That is an easily stated but profound requirement. Let's consider the example of the PDF format, which is used for printable multi-page documents. PDF is about your best bet for preserving exact print formatting in a document while still displaying OK on screen. You've probably already viewed PDF documents in your web browser, using Adobe's excellent Acrobat Reader. This gives you some things for free:
But a few challenges remain. Let's go through the positive features of blogs and speculate on how to integrate PDF files.
Hmm. That's not so bad. The other question is, can we do all of these things without compromising the rest of the blogging experience? Clearly, despite our best efforts, a PDF will never be as easy to work with as a plain HTML blog post. It will waste more time and cause more frustration. What about more complex/proprietary formats, like MS Word? What about video? audio? source code? executable software?
Actually, I suspect many of these will have their own holistic community collaboration platforms, using the metaphors for authority, discussion, republication, and convenient use that apply in that medium. Cool.
6 Aug 2004
Great news! Our proposal for a talk called Interpersonal Content Management has been accepted into the 4th conference on Open-Source Content Management. Josh and I will be speaking at 10:15am on Friday, October 1 at ETH in Zurich, Switzerland.
In addition to providing me with a great excuse to travel to Europe, this conference will give me an opportunity to meet many interesting people. On the work end of things, it implies a few tasks for Josh and me to finish before leaving the country:
The talk will be about an emerging genre of content management we call Interpersonal Content Management. Here's the talk proposal:
Content management systems have found two compelling applications. The organizational CMS focuses many contributors around common business goals. The personal CMS, typically a blog, eliminates barriers to individual publishing. While organizational CMS recreates its social structures based on existing business relationships, personal CMS leaves its users to develop relationships from the ground up.
Bloggers express these relationships using simple mechanisms like linking and republishing. Because blogs provide a lasting, personal identity, they make it possible for social phenomena like reputation and trust to develop online. These in turn support informal communities of interest, offering their members ad hoc ways to collaborate without establishing a typical business relationship. We call this blossoming new usage Interpersonal Content Management. It is characterized by a fusion of content consumer and producer roles. By contributing incremental commentary on others' content—even by the implicit endorsement of linking—individuals make connections between their own interests and the interests of others.
Readers already use these connections informally to evaluate the meaning and relevance of new content. But by designing software to make the creation and discovery of such connections easier, we can make interpersonal content management more practical and scalable. First, users are empowered to quickly bookmark, rate, categorize, and remix content from anywhere on the web. Second, the associations they form in these actions are tracked by the interpersonal CMS, which then automatically suggests ratings and categorizations for new content. By making personally meaningful judgments about content, individuals not only prioritize items within their own CMS, but help those who trust them do the same.
This presentation explains Interpersonal CMS in terms of its technological features, the relationships it supports between people, the goals that drive its deployment, and the challenges it will face in the future. In each of these aspects, we contrast iCMS with existing notions of personal and organizational CMS. Specific references will be made to our proof-of-concept iCMS, frassle (frassle.rura.org), which will be open-sourced this summer.