Once frassle gets out of alpha, it would be nice to make it super-easy to try on your own machine. Since I think one of frassle's most compelling uses is behind a firewall, we should make it easy for any networked PC to become a frassle server. Here's the process I think might work well:

1. Download a 200MB ISO image and burn a CD.
2. Find an unused PC with a network connection.
3. Insert CD, turn on PC.
4. The PC displays a screen that says something like "You can now connect to frassle at http://192.168.1.114/" in big letters across the screen. Clicking that would launch a web browser right there.

Something like LAMPPIX would be a good basis for this. By default, the ISO could be configured to use a RAM disk for testing, but ideally you'd have other choices. For example, you could choose to store frassle data in a standard place on an existing Windows or Linux partition, or create a new partition; and the frassle ISO would autodetect this data after rebooting. That way you could put frassle on your intranet by finding an unused PC, popping in the CD, and turning it on. When a new version of frassle came out, you could shut down, pop in a new CD, throw away the old one, reboot, and bam! All set.

Going further, it would be great to have easy-to-install packages for Windows (like EasyPHP) and various Linux distros too.

Sounds like a good project for a summer intern, no?

There are two conflicting designs for RSS aggregators. On one hand are email-style three-pane readers, typically found in desktop aggregators such as SharpReader, RSS Bandit, and others. On the other hand are blended-feeds aggregators, like Userland's Manila and Radio, which take the latest news from all of your subscriptions and blend it into one big time-sorted page.

Dave Winer strongly advocates for the blended-feeds style. When I first heard him rant about this, in person at a Berkman Thursday meeting, I didn't know why he cared so much. I had used both styles of aggregators, and I thought the difference was really just an issue of taste.

That was when I had a small number of subscriptions, around 30 or 50. Now that I have over 200, there is a major difference. In a three-pane aggregator, when you can't read all the news, you skip feeds that aren't often of interest. In a blended-feeds aggregator, you skip postings that are older, or have boring-sounding titles and no pictures.

While the latter seems like a more arbitrary way to prioritize your reading, it actually has some advantages. If you have a big set of feeds that you kinda-sorta read, but aren't devoted to tracking every last post, it works better. With a three-pane aggregator, there is some point where you just give up on a feed—it gathers messages for months, but you can't remember what the hell it is, so you never click it. After a while you can't remember what it's there for and the 312 unread posts makes skimming it too intimidating. Unless you regularly schedule time to organize your subscription list, it just sits there. (Maybe we need a way for computers to emit smells, so you can actually notice it rotting?)

On the contrary, with a blended-feeds aggregator, you'll occassionally see a message from that feed. Either you'll like it and keep the feed, or you'll realize what crap it is and unsubscribe altogether. You're less likely to maintain a meaningless subscription. And the subscriptions you do maintain will all be given a fair shot: your existing preferences for a certain core set of feeds don't preclude everything else to the dustbin.

There's a reason this advantage isn't evident to new aggregator users: it depends on a particular memory threshold. For a while, it's easy to (implicitly) rank a bunch of feeds in your head. Some you check every time they go bold, and that's great, because you never miss or wait for news from the sources you care about. Others you check at specific times, like the comics I read every morning. Others you might save for when a certain topic crosses your mind, or simply for when you're bored.

Up to a certain number of feeds, your mind is capable of telling you when to read what with pretty good accuracy. But at a certain point, the accuracy starts falling off. It becomes risky to subscribe to a new feed because either (1) you will love it and it might push off something else you care about, or (2) you'll not love it enough at first and it will fade into the abyss. But what if it starts to be interesting again? You're not giving it even partial continuous attention, so you miss it.

That's right: in an aggregator that seems designed to help you read every post, you actually miss all sorts of interesting posts. In one that seems to make it difficult to ensure you've read all you care about, you're relieved of caring—and in the process, you're more flexible and open to exploring.

Nonetheless, both approaches have their advantages. Thus the problem is that you're forced to pick one or the other for your whole aggregator. No fair! I have feeds from friends, colleagues I respect, serial publications I want to follow every bit of. I also have feeds from a gazillion social software nerds where I often want an update but can't possibly follow everything.

So my aggregator should let me put the most important feeds on watch lists. It should make sure I've read every post on my watched feeds. And it should let me quickly skim everything else in the more flexible, more efficient blended-feeds format.

link

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:

• you can categorize individual files
• you automatically get the same renaming, editing, deleting, and sharing/privacy options as anything else in your blog
• you can easily browse by timestamp or category
• you can subscribe to updates
• you can use the regular search to search the HTML representations of files; i.e. you get to do text searches of PDFs and MS Word documents.

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!

link

Jessica has some interesting thoughts on using frassle within an intranet, which is something I've been thinking about a lot recently. Particularly important is her list of crucial features that frassle is missing. I'll let you know my plans for each below.

file/picture posting

• I think I could start this with a simple file attachment mechanism, and perhaps later expand it to e.g. be smarter about handling photos. Still, this is at least one version away.

user documentation

• I have started writing a lot of this, and over the next 2 months I think we will be in much better shape in this regard.

privacy options

• I think I have a simple but reasonable design for this and am going to try it tonight.

trackback

• I haven't quite figured out the design for this. Sending trackbacks is easy — frassle can just look at all your links and try to find trackback URLs at each one. But receiving trackbacks is tricky. Ideally, a received trackback would tell frassle where to get that blog's RSS feed, and then frassle would simlply start aggregating that feed and properly threading its notes with other notes in frassle. Trackback provides a lot of this information, but I have the feeling trying this will show me some unexpected difficulties and limitations. Therefore, I've been procrastinating until I can set aside a good chunk of time to experiment and back down if something goes dreadfully wrong.

link

Currently, you can't use a feed from a block in a noteset expression. For example, if you write the noteset expression:

feed="http://frassle.rura.org/rss?block=1"

which points at recent comments on my blog, your block will contain nothing. Nothing, Lebowski.

What you really need to do in order to get the contents of another block is copy over that other block's noteset expression. This is kind of hard to do unless you actually own that other block.

However, this trick you tried is the logical thing to attempt. So in the future, I'll have the publisher recognize what you're doing and replace that feed="…" expression with the original block's expression when feed you're referring to comes from a frassle block.

Here's a sloppy workaround, though:

1. Open, in your browser, the RSS feed for the block you want to duplicate. Example.
2. Near the top of the RSS file, you'll see an XML element called <description> which contains a description of the feed you're looking at. It looks something like this:

   <description>This feed is generated dynamically by frassle. See http://frassle.rura.org for more information. The noteset expression used is: responds_to( feed = "http://frassle.rura.org/Directory/rss?id=1" ) & not ( feed = "http://frassle.rura.org/Directory/rss?id=1" )</description>

3. Copy the underlined part, which is a noteset expression, into the noteset expr box in the block you're creating.

Note that if the block's owner changes its definition, your block will not change since you've copied the original search expression.

Frassle's upcoming Publisher (formerly Site Builder, formerly Page Builder) component makes it possible to create many types of web community sites using frassle in the backend. Unfortunately, it doesn't make it easy. If you want to make a weblog, you have to create a site, then create some pages, the add some blocks to those pages. To create the blocks you have to know your RSS feed's URL and write strange "noteset expressions" that aren't non-programmer-friendly. Frassle needs a way to make this really easy, particularly if you just want to make a weblog.

Here's an obvious idea I hadn't thought of before: publisher scripting. Frassle developers write some code that describes how to prompt the user and take actions based on those prompts. For a weblog, you might prompt for the user's name, a title and tagline for the weblog, a note about the author, and some RSS URLs of feeds that the user reads. Different publisher scripts could make different kinds of sites that show off a variety of frassle's strengths.

