Realigning the Azimuth

Twitter’s recent acquisition of leading iPhone client Tweetie (along with hiring its developer for their mobile team) was certainly a minor surprise for those users who follow the behind the scenes events in the industry.

For those users who aren’t so involved with the behind the scenes machinations, the first they would have heard about it was upon installing Tweetie’s 2.1.2 update. Besides a small collection of bug fixes, the main focus was on a so-called surprise – which turned out to be a little heads-up to users notifying them of the impending rebranding of Tweetie as the Twitter for iPhone application.

As I see it, this is where things didn’t go as smooth – sometime after the release, I started to see a number of users on my timeline complain about not being able to deactivate it. At this point, I hadn’t given a thought to disabling it either (having worked out what to do to avoid activating it) until this started happening. A quick cursory glance through its Settings screen was enough to find the necessary option to disable it from appearing.

This is where I happened to get a little grumpy.

Not because of the Easter Egg, but rather for the fact that why didn’t any of the complaining users dive into the settings before complaining? Is this simply an artefact of settings for iPhone applications being stored in an external application (though, the number of new applications doing this is somewhat decreasing)? Or is this down to users not being interested in customising the application?

The other question which was floating around my head was what about the Easter Egg upon discovery? Unlike other Easter Eggs (for example the hidden games inside earlier versions of Microsoft Excel & Word), this Easter Egg was really only meant to be seen the once. Thus, I would have believed that upon discovery, the most logical thing to do would be to automatically disable this.

The fact that it’s disabled via a simple UI switch would suggest that it’s the best option, but sadly this wasn’t the case.

What lessons can a developer take away from this? First & foremost would be the value in not pissing off your end users. The fact that the Easter Egg didn’t switch off upon being discovered was a serious lack of foresight, only compounded by the lack of discovery being performed by the user.

The second thing to take away would be considering a better way to managed any such notifications. Had I been implementing such a feature, I probably would have gone & presented it as a simple banner when the application had been started up for the first time. That way, I would have been able to have it appear on screen for a short period of time, before disappearing.

Regardless of how it was put in, I personally liked the feature & felt that it was a great way to notify users of the impending rebranding. I guess I just believe that in this case, it could have been executed in a way which didn’t annoy the end user.

Whilst I’m continuing to hunt contract work down – I’ve also been looking into some more of my own projects to hack on (to both kill time, and to potentially sell). One of those is a basic game prototype based on some ideas I’ve had lying around.

The basic idea is that you’re controlling a fighter (the blue block) and need to defend the giant spaceship (the white block) from the approaching enemies (the red blocks – yes there are multiple!).

I’m putting this out there mainly as a way to solicit some feedback from across the interwebs. I’m not the most original game designer out there, and I’m hoping by doing this, I can get some feedback on both whether this is viable (in particular for the iPhone, but even as a web game or something), and on where I could go with it – I have some of my own ideas, but I’m interested in what others have to say.

So, if you’re interested, download it – either for Windows or for Mac OS X.

The introduction of DLC with the most current console generation heralded an easier way for publishers to add additional content into their games. Whilst there have been some outstanding uses of this, in particular, the support given to Burnout Paradise by its developers, there were also a number of staggering misfires (the Oblivion Horse Armour pack stands as a classic example of this).

With the years of experience gained on the consoles, I would have expected a decent experience with releasing DLC for iPhone games (I’m unsure how many non-games apps are using DLC, but that’s because I’ve simply not examined that area in detail) since the release of OS 3.0 earlier this year. Even with the recent policy change to allow free applications to also have DLC, the way this has been treated by some publishers has been one of the earlier micro-transaction pain console gamers experienced.

I’ve always seen DLC as a means to provide additional content for a game to help maximise the life time of it in the marketplace, so seeing DLC available upon release of a title feels like a desperate cash grab. For me, this is only reinforced upon paying premium price for a what ends up being a tiny subset of a complete game.

