I was recently surprised by a new icon in my OS X status bar that I hadn’t seen before. As someone who keeps a pretty tight rein on my already crowded bar I wasn’t too impressed to find this automatically appear there without my knowledge or consent.

If you click on it you’ll find it’s part of Google Chrome:

After doing some digging it seems this is part of a new Chrome notifications system that was added in Chrome 28.

I tested on a different machine still running Chrome 29 and it looks like this status item actually had a different icon (a message bubble, shown below) and this has been updated to a bell in Chrome 30.

I closed and reopened Chrome 30 and the icon disappeared. It turns out that it doesn’t show the status item unless you have notifications waiting, except that it seems to show once the first time after you update even if there are no waiting notifications.

To get the status item to show up again I had to generate a notification using this javascript notifications example. There’s also a Google Chrome extension you can use to create and debug notifications. I used it to create the notifications below to show how the new notifications UI works:

Pretty as it is, this is a feature that I don’t personally need or want, and I looked around for a Setting to disable it. The closest I could find was buried several clicks deep in the Privacy section under ‘Content Settings…’ and then the Notifications section:

I tried changing this to ‘Do not allow any site to show desktop notifications’ but the status item persisted. After some googling I found that there’s a option that you can get to by putting chrome://flags into the address bar that (after a relaunch) allows you to disable the status item permanently:

After doing this, when a notification is generated Chrome will revert to using the standard built in system notification system instead which I think should have been the default setting:

This leaves me with a few questions:

1) Why is this status item switched on by default after an update without any attempt to ask or inform the user what has happened?

2) Why is there no setting in the main Google Chrome Settings to toggle the status item?

3) If this feature is experimental and still missing some options then why is it switched on by default?

4) Why does Google Chrome have its whole own notification system instead of integrating with the built in OS X notification system?

You might think this is a strange thing to want to do in which case this post isn’t for you.

The Dropbox sync icon in the OS X menu bar has been irritating me recently. I have all of my documents folder synced so just about every save I do makes the icon change to the spinning sync icon and it draws my attention to the menu bar which I find annoying. I’ve written a little bash script to make the menu item always show the idle (green tick) icon even when Dropbox is actually syncing. It simply replaces the syncing menu item images with the idle ones instead. You can still click on the menu item if you want to see what’s actually happening.

Here’s the script to make it always show idle – Open Terminal.app and paste it in. You’ll need to re-run it each time the Dropbox client auto updates (not that often in my experience):

Epic rant about the trials and tribulations of building a Mac app follows. I’ve decided to lay it out with warts and all so I can reflect on the process. Hopefully it provides some insight into how an app gets made and helps other developers avoid some of the mistakes I made along the way.

It started the way all my apps start. I had a problem I needed solved.

I had taken to using Twitter to respond to feedback about my apps. I’ve mostly stuck with using the Twitter website on my Mac and only use a dedicated client on my iPhone.

This was fine, the only problem was that when I had the Twitter website closed I would miss peoples mentions. What I wanted was a simple app that would let me know when I had new mentions waiting.

I headed to the Mac App Store and did a search for ‘twitter notification’ – here’s what comes up when you search for that:

Bird Bell was the only app that looked promising, the others definitely didn’t do what I needed. I installed BirdBell but found that it didn’t notify you when you get mentioned, only when someone follows you, retweets you or adds you to a list.

I hunted around for a while but I couldn’t find a simple app to notify me. I finally asked on Twitter:

A few ideas came back, I could setup a dedicated email account, get mention notifications sent there and then use a mail notifier app to show me notifications for this account, or I could setup SMS notifications to my phone. Ugh. The last thing I want is Twitter taking over my phone as well.

No problems, I thought – I’m a Mac developer. I can whip up an app to do this in no time. Maybe I can even put it on the Mac App Store and sell a few copies. Looking back, I can only laugh at how naive I was. What I thought would be easy and only take a few weeks to develop would end up being a five month long nightmare project that the universe would try very hard to stop me shipping.

I fired up VoodooPad and started drafting out my masterpiece. This is what I came up with:

As you can see, the idea was simple enough – I didn’t think the app would need a full user interface, just some basic preferences and a menu item. I also thought I would have the app simply poll the public Twitter search API, that way I wouldn’t need to worry about handling authentication. You simply give it the username you want to check and the app requests http://search.twitter.com/search.json?q=@johnwinter every now and again and checks if there’s anything new there.

I went ahead and coded up a prototype. Here’s a quick demo I recorded at the time:

As you can see, my initial design was pretty rough, but it got the job done.

Around this time it occurred to me that the app would need an icon. I sent the video and some ideas I had for the type of icon I wanted (below) to Taher – a designer friend of mine and asked him to have a go at it.

This is what he sent me back:

I was thrilled with that, and he also convinced me to change the name to Tweetifier. But now I felt that the app design wasn’t good enough for the icon.

After some more discussion, Taher did a completely fresh design for the app:

Although I was initially reluctant to increase the complexity of the app by having a full feed display, seeing this new design convinced me otherwise. I decided it would be nice to be able to see my mentions and also reply to them.

I went ahead and implemented the new design, starting with the updated status item. Here’s a short video I recorded:

Much nicer than my first prototype, but the main UI still needed implementing.

Apple change the game

Around this time, Apple held their yearly Worldwide Developers Conference (WWDC) in San Francisco and released the MacBook Pro with Retina display. I decided that if I was going to release Tweetifier on the Mac App Store, it should look great on these new MacBooks. This would mean doing two separate versions of all the app artwork, one version at the standard size and one at double size (2x) for the new displays.

The other thing Apple announced at WWDC was OS X Mountain Lion. I remember watching Craig Federici demo the new Twitter integration – one of the features announced was the ability to display a notification when you received a new mention on Twitter. I was a little concerned by this, as it seemed like there would be little need for my app if Apple built the main feature right into the operating system. It would suck if my app was Sherlocked before I even released it.

I downloaded the Gold Master of Mountain Lion so I could decide if there would still be a need for my app after Mountain Lion shipped.

Initially, it didn’t look good. Setting up a new Twitter account on Mountain Lion was straightforward and I could easily set notifications for mentions and direct messages. I tried tweeting myself from another account and waited for a notification to appear. Nothing happened. I fiddled with the notification settings, removed and re-added the account, tried a reboot and looked for messages in the Console. I even installed Mountain Lion on a different machine, but I still couldn’t get the Twitter notifications working.

I googled around for a solution, but Mountain Lion was still under NDA and I couldn’t find anything about the issue. I had to assume Apple would fix this eventually though and if their notifications would actually work it could still spell trouble for my app. In light of my findings, I decided to continue on with the app but planned to add some extra features not offered by Mountain Lion (more on that later).

The scope changes

I finally got the main UI working and got the app checking Twitter for mention updates. This brought to light a new problem – the Twitter search API for unauthenticated requests was very restrictive in terms of how many requests you could make. Unauthenticated calls to the Twitter API are limited to a maximum of 2 requests per minute. This meant two things:

There would always be about a 30 second delay between a new tweet arriving and the user getting notified about it

Multiple account support would make this delay much worse as the two requests per minute would have to be shared among how ever many accounts the user had added

I decided this was less than ideal and began researching the Twitter streaming API – with the streaming API you open a long running connection to Twitter and they push new tweets to you as soon as they arrive. It was perfect for a notification app, but it came with a major downside – I would have to implement Twitter OAuth authentication in the app.

I had planned to develop the app in a few weeks, but the scope of the app was now rapidly expanding. Instead of my orignal, simple app idea – I now wanted:

Twitter Streaming API support

A feed display

Retina display support

More features so the app could hold its own against Mountain Lion Twitter notifications

The Tweetifier codebase rapidly grew. Although there were a number of useful libraries I was able to use to help my app communicate with Twitter (OAuth Consumer & SBJson), I still ended up writing several thousand lines of code myself to get streaming working. I spent many weeks testing and fine tuning to get the app working reliably with the Twitter API.

