There will simply be a new Option somewhere (to be chosen) which asks (like so many software apps do nowadays) as to whether you'd like to provide 'user experience' data, or some other term for the feedback.
The user selects Yes or No, and that's it. There is no further user involvement - ever.
Nothing in the user interface changes. Nothing for the user 'to do'. No personal identification at all is included, or where the data came from, even after I receive the data. No usage whatsoever of the user's EMail ID / pswd etc. No visual indication at all that this collection is happening.
So what is there "not to like"? And if the user is still concerned, simply say NO.
Your proposal has user involvement everywhere and puts the onus on THEM to make this happen. Why is this better?
I agree with Robert that this kind of 'spying' is likely to be viewed with suspicion. I habitually deny such requests for 'data for quality improvement purposes'. I also dislike products writing stuff to my drive over which i have no/little control.
I can see the attraction of linking this to Forum users.
Afterall, members of the forum most likely have a 'closer' relationship with SPFLite than non-members, and so are more likely to agree to upload data.
However, there are probably many more users of SPFLITE than there are members on this forum, and thus you could be missing out on a whole bunch of "usage-patterns".
I offer some thought below, but I think this is getting a bit too involved.
Perhaps an alternative is to pop-up a panel at installation time, advertising those 'features/aspects' of the product which are "candidates for retirement/removal" and giving users a link to this forum (or an email address) where they can voice their objection. Combined with some kind of 'there's a newer version available' check at startup, this could be just as effective and require less effort on your part.
If you want to go the automated route, my thoughts are....
I think you probably also won't want the process to go on ad infinitum.
Once you have a reasonable representative sample of which features of the product are used/unused, you could stop/prevent further data collection.
You could disable data collection after a specific number of collections have occurred and re-enable collection after a specific amount of time has elapsed.
You may need to introduce a "session count" so you can tell how 'busy' the product is with a particular user - could be they don't use SPFLite a lot and hence their "tracked-feature" count is low.
The upload process (if user permitted) should probably run automatically and should probably clean up the data capture file(s).
Perhaps upload would be triggered when a given number of data collections have occurred and/or in relation to the "session count".
Since you can probably only change the behaviour at installation time, you'd may need to issue an update to change the parameters, time periods, aspects to be tracked, etc..
To ensure that users perform such update in a timely manner, you may need a 'new version check' routine during the dtart-up/initiatlisation process - perhaps once a month.
Perhaps the approach ought to focus on specific product 'aspects', ie. those which you think may be candidates for removal, rather than tracking all features.
There definitely should be an 'Allow/disallow upload' switch, probably on the OPTIONS GENERAL or CONFIG page.
You may need two settings for this - one to permit data collection, another to permit data upload.
In addition, you probably need a pop-up at instalation time, which should:
- explain the concept's rationale and which 'aspects/features' are being tracked
- explain when and how frequently then data will be uploaded.
- show where the collected data files are kept and how to view them (so users can be comfortable with what's being captured)
- remind them that they can change their mind at any time via the OPTIONS dialog
- request permission (YES/NO) - perhaps collection default is YES and upload default is NO so users can see what's being collected.
Stefan: Well, I tried to make this as simple and unobtrusive as possible, no user required activities, and with a simple YES/NO so users who are more security concerned can simply turn it off.
My feeling is that if users are expected to 'DO' something to make it work, it is doomed. Whether that is via the Forum or by uploading/sending data manually makes no difference. Over the years it has become blatantly obvious that users provide basically nil feedback. It's been tough to even get them to report bugs. As you said, getting users to assist is just 'too involved'.
Being honest, I truly expected this kind of push-back, that's why I posed the question on the forum. I think I'll leave the data collection in place (it's done, it works and the data is kept in the CFG file) and just cripple the whole contentious data shipment portion.
Maybe I'll put back the checking and notification of new releases. It was removed back when SPFLite went GPL3 and I didn't want a dependency on the WWW.SPFLite.COM website.
So why not go with issuing a message on install with a URL link to your website where new features, changes, and items to be discontinued are listed/described as well as how to provide feedback if they object. This points them at the forum or perhaps an email adress. If they don't they don't feel strongly about it.
If you don't hear from anyone you go ahead and modify the code.
Combine it with a "new version available" check so you can be sure folks get to see the notifications. If folks do not upgrade they've made their choice already.
OK, because of the concerns expressed here, how about the following:
There will be no automatic creation of the Usage statistics, if users do nothing, I will effectively get no feedback.
The creation of the Usage data file would be done by the CFGMaint utility. It will create a unique CSV (comma separated values) file in the normal SPFLite Data folder. I'll add a new -USAGE command line operand to trigger this. It should take only a second or two to run.
The user can review this data file at leisure to ensure there is no personal information included. I will document the contents, although they are in plain text and pretty obvious.
Then hopefully (for me) they can send the data file via email to the normal Support@SPFLite.com address. The file can be deleted at that point.
Also hopefully, this could be performed periodically (like every few months)
At the same time I plan to re-introduce the periodic checking for a new SPFLite version. This will encourage users to remain more current. Again, this will be defaulted to OFF mode.