The scripts could be Perl code, but they should use a well-defined, stable vocabulary (API). The goal is that a programmer should be able to read about how publisher scripts work, then sit down and write one. That script should be easy to deploy in any frassle installation, much like the current page block system. (A page block is a template that renders a list of notes inside a page. For example, you might render the full or excerpted text of your most recent entries in a block in the center of your page, and show a list of titles in the right column.)

These types of modules — intermediate in complexity and easy to share — are crucial to my goal of opening frassle development to new contributors. Frassle desparately needs new authors and critics: I've gotten used to many of its quirks and deficiencies, and countless potential improvements escape my sight. But it's currently just impractical for others to contribute without my intimate involvement. There is no downloadable code, CVS repository, or documentation. But these are easy to fix. The important thing is that there be a gentle slope into development. Roughly:

1. Frassle piques your interest.
2. You start using frassle to bookmark some stuff, and perhaps use the aggregator.
3. You start using frassle to post some notes and participate in discussions.
4. You build a site using frassle publisher.
5. You want something unusual on your frassle site, so you develop a special page block.
6. Other people beg you to show them how you built your site. You write a publisher script that allows others to create something like it easily.
7. You want something I can't even imagine yet, so you make (or simply suggest) changes to frassle itself.

That's right… weblogs are just a gateway drug! (=

The functionality and power in frassle is growing a lot right now, with the creation of the site builder and usability improvements in the aggregator. The site builder will keep me occupied for a while, but when it's done it will demand a new kind of feature: support for collaboration.

Collaboration is an interesting issue in frassle. On one hand, a fundamental assumption in frassle is that categories are personal and we need ways to gradually learn correlations between different organizational systems. On the other hand, there are some times when you want to work within an explicitly agreed-upon category hierarchy. This usually happens when you're working in a close-knit group with clear goals.

Right now I'm involved in starting this kind of group. It looks like our first project will be developing a comparison of aggregators. I think it would be useful to use frassle to build this comparison: a note would represent one aggregator, and we'd categorize that note according to what features that aggregator had. For example, we'd create a note for SharpReader and put in under /platform/Windows, /display style/3-pane, and /features/tracks which items you've read.

The category system here is something we want to all share. It probably won't be feasible for a single person to review every aggregator, but we have to stick to the same criteria.

Today frassle binds one user to one feed. So I may well have to start this project by creating a fake user account, giving the password to my colleagues, and (as far as frassle is concerned) all acting like one person.

This is kind of like stepping into a corporate role; you log out of the frassle user that normally catches all your writing—the personal role—and enter an entity that looks like a user but is actually the collective effort of whoever has the password. This is an appealing metaphor and I wonder if all frassle needs is a way to do this without the graceless kludge of sharing a password.

Other possibilities:

• Shared categories. All users have access to a certain set of categories. They can each add things into one of these categories, as well as add, remove, move, or rename the categories themselves.
• Subscribing to categories. All users subscribe to one user's category tree. When that user changes her tree, the changes are offered to each subscriber, who must accept them into their own tree. This is an interesting possibility, and could perhaps be a layer on top of shared categories. Also, it is not just one-way; if Alice and Bob wanted to fully share control of a tree, they would both subscribe to each other. The change approval system would be a good way to ensure that changes are made obvious to everyone involved.

Still, all of these approaches are pretty abstract. How do you think it should work?

link

Not exactly. Measuring popularity is useful, but the point of the metric I was describing is not just to measure quality, but to encourage contributions. Think of it as a high-score board for frassle: here are the people who did really well. There should be straightforward, but not trivial, ways to bump up this score. The prospect of getting a high score will encourage users to contribute in the ways favored by the metric.

link

The personal reputation thing would just be a little gimmick. The whole point is to define a metric that correlates to positive contribution to the frassle community, not to offer stars and hearts like Orkut. I wasn't thinking the reputation would be determined directly by other frassle users, although it should somehow take into account interacting with other users. But maybe also page popularity, frequency of writing, and more. I guess perhaps the hard question is: what does it mean to contribute usefully on frassle? Is it just writing a lot? (That seems overly transparent.)

link

I was talking about two things.