February 2019

I’ve been getting more NetNewsWire feedback now that I’ve called it actually usable now.

Feedback is always an education. (See the most recent issues for some of it.)

There are things I expect to see, and then do see. Things I expect to see, and then don’t see. And things I didn’t expect at all.

It’s a great reminder that everybody’s different, and people want different things. They want to use the app the way they want to use it.

The tricky part is deciding what to do, of course. When I was younger, and selling NetNewsWire, I was reluctant to add features and preferences — but I did it anyway. A lot. I wanted people to buy the app!

But it did mean that NetNewsWire became, in at least one person‘s words, a kind of “Swiss Army knife” of RSS readers. This made it difficult to move forward with new features that I thought would be cool and useful.

Now that I’m older, and I’m not trying to please everybody and make money, I’m even more reluctant. I want to keep the app as simple as possible — because I like simple apps, and because it means I have time to add other features that I’ve never done before, but that I always thought would be cool.

But, at the same time, I really do want it to be used by as many people as possible. So there’s a tension there which I find interesting. My position on it is just to go slowly — which I can’t really help anyway — and think hard about each issue.

One That I Did Not See Coming

One of the unexpected things is Add way to see how many total unread items there are within the app.

There is a way, of course. There are two ways, even: the unread count appears in the Dock icon and beside the All Unread smart feed.

You’d think that would be enough — but it’s not. Consider that you might have the Dock hidden, and consider that you might have enough feeds and folders in the sidebar so that you can’t see the All Unread smart feed — it’s scrolled off.

Then what?

It could go in the toolbar — but some people run with the toolbar hidden. And, anyway, I never like status-y stuff in the toolbar. It could be a non-default toolbar thing — people could add it. But I’ve learned that lots of people don’t know you can customize toolbars.

How about a status bar at the bottom of the sidebar that can’t scroll off? Older versions of NetNewsWire had this.

Sure — but the trend these days, which I like very much, is to have a clean bottom edge to the window. No chrome. Look at Mail, Safari, Pages, and Numbers.

Well, okay — do that, but make it a View menu option, off by default, so we keep the clean edge.

Ugh. Now we’re going down the road of endless permutations of little things you can configure. That’s the road I want to avoid as much as possible. Do we really add that just because of the probably rare case where someone hides their Dock and the All Unread smart feed is scrolled off?

Another idea: that bottom-of-the-sidebar status view could appear only when the All Unread feed is scrolled off. But I really hate non-stable UI with weird little changes like that. It always seems too clever, and it makes me think the designer thinks they can paper over a design flaw by showing off.

Or there could be a non-scrolling indicator at the top of the sidebar. That ruins the nice line going along the top, though. But maybe the timeline needs a thing at the top for sorting, so maybe that line will go away anyway? And: wouldn’t this look weirdly redundant when the All Unread feed is not scrolled off?

So… what to do? I’m not actually asking for suggestions — though I’ll get some, because people tend to read things like this as problems-to-solve. (And I don’t mind suggestions. Not at all.) But what I actually intend here is just a look behind the development process at the point where people start giving feedback on an app.

Here’s what happens at this point: your design meets conditions you didn’t account for. They’re often rare cases, but they’re legitimate. And all the options seem pretty bad.

What will probably happen, in this case, is that I’ll punt on figuring it out till after 5.0 ships. I have no idea what I’ll end up doing. Which is part of the fun. :)

Our community is mourning the loss of Tristan O’Tierney today.

I met him before the iPhone days, I’m pretty sure. While we were never close, I was always happy to see him at WWDC and similar events, and I liked him tremendously. I had somehow missed that he had been struggling. I wish so much that he had not been.

Joshua Blankenship misses 2004 and personal websites. (Via Colin Devroe.)

The latest build of NetNewsWire adds searching, one of the last important things to do before shipping.

It still doesn’t have syncing yet. There are a few bugs to fix. It doesn’t have a new app icon yet.

But this is the first build where I’d call it usable. The core features of an RSS reader are there.

If you were holding off, waiting for a usable build, then you can stop holding off.

(But if you still want to hold off trying it until I add FeedBin syncing — or your preferred system — I totally understand.)

Reminder: it’s so basic it’s not even funny!

The ODB Editor suite — which came up on the latest The Talk Show podcast — happens to be something I know about.

Here’s what I remember about how it happened… (Dave Winer or Rich Siegel may remember more, or better, and may correct me, and maybe not.)

I was working at UserLand, or maybe still doing contracting, or maybe I was still just an enthusiastic member of the community. I forget. But I was nearby when this happened.

Dave had written a website rendering framework for UserLand Frontier that generated static sites. This was the mid-to-late 1990s. The pages were stored in Frontier’s object database, which had its own text editor.

The problem was that some people wanted to use BBEdit instead of Frontier’s built-in text editor, because, well BBEdit was (and still is) awesome.

