A "collage" is "the assemblage of different forms creating a new whole."

It's based on the French word, "collé," for "to stick."

Looking at wiki as a collage, we can think of ways to improve it.

Basically, you want to make it easier to stick things to the wiki. Once it's on the wiki, your WikiCommunity can work to organize it. But first, you've got to get the stuff on there. This is a ContentRouting problem.

This suggests making it possible to send different things to wiki:

If we do this, our vision of wiki changes from "community HyperText authoring site," to "community DataBall."

This is related to the idea of a "group server" from the OneBigSoup page. Likely a wiki that did all these things would start to look like something else. Document editing would be a feature of the "wiki." But not necessarily the center of the wiki.

That said, documents have a nice way of gluing things together – especially considered from the document-as-in DocumentsVsMessages perspective.


This isn't a new idea. People have talked about e-mailing wiki for a while, and some wiki have implemented it. Most wiki support file attachments. Automatic pictures inclusion, I'm not so sure about.

What this page is mainly about, though, is viewing wiki as a collage.

When you send stuff to a wiki, you could tell it where to go. Or perhaps you could let it sit in a miscellaneous bin.

I've been thinking that there should perhaps be something like "sticky points" or "hot spots" within a wiki.

If you make a reference to a non-existant picture on a wiki, and then go into an image editing program- When you save, and say you're working on CW, it should be able to list the sticky points.

This helps save you from the Visual:LongImageIncorporationProcess. You don't have to go manually bouncing files around off filesystems and the like.

I suspect much of the reason we don't have more e-mail driven tools, is simply because most of us here don't understand e-mail related interfaces very well.

It'd be great if you could write an e-mail to "", and have the contents appended to the page. Or the page created, if it's a new one.

The sender could be identified by email address, and automatically associated with a user.

If the pagename had "Picture" at the end, and it had an attachment that was a GIF, JPG, or PNG, then it would make the portrait page and upload the image to it.

If the pagename had "Portrait" at the end, and it had a similar graphic attachment, it would (Lion crosses his fingers) run a face-detection algorithm on it, choose a square region enclosing it, resize it to 48x48, and put that on the portrait page.

Bam! Instant emotion facial expressions, if you've got a camera-phone that sends e-mail pictures.

WikiCommeUnPêleMêle? could be a french adaptation of your french "collage" ;) Neat idea Lion. How about music, voices, mpeg and whatever adapted on a nice UserInterface like 10x10 or on a newage aggregator like CraoWiki:VeillerAuGrain ? I'd like to imagine it for any uses of a future World Wine Wiki ?

I have a procmail filter for that will post any SMS or MMS (image attachments) on my wiki blog. I can do the same thing or something similar for Community Wiki, but I'm not sure how useful it will be. Do you really want to try something like that?

Here's how I would specify it:

Community Wiki Posting: Foo, where Foo is the pagename
text and plain text attachments will be appended as well; image attachments will be posted to pages with the appropriate name
text will be appended to the page, after a level two heading saying "Mail from received YYYY-MM-DD HH:MI"; images will be posted to a page, and if the page already exists, a number will be appended to the page to make it unique

This approach has the benefit that you don't have to rely on a catch-all email address; instead it will work for any single email address where you can install a procmail filter.

I would love to install something like that in instead… Can I use

Perhaps I'm missing some of the connections that support the ideas on this page, but it sounds to me like what is being described is falls within the scope of RssFeed?(s) that have inclusions.


  • The RSS feeds that I get from Flickr using SharpReader? present me with a neat thumbnail of the image.
  • I gather 'podcasting' (which I have only had a tiny bit of experience with, so I may be wrong) is all about enclosing an MP3 or equivalent file within a RSS feed.
  • Some of the tagging projects that I am familiar with are starting to incorporate mete data into the feed, and I can see no technical reason that my client-side applications could not simply process (or render) this information.
    • I think this is also in-line with the some recent chats here at cw: about client-side filtering of RecentChanges)

If these observations are pertinent, then it seems to me that WikiAsCollage needs to be more tightly defined as a contributor of certain types of information or data, rather than as a central repository for a signifiantly expanded set of data types such as images, sound files, etc.

Mind you, I'm not advocating against the idea of expanding what wikis do. I am simply wondering if there isn't a "natural" set of capabilities for wikis, just as there is for many other tools. If so, then it may be appropriate to guard against some feature creep, and risk seeing everything as a 'nail' to hit with a (wiki) 'hammer'. Hence, I wonder if Wiki should become a collage?

Oh, I see.

Actually, I'm intentionally generalizing, and, in the process, turning the idea of a "wiki" into something that is not a wiki.

It may be better to think of the WikiCommunity, rather than the WikiEngine, the software.

The vision is of us as people who are exploring the web, and "processing" it- making sense of it.

Imagine that instead of a wiki, we have a "data ball."

Whenever we see something that we want to organize in our data ball, we throw it into the ball.

Then we organize it on the other side, and fit it into our output- our understanding of the world.

In terms of wiki, that output is documents. But as we move towards OneBigSoup of mediums in the future, "wiki" will melt into these sort of "data balls." That's what I'm thinking of, with "collage."

Here's a use case from SocialBookmarkingToWiki:

I'm wondering: "What happens if we think of a wiki as a more general collage, rather than just a link collage?"

The thinking may turn up nothing, but it's a way to explore the concept.

If the result is not a wiki, that's okay with me. OneBigSoup. Wiki's children.

It'd be nice to throw quotations at wiki pages.

If we're reading a page, and it has a nice quotation that we would like to attach to a page in our wiki (abstractly, in the language of the "collage"- a "node in our wiki,") then we can route the quotation to the page, along with attribution of source and title.

We can ride this on top of SocialBookmarkingToWiki, by making use of the description, and retrofitting the unalog bookmark to use selected text to fill out the description.

Then when we ride back to the wiki page, we will see all the quotations and web pages that we thought were relevant to it.

Yeah, neat idea.

I think the part that would require the most effort (not necessarily difficult effort, just time) would be to enable all of these other applications to conveniently let the user send bits of data to the wiki. Getting the DataBall to receive the bits will, by contrast, be easy.

On the receiving end, I envision two kinds of things be attached to each WikiPage;

  • the wiki page as we have it now
  • a DataBall related to that page (right now I'm imagining the DataBall being technically organized as sort of a database filesystem, i.e. a database that holds (or more practically today, point to) entire files of arbitrary type.

We could be UsingTags on this wiki, without actually writing any code for CommunityWiki;

We could just set up a UnaLog server, dedicated to just communitywiki, and hyperlink it from the RecentChanges page.

If we wanted to be really clever, we could even theme it right, and point to it from

Define external redirect: SharpReader WikiCommeUnPêleMêle RssFeed

EditNearLinks: WikiCommunity HyperText UserInterface WikiPage WikiEngine