Add more preferences

[kadet1090]

Refactor for preferences and additional tracking of:

• Selected sketcher settings:
  • Dimensioning tool preference
  • On-View Parameters preference
  • If Unified Coincident and PointOnObject constraint is enabled
  • If Auto horizontal / vertical tool is enabled
• Panel (Task View, Tree View etc) settings:
  • If panel is enabled
  • If it is placed in overlay mode, if so where
  • If transparency is enable
  • Width/Height of the panel

[maxwxyz]

I'd like to see some more info about

• Background color and setting (solid color / gradient)
• Is there an info on when the user installed this version of FreeCAD?
• Is there an info if the user had a previous version, if so which was the first on the system? I guess the config files get stuff added with every version
• what about the config files? Or do they consist of personal data?
• Toolbar icon size
• Any installes preference packs?
• Can we get log warnings and errors that happened before a crash?
• Navigation style
• Default WB on start
• which WBs are enabled
• Sketcher Grid yes/no
• BIM ifc version
• FEM: which solvers are installed and enabled?
• ISO/ASME standard settings in TechDraw (Dimensions and line style)
• TechDraw default font
• TD multi selection mode enabled/disabled?
• TD has the user set default files for templates?
• TD dimensioning tools (single, both, separate)

@FreeCAD/cad-advisory-group any other info regarding user workflow and standards which would be interesting?

[kaiwas]

Please add another option to choose the default behavior for, link copy on change (true/false)

[pierreporte]

@maxwxyz Your list seems fine. I don’t really have an opinion. It mainly depends on what developers need.

[maxwxyz]

@pierreporte IMO it is not solely directed towards developers. It helps to make UX decisions and gain knowledge on how people use FreeCAD.

[chennes]

* Background color and setting (solid color / gradient)

To do what with?

* Is there an info on when the user installed this version of FreeCAD?

I'm hesitant to go poking around in their filesystem for file modification dates. FreeCAD itself does not (intentionally) record that information. What would you do with it?

* Is there an info if the user had a previous version, if so which was the first on the system? I guess the config files get stuff added with every version

We don't track this.

* what about the config files? Or do they consist of personal data?

They contain personally-identifiable information. Only selected preferences will be transmitted.

* Toolbar icon size

To do what with?

* Any installes preference packs?

We are sending a list of Addons, which will include Preference Packs, and we send the current active theme, which may be from a PP.

* Can we get log warnings and errors that happened before a crash?

No. That will require cooperation from the core of FreeCAD, and we are not going to put telemetry in there right now. Eventually we'd like to incorporate Sentry into our workflow to analyze crash data, but it will require careful navigation of privacy concerns.

* Navigation style
* Default WB on start
* which WBs are enabled

These seem fine.

* Sketcher Grid yes/no
* BIM ifc version
* FEM: which solvers are installed and enabled?
* ISO/ASME standard settings in TechDraw (Dimensions and line style)
* TechDraw default font
* TD multi selection mode enabled/disabled?
* TD has the user set default files for templates?
* TD dimensioning tools (single, both, separate)

This is getting into a pretty detailed picture of the user. What would you use each of these pieces of information for? Although we are operating with Consent as our lawful basis for GDPR, I'd still like to ensure we would also be covered by Legitimate interests, so every piece of data we collect should have a use case: if you knew the distribution of each of the above pieces of information, what would you do with that knowledge?

[maxwxyz]

Basically to know how the users are working with FreeCAD to make better decisions about future UX changes and feature priority which are not based on the loudest complaints of forum users but the majority of FreeCAD users. Of course they are all nice to have and not necessary info.

• Background color: to know how many change it to a custom one and not use the theme default and to know whether the shades are in general light or dark so we know how the geometry appearance on default should be to adjust defaults.
• Toolbar icon size: to know what is the most common icon size and how it is distributed in the userbase

[chennes]

* Toolbar icon size: to know what is the most common icon size and how it is distributed in the userbase

