So, what’s it about? Some of you (probably the majority of Apple customers) might have heard about “Things”, an “Getting Things Done” (GTD) application suite contained of an Mac App, an iPhone App and an iPad App that let’s you organize tasks and projects for yourself. Several years ago, the developing company CulturedCode won the Apple Design Award with their pretty neat desktop application. Thanks to my buddy Andreas, who bought me my Things for Mac license in 2009 as a birthday present, I started using the software from it’s quite early 1.x phase. I really loved the application, especially because of its clean and simple design and its ease of use. After quite a while my needs started to change, though. I wanted to have both of my Macs in sync, for example. I played around with Dropbox and found a way to do that, although it didn’t allow me to have Things on both machines open at the same time. Soon, more and more people started writing about how they’d love synchronization features for things, especially OTA (“Over the Air”) sync. And CulturedCode reacted. In mid 2009 they already published a roadmap that was “not a roadmap” and wrote about them having worked since the beginning of that year on a “really sweet” OTA solution that should be better than the competitors’ products.

This means, they actually announced their work on an OTA feature in mid 2009 with the additional info, that they’ve been working already for around 8 months on it. The people who read that and don’t really know about usual timelines for such big IT projects might expect a solution to finally be there in a couple of weeks or maybe months, especially after reading a sentence like this:

Okay, those fanboys and Mac addicts who can’t wait for such kind of delicious features now got pretty aroused and everyone else (especially the people who haven’t spent around 40 bucks on a Things license plus another eight bucks on Things for iPhone so far) really started considering Things as serious solution for their task-planning needs.

Then, till April 2010, CulturedCode didn’t blog about anything related to sync at all. From August 2009 till April 2010, that’s nearly one year without letting users actually know what happened to OTA sync. Meanwhile, many people spent their money on Things, mostly because they trusted in CulturedCode and it’s blog post announcing their work on OTA sync in 2009. And yeah, they haven’t heard about the sync feature for quite a while, but still they saw that progress was made in other areas, so there was not much of a reason to think of CulturedCode being dead or something. Especially, after reading their follow ups about the team growth, people thought, “Eh, it can’t take that long anymore!”.

In the meantime, I became responsible for handling the Mac infrastructure at my employer. For me, it was pretty clear what solution I would be deploying on people’s MacBooks when they’ve been asking me for some GTD application. I thought of Things as a solid and reliable application and the fact that CulturedCode was a Stuttgart-based company made it even more attractive for me to order a volume-license for Things.

People were getting hungry about the OTA sync feature and I guess CulturedCode really saw a need to act, so in December 2010 (8 months later) they released it. Oh, no, not the OTA sync feature, I’m sorry. They released the first chapter of a set of blog posts regarding the OTA sync feature: State of Sync, Part 1. Instead of providing a first beta, what would be appropriate after theoretically 2 years of work, they provided information about general problems on OTA/Cloud synchronization and some nicely drawn wallpapers for your Mac, your iPhone and even your iPad. Hurray to the design department. But people didn’t yell at CulturedCode, not even after 2 years of waiting. Instead, comments like those were written:

This is what I’d call loyal customers.

However, in January, the second post about the “State of Sync” was published. It looked like there was at least some thinking and progressing on the OTA sync feature. Even if it’s not really what customers expected after over two years of development. In March, CulturedCode released part 3 of their blog odyssey, introducing a sign-up for for Cloud sync beta. Hurray, people could sign up and had to wait for the Beta to start. So they did and nearly two months later the first couple of users got approved as beta users and received the testing instructions. Unfortunately, Cloud sync was only available for Things for Mac at that time. It took the CulturedCode people nearly one year to introduce Cloud sync (beta) on iOS! By that time, other products like Wunderlist, that already provided OTA sync attracted more and more former Things users. For new users it was super-attractive too, since they didn’t charge 40 bucks for their desktop client. Actually they didn’t charge for anything. It has just been there. Free to use.

