New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Send current synthDriver name and brailleDisplay name to update server for stats gathering. #8217

Merged
merged 10 commits into from Jun 17, 2018

Conversation

Projects
None yet
8 participants
@michaelDCurran
Contributor

michaelDCurran commented May 1, 2018

Link to issue number:

None.

Summary of the issue:

Currently we have no idea what percentage of users use a particular synthDriver or brailleDisplay. This would be extremely useful data to better prioritize future work, including how much effort we put into eSpeak contributions for example.

Description of how this pull request fixes the issue:

Simply sends synthDriver name and brailleDisplay name as variables to the update server.
Eventually it would be nice if we could prepend the add-on name if there is one, but for now this at very least will give some much needed visibility for espeak usage.

Testing performed:

Instructed NVDA to check for update. Confirmed on the server that synthDriver name and brailleDisplay name were being gathered.

Known issues with pull request:

None.

Change log entry:

Changes:

  • When checking for updates, NVDA will now send the name of the current synth driver and braille display in use, to aide in better prioritization for future work on these drivers.

@michaelDCurran michaelDCurran requested a review from feerrenrut May 1, 2018

@michaelDCurran

This comment has been minimized.

Show comment
Hide comment
@michaelDCurran

michaelDCurran May 1, 2018

Contributor

A reminder that users can uncheck automatically check for updates in the General Settings, if they are uncomfortable with this data going to NV Access. But again, this data will greatly help us understand what we need to work on. There is no point putting large amounts of effort into eSpeak say if it was found athat only 10% of users actually use it.

Contributor

michaelDCurran commented May 1, 2018

A reminder that users can uncheck automatically check for updates in the General Settings, if they are uncomfortable with this data going to NV Access. But again, this data will greatly help us understand what we need to work on. There is no point putting large amounts of effort into eSpeak say if it was found athat only 10% of users actually use it.

michaelDCurran added a commit that referenced this pull request May 1, 2018

@leonardder

This comment has been minimized.

Show comment
Hide comment
@leonardder

leonardder May 1, 2018

Collaborator

As discussed last week, how about adding the output braille table as well while at it? Cc @bramd

Also, I wonder whether there any privacy concerns. I don't care at all for myself, other's might.

Collaborator

leonardder commented May 1, 2018

As discussed last week, how about adding the output braille table as well while at it? Cc @bramd

Also, I wonder whether there any privacy concerns. I don't care at all for myself, other's might.

@leonardder

This comment has been minimized.

Show comment
Hide comment
@leonardder

leonardder May 1, 2018

Collaborator

@michaelDCurran commented on 1 mei 2018 08:35 CEST:

A reminder that users can uncheck automatically check for updates in the General Settings, if they are uncomfortable with this data going to NV Access. But again, this data will greatly help us understand what we need to work on.

Would it help to have a section in the user guide that explicitly states what data is send to NV Access?

Collaborator

leonardder commented May 1, 2018

@michaelDCurran commented on 1 mei 2018 08:35 CEST:

A reminder that users can uncheck automatically check for updates in the General Settings, if they are uncomfortable with this data going to NV Access. But again, this data will greatly help us understand what we need to work on.

Would it help to have a section in the user guide that explicitly states what data is send to NV Access?

@Brian1Gaff

This comment has been minimized.

Show comment
Hide comment
@Brian1Gaff

Brian1Gaff May 1, 2018

Brian1Gaff commented May 1, 2018

@Brian1Gaff

This comment has been minimized.

Show comment
Hide comment
@Brian1Gaff

Brian1Gaff May 1, 2018

Brian1Gaff commented May 1, 2018

@PratikP1

This comment has been minimized.

Show comment
Hide comment
@PratikP1

PratikP1 May 1, 2018

PratikP1 commented May 1, 2018

@bramd

This comment has been minimized.

Show comment
Hide comment
@bramd

bramd May 1, 2018

Contributor

Sounds good to me. Braille output table is interesting as well, but only if we know the users' language/locale. So we should gather that as well if we don't already do that.

Regarding GDPR. I'm not a subject expert on the matter, but have lots of (government) clients who are really busy implementing GDPR measures right now, so I've heard a few examples there. Basically, it's best to ask consent for any data you want to gather and that could be qualified as personal data. Even an IP address seems to be classified as personal data as far as I know. Also, you need to be specific where the data is used for and it's not allowed to deny people functionality if they don't want to share their data. For example, if users don't agree to share their synth/braille display name, we might not ban them from getting updates automatically, since that data isn't strictly needed for the auto update function.

That being said, I don't know how it is if we aggregate the data directly after receiving it, so we can't see which specific person uses synth x. Since GDPR is a big issue in Europe right now it would be good to investigate if NVDA is GDPR compliant. That's outside the scope of this PR of course, but sooner or later European companies willing to use NVDA will request GDPR compliance.

Contributor

bramd commented May 1, 2018

Sounds good to me. Braille output table is interesting as well, but only if we know the users' language/locale. So we should gather that as well if we don't already do that.

Regarding GDPR. I'm not a subject expert on the matter, but have lots of (government) clients who are really busy implementing GDPR measures right now, so I've heard a few examples there. Basically, it's best to ask consent for any data you want to gather and that could be qualified as personal data. Even an IP address seems to be classified as personal data as far as I know. Also, you need to be specific where the data is used for and it's not allowed to deny people functionality if they don't want to share their data. For example, if users don't agree to share their synth/braille display name, we might not ban them from getting updates automatically, since that data isn't strictly needed for the auto update function.

That being said, I don't know how it is if we aggregate the data directly after receiving it, so we can't see which specific person uses synth x. Since GDPR is a big issue in Europe right now it would be good to investigate if NVDA is GDPR compliant. That's outside the scope of this PR of course, but sooner or later European companies willing to use NVDA will request GDPR compliance.

@michaelDCurran

This comment has been minimized.

Show comment
Hide comment
@michaelDCurran

michaelDCurran May 1, 2018

Contributor
Contributor

michaelDCurran commented May 1, 2018

@Brian1Gaff

This comment has been minimized.

Show comment
Hide comment
@Brian1Gaff

Brian1Gaff May 2, 2018

Brian1Gaff commented May 2, 2018

michaelDCurran added some commits May 2, 2018

When sending synth / braille driver names to the server for stats gat…
…hering, append either core, external or addon:addonName to better differentiate between the drivers.
Ask the user if they wish to allow sending usage data to NV Access. A…
…lso allow this to be configured from the General Settings tab. Document what data is sent in the userGuide. Also collect outputBrailleTable.
Show outdated Hide outdated source/logHandler.py Outdated
"installed": config.isInstalledCopy(),
"synthDriver":getQualifiedDriverClassNameForStats(synthDriverClass) if synthDriverClass else None,
"brailleDisplay":getQualifiedDriverClassNameForStats(brailleDisplayClass) if brailleDisplayClass else None,
"outputBrailleTable":config.conf['braille']['translationTable'] if brailleDisplayClass else None,

This comment has been minimized.

@feerrenrut

feerrenrut May 7, 2018

Contributor

Might be worth while adding a comment here to say that any additions must be added to the userguide.

@feerrenrut

feerrenrut May 7, 2018

Contributor

Might be worth while adding a comment here to say that any additions must be added to the userguide.

Show outdated Hide outdated user_docs/en/userGuide.t2t Outdated
Show outdated Hide outdated user_docs/en/userGuide.t2t Outdated
Show outdated Hide outdated user_docs/en/userGuide.t2t Outdated
Show outdated Hide outdated user_docs/en/userGuide.t2t Outdated
@michaelDCurran

This comment has been minimized.

Show comment
Hide comment
@michaelDCurran

michaelDCurran May 7, 2018

Contributor

I'm wondering about the yes no dialog on start-up. Is it too easy to dismiss in the affirmative? Perhaps the focus should default to the No button? But then I feel that can heavily bias the question. I'd really prefer that the focus be on neither... like... a cancel button? Then they'd be asked again the next time?

