This was a really fun project. It was a whiteboard app meant for designers to use to draw on top of their artwork while presenting them to their clients.

User Experience

1. I made a web app instead of a mobile/desktop app because this app would be used sporadically by at least one set of users — the clients. Designers would find it far easier to have their clients go to a URL than to have their clients download and open up an app.
2. The app also doesn't have a registration process. It is instantly ready to use.
3. The toolset is fully exposed, and its capabilities are limited by design — you don't need something users use only occasionally to be complicated. Even the ability to change the line colours are tucked away under a sub-menu.

4. The “advanced” capabilities of the tools — uploading the design and initiating a connection — could be done by the designers, who have more experience with the software.
5. Connecting to another client required a verification code. The code was numeric because it was expected that the verification code could be done over a call, where conveying a code that had letters in it could result in confusion between similar sounding letters like B and C, M and N, etc.
6. The thickness of the lines was fixed. A “medium” thickness that would suit most situations was chosen.
7. The colour palette chosen was also one that was functional. Dark grey was the default colour; white was available if the background image was dark. The grey-blue and teal were other neutrals. The yellow, orange and red could be useful to highlight things. Also, regardless of the meaning, the colours could be used when multiple people are collaborating on a call.
8. The eraser was built so that its usage needn't be precise. It was built so that entire lines — not just pixels — would be erased by swiping across any part of the line.
9. The “trash can” tool erases all the lines. It doesn't wait for a confirmation because it is assumed that all the things drawn are not terribly important.

Software Development

What surprised me was how fun this project was to build! Elm just makes things fun to build, and leaves you feeling like you are playing with a bunch of legos. Features could be just thought up and put together very quickly. It's a shame this fanctastic language isn't more popular!

The main aspect was the drawing board. I initially thought of building a raster based image that would be as a layer on top of the designer's artwork. It became clear to me that there would be a lot of interoperability between Elm and Javascript, with much of the code in Javascript. I didn't see a way around that until I looked at the SVG modules in Elm. The documentation was clear and the usage was straightforward. I mocked up a working drawing board quite quickly. It was absolutely brilliant. Colouring the lines was a simple matter. The added benefit of SVG was that lines could now respond to events — thus, the eraser tool came to be. The files module made downloading the drawing a cinch. The toolset was completed very quickly. (The reason for the quick turnaround was also because I was wary of scope-creep and did my best to limit the feature set.)

The other big part of the project was collaboration. Any lines drawn would have to be transmitted to the other participants. One of the obvious methods of transmitting this data was to use Firebase's Realtime database — lines could just be added to the database and the other participants could just listen for new records. However, this introduced a bit of lag during testing. While not unacceptable, it wasn't the greatest. Fortunately, I had worked with WebRTC before. So, I thought to try that here. The connection was brokered using Firebase's Firestore. But, once connected, the communication just happened directly between clients. This made things much faster. Additionally, this app could now scale immensely since all the communication wasn't flowing through one place. (Of course, had to develop a protocol with which each client would tell the other clients whether a line had been drawn or removed, and in what colour.)

Once the working version was completed, I added some optimisations: I used the “Svg.Lazy” module to speed things up even further, so that only the current line could be redrawn and everything else was left untouched.