Technology stack

Making a webapp meant that we had to use web technologies for everything: HTML for the structure of the app, CSS for its layout and JavaScript for everything else. The good news is, with HTML5, there is now a way for 95% of browsers to generate and manipulate images in realtime with code. This technique relies on something called the canvas. In a canvas, and with some javascript code, you can draw geometric shapes or images wherever you want, move them around smoothly, get touch/mouse position and react to clicks/taps almost instantaneously. Usually, for complex canvas animations, developer don’t write plain JS/canvas code but instead rely on a JavaScript library that already implements a certain number of complex formulas to accelerate code development.

http://topotopo.io/, a simple and engaging web app to generate and explore terrain data from different places on earth.

Exploring the web for examples of web app similar to what we had in mind and testing those on a tablet, we were convinced that this would be the way to go.

Week 1–2: first prototypes

The first two weeks were spent experimenting with DCW catalog and making simple interactive prototypes to test our sketches and minitial mockups in a real setting. We worked on the user interface and the prototypes in parallel, with integration of visual elements being usually done the day it was drawn. This way, we could work in a two-way feedback loop (UI-wise and code-wise) that helped improve the overall consistence and helped us experiment a lot of possible interaction principles.

To be as close as possible to how the app would be used (that is, in the context of a stand in the busy Salon of Milan), we focused on designing and prototyping for an iPad in landscape.

“Our target resolution was a tiny 1024*768 pixels in a 4:3 aspect ratio. While we kept in mind that a lot of our visitors from the web (and not the Salon) would be using larger screens, it was a good exercice to try and optimize the user experience for such a screen.”

Drawing on the web

There are a lot of different drawing-oriented libraries in JavaScript for the web: some of the most well-known include paper.js, rafael.js, or p5.js. For that project, we didn’t have much time to experiment to find the most appropriate library. Instead, we considered the following factors to decide which one to use:

familiarity with the logic and functions,

and functions, size and importance of the community behind that project

behind that project quantity and precision of the resources we would need, such as vector manipulation, touch controls and physics-based animation

All things considered, we decided to use p5.js. We had no prior experience with this library but a lot with Processing, the langage that inspired it (which helped us build working prototypes in just a few minutes). Also, p5.js’s community is large and has been very active since the beginning of this library. Its issue tracker many hundred issues closed and almost all those that are opened are being discussed.

Also, one of the deciding factor was that Daniel Shiffman, from the youtube series The Coding Train and the book Nature of Code, had published a lot of resources for p5.js, especially on physics. Having watched a bit of his channel already, we were confident these would be precious additions to kickstart our physics engine (which turned out to be the case).

An example of a great video by Daniel Shiffman about physics engine. Excellent way to get to know how they work and how to use them.

In this situation, the riskiest aspect of going with an unknown tool such as a JavaScript library was stability and performance: what we had sketched initially would probably be feasible in p5.js but what could happen was that after a good bit of work on a prototype, we would discover that p5.js can only manage 5 or 10 lamps in a given scene when we expected 30 or 40, or that the app would crash randomly for some unknown reason.

We settled on a reference device to test all our prototypes on (both UI-wise and performance-wise): an iPad 3 from 2012 running an up-to-date iOS and Safari. Since this device is quite old and would probably be amongst the slowest device in terms of performance to connect to our app, we were forced to optimize everything as much as possible.

Testing p5.js

The first few prototypes we made were about getting to know and testing the limits of p5.js. We spent some time reading the tutorials and experimenting with object-oriented programming in p5. We specifically looked at the following example from the p5 docs, and from the Nature of Code Vectors chapter.

This is what the first prototype looks like: