Don’t worry we are not add telemetry to the core software!
In the ongoing conversations about homing the microscope. We mentioned how it would be nice to monitor how the home position “drifts” over time (due to things like missed steps).
This took us towards an off-topic discussion of telemetry as and add on:
To stop us derailing that thread I have moved the conversation here!
Updates are a huge issue. I think and update interface in the software and an add-on manager would be great additions. They are the sort of non-academia type UI/UX improvements we need to think of a good path for how to fund. Part of this would be ensuring that this can also update the Sangaboard firmware.
If we had an add-on manager this would create an easy path for letting people install a theoretical telemetry add on.
I can imagine a UI for it where you select what sort of data you send back. Obviously we are not going to sending back images, but there are probably different types of data people may or may not want to send. As it is entirely opt-in via download I think it gives potential to learn about how the UI is used, and which features are used.
How we store that data, what data we would like, how we ensure it is properly anonymous, and how open that data set should be are detailed questions we would need before we started. This to me sounds like it would want to be set out in an OFEP.
Upgrades: I think the quickest way to something manageable would be an easy way to export all the settings/data, then re-image the SD card, then re-apply the settings. It’s not as elegant as an in-place upgrade, but would be much easier to implement reliably. Upgrading the Python code in-place is possible, but you’ll then end up with microscopes where the Python is out of sync with the system requirements, which is a support burden we could probably do without…
Telemetry: There are definitely places where collecting telemetry would be helpful. Some of these are obvious points in time where the user could be prompted (e.g. after you’ve completed a hypothetical first run calibration wizard, we could ask if the user would like to upload the calibration and get a certificate). I think that can probably be done in a sufficiently clear and transparent way to make it into the core software, but I agree we should set out what and why in an OFEP and leave space for a discussion. As for collecting ongoing usage data, that would be interesting, but I agree it probably wants to be opt-in and if we can avoid any telemetry code being bundled unless it’s asked for, that would be cleanest by far.
An issue is that, at present, the extension mechanism really only works for server-side stuff in v3: adding UI extensions is not something I’ve dealt with yet. If anyone with Vue.js experience wants to help with that, I’m all ears…
But the server side extensions can create a UI? Are you saying that in the new software they can’t, or that you want a second type of extension that is JS only?
In v3, I have not yet ported over the ability of server-side extensions to display a UI. Clearly something in that direction would be useful, but it’s not yet made it onto my critical path…
also, depending on what telemetry might mean, v2 of the software is fairly limited in what extensions can do: they can display a simple form or an iframe, but adding in javascript to affect what happens on other tabs is deliberately quite complex. The closest thing to a UI plug-in we have is the ImJoy integration, which is just a part of the Vue application - there’s no neat modular loader for it.
To be clear, I’m not saying I’m against a nice UI plug-in architecture (or giving server-side extensions the ability to alter the UI), it’s just not something I’ve been able to give any time to yet.
I wouldn’t think we would want custom JavaScript to watch the user. Or to have the ability to mess with other tabs. A simple form could easily set what is monitored, if an addon is installed.
I see no reason the add on needs to do anything else client side. Server side we know when UI features are used if they trigger a server endpoint. This will all be monitored by the python logging module. A telemetry add-on could subscribe to the logging feed, filter based on form options, and have a way to post that data elsewhere.
That makes a lot of sense. Particularly once we’ve cleaned up our logging, which is something we should be doing anyway. I wondered if you meant telemetry specifically on the UI (like when and how the user is interacting with different elements) but perhaps I was getting carried away there. The approach I’ve taken so far is to put UI stuff into the Vue app, but hide it if the server-side Thing is not present. This isn’t wonderfully scaleable, but works for now. I think we could still say with a clear conscience that there’s no logging code, even if there’s a form available to control a logging Thing, provided said Thing isn’t installed by default.
The only issue with doing telemetry on the server side is that many microscopes are (and should be) running without an internet connection: uploading data would be done most easily by presenting it to the user (who’s probably running it from a machine with a connection to the microscope and a separate connection to the internet) and uploading it from there. Doing that neatly wouldn’t be trivial, but I hope it is possible. It might require the user to be at least a bit “in the loop” when we phone home, but that’s not necessarily a bad thing.
I think that starts to get creepy!
That is certainly from a data sensitivity point of view, but perhaps more annoying from a user perspective. Food for thought.