Ok, it doesn't have to be complicated. If it is all or nothing, just an uneditable text area with the content of the data to be submitted will do. Optionally hide it behind a preview button like in Talkback.[EMAIL PROTECTED] wrote:
We are still evaluating this. There's no clear reason why this is necessary (considering using the tool shows an intention to send the specified data), but it hasn't been 100% ruled out.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.
Again, the *purpose* of the tool is to send the said information. ...2. In Talkback, no URL is sent unless the user volunteers it by pasting it in.
There will likely be a privacy policy specifying how information is collected/used. ...
Sorry, this was not intended to suggest omitting the URL completely. It was meant just to point out the precedent: Talkback is also being careful about collecting URLs.
By using the tool, you know a URL is going to be sent.
But the user doesn't know all the URLs displayed in frames. If the problem is in a page within a frame, the problem page may not be the one shown in the URL bar, and might not be reached by just typing the urlbar url. So it is reasonable for a user to expect that, to report reproduceable problems on sites with frames, the tool sends the URLs of all the frames displayed.
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.
> ...
The point: make it possible to preview what is being sent so that the user can check it to see if there is any info they do not want to send. The user should not have to be an expert and go look into all the places from which that info is gathered.
> ...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.
If a user feels the need to edit/remove... we don't want their report.
These options were intended to show there are intermediate design options between no modifications (abort-only) and arbitrary editing. It sounds like abort-only is the current plan, ok.
Banking or financial sites *don't* show any personal info in the URL. ...
We don't collect cookies, usernames, passwords or the contents of the page. ...
How can the user verify this for themselves if they want?
This tool is more suspicious than a normal website because it is like talkback, and probably gathers internal info like the about:config data and who knows what else.
One of the choices specifically mentions whether login is required. So it is reasonable for a user to wonder whether it is sending the saved password for that page.
Configuration info as well as URLs can be identifying: Some companies may use private extensions which append on to the configuration info such as the userAgent string, so the configuration info might include a combination of data which is identifying.
Rather than try to describe what data the tool is sending, and anticipate and describe all the data the tool is not sending, it is simplest just to show exactly what it is sending, like Talkback does (but without the checkboxes).
>
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.
You need to remember, there is nothing to say.
As suggested above, the number of complaints against the site, and the rank of the site among sites with complaints, is something.
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.
sorry, GetFirefox -> SpreadFirefox.
Agregate data isn't a good idea to show the user. Since it could be misunderstood. 1,000,000 reports in our DB doesn't mean 1 Mil incompatable websites. 90% could be windowsupdate.
That datum wasn't suggested, so this knocks down a straw man.
Sounds like SpreadFirefox tech enthusiasts are expected to be a broad enough audience for the present purposes, so the report reward is not planned for now. Ok, it remains a suggestion for encouraging more participation if desired in the future.
Summary:
* please provide a simple preview of what data will be sent.
* Suggestion of ways to omit or edit data is not planned, understood.
* Suggestion of site count/rank reward for submitted data is not planned, understood.
_______________________________________________
mozilla-layout mailing list
[EMAIL PROTECTED]
http://mail.mozilla.org/listinfo/mozilla-layout