Existing CulturedCode customers became pretty sad or angry or let’s just call it pissed. Pissed about the fact that they still don’t have a fully working cloud sync solution. Pissed about the fact that they spent 40 bucks on a Mac software, maybe 8 bucks on an iPhone App and maybe even 15 bucks on an iPad App. For what? Yeah sure, you’re not buying software for what it might become, you’re buying software for what it is, I know. But let’s be honest, even Andy Potion, who’s pretty much a one-man-show, did a quicker job with The Hit List, in comparison to CulturedCode’s timeline. And not to mention that not too long ago, the creators of Wunderlist – 6Wunderkinder – just launched their new, web based Wunderkit service, that introduces collaboration. And by “collaboration”, I don’t mean the “I’m creating sidebar entries ouf of my Address Book information and drag Tasks onto them to remind myself who’s in charge, without any functionality of actually really letting the people know that they’re in charge”-CulturedCode-collaboration. I mean real collaboration, where you get notified about tasks that have been assigned to you. And it’s web based, too. And there are Apps for it. And it’s even free of charge. And all that it probably half the time CulturedCode had. So, let’s be serious: You do not buy software, for what it might become, but in consideration of such heavy-armed competition, you’d expect the developer to hurry the flock up!

Suddenly, people began to realize all that and the five-star ratings on the App Store became one-star ratings:

People got fed up and CulturedCode became quiet. Not much response on people’s angry tweets to calm them down, no more information about the actual progress, nothing. One possible response could have been to slash the prices on their software for a limited time, to allow existing customers to extend their suite. Another would have been spreading coupon codes for Things for iPhone or Things for iPad. They could have teamed up with several reviewing sites to get media attention on their existing products and their existing features. I mean, after all it still is a beautiful product. It might be over-priced, it might be slow in development and it might not support features that should be mandatory for a 2012 GTD application suite, but still it’s a good piece of software and the jobs it can do, it does extremely well. Unfortunately, CulturedCode has let the users put the focus too much on features they were clearly unable to deliver in an realistic amount of time. There was progress on Things, even if it wasn’t that much, but there was and still is – unfortunately this progress drowned in the OTA-sync-well created by the users. On one hand, CulturedCode had to respond somehow, on the other, they probably wanted to get themselves a bit more time, just a bit more time. In my opinion, their response was influenced too much by their user’s pressure and I got the feeling, that they did not respond because they felt the urge to provide information about what’s going on. The blog posts were nicely written and had some very cool drawings, still it’s not what the users actually wanted. They didn’t want to read philosophical posts about Cloud synchronization or comparisons between MobileMe and Dropbox. And I believe, that, if CulturedCode would have provided more information about OTA (and their other internal project / development progress) without users permanently requesting it via Twitter, E-Mail or even App Store reviews, the whole situation would look way more relaxed these days. I think in general it’s pretty simple to say: Either you try to make your internal development process more transparent to your customers, so they can get a feeling for what to expect and when, or you do it the Apple-way and shut the f*ck up until it’s ready. You don’t get people excited about a feature and let them wait three years for a first beta.

However, in February of this year CulturedCode started their public beta of Things Cloud, so now everyone can at least get a taste for what is probably going to be released someday. Still, people are mad, because rudimentary features like task-notifications don’t work so far – IT guys understand, that it’s pretty hard to notify the user about content you might not even have available on the specific device, regular people instead just get the impression that Things now stars getting OTA sync, but loses existing features for that, what’s a bit unsatisfying.

I had a testdrive account for their private beta and used (and sometimes still use) it – and I liked what I saw, to be honest. Still, I moved over to another solution, just because from my current point of view it integrates better with what’s important to me and costs less, due to the fact that the desktop client is built into OS X (Calendar) and the iPhone/iPad client is one universal binary, priced at something around three bucks. The app developer answers pretty quickly to questions, even via Twitter and customers are being involved right into the development progress, by asking about their preferences regarding certain, to-be-implemented features via Facebook and other modern social media. I mean, come on, it’s not that hard: If you follow some simple rules and strategies, customers will stay loyal at any time, no matter how delayed a long-awaited feature might be. I think, that one of CulturedCode’s biggest problems was and has always been the direct communication. I personally see them like people have probably seen Microsoft several years a ago: A big and massive brick where customers can’t really reach someone that has an open ear for their thoughts and their wishes. A machinery that produces software the way it thinks its best for the customer, without involving him in that progress. But we’re not talking about huge corporations with a super-huge user-base here!

Well, anyway, at last but not least, I would like to lose some words about direct communication to the customer. I’m not the person that posts Steve Jobs’ emails on my blog – not that I would have ever gotten any – and therefor I’m not going to post the details about my email conversation with Jürgen Schweizer, one of the CEOs of CulturedCode, here. Instead, I just want to talk about the feeling I had during that conversation. It started with a tweet from a guy I actually don’t know, complaining about – you might guess it – Things’ missing OTA feature. He had a short conversation with CulturedCode on Twitter about that and I got into it to confirm the points he made, since I found them totally true and understandable. I ended up writing a mail to Jürgen Schweizer, to answer some direct messages he sent me via Twitter. In my opinion, the mail was polite and reflecting the way I (and many other customers) felt at that time. No bitching, no screaming, just some honest feedback from one of their users. What I got back instead was a mail, that truly made me feel a bit stupid and uncomfortable. I was a bit disappointed, about the way a CEO writes to one of his paying customers and intentionally makes him feel, like he has been writing something he should feel bad about. This is not the feeling you’d expect from a representing person of a company, regardless of how rude the customer might have been. You don’t indirectly tell the customer, that he (and/or other users) are disrespectful. Never. It’s a paying customer who actually supports your product through buying it – and even if this customer should get sad, angry or really mad and no matter how upset or uncomfortable you are with the things he’s been writing you, it’s in your responsibility to always keep the conversation at a level where you can point out your view without indirectly making the customer feel insulted or whatever. It’s useless to try to argue, who’s wrong or right with a customer – in the end, the only thing that matters is, that people get the feeling, that this company cares about its customers and really wants their products to make them happy. It’s always bad, when a company’s way of leading conversation makes their customers get a negative feeling.
For example: Some while ago, I’ve downloaded a movie via iTunes on my MacBook. Later, I wanted to watch it on my iMac, so I transferred it to to my iPhone (because that’s the only way I knew) and from there I tried to transfer it to my iMac. Unfortunately, it didn’t work out and I lost the movie, literally. The file was gone somehow and I could not re-download it at that time. I called the Apple Support and told them, what I tried to do and that I found it pretty meh anyway, that there was no other possibility to get a movie from my MacBook to my iMac. Now, the Apple Support could have told me, that I was trying to do something that was not intended by Apple to be done and made me feel really stupid by that and leave me alone with my transfer problem. Or they could have provided me a way, to download the movie again on my iMac, so I could watch it there. Or they could have just hung up. But instead, the support guy on the other side added a credit for watching two movies of any kind from the iTunes Store for free, just because of the inconvenience caused. And see there, the customer was happy. I bitched about the fact that there was no possibility to simply transfer the movie from one Mac to another, but in the end, Apple just made up for that by allowing me to download the movie again plus watch another movie – for free! This is, what I call customer relationship. The customer is not an enemy threatening you with feature-requests, he’s the nice guy from vis-à-vis who loves your product that much, that he agreed on giving you a part – even if it’s just a small part – of the money he has been working for so hard, just to give you the opportunity to continue developing such a great product. So please, companies of this world, treat him like this.

Just my two cents. Thank you for reading.

So, what’s new in 0.3? Well, just about everything. I’ve renamed the bundle (at least its metadata), since webOS is not just limited to the Pre and I’ve modified the shortcuts of existing features to fit TextMate’s styling guidelines a bit better. I’ve also created some snippets which can be used for faster code-writing now and in addition to that, I’ve implemented a very own language for the bundle, which can’t be found in the document type picker named as “Mojo”. “Yeah baby!”, as Austin would say now. Actually, yet it’s just a copy & paste of the JavaScript-language implementation in TextMate, but I’m planning to extend it to fit the Mojo-framework even better.

The TextMate bundle is now also available on GitHub, for everyone who can’t wait for me packaging the releases and releasing them here. If you have any ideas for improvement, feel free to contact me by mail or just leave some lines here on my blog.

Enjoy!

Download: Palm_webOS-Bundle-0.3

Download: Palm_webOS-Bundle-0.3

Palm Pre Development Bundle 0.2

Yes, after not even four hours I’ve already finished building the 0.2-release of my Palm Pre Development Bundle for TextMate. In case you’re wondering what weird stuff I’m talking about, please read my previous post first.

However, this second release includes a lot more features than it had before, plus I’ve made use of the CocoaDialog now. Let me describe the new features from the top to the bottom of the screenshot on the left site.

First of all, there’s “Generate New Project”. This lets you execute a palm-generate with all important attributes and opens the created project afterwards using the “mate” terminal-command, which needs to be available for this to work. All you have to do then is simply to save the TextMate project right into your generated project-directory.

Next, we still have “Generate New Scene”. I’ve enhanced the feature now, so that you’ll get a cocoa dialog asking for the scene’s name. Beware: The generation usually works as it should, the only problem is the TextMate project-drawer, which doesn’t seem to refresh by itself. A workaround: Cmd+H to hide TextMate and then click on its Dock-icon to make it appear again. Then all newly generated files should be visible in its drawer.

The next three features work just as before, no enhancements at all. On the fourth, the “Launch Project in Debugging-Mode” feature, I’ve implemented a palm-launch with debugging options, that can be run on an existing, packaged and installed project.

Next, there are ways to close and remove installed Projects. “Close running project” of course only works, when the App is actually running and “Remove installed Project” removes the App from the device. As device for all those commands the first device found by the Palm toolset will be taken – so if you would like to use the Emulator, better disconnect your real device and vice versa.

I’ve also built-in two features that let you simulate test calls and SMS on your Emulator, if you changed from password authentication to SSH public key authentication. You can do this either manually or try to use the feature at the menu’s bottom named “Auto-install SSH-Pubkey on Emulator”. Depending on your SSH-key-setup it works out or… not.

The other seven features allow you to simulate GPS drives on the Emulator – again only if you’ve set-up SSH-Pubkey authentication.

I hope you enjoy this release of the Palm Pre Development Bundle for TextMate!

Download: Palm-Pre-Bundle-0.2

UPDATE: There’s a newer version available! Get it here. Or use GitHub.

The scene generation works like this: You implement your this.controller.pushScene(“Main”);-statement, select the scene’s name (Main, without the quotes!) and select the scene-generation command from the bundle’s menu. The command will immediately generate you a new scene named just the way you chose to name it.

The other three commands can be ran by pressing the keys Fn+Ctrl+F5/F6/F7. Attention: The bundle only works with TextMate Projects! Generate your Palm Pre project like you always do, by using the following command:

palm-generate -p “{ title:’ProjectName’, id:com.my.ProjectName, version:’1.0.0′ }” ProjectName

Then, create a new TextMate Project and drag&drop the folder palm-generate created for you (“ProjectName”) into the Project’s drawer. Save the project within your Project-directory (“ProjectName”) and then run the commands.

This is the very first version of this bundle and I’ll keep constantly improving it with other features that help me and hopefully others on the development of Palm Pre Web-Apps.

Enjoy!

Download: PalmPre-Bundle-0.1

UPDATE: There’s a newer version available now! Get it here.

WebKit Development Tools

In the past few weeks, I was involved into heavy JavaScript web-development at work and had to work with tools that allow me to debug dynamic web-content in an effortless way. Most people would now say “Use Firefox with FireBug addition!” and I would even agree with them, if I would be using some Windows operating-system instead of my lovely Mac. Everyone who has ever used Firefox on a Linux or a Mac OS X will know, that it’s a pain in the arse. Due to the way Mozilla-developers have taken to make Firefox available on multiple platforms, it lacks of any speed and integration within most implementations.

So what to do on a Mac, where Firefox trying to render a full-blown AJAX-site needs more space and CPU-power than a VMware or Parallels instance of Windows XP, running the IE? Most people don’t really know, that the Mac’s integrated browser already provides a very good toolset for web-development which just got even better with the version 4 (yet, still Beta) of Safari.

The toolset is hidden, on a regular OS X, but it can be unlocked pretty easy. The only thing you gotta do, is quit your Safari, open a Terminal and enter this command:

defaults write com.apple.Safari WebKitDeveloperExtras -bool true


It should quit without any output. After that, you can quit the Terminal and re-start Safari. You might not see any difference to Safari’s appearance before spawning the command, but now just try to do a right-click / command-click within a web-site. You will see, that your popup-menu has just been extended by one new item at its bottom, called “Inspect Element“. By clicking this entrie, Safari either opens a new window or separates your current one with an additional view, depending on what Safari version you’re using. This command works on 3 and 4.

Within that window, you will see a lot of useful information about the page. You can see time and size measurements, script-warnings and -errors and many many more. This extensions to Safari’s WebKit provides you nearly everything you might know from FireFox Add-Ons like FireBug. And besides of that, it allows you to profile your page in a sleek and easy, graphical way.

I’m now working quite some time with those tools, exactly because of all the problems I had with Firefox on my Mac, and I must say that I love them. I love the integration and the way it allows me to debug my sites. The only thing I liked more in FireBug was the precision of its GET/POST/PUT/…-output, but most of the time I don’t need that anyway.

Enjoy!