Build

9.2 Build and maintenance

This broad list of thoughts suggest the direction of discussion required as the design proposal moves closer to operational software.

Identifying where the data ‘lives’ and what is done with it is as important as the data itself.

Resilience of the information and the experience will need to take into account client side download and storage of data that allows the experience to operate whether there is a data signal from a cell tower or not. This download should occur regularly to lessen service to the user regardless of what even is underway. This download and caching should occur with the user’s knowledge and permission.

Unless any secured budget is significant, the first version of this experience should be produced as a responsive web application in order to reach as many people as possible.

A brief, separate proposal will need to be created that looks at the fragmentation of the market should iOS and Android applications be deemed necessary at some point in the future.

Design note: the experiences illustrated in this document are shown on iPhones. However this is not a recommendation for the creation of an iOS native application.

PDFs should not be used in a public experience online outside of long form reading as they are not semantically structured documents; they elicit some of the same experience limitations of printed media and enforce a static one way relationship. As long as they are formatted appropriately they may be used to fill some experience gaps within the MVP. But on a mobile phone they use excessive processor capacity and are hard for most users to manage.

The processo- intensive use and battery consumption issues highlighted in the application of a PDF within an experience apply also to data responsive mapping technologies.

With the potentially patchy availability of a cellular signal in a crisis area, alongside clientside caching, Prepare Wellington’s UI will need to degrade (offer a progressive or phased limitation of functionality so that the available information infrastructure is used economically).

9.3 Build locally

Leaving ‘Buy NZ’ discussions aside for the moment, why do we recommend building something essentially from scratch? Why not use Ushahidi, Google’s crisis map, or New Zealand’s own Thundermaps?

Prepare Wellington should be comprised of personally relevant, socially and culturally specific information. The data that it collects and protects should be guaranteed within New Zealand law and potentially the primary data stored within NZ’s boundaries.

The product should be open to local software development volunteers to help provide a sense of wider public ownership.

Ushahidi is constantly changing its public/private relationships with the open source community and their business model locks account usage to a flat fee: only a few people can contribute to it. Despite that and in a ‘normal’ use context that the platform was designed for, it would be permissible to sign the contract, but the trans-situational use-case that WREMO has stated is not compatible with the way Ushahidi deployments are usually made.

As a ‘startup’ with European Commission funding, it is not hard to conceive that Thundermaps may find itself in a similar situation. That this mapping service is also built on proprietary code also means that the local V&TC community cannot support WREMOs goals and the locked platform cannot respond to how WREMO anticipates the growth of their own product serving the local community.

In the creation of the experience, a partnership between the public, private entities and the stakeholder should be created to ensure community ownership and a condition of transparency that helps encourage widespread adoption. Again, this should include dialogue with V&TCs.

Wellington’s own Koordinates open GIS database should be explored as we consider the development of, and data sources for this product.