The Waffler

On The Horizon

Byline 3.0 has been in development for a long time, much longer than I expected due to various distractions and a failure to be realistic about the time I would need to make such sweeping changes to the app. I’ve been reluctant to release information about the project until its final form begins to take shape, which has led to some speculation that development has stalled altogether. I regret creating such an impression, and would like to assure you that Byline 3.0 is alive and well, albeit late. The success of Byline thus far does not mean I no longer care about improving the app; on the contrary, the knowledge that so many people are waiting for Byline 3.0 has only made me feel worse about taking so long over it — and will no doubt make the euphoria of finishing and releasing it even sweeter.

I haven’t reached the home stretch yet, but I feel it’s close enough to start sharing some details. Perhaps I just can’t wait to show off the cool things I’ve been working on. Either way, let’s start with the new “Folders” screen.

The redesign features icons by Emanuel Sá, who seems to get more talented every time I work with him. Besides being pretty, the new icons are a little smaller, which allows more rows to appear on screen. The unread totals are shown in grey bubbles on the right — just like Mail, and much clearer and more balanced than before.

The real star of the show, however, are the blue disclosure triangles to the far right of each folder. When tapped, these swivel open to reveal the feeds within, which can finally be browsed individually. I love everything about the way these work, from their iPhone-native appearance and smooth animation to the bare fact that they allow total control over the way you browse without adding another level to the app’s hierarchy.

Finally, you’ll note that Byline’s settings are now within the app. I’ve been considering this for a while, as I get the impression that many iPhone users simply don’t think to look in the main Settings app for third-party settings. In the end, my hand was forced by my desire to add some smart, dynamic new settings which can only be accomplished in-app. I’ll be talking about these in an upcoming post, so keep an eye out over the coming weeks, and in the meantime feel free to tweet feedback to @phfish.

Pushing It

I’ve been receiving an increasing number of requests for Byline to make use of the new Push Notification service in iPhone OS 3.0. Many people seem to assume — understandably, given Apple’s enthusiasm — that push notifications are just as effective as allowing apps to run in the background, and that using the service is relatively easy for developers given that Apple provides a large part of the infrastructure.

Both assumptions are more true for some apps than for others. Neither are very true for Byline, unfortunately.

The Benefit

Push notifications could be used to periodically update Byline’s unread count on the home screen.

… That’s all. No data can be loaded or processed beyond the notification itself, so Byline would still have to be launched with an internet connection available in order to sync, download and cache the new items. Note also that the updates would be periodic, not truly pushed as soon as new items appear in Google Reader.

The Cost

I would have to set up one or more servers with a high-bandwidth commercial internet connection. I would have to write custom software to receive and store the Google username and password of users who wish to receive push notifications. After that, I’d probably want to consult a lawyer. Then, I’d get the custom software to periodically poll each and every Google Reader account for the total number of unread items. Any changes would be pushed to Apple’s server. And so on, until Google blocks my IP address.

Value

Like most developers I love being challenged; difficulty alone is not enough to dissuade me from trying something. But a great effort should bring a great result, one which makes the app better for a large proportion of its users, and which justifies using time which could have been spent on other improvements.

For the vast majority of users, there’s no value in adding push notifications to Byline. Anyone who subscribes to more than a few feeds is likely to have new items appearing in their Google Reader account on a regular basis, so knowing the precise number of unread items awaiting them at all times just isn’t that important.

Conclusion

Apple’s Push Notification service is a good idea, but it does have limitations. It’s not very useful for apps which need to do more while they’re not active than simply attract the user’s attention, and it’s not very practical for developers who don’t control both the app and the web service on which it relies. Still, I’m not complaining — there’s no better solution until background processing becomes feasible, which I don’t see happening until the iPhone gets at least 512MB RAM and a dual-core processor.

How Not to Design an iPhone Icon

Byline 2.5 finally saw the light of day last week. The update has had a very positive reception, with the notable exception of the new icon, which has been roundly abused by almost everyone I’ve heard from. Making changes to anything which so many people are familiar with — fond of, even — always provokes a bit of a backlash, but I was surprised by the sheer volume of the complaints I received, and, on reflection, I think they’re justified.

The new icon is a blunder, one which I find particularly embarrassing because it’s Byline’s third icon in under a year, and I really should have gotten this right by now. Why haven’t I?

