Donnerstag, 25. November 2004

Journalismus Session Bloggercon

Bloggercon, belatedly: "Bloggercon III was great. I barely had time to digest everything I took in because I was flying off on a long-planned trip the next morning. Here are some notes.

My session was on Journalism: I talked for about ten minutes, outlining some basic things that I think bloggers can learn from professional journalists and vice versa.

What bloggers can teach the pros:
*How to blur the line between the personal and the professional -- creatively
*How to improvise in real time
*How to have a conversation with the 'people formerly known as readers'
*How to be humble -- you don't know everything!

What bloggers can learn from traditional journalists:
*the value of legwork
*the nature of accountability
*The positive aspects of editing
*How to be humble -- you don't know everything!

Then I just opened the mike, which is the custom at Bloggercon, where there are no speakers -- just 'discussion leaders.' We didn't get trapped in the 'Is blogging journalism?' rathole, thankfully; and I think we are now well past the stage of simply re-fighting the old holy war between bloggers and pros, which was never as heated as press accounts had it, anyway. Journalists cast every new phenomenon in horse-race terms -- who wins? who loses? -- because that's such a fundamental news template. But I think the smarter participants in both camps, and the many of us who have feet in both camps, or wear hats with multiple insignia, now well understand that this ought to be a win/win game.

I was too busy moderating to take decent notes, but the entire audio for the session is now online (along with other Bloggercon sessions) at Doug Kaye's excellent ITConversations site, and there's tons of others who did take notes.