To start seeing this trend in the App Store (although, these cases are in games from the same publisher), is one I find worrying. Is this a tactic being employed by publishers to attempt to reduce piracy (simply by ensuring that users who do pirate are unable to access all of the content)?

But even then, is this the right way of ensuring that users will purchase the additional content? If a user feels that they’ve not received a fair deal on the base game, then I wonder how likely they will be to purchase said content? I might be cynical, but I feel it isn’t that likely.

I guess there are two viable models – the first would be to mirror the model used for titles on Xbox Live Arcade. The complete package is downloaded for free, with only a small subset of the game playable. If a user enjoys the game, they can purchase the DLC which enables the full game for a reasonable price. Doing this can ensure that the so-called lite versions of games are no longer required in the App Store (which will help close down the flood of releases).

Another alternative would be to mirror the more traditional console game. Charge a fair price for the complete game, and offer smaller pieces as DLC. This would work more for traditional games, but would require the gamer to pay more up-front for a title, with smaller pieces of DLC.

As it stands, I feel that pricing games (and any associated content) is never going to be easy. Striking a balance between giving the gamer a fair amount of content for their dollar, and being able to provide a means of getting a return on the time & money you’ve put into your title is something which requires a lot of thought in my own opinion.

We’ve had the announcement that Flash CS5 will now natively cross-target the iPhone/iPod Touch. In terms of what it offers for the iPhone OS platform & its eco-system, I’m not entirely sure it’s a good thing.

The process they’ve used, in which the raw Actionscript is compiled down into native ARM code, at least appears to be sound on first glance. The fact that several applications have passed Apple’s approval process also helps validate this.

Whilst this does sound similar to the process employed by the MonoTouch project, the significant difference is that this will not allow Flash developers to take advantage of the iPhone’s rich frameworks (ie. UIKit), instead relying upon developers to design & implement their own UI widgets for serious applications.

Maybe I’m wrong for looking down on them for this, but one of the big advantages in developing for the iPhone (as well as desktop Mac OS X) is that you have a rich palette of UI controls available for use in your own applications. Without these, using Flash to develop serious applications is not going to be a productive endeavour. That of course, is ignoring the lack of UI consistency which native applications offer.

Even more worrying is the low-level technical implementation. Compared to doing development on a desktop platform, mobile development requires significant more skill in managing the limited memory & resources which are available. Looking at the breakdown of one of the available applications (via Jeff LaMarche’s blog), it appears that the final binaries are about 10mb in size, which happens to be about the maximum allowed size for downloading applications over the air, which is likely to impact on the reach your application has to the wider market.

They also appear to not be fully optimised – unlike a normal application, the application binary and all resources are combined into a single executable. On the original iPhone, or the iPhone 3G, this is likely to be a potential to hit the smaller memory limits those devices offer as a result.

At this stage, whilst my curiosity is peaked, I still don’t think it’s an entirely good path to go down. There appears to be a few interesting issues with the platform (which may be related to the early nature of it), but at the moment, I’m not entirely confident that it’s the best way to go, or the results will be worth it.

I can’t help but feel that it’s best to stick with the native Objective-C/Cocoa Touch stack for development, unless you’re specifically doing games development.

After a fortnight in the black box of review, I’d like to announce that my first self-published application, Eventbook has gone live on the iTunes App Store.

I won’t go into the details again (as you can always check the Eventbook site for the specifics), but for a project which came together in about a month, I’m really proud to see it available for download.

It feels weird that after developing software for so long (in a serious sense – a good 6 years since I finished my CS degree), that I’ve finally pushed a project out the door.

My time at various employers has been doing maintenance on existing applications, working on projects that never got released for various political reasons, and other cases like that.

Having decided to leave corporate employment some time ago (for a lot of personal reasons), the fact that I’ve been able to accomplish this is quite a big thing for me.

I plan to go into a bit of behind the scenes stuff on the design (not necessarily code) behind Eventbook now it’s out, over the next few weeks, as a form of a retrospective for myself.