3 ms·

> telemetry is useful I'm just going to point out that you accused privacy advocates of magical assertions, then did the same thing :) (there is a point of vi

by cmsj 5y ago

> telemetry is useful I'm just going to point out that you accused privacy advocates of magical assertions, then did the same thing :) (there is a point of view which says that you make good products through thoughtful and rigorous design, rather than pouring over databases of events to try and reverse engineer how people are actually using your product)

notatoad 5y ago
as a developer, i find crash reports helpful when troubleshooting issues, and use device metrics like screen size to determine where to focus limited developer efforts. telemetry is useful because i use it. that's not a magical assertion.
vhanda 5y ago
Some ways in which telemetry can be useful - * Figuring out which features are not being used, and being able to change things according. This also covers UI decisions - Oh. We added this new toolbar. Is anyone actually using it? * Prioritizing localizations of a particular country / language. * An actual positive feedback loop for products that don't generate revenue. Most open source project maintainers just receive bug reports, feature requests, and sometimes hate mail. Telemetry information which roughly shows that even though there are some people complaining loudly about the software, there are 50k other users happily using it, is very very motivating. * Crash reporting / exceptions monitoring - Bugs are inevitable, and this gives so so much information. In my experience, very few users actually report bugs. Many might even just rate your app badly, and then ignore any attempts at following up. Especially cause they have deleted the app.
fouric 5y ago
> there is a point of view which says that you make good products through thoughtful and rigorous design, rather than pouring over databases of events to try and reverse engineer how people are actually using your product There are two problems with this view. The first is that it's generally user-hostile. If you're meaning your software to be useful to users, then you need to see what your users' needs are, and how they're actually using your software - not how you think they should be. There are people who design pieces of software that are meant to be opinionated, beautiful gems that are not meant to be used by others (which includes software that pays lip-service to users but is so user-hostile that it's effectively not for them anyway) - and telemetry, crash reports, auto-updates, and more generally a feedback loop from user to developer are not for them. The second is that it requires a lot of discipline. Look at how user-hostile most applications (both open-source and proprietary) are anyway - do you really think that their developers are going to have the discipline to carefully engineer a good user experience? As an idealist, I wish that they did, but as a realist, I know that in most cases that will never happen, and so telemetry and crash reports (crashing is part of a bad user experience) will get you a slightly better piece of software than nothing at all.
- pseudalopex 5y ago
  The problem with telemetry is it doesn't tell you what users' need are. It tells you what they do with their software. Not why. Not how they feel about it. Not what they wish it would do. Thoughtful and rigorous design includes user research and testing. In my experience it takes more discipline to use telemetry responsibly. I've seen equivalent data used to justify removing 1 feature and making another more prominent. It seems to go hand in hand with UI churn. And it seems to lead to dismissing user feedback. Crash reports and event streams are different. But there's no reason not to ask consent anyway.

by cmsj 5y ago

notatoad 5y ago

as a developer, i find crash reports helpful when troubleshooting issues, and use device metrics like screen size to determine where to focus limited developer efforts. telemetry is useful because i use it. that's not a magical assertion.

vhanda 5y ago

Some ways in which telemetry can be useful - * Figuring out which features are not being used, and being able to change things according. This also covers UI decisions - Oh. We added this new toolbar. Is anyone actually using it? * Prioritizing localizations of a particular country / language. * An actual positive feedback loop for products that don't generate revenue. Most open source project maintainers just receive bug reports, feature requests, and sometimes hate mail. Telemetry information which roughly shows that even though there are some people complaining loudly about the software, there are 50k other users happily using it, is very very motivating. * Crash reporting / exceptions monitoring - Bugs are inevitable, and this gives so so much information. In my experience, very few users actually report bugs. Many might even just rate your app badly, and then ignore any attempts at following up. Especially cause they have deleted the app.

fouric 5y ago

> there is a point of view which says that you make good products through thoughtful and rigorous design, rather than pouring over databases of events to try and reverse engineer how people are actually using your product There are two problems with this view. The first is that it's generally user-hostile. If you're meaning your software to be useful to users, then you need to see what your users' needs are, and how they're actually using your software - not how you think they should be. There are people who design pieces of software that are meant to be opinionated, beautiful gems that are not meant to be used by others (which includes software that pays lip-service to users but is so user-hostile that it's effectively not for them anyway) - and telemetry, crash reports, auto-updates, and more generally a feedback loop from user to developer are not for them. The second is that it requires a lot of discipline. Look at how user-hostile most applications (both open-source and proprietary) are anyway - do you really think that their developers are going to have the discipline to carefully engineer a good user experience? As an idealist, I wish that they did, but as a realist, I know that in most cases that will never happen, and so telemetry and crash reports (crashing is part of a bad user experience) will get you a slightly better piece of software than nothing at all.

pseudalopex 5y ago
The problem with telemetry is it doesn't tell you what users' need are. It tells you what they do with their software. Not why. Not how they feel about it. Not what they wish it would do. Thoughtful and rigorous design includes user research and testing. In my experience it takes more discipline to use telemetry responsibly. I've seen equivalent data used to justify removing 1 feature and making another more prominent. It seems to go hand in hand with UI churn. And it seems to lead to dismissing user feedback. Crash reports and event streams are different. But there's no reason not to ask consent anyway.