Staci Kramer wrote it up for OJR (those are my bullet points quoted anonymously). There are also good posts about the event from Rebecca McKinnon, Claude Muncey, Barnaby, and Colin Brayton, who posted a a big picture of me that shows just how tired I was... (Note to Colin: if I was edging away from you after our brief conversation it's because it was late in the day, I was trying to hit the road -- my kids were waiting at home!)

Most interesting idea aired at the session (and apologies that I can't remember whose idea it was -- step forth and remind me so I can give you credit): Perform a controlled experiment in which readers take in the work of a number of journalists covering a controversial issue or election who are striving to be 'objective' but who actually have a point of view that they do not disclose (i.e., they are normal human beings). The readers will try to guess the writers' sympathies based on the 'objective' work. Can journalists really hide their views? Or, as some critics maintain, can we always tell which side they're on, anyway?

It is, as Dan Gillmor suggested, a great idea for a thesis. Only you'd also somehow have to control for the biases and sympathies of the readers making the calls. This 'objectivity is impossible' thing cuts in all directions. There is no alternative to being human. (Unless you're, er, a marsupial or something. But then you're probably not worrying about the nature of journalism.)

UPDATE LATER: That was indeed conference host and organizer Dave Winer who proposed the great 'controlled experiment' idea. Thanks for that. Could someone -- Poynter? Columbia Journalism School? NYU Journalism School (Jay?) -- now put up a little money, or assign it to a class, to make it happen?

Also -- more good notes from the session over at John Adams' blog."

(Via Scott Rosenberg's Links & Comment.)

10:40:55 PM   trackback [] 

Potcast Recording: Partisan Radio

Partisan Radio: "Adam Curry and Dave Winer started a series of two-head radio talk show called 'Trading Secrets'. You can download the first show (60 MB). They talk about politics and some IT stuff.

The show is basically like a long phone call. Dave calls via Skype from USA with his Windows laptop while Adamy Curry records the joined Skype audio output and his own microphone with Wiretap (free from Ambrosia). Audio HiJack is another utility that allows recording from various sources.

OS X has a very good Audio architecture (called CoreAudio) that makes it possible to route sound between applications and devices and hook in filtering applicaions. Detour is an application that allows to route sound output from various applications separate devices. Another interesting tool for this is JackTools. JackTools is like Detour but unlike that it has a low-fi user interfacce but can route sound from one source to multiple outputs. Soundflower from Cycling'74 offers virtual devices for mixing. All this can work together.

A good resource for Audio on MacOS X is osxaudio.com.

Anyway Adam fiddled around and cam to no satisfactory solution with software only. He is talking about his approach on his audio blog called Daily Source Code. His solution is based on the Digidesign MBOX hardware.

"

(Via owrede_log.)

10:35:35 PM   trackback [] 

Technical notes about external weblog editors

Technical notes about external weblog editors: "The Atom folks are working on a weblog editing API. I plan to support it in MarsEdit, of course. (Assuming it’s do-able and it’s adopted by weblog systems—safe bets, but I have to say it anyway.)

What follows is some notes—for the benefit of the Atom folks and anyone else—based on my experience writing external weblog editors.

My background

First, just to establish what my experience actually is...

I’ve been writing external weblog editors since early 2000. The first one I worked on was UserLand Pike, which was an external editor for Manila sites. It used Manila’s XML-RPC interface. (This may have been the first external weblog editor, though I’m not positive of that.)

I then continued to work on external editing at UserLand. Later on, at Ranchero Software, I wrote an external editor that was part of NetNewsWire 1.x. My most recent editor is MarsEdit, which works with a variety of systems (Movable-Type-compatible, MetaWeblog, Blogger API, and Blosxom systems).

I’ve also worked on the server side, both at UserLand and later for my home-grown weblog system.

What follows is some notes on things I’ve learned along the way, some things that make writing clients easier.

Fewer calls are better: one call is best

Say you want to get the ten most recent posts from a weblog. Ideally, you make a single call of some kind to the weblog server to get all the info you need about those posts.

(I think this should be self-evident—but, in case it’s not, I’ll just mention that it’s much easier to deal with state, updating the UI, and error handling when you can make a single call.)

This means that the data for each post should contain not just the various bits of text but information such as categories, what text filter is used, whether or not comments are enabled, what trackbacks have been sent, etc. All the various pieces of data that you might want to edit through the UI should be returned in this one call.

There are some systems today that require 11 calls to get the ten most recent posts. First you make a call that returns most of the information about those posts—but then you have to make a call for each post to get the categories for each post. That’s one initial call plus ten more calls. That’s ten calls too many.

Similarly, you’d like to be able send a new or edited post to the weblog with a single call. Again, there are some systems today that require multiple calls in order to send a new or edited post.

Here’s how that sequence goes:

1. Make a call to send the post to the server—but tell it not to publish.

2. Make a second call to set the category.

3. Make a third call to tell it to publish the post.

Obviously one call would be better. (What if the network goes down in the middle of this sequence of calls? It’s not like transactions are supported here.)

Clients need info from the server other than just posts

Downloading posts from the server is, obviously, very important. But there’s some other information you need to be able to get:

1. What are the names of the categories for this weblog?

2. What text filters are available?

3. What comments options are available?

(And so on.)

For instance, in order to present a list of categories in the UI, you need to know what they actually are. Same with text filters and everything else like that.

It would also be nice to be able to get the defaults for those things. For instance, a system may allow you to set the default text filter as Markdown. You might be able to say that comments should default to on. It would be great if the external editor could know the user’s settings. (Right now, they don’t.)

Drafts are a big deal

People who write for weblogs love drafts, but the situation with editing drafts is very bad right now.

For some systems, they just don’t tell external editors if a post is a draft or if it has been published. This is important! Not least because an external editor might end up publishing a draft that should have remained a draft.

Another issue is that an editor doesn’t have a way to ask for the ten (or whatever) most recent drafts that are stored on the server. This is a feature request I get all the time—people want to see and edit their server-stored drafts—but, right now, no can do.

(So I have local drafts instead, which is okay, but people would—quite rightly—like to be able create and edit server-stored drafts.)

Image and file uploading needs work

The MetaWeblog API has a great feature—you can upload images and files. The server returns the URL of the uploaded image, and the client software can then build an img tag and insert it into the body of the post.

As cool as this is, it’s limited, and I get feature requests about this all the time.

The current API allows uploading, but more things are needed:

1. A way to find out what images and files are already stored on the server.

2. A way to delete images and files. (Say you upload the wrong file by accident.)

3. A way to rename images and files. (I’ve seen people upload the same image again just so the filename will be what they want it to be.)

4. A way to replace images and files. (Yes, you could delete and upload, but one call is better.)

Of course, info like MIME type and size are needed along with the URLs.

Enclosures should be supported

I’m not sure what the current thinking is with Atom and enclosures. You’ve noticed the enthusiasm around podcasting, I’m sure.

This is related to image-and-file-uploading. A way to tell a server that a given file or image should be linked-to as the enclosure for an item is important.

(Imagine the UI in the client. A user clicks an Attach Enclosure button, chooses a file, and the file is uploaded. When the feed is read by an aggregator, that uploaded file is listed as the enclosure for that post.)

Multiple users should be supported

Some weblogs have multiple users. Some of those even prevent one user from editing another user’s posts.

But most systems don’t express that in their external editing interfaces. A client should be able to get the ten most recent posts for a given user.

Errors should be standardized

There are various types of errors a weblog system might report, but there’s no standardized way to report the errors. (I’m talking about the current APIs. This may or may not be true in the current Atom editing draft, I don’t know.)

Example: say there’s an authentication error. My software has to actually look at the error string for keywords like ‘login’ and ‘username’ and ‘password’ and make a guess that the error is an authentication error. That’s just plain bad.

That’s the most common error, but other errors should be standardized too. Clients should not have to guess what an error means. Ideally error codes are used so that error messages can be localized.

Maybe some of this is just standard HTTP: that’s cool. But I can imagine error conditions that aren’t part of the HTTP spec. (Or that are in the spec but are insufficiently specific for weblog editing.)

Discovery is very important

Imagine you’re trying to configure an external editor to work with your weblog. Your hope is that you can just tell the app the URL of the weblog, your username, and your password—and that’s it.

Systems that support RSD make this possible right now.

If RSD is not used, then something just as good should be used. Configuring a client is difficult without it.

Discovery is something a client should do just once: it shouldn’t be constantly having to make calls to discover different URLs for different things. (The way RSD works is that you read the file once and you know everything you need to know.)

Duplicate pings should be avoided

Some servers send ‘pings’—update notices—to various sites when you publish a new or edited post. Many clients do the exact same thing.

So clients should have a way of knowing what URLs the server is pinging, in order to avoid duplicate pings. While duplicate pings aren’t the worst thing in the world, it’s still a situation that should be fixed.

Pie in the sky features can be ignored for now

There are so many more features my users would love to have. Editing pages, for instance, not just weblog entries. Editing all the various templates and settings. Editing the list of categories.

I’d still be happy even if all the pie-in-the-sky stuff is put on the back burner at first. The more important issues are things I’ve listed above."

(Via inessential.com.)

10:33:13 PM   trackback [] 

More about standard weblog features

More about standard weblog features: "I wrote yesterday about the idea of standard weblog features. Today I’m going to refine and explain the idea.

First thing you should know is that I expect that pretty much no one will agree with me. That’s fine—but I still have to write this up, since I’ve been working with lots of different systems in the course of developing MarsEdit, and it would be wrong if I kept this experience and my thoughts to myself.

Writing should be easier

Weblogs are very important to the future of the web. Syndication standards have already revolutionized how people read weblogs.

But writing is another thing. We haven’t made that easy yet—and, I argue, it’s not for lack of good plumbing (XML-RPC, Atom, etc.) but because we don’t have a good common set of features.

A common set of features will make tools for writing better.

Lowest common denominator

Right now the common denominator is just the body of an entry. You could write a universal weblog editor that only supported that much. But people want to set categories, trackbacks, and so on too.

Better common denominator

What if, instead, there was an agreed-upon basic set of features that every system had beyond just the body text?

That’s not to say systems couldn’t have more features—and of course they could compete on support, performance, hosting, and a bunch of other things.

But I argue that there are some features where we actually know how they should be done, and there’s no reason for different systems to work differently. There’s no competitive value, no differentiation value.

Take categories as an example. Categories are supported in various ways—and each one requires a different user interface in the writing tool.

1. No categories.

2. Only one category.

3. Multiple categories.

4. Multiple categories plus a primary category.

Why not just go with #4 in all weblog systems? After all, we know a few things—we know that people like categories. They like multiple categories. They like primary categories. We also know that people who don’t care about categories can ignore them.

Another example might be text filters. We know that Markdown and Textile and similar are wildly popular. If your system doesn’t support these, it should, and it should do so on a per-post basis, since we know that people like that flexibility.

Or take trackbacks. Every system should be capable of sending trackbacks. People like the feature. It’s an idea that has already survived the Darwinian process and so it should be a no-brainer. (And, again, people who don’t like it can ignore it.)

There’s an entire list of features like this that are just, simply, things every system should have and should do the same way. There’s no value in not having them or doing them differently—and there’s a big value in agreeing to them.

To reiterate

I’m talking about a core set of features, a better common denominator than what we have now.

A bunch of features have already been tested in the marketplace, and we know which ones have stuck.

That’s not to say that systems couldn’t compete on additional features (and a bunch of other things), but that we can raise the common denominator so that better writing tools are possible.

And, later, we can raise it again, as new features stick and become, hopefully, widely adopted.

My own self-interest

I’m arguing against my own self-interest here, in a way. After all, I’ve already done the work in my software—I’ve written the code to generate different user interfaces for different systems.

The current situation means the barrier to entry is rather high for any developer that wants to create a desktop weblog editor that works for lots of different systems. And that high barrier protects my investment.

But that barrier to entry is against the interests of the weblog world as a whole, and I’d rather align myself with the interests of the entire community.

Question

Are weblog systems a central piece of web infrastructure, or just something off to the side?

Even though they’re applications built on top of other standards (HTTP, HTML, and XML), I argue that they have become central, and we should be talking about a standard core set of common features.

And I think syndication is just half the job: the easy half."

(Via inessential.com.)

10:30:58 PM   trackback [] 

Space Quilt

Space Quilt: "Xeni Jardin:

Todays Astronomy Picture of The Day from NASA is a quilt designed by a fan of Hubble Space Telescope photography. The 41 inch by 38 inch quilt was sewn by a woman named Judy Ross (wonder if there's any relation to the other Ross famous for sewing something that included stars?) The explanation on the APOD site includes links to the original images: Red Rectangle Nebula (Link), Eskimo Nebula (Link), Sleeping Beauty Galaxy (Link), V838 Monocerotis (Link), and Supernova remnant N49 (Link)

Link

(Thanks, Scott Matthews)"

(Via Boing Boing.)

9:53:39 PM   trackback [] 

Apple Asteroid, was eMagic EMI?

Apple Asteroid, was eMagic EMI?: "

More evidence that Apple is indeed releasing a FireWire/USB breakout box. Earlier we speculated along with many others that Apple is developing a FireWire audio interface for GarageBand codenamed ‘Asteroid’ or ‘Q97’. The breakout box will include multiple audio inputs, including two XLR microphone inputs. And now suddenly we’re reminded that a little while ago Apple bought a company called eMagic which makes a sub-$200 breakout box for Macs and PCs. Exactly.

(Via Engadget.)

9:51:51 PM   trackback [] 

ZDF überarbeitet nach Ende der T-Online-Kooperation Web-Auftritte...

ZDF überarbeitet nach Ende der T-Online-Kooperation Web-Auftritte...: "ZDF überarbeitet nach Ende der T-Online-Kooperation Web-Auftritte"

(Via heise online news.)

9:40:01 PM   trackback [] 

Kevin Marks, via IM, reminds us that...

Kevin Marks, via IM, reminds us that...: "Kevin Marks, via IM, reminds us that Apple bought a company called eMagic, that makes a breakout box, that's probably a lot like the product that's being rumored around the blogs today."

(Via Scripting News.)

8:11:36 AM   trackback [] 

© Copyright 2005 Georg Berg .
Last update: 17.03.2005; 23:10:14 Uhr .

	Web georgberg.de erftkanu.de tennis-grevenbroich.de