5 minute read

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.

Corner-of-office charging … zone… The devices are starting to accumulate. CC-BY Brian Ballsun-Stanton

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:

Thanks for reading FAIMS 3 - Electronic Field Notebooks! Subscribe for free to receive new posts and support my work.

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

  • Federated logins

  • Sync status button3

  • More polish on the notebook creator4

  • QR code label-printing view

  • Linked open data import for vocabularies

  • Dynamic notebook-level internationalisation

  • Record duplication/templating

  • 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

  • Derived/calculated fields

  • In-app audio/video recording

  • Sliders

  • 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?

Leave a comment

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:

A link to the version of our app pointing to the demo server

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!

Subscribe now

Stuff I’m reading

1

Word inflation?

2

And a pony.

3

We’re hoping that the offline server more than compensates for a lack of a visible sync status for individual devices.

4

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.

5

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.

6

To really belabour the analogy… (But hey, here’s Tasting history on the second class experience)

For more news, subscribe!

Updated: