Citypath

Building a state-of-the-art responsive webapp

June 2013

Citypath is a mobile city guide app, with many hundreds manually curated quality points-of-interest. The advanced interface allows users to browse through this large collection through several different components, fire detailed queries to the database, filter, and bookmark.

With Citypath, visitors who want to get to know a city, plan a trip beforehand, or find a place to sleep/eat/drink, etc., while on the go, have a nice new option. And the best thing is: they don’t need an expensive iOS device, or any other proprietary lock-in platform — all they need is access to the Internet using any (modern) browser! Citypath is a webapp, and I’m proud to be a lead contributor to its development.

The cosy historical town of Ghent in Belgium (our home country) is the first (and, for now, the only) city Citypath has on offer.

Citypath.be’s orginal website, before we came in: a very basic database search form, running on an obsolete php back-end.
Citypath.be’s orginal website, before we came in: a very basic database search form, running on an obsolete php back-end.

Citypath were founded October 2012; they got their first round of seed capital January 2013. The first iteration of Citypath.be was a simple website, running on a hacked-together CMS, built in an obsolete PHP framework. It did what it had to do, though: reach out to an indispensable base of B2B partnerships. The founders knew that they needed to scale up fast, however, to build an (even more indispensable) audience of end-consumers. Thus — as most startup founders believe — they thought to need an iPhone app.

The team

Luckily for Citypath (and for us ;-), their investor consulted a seasoned PHP developer who was tasked to run the codebase through a technical audit. That consultant was Pieter Soudan (yup, my bro!).

Me and my brother (on my right) at a startup incubator meetup in Antwerp. We just released our very first Meteor project, less than three months before we started work on the Citypath app. It was my 34th birthday.
Me and my brother (on my right) at a startup incubator meetup in Antwerp. We just released our very first Meteor project, less than three months before we started work on the Citypath app. It was my 34th birthday.

Pieter has years of experience in PHP, and at first sight he considered a complete make-over of the Citypath back-end into a more robust Symfony 2 implementation. But as the business needs of the founders demanded for a more cutting-edge “appy” sollution, it became clear soon enough, they really needed a whole different beast. To sum it up: a stunning front-end would be at least as important as a scalable back-end.

Pieter and I had quite a bit of experience with building webapps in Ember.js, and we had done (started) a project in Meteor.js, together.

New tech

In fact, I was very happy, when, about two years ago, Pieter said he wanted to make the jump from his traditional LAMP stack. As a tech-savvy n00b (a hacker groopy really), I had been eagerly following all the cool stuff happening in the web tech scene: NoSQL, MVC patterns in Javascript, Javascript on the server, … I had been playing around with CSS3 and HTML5 as they came around, and did some nifty little things with it. From time to time, I urged Pieter to have a look at the new kids on the block.

But you know how things go for consultants: they got clients, with legacy code that needs to be maintained, there’s few time to toss around with new repo’s and discover fresh dev stacks. Anyways, the feeling to miss the boat (like the generation of Java devs that just precedes us), became itchy, and Pieter really wanted to do future projects using the latest of technologies. Thus we dreamt up a startup side-project together and did a few pair-coding hackatons. Pieter did all the difficult stuff on the back-end, while I continued to get the most out of all the cool new CSS. Citypath was an opportunity to rehearse our experiences, for a real production app…

Pitching

Pieter’s verdict had been clear: if Citypath wanted to survive scalability issues, their legacy codebase had to be refactored from the ground up. Php was still an option (Symfony2), but it would be wise to go with the new tech, from the start. For the time being, Citypath’s legacy CMS could be kept in place, after all, but on the front-end a complete make-over was sorely needed. Meteor was the perfect fit for that, all while being a sound, future-proof choice, once the business would scale and move to a more modern architecture. As a consultant, Pieter gave his technical advice and explained to Citypath what their options were. Of course, whatever they would decide, they would need a new supplier.

Chances were likely that Pieter’s agency would pitch. He asked me if I wanted to join in as a usability consultant to his team, to work on the Citypath lead. Sure I did! Indeed, with our freshly acquired Meteor skills, together we could make a bleeding-edge webapp for Citypath. I already looked forward to work (as a freelancer) with the team over at Red & Ivory (Pieter’s dev shop), both as a product designer, and a front-end developer. Well, after some back and forth, and a successful pitch indeed, we landed the job.

My early-stage raw nightly “wireframe” sketches. The basic UI patterns are there — now they’ve materialized in a touchable interface.
My early-stage raw nightly “wireframe” sketches. The basic UI patterns are there — now they’ve materialized in a touchable interface.

Designing the product

There are lot of competitors in the tourist app space — Citypath is going for a tough ride. (But hey, guys, it’s your business! You sure know.) As their were no real functional requirements, let alone a strictly defined view on what the product should look like or be, it was my role as the product designer to shape that view. I of course did my homework and had a look at what was out there, and how existing competing apps placed themselves in the market.

