So I pulled my Windows machine out of the closet the other day and hooked it up to the net and a monitor and all that—I wanted to try out some Windows aggregators, see what features they have, see how they’re solving some UI problems, etc.
And I had some stunningly bad luck. Almost every single app I tried crashed on launch or right after displaying their main window.
My machine is a 500 MHz Dell box running Windows 98. It’s up-to-date with security patches, and it has .NET 1.1 installed. But... apparently it’s a bit too stone age. Fair enough: I’m not complaining, just learning a lesson.
Anyway... of the aggregators I did get to work, I was struck by how Windows-y they are. Wizards for adding subscriptions!
That’s not a criticism, by the way. Windows apps should have wizards, they should be Windows-y, just like Mac apps should be Mac-like. (And Linux apps should be... GNOME-y? KDE-ish?)
This experience was a reminder for me of how unimportant the underlying syndication formats are, in a way. What percent of time does an aggregator developer spend on RSS and Atom parsing code? 50%? 25%? 10%?
I figure it’s somewhere less than 1%.
The rest of the time is taken up with things like data storage, networking, and user interface. But mostly user interface. Not just implementing—which is often easy—but designing user interface, which is difficult.
What this means, finally, is that a Windows aggregator developer is foremost a Windows developer, and secondly an RSS/Atom developer. Similarly for Mac and Linux developers.
There’s a piece of software I use that has this Labels menu that freaks me out.
It’s okay until I look at the Yellow label. Then it becomes like one of those weird left-brain/right-brain experiments. I can feel the conflict in my head. It’s like a denial-of-service attack—my brain goes into a loop.
I don’t know how this happened—I don’t recall ever customizing anything label-related.
Are RSS aggregators pretty much there, just needing some tweaks and small features—or at they still at the very beginning of their evolution, with a long road still ahead?
This question was asked on the NetNewsWire beta testing list. It’s a good question.
Answer: aggregators still have a long road ahead. What you see now is just the beginning.
I have an idea of some of the things you’ll see in 2004 (not just in NetNewsWire but in aggregators in general). So consider this as Brent’s psychic predictions for 2004.
1. Atom syndication support. Some aggregators already have this, and I suspect most will by mid-2004.
2. Synching. The idea is to synchronize not only your subscription lists but also the read/unread status of individual headlines—and to make it so it works between different apps, even apps running on different operating systems.
3. Easier subscribing. One of the problems for new users is the problem of subscribing to feeds. The “feed” URL scheme is a step forward here, because it makes it so you can subscribe to feeds directly from your browser. It also means instead of lots of ways to do this, which is inherently confusing, aggregator developers and users can collapse it down to one way. (I suspect there will be other good ideas too—especially in the realm of finding feeds.) Making all this easy for new users is a high priority.
Anyway... individual aggregators, NetNewsWire included, will add lots of other new features not listed above. The above are just the things I predict aggregators will do in common for 2004. I expect lots of innovation to come from all over, but I can’t predict what those innovations will be.
Years from now aggregators will be like email apps: we’ll know what an aggregator should do and what the UI conventions are. But for now we get to be creative, try new ideas, see what sticks. So—my last prediction—I expect 2004 to be fun.
Some people think it’s cool, others don’t. I suspect an obvious feature request will be for aggregators to notice when this technique is being used and be able to turn it on and off.
Dare Obasanjo has published a pre-draft of a spec for the “feed” URI scheme and is requesting comments.
Seth Dillingham: “The feed protocol was originally designed for farms. Cattle, for example, just have to click a button to access a feed: url on the farmer's server, which causes grain to be dropped in the trough.”
The older I get, the more I like mustard and the less I like mayonnaise.
I never used to like Tartar sauce at all, but now I like it sometimes on french fries. And salsa—the hotter the better—is on the lunch menu just about every day.
We’re getting some people asking about our plans for Atom support in NetNewsWire. Here’s the deal:
A future version of NetNewsWire will support the Atom syndication format. The weblog editor will also support the Atom API.
That’s it. There isn’t really anything else to say.
This release of NetNewsWire and NetNewsWire Lite 1.0.7 adds support for favicons and feed URLs, boosts performance, and fixes dozens of bugs. The full version includes a new widescreen view especially suited for laptops.
See What’s New in NetNewsWire 1.0.7 for details.
Whenever I go into Jaguar (which I do for testing) I’m reminded about how much nicer Panther looks. It’s a dramatic improvement in look and feel.
Except for the Finder, that is.
In my previous post I mentioned the year 1982. Some of you may not have been born yet or were too young to remember 1982 very well.
So here are some things to give you the flavor of 1982:
My school didn’t have any computers. I was trying to convince them to add a computer lab. This was a common situation.
Macintosh computers didn’t exist yet.
Most people didn’t have computers at home. (We had an Apple II Plus at home.) Most people weren’t sure that computers were important. They were thought of (by many) as useless and expensive toys.
We had a VCR, but no CD player, and certainly DVDs were unheard of. I had a turntable and a cassette deck connected to my stereo. Video rentals were a new type of business. It cost $3.00 to rent a movie for a night.
The VCR had a remote control—but, as was very common then, it was actually connected by a wire to the VCR.
The two leading on-line services, as I recall, were CompuServe and The Source. They were too expensive: we didn’t use them.
My mom had a terminal—not a full system, a terminal—that she connected to the University of Delaware’s Unix system via a 300-baud modem. You had to dial the phone (an old-style AT&T phone) and then plop it onto these weird rubber cups. (This was my first exposure to Unix. I think I used ed for text editing, though I could be remembering wrong.)
Microsoft made games—I loved their Apple II port of Adventure. (And later on I loved Zork from Infocom.)
The Clash were still together.
I learned at an early age the importance of shipping software.
My first software award
It was 1982, I was barely a teenager, and I was at a computer fair where young geeks from all over Delaware were competing in a programming contest.
We were paired up at random with other geeks. (Early extreme programming?) Our mission: to write a BASIC program that sorted an array of strings.
Each pair had a computer to work on—we were in a room full of Apple II Plus's (or perhaps Apple IIes). We had a time limit, something like two hours.
I discovered quickly that my co-geek didn’t actually know much about programming, so I just kind of talked to him as I wrote the program.
We faced a big decision right at the start. Should we use the slower, but easier to implement, bubble sort algorithm? My comrade just kind of shrugged and agreed. I laid it on the line: if we do it this way, I said, we won’t win, because it’s too simple. It won’t impress the judges. But at least we won’t be embarrassed: we’ll have a working program.
So I wrote a little program that wasn’t fast but that actually worked to sort an array of strings. After we were finished, I told my Dad I wanted to go home, since there was no way we were going to win. So we left.
But—you can see it coming—we did win. Someone else from my school accepted the award on my behalf. I still have it.
Lesson? Shipping is important.
It’s kind of like what Woody Allen said, “90% of life is just showing up.” Software is the same: it has to “show up” first. If it doesn’t ship, it doesn’t exist.
I bring this up because I hear from people and read on weblogs about software that’s pretty cool but that never gets done. It doesn’t make it out into the world. And I often wish I could transfer some kind of magical shipping-energy over to the developer.
I don’t know why these projects, some of them in quite advanced stages, don’t ship. I know what I do: I myself don’t even conceive of not shipping. Once I have committed to a piece of software, I just keep going.
The brick wall of shipping
I actually picture in my head a weird little scene. I see a big field of grass with a line drawn in it, like a line on a football field. And then I picture a giant brick wall moving forward slowly but steadily toward that line. The line is the shipping mark, and the brick wall is the software. Nothing can stop that wall.
Part of shipping is attention to detail. It can get boring, tracking down and finding all the million little things. (Unless you’re a software developer, you may have no idea how much of software development is just about all the little details. It’s housekeeping. It can be overwhelming if you’re not used to it.)
Another part of shipping is making hard decisions. When do you stop? How do you know if a feature can wait until a later release? How do you know which bugs you can live with and which are deal-stoppers?
And another part of shipping is anxiety. What if there’s a terrible bug that doesn’t appear, despite all the testing, until right after it’s released? What if you made the wrong decisions about bug x and feature y?
What you do is just do the best you can—and when you make mistakes, you deal with them the best you can. You get better at shipping software every time you do it. Experience is your teacher.
Going back to my experience at that computer fair in 1982... I learned another important lesson. It’s not just that shipping is important—I also learned that I could trust myself to look at my resources and the amount of time available and the goal and make a good call. I learned I could trust my judgment. That doesn’t mean I don’t make mistakes—I have and I will. But I think this self-trust is important to shipping software.
(An important point though is that self-trust doesn’t mean don’t listen to other people. The opposite is true. You want as much feedback as possible. The buck stops with you, though.)
I’m stunned—I had a computer problem, zapped the PRAM, and the problem was solved. When has that ever worked?
We just updated NetNewsWire’s Frequently Asked Questions page. Please let me know if any of it is confusing or if there’s anything missing.
P.S. You can always get back to the FAQ page via the Help menu.
NetNewsWire and NetNewsWire Lite 1.0.7fc1 are both available now on the betas page.
This is a final candidate release—we’re looking for deal-stopper bugs.
This release has just a few changes since the previous beta: most notably, a bug with freshly-downloaded favicons not appearing was fixed. See the change notes for details.
So—here’s one way spammers are trying to work around Bayesian filtering. Random text.
One of my favorite NetNewsWire features is not new in 1.0.7, but I suspect many people don’t know about it.
When reading the new-headlines feed or a group, you can delete read items by typing the letter d. (Just d, no modifier.) (Or choose Delete Read Items from the News menu; or type option-cmd-K.)
It’s just a little thing, but I find it very useful.
You can find more keyboard shortcuts like that by choosing Keyboard Shortcuts from the Help menu.
RSD—Really Simple Discoverability—turns one year old today. RSD is what NetNewsWire uses when you click the Autofill button when configuring a weblog for editing. Thanks go especially to Daniel for making this happen.
NetNewsWire and NetNewsWire Lite 1.0.7b7 have been posted.
In the process of working on 1.1, we fixed a mach port leak and some performance bugs, and we didn’t want to wait until 1.1 before making these fixes available, so we decided to do a 1.0.7 release.
1.0.7 also contains a few of the smaller features that were planned for 1.1: a new widescreen view is especially suited to laptops; favicons are now displayed in the Subscriptions pane; NetNewsWire now responds to the feed URL scheme.
See the change notes for more new features and bug fixes.
The features chart comparing NetNewsWire and NetNewsWire Lite has been updated.
As a boy living just outside Newark, Delaware my favorite college team was the Fightin’ Blue Hens. I remember well when they won the Division II championship.
I also remember hating their various rivals—Temple, Lehigh, Villanova, and, most especially, Colgate.
Gimme a C! Gimme an O! Gimme an L! Gimme a G! Gimme an A! Gimme a T! Gimme an E!
What does that spell?
Anyway, now the Hens will face Colgate in the Division I-AA championship this Friday.
Go Blue Hens!
(It’s not lost on me that a fightin’ blue hen doesn’t sound as ferocious as a lion or a bear. Oh well. I probably shouldn’t mention, but I will, that the football team for the nearby high school is the Ballard Beavers. “You better get outta my way Mr. linebacker or I swear I’m gonna build a dam in this creek.”)
Buzz Andersen posts on the problems with interfaces that mimic the real-world too closely.
Here’s a picture Sheila or I (I forget) took a few years ago of Mt. Rainier. It’s taken from the car while driving south of Seattle on I-5.
And here’s Elvis.
Spammers send email to email@example.com—and assume that “info” is somebody’s name. Note the subject line in the screen shot below:
I started to come under comment spam fire again today. It didn’t last long. (It could be that they’re just taking a break.)
What happens to people that they grow up to be so unethical? Just wondering.
One of the best ways to help a developer improve their software is to report bugs. But of course there’s an art to bug reporting.
Most of the bug reports I get for NetNewsWire are very good. But now and again I get a report that isn’t that helpful, and I have to ask a bunch of questions before I understand it.
Here’s a made-up example:
“I subscribed to the The Cool Foo Bar feed, and it doesn’t display correctly.”
That immediately brings up a bunch of questions. The biggest one is: what’s the URL of the feed? Without the URL, I can’t possible reproduce the bug. If I can’t reproduce the bug, I can’t fix it.
More questions: does the feed validate? What view are you using (Combined View or traditional view)? What about the display is incorrect? What version of NetNewsWire are you using? What version of OS X are you using?
When I worked at UserLand we used to suggest a format for reporting bugs. It’s a good format, and I recommend it to anyone reporting bugs to anybody. The format:
1. What I did. This should include as much detail as possible.
2. What I expected.
3. What actually happened.
Knowing what was expected is important information. Sometimes bugs aren’t bugs but are misunderstandings. Sometimes the app is working as designed, but really it should work as the user expects. But most of the time a bug report describes an actual bug.
Another thing: if applicable, include a screen shot as part of #3. This doesn’t make sense for some types of bugs, but for display bugs it’s hugely valuable.
Now, as I said, most of the bug reports we get are quite good. So this is just for people who’d like to make their bug reports more useful.
I’ve written before about how listening is the most important skill a software developer can have.
One part of listening is the art of listening to feature requests.
Sometimes you get a feature request that describes a problem and proposes a solution that’s right on the mark: all you have to do is implement it. Sometimes you get a feature request that’s just about right, and with a little modification and back-and-forth you end up with the right thing.
And other times you get feature requests that describe a problem but propose a solution that’s not right. So the art here is listening to the problem. Sometimes it’s not always plain, you have to figure it out (often by asking questions of the person who made the request).
For example: think about how Exposé must have come about. Users made requests about ways to find a given window easily when you have a bunch of windows open. I imagine people suggested solutions like a system-wide window menu.
But what Apple did in this case was listen to the problem rather than specific solutions, and they came up with a solution that probably nobody had asked for—but that works wonderfully (and that, as a bonus, delights people who use it).
Not every feature request will be solved so dazzlingly. Most requests are for small problems with simple solutions. But it’s worth keeping Exposé in mind as an example of the art of listening.
I’m old enough to remember when it was new. My arcade-playing days predate the first-person games—for me, arcade games are about shooting things in outer space. Controlling a human walking around with a gun seems so mundane and puny. I need rockets and ray guns.
Another favorite was Missile Command. Does anyone know of a good OS X version of Missile Command?
One thing that always bugged me about Project Builder is that there were no keyboard shortcuts for the most common source code management commands.
The commands I use most often are Compare with Latest and Commit Changes. It was such a pain to have to actually use my mouse. Hey! I’m a programmer! Don’t make me take my fingers off the keyboard!
Anyway... In Xcode you can now customize the list of keyboard shortcuts. So I gave Compare with Latest cmd-option-L and Commit Changes cmd-option-C.
That took away the pain of doing cvs stuff. And now, I’m happy to report, the sky is bluer and the air is fresher.
“Just a minute... I have to deal with these shapes.”
I’m so looking forward to Battlestar Galactica.
I was about 10 years old when the original series premiered. I had already seen Star Wars of course and I was a big Star Trek fan (there was only the original series in those days; I’m not sure if even the first movie had come out yet).
I loved Battlestar Galactica. Space! Space battles! Lasers! Really fast and noisy space fighters equipped with lasers!
I was sad when it was cancelled.
(Another space show I loved was a sitcom: Quark, starring Richard Benjamin and John Candy. Nobody remembers it these days.)
I’ve read a bit about how purists are upset that the new version of BG changes a bunch of stuff. Me, I’m cool with it. It’s just TV.
It seems a bit more grown-up-ified. More babes and more philosophy.
But I find myself looking forward to it much the same way I did when I was 10 years old. Space! Space battles! Lasers!
I’m easy to please.
One thing has stuck around with me since the original series: sometimes when I get mad, instead of cursing I say felgercarb. Felgercarb was a made-up curse word from the future.
This makes me a hopeless geek, I know.
(My guess is that felgercarb refers to carbonized felger, the waste product of robots.) (I’m joking.)
I was thinking about what if cats wrote Christmas carols.
It came upon a midnight fish...
Good King Wenceslas looked down
on the fish of Stephen...
Jingle fish, jingle fish...
Away in a manger,
no crib for a fish...
Silent fish, holy fish
All is calm, all is fish
Thanks for the Eddy award also go to some people who’ve made direct contributions to NetNewsWire.
Bryan Bell did the application icon (which I adore).
Robert Daeley wrote some of the documentation on using the weblog editor with various publishing systems.
Sheila and I were so excited when we heard that NetNewsWire had won an Eddy. Imagine us jumping up and down in our little office, with our cat Papa wondering why the monkeys had suddenly gone crazy.
We got the news about a week ago, but then had to wait for the press release to appear before saying anything. But knowing about it made for an extra-nice Thanksgiving.
Huge thanks go to everyone who has supported NetNewsWire by using it, buying it, telling other people about it, sending feedback, making feature requests, and submitting bug reports. You’re what makes the difference between so-so software and Eddy-winning software. So: thank you very much.
If you’re a software developer, you need to understand the perspective of people who use your software.
I ran across a good, small example of the difference between the two perspectives, via an email from a NetNewsWire user. I mention it because it might be illustrative of one of the ways developers and users see things differently.
It also illustrates one law of UI design: don’t let the logical and correct thing get in the way of the right thing.
Here’s the example:
When you import an OPML subscriptions file into NetNewsWire, if the file is a valid OPML file but contains no subscriptions, NetNewsWire doesn’t report an error.
It’s logical, no? It’s a valid subscriptions file, and NetNewsWire successfully imported zero out of zero subscriptions.
But it’s not the right thing, because someone using the software is left wondering what the hell just happened. An error message that explains that the subscriptions file contained no subscriptions would be the right thing to do.
So here’s another law of UI design: while developers see zero as just another number, users often see zero as an error.