Rhythmus.be

Citypath Building a state-of-the-art responsive webapp

How we designed, engineered, and built our first flagship cross-device, cross-platform, cross-browser responsive mobile web app. Citypath: a mobile city guide for Ghent. Product design, UX engineering & front-end development by yours truly.

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 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 in october 2012, they got their first round of seed capital in 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: reach out to an indispensable base of B2B partnerships. The founders knew however that they needed to scale up fast, 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!).

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.

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 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 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 haal het onderste uit de kan of 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. Of course I wanted! Indeed, with our freshly acquired Meteor skills, together we could make a bleeding-edge webapp for Citypath. I already looked foreward 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 succesful 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. And not onwaarschijnlijk, they are of varying quality and with different focus.

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 pixelperfect 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 however 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 live additionally 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.

As voorlopig the app would not allow for user input data pushes, the existing CMS could be kept in place, along with the relational database. We made a process that would regularly take a dump and put it in a NoSQL (MongoDB) document store, from which we would get the data for the app.

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

I went to my rapid prototyping IDE of choice (Adobe InDesign ;-) to create the frets mockups with I would pitch to the client, and which would be the basis from which we would discuss the functionality, look and feel and the features of the product.

Before we could start coding, we needed full funcional 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, the office was embezzled with cigarette smog and the sketches on the flipboard sloppy.
Late night, the office was embezzled with cigarette smog and the sketches on the flipboard sloppy.

Interface

As a designer you’re working with the client’s content, all the time. Each iteration over your templates-in-progress, has the browser render the same bloody images over again. Citypath wanted to feature prominent users on their platform, as a marketing tactic. One of those profiles was the Ghent city major. In the long run, I couldn’t bear his grave sight any longer.

Termont is a fine chap allright — probably one of those rare politicians who know to embrace the Web and social media.
Termont is a fine chap allright — probably one of those rare politicians who know to embrace the Web and social media.

Designing is very much about data modelling. Together with the lead dev, I worked out a solid domain model: Citypath is now bullet-proof future-ready to also cater for festivals, like the notorious “Gentse Feesten”. Events have their own taxonomy, and in the UI we present them as billboard posters, neatly linked-up with their host locations.

Events are temporary points-of-interest. Or are they?
Events are temporary points-of-interest. Or are they?

I took the notice of a public transport, subway chart, with “haltes” — a mental model users are familiar with and which translates the idea of ready-made routes through a city very nicely.

Each route has a cover: look-and-feel of those printed and folded brochures, with a map and an overview, you get in the tourist office. Each point of interest is a stop on the route, and is assigned a category (eat, drink, shop, sightseeing, etc.), all color-coded. Inbetween routes, data for public transport is pulled live, in real time. Hence, “play” button to start, stop, and recommence.

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 “home page” (well, actually, the startscreen — What’s a “page” in a webapp?) went over way too many iterations.
The “home page” (well, actually, the startscreen — What’s a “page” in a webapp?) went over way too many iterations.

Localization & Icons

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 metaphers. Next, these were scrupulously mapped to existing standard Unicode codepoints — quite a scoop in the web icon font world. We didn’t even got to actually designing the glypgs of those icons themselves…

With N icons, the Citypath iconset is ready to scale along with the business.
With N 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. wire 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!)

URL scheme and routing

Webapps are websites consisting out of web pages. That’s where they’re different from native apps — and, boy, it’s a very prominent feature indeed! For one, each of those “pages” has its own dedicated URL… which can be shared by users, tweeted, embedded on Facebook, liked, e-mailed, bookmarked, etc. Having dedicated sharable links to each and every asset in your app (such as the paid ads and profile pages of your B2B partners), is quite a competetive marketing advantage.

As Citypath would expand to other cities we had to take into account early stage. I “designed” an appropriate bullet-proof URL naming convention — (“designing” may be too big a word): zie mail.

Meteor.js

Future-proof

Lessons learnt

Too much in too less time. Very hard: lots of overuren.

Still, we’re very proud to have built a product of such scope in under five weeks, from scratch with a team of basically two to four developers.

Lost time on discussion.

We’re very proud of what we have acomplished with such a small team in roughly one month!

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

May I steal your attention for a few more minutes?

  1. Read more from my blog
  2. View my work
  3. Get to know me a little better