Building the Digital Shoreditch Open House Guide

In the Beginning

When This Place registered an open house event for Digital Shoreditch 2015, we were excited both to create an entertaining experience for our attendees and to see what the other open house events were like. The events page had a table of 115 events but no easy way to find out how close they were to us without manually entering each address into Google Maps.

The event listing page had a rendered height of over 35000 pixels. This is almost 33 full screens worth of information on a 1080p display.

It seemed obvious that we wouldn’t make the effort to go to any of the events unless it was more convenient to browse the details and if that was too much for us, it could be a big barrier for others too.

We wanted to build a tool to close this gap. The more we thought about it the more it made sense:

  1. It’s one more publicly available project to show off what our team can do
  2. Making this helps fellow attendees find great events at Digital Shoreditch
  3. It seemed like an easy and fun addition to our daily client work

We like to take bits and pieces of agile processes and workflows which best suit our team and the project at hand. For the open house guide, we would be trying a new approach for the core team of three (1 dev, 1 UX, 1 visual), which was a more integrated and iterative version of our normal way of working.

In short this meant that UX and visual pair-programmed with the development team and thus decisions about all aspects of the product could be made, literally, on the fly. We did not produce a separate visual reference document, the project code itself was to be the living visual reference. On the development end, we did not set up a build toolchain. Opting to code straight onto an inline script to start. Deploying the app would then be moving the project assets into an Amazon S3 bucket.

An Idea, A Deadline

Since this was a greenfield project, we found it easy to conjure up a large bucket of potential features and started expounding on the various use cases of the bigger ones.

The date was May 12th, only four days before the first open house event.

With such a tight deadline, we knew prioritising tasks took on a grand importance and this couldn’t be done unless we knew with some detail what it was we had to do. We decided these were the must-have features:

  • A list of all events for Digital Shoreditch Open Houses
  • A filter for separating events in a relevant way
  • A map to display the location of all events after being filtered
  • An event detail container
  • A way to share an event on Twitter
  • A way to get directions to an event using Google Maps

At this point, there was enough direction and dev work started.

Day 1

Dev started by using a modified version of ExcellentExport.js to scrape the event listing table into a CSV file. We knew the data wouldn’t have significant changes during Digital Shoreditch so it was an acceptable trade off to use a CSV snapshot of it as the database for the guide app.

To show the event locations on a map, we used a geo-coder to turn all the addresses into latitude-longitude coordinates. This would make it easy to plot the points on a Google map. Our data was now in such a state that we could begin developing a basic Google maps mashup as the starting point of the app.

That’s exactly what we had built at the end of the first day: a barebones prototype.

Day 2

Now that we had something real to play around with, the focus was on UX once more to compile a cohesive experience. Whiteboards were essential in drawing out app concepts collaboratively. We iterated through several complete flows including sharing of deep-links to event details. We also figured out several ways to filter the events and gradually wrapped our minds around what a stranger to Digital Shoreditch might be interested in when browsing through events. At first there were a few different filters and sorts for the events list. There was already a map, a pre-sorted list of events by day and their times and locations and the geolocation of the current user. Through the iterations we kept asking ourselves: “how could we make this even simpler?”

The quick but confident pace felt great. It also put more cool looking wireframe graffiti on our office walls. After we internalised the learnings from whiteboard sketching, Glenn (our UX man) applied these to more high-fidelity wireframe documents to be fed straight into development.

UX and visual were also keen to explore in-app navigation that wasn’t hidden behind the over-generalised burger menu. Recent studies have indicated it elicits a less than positive response from users.

Keeping in the theme of simplicity, we used open, “glanceable” language, allowing fast access. Simple changes such as seeing today and tomorrow’s day items marked as “Today” and “Tomorrow” instead of the weekday helped us short circuit mental clutter out of the experience.

At the end of day 2 our minimal viable product existed in code and all the additional feature priorities were up to date along with the stretch goals. We knew exactly what steps we should take next.

Day 3

The third day saw a continuation of the wire-framing to ensure that the app was easy to use on the two modes we had planned for: mobile and large screen devices. The “About This App” information also had to live in a spot within the app and the task of choosing a good location to put it was quite difficult.

Dev continued in parallel as the UX was being finalised: scrolling enhancements on various elements for touch devices, Google Analytics event tracking, ways to share events externally (URL deep-linking within a canned tweet), and caching of the processed CSV data on devices that supported the LocalStorage API. Visual design was continuous and unrelenting in replacing the placeholder visuals after each batch of development.

Towards the end of day 3 the guide had become feature complete and it was now ready for a full visual design run down. We tried several styles of map markers, each set having two separate styles: one for normal events and one for This Place’s event on Friday the 22nd.

Day 4 — The Finale

The app received its glossy outer sheen when we coded in the visual and interaction designs that had been polished up. It now had a more refined personality and was altogether a more pleasing experience.

Development-wise, JS, CSS, and HTML minification were added as a last step before deployment.

Much of the final day was reserved for running over all tweaks and kinks that had slipped through and to correct a few errors from the data we scraped: for instance a “mailto:” prefix was missing on some of the event RSVP email links.

We recruited nearly everyone in the office as guinea pigs to iron out any last snags in the app interface. When the state of the app passed our confidence test, the social media broadcast began in earnest. It would carry on for the whole week of the Digital Shoreditch open houses programme.


The app generated a lot of new interest in both our team at This Place and our capabilities. There seemed to be four key elements that made this a successful delivery:

  1. The problem the app solved is expressed in a single sentence.
  2. The core team was small, highly integrated, and sat next to each other.
  3. The core team had advanced knowledge of their tools.
  4. The deadline was tight, yet not suffocating.

We would definitely do another project in this manner again. Slightly differently depending on the scope and size of the team, given our learnings from this exercise. You can find the code base for the app at MIT licensed.

Like what you read? Give Jim Yang a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.