Contributor

michaelDCurran commented May 7, 2018

I'm wondering about the yes no dialog on start-up. Is it too easy to dismiss in the affirmative? Perhaps the focus should default to the No button? But then I feel that can heavily bias the question. I'd really prefer that the focus be on neither... like... a cancel button? Then they'd be asked again the next time?

@feerrenrut

This comment has been minimized.

Show comment
Hide comment
@feerrenrut

feerrenrut May 7, 2018

Contributor

I'd really prefer that the focus be on neither... like... a cancel button? Then they'd be asked again the next time?

Yes, but perhaps "Ask later" or similar, rather than "cancel".

I am also a little worried about introducing multiple dialogs on startup. It could complicate things, but perhaps combining this with the welcome dialog when the welcome dialog is going to be displayed, and showing this prompt independently when the welcome dialog is not shown?

Contributor

feerrenrut commented May 7, 2018

I'd really prefer that the focus be on neither... like... a cancel button? Then they'd be asked again the next time?

Yes, but perhaps "Ask later" or similar, rather than "cancel".

I am also a little worried about introducing multiple dialogs on startup. It could complicate things, but perhaps combining this with the welcome dialog when the welcome dialog is going to be displayed, and showing this prompt independently when the welcome dialog is not shown?

@leonardder

This comment has been minimized.

Show comment
Hide comment
@leonardder

leonardder May 7, 2018

Collaborator

@feerrenrut commented on 7 mei 2018 08:45 CEST:

I am also a little worried about introducing multiple dialogs on startup. It could complicate things, but perhaps combining this with the welcome dialog when the welcome dialog is going to be displayed, and showing this prompt independently when the welcome dialog is not shown?

Hmm, I agree with having multiple prompts introducing more complexity, so I'd just add the prompt to the welcome dialog. We could use a config profile upgrade step to enforce the welcome dialog showing up again.

Collaborator

leonardder commented May 7, 2018

@feerrenrut commented on 7 mei 2018 08:45 CEST:

I am also a little worried about introducing multiple dialogs on startup. It could complicate things, but perhaps combining this with the welcome dialog when the welcome dialog is going to be displayed, and showing this prompt independently when the welcome dialog is not shown?

Hmm, I agree with having multiple prompts introducing more complexity, so I'd just add the prompt to the welcome dialog. We could use a config profile upgrade step to enforce the welcome dialog showing up again.

@michaelDCurran

This comment has been minimized.

Show comment
Hide comment
@michaelDCurran

michaelDCurran May 7, 2018

Contributor
Contributor

michaelDCurran commented May 7, 2018

@leonardder

This comment has been minimized.

Show comment
Hide comment
@leonardder

leonardder May 7, 2018

Collaborator

Hmm, I think you have a valid point here.

Now, there are more things I could think of that at some point could end up in the welcome dialog, such as the possibility to enable or disable braille display auto detection. This might require the welcome dialog to become a multi step dialog and behave more like a wizard.

Collaborator

leonardder commented May 7, 2018

Hmm, I think you have a valid point here.

Now, there are more things I could think of that at some point could end up in the welcome dialog, such as the possibility to enable or disable braille display auto detection. This might require the welcome dialog to become a multi step dialog and behave more like a wizard.

@feerrenrut

This comment has been minimized.

Show comment
Hide comment
@feerrenrut

feerrenrut May 7, 2018

Contributor

Trying to introduce this question into the welcome dialog also brings the danger that the question is hidden from the user. A user is unlikely to carefully inspect all options in the welcome dialog.

Mick, after considering this, I agree we should leave it as is.

Contributor

feerrenrut commented May 7, 2018

Trying to introduce this question into the welcome dialog also brings the danger that the question is hidden from the user. A user is unlikely to carefully inspect all options in the welcome dialog.

Mick, after considering this, I agree we should leave it as is.

@michaelDCurran

This comment has been minimized.

Show comment
Hide comment
@michaelDCurran

michaelDCurran May 7, 2018

Contributor
Contributor

michaelDCurran commented May 7, 2018

@feerrenrut

This comment has been minimized.

Show comment
Hide comment
@feerrenrut

feerrenrut May 7, 2018

Contributor

Ahhh. Yes. Sorry, I must have been tired when I wrote that. I think it's important to be able to dismiss the dialog without making an explicit decision.

Contributor

feerrenrut commented May 7, 2018

Ahhh. Yes. Sorry, I must have been tired when I wrote that. I think it's important to be able to dismiss the dialog without making an explicit decision.

@michaelDCurran michaelDCurran requested a review from feerrenrut May 10, 2018

Show outdated Hide outdated source/gui/__init__.py Outdated
Show outdated Hide outdated source/gui/__init__.py Outdated
Show outdated Hide outdated source/gui/__init__.py Outdated
Show outdated Hide outdated source/gui/__init__.py Outdated
Show outdated Hide outdated source/gui/__init__.py Outdated
Show outdated Hide outdated source/gui/__init__.py Outdated
Show outdated Hide outdated source/gui/__init__.py Outdated
Show outdated Hide outdated source/core.py Outdated
Show outdated Hide outdated source/gui/__init__.py Outdated
@michaelDCurran

This comment has been minimized.

Show comment
Hide comment
@michaelDCurran

michaelDCurran May 14, 2018

Contributor
Contributor

michaelDCurran commented May 14, 2018

@feerrenrut

This comment has been minimized.

Show comment
Hide comment
@feerrenrut

feerrenrut May 14, 2018

Contributor

Ah yes, I see. I missed the id change for that button. Could you add comment to that effect to that line, just to make it clearer why there is inconsistency with the others. Something like: "evt.Skip() is called since wx.ID_CANCEL is used as the ID for the Ask Later button, wx automatically ends the modal itself."

Contributor

feerrenrut commented May 14, 2018

Ah yes, I see. I missed the id change for that button. Could you add comment to that effect to that line, just to make it clearer why there is inconsistency with the others. Something like: "evt.Skip() is called since wx.ID_CANCEL is used as the ID for the Ask Later button, wx automatically ends the modal itself."

@feerrenrut

Looks good

michaelDCurran added a commit that referenced this pull request May 15, 2018

@@ -633,6 +633,12 @@ def makeSettings(self, settingsSizer):
if globalVars.appArgs.secure:
item.Disable()
settingsSizerHelper.addItem(item)
# Translators: The label of a checkbox in general settings to toggle allowing of usage stats gathering
item=self.allowUsageStatsCheckBox=wx.CheckBox(self,label=_("Allow the NVDA project to gather NVDA usage statistics"))

This comment has been minimized.

@leonardder

leonardder May 16, 2018

Collaborator

I actually think it makes sense to reposition this checkbox after the notifyForPendingUpdateCheckBox. The current order of check boxes is a bit arbitrary now.

@leonardder

leonardder May 16, 2018

Collaborator

I actually think it makes sense to reposition this checkbox after the notifyForPendingUpdateCheckBox. The current order of check boxes is a bit arbitrary now.

@michaelDCurran michaelDCurran requested a review from leonardder May 16, 2018

@netblue44

This comment has been minimized.

Show comment
Hide comment
@netblue44

netblue44 May 18, 2018

netblue44 commented May 18, 2018

@bramd

This comment has been minimized.

Show comment
Hide comment
@bramd

bramd May 18, 2018

Contributor
Contributor

bramd commented May 18, 2018

@netblue44

This comment has been minimized.

Show comment
Hide comment
@netblue44

netblue44 May 18, 2018

netblue44 commented May 18, 2018

leonardder added a commit that referenced this pull request May 21, 2018

Incubates #8217.
Merge remote-tracking branch 'origin/pr/8217' into next

@michaelDCurran michaelDCurran merged commit e791c8d into master Jun 17, 2018

1 check passed

continuous-integration/appveyor/pr AppVeyor build succeeded
Details

@nvaccessAuto nvaccessAuto added this to the 2018.3 milestone Jun 17, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment