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 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.
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.
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…
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.
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 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 :-)
- users would need an “app” on their mobile device, going around town, be connected
- Wifi boxes - we dreamt up our own wireless ad-hoc network (very much like MacAfee’s), running on Arduino hardware, Node.js w/ Meteor deploys
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.
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.
image: Fully responsive — Use that plugin like Instapaper does!
“appy” look and feel (beacuse the client wanted to appeal to the iPhony hipster folks): slide-in drawer menu on mobile, while on desktop computers it rseponsively transforms into a more conventional multi-level dropdown menubar
on mobile app bar always visible
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.
- Event posters
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.
- image: The paths component
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.
- Image carousel: Path covers
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.
- “Stacked panes” !
image: stacked panes in action — animated gif
we went with the vogue of flat design, but not all too fundamendalistic: the path component especially features more iPhone-style, subtle gradients, bevels and shadows
- the “home page”: real pain; went through severla different iterations. At first we agreed upon a tile grid, very mch inspired bu Windows8 user interface (previously knwon as “Metro”): made abstraction of the content, we could put in there whatever we wanted: ads, gfeatured content, banners, path covers, points of interest, etc. So we implemented very powerful grid system (Isotope.js). Only when we got further in the proces, it beacame clear the client wanted more of a traditional homepage, with full control over the exact and content and the positioning and layout. Hacking the algorithm. Lesson learnt: lots of efforts spilled when there is no full finctional requirement and throuough information architecture which can be agreed upon by all parties involved, upfront. We embrace agile development, but the project was too much in a hurry.
Localization & Icons
- A dedicated set of icons for the user interface, all carefully mapped to standards-compliant Unicode code points.
- No time (i.e. no budget to have a custom set designed), so cherry picked form existing (right free) icon sets.
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…
- We setup a basic admin tool by which the client could provide language keys of elements in the UI
- Language detection (instead of outdated flags)
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.
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.
- Originally hybrid approach with symfony2 php back-end, and Ember.js for the front-end app. We had some experience with Meteor before, but only a side-project trial.
- not stable, no real production apps. Still we would give it a go! Quite a daring decission the lead developer took, but I’m very glad he did!
- We prepard 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. Foundations are solid: app will scale, code is clean and maintainable. Everything’s staged for a state-of-the-art infrastructure in the cloud.
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!