Our approach to selecting technologies

Published on April 3, 2015

A clever approach to selecting technologies using the classic example of Native vs Web apps, showing how there is never a right or wrong answer, only advantages and disadvantages.

One of my favourite projects we created last year was our Photobooth app. It allowed users to walk in and instantly take a photograph, enter a personal statement and share for the rest of the internal network to see. We worked in small teams across strategy, user experience, design and development.
Projects such as our Photobooth app present interesting technology decisions for the team. For these types of projects, features and time to launch are often determined by the technology chosen. Decisions like this can hold a team back or enable better work.
Today I want to illustrate a clever approach to selecting technologies using the classic example of Native vs Web apps. This is an example of how there is usually not a right or wrong answer, only advantages and disadvantages. We followed this approach for our PhotoBooth app!
1) Requirements

  • List the features you require, before looking at technologies themselves
  • Organise the features by: must have, should have, could have, nice to have
  • Ensure everyone is aligned on these before proceeding to the next step

2) Discovery

  • Spend some time to discover and learn technologies out there that might fit the needs
  • Range of existing and new solutions
  • Start wide then narrow down to a more manageable list

3) Assess and compare

  • To avoid a bias over technology favorites you need to assess them side-by-side
  • Create a feature table of features vs solutions
  • Create a discussion over which advantages are more important than others

4) Select solution

  • After selecting a technology, an important next step is to communicate the reasons for choosing it
  • Explain the steps you took to select a technology, show your thought process
  • Outline the pros and cons you accept with going this route

1) Requirements

  • Device features (camera, location, form inputs)
  • Speed (quick to navigate, polished look and feel)
  • Ease of development (build in a reasonable amount of time)
  • Cross platform (roll this out to other devices easily)
  • Maintenance (cost and possible reuse/customisation for future events)

2) Discovery

  • We identified three main categories of technology: Native App, Hybrid App or Web App
  • We wanted to assess this higher level of decisions first before narrowing down other technologies/libraries

3) Assess and compare

We can now put the requirements into a feature table to show us strengths and weaknesses of each approach/technology. I like to use a traffic light system here to help visually communicate the differences:

4) Select solution

At this stage it then becomes a discussion of all the pros and cons, will you accept less of A if you can get an improvement on B? Are A & C more important than B & D?
We had a tight timeline for our launch and needed an approach which assisted development, so we decided to go for the middle solution to mitigate risk. We settled on a web app which is packaged as a hybrid app to support device features:

Our final technology stack:

If you would like to try these technologies out yourselves I have put together a working hybrid app template here: