I’m on vacation this week. I’ll be checking email and the Web a few times, but mostly I’ll be out until next week.
For NetNewsWire I’m working on a list of weblog publishing systems that support the Blogger API and optionally the MetaWeblog API.
So far I have, in alphabetical order, Blogger, Conversant, Drupal, Manila (news items), Movable Type, pMachine, and Radio UserLand.
Am I missing any?
The way it works in NetNewsWire: when you set the prefs for a weblog, you specify the publishing system. There’s a popup menu. This way NetNewsWire knows which API or APIs are supported.
But you can also choose Other as the publishing system and set the supported APIs manually. (Which I do for this site and for ranchero.com.)
The great thing about rolling your own weblog software is you get to do it yourself.
The bad thing about rolling your own weblog software is you have to do it yourself.
I’ve been working on NetNewsWire’s weblog editor—but, I confess, my weblogs don’t support either the Blogger or MetaWeblog API. So, ironically, I can’t use my weblog editor with my own weblogs.
So now it’s time to implement at least the relevant parts of those two APIs for my own sites, so I can edit them with NetNewsWire.
The thing is, the thing that makes me a geek, is that I’m looking forward to doing this bit of programming.
I posted an RFC on an addition to the MetaWeblog API: metaWeblog.getRecentPosts. The idea is to make implementing external weblog editors easier and to reduce bandwidth use.
How do 18-year-olds see the world? Beloit College’s Class of 2006 Mindset List tells us.
“‘Big Brother’ is merely a television show.”
“George Foreman has always been a barbecue grill salesman.”
“A ‘Hair Band’ is some sort of fashion accessory.”
(Link via The Atlantic Dec. 2002, the issue with JFK on the cover.)
I’ve been testing NetNewsWire‘s weblog editor with MovableType—and it’s working. Here’s my test site.
One of the painful parts of weblog editors is configuration, as Daniel Berlinger points out in his RFC on discoverability.
I had to send an XML-RPC request to get the blogID of my MovableType site. For Manila the URL of the site works as the blogID. I don’t know what I’ll find when I try other weblog publishing systems, but I wouldn’t be surprised to find them all slightly different.
This needs to get much easier.
Ideally all it would take to configure one’s editor is to know the URL of the home page of your site. (And of course you’d know your username and password also.) A user should never have to know or figure out the blogID, RPC URL, and supported API or APIs.
Here’s a screen shot of the weblog editor that’s going into the pro version of NetNewsWire.
There’s a good chance that it will change quite a bit between now and when it actually ships, of course.
You can see that some of the features are in place—including editing recent items. (Note the drawer on the right side of the screen shot.)
There are buttons for making text bold and italic and for adding a link. A Preview button shows a preview of the item (in a sheet).
Though you can’t see it in this screen shot, it supports the Blogger API as well as the MetaWeblog API.
One of the notable missing features at the moment is categories—but they’ll be there.
I’ve got the basics of weblog editing in NetNewsWire pro working—I’ve been using a Manila site initially, since Manila supports both the Blogger and MetaWeblog APIs.
(Thanks to Daniel Berlinger for setting up the site for me.)
Soon I’ll be setting up test sites with Radio, MovableType, and Blogger, so I can test with the main weblog tools.
I’d like to be able to talk to Blapp too, for posting to Blosxom sites. And also find a way to post to wikis. But one thing at a time—XML-RPC-enabled sites come first.
I’m looking forward to getting acquainted (or re-acquainted) with the various states of the art in weblog publishers.
Another thing this means is that I now have calling methods via XML-RPC working pretty nicely. This opens up a huge world.
Here’s a screen shot of dates in NetNewsWire Pro.
I’m still working on formatting issues—it will be contextual, as in most email apps. It will also convert to the local time zone.
It supports both pubDates and Dublin Core dates.
In looking at my subscriptions, it appears that not that many RSS feeds include dates yet. I hope that changes, because, well, knowing the date and time of an item is pretty useful.
Feeds for my sites don’t contain dates, even. But I’ll add dates.
NetNewsWire Lite 1.0.2 ships! It’s no longer in beta.
Changes since 1.0.1 include reduced bandwidth use, a Bandwidth Stats window, bug fixes, and user interface enhancements.
I’ve been working on the Find command for the pro version of NetNewsWire. It’s pretty straightforward. Here’s a screen shot.
NetNewsWire Lite 1.0.2fc1 adds a Validate this Feed command, which opens the RSS Validator in your browser to validate the RSS feed for a given subscription. The command is in the contextual menu for the subscriptions view.
Matt Haughey: “I don’t keep track of post titles, I don’t think the syndication file is all that useful without HTML, and I’ve never personally found much use for a RSS reader. That all changed when a friend said she wasn’t reading my site anymore, or any sites for that matter that didn’t carry RSS feeds.”
Brent’s Law of Weblogs: If you’re not syndicating, you’re not publishing.
This law is descriptive, not prescriptive.
RSS, or something like it, was inevitable. I used to read a couple dozen sites regularly—now I read about a hundred sites. Far more than I could ever follow in my browser. And I do actually visit the sites I subscribe to: when there’s something interesting in their feed, and it links back to the site, I go to the site.
Traffic patterns are changing, definitely. But RSS is a chance for webloggers to reach an even wider audience. It doesn’t mean that the HTML version of one’s site is now irrelevant—in fact, because of RSS and newsreaders I now visit lots of sites I never used to visit.
Mark Pilgrim’s stats page shows the amount of bandwidth saved by aggregators supporting conditional GET. It’s 88.95 MB at this writing. Very cool.
It looks like NetNewsWire will be on television, on TechTV, Wednesday night. I think that’s pretty cool.
(I hope I’ll be able to watch the video from the site since I don’t get TechTV.)
This screen shot of NetNewsWire Pro’s Notepad should be fairly self-explanatory.
As an homage to Frontier, the keyboard shortcut for opening the notepad is Cmd-Y.
It’s not a document-based outliner—there’s just one outliner window, and its file is stored on disk in one’s Application Support/NetNewsWire/ folder. It gets saved automatically when you make a change.
Perhaps unsurprisingly, it’s an OPML file.
And yes, one can expect the toolbar icons and other cosmetic issues to improve between now and the first beta.
I’m starting to post screen shots of NetNewsWire Pro as the beta gets closer. Here’s one that shows choosing which weblog to post to via a contextual menu.
Both of our weblogs were created shortly before Manila shipped. (For those who are new to this weblog—I used to work for UserLand, and I worked on Manila.)
Sheila’s weblog started as a test site. Manila was fairly close to being finished, but we wanted some more usability testing, so I asked Sheila to help, and she did.
Some of the more user-friendly touches came out of watching Sheila work with her site and later discussing Manila with her. I don’t remember all the details—except for one.
At that time, when you uploaded a picture to a Manila site, it automatically generated a shortcut name, something like picNum123, where the 123 part was the discussion group message number containing the picture.
This proved to be confusing and not particularly user-friendly. Sheila insisted that the shortcut should be the name of the file, as in myCat.gif or ThanksgivingTurkey.jpg.
So, we (UserLand) discussed it internally, and made that change before shipping—and I’m sure glad we did.
Anyway, this is just to say that it takes a village to raise an application. And every user of any app should remember that it’s not just the developers who deserve thanks but also the beta testers and early users.
NetNewsWire Lite 1.0.2b6 fixes a performance bug introduced in the previous beta. It also fixes a bug so that clicking on links in the Description HTML view now respects your browser-viewing prefs.
Wired News: Monorail on City’s One-Track Mind. “A single-track electric train running above cars and pedestrians’ heads has been a part of Seattle’s self-image since the early 1960s, when a one-mile stretch of last century’s transit-system-of-the-future was erected for the World’s Fair. Still, the promise of a citywide monorail system had been a dream deferred, until Tuesday’s election.”
The new monorail will have a stop a couple blocks from my house. I voted for it.
(Note about the old-but-still-current items bug: it will take a few days to take effect once you start using this beta, since some stale data will have to work its way out of NetNewsWire’s history database.)
I get a fair amount of email about how Huevos should allow one to choose a search engine from the keyboard. I agree completely.
Most of the email I get suggests adopting the same UI that is used in at least one Windows app—type a leading character or two to choose the search engine.
But I don’t like that. It’s not Mac-like.
What I’m thinking right now is that it would be best to allow the user to assign command keys to the various search engines. Google, for instance, might be cmd-G. You’d assign command keys through the Prefs window, the same place you edit your search engines.
So to run a search you’d bring Huevos to the front via a hotkey, type a command key to select your search engine, type your search string, then hit return to run the search. You’d never have to touch the mouse.
What do you think?
Another Huevos idea—Huevos could be a Services provider. A Huevos submenu in the Services menu would allow you to run a search on the selected text in a given search engine. The submenu would be the list of search engines—so you’d select some text, choose Services->Huevos->Search with Google (for instance), and the search would run.
Happy Election Day!
I get all gooey inside, thinking about the history of democracy, and all the people who have fought and still fight for the right to vote.
Call me a sap. I don’t mind.
It also includes one of the most common feature requests—that the space bar should scroll down the Description HTML view when it can be scrolled. (When it can’t be scrolled, or when it’s scrolled to the end, then the space bar still goes to the next unread headline. This way you can motor through all the unread headlines without taking your finger off the space bar.)
Give Bill Gates a fish, and he’ll buy some tartar sauce to go with it.
Teach Bill Gates to fish, and he’ll build a tartar sauce factory and eventually corner the market. The tartar sauce won’t be as good as some other tartar sauce, but people won’t mind, they’ll just think that that faint hint of mercury is how tartar sauce is supposed to taste.
Give Scott McNealy a fish, and he’ll rant about how it’s all Microsoft’s fault.
But teach Scott McNealy to fish—and he’ll rant about how it’s all Microsoft’s fault.
Give Steve Jobs a fish, and he’ll give it back, being a vegan and all.
Teach Steve Jobs to fish, and you’d just be wasting your time, because he really doesn’t eat fish, I just told you.
Give Larry Ellison a fish, and he’ll eat for a day.
Teach Larry Ellison to fish, and he’ll come up with a better fish, one that can’t be captured or killed. (Leading to ecological catastrophe as the lesser fish are killed off by this new fish.)
Here’s a screen shot of a new feature coming in the next NetNewsWire beta—bandwidth statistics.
You can see which of your subscriptions are bandwidth-friendly and which aren’t.
Especially friendly sites are in blue; especially unfriendly sites are in red.
The stats window shows the number of the times the site has been checked, the number of times the full RSS feed has been downloaded, the number of 304s the site returned, the total number of RSS feed bytes read, and the average bytes per check.
Why do this?
First thing is because it’s hard to know what to do about bandwidth consumption unless you know what’s really going on. Seeing actual numbers helps.
Another reason is that you may need to conserve bandwidth on your connection, and so you might unsubscribe from feeds that are not bandwidth-friendly.
Another reason is that you may want to check to see if your own site is bandwidth-friendly or not.
I’m working on a new beta for NetNewsWire that supports XML-level redirection (as specified here).
But, since I’m working on a new beta, and bandwidth is still an issue, I was thinking of adding another feature—a note on the Info window for a subscription that says whether or not the subscription is bandwidth-friendly.
By “bandwidth-friendly” I mean the feed uses ETags or Last-modified headers to cut down on the amount of bandwidth used when reading the feed.
This gives users an additional bit of data to use when deciding whether or not to keep a subscription, and it will help raise the general consciousness about bandwidth issues.
In running my debug builds I’ve found that most of my subscriptions are in fact bandwidth-friendly—but still way too many feeds are not. In my opinion this is the single best way to reduce bandwidth consumption from the server side. (That’s not to say that other ideas aren’t helpful also.)
What do you think? Make sense?