Mike Kaply wrote:
> On Aug 20, 1:52 pm, Justin Scott<flig
...@mozilla.com> wrote:
>> A note on "first run experience" - this does not include basic first-run
>> pages, but does include any other type of first-run dialog, wizard,
>> sidebar, or other distraction.
> But you're asking people to put in dialogs for opting in for search.
> Does that mean we are going to get dinged for doing what you say?
We are asking that changing search defaults be opt-in. We would
certainly be okay with other methods of opting in, such as a link
somewhere that the user must click to turn on the change you want.
Obviously, users would be less likely to do this, so a dialog makes the
most sense for add-ons that really want the user to opt in. But we are
certainly not requiring a dialog, as long as the experience remains opt in.
> Other comments:
>> This add-on changes the homepage
> What if the add-on offers to change the homepage but doesn't change it
> unless you say so?
Still trying to figure out requests vs. changing without request. There
are a couple of the practices that seem like they should have 2 options:
"This add-on changes the homepage" and "This add-on requests to change
your homepage."
Homepage Changer 1.0 would be expected to change the homepage, yet it
should still disclose that it changes the homepage. Whereas RSS Reader
1.0 would have to have an opt-in mechanism for changing the homepage,
and should disclose that it requests to change the homepage. I'm not
sure it makes sense for it to disclose that it changes the homepage when
it only requests to do so per our policy, but I still think it should be
disclosed so the user knows to expect it.
I tried a mockup with 2 checkboxes at one point but didn't like it.
Looking for feedback from anyone on requesting vs. changing disclosure.
>> This is an extension or theme and adds a new search provider
> This makes no sense. Why do you need to call out the extension/theme
> part? Shouldn't it just be "This add-on adds a new search provider?
Search providers are a type of add-on hosted on AMO. We do not expect
add-ons that are search providers to disclose that they add a search
provider. Does immediately dismissing ideas that you don't understand
work well for you in other discussions?
>> This add-on contains binary components
> Why is this relevant for an end user to know this? Is this a bad
> practice? Some things can only be done in binary components.
It is not necessarily a bad practice, just a noteworthy one. There are
some great add-ons that use binary components. They just require special
review by AMO, and we don't have the same level of confidence in their
review that we do with an open source add-on.
>> This add-on is supported by advertisements
> Why is this important? Advertisements is too general. What if they
> aren't intrusive? What if you have a google ad on your first run page?
> Isn't that supported by advertisements? Are you finding fault with any
> add-on that supports itself with advertisements?
I think this may change to "This add-on displays advertisements in its
interface" to make it clearer that we're talking about advertisements in
the browser chrome and extension interfaces, not a first-run page or
website. I'm not finding fault with advertisements -- some users just
don't want to see advertisements in their browser.
>> Other noteworthy practice:
> What does that even mean? You expect people to point out when they are
> doing something that the AMO team doesn't like?
Yes. If we notice something when reviewing an add-on or something is
brought to our attention that we think is noteworthy and we don't have a
standard checkbox for it, add-ons would need to disclose it there before
they can be approved.
>> Please note practices that your add-on employs?
> employs? Come on, that sounds a little sinister, doesn't it? How about
> uses?
Sure, the copy isn't final. Will take it into consideration.
> Where's the policy page that is referenced in the spec?
It will be in the policy section of the new developer site, which will
be live before this is implemented but is not yet. Spoiler:
http://blog.mozilla.com/addons/2009/05/01/no-surprises/ > How is this going to be presented to the AMO user? Is it going to look
> like a warning? Are you going to try to scare off users from
> installing add-ons that do these things?
>
The design bug is linked in the original post here.
|
