Statistics on plugin users
-
Talking about gathering people's data on a whole different scale... last week three firms with in total 160 computer shops all over the Netherlands were exposed tracking smartphone mac addresses, wifi, Bluetooth and infrared data. They collected data of people entering their shops and of every passer by.
Their response: we need this info for optimizing planning the amount of assistants in shops.
I don't get why at no point no-one didn't think this was sneaky and not the way to go...
-
We know when you download something.
We know what version of SketchUp you use.
We know your computer ID for displaying per device installs.
We know what you rated.
We know when you login.
We don't know when you turn on the tool. Apache server does keeps logs (up to 4 weeks) of activity but we don't use this for data collection. If we do need to use the Apache logs it is only for debugging an error. Which is rarely done.
So in terms of data collection the My profile tab is displaying the majority of the info collected.
If we introduced something that tracks usage it would be done in a fashion that Plugin Authors would need to inject code into their plugins to make use of it. I see no benefit in us knowing when you use TIG's Mirror tool when you are on holidays in Barbados.
I do see a benefit in providing Plugin Authors info on usage especially when that is used to further the development of a tool as in Jiminy's example earlier. But ideally that side of things should be developed within the spirit Plugin ecosystem that evolved here.
We could develop our API to allow cool things to happen based on the info about each plugin uploaded to the store. Try this for instance...
apicall=String.new("http://plugin.sketchucation.com/api.php?") apicall.concat("APIVERSION=1") apicall.concat("&APIKEY=test") apicall.concat("&CALLINGPLUGIN=testWidget") apicall.concat("&COMMAND=get_download_count") apicall.concat("&PLUGIN_ID=Layers_Panel") dlg = UI;;WebDialog.new("SketchUcation API", true, "SketchUcationAPI", 100, 100, 150, 150, true); dlg.set_url apicall dlg.show dlg.add_action_callback("api_reply") {|dialog, params| UI.messagebox params.to_s }
...it returns the download count of Jiminy's Layers Panel tool. Pretty useless huh?
But the possibilities are pretty immense if we could get Authors to adopt to a set convention.
-
@kaas said:
My problem with handing over additional info in general is that privacy apparently is of no concern anymore to anyone. Firms, governments and some programmers apparently have no moral problem with collecting any data they can at any time. I really don't like this kind of thinking. If you need to know something for bug fixing or you are curious in general, just ask or start a poll but don't just take it and bury it in (lots of) disclaimers nobody reads anyway.
In Layers Panel, it is completely anonymous. I can't track a user in any way. I can't tell if the user has check in yesterday, or the day before, when he started using the plugin, who he is, how many devices he uses, etc.
It's simply anonymous. How is this violating privacy?
I am concerned about privacy, that's why I don't want a more accurate tool to track users.I'm sorry if you don't read disclaimers. But you should take care of warnings when using any tool, especially one you don't know.
-
@jiminy-billy-bob said:
In Layers Panel, it is completely anonymous. I can't track a user in any way. I can't tell if the user has check in yesterday, or the day before, when he started using the plugin, who he is, how many devices he uses, etc.
It's simply anonymous. How is this violating privacy?
I am concerned about privacy, that's why I don't want a more accurate tool to track users.I'm sorry if you don't read disclaimers. But you should take care of warnings when using any tool, especially one you don't know.
Hello Jiminy-billy-bob,
I'm just fed up in general with third parties collecting bits and pieces of information of everyone's private life. Even if it just ends up in one big anonymous bin of data - it's still private data that is collected and if I could have it my way I would like to keep it private and use the plugin but be able to opt out.
Greetings
-
I think we also have to distinguish two points:
• an application/mobile app/plugin sends data to its own server with the user's consent
• an application/mobile app/plugin does this in a way that only its own server receives the data (ie. using a secure connection/encryption)I'd happily allow the first point if I know and trust the plugin author, however the second point suggests that it's better to send data sparingly, only if there is a benefit.
I had the idea "what if my plugin launcher [LaunchUp] also searches online sources or submits calculations to wolfram alpha etc.". That would be cool, but it would broadcast what people do in their SketchUp, ie. Select, PushPull, CurviLoft, Select, Delete…
-
I have just released a plugin for circular stair cases. The coding and design of the plugin was and is a huge undertaking and will consume a lot of time.
I have been working on the Web portion of my plugin for the last month. Most of my time has been spent to ensure a high level of security.
This plugin checks my web site on first time use in Sketchup session to see if the user is in a trial, is licensed, not registered etc.
I am totally up front with this. Currently you can only obtain my StairMaker plugin by going to my website and downloading it.
Hopefully in the future I will be able to evolve the process and to be able to use the plugin store. Currently I do not know what the process is. All I know is it should simplify updates.
I would love to learn, follow and to push a set of plugin standards. The only part I currently know is what I've learned from reading everything on Dan Rathburn's suggested reading list when building plugins.
Where can I go to find a set of plugin standards?
Now for the second part on sites secretly collected data. At a previous job we had 100's of reports and really did not know which ones were used, which ones could be consolidated and which ones could be dropped. So we stared to log report usage. We were able to analyse the information which allowed us to drop 25% of the existing (almost legacy) reports which were still being maintained. With 60% other reports we were able to consolidate.
-
@kaas said:
I'm just fed up in general with third parties collecting bits and pieces of information of everyone's private life. Even if it just ends up in one big anonymous bin of data - it's still private data that is collected and if I could have it my way I would like to keep it private and use the plugin but be able to opt out.
I'm concerned by how privacy is violated sometimes, without people knowing. But let's not be too paranoid about this.
What I do is like you walk down a street, and there are people surveying what you're wearing and on what side you're walking, but not your identity or anything that could identify you. The next day it's different people surveying so they can't recognize you. On top of that, there's a sign at each end of the street warning you what's going on.
These people compile this data and say, "ok we have 5% red shirts and 67% pants in this street".
Would you feel they violate your privacy?
I know I wouldn't, especially if that could improve my comfort in this street.It's give and take. My plugin is free, you can use it as much as you want, but you're willing to give me that little bit of anonymous data, so I can improve it.
I don't ask for anything besides that, and in the end it benefits the users...
You're warned about this, you can always choose not to use the plugin. -
@garry k said:
Where can I go to find a set of plugin standards?
The Extension Warehouse has a set of technical requirements which is based on patterns to avoid plugins clashing. These requirements are parts of what we consider good practice:
http://extensions.sketchup.com/developerA couple of years ago I wrote a short article with some key things to remember:
http://www.thomthom.net/thoughts/2012/01/golden-rules-of-sketchup-plugin-development/Followed up by this check-list:
http://www.thomthom.net/thoughts/2013/02/sketchup-plugin-checklist/(Edit: did you mean standards in terms of security when transferring data over the internet?)
-
Thomas,
I did mean standards. To protect data and web site.
BTW - I have now read all the articles.
I believe that my plugins are mostly in compliance but I did come up with 2 possibly 3 issues.-
My current documentation for DoorMaker and StairMaker is in pdf and is part of the install. I'm seeing that you want an external URL for documentation. Is there a spot in the Sketchup Extensions to provide the URL directly to help Page? Or is it sufficient to provide URL of the Home page?
-
I see what you are talking about as far as not using Sketchup.find_support_file, currently I am. shouldn't be too tough to change.
-
I don't believe that I am using typename - but I'll check this as well.
-
-
This probably should be moved to another thread.
I think my new plugin is ok for testing. The DoorMaker plugin has been around for a while but there was 1 global that I had to change. Currently there have been 327 downloads of the DoorMaker - and 1 complaint.
- No longer using Sketchup.find_support_file.
Users just create a loader.rb file with a require_all and put into real plugins folder - I only put a single rb file into plugins folder. This file is prefaced with GKWare_
- I create a GKWare folder for all of my plugins.
- I create a main module GKWare and for each plugin create a module under that
module StairMaker, module DoorMaker - My plugins are not dependent on each other nor on anyone elses
- No globals
- No modifying or extending base classes
- I do not use typename
- Units work properly - based on model
- I work with the Sketchup.Extensions - one entry per plugin
- Performance is fast.
- I use as few string manipulations as possible
- package is rbz
It isn't perfect - and there are situations where bugs creep in - mostly from unrealistic edge cases. I do trap for a few obvious ones.
- No longer using Sketchup.find_support_file.
-
Advertisement