Pukka

Just wanted to take a moment to congratulate Delicious on five years! Delicious was probably the first software many of us heard of that was using the idea of tagging, and now it's everywhere. I started using Delicious myself just shy of four years ago, both with a personal account as well as a shared work account at my former employer. That's where the idea for Pukka was born, after I (and several coworkers at our Mac-only company) got tired of switching accounts on the web all the time.

While many alternative services, most notably Ma.gnolia (which also works with Pukka) have also popped up and innovated in new and different ways, Delicious remains the grandaddy of them all.

Here's to five more years!

I've just released Pukka 1.7.2, an update which focuses solely on performance and speed. I studied the slowest points of the application and honed and sharpened those routines, making Pukka much faster at the things that it does most often in the background. And I studied the application launch and optimized the slowest parts of that as well.

I'm very happy to push out a free update that focuses so intently on making the application faster to launch and faster to use. So please, go grab it now and enjoy!

Update: I forgot to mention that I also made a change in the underlying URL fetching library used by Pukka on Leopard. Some time ago, I had moved to an alternate library due to stability issues on the then just-released Leopard release of OS X. Those days seem to be long gone, so I've reverted to the standard Cocoa way of doing this now for slightly better performance, but more importantly, better adherence to any system-wide proxy settings that you have set in your networking preferences. As always, you can keep up with the full release notes of each Pukka release in your RSS reader by following the appcast.

I've just released Pukka 1.7.1, available here, to address some user experience issues. This release features better keyboard navigation in the main and preference windows, some minor bug fixes with the preferences involving showing the accounts in the dock and menu bar, and it ensures that the most recent bookmarks are shown by default, something that wasn't quite working right in 1.7. Enjoy!

For the second year in a row, I'm proud to help Seth Dillingham in his efforts to raise money for the Jimmy Fund to fight cancer. His personal goal this year is $10,000, both by sponsorship of his cycling and (this is where I come in) his bundle auctions of Mac software.

If you'd like to help out, you can check out the info, where both Pukka and Meerkat are featured, build a bundle of the software that you want, and make Seth an offer for it.

There's a lot of great software on there -- apps that I use already include 1Password, DropDMG, MarsEdit, PlistEdit Pro, rooSwitch, Sound Studio, SuperDuper!, yFlicks, and YummySoup!, among others.

So go check it out!

After some public beta testing, I'm happy to report that Pukka 1.7 is now released! There are only slight changes over the beta release, but to reiterate, the main new features include:

• The description length can now be up to 1,000 characters in order to match recent changes to Delicious.
• The latest ten bookmarks across accounts is now shown in the dock and menu bar menus, if they are enabled.
• A backup of each of your accounts' bookmarks, as retrieved from the server, is made from time to time. See Pukka -> View Backup Folder...

There are two new features not in the beta, too:

• When selecting a bookmark from any of Pukka's menus, holding down the Option key will allow editing of that bookmark in Pukka.
• Application and document icons up to 512 pixels have been added for better appearance on Leopard and greater.

There are a number of bug fixes and tweaks, too -- the best way to read the full scoop is to use Pukka's in-app updating feature or check out the appcast RSS, and you can grab Pukka itself here. Enjoy!

I've had some enhancements to Pukka in the works for some time, but thanks to the launch of Delicious 2.0, I've been spurred into action to selectively put some of them into a release, as well as address some issues with the new platform. Chief among the latter is an update to allow post descriptions up to 1000 characters, or rather, to only warn when they are over 1000, not the previous 255, characters.

I'm releasing a beta of Pukka 1.7 that also includes the following:

• The latest ten bookmarks across accounts is now shown in the dock and menu bar menus, if they are enabled.
• Performance has been tuned in the menu bar item, which also translates to a faster launch time if you are using the item.
• A backup of each of your accounts' bookmarks, as retrieved from the server, is made from time to time. See Pukka -> View Backup Folder...
• The posting sound effect, if enabled, is now played properly when the preference to quit after posting is turned on.
• Tooltips have been added to menu bar items to display the full bookmark title if they are truncated for display.
• Account passwords are remembered for the duration of Pukka's launch once they are retrieved from the keychain, including across system sleep.