The first mockups for Citypath were designed immediately in the browser.
The first mockups for Citypath were designed immediately in the browser.

The first mockups for Citypath I directly designed in the browser. I’d be faster with my familiar InDesign workflow, but I was pretty sure we would land the job. And if we did, there would be very little time to meet the deadline. So I fancied, I would not waste my time on pixel-perfect yet unusable bitmaps, and instead write code we would be glad to have, once the term sheets were signed. I betted right :-)

The new Citypath has a somewhat unique offering. The fact that the product would focus on pre-made “paths” (and in the near future would allow users to create their own paths), could make Citypath into something special.

Originally, the client wanted to create “My Path” as a separate offering, a native iOS-only app, to go as an addition to the existing website. We convinced not to go for the native app approach, but go for a cross-platform, cross-device, browser-based responsive web app, using modern web technologies like html5 and javascript.

Second iteration of mockups, now back in InDesign.
Second iteration of mockups, now back in InDesign.

I returned to the drawing board, using my rapid prototyping IDE of choice (Adobe InDesign ;-), to create the first mock-ups which I would present to the client as a basis for discussing the app’s functionality, its look and feel, and the feature set of the product.

Before we could start coding, we needed fully functional requirements. There were none. As Citypath was the founders’s first experience with running a web business, we had to teach them how things are done. Together we had to invent the product, there and now, by going through all use cases, discussing the interface and the data structures simultaneously. My didactical experience as a teacher came in handy… It became a memorable 12 hours non-stop marathon meeting.

Late night, while the office got embezzled with cigarette smog, the sketches on the flipboard became more sloppy.
Late night, while the office got embezzled with cigarette smog, the sketches on the flipboard became more sloppy.
The “stacked panes” component: initial proof-of-concept in a css-only implementation. It was a brain-fuck already, but the final (?) full-fledged implementation in our Meteor.js front-end would prove to be much more work still, with many dozens of refactorings.
The “stacked panes” component: initial proof-of-concept in a css-only implementation. It was a brain-fuck already, but the final (?) full-fledged implementation in our Meteor.js front-end would prove to be much more work still, with many dozens of refactorings.

The Citypath iconset was carefully compiled. And it’s huge. For each feasible category, entity, and UI component, in the domain model, we selected clearly recognizable metaphors. Next, these metaphors were scrupulously mapped to existing standard Unicode codepoints — quite a scoop in the web icon font world.

With ∞ icons, the Citypath iconset is ready to scale along with the business.
With ∞ icons, the Citypath iconset is ready to scale along with the business.

Cartography

Having a good map component was a quintessential requirement for the Citypath app — sure, it’s a city guide. Initially we would use Google Maps, only to implement custom cartography later on. Unfortunately, during development the Google Maps API proved to have too much limitations, styling was not obvious, and, first and foremost, Google would put data of Citypath’s competitors on our maps… So, halfway development, with the deadline closing in upon us, we decided to go with a custom implementation after all.

I wasn’t too sad about this sudden change of direction, since I had wanted to try out Mapbox’s Tilemill for quite some time. The unexpectedly urgent business need, truly offered a development and design opportunity! Eventually we went with a CloudMade+Leaflet.js combo, though. Designing a custom theme with that stack was a pain, and definitely not the experience we would have had with Tilemill. But implementing Leaflet (i.e. wiring up in Meteor) proved just a tad easier, given the short deadline.

We developed a custom interactive map of Ghent for Citypath. Bars, restaurants, shops, and monuments, are all nicely color-coded.

Free wifi hotspots clearly draw attention. And on touch devices, users may of course pinch-and-zoom as much as they please :-)
Free wifi hotspots clearly draw attention. And on touch devices, users may of course pinch-and-zoom as much as they please :-)

The map (and the app as a whole) surely can have some more improvements, both on the usability side as in performance (especially on mobile connections). We’re aware of that. But I was very pleased to see it work by own experience. When we were still in development, by chance my girlfriend performed at the Ghent city theatre (she’s a gifted improv player). I wanted to buy her friends some drinks, but had no cash with me — a wonted emberassament for cyberanarcho’s like me. As we don’t know our way in Ghent, I was lost. Until I pulled my new Windows Phone, pointed IE to the dev-server, and within a minute I found the nearest ATM using our own f*cking app! Awesome! No taste like your own dog food!

Improving on cartography is definitely next on our dev roadmap. For now, it’s good enough, but as soon as we go in the next phase with Citypath, we will go for Mapbox. (On a side note: Mapbox now powers the map editor of OpenStreetmap. Yeah!)


We prepared Citypath for the future. There’s still a lot that can be done, and must be done. We got a vast backlog and a roadmap that’ll keep us busy for a long time to come. City path’s foundations are solid, though: we know the app is able to scale, the interface and UX patters are extensible by design, the codebase is clean and maintainable. Everything’s staged for a state-of-the-art infrastructure in the cloud.

Now it’s up to you, guys! Prove your business, get those sales up, stay focussed on the product vision, and see you soon!