[EMAIL PROTECTED] wrote:
Suggest extension should take privacy hints from Talkback reporting tools:
* Give users a way to preview what info they are sending/revealing
Pretty much everything that's being sent is visible in the UI. If it's not visible, then it's probably something like "time of the incident" and I'm not sure it's critical. This isn't a bad idea, but I'm not sure it's necessary.
1. You may know that, but the user doesn't know that. Enabling the user to preview the info gives the user confidence that Firefox is not spyware and only reveals data with the user's approval.
2. In Talkback, no URL is sent unless the user volunteers it by pasting it in.
3. It sounds like info may be available in the UI, but not known to the user. I certainly didn't know about about:config, and new users will not know about other information sources.
4. Displaying the info lets the user identify their own platform case better when following any discussions.
Please provide preview before send.
* Give users the option to edit/omit some info (for privacy) e.g., url may contain user-identifying parameters
I brought this up with Robert. I'm not sure on this one. I'd rather that users use a web form to submit broken site data if they want to edit the information. I believe we'll eventually have a web form version of the tool.
Options: * Abort only. If after previewing info, there is anything you don't want to reveal, your only option is to not send it. * Omit only. Like talkback, you can omit certain fields. The rest are unchanged. (Could be extended to trim parameters, or trim parameters and path, from URL, so you know the rest is accurate.) * Edit with flag. If user edits a field such as url, flag it as edited, so you know it may be erroneous.
This is less critical than preview. But recognize that complaint numbers may be reduced from sensitive sites, such as banking or financial sites.
Suggest extension should tell user how to track progress:
* Tell users how use the tracking number so they can see what has happened with the report
Their report won't have a very important existance on it's own so there won't be much value in tracking it. Maybe we could have some mechanism in the future to add bug numbers to reports when we create bugs, but I think that sounds like a lot of work for not much gain.
* Tell users how to find tracking numbers of previously sent reports.
Users usually will not use often unless they can see benefit to them. Tracking info can show some progress toward that benefit, and may help them verify that their contribution helped change the site. Otherwise it is just a mysterious black hole gathering info about them.
We're going to be using this information in aggregate, not following up on individual reports. Giving the user the idea that it's like submitting a bug to Bugzilla would be wrong. It's more like talkback. We'll be following up with Bugs on the most often reported problems culled from the thousands or tens of thousands of broken site reports.
The benefit doesn't have to be an individual report, it could be an aggregate report, like * the number of unique complaints against the site, * the number of unique complaints against each path at the site with more than 10 complaints. * the rank of the site: if it is the site with the 4th most complaints evangelism is probably working on it, but if it is the site with 104th most complaints, probably not.
Analogy: many people don't participate in web polls unless they are interested in seeing the results, and wouldn't participate at all if there was not the reward of seeing the poll results so far. Web polls also enable voters to go back and see the results again later, (so it doesn't discourage voters from voting early). For site complaints, the information in the aggregate report and rank is the reward, and the tracking number is what allows early complainants to go back and view the results later after more complaints have gone in.
This tool is unlike talkback in one important respect: Talkback is
initiated by Mozilla Firefox, the user only has to approve the process. But for this tool, the user has to initiate the process, so there
needs to be benefit users can see, or they will rarely bother.
Aggregate report rewarding is less critical than preview to start, but recognize that without it complaints will be skewed even more toward GetFirefox tech enthusiasts and not the general Firefox user population.
_______________________________________________
mozilla-layout mailing list
[EMAIL PROTECTED]
http://mail.mozilla.org/listinfo/mozilla-layout