I ran into many strange issues, sometimes a tweet would not be delivered at all via streaming in which case my app would have to fallback to the REST API and fill in any tweets missed. Other times, the tweet would show up via streaming but then wouldn’t show up in the REST API. It took a long time to work through these issues. There are also very strict policies that a Twitter client must follow that cover things like, how often to retry upon being disconnected, how to handle rate limits, response codes, API keys and many other things.

I had no idea that making my app talk with Twitter would require so much work, and things were about to get worse.

Twitter change the rules

In August, Twitter announced new rules for using their API. The new rules discouraged the building of Twitter clients by limiting the number of users an app could have and also added new display requirements for apps. While I felt that Tweetifier could fit within these requirements for now, it made me anxious to be developing an app for an API that might go away soon.

The new Twitter API rules combined with the Twitter notifications built into Mountain Lion were starting to make my great idea start to look like not such a great idea after all. Again I had to make a decision as to whether I should continue with the app. I wasn’t feeling great about the project at this point and it’s hard to make yourself work on something that doesn’t seem to be working out. One of my friends politely suggested I abandon the project. Things looked grim.

Glimmers of hope

By late August I had the app more or less working – it just needed Retina display support, the ability to reply to tweets and a lot of bugs to be fixed. I was already finding it highly useful for myself. I tried to focus on the upsides – The Tweetifier codebase was clean and tidy, the visual design of the app was extremely good and I’d learnt a ton about OAuth and Cocoa while building it. I’d also been testing out App.net, a Twitter alternative with a far more developer friendly ecosystem that launched around the same time Twitter announced their new rules. If things really turned sour with Twitter I figured I could perhaps turn Tweetifier into an App.net client later down the track. Adapting Tweetifier to work with App.net should be fairly straightforward.

I also felt that I couldn’t possibly throw out all the gorgeous design work that Taher had done (example below). I pushed on with the app.

By late October I had all the main features of the app working. Twitter streaming was working well, you could easily reply to mentions and I had integrated over 80 images required for the Retina and non-Retina UI into the app.

In the meantime, I’d had a an idea for another feature that I thought tied quite well into the app. Since the app was sort of a selfish Twitter client (in that it only showed mentions and notifications that are about you) without showing you the main feed, I thought it would be nice if it could also tell you how many followers you were losing/gaining. I called this new feature Widgets. It gives you movable Widgets that sit on your desktop and show info about each of your Twitter accounts.

The numbers in brackets give the change in followers/following over the past 24 hours. So I can see my @johnwinter account lost 6 followers while my @aptonic account gained 17 in the last 24 hours. I spent a few weeks developing Widgets, writing a preference pane to control them and then ironing out the bugs.

Launch time

After releasing a beta to a few hundred users on Twitter to fix any major bugs I missed, the app was finally ready for submission to the Mac App Store. I sent it to Apple for review on the 23rd of November and waited anxiously. If they rejected it, it likely wouldn’t make it into the store until long after the iTunes Christmas closedown from December 21 to December 28 during which Apple don’t review apps. While I waited impatiently, I worked on the Tweetifier website and got it ready for the launch.

Finally, 14 days later on December 6th Apple approved the app! I was thrilled. It had been a long and trying journey but I had learnt plenty and managed to make an app that I was proud of.

It therefore gives me great pleasure to announce that Tweetifier is available today on the Mac App Store. Take a look at the app website I did and check out the video and screenshots on the app store. Or better still, go and buy the app from the link below – it’s only $2

I’d like to mention that getting the app in the store is really only the beginning, as I alluded to in this post there are many more features I’d like to add such as App.net support, the ability to run a script when a tweet arrives, a keyboard shortcut to open Twitter and a few other ideas I have. I’m hoping to release some great updates to the app in the coming months.

Finally, I’d like to say a huge thank you to Taher who did an outstanding job with the design of the app and gave me much help and encouragement along the way. I feel like this app is the first of my apps that has really been really well designed from the ground up and that’s largely thanks to the work of Taher.

If you have thoughts or questions on the app or on this blog post I’d love to hear, leave me a comment either here or on Hacker News.

Designing status item icons is a pain. It’s really tricky to get the sizing, color, alignment and edges just right in such a small area. It’s also hard to get a feel for how the status item will look once it’s actually up in the menu bar.

In the past, testing a new status item image involved a tedious process of copying a new image into the app bundle or Xcode project and then rebuilding/relaunching the app to see the change. When you’re tweaking the subtle details of the icon it’s frustrating not to immediately see your changes reflected.

I’ve put together a little Cocoa app to help ease the pain somewhat. You simply drag an image onto it and it displays it in the menu item. The app then monitors the file using the file change notification mechanism and when it detects a change it automatically updates the displayed menu item to show the update. That means you can do your editing in an image editor and when you do Cmd+S the changes are instantly reflected in the menu item.

You can download the compiled app here. The source code is released under MIT license and is available on GitHub. Feel free to fork, improve and send me a pull request.

On my todo list is making the app work for testing dock icons as well so there’s something you could add if you’re looking for a quick project.

Update: Since I wrote this post, I’ve read many stories similar to mine of troubles with CloudFlare. They seem to be going for the bottom end of the market, and their offering leaves a lot to be desired if you need a serious CDN that doesn’t cause weird latency, annoying landing pages and other issues. I wouldn’t bother with this company again.

From the comments left on this post below I get the impression that nothing much has changed since I wrote this.

A commenter on Hacker News had this to say about my post:

I’m not sure why you’re surprised.
CloudFlare is amateur at best, compared to existing DSA/CDN offerings from Akamai, Cotendo, EdgeCast etc.
But those cost a lot of money (at least 50-100x the cost of CloudFlare) if you’re small/medium sized. You get what you pay for with $20/month.

I can only agree with his point. You get what you pay for and for $20 a month you’re not going to get a lot.

CloudFlare is a website performance and security product that launched publicly at TechCrunch Disrupt in September 2010. It’s a reverse proxy, firewall, and global content delivery network that requires very minimal setup. Their main product is free, but they also offer a pro version that provides a few extra optimisations and features available for $20 a month.

To use CloudFlare, you simply change the DNS name servers for your domain to point to CloudFlare and then they configure your A record to point at their servers. All traffic to your website is then routed through CloudFlare. They act as a content delivery network for your images, Javascript and CSS files which means they serve these assets from a server closer to you and reduce the load on your server. It’s worth noting that they do not cache the actual html of your website – these requests are still forwarded onto your web server.

As well as acting as a CDN, CloudFlare offers a number of other features as well. They will minify your JS/HTML/CSS for you, automatically obfuscate email addresses and can also preload static resources using Javascript in the background. CloudFlare will also in theory improve the security of your site by preventing attacks such as SQL injection, XSS Javascript injections and stop known bad IP addresses from accessing your site.

Other than email address obfuscation, I was not interested in the security features CloudFlare offered, one of the reasons being that if CloudFlare detects what it thinks is a suspicious user it will prevent them from accessing your site, display a CloudFlare branded page and make them enter a captcha to continue. I hate the idea of this – a false positive that triggers this will make your site look horribly broken and I also don’t want the user to ever see CloudFlare branding or anything on my site that I didn’t design myself.

I think this is one of the things CloudFlare gets very wrong about their whole offering, they should be aiming to be completely transparent no matter what happens. I don’t ever want to see their logo on my site or hear about how many ‘threats’ they prevented. That stuff needs to happen right out of my customers sight.

If your web server goes down and they are able to serve up a static version, at the top of the page they inject a ‘This page is offline, but here’s our cached version’ thing, along with the CloudFlare logo. I might be less annoyed about this if I hadn’t already shelled out $20/mo for the pro version of CloudFlare but they are essentially using the fact that my server is down as an opportunity to do some free marketing for themselves, despite the fact that I already pay them money. I don’t like this either.