Byline 1.0	The best icons consist of a simple, distinctive visual metaphor which hints at the app’s function. I spent a long time considering suitable metaphors for Byline, but there are no easy answers. The idea of an RSS reader is fairly abstract — a newspaper is the obvious choice, but newspapers tend to be neither simple nor distinctive when depicted at the tiny size required for an iPhone icon. In the end I settled on a modified version of the standard RSS icon, but it proved to be too generic, as dozens of other RSS apps with similar icons began to appear in the App Store.
Byline 2.0	This was beautifully drawn by Everaldo Coelho, but when shrunk to the appropriate size the newspaper is rather indistinct and jagged (as I had feared). There’s just a little too much going on in this icon for it to work in so few pixels. Many users didn’t realise that the object sitting on top of the newspaper was supposed to be a coffee cup, and some found the icon distracting when glancing at their iPhones due to its similarity with the red notification badge. In addition, this icon is not a very good match for the new interface in Byline 2.5.
Byline 2.5	I thought that a bold typographic design would make up for the lack of a visual metaphor, but I should have known better. This is more logo than icon, and logos — especially unfamiliar ones — have no place on the iPhone. The black background makes it appear to have an unusual shape when viewed on the iPhone’s home screen; it stands out, but at the expense of being wilfully inconsistent with other icons. I don’t think the design is actually ugly, it’s just entirely inappropriate as an icon. I have no idea how I let myself think it was a good idea.

Byline 2.5.1?

Much as I hate to change the icon a third time, I almost certainly will, and swiftly. I’ll try to get it right this time.

Slowly Getting Faster

Byline went from 1.0 to 2.0 in little over three months, gaining along the way a totally redesigned interface, support for folders, a built-in web browser, and a host of other features. Byline 2.5, on the other hand, offers very few new features, yet when it is released in mid-April it will have been a whole six months since 2.0. Why?

Part of the answer is boring; other programming projects, moving house and general sloth all contributed to a much longer development time than I expected. But the other part of the answer is much more interesting — or at least slightly less boring, I hope.

What was wrong with Byline 1.0?

Byline 1.0 was the result of only three months of frenzied development. It had a number of shortcomings; one of the main ones was that it would only sync twenty-five items from each list at a time. When syncing each list it would initiate a download of data for the newest twenty-five items, wait for the download to finish, and then use the data to update the list. This was easy to code, as all the Atom parsing and updating of the data model and user interface could be done in a single step.

So what was wrong with Byline 1.0?

Nothing! This method of syncing worked well, because Byline only ever had to process twenty-five new items at a time. There wasn’t a problem until Byline 1.0.2, which offered an option to sync up to two hundred items at a time from each list. Suddenly, the processing time required to parse the data for a whole list in one big chunk was long enough to make the user interface freeze noticeably. The processor would sit idle until the data had downloaded in full, and then kick into overdrive, delaying the whole syncing process and leaving the interface unresponsive for several seconds.

Should I have done things differently from the beginning?

Not really. Less code is better code, and the best code is no code. Most of the time. In rare cases fast code is better than less code, but it’s usually impossible to work that out before you’ve written the concise version and tested it to death with performance tools.

What have I done to solve the problem?

I’ve implemented progressive syncing. In other words, as soon as Byline begins to receive data for the list it’s syncing, it starts parsing the data and updating the list. New items are added gradually starting from the top of the list, and a heuristic is applied to determine which items should be removed from the list as the sync proceeds, so that you don’t see a jumbled mess if you view the list while it’s syncing. Because the data is parsed a little at a time the user interface never becomes unresponsive, and you can start browsing new items straight away, as soon as they appear.

The only downside is that there is a performance penalty incurred by parsing the data in small chunks and updating the user interface gradually throughout the syncing process. This results in marginally slower syncing over a very fast Wi-Fi connection, when the data would typically load very quickly anyway and processor speed is the major bottleneck. Over a 3G or Edge connection syncing is now faster, as the processor gets put to work straight away rather than waiting around for significant periods of time while the data it needs is downloaded in full.

In any case, it all feels faster now that the user interface is responsive.

What else is new in Byline 2.5?

Most other improvements are also related to performance. Byline is now much more reliable when handling large numbers of folders, and should be less prone to forgetting data between runs, a problem which was caused by the length of time it took to write the data model to permanent storage.

One major new feature is a button to toggle a “sort by feed” mode — this should make quite a few people happy! Other than that, you’ll have to wait and see … but not for very much longer.

SecuritySpy Screensaver

A free Mac OS X screensaver which displays live video from one or more servers running Ben Software’s SecuritySpy. I’m hosting this here temporarily — it’ll be moved to the Phantom Fish website to coincide with the release of the SecuritySpy client for iPhone.

Download version 1.3 (Snow Leopard only), released 26th October 2009, version 1.2 (Leopard only), or version 1.0 (Tiger only).

You can configure the screensaver to connect to as many SecuritySpy servers as you like. The servers can be running over the internet, over your local network, or on your own Mac (using the address “localhost”).

To set up SecuritySpy to act as a server, please follow the advice on this page. If SecuritySpy is running on the same Mac as the screensaver, you only need to follow the first bullet point, which describes how to enable SecuritySpy’s web server.