Which information we would then use to...

[obelisk79]

If we want to use telemetry to understand how users are interacting with the software, most of the requests seem... ok-ish. But perhaps we should have a joint conversation between the CWG and DWG to target specific facets of FreeCAD and then add the telemetry targeting that area?

For example, if we decide improving draft is a target. We would collect specific data about that, WB and then parse the data to extrapolate potentially useful datapoints. This shouldn't be a kitchen-sink approach for the time being.

I agree with Kadet's request for data. I would add a request for data indicating active workbench, as well as frequency and possibly order of functions used. This data could be used to help determine if certain functions need to be exposed at a surface level or could be nested away elsewhere within the interface as toolbar Compound toolbuttons, or integrated into relevant task panels, etc. I think keeping the telemetry simple in scope is better than a massively broad recording of properties and params.

[chennes]

Right now we have to focus on simple preferences: actual use data is going to require different instrumentation.

Even with preferences, we can't just take a "collect everything" approach: that will not be appreciated by the community whom we are trying to help. If you want a piece of data, document what you want to do with the information. We'll make that part of the public documentation. This helps keep us all focused on the big picture (and helps us confirm a "Legitimate interests" basis for the collection).

[maxwxyz]

As I understand it we need to collect the data upfront or is it possible as Joe mentioned to define a new use case (let's stick with improve Draft) and enable specific metrics for that? This would need that all users update the addon, right?

[chennes]

I'm not sure I understand the question, @maxwxyz. We could take a "collect literally everything we can think of right now just in case" approach, so that we never have to update the addon, but I don't think that's a very friendly way of operating. Updating addons is not terribly onerous. It might even provide us with an opportunity to encourage further participation by highlighting the current data collection focus in the first-start popup.

[kadet1090]

* Toolbar icon size: to know what is the most common icon size and how it is distributed in the userbase

Which information we would then use to...

... make decision about which icon size to optimize for. We cannot make icons that look good on 16, 24 and 32px because there is not enough common factors of these sizes to make sure that icons both have useful details and are crisp.

24px is widely used icon size in the internet and right now I'd say that it is de facto standard, but if we optimize for it they would look great on toolbars but icons in menus are 16px and will look blurred.

Background color could be used to decide if we want to care about "classic" color scheme as it is the most problematic to maintain because of a huge lightness difference across the gradienr

as well as frequency and possibly order of functions used.

That one we discussed that we can do based on collecting the count internally in FreeCAD and sending it once per month. We will know the frequency but not order which is good, as order of functions used can be considered as sending a bit too much information.

[obelisk79]

Updating addons is not terribly onerous. It might even provide us with an opportunity to encourage further participation by highlighting the current data collection focus in the first-start popup.

Intrusive thought/question: Since this is a telemetry addon, and internet connectivity is expected, could the addon collect data based on a github hosted file instead of local sourcing? ie, either read on launch, or create a local copy based on commit version and update based on detected change? This should be open and easily audited, but we should minimize any kind of interaction required by the user in terms of updating the full addon itself etc.

[kadet1090]

Technically? It could.

We should however not do that, as code can be inspected, users can review the addon before updating it etc, with file hosted on remote server and auto updating they cannot. No one likes stuff that is updating without their knowledge. If anything I'd push more towards general mechanism for automatic updates of addons within constraints of semantic versioning. Then we could simply encourage users to enable that option for telemetry - result would be the same but it won't be forced and people will not be worried that all of a sudden we will start to collect their private data.

I'm not even sure if it would be legal in EU to do so. You need to state stuff like this in privacy policy and list everything that is collected - if the set of collected things changes dynamically it is not possible to properly inform users about what is collected and what is not.

[obelisk79]

Reasonable concerns, like I said, just musing ideas.

[kadet1090]

Ok, I added changes that I think we can agree on. I split every category of preferences into own commit with short description on why that information is useful - if we decide that something is not needed it should be rather simple to remove.