March 21, 2006

OPML to Wiki

Phil (yesterday) :
Aside : I don't think Winer really "gets" wiki. If you want to take him on, that's the front to do it.


Dave (today) :
How long will it be before there's a wiki that supports the MetaWeblog API? ...

Anyway, send me a pointer to such a wiki, and I'll try to get the OPML Editor working with it. If there are problems, I'll document them, and when they're fixed, I'll try again.


Dave may not be trying to "win", but he's sure as hell determined to "succeed". And connections are the secret of that.

Strategic! :-)

2 comments:

Danny said...

What Is Wiki?
The simplest online database that could possibly work.
- Ward Cunningham

Simplest way of doing outlines on a web page? HTML. Simplest way of posting data over the web? HTTP.

Composing said...

Yeah. To me, simply plugging the OPML Editor into a wiki doesn't look like it's going to create a lot of value.

But don't forget that part of Dave's modus operandi is to address a lot of simple, quick pieces of what look like rather minor functionality, that start to add up.

After all, how hard is it *really* to maintain a weblog in an HTML editor? Or use a dedicated weblog client? (But now people like Les Orchard who are using the OPML Editor for blogging seem very impressed by its advantages.)

How hard is it *really* to access RSS feeds in an email-like client rather than a "river of news"? Or post a link to an mp3 file and ask people to download it through their browser? Or visit a blog everyday to see what's new? :-)

I'm pathalogically anti-tree and in favour of graphs. But one of the most common requests I have (from my infinitesimal user-base) for SdiDesk is for some kind of outliner-like view.

Obviously you can already do nested bullet-lists like this :

* blah

** blah blah

* blahhhh!


But there's no expand / collapse promote / demote etc.

The other request I get is for Wikipedia-type table-of-contents with named subsections.

So, in my future plans I've started to realize that pages in SdiDesk *could* have some kind of tree-structure rather than just being a flat text string. Which suggests a role for an outliner-like editor.

I agree that XOXO makes a lot of sense as a microformat which is designed to help you scrape data out the human-readable XHTML page.

I don't argue for the virtue of the OPML format. And I'd be inclined to prefer ReST for the interaction. But remember, it's the OPML ecosystem that I'm impressed by, not the individual components.

Simplicity or otherwise is relative to that. Actually what is it that "worse is better" says? It's slightly better for the "implementation" to be simple than for the "interface" to be. I'm not quite sure how you map that across to this domain but it's worth pondering.