As you can see the horizontal line has been lowered a little. Also the sun rays are less visible too. I already like the new design better than the old one. Hope you do too.

App Store Link – Today Todo

In this week’s post I will detail an idea for a small tool that tracks iOS sales as they happen. We are about to build such a tool and toyed with the idea to turn it into a service for other developers.

The Problem

Sales reports for iOS apps are provided by Apple. These are simple text files containing data about purchases, updates and refunds. The problem with these reports is that they are always provided a day later as they happen. Given the huge mass of App Store transactions this is understandable. However, the specific time for a purchase is not only a nice to have but can provide valuable insight.
Knowing from our own experience and hearing from other devs too, visibility is the usual problem in the App Store. Since there is no surefire way to improve it, we can tackle things that can be directly improved. Like finding the right target audience. If you build an app you should first find out who is your target audience. This way you can improve your app and adapt it to their needs. But finding the right target audience is very hard. Without studies, field tests, consumer reports it is guesswork at best. And these studies are hard to come by – especially when you just want to get to building this awesome app already
It is not too late to adjust your app to its users even after releasing it. And here is the crunch. You’ll want to have as much info about your users without compromising their privacy. Sure you could use something like Flurry. But their stats are not realtime – and I think that’s the valuable information you need.

Apptrack

We have thought about a tool that would provide anonymized realtime purchase stats for iOS apps. This tool would consist of a small library that needs to be added to your app as well as a web application. After starting the app for the first time right after the purchase, it gathers data and sends it to the remote web application. The code would only run on the first start (saving this info to NSUserDefaults is trivial). The data that is sent over is displayed in a useful manner that leads to valuable insights.
But what do you gain if you know when your app was purchased? Knowing the time alone, won’t do much good but combined with other stats it starts to become useful. After all as a developer you will want to know as much as possible about your users. This knowledge will help you shape your app for your target audience making it more useful for them. This ultimately leads to more app sales – if act on your insights.

Imagine the following scenario:
User X buys your system administration related app at 3am. Timezone is set to Europe/Berlin. Geoip lookup reveals that his purchase originated from Germany on a DE-CIX line. He has the latest available iOS firmware installed and his device and locale is set to EN. He also uses the latest iPhone model.
This is what I deduce from this info:

• User bought the app fairly late and as such he was probably looking for a specific solution (maybe an urgent problem)
• Since the ip originated from a backbone provider in Germany the user might be an admin who is working late from the server housing centre
• The latest firmware version and the latest iPhone model suggest that he is technically inclined
• Having the language set differently to his current location could mean that he is not a native speaker and/or (taking the other assumptions into account) used to English as the main lingo for tech content

So if you know that (many) stressed admins buy your app fairly late while working on a remote location – this ia a really good hint for the further development of your app. (like bumping up the price  – just kidding)

Besides useful insights about your users, there is some serious nerd potential in there. Just some ideas:

• Hook up a new purchase with push notifications that notify you, the developer, every time a purchase has been made (of course featuring a classy “cha ching” sound
• Build a “purchase-o-meter” on your site indicating the (crazy) amount of new sales due to a marketing event
• Build something similar to the “app wall” that Apple showcased on the last WWDC
• Change your desktop wallpaper dynamically depending on the amount of new sales (happy, sad, crazy…)
• Hook it up with your Twitter account

Conclusion and Request

I really like this idea and I am definitely looking forward to see it materialize. And here is my request. What do you think? Is it useful? Would you use it?Would you even pay for such a service? I am not talking big bucks since I don’t expect to strike it rich with such a service… It would be nice to know if others might find it useful so please comment.

This is our last post for #iDevBlogADay for now (Miguel changed the rules for the better and added a rotation system). We will be on the waiting list again but this doesn’t mean that we’ll stop blogging. Grab the RSS feed to stay in touch.

See you.

With all these AAA titles coming out for the iOS platform (and elsewhere) there are still some games who pop out of nowhere and climb the charts in no time as if there is nothing easier in the world to accomplish. I have a theory about what makes these games special and I want to share it with you in this week’s post.

The Problem

It is my firm belief that games (or gaming) are an integral part of our human nature. Sadly, this part is largely overlooked by adults with mostly the young instinctively holding on to it. As Raph Koster puts it in his book A theory of Fun for Game Design, gaming is a form of learning (or training skills) in a risk free environment with the ultimate goal to improve our chances of survival thus rewarded with a powerful incentive – fun.
The problem is that it sucks to be young these days. When I look back at my childhood it makes me glad that the internet wasn’t mainstream, that computer games were still in the 16 bit era and that I spent most of my free time outside.
Fast forward 20 years and we have an oversupply of games. If I were a kid these days I’d be more than tempted to loose my soul on World of Warcraft and the likes.
Since I am not the only one to realize that gaming is such a powerful concept, the multimedia industry focuses on computer and console games turning it into a huge business. But something happened along the way. It seems to me that the crazy high public expectations and the fierce competition forced publishers and developers to take the safe route and produce games that are known to appeal to the masses. Suddenly most games are no more sparking with creativity but are rather high spec tech demos boasting of sophisticated graphics and dumbed down to “go there, do exactly that” affairs.
An example. I have played through the blockbuster title “Call of Duty Black Ops” a few weeks ago. Right now I can’t even remember the name of the main character anymore. Yet with Minecraft – a formerly small indie game started only by one guy alone – I can remember nearly every time a Creeper blasted my ass off while I was mining underground…
If you prefer a more graphical presentation of this idea, check out Ben Croshaw’s Zero Punctuation series. While brutally honest and really hilarious Ben points out exactly what’s wrong with today’s games – one fuc**** game at a time.

I think the reason so many big titles turn into hollow shells is because the mainstream focus slowly shifts away from a passive art of entertainment to a more interactive form. Through the unhomogenous demographics that denominates the broad target group for games, these titles have to settle on the lowest common denominator in terms of mass apeal.

It’s All about Limitations

And then there are games like Andreas Illiger’s Tiny Wings.

This game was released on February 18 and a few days later it ranks #1 in the US App Store. Why? How? I asked Andreas if he had any form of marketing in place or did other preparations. He didn’t do anything! Crazy isn’t it?
Not at all. Because based on my theory he used artificial constrains to greatly amplify creativity while keeping it simple. And simplicity is what I think most people crave these days. Given the multimedia overload that surrounds us each day, we still look for ways to be entertained. And when a game strikes the right balance between creativity and simplicity like Tiny Wings did, it appeals to many people. Like Angry Birds did – or Doodle Jump or Fruit Ninja.
It is important (at least for me) to identify “limitation” as a main stimulus for creativity. Because that’s a winning formula for us small indie developers. We have everything in place to create great games whithout big investments. All it takes is creativity and the right balance between simplicity and depth. Add to it some deliberately chosen constraints and it could lead to huge success (yes, the game Portal 2 is coming soon and I am using its lingo because I have played Portal 1 a few days ago and I am listening to its song Still Alive ALL_THE_TIME).
The game machanic of Tiny Wings is by no means shallow. It may appear simple but it is damn hard to master. I am playing this game for days now and I still can’t reach the friggin island 7 (which by now every 12 year old would master after a few hours….)!
So what do I base my theory on? If you want proof for my idea – take a look around you.

• Twitter – 140 character limitation and it became one of the most popular platforms ever.
• Apple – with its religious “keep it simple” mantra that made MP3 players dead simple and has a proven record for really easy to use interfaces.
• Google – with its minimalistic interface and “no frills” approach to searching content.
  I have intentionally chosen big names here because I still find it fascinating that the idea of simplicity is still at the core of such big businesses.

Getting back to games, this doesn’t mean that only indie titles are a guarantee for great gameplay and mass appeal. There are many big titles that did it right. I guess that can be attributed to some bright minds who were involved. As usual – the right mix of people under the right circumstances.
I have played a lot of games in my life. Screw Valve for making it so damn simple to buy them (through Steam). Here is a list of my all time favourite games – big and small:
Click to expand

Conclusion

It’s pretty obvious this time. Limitations are great. Creativity is great. Combine them, amplify them and run with it.

See you next time around.

PS

Oh, and one last thing. For all those whiners (including me) who cry “cruel world” when they have created some really ingenious iOS apps and complain that visibility is the problem for their missing success. Andreas landed with Tiny Birds at #1 with NO visibility when he launched the game. So much for the witty iOS marketers who all chew on the same old cow “visibility is everything”…

This week I’d like to show you how we manage feature requests for our apps with Jira. If you want to know why Jira is great, see my last post.

The Problem

Feedback is one of the most valuable things your users can offer you (after paying for your app of course). There is now way you – as a developer – can forsee all the features your app will need. What’s even better, through feedback you can get a good grasp on how your users are using your app and what they expect next to make it even better. Since those users are your perfect target group, what can be better then feedback from them?
It’s up to you to decide what to make of it, but receiving and managing feedback (or featured requests as a subset of the possible feedback types) is very valuable.
If you have done it right, feature requests will start to flow in. They may be submitted via email and if you don’t store it elsewhere, it will shortly mess-up your inbox. Worse yet, if it is not categorized, you’ll have a hard time to remember for which version (maybe you have an iPad and iPhone app) it was meant.

Feature Requests with Jira

As you may have noticed by now I am a big fan of Jira by Atlassian (and definitely not on their payroll – this is pure enthusiasm). Since we use Jira to track issues while developing our apps, what would make more sense than to store feature requests there? One possibility for such a setup would have been to configure our Jira installation for public access so that users could submit feature requests by themselves. We didn’t follow this approach because most users tend to give up on requests if the entry barrier is too high. Before using Jira, we had set-up an account with GetSatisfaction. However, the simple fact that users had to create an account there, led to very few requests. After providing a simple HTML form (and later even a “contact support” button from within the app) – feedback shot through the roof  (hat tip to Sarah for the great idea).
Right now our workflow consists of the following steps:

• Feature requests roll in via email
• I access Jira to see if there is already a similar request
  • If there is one, I comment on the issue with the text “+1″
  • If there is no request, I create a new issue with the type “Story”

As you can see, I have added a custom field for the issue type “Story” called “Feature requests”. Then I have setup Jira to count all comments on the issue to display the sum in that field.
The great thing about this setup is that the field “Feature requests” can be used to filter issues. So for example when planning updates for one of our apps I can create a quick custom search and filter for something like:
“show me all feature requests with the component “iPhone” and sort by “feature requests” count”

As soon as we decide to work on that feature, I create a sub-task for the “Story” issue and assign it to our huge pool of coders to work on (Trung or me).

Conclusion

Feature requests are valuable and usually hard to come by. If you make it easy for your users to submit feedback they will make use of it. You’d be surprised how many users are stunned by the fact that a human beeing responds to their requests. I guess our spoiled mass market mentality leads to the impression that companies employs vast numbers of automated support drones whose only purpose in life is to create canned responses to customer mails…
Storing your feature requests right next to your development issues is a clever idea that makes it easy when it comes to deciding what features to work on next.

As an iOS developer (and a tech nerd as per definition) you want to keep tabs on what’s going on in the tech world. Many of you surely have a list of preferred tech news sites you follow. In today’s post I want to show you a nifty tool that solves the problem of the information overload and omnipresent guilt when one fails to stay up to date with the latest news.

The Problem

This is easy to describe as I am sure that virtually anyone in our business is aware of it.
You want to follow as many news sites and blogs as possible. At first you create a sizeable collection of really useful and cool news sites and dump it into your feed reader. And here’s where the problem starts. As noble as your intention was to follow every news bit, the sheer mass makes it impossible. This is – if you want to get anything else done besides reading news all day. I don’t know about you, but I can’t stand to see this red bubble at the top right corner of an icon. This nagging feeling that there is something (presumably exciting and important) makes me want to open the feed reader and see what’s new. This positive feeling turns into ugly guilt when there are hundreds of unread items. And “mark all as read” is not a solution – but rather resignation.

Fever

Fever is a personal recommendation engine by Shaun Inman . It is a web application that you have to install and run on your own Linux based server.
The way it works is pretty clever. At first you subscribe to as many feeds as you like – the more the better. Then there are three important categories: Hot, Kindling and Sparks.

Kindling contains the feeds that you absolutely want to follow – the essential ones. Sparks contains everything else like big aggregating news sites and generally news sites that have a high throughput. Finally Hot is the category you will want to use most of the time. This is where Fever ranks the most important news based on their importance. This is determined by the their re-linking and the amount of discussion they generated. Fever uses the feeds from the Sparks category to generate the rankings in the Hot category. A nice touch is the temperature based theme. It is related to the human body temperature.

You can set the time period in the Hot category if you want to catch-up with older news. Fever is very keyboard friendly. There is rarely a need to use the mouse.

Conclusion

Fever is perfect suited if you want to stay up to date without having to scan hundreds of headlines. Since it works on feeds you subscribed to generate the ranking in the Hot category, it is your very own personal recommendation engine. So less time spent on reading news means more time for coding

This post is about the launch of our latest app Today Voice Notes describing what went well and what didn’t.

The Problem

As with most apps on the App Store the initial visibility is a big problem. At an incredibly rate of hundreds of new apps per day it is becoming increasingly hard to get noticed when launching an app. Classic marketing doesn’t apply much here since most potential customers use the App Store app or iTunes to look for new apps. Banners and Adwords may still be effective in the long term but that’s not applicable for a launch.

But What’s Wrong with the Status Quo?

The status quo would be that you submit the app and when it is released you’ve got a few downloads. These downloads originate from the fact that App Store categories can be sorted by “release date”. After your app has fallen of this list, it becomes invisible (and forgotten) if you don’t actively market it.You have to rely entirely on the search keywords you set in the first place.

How Did it Go?

Today Voice Notes was released on the 19th december 2010. The launch was not stellar but okay. We had 514 downloads (priced at 1$) and 90% originated from Germany.

Launch

What follows is a list of actions we have undertaken. Apart from the immediate feedback (sales) there were other (positive) long term effects. Sadly these are very hard to measure.

Landing Page and Ads

For the small percentage of potential users that look for apps by other means than the App Store, a landing page is the perfect place for the sales pitch.Additionally a landing page can be a great benefit later on in the course of word of mouth marketing.
We have built a landing page that is light on text and uses videos to showcase the app’s features. Since I stared on it fa too long – I can’t say if it is exceptionally pretty or not. At least it does the job to present all features and lead the user to the App Store.

Together with the landing page we have booked an expensive ad. Fusionads is an advertising network for the design inclined. Since Today Voice Notes is rather pretty and heavily customized regarding UI, we thought that it would be a natural fit. Those who appreciate good design are presumably a primary target for the iOS platform too. The Fusionad “roadblock” shows your ad over the course of one day on the entire network – perfect for app launches.

Fusionads generated 500k impresions and 1.5k clicks. Only 0.27% of the people clicked on our ad.
Costs: 1.2k $ for the ad.

Google Adwords resulted in around 40 clicks and since we didn’t use any tracking – I have no idea how many did really buy the app.

Linkshare

It is still impossible to track sales until the very end of the order process because all tracking solutions stop right at the doorstep of iTunes or the App Store app. All except for one. Apple works with Linkshare and provides sales statistics. For this to work, special tracking links containing the app id can be generated and distributed throughout the landing page, other apps and so on. That’s what we did. To be honest the Linkshare report generation is really awful – either that or I don’t really get it. The following numbers could very well be wrong.
The landing page visits translated into 310 clicks on the App Store button and 8 orders.

Press Release and Video

Writing a concise and ad free press release is an art of its own. We have used Prmac for the delivery of our press release. According to their statistics there have been around 300 clicks on the iTunes link for the app. This time we didn’t use Linkshare for tracking. I don’t know why exactly but I didn’t feel like I want to have press people click on that huge and scarry Linkshare link
Along with the press release we created a presskit containing screenshots, app description and links.

• Presskit

A short promo video yielded 225 views (Youtube).

Vieda

Spielhaus is part of an organisation of German speaking iOS developers. From time to time Vieda performs promotions. Around Christmas they have created an advent calender. Every day three apps were presented that reduced their prices for one day. Today Voice Notes launced inside this promo event. This was the greatest success so far because 90% of the sales came from Germany.
Costs: 34$

The Rest

We have focused all our efforts into a time frame of 1-2 days to achieve a greater impact. Way before the launch we have contacted many review sites for exclusive reviews. Big profile sites didn’t even took notice and most of the others offered only “honest” pay per review models.

Conclusion

We have learned that it is crucial to find the right target group for an app. Otherwise ads will not deliver their full impact. Maybe Fusionads was not the right advertising network or maybe our ad sucked. But one thing is clear – promo events do have the greatest effect. Although the Vieda promo event does not have the same impact as being featured by Apple, it did catapult the app in front of many potential customers.

This post describes the decision-making process about choosing a proper synchronisation system for our todo management tool Today Todo.

The Problem

Today Todo was released in october 2009. The idea for a small tool that captures the today’s todos was born on a sunday afternoon and after only a few hours Trung had the first prototype ready. Time has passed and Today (as we call it) has evolved. After 22 updates, beeing featured by Apple, a ton of feedback and the usual iOS carousel – we came to the conclusion that Today needs to sync its data into the cloud. This is especially important since the iPad version is nearly done and screams for an unified data source. Our requirements are simple. The sync should be flexible, simple and involve the least user intervention possible.
There are quite a few frameworks and systems to choose from. All have their pros and cons.
Since I wanted to see how competing apps did fare with cloud syncing, I evaluated the most important ones. Here is what I have found out so far.

Do it yourself

Among other sync options Appigo’s Todo outsourced their sync affairs to Moki Mobility. They have built a web app that runs on top of Google Engine. The business model involves a 14 day trial account. After that it costs 19$ per year. The web app is not exceptionally pretty but functional and sports a clean look.
The internal data structure of the iOS app is kept simple. Appigo uses a handcrafted SQLite db.
The sync process blocks the entire app although it is rather quick. However this was done with a limited data set and with a very fast internet connection. It could be a problem later on.
Overall syncing went smoothly and was very easy to set up.

Pro

From the business perspective the advantage is clear. Only those users who are really interested into cloud syncing will pay for its usage. Although the fee is low, given Appigo’s large user base I expect it to yield a respectable profit.
Another bonus is the simple setup process for the user.

Con

The only notable disadwantage with this approach is the constant availability of the service. Since the user has to pay for it, the zero tolerance of many users will ceartainly make life hard for Appigo should the web app become unavailable at some point.

Another app that uses a similar approach is Wunderlist. This new contender made by 6wunderkinder uses its own service for syncing. Instead of a web app they have built a cross platform client based on the Titanium Framework. Upsides and downsides are the same here except that using the Titanium framework 6wunderkinder cut off their way into the Mac App Store.

MobileMe Calender

As with Appigo, Guided Ways’s 2do offers several syncing options. For cloud syncing they decided to use the MobileMe calender. This option is available via in-app purchase. Since the feature set of the calender does not suffice, Guided Ways had to make some compromises. Attachments are not synced and projects and checklists appear as flat lists.
Syncing is done either manually or when the app starts and quits. Conflicts are not handled very well and may lead to confusion. Again the data structure is kept clean and simple. 2do uses a handcrafted SQLite db.

Pro

The big advantage with this approach is offloading the availability issue to Apple/MobileMe. And since MobileMe is tightly integrated with Mac OS X the synced data can be accessed easily.

Con

Guided Ways had to force their data into the MobileMe Calendar structure. The compromises they made may not seem that bad but I suspect that the implementation was far from easy.
Another downside arises from the fact that MobileMe is a payed service. I guess this alone will drive many users away.

TouchTodo from Chen’s Photography & Software uses the Google Calender for synching. The same issues apply here.

Google Docs

Awesome Note from BRID went for two options. They support Evernote’s service and Google Docs. Syncing is done manually and turned out to provide the weakest experience from all test candidates. At one point I managed to unintentionally loose all my notes because it was not clear that restoring data from Google is only functional if it was previously backedup. However, Awesome Note has its own backup system that works via wifi. I still don’t know how to backup the data to Google (I thought that this was one of the benefits of syncing…)

Pro

As with the other tools, offloading the aviability issue to another provider is a big bonus.

Con

Although Google has a large user base, putting the data into Google Docs does not really fit the purpose of a todo manager. This problem originates from the fact that Awesome Note tries to be both – a todo manager and a notes utility. Google Docs works great with notes but not so great with todos.
Another problem is that Google and Evernote limits the size of uploads. However, this does not weigh-in that much since these are extreme situations that are rarely met.

File based sync

Omnifocus from the respectable Omni Group went for a file based sync approach. They support syncing to MobileMe or any custom WebDAV folder. They do provide a Mac client that can be set to sync to these services too. Syncing happens automatically and proved to be stable and smooth. Omnifocus uses compressed xml chunks to transfer data to MobileMe. This time MobileMe is used as a mere online disk for storage.

Upside

The file based sync provides the most flexible approach for advanced users. They can use their own WebDAV folders and have the certainty that they own their data.
Another plus is the small amount of data that needs to be moved around. This results in a fast sync process.

Downside

Syncing is considered a hard problem, especially when it is done on such a basic level. The whole sync logic needs to reside inside the app and was ceartainly not easy to implement.
As with 2do MobileMe is a paid service and may not appeal to everyone.

CoreData on Dropbox

TL Quantum Inc. implemented with Todo Queue syncing via Dropbox. Dropbox is a popular online storage service. For unknown reasons syncing in Today Queue involves moving the CoreData db around on every sync! This is crazy by any means. It is not only dangerous because it may easily lead to corruption but quite wasteful since TL Quantum Inc. has chosen to keep a copy of the db for every sync.

Pro

I have chosen this app because they use Dropbox and this is the service we are most inclined towards right now. All the advantages apply with the added bonus that Dropbox is free (2gb storage). This is more than enough for syncing.

Con

I don’t see a notable downside here (if you don’t put the db directly on Dropbox…). After a short glance at Dropbox’s API, their philosophy “keep it simple” seems to carry on here.

Conclusion and opinions needed

There really are many approaches to choose from. Right now Dropbox seams to offer the most advantages. It is free, popular and has a nice API. Their usage limits are fairly high too.
I would be very interested in your opinions. Is there something we didn’t take into account? Any gotchas?
Mat Smith was very kind to provide his view on this topic here (thanks Mat). He votes for a personal web app that can be run on the own server. Sadly this would exclude too many users and it is not feasible. His second best choice would be Google Tasks (where Google doesn’t provide an API at all…).

But one thing is certain. Regardless of the choice we make, there will be someone who will complain…

That’s it for this week. I have not decided yet on the next post, but one thing is for sure. It will be more on the teaching side than this one

This third iDevBlogADay post describes the combination of the previously outlined issue tracking and knowledge management that ultimately culminates in the creation of a digital hub for everything iOS related at Spielhaus.

The Problem

Using specialized tools for specific purposes is a good practice in nearly all situations. However, we humans have a hard time when it comes to multitasking. Constantly switching tools while working is not ideal. Especially when the end goal is to keep track of a complex process such as iOS development. Managing one’s knowledge in one place and tracking issues in another, is fine until the need arises to combine bits and pieces from both systems. The ideal supporting environment would be an ecosystem where problem descriptions (issues) are placed along with stored knowledge. If the tools involved don’t provide this feature, the developer needs to take care of it himself. Again, this is not ideal because every free mental resource should be dedicated to problem solving and not be used for gathering supporting info.

But what’s wrong with the status quo?

As with the former posts – the point is still valid: Nothing is wrong unless you want to give up potential of optimization.

Combining issue tracking with knowledge management

If you followed the previous posts it’s not hard to guess that two software packages built by the same developers were meant for each other. Jira (issue tracking) and Confluence (wiki) can be set up to cooperate. The objective is supposedly simple – show relevant issues right on specific wiki pages together with insightful statistics.
Jira can be set to trust queries from Confluence (and vice versa). The workflow involves telling Jira to trust Confluence and then add gadget links from Jira to Confluence.

Gadgets can display charts, the output of search filters or links to other tools – all of this in the context of issue tracking.
I would like to demonstrate this with our flagship app Today Todo. The main wiki page functions as a container for all enclosed pages – each sub-page contains specialized information. When accessing the Today Todo page, I can already see all background information concerning the project. It would be great if I could see the relevant issues from Jira.

As you can see from the screenshot, I can pull in any number of issues related to the development of Today Todo. These are by no means static lists. The content is fetched remotely from Jira and displayed on the wiki page. Furthermore clicking any links (or chart slices) forwards to the corresponding issue(s) in Jira.
This way we have built a cockpit with all relevant info for the project. I resisted the urge to go crazy with charts and extensive analysis data. I have only included the tasks for the actual and the next version together with the feature requests (not visible). These gadgets can be placed anywhere on the wiki concluding their greatest benefit of encapsulating the supporting material with the problem description. Similar to connecting data and code in object-oriented programming. When Trung and I are working on one topic – say implementing a “seamless synching of data between instances of Today Todo” – we have the problem description (feature request) together with all supporting material about synching right in one place.

Conclusion

Since I wanted to keep this post short – that’s all about it for now. I hope that this series of posts helped some of you with this exciting voyage of ours that iOS development turns out to be.
I am not sure what will follow next week now that I am done with my favorite topics. However these <insert app here> post mortems seem be en vogue and maybe it is time to review what worked and what didn’t for Today Todo and Spielhaus over the last year.

The Problem

Even if we try, no app will ever be bug free or remain unchanged. Over time requirements may change or other features creep up and so there is a constant need to maintain a list of todos that are related to developing the app. These todos do not emerge in succession right from the start. They can occur any time. While some of them are just mundane tasks others will have varying priorities. Be it a last minute bug that you found right before submitting the app or an useful user request later on – you will be constantly challenged to keep track of the development process. If you don’t – bad things will happen (and that’s common wisdom so I won’t repeat it here). ‘Because you’ve got issues’ is a slogan printed on t-shirts handed out by Atlassian (creators of Jira) and sums up the very essence of this post.

But what’s wrong with the status quo?

As with the previous post low tech is still a valid alternative. Yet again the time you save while poping out another .txt file on the desktop to dump todos for your app, will be spent later when you need to retrieve and prioritize these todos. This may be at the unfortunate time around the end of the development cycle when time is scarce and the crunch mode begins to leave its marks on your stamina.

Issue tracking

We decided to use a web based issue tracking tool. As with the wiki, the big advantage is its distributed availability and ease of use. Especially since we are working mostly independently from home. At its heart an issue tracking tool is just a specialised task management system tailored for the needs of software development. The base consists of separate issues. Each issue contains a bug description (or feature request, or user story). Ideally it has additional metadata attached like the version it belongs to, the component, the expected fix version and so on. This is the most important part but sadly also the hardest one when it comes to introducing the system. This time the adoption of the issue tracking tool was encountered by much more resistance then the wiki. Trung and I are still not on common ground when it comes to creating issues…

There are two main use cases for the issue tracking system. The first one is to gain an overview about the project. This is accomplished through the intricate filtering of issues. After all everything that is presented to you while operating the tool are just filters that display issues in interesting (and hopefully insightful) ways. The second use case is to store issues (and potential feature requests) so they are not forgotten. Again, filters come in handy when choosing the next feature that has to be worked on. Without metadata no proper sorting is possible. This greatly diminishes the advantage of an issue tracking tool.

Each new iOS project starts as an issue tracking project. We add the proper components following the MVC pattern as well as useful additions like “Text” (for translation related tasks as well as app store texts) and “Marketing” for well… marketing stuff. Versions are defined and we keep them in sync with the real versioning numbers for the app in iTunesConnect. For every bug we find, another issue is created and instantly prioritized. Although most entries are optional while creating the new issue – just their mere existance forces us to think about when and where the issue belongs to.

Jira

To be honest, the first time I encountered Jira I wasn’t very impressed. Even worse – I didn’t like it at all. Much has changed since then with both – Jira and my attitude about issue tracking. Atlassian has put quite some UI love into their (presumably oldest tool) and made it very accessible. Just like with the wiki software Confluence it follows the same usage patterns albeit in the context of issue tracking. This time I didn’t look for alternatives. I have used Mantis before and through my open source past Bugzilla for sure – but that’s all to it. However I am glad that I sticked to Jira – some gems are only discovered over time:

Roll your own or hosted

Just like Confluence, Jira is written in Java and has strong support for Linux. There is a hosted option or you can roll your own. Jira is comercial software and (sorry for saying it over and over again) – but just like Confluence – the ten user license is available for 10 bucks (all proceeds go to charity). Again just like… Atlassian uses it’s own tool to manage the further development of all other tools. There is also a huge community built around it and feature requests get instant attention (for the better or the worse if it is a duplicate request).

It’s like driving a Porsche Cayenne

Jira got its better looks quite late but for a heavy duty issue tracking tool it is pretty and extremly flexible. Besides basics like email notifications, integration with revision control tools (svn, cvs, perforce…) – there is something for everybody. Filters that can visualize just about every mind boggling project state, plugins for the fancy (agile development to mention only one of many), OpenSocial gadgets, fine grained security roles and so on. Workflows that define different states of issues with built-in logic (and sensible defaults) make it possible to customize Jira to fit way more than just the purpose of issue tracking. If you want the full firehose of feature overload:

• http://www.atlassian.com/software/jira/full-features.jsp

But there is more. Especially on the keyboard shortcuts front. Check out my following very short video showing some Quicksilver-style shortcut jugglings.

Click here to view the embedded video.

Conclusion

There is no way of saying that you should use an issue tracking tool because if you don’t, you are clearly making your life harder than it has to be. I hope that this post outlines why there are many advantages when using a web based tool and especially something like Jira. Creating apps is complex enough and needs time, so every tool that helps to reduce its management overhead is a valuable addition to every iOS development toolbox.
Next week I will pursue the ‘holy grail’ of integration when combining Jira and Confluence.

The Problem

While writing code we focus on efficiency and are always on the lookout to improve and optimize stuff. There are however steps in the iOS development chain that need attention too – but unfortunately don’t get much love.
There is a wealth of knowledge that every iOS developer accumulates over time. The question is – where to store it? The brain is not the best storage device since it tends to forget things easily – especially those that are not needed frequently or are somewhat dull and tedious. I am not talking about basic stuff – that sticks. I mean those bits and pieces like libraries that one comes accross while searching to solve a problem, snippets of code that are related to a specific task, ideas for new apps but also marketing materials (where to book ads, list of review sites, reviewer assets, app store stats etc.). The problem gets worse since these bits are sometimes not related to each other and can not be categorized easily.

But what’s wrong with the status quo?

This is a valid question since managing information for the development of iOS apps is perfectly doable with low-tech tools. However the time that is saved when poping out another .txt file on the desktop to dump info, is wasted later when the information needs to be retreived. Plus how are we supposed to combine knowledge in an interesting new way if it is scattered all over the place?

Wiki

We decided to use a web based software to store all of our knowledge and supporting material. A wiki has the huge advantage that it is really easy to use and always available. This is especially important for a team that consists of more than one person (okay, our team is not that huge either – it’s just the two of us Trung and Stefan). Furthermore a wiki is a living thing with built-in memory because every page retains the versions it has gone through.
Apart from Wikipedia where I am just a user, I started to actively use wikis only a few years ago. Kudos to Martin Seibert from //SEIBERT/MEDIA (my former employer) who then forced us to use the internal wiki on a daily basis. This is how I came to appreciate its value.
At its core a wiki is a ‘simple’ system for editing and creating pages that may be structured hierarchically, categorized and linked to each other. Pages may contain text, images or have any number of attachments. There are plugins that extend its functionality to display charts, calenders, forms and so on. However the most important hurdle when using a system like this is its acceptance. It has to be used frequently to become useful. This might have been a source for nightmares for Trung for a long time while I constantly pesterd him to use that damn wiki. One trick is stop attaching files to emails but instead put them on the wiki and send the link to the wiki page. Over time our Spielhaus wiki has evolved into the central hub of everything we do to create apps.
Here are some screenshots of our Wiki. We use a custom theme called RefinedWiki but the first screenshot shows the default look.

We store there everything that is related to our business. For example every new app idea starts as a sub-page of the “Apps” page. From there other sub-pages emerge like – Concept, Mockups, Roadmap, App Store Descriptions (we keep a version of every App Store description to see if a new version had impact on sales). Later other sub-pages are created like Feature Requests, Reviews, Competitors and so on.

But we don’t stop there. Financial informations (how much and where we have spent and the income after Apple’s cut) are stored into an easy to read table. License codes, assets (images and sounds) are attaced to the ever growing “Assets” sub-page. Together with quotes for potential clients, market analysis, developer success stories, book summaries, meeting protocols – the wiki formes a huge conglomerate of valuable knowledge – much bigger of what Trung and I could ever memorize.

Confluence

I have chosen Confluence from Atlassian for a number of reasons. The most important one was its polish and ease of use as well as the flexibility it provides. There are many wiki packages out there – but to put it in Linux window manager terms – Confluence is the Gnome Desktop of them. I have chosen this metaphor for a reason. Many many years ago I have spent endless hours on my beloved Linux desktop, tirelessly tweaking every aspect of it. I wasn’t affraid to extend and recompile parts of (at that time Windowmaker, Fluxbox, Xfce) just to have everything setup perfectly. But while I grew up and free time became more and more scarce and precious, I started to use other window managers where I gave up some flexibility for the sake of simplicity and because much of the basic stuff worked out of the box. It is now the same thing with operating systems, code editors, wikis – there is always a trade-off between flexibility and maintainability.
With Confluence the tradeoff is very small. It is very flexible and at the same time has a ton of syntactical sugar (in terms of managing knowledge). These are the highlights that finally won me over:

Roll your own or hosted

Confluence is written in Java and runs under every major OS. Since I have a bad feeling of running a Windows server online, I was very glad to see strong support for Linux (together with tons of documentation (managed by Confluence of course)). There is also a hosted option if one doesn’t care where the own data is stored. Confluence is commercial software. It is not free. But at 10$ for the 10 user license it is more than a steal. I guess that’s what Atlassian thought too since the money for the ten user license goes completely to charity…

Made by developers for developers

Atlassian consists of a bunch of cool guys (and gals) who first created a tool for themselves to manage their internal knowledge. Eating your own dog food is the best way to ensure a great product.

It’s like driving a Jaguar

For a system that targets the dry topic of knowledge management, Confluence packs quite a number of bells and whistles. Keyboard shortcuts that allow mouse free editing, drag & drop attachments, dynamic content through macros, the WYSIWYG editor, a fine grained permission system are just the basics. This wiki was built for collaboration. There is a built-in blog, a twitter like “what are you doing” thingie, personal wiki spaces and one can build networks of people inside Confluence. Basically it is a complete intranet solution with a huge depth but a very light apperance. And since most features are optional, one can use whatever fits the purpose. But there is more. Pages can be rearranged via drag & drop, content can be tagged and displayed accordingly, OpenSocial gadgets can be incorporated, inline display of pdf documents and so on. There is so much more really useful stuff about it but I will refrain from praising every feature because I don’t want to appear like a Atlassian sales person. Besides I am not affiliated with them.
Here is the full feature list:

• http://www.atlassian.com/software/confluence/full-features.jsp

Here is a short usage video showing some features (make sure to watch it in full screen):

Click here to view the embedded video.

Conclusion

I hope I succeeded with my inception. There is a big potential for optimizing the workflow outside of Xcode that finally leads to an tangible advantage. The upfront overhead of setting things up pays big time after a short while. Knowledge is only valuable if you can make something useful out of it. The way knowledge is structured and stored is critical for the process of creatively combining and ultimately creating something new.

This concludes the actual post and I hope it was useful. Next time I will take a look at iOS related issue tracking with Jira.