So we wanted to make it so you could be looking at text in Frontier, and then choose a menu command to open it in BBEdit for editing — and then have it automatically update in Frontier’s object database when you close it in BBEdit.

In other words, we wanted BBEdit to be an external editor for Frontier’s object database.

So Dave — working with Rich? Doug Baron? Jim Correia? I honestly don’t know who all worked on the details, though it wasn’t me — came up with the ODB Editor suite, which any text editor could support. (The BBEdit site has documentation.) BBEdit supported it, and other text editors added support too over the years.

The ODB part stands for Object Database.

Years later, for MarsEdit 1.0 (or some early version), I implemented the server side of the ODB Editor suite, so you could open something in MarsEdit in BBEdit, and have it save back to MarsEdit.

PS I use MarsEdit to this day. MarsEdit and BBEdit still support the ODB Editor Suite. Just to try it out, I’m writing this post in BBEdit, and it automatically updates the text in MarsEdit. It still works. :)

There’s a measles outbreak in Washington State, where I live.

I try not to think about people not vaccinating their children. I nearly died as a result of having a terrible case of chickenpox during a blizzard. I live every day with damaged eyesight.

There was no chickenpox vaccine in those days. I sure wish there had been.

While working on show notes for an upcoming episode of The Omni Show, I found this classic blog post about Objective-C Memory Management & Garbage Collection.

I had completely forgotten about the finalize method.

In the latest episode of The Omni Show, I am the guest. How does this even work? Do I interview myself? What’s going on here?

PS I like being on podcasts, and I’d be happy to be on yours, to talk about Omni stuff or my own stuff or both. I could probably even convince Ken Case to be a guest on your show if you want to talk about Omni apps and developing for Mac and iOS in 2019.

(My email address is no secret, and every spammer everywhere already has it, so I’ll just post it here: it’s brent@ranchero.com.)

There are three big things that remain before the first feature-complete build (which will be 5.0a1): searching, the app icon, and syncing with FeedBin.

Brad Ellis is working on the app icon, so that leaves searching and syncing (and a few miscellaneous bugs) for me.

I’ve been working on searching — I want to get that done next, and then do syncing as the last thing before hitting alpha 1.

How search is implemented

The UI for searching is pretty straightforward: you type into the search field, and then the timeline shows your search results. Click on an article to show it in the detail web view. Exactly as expected.

But there are two ways I can think of to implement this UI.

1. When a search starts, do the search and show the results in the timeline. When the user ends searching, restore the previous timeline and detail view states.
2. When a search starts, swap in a separate timeline and detail view, do the search, and then show the results in these swapped-in views. When the user ends searching, swap those views out, and swap back in the regular timeline and detail views.

Ideally the user can’t tell the difference between the two methods. But if you go with solution #1 — use the existing timeline and detail views — then you have the challenge of restoring state, including selection and scroll positions, when searching ends.

If you use solution #2 — swapping views in and out — then you don’t have that challenge. State is restored exactly as it was, because you saved the non-search views and swapped them back in.

