Improve published telemetry data

[mrlacey]

Is your feature request related to a problem? Please describe.

The published telemetry data presents incomplete and potentially misleading information. Improvements could make it more useful for the core team to use the information in evaluating and prioritizing changes. It would also be more useful to interested other parties. While the current information is not deliberately misleading it requires extra effort to understand and it is not always obvious where it is using incomplete data.

Describe the solution you'd like

1. Include a breakdown on number of pages added when generating each app.

The published data lists a breakdown of which pages are included most frequently but no indication of how many pages are included in each generate app. Knowing this could help in decisions related to future design changes for the wizard. For example, if it became clear that most apps generated have no more than 3 pages the design could be optimized to allow for this.

2. Do not include hidden features in feature breakdown.

The breakdown of features (example) includes items (e.g. Sample Data) that are hidden in the UI. By including them in the figures it distorts the representation of what people are actually selecting. This could lead to some items appearing less popular than they are.

3. Indicate when no features/services/testing options are selected.

The current WPF Services data suggests that 58% of apps include Optional Login and 42% include Forced Login. However, as this doesn't allow for apps that include neither of these options. Having details about such apps would help prioritize decision making. For example, if most apps do include one of these options it might justify spending time improving them. If very few apps include either of these options it might prompt a need to investigate why and/or find out if alternatives would be more useful/desirable.

As with the above suggestion for publishing details of page counts, having such values for how many features, services, and testing options are included in each generated app will provide a much clearer picture of how WinTS is used. This knowledge can help improve decision making related to future changes.

Without knowing the actual figures it is not possible to provide a best solution for how to display this information. An average (mean/mode/median) may be enough. Percentile based values may work better. Or percentages for individual values (with groupings if necessary) may be better for some data too.

4. Don't combine language data from all frameworks. Break it down on a per-framework basis for those frameworks that support multiple programming languages.

The current data show a breakdown between C# and VB for all UWP & WPF template usage but the WPF templates do not support VB. The result of this is that the VB usage figure looks artificially low. Without carefully considering the source of these figures it could be easy to assume the low figure justifies less future investment.

If not altered this will also introduce misleading values for C++ when support for WinUI3 templates with that language are introduced.

Describe alternatives you've considered

There are no alternatives as the information is not available elsewhere.

Additional context

Applies to the following platforms:

UWP	WPF	WinUI
Yes	Yes	Yes

[sibille]

Those are great suggestions. I think we have the data to provide this info. Adding to the backlog, we'll come back to this once the work for WinUI3 and milestone 3.10 is finished.