Today I was tooling around with some interface concepts and playing with apps like foursquare and Twitter (previously Tweetie) and I wondered if I could implement something similar to the now famous 'pull down to refresh' method of initialising a refresh of the content within a UITableView.

As it turns out it wasn't as difficult as I thought; There were already a couple of elegant solutions out and about. The first example I found was by Oliver Dropnik, which talked about altering an existing solution posted on git hub by user devindoty called EGOTablePullViewRefresh.

Oliver's code looked like it was a good addition to devindoty's because he had decided to subclass UITableViewController which leads to a much more complete solution that's easier to move between projects. My only issue with Oliver's code was that it refactored a lot of the underlying implementation, where I didn't see too much wrong with it.

I decided to come up with a half way measure; I moved the majority of the grunt work into a subclass of UITableViewController, cleaned up the XCode Demo project included with the source code and pushed it all back up to git hub. If you're at at all interested in this, I'd suggest checking out my fork of the EGOTablePullViewRefresh project on Git Hub.

Get a pull-to-refresh effect like Tweetie 2 and foursuare

Update: Another pull to refresh implementation is now in the three20 library by Facebook, but I'm not sure where exactly it's buried.

It's been a long slog, I have to say. It took a solid six weeks of development and many hours of dead ends and frustration but I finally managed to pull together a complete, stable release that made it through the approval process.

There's still lots to do, and since Saturday morning I have already sent for approval Seoul City Metro Lite, and Seoul City Metro V1.1.1 wich contains a few small bug fixes.

Busan City Metro is also in the works, I expect that to be running on the Seoul City Metro V1.1.1 code in the coming days and up for sale soon.

There's lots more to write on the extended development period of SCM 1.1, but for now I'll let everyone get the update and I'll take a deep breath!

Current iTunes Connect status

As I thought, this might be the case. Upon releasing the initial version of Seoul City Metro into the wild my work has load only got more intense. Two days after SCM hit the store the main Korean competition app unleashed a new 3.0 release and  a price reduction - and in addition to this almost all the feedback I received pointed towards one or two features I had deliberately left out of the initial release. So since SCM wen't live on the 10th I have been frantically preparing my infrastructure to handle timetables and Google maps (via the MapKit framework). I am also working hard to streamline the viewing, cacheing and organisation of the 'Routes' part of the app.

I'm not worried about implementing MapKit because I have previously mapped all 440 stations and their GPS coordinates - but it's been managing the almost half a million pieces of time table data that has taken so much more time that I had originally anticipated. Although the details of the timetable data are relatively boring, I find the statistics quite interesting.

• 468,000 individual trains mapped equalling 17MB of SQL data.
• 1,600 pages scraped, totalling 48 MB.
• The addition of this data almost quadruples the total size of the app (originally 5.7MB)

This leads to an interesting problem with the app bundle size. Apple limit the maximum size of an App you can download over 3G to 10MB. Personally I think keeping an app (if possible) below 10MB is really important, as it allows your app to capture the impulse purchase. I'm currently considering several options about how to manage this, including providing only the basic data with the app and allowing users to download the additional data as an SQLite adon-on, or by providing a web service that can be queried from within the app. There's advantages and disadvantages in each case (which I might outline in a later post) but in my opinion, most people will only need the first and last trains departing each station anyway.

New SCM Branding

In other news, I've been working with Steven Miller (@yargalot and from TheNetocracy) on some new branding and a new website for SCM and I have to say I'm pretty chuffed at what he's come up with. I had pretty specific ideas in mind when he asked me if he could help design a website and he met all expectations when he came up with a clean, stylish design almost instantly. We spent more time making sure we had the markup optimised for search engines that we did on design elements - and it looks great. The website now exists at http://www.seoulcitymetro.com (previously http://seoulmetroapp.com) and is hosted with a swish new slice purchased the other day from Slicehost (Slicehost Referral link).

With the idea in my mind that I would possibly serve 17MB downloads to SCM customers or provide a XML/JSON feed for individual station timetables - I had upgrade the hosting to something more flexible. Enter Slicehost. With the help of Jacob (@jacobch) we now have seoulcitymetro.com and our git repositories running on a speedy clean Ubuntu Karmic Koala slice. So far we're totally impressed with both Slicehost and Ubuntu and we hope to run more services from this in the future.  I can definitely envision a public bug tracker and documentation wiki for SCM and other upcoming projects.