(If you look at other apps — Mail, for example — it appears they use solution #1, and state restoration is not always instant. I want it to be instant.)

So, for the past week, I’ve been re-jiggering so that I can have multiple timeline and detail views and swap them in and out.

(This is not that different from how searching in iOS apps is supposed to work.)

And then, last night, as I finished the re-jiggering, I did the actual search-in-the-database implementation, which took about an hour.

This still leaves me to handle changes to the search field, so that the search is actually run at the right time, and so that searching ends properly. I expect that to take a few hours to get all right. (I’ve done this before, and it’s always slightly more complex than it seems.)

Why do I make this point?

If you’re not a programmer — or you’re new to programming, or haven’t written apps with a user interface — it’s easy to think that the actual under-the-hood implementation of a feature is what takes the most time.

It’s not. In the case of the search feature, I spent more time just thinking about how I want to do the UI than on the actual search-in-the-database implementation. And then there’s the UI work itself, which absolutely dwarfs the database work.

Another case: you might imagine that the bulk of the work in NetNewsWire was writing an RSS parser, for instance. But no. While that code is critical, obviously, it’s very, very small compared to the user interface.

And, similarly, the part of syncing that’s just making API calls and updating the database will be the easy part. The part that takes longest will be user interface. A factor of ten would not be surprising.

Jonathan T explains how to activate Apple ID 2fa when you have two accounts.

Short version: temp user on your Mac, SMS as backup, delete temp user, SMS keeps working.

I just got an email from Apple that two-factor authentication will be required for my Apple Developer account.

I have two accounts — one for personal use, one for development use — and so do lots of developers.

I don’t know how to make this work. None of my devices are ever signed in to my developer account. That account exists purely for building and distributing apps.

Brett Terpstra writes about blogging, ethics, and thin skin.

I’ve been reading Brett’s blog for years — I trust him, and he’s a good writer. I also use his app Marked pretty much every day.

Daniel Jalkut has bad news for Blogger users — Google is shutting down an images API.

Colin Devroe reminds us not to rely on mega-corporations keeping our beloved services alive. They won’t.

There’s still snow everywhere — but the sun just came out, and I heard some birdsong, and I looked outside and saw a couple robins.

Cliff Mass, Seattle’s favorite weather blogger, writes that the end of all this snow mess is in sight.

Cheri Baker writes about Spotify in Dear Podcasters…:

I fear we’ve seen this scenario before. A biggish company decides that they’ll aggregate an immense amount of creative work and monetize it. They’ll offer you tools to make “sharing” easy, and at first the terms of service will be reasonable. But once they’ve eaten a big enough chunk of content, they’ll lock the gates tighter, change the terms of service, and monetize the audience. By that point, customers would feel locked into Spotify, and podcasters would be afraid to leave.

Let’s look back at last year first.

2018: Evergreen to NetNewsWire

As 2018 started, the app was called Evergreen, which I still think is a pretty great name for an RSS reader. I’d been working on it for about four years, on weekends and at nights.

It was usable-by-me a year ago, and a few other people were using it, even though it was missing all kinds of important features.

And then, some time in the spring of 2018, I thought to contact the folks at Black Pixel about getting NetNewsWire back. Seemed like a total longshot. But why not try?

And they surprised me by being interested! In fact, they mentioned that they’d already been talking about it.

I was clear that I wanted just the name — not the code, not the then-current users, not the sync service. The app named Evergreen would be renamed as NetNewsWire, but would be, in every other way, the same app I was going to write. It would still be free and open source.

They agreed. And then, of course, discussions, mostly internal to Black Pixel, happened for a few months, because that’s how these things go — and we managed to make it official on August 31, 2018. (See NetNewsWire Comes Home.) Black Pixel gave it to me for free (we never haggled over price; that was their plan all along), and their generosity remains one of the things I’m most thankful for in my entire career.

Soon after that I renamed Evergreen to NetNewsWire — and memorialized the name Evergreen in the app’s bundle id: com.ranchero.NetNewsWire-Evergreen. (NetNewsWire will always be Evergreen.)

And so it turned out that I had been working on NetNewsWire 5.0 for four years already! I just didn’t know it for most of that time. :)

The rest of the year saw more work on the app, with code contributions from Maurice Parker, Olof Hellman, and Daniel Jalkut, with bug reports on GitHub, with the help of the folks on the NetNewsWire Slack group. (Which you can join too: just email me.)

That was 2018.

2019: Let’s Ship This Thing

At this writing we’re down to seven bugs in the 5.0 Alpha milestone. There are three main things: syncing with Feedbin, searching, and the app icon.

I want to ship 5.0 by WWDC, which is (most likely) the first full week of June. So here’s what I’m planning:

• Finish those last bugs, and ship 5.0a1.
• During the alpha period: write the Help book and document at least some of the code. Test, most importantly. Fix any bugs that get reported. Once there are no known defects, after a suitable period of testing, then ship 5.0b1.
• During the beta period, continue testing. The code will be touched only with great reluctance. (Every beta is a shipping candidate.) Continue documenting the code.
• Once there are no known defects, ship 5.0.

As you can see, the 5.0 Alpha milestone represents five years of work, and the alpha and beta periods ought to be relatively short, possibly just a couple weeks each.

But how quickly we get to alpha is mainly a function of how quickly I can get Feedbin syncing working and bug-free.

I think I can get it done by WWDC, but I could be wrong! No promises, of course. For NetNewsWire, app quality is everything, and hitting a date means very little.

Beyond 5.0: More Sync

There’s every chance that WWDC will bring changes and new technology from Apple that I’ll have to deal with. That’s expected — every app developer (hopefully) budgets for this. Assuming 5.0 is out before WWDC, then I can deal with this stuff in an update in the summer, in time for the next macOS.

There’s a huge list of features I could work on after that — there’s so much room for growth — but I think the big one has to be adding support for more syncing systems. I’m likely to do Feedly next, since it appears to the the most popular.

So my hope is to get Feedly support shipping by the end of 2019. And, if I do, then it will have been a very good year.

National Weather Service Seattle lets us know what’s coming up. More snow!

Thursday is the Last Dry Day.

Michael Zornek writes (and this is the entirety of his post):

It is not a podcast unless there is a RSS feed.

I love it when companies or products publish a roadmap. Omni publishes one every year — here’s the latest.

Today I ran across the Fiery Feeds Roadmap 2019. I’ve heard of Fiery Feeds, but I haven’t checked it out yet. Now I will, because the developer Lukas Burgstaller is a blogger and I enjoyed reading the roadmap.

Now, of course, I have to consider writing a NetNewsWire roadmap for 2019. The big thing on the list would be shipping 5.0. (I’ve been working on the app for five years! Time to ship.)