Today is the last day of the NetNewsWire $29.95 sale. If you were thinking of buying NetNewsWire, I’d hate to have you miss out.
Here’s what’s coming up for NetNewsWire...
The next release will use Web Kit (the Safari renderer) to display HTML. This will be a big improvement on the current lame HTML renderer NetNewsWire uses.
It will probably also switch to the new URL downloading code that Safari uses.
And of course a bunch of bugs will be fixed.
After that release, the biggest item on the to-do list is synching. My hope is that synching will work not just between copies of NetNewsWire but between NetNewsWire and other aggregators.
I updated the NetNewsWire Feature Ideas page, which lists most of the ideas we’re strongly considering for the future. I added a section at the bottom listing things that have been done since the page was started, so we can have a visible track record.
(And if you have feature requests not listed there, feel free to leave a comment here or email me or post on the bug tracker.)
What about Panther?
I’ve gotten a bunch of email about NetNewsWire and Panther. The only bug I know of specifically is a bug in the networking code in the current Panther seed that can cause NetNewsWire to crash. There may be other bugs, of course.
Here’s the deal: NetNewsWire will run on the final version of Panther. It will probably run on earlier versions of Panther too. But it’s impossible to say when.
I intend to take advantage of new technology in Panther, and have that ready in NetNewsWire before Panther ships. (A non-disclosure agreement prevents me from elaborating yet.)
However, I can’t guarantee that NetNewsWire will run trouble-free on the current Panther seed. Maybe yes, maybe no. It’s not a good use of my time to make sure it runs on an OS release that’s at such an early stage of development. Especially since the Panther bugs are, well, bugs in Panther.
Congratulations to Daniel Berlinger and his wife on getting married! Wonderful news.
A number of people have asked me for an explanation of what the Echo project actually is.
I’ve stated before that while I’m not thrilled about it, my software will support it as long as it’s technically supportable.
That’s so you know where I stand. What follows is a stab at explaining it without advocacy either way and in terms that will be familiar to people who read this weblog.
What is Echo?
The point of Echo is to create a new format for syndication. It would be like RSS but different.
The second, related point is to create an API for editing weblogs. Two such APIs already exist, the Blogger and MetaWeblog APIs.
Why do this?
There appear to be two main motivations:
1. To improve on RSS and the current editing APIs, to do better. See for example Ben Trott on why we need Echo.
2. To deal with the political and personality issues involved with RSS and the current editing APIs. See Tim Bray’s conversation with Mr. Safe. See also Jon Udell’s conversation with Mr. Safe, which concludes somewhat differently.
Which is the bigger motivation? It’s hard to tell. I lean toward saying it’s the politics, but there appear to be a number of people interested primarily in the technical issues.
For more about the why of Echo, see the page on Motivation on the Echo wiki.
What will it look like?
It’s a safe bet that Echo format feeds will be XML. But the details are still being worked out.
If you’ve looked at an RSS feed, you’ve seen some stuff at the top about the feed (its title and description and so on) and then the rest of the feed is a number of news items. Echo will (most likely) look like this too.
See the EchoExample page. Nothing is set in stone yet, I think, but it appears that instead of having a bunch of item tags, as in RSS, there are a bunch of entry tags.
Were that the only difference from RSS, you’d have to say, “So what?” right now. I’ll note another difference, so you can get the flavor of the kind of ways Echo differs from RSS.
Each entry can have multiple content items. The same entry on a weblog could have a plain text version, an XHTML version, and so on. You can specify the language of individual content items.
Maybe that’s a big deal, and maybe not. (I’m not going to mention each way Echo differs from RSS.)
It looks like there are a number of such small things that may add up to a more flexible and complete syndication format. Or, it may add up to a more complex and difficult-to-generate and difficult-to-parse format.
One main criticism of Echo would be that it’s not really necessary: RSS and the current editing APIs get the job done. In fact, you could argue that they do the job fabulously well. Look how many weblog publishing systems there are; look how many sites support RSS; look how many newsreaders there are. If RSS was so broken, this wouldn’t be happening.
And if there are problems with RSS, they could perhaps be fixed by working with RSS rather than starting something new.
An Echo enthusiast would reply that RSS does indeed have some technical problems which can’t be fixed because RSS is a frozen spec and because politics gets in the way too much. An Echo enthusiast might also add that the politics of RSS is a barrier to wide adoption, so something that is completely vendor-neutral is needed. (Again, the two Mr. Safe conversations argue different sides of this.)
You might then ask what vendor-neutral means when Sam Ruby, who started the project, works for IBM and works on this with the blessing of IBM. You might also be getting into the realm of conspiracy theories and paranoia here.
You might also question the process. Tim Bray writes about too much creativity: “I am worried that the next-gen syndication process rooted in Sam’s Wiki is in danger of going seriously off the rails, because some of the participants have got the idea that it’s about trying to invent new technology or improve RSS.”
Design by come-one-come-all committee may make delivering a good spec nearly impossible, because so many people want to solve their favorite technical problem. Too many engineers may lead to an over-engineered format, which would subvert the goal of delivering a clear, well-specified, easy-to-use format.
Or not. If you like sausage, don’t go to the sausage factory. Sometimes beautiful things come from unsightly processes. Sometimes.
A year ago I started a mailing list devoted to web services on OS X. It’s been largely inactive, but today people started talking about Web Kit there. That’s totally cool by me.
If you want to join, here’s its home page on Yahoo Groups.
Yesterday I started working with Web Kit. It’s so easy to get started. What a treat!
We don’t have experience with Web Kit yet; we don’t know what the security implications are of allowing scripts and plug-ins and so on to run. We can theorize, we can make some pretty good guesses, but we don’t really know, yet.
That’s merely obnoxious (probably)—but are actual security exploits possible? You have to assume the worst.
I don’t want Mac OS X to become like Windows, where untrusted code seems to run all the time from all kinds of sources. (Windows has perhaps gotten better than its reputation; I don’t follow it that closely.)
So, to Mac developers, I’m not saying don’t use Web Kit. Use it. It’s super cool. I’m going to use it.
And be glad that Web Kit allows you to turn off this stuff. It’s a very good thing. Thanks go to the Web Kit team.
I plan to support Echo in my software.
This is conditional of course on the final spec being deployable. But I expect it will be. This isn’t rocket science.
I took a look at a bunch of places where decisions have to be made, and realized that these decisions could go either way and we’d still end up with a deployable format.
The thing is, I’m still not convinced of the need for Echo. I’ve read pretty much everything I could find on the issue.
But that’s just me. I’m often unconvinced of the rightness of an idea, but then it turns out to be a very good idea. Happens all the time.
I’m back home from WWDC, getting caught up. Lots to do. One of the first things it to take a look at Echo.
It looks like there are multiple espresso machines.
I’ll be at the far one (at 1:30), if it’s still there. Otherwise I’ll be at the one closer to the video displays and snacks and so on.
If I haven’t run into you yet at WWDC—I’ll be at or near the espresso machine on the 2nd level at 1:30. Today, Thursday. So come say hello!
(In case you hadn’t noticed the machine: it’s the big bronze-looking thing at the end farthest from the main entrance on the 2nd level.)
To make me easier to spot: I’m wearing black jeans and a light-colored button-down shirt. Here’s a picture of me.
As a developer, the things at WWDC that I dig are things that make me more productive and that make my software better. Though I think iChat A/V and new G5s are cool and all, what gets me excited are the new developer tools, OS improvements, and the new stuff in Cocoa.
It turns out that there’s lots more than just WebKit to be glad about. And I’m just, well, amazed.
I don’t have a lot of time to write about it all, and a bunch is covered by nda anyway for now. But the upshot is that being a Mac developer is getting more and more fun.
But did I mention that the wireless connection is a bit overloaded? Nuts!
I’ve gotten some email regarding Echo, a new format for weblogs. Unfortunately this whole thing came up as I was getting a new release of NetNewsWire out and then going to WWDC. I’ve had absolutely no time to read it.
And I probably won’t have time until I return from WWDC.
Here’s my general take:
I care about software, not specs. I have not a shred of idealism about specs. My support for standards is purely pragmatic. (In other words: I strongly support standards, but for pragmatic reasons.)
I’d rather spend my time fixing bugs and doing cool new features. I don’t relish the idea of writing new code to parse another format.
But—my philosophy is that NetNewsWire should work with what’s out there. It works with RSS 0.9x, RSS 1.0, and RSS 2.0 currently. If there’s a new format, and people use it and like it, I’ll support it. In other words, if this format is generated by one or more of the popular weblog publishing tools, then support in NetNewsWire is pretty much a given.
This effort seems to me to be more about fixing political bugs, real or perceived (same thing, maybe), than fixing problems in RSS itself. I could be wrong, since I haven’t had any time to look at the specifics.
About RSS and its political issues I have nothing to say. I’m Switzerland on this stuff. My philosophy is just to support what people use.
Anyway... about the technical merits of the new format, I’d like to take a look and provide feedback, but I won’t be able to until the weekend.
I haven’t had the chance to try out Panther yet—but I got an email from an Apple engineer telling me NetNewsWire will crash on the Panther seed. (Due to a bug in CFNetwork.)
The same engineer told me it will probably be fixed for the next Panther seed. I may be able to do something in NetNewsWire about this before the next seed, but then again I may not bother, since it’s not necessarily a good use of my time to work around someone else’s bug that will get fixed anyway.
I’d rather spend my time fixing other bugs and upgrading to WebKit.
Update 12:02 PM: More details... the Panther system networking crash occurs when there are more than n simultaneous DNS lookups, where n is something like 15. (I’m not sure if that number is exact.) Depending on various things, you may not encounter the crash in NetNewsWire. It may work fine. But then again it may crash.
I’m having a great time at WWDC!
It’s about 1:30 Pacific as I write this, and the first session on WebKit starts in a half-hour. Cool. There has been a little talk about it in some other sessions, including one where they showed how easy you could create a basic web browser. So, without knowing more yet, it sounds like they did a good job and it’s easy to embed in Cocoa apps.
Unfortunately I’m having some net connection issues, so I’m way behind on email. I’ll catch up on the weekend.
One of the reasons I’ve been looking forward to WWDC is to learn about WebKit. There’s a session on using WebKit in Cocoa apps, and that’s the one session I absolutely can’t miss.
NetNewsWire needs WebKit. It keeps asking me for it, and I have to say: sorry, not yet. Soon. (Imagine how cool the Combined View will be with WebKit.)
Anyway... while the rest of the Mac universe is looking at leaked G5 machine specs and things like that, I’m fixated on WebKit.
My guess is that WebKit will result in a bunch of new apps from lots of different developers. Having an easy-to-embed HTML renderer that comes with the system is a good thing for developers. It opens up lots of possibilities.
Of course, I expect there will be lots of experimental apps as a result of WebKit. Not everything will be good; not every idea will stick. But I bet there will be some gems.
I’ve been getting a fair amount of email asking if I’ll be at WWDC.
Yes! I’ll be at WWDC. It’s my first time, actually. I’m pretty excited.
I’m looking forward to meeting and talking to other Mac developers. So if you see me, please say hi. (Here’s a recent screen shot of me, taken at O’Reilly’s conference in May.)
I’ll have my laptop, so I’ll be updating my weblog (hopefully), and I’ll be in email range. I may even turn on iChat. (I’m pbrentsimmons on AIM.)
In case you didn’t notice from ranchero.com and elsewhere—NetNewsWire 1.0.3 was released late last night.
The big new feature is the Combined View, which puts titles and descriptions together in a single pane. I’ve written about it many times here. I’ve also written about the other new feature, the ability to edit LiveJournal weblogs.
See What’s New in NetNewsWire 1.0.3 for more details.
To celebrate the new features—and celebrate WWDC and the start of Summer—we’re running a 25%-off sale: NetNewsWire is $29.95 through the end of June.
NetNewsWire 1.0.3b2 fixes a bunch of different little things. It may be the last beta before 1.0.3 ships—which means we’re looking for deal-stoppers bugs.
See the change notes for details on what’s changed.
I always get a little anxious before a release—Oh no! It’s not perfect! There are still things to do!—but then I remind myself that there will be another release, and another, and another...
And if you don’t release you end up doing these infrequent, giant, would-be-utopia releases which really aren’t any better anyway than more frequent releases.
The big news in this beta is probably that LiveJournal has been added as a supported weblog system. (Thanks to the LiveJournal folks for adding Blogger API support.)
Here’s a page on configuring NetNewsWire to edit a LiveJournal weblog.
Since the LiveJournal folks added Blogger API support, you can edit your LiveJournal weblogs with NetNewsWire. (And other weblog authoring clients such as Kung-Log.)
Here’s my test LiveJournal weblog. It worked!
The next release of NetNewsWire will include LiveJournal as a type of weblog system in the popup menu.
Dave Winer writes about prior art as a design method: “Anyone who has worked with me knows how much I value prior art.”
True! As a UserLand employee I was often looking at prior art.
An example (one of many possible) is the standard Members box on Manila sites. We wanted a way to give people three links: join a site, login to a site, or logout if they’re logged in. So we looked around at a bunch of popular sites that had membership to see how they were doing it.
There was a common thread: lots of sites used a little box with two states. When a user isn’t a member or isn’t logged in, it has two links: join and login. When a user is a logged-in member it has just one link to logout.
There was no clear consensus on terminology, so we chose what we thought was best. (There’s even a little inconsistency—there’s a Login link, but instead of a Logout link it’s a Sign Out link. This was not a problem.)
The thing is, we didn’t have to re-invent the wheel. We took a look and discovered that the wheel is round, and also that it doesn’t matter what color you paint it, it still rolls.
Anyway... I bring this up because I was planning to write about this topic today, and it’s coincidence that Dave also wrote about it.
The pressures of conformity?
What brings this up for me was that I was emailing with a guy who runs a couple cool websites, but his background is not software development. He added a new feature to his site, but he did it in a way that’s very different from how other sites do the same (or very similar) thing.
I suggested he do it the same way as sites x, y, and z. His response—light-hearted though it was—surprised me: he agreed to “conform.” (As in the negative social sense rather than the neutral engineering sense.)
What? Conform? That response surprised me.
So here’s my advice to people building websites (or other software): look at prior art. Doing something the same way other sites or other software do it is a good thing. It’s not some kind of evil conformity.
There is still plenty of room for innovation and self-expression. In fact, looking at prior art allows you to quickly solve the problems that have already been solved—so you can concentrate on the new problems, the problems that are yours to solve, the stuff that makes your software cool.
Prior art is your friend.
I was reading this totally funny thing, a History of the Internet, and it mentions weblogs as being invented in 2001.
At first I didn’t think about that, but then I did, and I realized—for all the talk about weblogs these days, weblogs are actually very old.
In fact—I did some quick checking, and I think weblogs were invented ten years and four days ago. Check out the June 14, 1993 date at the bottom of the archive for What’s New with NCSA Mosaic.
Happy tenth birthday to weblogs!
The first weblog authoring software that I know of is NewsPage, from May 1997.
I’ve posted an introduction to NetNewsWire’s new Combined View.
The new view combines titles and descriptions—it’s sort of like a web page, actually, except that you can navigate via arrow keys and the space bar and you can expand and collapse descriptions.
And you can get it from the beta page.
There are some other changes in this beta, mostly bug fixes, but also some new features—such as the ability to read feeds via https. Read the change notes for more details.
The Combined View wouldn’t exist without the work and ideas of other people. Radio UserLand and other browser-based aggregators display news in a similar fashion, with titles and descriptions together.
And lots of other people have asked for this feature and kept asking for it—and so we did it.
Finally, some brave souls helped test the alpha versions. The early versions of the Combined View were weird at first, but it got better, thanks to the testers.
The next version of NetNewsWire will include support for updated items.
The idea is this: when a headline comes in—and it’s not new but edited—it doesn’t get marked as unread. Instead it’s marked as updated.
This is a good thing because it means that you don’t re-read a headline for each little edit.
Here’s the thing, though: it works only for...
1. RSS 2.0 feeds that contain guids.
2. RSS 1.0 feeds. (It uses the rdf:about attribute as an identifier.)
That means it works for many RSS feeds but not all of them.
So... if your feeds are RSS 0.9x feeds, please upgrade them!
If your feeds are RSS 2.0 feeds, but they don’t contain guids, please add guids!
It will make people who read your feeds happier.
On the anniversary of D-Day, I thought I’d quote the famous Thomas Jefferson line: “Every man has two countries, his own and France.”
Except now I’m not sure it was Thomas Jefferson who said that. I did a Google search, and this line has been attributed also to Benjamin Franklin, John F. Kennedy, Voltaire, Henri de Bornier, and a station wagon.
They say it’s going to get into the 90s here in Seattle today. Right on.
Also hot: the Mariners. They swept the Phillies. They now have a nine-game winning streak, all on the road.
The Phillies were my boyhood team.
Ben Hammersley says, in an interview, “Certainly I’d never go to a conference anymore that didn’t have Wi-Fi. Being in a meeting room without bandwidth is against god and against nature.”
Here are are a couple good-looking, easy-to-read, wikis—or blikis. Blog-wikis.
They’re Vanilla sites.
(It doesn’t escape me that Vanilla rhymes with Manila. I have no idea if that’s coincidence or not. Either way, I like the name Vanilla.)
Amplifying my earlier post about wikis...
Some people have said that wikis look the way they look because they’re just trying to get a job done and they don’t care about appearances.
In other words, the idea is that beauty and usability aren’t connected.
I disagree with that utterly and completely—beauty and usability are completely connected. In the case of web design, usability is the biggest part of beauty.
When I say usability I usually mean readability. The main thing people do with wikis is read them. (The main thing people do on the web is read.)
So what I’m saying is that almost all wikis don’t do the job of being easy to read.
Picking on Jakob
I’m going to pick on Jakob Nielsen now. Mostly because it’s ironic fun, but also because he can take it, and his site has many of the same usability and aesthetic problems that wikis have. (In my opinion, of course.)
Here’s a recent, fairly representative page: Usability For $200. (Warning: link opens in a new window, so you can see it and continue reading here.)
The text goes from the extreme left of the browser window to the extreme right. It is very difficult to read. (A more narrow column and white space would make it easier to read.)
I have to resize my browser window to about half its normal width before I can even attempt to read this page.
Any site that makes me resize my browser window, I leave.
The Summary box has no margins. Worse still, the background yellow of the box bleeds into the white background of the page, which makes reading the summary difficult. A border would help. See how it’s hard for your eyes to make out the edges of the Summary box? It makes that area of the page look smudged.
Then there’s all the bold phrases in the paragraph text. These little bold phrases add visual noise to the page. (Links don't have that same effect.)
You know what? That’s it. Not that many things.
And, as with Jakob Nielsen’s site, there isn’t that much that most wikis would need to do to become easy to read.
It’s as easy to create an easy-to-read site as it is to create a hard-to-read site.
It’s interesting (at least to me) to compare our different answers. Our interviews reflect different personalities and different visions—and I think our apps do too.
NetNewsWire is very textual. It takes a new thing (RSS) and puts it into a familiar interface.
Spring, on the other hand, is very graphical. It takes familiar things and puts them into a new interface. With Spring, the new interface is the thing.
Despite our different visions, Robb and I definitely agree that independent developers benefit when they work together.
Another thing we’d agree on (I think) is that the web browser is not going to go away—and it should not go away, and we don’t want it to go away—but other applications are going to present other ways of doing things on the web.
The web is too big and cool to be stuffed entirely in the browser box. Yet browsers remain hugely important. It’s an AND thing, not an OR thing.
Rob McNair-Huff posted a picture of one the first butterflies this year.
I myself have seen just a Tiger Swallowtail so far, a couple days ago. And Sheila saw a hummingbird feeding on our honeysuckle bush yesterday.
I want to like wikis. But for some reason every wiki I’ve ever seen is, well, ugly.
So I propose Brent’s Law of Wikis: the set of people who use wikis and the set of people who know how to make websites look good are mutually exclusive.
Feel free to prove me wrong!
I use Safari most of the time—but there’s one thing I always use Camino for: getting the height and width of images.
I’ve been using this feature of web browsers for like eight years or something. But Safari doesn’t have this feature.
I stumbled across this yesterday.
In a recent interview I mis-remembered the original name of NetNewsWire (before anyone saw it) as CocoaWire—but I was wrong, its original name was AquaReader. (Which made me think of Aquaman the superhero.)
Even just a year ago people were still naming their apps Cocoa-Something or Aqua-Something or Something-X to make it clear they were OS X apps. That was a pretty dorky thing to do.