There's heaps of work to be done! I'm hoping to have the next SCM version 1.1 submitted to Apple by 1/1/10. Watch this space! To the minute updates can be found on twitter by following @seoulmetroapp . Seoul City Metro is available on iTunes for $1.99  iTunes Store (iTunes link)

Seoul City Metro

I'm excited to report that Seoul City Metro has gone live on the Apple App Store!

You can purchase a copy on the world wide store right here for $1.99 US.

Now that the iPhone Application development cycle has been completed - it's time to start some promotions to drum up some sales! I have @yargalot and myself working on a proper website, and I'm looking into promotions on Facebook, and around Seoul itself.!

There's no shortage of apps that will take your 1-4 dollars and let you sift through lists of stations or tap on a map and work out a way for you to get from A to B in your given city.

I've been working with a pile of transport apps leading up to Seoul City Metro and I've noticed a lot of similar transport apps fall into the trap of implementing too many non standard UI elements or offer too many different ways to do the same thing at the cost of consistency.

Non standard interfaces are not uncommon as developers decide not to adhere to the apple Human Interface Guidelines and roll their own half baked Us. I I have found some great examples of non-scalable, non standard implementations that are so bland and basic (or crazy and complex) that it's hard to know what you're doing or what you just did. The time required to lean these UIs is frustrating to say the least.

Great example of very non-standard UI

My second issue with the current state of transport apps is the compromise made to consistency to offer multiple ways of accessing the same functionality.

Most transport apps provide you with a list of stations you can select via searching or scrolling through via a 'Stations' Tab Bar icon. This interface is then repeated via a 'Routes' Tab bar icon and quite often you can also access the 'Stations' via the 'Lines' Tab Bar icon. My problem with this solution is when the selection of a station name in a list looks the same and behaves differently.

Two ways to begin a route visible here.

As is often the case, selecting a station from the 'Stations' tab gives you a detailed overview of the station. In the case of the 'Route' tab it skips the details and provides you with the same interface over again to select another station.

A lot of apps have about 3 ways you can enter into the 'route calculation loop' and I find this overlap pointless and confusing.

Another example is when applications let you tap on a map and use the selection as a 'route start' or 'route end' and then take you to a list or an overlay of the route you've selected. This can be a great feature except when you can get to the same map that behaves differenty via three other Tab Bar icons.

In the case of applications with a tab bar interface you can end up with the same screen of information appearing on all or most of the tabs at once by navigating through each Tab Bar icon independently. This is not a good user experience because clicking on a tab bar icon saying 'Stations' can be showing a map if thats how the user haphazardly left it.

