Creating an app that will never go to market poses unique and interesting challenges. What is the purpose in writing such an app? Who is the target audience? Where do you spend your time as a developer?

As the developer on Wayfindr’s London Euston Underground trial, working on the demonstration app I was forced to consider these questions. Wayfindr’s ambition to produce the open standard for audio based navigation is extremely exciting, but also involves numerous challenges.

Who are you building it for?

As part of the London Euston Underground trial we were aiming not only to refine and reaffirm our vision for the Wayfindr standard for vision impaired users, we also needed to validate that managing a fleet of beacons within a large underground station was sustainable. This gave me as a developer two target audiences; the vision impaired people who helped us with testing and the teams within Transport for London (TfL) who commissioned us to work on the trial. In this case, our target audience was the vision impaired users participating in the trial.

On top of all those considerations, the app is just a prototype that will never hit the app store. This meant that developing the app is a delicate balancing act. For the success of the trial I needed to design an app that was immediately accessible to users, while at the same time not over-engineering for features that are not and will never be there.

Managing your time when you aren’t launching a product  

As always, good programming practices hold true for such a project. However, some practices came out as especially important for this type of project. I feel that having kept these in the forefront throughout the development process helped make this trial so successful.

• Keep It Simple: Time is limited within these types of trials, even more so than for building apps for public release. Keeping your code simple and organised is all the more essential for meeting tight deadlines.
• Iterate Frequently: Trials are all about testing ideas and hypotheses, so get out there at test your code with real users as often as you can. Don’t wait until feature ‘X’ is polished; get user feedback, iterate to fit their needs and ultimately meet the goals of the trial.
• Don’t Optimise Immediately: Unless your trial is about having the fastest running app, postpone any optimisation of the code base until you actually need to.
• Clean As You Go: Keep your code base clean. If you are going to be working at high speed, you need to be working in a clean environment. I like to split my work day by doing 7 hours of development and ending with 1 hour of code cleanup. This may include refactoring, writing documentation and comments, removing dead code, etc. For me it was the right balance between delivering new features and keeping the project a pleasant working environment.

Find out more about what we do here.

Special thanks to:

AEXML, Alamofire,  Fabric,  GRValidation,  Kontakt.io, Moya,  OHHTTPStubs, SwiftGraph, SwiftyJSON, and SVProgressHUD for making great frameworks and tools that were used in the development of this London Euston Underground trial of Wayfindr.