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

Status: RESOLVED FIXED

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

Description

[Ketsueki Shard]

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. -

Comment 1

[Fred Wenzel [:wenzel]]

I am inclined to dupe this against bug 362371?

Comment 2

[Andreas Kloeckner]

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.

Comment 3

[Salman Niksefat]

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.

Comment 5

[Andrew Smith]

Bug 454953 has also been sort of marked as a duplicate of this bug

Comment 6

[Fred Wenzel [:wenzel]]

(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).

Comment 7

[Basil Hashem [:baz]]

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.

Comment 8

[Ryan Doherty (:rdoherty)]

(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.

Comment 9

[Andrew Smith]

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.

Comment 10

[Salman Niksefat]

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.

Comment 11

[Johnathan Nightingale [:johnath]]

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

Comment 12

[Jennifer Morrow [:Boriss] (UX)]

(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?

Comment 13

[Michael Morgan [:morgamic]]

Is there a plan for this?  Assigning to Basil until there is.

Comment 14

[Wil Clouser [:clouserw]]

(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

Comment 15

[Basil Hashem [:baz]]

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.

Comment 16

[Fred Wenzel [:wenzel]]

> 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.

Comment 17

[Jennifer Morrow [:Boriss] (UX)]

Attachment: Experimental add-on warning: checked and unchecked state

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?

Comment 18

[Fred Wenzel [:wenzel]]

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.

Comment 19

[Michael Morgan [:morgamic]]

-> 4.0.5, alex has finals this week

Comment 20

[Justin Scott [:fligtar]]

Good luck Alex!

Comment 21

[Michael Morgan [:morgamic]]

Alex, need you to pick this back up.

Comment 22

[Nick Nguyen [:osunick]]

FYI- metrics are in place to measure impact of this change once we ship

Comment 23

[Nick Nguyen [:osunick]]

Alex?  You around?

Comment 24

[Alex Buchanan [:abuchanan]]

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.

Comment 25

[Johnathan Nightingale [:johnath]]

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.

Comment 26

[Wil Clouser [:clouserw]]

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

Comment 27

[Wil Clouser [:clouserw]]

Hey Alex, what's the status on this bug?

Comment 28

[Alex Buchanan [:abuchanan]]

Attachment: patch v1, JS confirm experimental install

Comment 29

[Wil Clouser [: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

Comment 30

[Alex Buchanan [:abuchanan]]

Attachment: v2, fix comment #29

Comment 31

[Wil Clouser [:clouserw]]

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

Comment 32

[Wil Clouser [:clouserw]]

osunick thinks a better place to link to would be /pages/experimentalAddons so let's do that

Comment 33

[Wil Clouser [:clouserw]]

(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. :(

Comment 34

[Alex Buchanan [:abuchanan]]

(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?

Comment 35

[Wil Clouser [:clouserw]]

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.

Comment 36

[Alex Buchanan [:abuchanan]]

Attachment: version check, l10n, CSS, comment #31

Comment 37

[Wil Clouser [:clouserw]]

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.

Comment 38

[Alex Buchanan [:abuchanan]]

Attachment: reroll

re-roll, looks correct this time

Comment 39

[Wil Clouser [:clouserw]]

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.

Comment 40

[Alex Buchanan [:abuchanan]]

Attachment: comment #39 A) in production

(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!

Comment 41

[Alex Buchanan [:abuchanan]]

Attachment: fix comment #39 B), clean up CSS/JS, svn up

fixes the href JS error

Comment 42

[Wil Clouser [:clouserw]]

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.

Comment 43

[Alex Buchanan [:abuchanan]]

(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

Comment 44

[Jesper Kristensen]

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.

Comment 45

[Fred Wenzel [:wenzel]]

(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?

Comment 46

[Fred Wenzel [:wenzel]]

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).

Comment 47

[Jesper Kristensen]

(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.

Comment 48

[Fred Wenzel [:wenzel]]

Attachment: check box and label style on details page

Comment 49

[Wil Clouser [:clouserw]]

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.

Comment 50

[Alex Buchanan [:abuchanan]]

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

Comment 51

[Dão Gottwald [:dao]]

The "What's this?" link is part of the label. Clicking it will check/uncheck the checkbox.