Anyway, I switched off all of the security features with the goal of using CloudFlare purely to improve the performance of my site. Some of the features CloudFlare offer are still in beta. To begin with I left all beta features disabled except for JS/HTML/CSS minification.

The site I was trying to improve the performance of – http://frenzyapp.com is pretty simple and made up of just a few images and static html pages.
Things seemed to work quite well for a while, but sometimes I noticed my site was taking longer than usual (>3seconds) to load now that CloudFlare was in the picture.

I started doing some tests using the site performance testing tool at http://www.webpagetest.org which allowed me to test the page load times from multiple locations around the globe. WebPagetest showed that a single file – jquery.fancybox-1.3.4.css was taking over 3 seconds to load from certain locations and also showed some other issues with requests being cancelled. This was causing the whole site not to be fully loaded for over 6 seconds. Not good at all.

I ran a lot more tests and found I couldn’t get the problem to occur consistently from all locations but it would always happen when loaded from New York. I opened a support ticket with CloudFlare describing the problem and attached screenshots of a number of tests. They responded quickly and told me to try disabling the JS/HTML/CSS minification feature (which was after all, in beta) and see if that improved things. I did this and re-ran the tests 10 times from New York, again using WebPagetest to see if the problem persisted, unfortunately it did. Loading this file was taking over 3 seconds to load bringing the overall page load time to around 6 seconds. Still no good.

I tried disabling some of the other CloudFlare features such as the website preloader and ran more tests. Still the problem continued. I updated the support ticket with my findings and then waited patiently for 3 days. This time CloudFlare did not respond. I posted to their support system again to ask if a resolution was coming and tweeted them:

Almost immediately, I got a tweet back from Matthew Prince, the CEO and co-founder of CloudFlare. He suggested that I try completely deactivating CloudFlare and re-testing. We had a rather lengthy, friendly exchange which ended with this tweet from him:

This is encouraging. I am hopeful that the problem will now be resolved or that I’ll at least get an update soon now that I have a promise from the CEO.

I also took his advice and tried fully deactivating CloudFlare from the control panel, this makes the DNS A record to point directly at my server, taking CloudFlare out of the loop. I then re-ran WebPagetest 10 times from New York and found the problem had disappeared. The page is now fully loading in an average of 3 seconds or less compared with the 6 seconds taken with CloudFlare enabled. This provides further evidence that CloudFlare is causing the issue and not my server configuration. I update the support ticket with my findings and wait patiently for another 4 days.

I don’t hear a thing from CloudFlare, no more tweets, no update to the support ticket, nothing. I guess they must have changed their mind about resolving my issue ‘in a few hours’

I decide to re-test everything anyway, and also run tests from other locations to get an overall indication of the performance of my site with CloudFlare enabled versus CloudFlare disabled.

My findings are displayed below:

The times given are seconds to fully loaded. In New York – the problem location where the CSS file is taking greater than 3 seconds the total load time is, on average, 2.7 seconds greater with CloudFlare activated.

The site actually loads faster when direct from my server in every tested location except for two.

On average, across all tested locations, the site is loading 0.8 seconds faster with CloudFlare deactivated. This certainly isn’t what I would have expected from a product that is supposed to ‘supercharge’ your website.

One factor to consider is that these tests were done while my site was under almost zero load. If my server became overwhelmed then it would slow right down in which case CloudFlare may actually be faster. It also remains to be seen whether other sites using CloudFlare exhibit similar load times or if my site is particularly troublesome for some reason. Much more data would have to be collected to conclusively prove anything. I have uploaded a zip archive that contains screenshots of all the WebPagetest results with more information on each test in case you are interested or want to see the original source for those numbers.

Personally, I’ve decided to move on from CloudFlare. Despite what seems to be a promising service, right now they are not providing me with a faster website. They also don’t seem to be fixing my problems or keeping me informed. It’s a shame because I really think they are onto something, there’s so much that goes into keeping a website speedy and available these days. If I can change two name servers and have everything taken care of for me, it leaves me more time to put into building great products.

