While FAIMS plans for the ‘final’ August–November development cycle, Brian is experimenting with different hardware: an iPad and a Bad Elf GPS unit. He reflects on our roadmap to production.
The final countdown
As we enter our last development cycle, we are closing in on the final feature set that FAIMS will be sporting early next year. Our “expensive sentence” (which has turned into a paragraph1) starts:
To finish the work of developing FAIMS 3 as an acceptable successor to FAIMS 2.6. In order to this, our goal is to achieve a polished production/operational implementation of FAIMS 3 which meets the goals of our original ARDC contract…demonstrating a mature OSS product suitable for task.
Features on our August–November Roadmap
Some (much smaller) subset of this list is what we’ll be working on for August–November, but here are the features which presently have our attention. Comment below if you really want one of the features or have ideas about a feature that will solve a problem you’re presently having!
In (very, very) rough order:
“First-class” iOS support (see the next section for our present workarounds)
Offline Server support
Authentication, notebook-specific sharing controls, and user-provisioned notebook deployment
Improved interface for child entities
Offline basemaps and custom symbology for collected data per layer
Field inheritance and persistence
Branching logic for fields and views
External bluetooth GNSS providers (see below)
QR code scanning and record loading via QR code
An in-app record history and undelete view (we already have that via external tool)
Timestamp fields to reflect record creation and/or a button press to record when an experiment was run
More work on external bluetooth
Sharing/exporting/importing notebook designs in the notebook designer
Live, user-initiated data+metadata backups and restores
Search improvements (ultimately faceted search by data and metadata and paradata2 attribute, but … not now)
Picture vocabularies as per FAIMS 2
A more robust data API
Tabular record view for viewing/editing in bulk
Having controlled vocabularies limit their contents as a more sophisticated form of branching logic
Sync status button3
More polish on the notebook creator4
QR code label-printing view
Linked open data import for vocabularies
Dynamic notebook-level internationalisation
Field descriptions/html infoboxes that are part of the field metadata button
QR code based photocard
Templated inheritance of sets of fields in the notebook creator
In-app audio/video recording
Bluetooth label printers
Citizen science security improvements
All of the above features are “on our roadmap” as we start moving towards sustainability next year. What do you think we’ve prioritised incorrectly or omitted?
iOS workarounds — and “First class” and “Second class” apps
First, what do I mean when I say “first class?”5 A first class app “experience” (regardless of technology) is one where it flows “along the grain” of the operating system: everything “just works” without need for other apps, exceptions, or fiddling settings. There is, obviously, nuance here. While providing:
feels like the start of a “first-class” release: using the platform’s app store, has smooth integrated app permissions with the UI, and has an automatic update flow, we’re still some distance off the full experience (mostly due to manual user provisioning and management, and the external GPS flow in the next section). Still, someone (you) could follow the above link, then visit https://forms.gle/yUjnstZZ7EPWWcGz7 and have Android app access to our demo server at https://demo.3.faims.edu.au without undue fuss or instruction-provision.
The stewards barring the staircase6 to first-class offer workarounds like “side-loading” or “Progressive Web Applications (PWA)” where users can get an experience almost, but not entirely, unlike the normal app store. This experience inevitably includes settings menus and security workarounds that normal apps never need encounter.
Our focus has not been on iOS during the last development cycle due to the priorities we had to meet. Despite that, we are very aware of how important first-class (that is to say “published as an App on the Apple App Store”) support is to be a credible cross-platform tool.
Having FAIMS 3 as a second-class “app” on iOS is possible, but with caveats and security implications. (We’re looking for iOS beta testers who can help us explore the limits of this workaround. If you’re an iOS user and are keen to get involved contact [email protected] and we’ll be happy to give you instructions.)
Adventures in External GPS
On the Android side of the fence, I’ve been working with a Bad Elf GPS Pro+, to investigate how modern mobile OSes handle external GPSes. Quite frankly, little has changed in the last decade — on iPadOS, I need to use the Bad Elf Pro app to provide NMEA 0183 parsing for the OS. At time of writing, I haven’t established that the app provides geolocation data to Safari (see above) — so right now these instructions are android only.
Happily, Bad Elf’s instructions for Android are excellent. Follow the instructions at https://badelf.freshdesk.com/support/solutions/articles/5000708633-enabling-android-mock-location (and as far as I can tell, the apps they recommend can pair with any relatively modern external GPS unit. I’ve got 3 charging (photo above) but haven’t managed to test them yet. Once paired, having the “Bluetooth GNSS” app running (and having gone through its checklist) and provided the unit about five minutes of good skyview to see satellites, it managed to get a 2.7m accuracy on the top of a MQ building, quite close to the promised 2.5m accuracy of the store page.
While these workarounds are not becoming of “first-class” apps, they allow us to collect external GPS data without spending significant development time (and we have too many things fighting for that time right now). Let us know if you want to commission this feature for next year!
Stuff I’m reading
Julia Evans on What happens when you press a key in your terminal
Patrick McKenzie on the Alchemy of Deposits
Graydon Saunders on Scale
And a pony.
We’re hoping that the offline server more than compensates for a lack of a visible sync status for individual devices.
It is very rough and ready right now but having a transition period where hand-editing JSON gives way to a more robust field data collection experience is a tradeoff we’re willing to make.
Terminology note: these are terms I’ve just thought of, mostly because I was just listening to:
and thinking about steamships. A quick search doesn’t turn up any standard nomenclature, though lacking knowledge of standing nomenclature, searching for it is fiddly.
For more news, subscribe!