Some other minor tweaks have been made as well, and I'd appreciate some testing. So, if you are reading this, consider yourself invited in the beta. Now take it for a spin!

Just wanted to pop in and mention a few appearances of our apps around the web recently since the Meerkat launch. Things are really moving this summer!

Again this year, I'm happy to announce that I'll be supporting Seth Dillingham in his efforts to raise $10,000 for cancer research and treatment. Last year, I was able to donate some Pukka licenses and this year, I'll be doing the same, plus adding Meerkat into the mix as well! I'll be blogging more about this as the time gets closer. How can you help? If you are a software user, check out his auctions, and if you are a Mac developer, please consider donating some licenses to your application(s) to help in his fundraising. Seth is riding his bike across the entire state of Massachusetts and all you have to do is continue to use great Mac apps to help!

Next up, I was happy to learn that a fun podcast, NeatLittleMacApps, reviewed Pukka recently. If you like, well, neat little Mac apps, you should check out this podcast and especially Pukka's episode. Thanks, NLMA!

Lastly, stay tuned soon for an update to Meerkat. I'm happy to report that thanks to some great beta testers, there are no known bugs in the 1.0 release, so I'm focusing on some great feature enhancements and additions for the next release. Have an idea? Contact me and let me know so that I can get it on the roadmap. And if you like Meerkat, please consider bookmarking it on del.icio.us (I know a great app you can use), adding it on iusethis, and posting a review on MacUpdate or VersionTracker.

I'm happy to report that a rather longstanding issue with posting in Pukka has been resolved -- on the del.icio.us side of things. That is to say, the version of Pukka that you are using right now will now work properly with no action required on your part.

I had been getting some reports from users of periods of inability to post for a few months now, but only very occasionally. Users would get a message like this when trying to post:

This would happen many times in a row in a short period, but then eventually go away after a few minutes. It turns out that the resolution may have been due to users finally getting a different del.icio.us backend server, one without the problem, but without knowing otherwise on the frontend of things.

Unfortunately, the condition that was producing the posting problem was indistinguishable at a network level from being offline when trying to post (which would obviously fail). So it was difficult to determine if this was a sporadic networking problem on the user side or something deeper. However, in the last week or so, the frequency of folks seeing this problem went up, so I began to hand out some debugging builds of Pukka that could supply me with more information about what exactly was happening.

Once I had this info, I posted to the del.icio.us developer Yahoo! group about the problem and within a day or two, they were able to track it down to a problem in their system.

So in review, I'm happy that this is resolved, but by all means, please do let me know if you continue to see it, especially if you are using Ma.gnolia or another non-del.icio.us service as I have never had a report of a problem under those conditions.

I'd also like to extend an apology to users of Pukka who have been dealing with this for a couple months. As I've mentioned before, it can be difficult when core functionality of your application relies on a third-party, network-based service, so it's important that if you are having a problem that seems to be related to the service to let the developer know so that they can get to the bottom of things as quickly as possible. More votes means more time with my eyes on the problem and hopefully a speedy resolution!

First off, I realize that I'm a little late to blog about this, but this past weekend I've been in the process of moving. I'll certainly be posting more on that in the not-too-distant future, but suffice it to say that I've been a little busy these past couple days...

Anyway, last week, I was thrilled to hear from my friend Daniel Jalkut of Red Sweater Software that Leo Laporte singled out and mentioned Pukka on MacBreak Weekly, his weekly podcast, as a Pick of the Week. Ever since I learned that both Leo and productivity geek and frequent show guest Merlin Mann had used Pukka, I was hoping that they would mention it. A few months ago, my friend Jim alerted me to the fact that Pukka's posting sound effect appeared in the middle of a MacBreak Weekly episode (Episode 65, about 10:20 into the show) but no mention was made of Pukka -- though obviously someone was using it during the show! That's why in this past week's episode, when Leo and the guys spent a good chunk of time talking about Pukka, I was really excited! I found the spot in the show (Episode 82, about 1:36:18 into the show) and my wife and I sat down to listen.

On the whole, I was quite happy with the feedback -- after all, Leo said "I love Pukka" and "Pukka is simple -- it just does what it does." But pretty quickly, though the feedback about the app never went negative, I heard something that made both my wife and I take pause -- "They shouldn't charge for it, but they do."

I'm not going to rehash arguments for and against this, as Daniel wrote eloquently on this and received 87 comments on his blog post before he closed commenting. I really wanted to get my word in there, but the time for that conversation has passed (however, you should still go over there and read both Daniel's excellent analysis as well as the many thoughtful comments if this is a topic of interest for you.) Other folks also got their say on their own blog posts: Michael McCracken, Tom Armitage, Matt Johnston, and Baron VC, for starters.

One of the commenter's thoughts, about Pukka being no more than two hours of work, is ludicrous enough that I'm not even going to address it save mentioning a few nuggets of Pukka's programming that could keep you busy for more than a couple hours each:

• AppleScript support
• Spotlight support with Core Data
• Scalability testing on up to 25,000 bookmarks
• Custom managed object deletion policy in Core Data (Hint: when deleting a bookmark, only delete each of its tags if it was the last bookmark for that tag, and when deleting a tag, only allow deletion if all of its bookmarks are deleted, but maintain a consistent and responsive data set during these transactions. Also, see above re: 25,000 bookmarks.)
• Sparkle support: Cocoa code, but also a distribution and appcast feed update process.
• Working out fun API issues like inconsistency and client throttling.
• Trying to implement dockless mode while maintaining future compatibility with Leopard code signing. Also, taking the time to blog publicly about it as a way to help other programmers as well as to open your own thinking to analysis & criticism by others.
• Dealing with a Leopard API instability that is core to your application. Also, taking the time to blog publicly about it for your users and for other developers.
• Doing the above with an installed user base on Tiger and Leopard.
• Doing the above, while providing what I feel is an above average level of support, for two years.

I'll leave that argument as is -- blame the above list on a lot of driving in the past few days while thinking about that specific comment ;-)

It's true, at first glance, Pukka may not look sexy (it doesn't produce smoke effects, after all) and may seem to be nothing but a simple form-like frontend to a free, public service, but as many kind commenters on the above-mentioned blogs have pointed out, and as Leo himself summarized when he said, "It doesn't do much -- I just love it!", Pukka represents hours and hours of thought and planning and attention to the user experience -- that is what is king in the Mac software business. Mac software for me is like a good relationship -- the more time you invest in the software, the more richly you will be rewarded with little surprises and delights along the way. You can see the kernel of this idea in my first post here over two years ago:

I set out to write a program that does the actual posting and I had it working that night. It grew from there as I lovingly tweaked it and worked with beta testers to make it better. I hope you like it. What’s more, I hope that you’ll support my efforts so that I can keep the creative juices flowing.

I followed that up a few months later when I started charging for Pukka:

If you look at my blogroll, you’ll see over 30 Mac developers or products that I admire, nearly all of which I use and have paid for, if they charge. I’ve easily spent several hundred dollars on Mac shareware [...] The Mac has shown me what it has undoubtedly shown you — that software is art, and Mac users have deeper loyalties than price points.

On the topic of pricing, it's true that there is some voodoo to determining the price of a piece of software that you've created, and I say that even though I do not make my entire living off of Mac software (though I will point out that Pukka enabled me to bootstrap my own business, including starting out on my own and enabling me to attend developer conferences and meet like-minded entrepreneurs.) I don't typically like to quote the same blog when discussing two different points, but again Daniel Jalkut nails this topic in his post The Price is Wrong from several years ago (there's a reason Daniel attracted a Daring Fireball link and 87 commenters on his latest post.)

I'm all on board with free software if it works for the developer -- in fact, the day the MacBreak Weekly episode was published, I released a little freeware application called Snarf for icon designers. I maintain and build Drupal modules. And before that, I released a number of open source programs like Ticketsmith, spliff, and purgeimap.

But for me, it all comes down to this: what will the market support for an application that, for the right user, adds at least that amount of value to their workday? For me, right now, that's what I'm charging for Pukka. I hope that you agree, but if not, I fully support your right to make a better application, at a price point that works for you, or to use the free services that Pukka works with yourself directly. And I'll even help you out if I can, because others have certainly helped me along the way.

One of the challenges of developing Mac software, particularly for an audience that is generally more technical than the average user, is that your users compare your application to others that are out there on the basis of how they utilize the rich set of technologies available on Mac OS X. And I'm not just talking competitors here, but any Mac application. This can be both a blessing and a curse, as it can inform you of and inspire you to add great new features, but can also cast a seemingly bad light on your own product if you are unable or unwilling to implement certain functionality. Users often don't care why you might not want to or can't implement features which are, in your own estimation, not the "right" way of doing something -- at least not right now. Other apps are doing it, why can't you?

I'm hoping to provide some insight into my thought process on making these judgement calls and talk about a specific issue that I've been working on in this department. I'll get a bit technical, but I'll try to explain along the way for the non-programmers in the room. And I'll mention a couple of other apps by name that handle the same issue in different ways. I don't mean to call out or embarrass anyone, and all the apps that I mention are ones that I use (and love) on a daily basis, but I want to show what other developers are doing. Lastly, I have an overriding goal here to be a somewhat exhaustive resource for this particular issue for other programmers to find, too.

What's up, dock?

A big feature request that's been hanging around for some time for Pukka is the ability to run without a dock icon. For a utility with a small footprint like Pukka, this makes a lot of sense for a number of reasons:

• As of Pukka 1.6, a status bar menu provides omnipresence for all of the app's "background features" -- looking up bookmarks and visiting your links online.
• Pukka is not visible when you are not using its "foreground features" -- posting bookmarks -- anyway. Some users would like to not have to think about it by seeing it in the dock and task switcher.
• Pukka has long supported a "quit after posting" feature which quits the app entirely after a post is made. Since you can call Pukka via your RSS reader or the browser bookmarklet and since it's lightweight and starts quickly, Pukka can come and go only when you need it. People who like an uncluttered dock really appreciate this, though some people would rather have Pukka running all of the time, but still not in the dock. After all, lingering invisibly in the background is faster than starting up on demand.
• "All the other apps are doing it!" :-) Apps that I use that have a user-configurable dockless mode include Twitterrific, MenuCalendarClock, Knox, BluePhoneElite, SSHKeychain, and iShowU. There are many more that do as well.

I should make a distinction here between applications like Lighthouse, Macaroni, and Growl (which I also use) which always run dockless, since these apps have alternate interfaces -- typically robust status bar menus or preference panes -- that allow use of the application. I'm talking about applications that let you choose on a whim whether you'd like to run without a dock icon or not -- defaulting, of course, like normal applications, to running with a dock icon.

Users who are used to dockless apps know the downsides -- no application switching, the app doesn't show up in the Force Quit menu, and sometimes there are window focus issues -- and are willing to accept them as limitations in Mac OS X. But there are some issues on the developer side that make this feature more difficult than one might think at first pass.

How do you work this thing?

The only real way^* to make an application run dockless is to change a setting in a file inside of its application bundle -- though a variation on this exists, as I'll describe in a little bit.

* I do know about TransformProcessType, a Carbon call, which can go from dockless mode to having a dock icon, but this has to happen too early in the launch process to read a user's preference setting, plus it's only a one-way transition.