My approach to a transport app (although only in it's first iteration) focuses on the soul purpose of directing the user towards selecting stations. The user will be given ways to select a station by map, name, or nearby then be presented with the detailed view of the station in order to decide what to do with it. After the user has completed an action their selected station (set as route start, or route end), the user navigates back to the main menu to select a second station. Only when a route has been completed are they presented with a 'view route' option.

Straight forward navigation structure

So rather than a Tab Bar I have used a single navigation structure to direct the user down a single path at a time to select a station. This provides the user with a linear way of working, keeping them from getting confused between 5 or more tabs that all do similar, overlapping things (and could all be displaying a map at that particular point in time).

I think it saves the user mental processing too. The maximum menu depth a user can get to to view a calculated route is only three screens deep, and if they have used a route before they can get to the calculated route in only two steps. The worst case in the application above (London Tube) can require you to navigate through 5 different screens to view a route and then you need to go back through the whole 5 to start again.

I think simplifying transport apps is the way to go, working and thinking about how to do this all the time.

If you've read this far - thank you! This post just touches on my thoughts about current transport apps and their inconsistencies, I'm keen on posting more of my thoughts as development of my transport apps continue.

Seoul City Metro should be hitting the App Store around December 14th. Follow @seoulmetroapp on twitter for updates!

Wow, what a month!

It really was about 10 times more stressful than I had planned.

Here I was plodding along with the development of Seoul City Metro (@soulmetroapp) thinking I had another couple of months but all of a sudden the iPhone was approved for sale and then released in South Korea in the same two week period! I had to push everything forward...

So over the last couple of weeks I have more or less shut myself off from everyone except my twitter feed and a few friends keen to test some development releases (thanks to @jacobch for some great feedback). Due to the announcement of imminent iPhone release in South Korea I just had to try and get everything running ASAP.

Unfortunately Seoul City Metro missed being ready for sale on iPhone launch day (it was never going to happen) but as a consilation I managed to make it to TEDxSeoul at the last minute  for a day of eye opening talks from a wide range of awesome Korean innovators. I had no expectations for TEDxSeoul (how did I not know about TED ?)  but it left me with a mind spinning with excitement and positiveness about releasing software in South Korea. I wish I had had some business cards to hand around and some infomation on the app ready - but getting to go was just a bonus.

Seoul City Metro

But I'm now happy to write that I have finally got there! As of Tuesday morning I have completed an initial working version of an iPhone app and submitted it to the App Store. With submission only four days after the release date in South Korea I am pretty happy with my efforts. This is  is a really  important milestone because it's taken me so long to get past being completely overwhelmed by the whole process of becoming an iPhone developer. In fact it's taken me  two trips to WWDC, two iPhone releases (3G , 3GS release), two new computers (a laptop and a Mac Mini) and countless days and weeks of feeling overwhelmed and lost at where to start.

New Business Card (back)

Regardless of the outcome (approved or not) I'm feeling like I have reached my goal. While I wait for approval from Apple I'm running at a slightly slower 80 km/h getting promotional material ready for it's launch. I'm hoping with some relevant, informative tweeting on my behalf via I can rustle up some interest over Twitter and Facebook, there's also a website up at seoulmetroapp.com and I have printed flyers and business cards for some real life promotions.

I'm attending the Seoul Writer's Workshop Masquerade Ball this Saturday night in Itaewon and hope to bump into some people there.

Watch this space for all kinds of things I've learnt over the iPhone development process, and updates on what I'm calling the City Metro Ecosystem - a suite of apps encapsulating apps for Hong Kong, Beijing and Shanghai.

More details coming soon

So, finally Apple have relented and decided to allow In App Purchase for free apps.

I just have to say that I'm really excited about this.

I think the initial idea behind Apple's 'free apps stay free' policy was to prevent 'fart apps' hitting you up for money mid session and allowing the paid apps to prosper in their superiority. But now the App Store eco system has evolved to a point where serious developers are needing ways to give  their potential customers previews beyond the only option of  'buy the free one, then if you like it buy the non free one'.

Recently I've been looking at ideas for in app purchase and I decided the two app idea wasn't going to work for what I was thinking. These new changes basically allow me to sell my ideas (they're not apps yet) on the App Store they way I want to.

Take this scenario:

If I were to build a single application that supported lots of different maps (for example) via in-app purchase, which map would I bundle with the initial cost of the app? And what if if the customer didn't want the bundled map I was including? In that case the customer would essentially  be charged extra money to end up with the map they really wanted, and I didn't see that as a great introduction into my software.

An alternative approach would have been to sell the initial app at a low price point to get people feeling comfortable about buying the app, and then continue to sell the other maps via in app purchase for an appropriate price. This would have half solved the 'unhappy default map' scenario by simply costing the customer less money. But would they see the saving? Or would they still be just as annoyed at paying me twice for what they really wanted in the first place. This was the compromised way  I was heading, but it would have meant giving away the the most popular map at a discount just to get foot traffic.

But as of today with these new rules on the App Store I can do what made sense in my mind and create a main 'gateway' app that could act as it's own little 'map store' and be given away for free - allowing the customer to choose the map(s) they want without going through the mental hurdle of paying me twice to get what they want. This is a much better option.

These new changes to the App Store policy will provide a great deal more flexibility all round. Now that the developer isn't required to charge an initial fee for in app purchase enabled apps they can provide free apps as a means to paid content. Previously the customer had to pay for that privilege, and in some cases it was a bit backwards. This will also be great for sales and promotions. It allows apps that include in app purchase to become free for a specific period of  time then go back to how they were.

All in all it's a great addition and is only telling me to get my act (app) together even faster!