This year at the ETH Library Lab we set out on a journey: trekking through the winding valleys of software development, tip-toeing across the expansive glacier of the iOS App Store until finally reaching the heady heights of deploying our first app. The name of the project: BioDex, its goal: to enable biodiversity research with automated species identification. The resulting BioDex App, specifically designed for use in natural history and entomological collections.
From a proof of concept phase with strong focus on insect classification in the previous year, we had now established our basecamp, a rough prototype running on Google Cloud . Our intention for this year then was to improve the species prediction model and create a new mobile app to improve the user experience. With these objectives in mind, we set out in the winter months of 2020 to find our course…
Choose Your Own Adventure – The Design Stage
The design phase is a vital part of any project. We wanted to create an app that has a workflow specifically suited to people working in natural history collections (i.e. people who are sorting many specimens in a day). Consequently, our priorities were to have an ergonomic layout that minimises the number of steps between photographing a specimen, viewing the results and starting again. We created mockups  of each screen and sketched out the workflow to visualise these layouts. Taking this time upfront to clarify your own thoughts and clearly communicate your ideas with others can save a lot of time once development starts.
Venturing into unknown territory is more likely to go smoothly if you can enlist the help of others. For this, we enlisted the development services of fellow Technopark residents, Propulsion Academy, who handled the Full Stack development of the Mobile app. Our planned route was quite simple; for ease of organisation, and for flexibility after completion, we would split the project into two main parts; the Full Stack App Development and improving the Prediction API. This would give the flexibility to easily update the prediction model in the future, without needing to change the mobile app.
We tried to focus on including only the most important features for the app to function well; anything extraneous was noted and set aside, for possible addition in the next release. Our aim was to complete the full cycle of releasing the app and getting user feedback rather than unnecessarily spending time on features that were not needed.
In retrospect, reflecting on the project from my personal perspective, it’s clear that the journey would be better represented from another angle!
Take Home Points
- define which features are essential for the App’s functionality
- detail how these features will look, function and navigate between one another
- set a time limit for feature development
Development – the Hike to your Destination
Soon after starting development on the app, we decided to invest the time in developing our own infrastructure to host the project internally rather than on Google Cloud. This shifted the focus of the project away from Data Science experiments to improve the prediction model’s accuracy, to instead creating the full stack infrastructure that would facilitate hosting the model and mobile app on our own servers. With limited experience in web development, we knew this particular aspect would be a challenge. However, the key learning was that delays were rarely caused by major decisions or problems, but rather by the accumulation of the many small day-to-day issues and questions. Compounding this effect, modern full stack applications – particularly ones using machine learning – will use many different libraries and frameworks, and when working as a single developer it takes time to switch between these, especially when using them for the first time. The benefit of regular access to technical support to quickly solve these issues should not be underestimated.
“Motivation is the single most important factor in any sort of success”
Sir Edmund Hillary 
To combat these challenges, one should aim to create features that are just fit for purpose and are not over-engineered and complicated. Ideally, keeping the right balance between developing features quickly (using simple approaches) and only spending time optimising code when necessary.
In addition to the development work, I underestimated the amount of time needed to work with a third external developer. We were fortunate to have a great working partnership but the onus is still on you to make decisions along the way and supply the developer with assets, designs and clarifications that they will need to contribute to your envisioned app.
Take Home Points
- junior developers are most effective when they have convenient access to more experienced developers for day-to-day problem solving (or can work as a team)
- beware of optimising your software before it is necessary
- working with third party developers effectively requires a considerable amount support of time
Deployment – The Push for the Summit
As is now common practice, we containerised  each part of the project for easier deployment, stability and future scalability. And future is the keyword. Containerising your project is an upfront time investment to avoid issues at a later stage; meaning that your project is more transportable and can quite easily be deployed to different servers or ensure that other contributors can reliably recreate your project.
Despite the benefits of containerising a project, it cannot completely replace the need for some testing in the actual deployed environment, where some operating system version or security protocol could have an impact. We were fortunate to have a test environment for this purpose that replicated the production server.
Take Home Points
- try to provide early access for developers to a hosting environment that replicates the production environment
- project requirements can change rapidly in the early phases of a project, so avoid spending a lot of time on specifications
- carefully consider the costs of cloud hosting vs. the time required to host on-site
Distribution – The Home Stretch
To create the Android and iOS versions of the app, we used a cross-platform approach using a framework called Expo which will build native versions of your app for both platforms without having to write additional code. The philosophy of Expo is to abstract away the complexity of authenticating your app and releasing it to the app store. In our experience using their process only works if you have an iOS developer account that has permission to release an app. This can create an extra hurdle in larger organisations with defined security protocols such as ETH Zurich, in such a setting it may be worthwhile paying for a separate Apple developer account to free up this process.
Take Home Points
- frameworks can abstract away complexity, but usually restrict flexibility
- apps may get rejected by Apple on the first submission, budget additional time for correcting small issues or improving the content in the app store
Looking Back on the Journey
A major consideration for future projects will be to determine if making an app for the Play or App store is the best decision. And if so, how will there be separate Android and iOS codebases or will you use library that supports building for both platforms. The use of the term “app” has become so commonplace that is worthwhile checking what is really needed before committing to developing one. Web browsers’ capabilities have improved so much in recent years that the majority of apps could be implemented just as well in a modern website. And if users still need the ability to use the app offline, it is worth considering creating a Progressive Web App (PWA) , which allows users to continue working with the app and then synchronise with the backend once they are back online.
The right choice depends on the use case and the resources available but removing the complication of publishing through the app store can save a lot of time. It is a matter of considering if the potential improvement of brand recognition and discoverability is worth the time and cost investment to get your app approved by Apple and Google.
Being good at development takes practice, and with each trip through the development life cycle, things will go much faster. Especially if you take the time to create services that can be reused in the future.
We were supported and given advice by many people throughout this process and would like to extend our thanks for their assistance:
Sven Koesling & Johana Llakmani of ETH Library IT (BIT), Max Schlapfer of ETH IT (ID BD), Dominik Hug of ETH IT (ID SWS), Dr. Matthias Töwe of ETH Library, Björn Scheiwiller , Cedric Delacombaz, Daniele Roncaglioni & Nitin Kumar of Propulsion Academy, Dr. Silke Meyns of ETH Transfer, Dr. Andrei Plamada & Dr. Uwe Schmitt of ETH Scientific IT Services, Dr. Michael Greeff of ETH Zurich Entomological Collection
Footnotes and References
 BioDex iOS App (android app to follow)
 Specifically, we used a google cloud function which takes care of a lot the complexity of creating an api endpoint.
 We used the free tier of a tool called Moqup for this purpose which is probably more suited to teams with a dedicated UI/UX developer. Since then, we’ve been using Whimsical (similar to Miro) which has less detailed control over the visual and interactive elements of the design, but is faster to use and is easier to include the navigation between screens.
 A container is a self-contained unit of software that packages up code and all its dependencies so the application runs quickly and reliably on different computers and servers. Learn more here.
 See more explanation and description of the benefits here.