A saga that begins with the desire to be young again and ends with a week full of front-end programming and a day of running around in the park.
each year i feel i'm one step closer to the grave. to be precise, this occurs, for the most part, when the older kid has a birthday, forcing me to face their increasing demand for entertainment, thrills and a special event. age five was dreamy. all we had to do was make a pinata, dress up in a pirate costume and run around the house with a horde of toddlers chasing us down. everyone loved it. then, age six came. a horde of ravaging firstgraders almost took our house apart. and while digesting the consequences of that, we considered ourselves lucky for not being sued by another parent for self-inflicted trauma. after that we turned to outsourcing, and for a while it worked. two years ago we ordered a juggler who had done wonders, and last year its been at skyjump, an establishment where a horde of ravaging kids can expend their energy with no shoes on, within the relative safety of bouncy floors and safety nets. anyhoo, this year, i've had some extra time, and decided to meet my creeping dementia head-on, by planning Maya's birthday myself.
initially, it was to run a class-wide game of orienteering, map & compass, having the kids run across a nearby park. i soon discovered that there are no high resolution satellite or terrain maps of said park in the public domain. delusional aspirations of drawing the map shattered in the face of the harsh reality that my drawing has not improved much since age 10 or so. and then it hit me: why don't i just make a code-scanning webapp, complete with interactive map and all? excellent excuse to hone my react skills, too.
- a map that would show a player their location and nearby markers to collect.
- the ability to collect markers by scanning them with a qr reader.
- an admin mode that would allow me, game creator, to set up markers, edit their description, location and upload a hint image for them.
Process & discoveries
- didn't wanna go redux, too damn verbose and repetitive. took up mobx instead
- mobx is magic, but hides and complexity and is not without issues. had to issue workarounds such as triggering rerenders of specific components from store functions themselves. could not get mobx's autorun & friends to work
- google-map-react integration is also not smooth, had to resort to calling google methods directly and using workarounds to prevent redraws
- react-qr-reader was an extremely positive surprise. that thing works better than many "native" scanners.
Devices , software, compatibility
- tested initially on one up to date android (a pocophone f1) and intermittently, on three ios devices(iphone 5s, iphone 6s, ipad mini) - all upto date. stuff was good
- in the wild, there are crippled ios devices (not up to date software). that mostly caused issues with the camera, as well as crippled androids. again, mostly issues with camera.
- the workaround was to use the built-in qr code scanning functionality of the phone or a qr-scanning app. thus the decision was to use a fully-qualified url within each qr, to enable opening it both from within the web app, as well from an external scanner.
- geolocation in a mobile browser ,even when using enableHighAccuracy, is still bad. the user's coordinates jump all over the place and are unreliable.
- having fourth-graders use a web app is challenging. the vast majority of them do not know what a "browser" is. they know icons (=apps).
- within our specific usage scanario, two major issues were identified:
- getting players into the game
- making sure the web app was functional (map, scanner, auth etc) before commencing
- lacking an installable appstore app, a good entry point into our game was the scanning of a code. this, indeed, placed them within the "app", which, of course, in reality is just a website.
- so long as the scanning using the built-in camera worked, we were golden (latest ios, android do that). in older versions the ride was bumpier: we had to either install a QR reader app, or manually punch in the domain.
- as a result, whenever players closed the game for whatever reason, they found it hard to return. they had to either scan an existing physical game marker, or manually punch in a domain name. none of the players were savvy enough to use bookmarks or place an icon on the home screen.
- what saved the day in our case, was the ability to create teams. kids with broken or semi-functional phones were able to play together with their friends, keeping themselves in the game despite the technical difficulty.
result can be examined, poked and insalled by grabbing the source.