| |
 |
Thursday, March 28, 2002 |
|
Marc Barrot's outline renderer
The following macro:
<% renderCss ( "C:/Radio/www/instantOutliner/jonUdell.opml", "instant" ) %>
will render my instant outline like so:
(removed, was becoming too much to include here) Nice, Marc! As you can see on Marc's blog, this is an elegant way to manage structured elements that can be included anywhere. The CSS integration, which I'm not using here, adds another dimension of control.
10:12:24 AM
|
|
|
Productivity is the endgame
Here's another great way to use the W3C XSLT service:
- Dave's outline
- Jake's outline
- My outline
Outstanding work on the XSLT/JS/CSS renderer, Joshua! It's amazingly cool to be able to export that capability to the world by blogging some URLs, eh?
As to the meaning of what's happening here, some comments picked out from Dave's stream-of-consciousness outline tell the story:
We've been using this tool since November, internally at UserLand. We shipped Radio 8 with it. When we switched over our workgroup productivity soared. All of a sudden people could narrate their work. Watch Jake as he reports his progress on the next project he does. We've gotten very formal about how we use it. I can't imagine an engineering project without this tool.
Eventually this way of working together will happen for all professions. This is the killer app behind blogging, I'm pretty sure of it.
So am I. That said, there are many, many more pieces that need to fall into place. People are going to look at this and say ugh, the outliner's UI sucks. Which it does. They're going to lament the lack of robust search, persistent URLs for outline subitems, and a million other things. And they'll be right. But these will be good problems to have, if what precipitates the whining is a general adoption of a style of networked communication based on structured messages and a willingness to work transparently. We can solve those merely technical problems. What's been missing is a context in which to address them in productive and useful ways.
"All of a sudden people could narrate their work. Watch Jake as he reports his progress on the next project he does."
This is the key. It's not about XML, or HTTP, or outlining. It's about people evolving to the point where they publish what they're doing, and subscribe to what other people are doing, in just the right proportions, so that there's maximum awareness of shared purpose but minimal demand on the scarce resource of attention.
Don't just focus on the outliner. Look at how the people who are proficient with it structure their work. That's the endgame. Software tools (like the one being boostrapped here) are a necessary, but not sufficient, means to that end. Once people figure out how networked communication is really supposed to work, though, software's going to get much more interesting than it ever has been.
12:17:52 AM
|
|
 |