I do think CloudFlare will iron out these issues eventually. At the moment the company still seems to be in early/beta stages. They may be worth another look at some point in the future. They also need to do some work on improving their customer service and make sure they follow up with customers who have problems.

I’d like to to talk a little about the motivation behind Frenzy and show off a few tricks that haven’t been discussed elsewhere.

When Dropbox came out, it made sharing files and folders with your friends effortless. You can just put stuff in a folder and then you know that at some point the same stuff will turn up in your friends folder. It’s also private, so no one but the people you choose are able to see the contents of that folder.

The problem is, Dropbox lacks some of the more social aspects to sharing with each other. In a lot of cases, sending someone a file also needs an explanation to go along with it, and it would also be nice if the recipient could reply directly about what was shared. Of course you could do this bit by email, but it would be much nicer to be able to write a message to go right along with the thing you shared.

Frenzy lets you do just this. You simply drag a file or folder onto the menu item and Frenzy pops up and asks you which groups of people you want to share with.

Lets see a real world example of this:

Say I have some design sketches I want to get feedback on. First I drag the folder onto the Frenzy menu item:

The main Frenzy window pops up and asks which groups I want to share it with. Groups are simply the Dropbox shared folders that I have setup. You can invite new people to a shared folder or remove someone via the Dropbox web interface.

You can have multiple people in each group, or just one person as in my ‘Jason’ group. In this case, I select the Design group. I press enter or click share and the folder is copied to the Dropbox folder for syncing and my item is added to the feed:

My friends will now see the item I shared in their feeds.

When I receive replies, the number of new messages will be shown in red on the Frenzy menu item:

But Frenzy isn’t just for sharing and discussing files and folders. You can also share links with Frenzy.

To share a link, goto a site in your favorite browser and then use the Frenzy keyboard shortcut. The default is Control+Option+S. You can customize this shortcut in the Frenzy preferences.

You can also use the keyboard shortcut to reply to links already shared in the timeline.

For example, if Karen shares a link with me, I can click on the link and it opens in my browser. Now I can use the keyboard shortcut and Frenzy detects this item has already been shared so it will treat this as a reply:

Alternatively, I can click in the area indicated above to re-share this link with a different group. If I want to re-share this link with the family group for example:

Frenzy is available for download now from http://frenzyapp.com as a full featured 15 day trial. For a limited time it is $10USD to buy. Watch the screencast and give it a try.

I warn you though, once you start down the road of doing horrible hacks like this there is no turning back and you will need 100s more hacks to maintain the initial hack. It took me months of hard work to make the dock tracking system work well and it still has to use a separate process and constantly takes up CPU to poll the API as there is no notification for when the dock tile size changes.

I STRONGLY urge you to find another way to do whatever you are trying to do that does not require a window over the dock icon.

It got me thinking how clever I thought I was when got the dock tracking system Dropzone uses working. It’s a horribly complicated system involving all kinds of hacks and workarounds, all to give me dragging notifications on the dock icon so I could show the grid of actions. This is something Apple never intended apps in the dock to be able to do.

One example of the kinds of extra hacks it leads to is that if you hit F11 it shifts the hidden window off screen, and dock dragging no longer works. This is annoying for a user if they want to expose the desktop and then drag something onto Dropzone. I can get around this by recreating the window when a show desktop is detected, but then I need a way to detect show desktop activation and there is no API for this either…

If you’re thinking of making an app that does hacks like Dropzone, change your mind and don’t. It leads to inflexible and unmaintainable code that is subject to break at any moment.

Compare Dropzone with more standard, single windowed apps like Things and NetNewsWire. I don’t think they have an easy job either, but at least they aren’t trying to interface with integral parts of OS X like the dock where there is no API and things are liable to break next OS update. It’s fun and novel to break all the rules, but in the end, you won’t feel so great about your app. Trust me. Been there.

Second thing:

People have been asking me if I’ve given up on Dropzone. No I haven’t give up and I’m still selling a few licenses a day which I’m really thrilled about. Thank you all.

Part of the reason I haven’t updated Dropzone in a while is that it’s already doing everything I need.

The other reason is that I’m hard at work developing a new app! This will be a slightly more conventional app than Dropzone – It’s a private social network for sharing links, messages and files using Dropbox as the backend. It’s in still in alpha at the moment, but it’s coming along well and I’m hoping to do a big open beta in month or so to get feedback from a wider audience.

Have you tried the Google Chrome for Mac developer release? It’s missing just about every major feature you might expect in a browser (bookmarking, printing and Flash to name a few) but is still plenty awesome, and mostly on account of its incredible speed. It feels even snappier than Safari 4 which is also pretty quick.

As well as being fast at rendering pages, it also appears to start very quickly. When you first launch it, you’ll see what I mean. Many people have commented that the dock icon doesn’t even bounce once during launch. Here’s Kevin Rose and Leo Laporte discussing this unusual behavior on last weeks TWiT episode:

This behavior of zero dock icon bounces intrigued me as well, so I did some digging, and Kevin’s right, they did a hack. If we look in Chromes Info.plist we find the following:

The key I’ve highlighted tells OS X that Chrome is an agent application, that is, a background application that should not appear in the Dock or Force Quit window. That seems strange, as we know Chrome does appear in both.

Some more digging led me to this patch which tells us exactly what’s going on here.

So. Chrome is initially launched as a background app and then transformed into a foreground app using the Carbon API call TransformProcessType. This means that when Chrome starts, the dock icon doesn’t bounce because OS X doesn’t think it should have a dock icon. When TransformProcessType is called to give it back its dock icon Chrome is already fully loaded, the net result being that we never see the dock icon bounce.

What’s interesting is that the Chrome developers are actually doing this to workaround a completely unrelated issue involving the WebKit UI and it has even been filed as a bug. And to think we all thought they had done it deliberately to give the impression of a faster launch. Shame on us all.

Anyhow, I was interested in adding this behavior to Dropzone, as the Dropzone dock icon should ideally not bounce either as this is more in line with the behavior of the built in dock grids that Dropzone tries to mimic, also, the dock icon bounces would occasionally interfere with the positioning and display of the grid directly above it. Therefore, I have added this same code to Dropzone and made another improvement – if you click on the Dropzone dock icon when it’s closed, the grid is displayed immediately after launch. There is also another neat feature in Dropzone that you may not be aware of – if you drag something onto the dock icon when Dropzone is closed, it automatically launches and opens the grid. I have done a quick screencast that demos both of these behaviors:

As you can see, Dropzone launches so quickly you barely even notice that it was closed to begin with. Without this code, the Dropzone dock icon would always bounce once even though before it finished its first bounce, Dropzone was already launched.

So, while I’m certainly not recommending people start adding this code to their apps to provide the illusion of a faster launch, in the special case of Dropzone this is a nice touch.

It will also be interesting to see whether Google ends up sticking with this behavior in future releases of Chrome. I think since Chrome launches so quickly anyway they are best just to leave it as is. Also, I bet people will complain it now seems to start ‘slower’ if they make it start bouncing again. Perception is everything.

Go download it if you haven’t already, and if you like it, support the project by buying a copy – As promised, it’s only $10.

I’m really very proud of it, and have come to depend on it in my day to day work. Although it can take a while before it feels a natural part of your OS X workflow, once you ‘get it’ it becomes an indispensable utility, a lot like Quicksilver or TextExpander.

I see this as just a beginning, and I hope you’ll help me build on it using the Dropzone scripting API. Some pretty neat stuff has already been built. I also need your feedback on how to evolve the API to make it even more useful.

There are many more features I am working on for future releases, such as SFTP, WebDAV and MobileMe support. So if you need these, rest assured they are coming soon.

Meanwhile, I hope you enjoy using the app and let me know what you think of it!