Customer Experience Program
And now something that I expect to cause controversy… The Customer Experience Program. Users of many programs, including WinZIP, MS Office, and Solid Works, have probably seen the installers ask for permission to share your usage data with the company. Until the last few weeks I considered this an imposition and generally didn’t participate.
Now that I’ve seen evidence that my development efforts are not exactly aligned with the day-to-day behavior of my users, I see the point of these feedback programs. Very few users give feedback so it’s difficult to get a information about what they want. In retrospect I see lots of wasted development time that could have gone into more desirable features.
Moving forward, MeshCAM will give you the option of participating in a program to send usage data back up to my server so I can see what functions and commands are used most often. Development on V4 development should be much quicker if I can focus my efforts only on what people actually use- and maybe phase out the features that are not.
The data sent back is a list of commands used and some file data like the number of triangles an STL when it’s loaded- there is NO personal data and nothing that can be mapped back to a particular user. There is nothing sent that contains any part of your name or registration code. Further, all data is held in an “analytics” directory in plain text so it can be reviewed. It is transmitted as plain text so someone could confirm that the transmitted data matches the recorded data. Transmission takes about 1-2 seconds on shutdown.
You will be able to opt out of the program but I would hope that everyone would choose not to- this is the best way to collect the data that I need to make the program more relevant to it’s users.
So my question for you all, does the brief text in the installer pane below give enough information to encourage someone to opt it? If you are the type that would generally not participate in these, would the text below sway you? If not, what would?
Robert, there’s a whole lotta whitespace in your dialog box–probably enough to include the whole fourth paragraph of your blog posting (“The data…on shutdown.”) which is an excellent description. Knowing those details I’ll even opt in, though I might skew the data curve a bit…
BTW I assume “on shutdown” means on MC shutdown and not PC shutdown?
Randy
Robert,
I have no problems with the concept although I might be twisting the data as much as Randy.
Get too many of us and the data will have no basis in reality
jeffD
I occurred to me when I was writing the code that If I look that the size of the STL I would immediately be able to find the two of you.
-Robert
Doctor: Mr. Gordon-Gilmore, your HDL and LDL levels are within normal limits, but your STL level is way off the chart…
Randy
From my experience from the software trenches, i.e. from the developer side, these kind of feedback systems don’t really get you the valuable info(feedback) that we are expecting.
And the reason is simple, we can only log, what we expect, and not the unexpected.
Another factor, that makes this info not so valuable, is the fact that it’s completly out of context.
From my experience, it’s a lot better to supply and support a direct connection from the application, so the user can report problems directly, when they occur.
If the user is really interested, he will imput valuable feedback, to contextualize the error or situation he found.
Better yet, is to support a live connection to support, directly inside the aplication, like a chat, or the best a graphical application view (remote support). However, this takes a heavy toll on support, specially on small teams, worse in one man teams, including discrepancy of users in this global market, where half the world is sleeping when the other half is awake.
Check out DBSchema (http://www.dbschema.com), and see the “report bug” feature, for an example.
User can report a problem, and automatically include a part of the application log, that is clearly visible and can even be edited, if you think there is something that shouldn’t be sent.
Rui-
Very true. I expect to only turn this on for a while just to see what’s going on. 4th axis is a good example of a feature that I have little information about- are people using it? Are the people using it trial users that are not buying because it’s not feature-rich enough? Are people using the waterline and pencil toolpaths or just using parallel because they’re easier to understand?
I want the typical MeshCAM usage to be completely streamlined and then make sure that the unused functions are moved out of the way.
I consider this to be a way to figure out what commands and functions are being used but I do not expect to get any context out of it. I like your idea and that may be a better long-term strategy to help with support and feedback and to get that missing context.
-Robert
I Robert
A I said before, You can find out for example that people are not using Waterline, or some other feature, as mcuh as you expected, but the fact is that you don’t know why that happens !
You can only guess.
It can be a million things!
- It can be harder to understand.
- It can be named and presented in such a way that people get it differently than what it is, so they fail to use it.
- It can have a bug making it unusable.
- Some user CAM jobs, may never required a specific operation.
- Some users, may prefer one operation over the others, due to the finish it provides, or time it takes to compute, or some other factor.
And what is worse in all this guessing work, is that, the least used feature, might be what the users what most, and vise versa.
And there is no way to know, except asking the users.
By the way, another option for feedback, is to make available a poll, eiter on the website or/and inside the application.
However, note that you must be careful how you phrase the question, or the results may give you meaningless info too.
Posted again, to correct spelling errors.
As I said before, You can find out for example that people are not using Waterline, or some other feature, as much as you expected, but the fact is that you don’t know why that happens !
You can only guess.
It can be a million things!
- It can be harder to understand.
- It can be named and presented in such a way that people get it differently than what it is, so they fail to use it.
- It can have a bug making it unusable.
- Some user CAM jobs, may never required a specific operation.
- Some users, may prefer one operation over the others, due to the finish it provides, or time it takes to compute, or some other factor.
And what is worse in all this guessing work, is that, the least used feature, might be what the users want the most, and vise versa.
And there is no way to know, except asking the users.
By the way, another option for feedback, is to make available a poll, either on the website or/and inside the application.
However, note that you must be careful how you phrase the question, or the results may give you meaningless info too.
Rui, there can also be reasons people [i]are[/i] using a feature. Now that we have a handle on doing 2.5D work with MC, I think a lot of people (based on the frequency of “how do I do this 2.5D part” questions on the forum) will be using it, but not for the same reason that 3D people are…
Randy
Robert,
As said before I have no concerns about the use of snooping, gawd only knows how many programs do it. Daily boot and I have to send a bunch of them to hell.
I am quite concerned about dropping MC features. I might use something once a year but I like to be able to depend on it being there. The code is done and works, hide it on the UI under a twisted_user or rabid_ferret menu. Some of us would really appreciate it.
jeffD
Jeff, I think I prefer the term “technologist adventurer” over “twisted user”, thank you.
Randy