Closed Bug 441739 Opened 12 years ago Closed 11 years ago

Remove registration barrier - allow experimental testing via alternate confirmation method.

Categories

(addons.mozilla.org Graveyard :: Public Pages, enhancement, P1)

enhancement

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: ketsueki.shard, Assigned: abuchanan)

References

()

Details

Attachments

(4 files, 4 obsolete files)

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.14) Gecko/20080622 Firefox/2.0.0.14
Build Identifier: 

Registration is an annoyance that I, and probably many other users avoid at all costs.  There are too many accounts in too many places for it to be worth it.  Please allow an -alternate- method for verifying a user wants to try an experimental add-on.

Suggestion: Allow some way for the user to enter the exact add-on name and version as on the title of the experimental add as confirmation that they are in fact installing something experimental.  DO NOT require a valid account of any kind for this method.

Reason: There is surely a non-zero percentage of potential testers who would want to try add-ons and leave 'it works well enough' comments only if they actually like the software, or just remove it and leave entirely since the rest of the public add-ons meet their needs, besides the potentially not yet useful add-on they just tried.   Testing unproven add-ons for a majority of users is likely a rare thing.  The entry barrier forced by registration and yet another account will surely stop some users who just want to test one add-on that happens to offer a minor improvement they can otherwise live without.

Reproducible: Always

Steps to Reproduce:
- Security policy that does not consider casual testers. -
I am inclined to dupe this against bug 362371?
Frederic: This is not an 'OpenID will make this problem go away' issue.

It's more that 'user is registered' does not correlate with 'user knows FF well enough to be trusted with experimental add-ons'.

As far as I'm concerned, a scary-enough click-through web-page with 'this is experimental code, it may eat your computer. so don't come crying if it does' should do the trick and be easy enough to implement. If you care, you can even add a couple-second delay to make sure people actually read it (yeah right). While you're at it, point out safe mode on the click-through page to make sure people know how to get rid of really broken stuff.
well I agree with Ketsueki Shard. 
As I read in experimental add-on page,
https://addons.mozilla.org/en-US/firefox/pages/experimentalAddons,

"The add-on site requires that users login to install experimental add-ons as a
reminder that you are about to undertake a risk step."

Why should users register for a "Reminder"? I think forcing users to register
before downloading an experimental add-on is not an appropriate way to warn
users....It looks like collecting personal information and email addresses...

My suggestion:
- Let the users choose themselves whether to register or not. If they choose
not to register, they should agree to a "Terms of use"  and take the
responsibility of the experimental add-on themselves.
Duplicate of this bug: 455872
Status: UNCONFIRMED → NEW
Ever confirmed: true
Blocks: 454953
Bug 454953 has also been sort of marked as a duplicate of this bug
(In reply to comment #5)
> Bug 454953 has also been sort of marked as a duplicate of this bug

No: I renamed that bug intentionally to give it a meaning beyond "don't make me log in". It's now focused on removing these dummy accounts when the functionality for that lands.

(Otherwise I'd have to dupe that bug against this one, then file a new one about removing the dummy accounts; but that seemed overkill to me).
So, currently sandbox'ed/experimental add-ons show up in search results but require a login to install them.

I'd like to solicit some ideas on how best to solve this.

1) Sounds like an interstitial (JS popup or additional confirmation page) for experimental add-ons is one way to solve this but could get annoying for users that are trying out lots of experimental stuff.
2) We can revert back to adding a preference to "enable sandbox" on a per user basis but that again doesn't solve the "I need an account to install an experimental addon" problem.

Does anyone have any other ideas besides an interstitial? Otherwise, we'll go with that and get feedback.
Target Milestone: --- → 4.0.2
(In reply to comment #7)

> 1) Sounds like an interstitial (JS popup or additional confirmation page) for
> experimental add-ons is one way to solve this but could get annoying for users
> that are trying out lots of experimental stuff.

Why not have the interstitial the first time and allow users to click a checkbox that says 'Do not show me this again'? We could set a cookie for non-logged in users that would save the preference and for logged in users save it in the db.
Idon't really care as long as I don't need to log in, but here's an idea:

Have a standard agreement-type form with an 'I understand' button, but instead of a lengthy explanation, just have one sentence in big bold text, something like:

'This extension is experimental, it will probably destroy your Firefox profile.'

Anything longer than that people aren't going to read.
Blocks: 453758
I think the Andrew idea for having a short 'agreement-type form' seems good. I mean there's no need to have a separate page or popup for agreement. You can place it in the page that the user click on download button. The download button would not be activated unless the users checks the "I agree" checkbox. sth like this.
From bug 455872:

Is it naive of me to suggest something like we have for ignore version check
(again, this is only seen by logged in users, but that's a separate discussion,
really) where users have to consent to some warning before the install button
is activated, but don't have to provide personal information like email
address?  Something like:

[ ] I understand that this addon is experimental, and may cause %ProductName to
crash or behave oddly
Priority: -- → P1
(In reply to comment #10)

Considering there's a dropdown agreement to install the add-on, maybe we could  add a very visible notice onto this dropdown saying this is experimental code and force them to click "I agree, I won't come crying when the world ends" before installing?
Is there a plan for this?  Assigning to Basil until there is.
Assignee: nobody → basil
(In reply to comment #12)
> (In reply to comment #10)
> 
> Considering there's a dropdown agreement to install the add-on, maybe we could 
> add a very visible notice onto this dropdown saying this is experimental code
> and force them to click "I agree, I won't come crying when the world ends"
> before installing?

It's been shown again and again [1] that users don't care what popups say, they just want them gone.  I like the ideas in comments 10 and 11 about the checkbox enabling the download button.  It will suffer the same problems as the popup (namely, no one will read it once they figure out that's how to enable the button) but figuring out the balance between being useful and being a barrier is the tough part and I think it swings in the right direction.

[1] One from this morning: http://arstechnica.com/news.ars/post/20080923-study-confirms-users-are-idiots.html
Without creating a new popup dialog as has been suggested by everyone, include some next text next to the install button. Here is my recommendation for the confirmation text to use:

[ ] I understand that this addon is experimental, and may cause %ProductName to
become unstable, unusable or even crash

I like the idea that Ryan has in comment 8 but for the first iteration, let's go with this and get feedback before we make it a "permanent" decision for users via a cookie.

Assigning back to default owner.
Assignee: basil → nobody
> It's been shown again and again [1] that users don't care what popups say, they
> just want them gone.

Sadly, that also implies that no matter how much we tell them not to cry when crashes happen, they'll still do it, assuming that we didn't actually mean it when we said, experimental add-ons can be unstable. Still, I'm with Basil here, let's put a checkbox in place. If we want a cookie at a later time is up for debate after gathering feedback.
Blocks: 456698
Assignee: nobody → jboriss
No longer blocks: 454953
Here's the screenshot described in comment 15.  My only concern is that a user might click "Add to Firefox," the biggest and most obvious button even when it is at half opacity, and miss the warning.  What about if we gave a slight visual indication to the checkbox if the user clicks the deactivated Add to Firefox button, such as a slight burst of color or highlight the check box in red?
Assignee: jboriss → buchanae
Target Milestone: 4.0.2 → 4.0.3
FWIW, this is how others do it: http://www.jboss.org/jbossjbpm/jbpm_downloads/ Click on any of the download links which will give you a JS overlay reminding you that you are about to download a community package, not a Redhat enterprise one.
Target Milestone: 4.0.3 → 4.0.4
-> 4.0.5, alex has finals this week
Good luck Alex!
Target Milestone: 4.0.4 → 4.0.5
OS: Linux → All
Hardware: PC → All
Target Milestone: 4.0.5 → 5.0.1
Alex, need you to pick this back up.
FYI- metrics are in place to measure impact of this change once we ship
Target Milestone: 5.0.1 → 5.0.2
Target Milestone: 5.0.2 → 5.0.3
Alex?  You around?
Assignee: buchanae → nobody
Assignee: nobody → buchanae
Hey.  I'm sorry I have let this bug get so stale. I have been really busy with work on spreadfirefox.com.  I haven't forgotten about this (and I've worked on it some) but I haven't kept it updated.  My bad.

To business.  I have this roughly working, as you can see here...
http://abuchanan.khan.mozilla.org/remora/site/en-US/firefox/search?q=experimental&cat=all#install-53695

What's left?
 * bug: the install button text changes on confirmation
 * small (but mysterious) JS+CSS bug when you confirm, then refresh that page 
 * l10n
 * some minor CSS

I'll try to work this out tonight and tomorrow.
Thanks Alex - great to hear.  That URL doesn't work for me though - typo?  I'm on hotel internet, so it's entirely plausible that it's my problem.
It's looking good, Alex.  Johnathan:  it's on the VPN which doesn't reliably propagate DNS.  If you're on the VPN you can hardcode the address in your hosts file to 10.2.74.111
Hey Alex, what's the status on this bug?
Attachment #366337 - Flags: review?(clouserw)
Comment on attachment 366337 [details]
patch v1, JS confirm experimental install

- clicking on an icy button still installs the add-on

- All the Recommended add-ons on the front page (click through the merry go round thing) have enabled buttons even when they are only compatible with older browsers.  They should have the "ignore this check" link for logged in users to enable the button
Attachment #366337 - Flags: review?(clouserw) → review-
Attached file v2, fix comment #29 (obsolete) —
Attachment #366337 - Attachment is obsolete: true
Attachment #366419 - Flags: review?(clouserw)
Attachment #366419 - Flags: review?(clouserw) → review-
Comment on attachment 366419 [details]
v2, fix comment #29

CSS pickiness:  The cursor shouldn't be a hand over frozen buttons (it isn't over our current ones but it is over yours).

Your checkbox bypasses the version check.  When I'm logged in I get version warnings using a nightly on, e.g. add-on 8278.  When I log out I check your box and don't get any warning about version incompatibility.

Even with the checkbox checked I can't right click -> download.

install_button_confirm_exp_install  should be localized to:  Let me install this experimental add-on. <a href="%1$s">Whats this?</a>
and the href should point to /pages/faq#experimental-addons
osunick thinks a better place to link to would be /pages/experimentalAddons so let's do that
(In reply to comment #32)
> osunick thinks a better place to link to would be /pages/experimentalAddons so
> let's do that

disregard all this. :(
(In reply to comment #31)
> Your checkbox bypasses the version check.  When I'm logged in I get version
> warnings using a nightly on, e.g. add-on 8278.  When I log out I check your box
> and don't get any warning about version incompatibility.

While working on this, I noticed what I have is slightly off from the version check message, which is the same type of check.

* the version check message disappears after the user confirms

* the version check message uses a link instead of a checkbox

* when one version check message is confirmed, all others on the page are different too

It seems best to keep things in line, and I like the version check method more, but it's slightly different that what's been discussed here.  Is it OK to tweak the spec a little to do it the version check way?
We talked about this on IRC but for the record we're going to keep the checkbox because from a UX point of view checking a box happens more often when agreeing to something I think.
Target Milestone: 5.0.3 → 5.0.4
Attached file version check, l10n, CSS, comment #31 (obsolete) —
Attachment #366419 - Attachment is obsolete: true
Attachment #370298 - Flags: review?(clouserw)
Attachment #370298 - Flags: review?(clouserw) → review-
Comment on attachment 370298 [details]
version check, l10n, CSS, comment #31

I tried to review this but it didn't apply cleanly (failures in addons.js and install.thtml).  Additionally, the L10n portion is really messed up.  Changing line numbers and stuff is fine but you're deprecating a bunch of valid strings as well as adding in all the invalid admin panel strings (everything above a_cancel_installation in the .po).  I'm not sure what you did there but I'd suggest svn uping your entire tree and then running the extract script again.
Attached file reroll (obsolete) —
re-roll, looks correct this time
Attachment #370298 - Attachment is obsolete: true
It looks a lot better.  Two things:

A)  
  1) load /addons/versions/4695
  2) check the box
  3) click the button.  The background of the button gets really messed up (I can screenshot if needed)

B)
  1) load /search?q=test&cat=all&show=20&page=15 with a 2.0 browser
  2) check the box next to one of the buttons
  3) get a JS error about href not being defined.
(In reply to comment #39)
> A)  
>   1) load /addons/versions/4695
>   2) check the box
>   3) click the button.  The background of the button gets really messed up 

I should note, this is a problem in production.  See screenshot.

looks like the problem comes from screen.css line 420

#addon-summary .link-sharing .share-button a:hover, .install-button a:focus, .install-button a:active { color: #0a3b73; background-color: #9dd34c; background-position: -800px -860px; }

It happens on buttons with long text, e.g. windows specific installs have "Add to Firefox (Windows)" which expands the button dimensions, and messes with the sprite offsets

I can try to include it in this patch, if you like, but wanted to get thoughts from those more experienced with AMO CSS/Sprites, someone here might know a quick solution.

Thanks!
fixes the href JS error
Attachment #370490 - Attachment is obsolete: true
Attachment #370732 - Flags: review?(clouserw)
Attachment #370732 - Attachment is patch: true
Attachment #370732 - Attachment mime type: application/octet-stream → text/plain
Attachment #370732 - Flags: review?(clouserw) → review+
Comment on attachment 370732 [details] [diff] [review]
fix comment #39 B), clean up CSS/JS, svn up

Ok, let's ignore the ugly button for now.

I think this is good.  Since our buttons are so complex we get some odd cases: like, browsing with a newer version will let you "ignore this warning" which never prompts you to check the box.  I think it probably should but I'm r+ing this so we can get QA started on it.  Can you write an additional patch to fix that?

QA: this affects all our download buttons on AMO and there are a lot of corner cases (logged in/out, add-on for pre-release/older/newer browser, add-on has policies before downloading, add-on has newer versions, etc.).  Let me know if I can help - it would be awesome if we could setup some automated testing for each case.
(In reply to comment #42)
> (From update of attachment 370732 [details] [diff] [review])
> I think this is good.  Since our buttons are so complex we get some odd cases:
> like, browsing with a newer version will let you "ignore this warning" which
> never prompts you to check the box.  I think it probably should but I'm r+ing
> this so we can get QA started on it.  Can you write an additional patch to fix
> that?

Per IRC, this happens because logging in allows users to ignore version check, but it also disables blocking of experimental add-ons.  So currently, it's impossible to get a exp. confirm dialog after an ignore version check message.  

committed in r24129
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Is this supposed to be on the preview site? All I see on experimental addons when visiting preview.addons.mozilla.org is a little 10x10 pixel box where the disabled button and the explaining text used to be. "Error: initExpConfirm is not defined" is in the error console.
(In reply to comment #44)
> Is this supposed to be on the preview site?

Seems to work for me. Maybe it still needed to update itself?
Sorry, I need to reopen:

- the <label> should have a for=... attribute so clicking on the text checks/unchecks the box. The check box itself is a very bad click target because it's so small (the UX people blame that on Fitts' Law).
- The text reads "Whats this?" (sic) and should at least get an apostrophe.
- Finally, maybe we should give it just a few pixels of margin between the button and the text? Also, on the add-ons' details pages, the line break in the middle of "What's this" looks fairly odd (screen shot to follow).
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(In reply to comment #45)
> (In reply to comment #44)
> > Is this supposed to be on the preview site?
> 
> Seems to work for me. Maybe it still needed to update itself?

Propably. Works now.
Depends on: 487113
Thanks for the feedback Fred.  I checked in r24206 which fixes everything except the "what's this?" linebreak.  That's got some strange issues when I start playing with it so I'm skipping it for now (will change with l10n anyway).

I'm closing this bug and calling bug 487113 a separate (non-blocking) bug.
Status: REOPENED → RESOLVED
Closed: 11 years ago11 years ago
Resolution: --- → FIXED
12:27 < stephend> buchanae: if you click "What's this?", which loads the FAQ page, then click back, and then forward again (yeah, a bit convoluted), the 
 download button disappears

Donner, I couldn't reproduce this on preview.addons.m.o  Could you post a screencast, or maybe the desc. above is missing a step?

Thanks
The "What's this?" link is part of the label. Clicking it will check/uncheck the checkbox.
Depends on: 487455
Depends on: 487462
Depends on: 487476
Depends on: 487672
Blocks: 491446
Blocks: 516710
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.