codesofaJust another WordPress weblog

The big naming issue.. a.k.a mv “GottaGo.app” “Transport.app” ?

Well, maybe the most of those who read my blog on a regular basis know the problem with “GottaGo” already.

One week after I released “GottaGo” (release in the sense of ‘appeared in the App Store’), another company called “WindyStudious” released an app with the same name. No big deal – I thought. Pretty stupid, but no big deal.
Problems started later. First of all, it became confusing for my users. Some (I only know 2 who told me) bought the app from “WindyStudios” cause they thought it’s my GottaGo.. So this is not so funny.

Ok, 3 weeks ago, I got a mail from Apple, informing me, that I should update my app because it features non-functional standard iPhone interfaces – the phone interface. Uhm, well yeah, so I searched through my app to find anything resembling the phone interface – no I didn’t, I knew it :)

Long story short: they were talking about the other GottaGo. Great Job! If even Apple is confused, how should customers feel?

Then I wanted to update the information about GottaGo – did not work because there was another app with the same name. So when I sent the form with the new information, it checked if that name existed already – so it did. How friggin stupid is this?
It gets even better: 3 e-mails to Apple – no response.
Alright, so what are we gonna do about it? Renaming.

Of course, geeks like the name. It’s not something like “Maps” or “Calendar” – it’s the philosophy of the app “GottaGo”.
But I noticed some comments in the SBB-Fahrplan app, from people telling that they were waiting for a mobile timetable app for the iPhone. Well – GottaGo was out there 2 weeks before.
Now with that issues with Apple and the “not so obvious name” issue in my neck, I started to think about a new name.
For now, I changed it to “GottaGo!” (which seemed to get around the duplicate name issue) – But that’s not the end of the game, I guess.

What is the real problem with an easy name? I think, that people on the App Store don’t have a subtitle or an abstract of an App when they browse through the Apps. Just a name. So your name must be informative and eyecatching. “GottaGo” is eyecatching only with a philosophy information – which, I think, only 2% care about.
Compare this to desktop software: You can release it under any name, as long as the information is right and Google finds it, as soon as you got the geeks on your side, you’re set.. Not so on the iPhone. Actually, quite a bunch of people using the iPhone are a) not even using the AppStore or b) only downloading games – most of them are non-geeks.

So what we “useful application developers” are trying to do is getting the attention of those who occasionally browse through the apps, and don’t care much about what’s behind an app.
The others, who download your stuff anyway are the “geeks” (not all of them are real geeks, though). They download everything that is free – or they read information or they search for something they want. So, with a good information and a good app, you’ll get them anyway. (the quality maters effect)
But those who browse occasionally through the App Store are the most fascinating. Not only do you have to deal with getting their attention. Your App is your only way to talk to them. They won’t follow the comments of your app, they won’t read your blog, they won’t write you an e-mail, they won’t file a bug – they write a comment, that’s it. Sometimes, they don’t even update your app for weeks.. If you’re lucky and they wrote a comment with a complaint you understand (which is about 30% of all complaints) you’re even in a worse situation that you can’t response to them. You don’t get the e-mail addresses of those anywhere, and there is no reply-to-this-comment method – which is very sad.

But we’ll discuss this later on, as soon as we see what happens with GottaGo and a much improved version. I’m very curious about the change in the numbers of API-calls from the new and the old version. I’ll keep you posted :)
Back to the name. There is another issue with the name now – publicity. I had that interview with Blick am Abend and so users know the name “GottaGo” now – changing the name now would be very confusing. But nevertheless, what to do?

On one side, there is that bunch of people who don’t use GottaGo because they don’t know what it is because they only read the name and nobody recommended it to them. On the other side, there is that bunch of people who are waiting on the new release of “GottaGo” and might get confused by a change of the name.
I’m actually thinking about changing it to “Transport” (because it’s more or less language neutral, eyecatching and informative) – “Transit” was also for discussion, but “Transport” sounds better.

I’m asking for your input. What do you think – should GottaGo be renamed to “Transport” or not?

Comments (1) | Share It »
Filed under: GottaGo, Information, iPhone on September 18, 2008 at 5:59 pm by marc.
Tags: advice, fahrplan, GottaGo, iPhone, sbb

There are friends and there are friends..

If you’ve ever used “GottaGo“, you might have experienced it from time to time: The stations around you disappear on the “Closest” Screen.

Why does this happen? Let me explain.

So far, I used the nearby search from Google to get a list of stations around you. Fairly simple. But.. SBB.ch does i.e. not understand “Bäckeranlage” but “Zürich, Bäckeranlage” which makes sense. But Google only provides “Bäckeranlage” – not so nice to map here. I’ve seen a comment in the AppStore from someone who noted this problem.. And he is right. This gave me a hard time.. [The fact that I'm in the exam session was no helpful either but nevermind :)]

How was the problem solved so far? With reverse geocoding. With the (great) API provided by geonames.org, I could more or less flatten this problems out. More or less? Yes. In the logs (Yes, sorry, I keep logfiles, but it’s to improve the query results, nothing more. I don’t see any IDs or sth. Just from where to where you are going and what method was successful for your query) I saw that a lot of requests for simple station names had to be handled by the “Google Fallback” – which is obviously not intended. This “Google Fallback” should catch up, when/if you search for an address or a POI (like Subway Restaurant Zurich). Why is that? Because the city mapping from Swiss Postal Service and SBB are quite different. I.e. there is a “Klein-Basel” in their database, where there is only a “Basel” on the SBB side. Then there are various ambiguous names, like “Bern / Liebefeld” which is also no hit on SBB.ch .. I guess you see the point.

Summary: Google returns list a stations which do not have the same name on SBB.ch which cannot alway be corrected because the reverse geocoder is not always “right”.

What do you do in your darkest hours? Yes, you ask your friends. There are friends. I’d call them “GottaGo”’s Baywatch ;) I was looking for a solution. Since we plan to release the next iteration very soon and we need a lot of work to do. (Btw.: we is me and Stefan Sicher from sichr.com who is working on the new design like a crazy cow ;) – and no, that design from the last blogpost is not from him, that’s just a mock-design I used to illustrate the layout)

Again – solution. I asked the guys over at local.ch again to help me out. Guess what – they did. They didn’t even say “Yes, we will look into it” – no. Just “Yes, we do it. Just say what you need so I can do it _before_ holidays”. Really – how awesome is this? This will require a few more Horsepower to be squeezed out of my dear “gonzo” but it’s a real breath of fresh air – the light at the end of the tunnel ;)

So you might wonder, what they will provide me.. A lot. First of all: Station-names as on SBB.ch (really exactly the same) together with coordinates (WGS coordinates, they used CH1903 so far). Together with their superfast services and customized XML interface, this will free us from bloated information we don’t really need and exact information we really need.

Then there is autocomplete. I was really worried about that.. (Really really worried. I set this up on another server so I could do it with a different IP-Address in case SBB.ch would block this). I got full permission and a customized API to do autocomplete stuff on local.ch .. Again: superfast! (I know, SBB.ch does a lot more computing for that stuff, but it was really slow :))

As I read these lines, I wanted to tell Joel to bake a big cake so I could give it to the local team. For all those who asked me to open a Paypal account for donations or sth: abandon search.ch and use local.ch from now on! ;) that would result in a win – win situation for all of us :)

Again: I just want to thank you guys over at local.ch, namely Vasile, Patrice, Ebi and Joel for your effort. I hope the users will appreciate it as much as I do :)

Comments (0) | Share It »
Filed under: GottaGo, Information, Tech, iPhone on August 22, 2008 at 12:06 am by marc.
Tags: GottaGo, iPhone, nearby, sbb, sdk, stations

A swiss public transit API (SBB and Google..)

Here we go.. After weeks of going back and forth between a crappy API (sbb.ch) with exact schedule and a nice API with wrong schedule (google.com), I finally merged them into one.

What are the capabilities of this API? Let’s make an example.

Given you entered from = “Feldstrasse 133, Zürich” and to = “Bern”.

• It then checks sbb.ch first – No hit.
• Then it checks google.com, which will return you a schedule with the next transit station from the address “feldstrasse+133, Zürich”

Ok, this is not a big deal.

In GottaGo, we often use (or almost everytime) the coordinates of a station. Let’s make another example.

Query: from=Triemli[8.495521,47.368052,0] and to=”Feldstrasse 133″.

The coordinates are then reverse geocoded, so that we get a city name.. Which is “Zürich” in this case.

• The API will first check sbb.ch for “Zürich, Triemli” to “Feldstrasse 133″, which will be no hit.
• It then checks sbb.ch for “Zürich, Triemli” to “Zürich, Feldstrasse 133″.

  Note that the city is also added to the other parameter since we had no hit in the first place and the city name did not yet occur in the second parameter “Feldstrasse 133″. But no hit again..

• Then it checks google.com for “Zürich, Triemli” to “Feldstrasse 133″, which will be no hit, since there are a few more “Feldstrasse”s around in Switzerland.
• Ok, now the last resort: Check google with “Zürich, Triemli” to “Zürich, Feldstrasse 133″ – Ahhh, finally a hit :)

Why all this? Because of POI and address-book search.

SBB.ch doesn’t really provide a proper API for using POIs and addresses. And google doesn’t provide the comfort of saying “Fribourg” is the Mainstation of “Fribourg” and not the center of Fribourg, and the schedule is sometimes wrong, especially during holidays.

This results in a comfortable API which we can use to make also very simples queries like: from “Current Location” to “Liip” in `GottaGo’.

The URL to this API? http://couch.codesofa.com/api/transit.xml?from=station[longitude,latitude,0]; station2[longitude,latitude,0]&to=station3; station4[longitude,latitude,0]

(The coordinates are optional, and you can enter as many stations as you like, separated by “;”)

Eg: couch.codesofa.com/api/transit.xml?from=Triemli[8.495521,47.368052,0]&to=Bern

Btw.: Latest Beta of `GottaGo’ is out. (An iPhone app for swiss public transit). If you want a preview, see: http://liip.to/applyforbeta

Comments (8) | Share It »
Filed under: Information, Okapi, Tech on August 3, 2008 at 11:39 am by marc.
Tags: api, google, Okapi, php, public, sbb, transit

Sunshine follows rain – GottaGo in the wild

Well.. it took me a while to get here.. And here we are now.

GottaGo is done. (Well, as far as software can be done..) I’m very happy to tell, that GottaGo is ATM. out in the wild for testing and has already been submitted to the AppStore.

Here are some high quality pictures of GottaGo in action:

Well, what has happened so far?

The main problem was the absence of NSXMLDocument/Element. When I started the project, I chose NSXMLDocument over NSXMLParser (SAX) because it’s way easier to handle difficult documents.

Because the app gets its data from Google and SBB over their respective APIs, a flexible XML parser was needed. Especially for SBB. If you’ve ever dealt with the SBB page, you know what I’m talking about.

To my bad, NSXMLDocument was not going to be included in the final SDK – what now?

In the last blog post I mentioned my options. Alea iacta est ;)

First I tried to make it work without a proxy – using IconoraXML but this project was kinda unmaintained and even failed to build. My other approach, to write a wrapper for libxml2 was kinda overdosed.

So I had to rewrite the complete Google and SBB parsing stuff because I screwed up in the first place – this time using NSXMLParser.

What is NSXMLParser – you might ask. It’s actually a SAX parser for Objective-C, which means you look at 1 element at a time. There is no DOM tree or whatsoever. That is a problem if you have hierarchical data – obviously. Let’s say you have 3 train-connections, each with sections.. now how’d you know what section is in which connection if you don’t know about the parent node? I guess you get the point.

If you are really interested, grab the SeismicXML example for the SDK to see how it works in detail. Basically, you just work your way through that Document recursively and always add the stuff you `find’ to your current parent-object. Once you get it, it’s easy to follow..
Sounds like an easy deal, eh? Well, that might be true for the Google data. It was, and that’s what I did.
But SBB? No go. The loader wouldn’t even let me load the html. So what now? – Yes, a proxy was needed – and that’s what was next.

On http://couch.codesofa.com/api/sbb/from/Source1[;Source2 ..]/to/Destination1[;Destination2 ..].xml you see the result (Example). I think this is the first real API available to everyone for SBB.ch .

This was made using the Okapi-Framework with a lot of XPath magic :)

In the next days, I will release the source-code for it, together with an introduction into Okapi since it’s the most basic project I can think of – I just need to polish the code a bit..

So now it was quite easy to parse the SBB data..

Lessons learned? Well, there’s nothing more adorable than a good webservice ;)

What’s next? Favorites and Address book stuff.. But first are some other apps I wanted to get my hands on. (Top secret!)

Comments (2) | Share It »
Filed under: Okapi, Tech, iPhone on July 18, 2008 at 10:47 pm by marc.
Tags: api, GottaGo, iPhone, Okapi, sbb, xml