A Mac application is actually a folder named <application name>.app containing a number of files and folders, one of which is called Info.plist. This property list file contains entries such as the application's name, version, copyright info, and other info used by the system to query what the application is all about.

If you add an entry to an application's Info.plist called LSUIElement and set its value to a string containing the number one, relaunching the application will make it go dockless. There are even applications like Dockless and Dock Dodger that will do this for you for a given application. Most of the applications that I mention above use this method to go dockless.

However, I've long preferred not to do this for a couple reasons:

• It's bad form for an application to modify itself -- though I realize it's not the end of the world.
• If the user is not an admin or if the application is located someplace like a network-mounted share, the user will not be able to -- and shouldn't be able to -- modify the app bundle that is shared by other users or even other computers.
• Lastly -- and this is the big one -- Apple introduced code signing in Leopard and, according to the documentation, it's only a matter of time before this method of altering the Info.plist will render the application unusable.

With code signing and Info.plist modification on the fly, the writing is on the wall:

A seal, which is a collection of checksums or hashes of the various parts of the program, such as the identifier, the Info.plist, the main executable, the resource files, and so on. The seal can be used to detect alterations to the code and to the program identifier. #

Various components of the application bundle (such as the Info.plist file, if there is one) are also signed. #

Your code must be immutable once signed. After signing, do not attempt to change executable code (including symbol tables), the Info.plist, or your program’s resource files. Do all that before signing. If you make modifications after signing, the signature may be invalid. #

And according to Apple, you should be signing code now. Not doing so can interfere with the keychain user experience, Parental Controls, firewall, and other integrated systems in Leopard that rely on code signing.

So, where does that leave us?

When I talked to Marko Karppinen, whose company makes the excellent Knox security application, at last summer's C4 in Chicago, he let me in on how he accomplished a user-specified dockless setting in that application.

If you look at the application bundle, it contains another copy of the application within a subfolder of the app bundle itself -- sort of a Russian Doll. But if you look closer, you'll see that all of the components of this "inside" application are actually symbolic links to the parent application's version, except for the Info.plist file. And -- you guessed it -- the internal Info.plist has the LSUIElement set. For the curious, here is a shell script that I came up with to be used as an Xcode build phase to accomplish this.

I'm actually using this method successfully with Meerkat, my next application (which is currently in private beta) and it's working ok for now. On launch, the application checks to see if if the user's preference setting matches the setting of the version being launched and if not, it launches the other one. Pretty sweet, right?

It is, except for one thing in Pukka's case -- Apple Event targeting. Besides being launched normally, Pukka can be launched by a number of external forces, including:

• AppleScripts that interact with Pukka
• Posted information from RSS readers like NetNewsWire using its author's External Weblog Editor Interface
• Pukka's bookmarklet, which actually uses a custom pukka:// protocol to pass information
• Opening http:// and https:// URLs with Pukka like you would with an alternate web browser
• Opening a supported file, such as a .webloc on the desktop, a Pukka license file, or one of the Spotlight files that Pukka generates for easy access to your bookmarks via system searching

On launch, not only do I have to figure out if the right version is running, but if not, I have to pass whatever information actually launched the application to a new process. I've actually managed to accomplish this for everything but AppleScript, but it's still non-ideal. It comes down to the fact that it's just generally bad practice to have more than one copy of the same application on the same hard drive because Mac OS X's Launch Services can get confused as to which one it should be targeting.

On top of that, since Pukka uses Sparkle for auto-updating, some issues needed to be resolved in order to update the outer, docked application and not the internal, dockless one, even if the internal one is the one running the update. Overwhelmed yet?

Now what?

So right now, I'm at a loss as to how to proceed. Apple doesn't provide a tried-and-true way to let the user toggle an application's dock mode and although many applications implement this, it seems to me that no way is fool-proof nor future-proof. The last thing I'd want is to release the feature but have to revoke it later from paying customers because it's untenable.

Cocoa developers, anything obvious that I'm missing? Have you tackled these challenges? Are you thinking about adding the same feature to your application?