Thursday, March 14, 2002 |
|
Ask and ye shall receive: Hannes Wallnofer's Bloggenmoz
Hannes Wallnofer writes:
Welcome to Bloggenmoz!
This site was created to document my attempts to add support for the Blogger API directly to Mozilla Composer . What this means is that people should be able to post to their weblogs directly from the HTML editor that comes with Mozilla. I've started coding over the weekend and already have a functional prototype. Here's a screenshot: (Click here if thepopup script doesn't work) You can get my current code from the download page . You'll also find installation instructions as well as some notes and caveats. Please remember that this code is experimental! This project was inspired by Mike Lee's MozBlog, a Mozilla extension thatis embedded in the browser window and allows for quick posting of smallertexts (think bookmarklet). In contrast, Blogger API support in Composer wouldbe ideal for writing longer texts, something that is very unconvenient withbrowser-based solutions. There's more to come soon - stay tuned and let me know what you think!
I think things are getting really interesting, again! If you try this, remember to enable this Pref. Here are the settings I'm using in the Publish dialog:
It's so nice to have the use of a table editor, once again! As Hannes notes in his blog, there's more to do. This really does want to be embedded in Radio's UI, not external to it. And of course the recent innovation around RSS titles is, I guess, not yet available through the Blogger API, so I'll probably go back and title this item. Oh, and I had to tweak some image URLs in source mode in order to refer back to Hannes' site. All this can get sorted out relatively quickly, once there's a critical mass of people who are in a position to use, and appreciate, the full power of hypertextual writing with words, pictures, tables, math, and vector graphics. Bring it on!
(PS: Hannes, some words ran together and I had to do some additional touchup in Radio's editor. But...this is way cool! Thanks so much!)
9:53:29 AM
|
|
 |
Monday, March 11, 2002 |
|
Titled items added to Radio!
Thanks so much for adding the title feature!
Should the Link field default to the permalink of the item being written?
Hmm. There's a difference between what I'd want the HTML reader to see:
Most excellent!
and what I'd want the RSS reader to see, in a titles-only view:
Most excellent!
7:53:41 PM
|
|
 |
Sunday, March 10, 2002 |
|
Helping Marc with a Radio script
Marc Barrot's still stuck. I'm hardly an expert on this stuff. If anyone wants to correct or augment my advice, please do.
11:34:29 PM
|
|
 |
Monday, March 04, 2002 |
|
Oops, broke the News page
Steven Vore pointed out that the previous item breaks the News page. I removed the angle brackets surrounding the word "title" as a workaround. If you've already received the feed containing that item, though, you should probably unsub/resub. And, I guess, avoid using amp-lt-semi until this gets sorted out.
Mark Pilgrim ran into the same thing.
10:54:42 AM
|
|
 |
Thursday, January 31, 2002 |
|
The uses of indirect discussion
Sam Ruby and I have been having this oddly indirect discussion here on Radio, and it's made me think. At first glance, the indirectness seemed like a flaw in Radio. Were it a discussion system, like Manila and countless others, we'd be talking back and forth directly, and others would doubtless be chiming in too.
Many believe that every document on the web -- even every paragraph or sentence -- should be, at least potentially, the root of a threaded discussion. I have thought so too, for a long time. But now I'm wondering whether this "bug" in Radio is really a feature. Writing for Radio feels different than writing for discussion groups. It feels more like writing for publication. It makes you want to think through what you say more carefully, and not shoot from the hip.
I've been a writer all my life, and one of the lessons I've learned is that the process of writing -- done slowly and reflectively -- is closely related to the process of learning. I don't really know something until I can explain it, and I can't really explain it until I can write it.
In this age of instant communication and message overload, it gets harder and harder to find time to think things through. Maybe every document on the web shouldn't also be a conversation. Maybe we also need some quiet places in which to think and write.
9:14:39 PM
|
|
 |
Thursday, January 24, 2002 |
|
Sam Ruby writes:
Many SOAP stacks these days come with automatic roadmap dispensers. Simply append a "?WSDL" to the URL and out pops the description of the service. Many alpha males will tell you that they don't need to ask for directions. But I suspect that these roadmap dispensers will be heavily used.
Absolutely. When services are consumable by namespace completion in an editor, like so:

Then we get the kind of network effect we all want. What matters is not only the number of SOAP endpoints that exist, but the number that are actually used, and "roadmap dispensers" are critical. Automatic testers are darned handy too:

Necessary? No. Desirable? Hugely. I want this, everybody should want this. And it looks like we're going to have it. The tension here, as always, is between what is considered the bare minumum interoperable core, and what is considered optional. If WSDL is not considered core, and isn't everywhere, that will compromise the vision displayed in these images. If it is considered core, it raises the bar on resource-constrained implementors. There's an inevitable and natural tension between these two positions.
John Robb wrote privately to say:
Jon,
You are pointing to images on your Weblog that are located in your desktop folder (so they are not visible). They have been upstreamed to your cloud.
Thanks, John. This is exactly what I was testing. Here's what I learned:
-
An image in or below /www/radio/images will be upstreamed. (I think automatically, but maybe it has to be kicked -- Publish->Entire Site?)
-
Such an image, loaded into a separate IE window, can be dragged into Radio's MS DHTML edit control, and will be inlined.
-
By default, the URL is like 127.0.0.1:5335/images, not ./images.
-
I guessed that Radio would translate that on upstreaming.
-
It didn't.
-
So you have to use Source view in the editor, and change 127.0.0.1:5335 to .
-
Then, Publish directly. If you switch back to WYSIWYG view, the editing component (which Radio does not control) will revert you to 127.0.0.1:5335.
Obviously most users are not going to figure this out. Just as, years ago, most did not figure out how much writing and illustrating and cross-referencing power was built into the mail/news client that they ran every day. We have a chicken/egg situation here. Hypertextual writing, using words and pictures and links, with fluid transitions among local and remote resources, remains difficult. This exactly parallels the WSDL discussion. Until users can take for granted that in any web writing environment, images and text can be dragged and dropped, and everything will just work, we'll keep missing out on an important network effect.
And now, I'm going to switch back to Source view and re-fix those links which the Edit control has re-broken. Radio can fix this particular glitch by rewriting what the DHTML edit control does, before upstreaming. But the general issue of how we get to a universal canvas remains, well, a general issue.
PS: One more wrinkle. Using . was OK for the homepage, but I forgot this item is echoed into categories and an archive page. So I'm redoing the . as a full reference to the public site.
9:22:04 AM
|
|
© Copyright 2002 Jon Udell.
|
|