Closed Bug 322884 Opened 14 years ago Closed 14 years ago

Need an uninstall survey application

Categories

(mozilla.org Graveyard :: Server Operations, task, blocker)

x86
Windows XP
task
Not set
blocker

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: mtschrep, Assigned: morgamic)

References

()

Details

Attachments

(2 files)

Bug 320504 asks the user during uninstall if they'd like to op-in to an exit survey.  We need to build the survey and host it on survey.mozilla.com.
Assignee: Bugzilla-alanjstrBugs → cbeard
I'm not sure why this would be the Update component.  I guess for lack of another place to put it?
Yep - couldn't find a better place for it.  Webtools would be the next best - but neither seemed right.  
Waiting for mocks, specifications for questions.  We agreed on the plans for this app, and I'll be writing the form, etc., and Polvi will set up DNS, infra.
Assignee: cbeard → morgamic
Attached file mock exit survey
Here's a mock of the exit survey provided by Andrew (at Google).  Let me know if you are blocked on anything else.
Thanks Darin - will get to work on this tonight.
Status: NEW → ASSIGNED
Update -- set up the database and form.  We can always add things later -- working on validation and template now, and should have a working example by Wed.
The data from the URL will be stored in `result` based on app logic.  The app logic will be determined by the survey version (/1/ in our case right now).

If we need to add values, we can append to `result` or create new tables/map tables if necessary.
FYI, the FF/TB nightly windows builds (starting tomorrow) will start prompting the user to visit this survey app when uninstalled.
Sample survey, all checked in at /mozilla/webtools/survey/.  Please review to verify that it is the correct form and workflow.
(In reply to comment #8)
> FYI, the FF/TB nightly windows builds (starting tomorrow) will start prompting
> the user to visit this survey app when uninstalled.
> 

Or at least would if the 2 blocker bugs were resolved.  See the dependency tree.

https://bugzilla.mozilla.org/showdependencytree.cgi?id=322884
Could someone please look at the example?  Is this the correct layout and workflow?
https://update-staging.mozilla.org/~morgamic/survey/webroot/
morgamic: Thanks for posting the prototype.  I've sent mail requesting feedback on it from Andrew (and others).
Layout issue:
The text boxes after each of the Issues really makes this page seem daunting. Can we make the Other comments field the place to elaborate on these issues?  Maybe we can just add a note that asks the user to "Please provide specific examples below."

Wording nits:
"Ease of use" should probably be phrased as "Hard to use/confusing" to frame it as an issue.

"Couldn't get features to work" might be better as a more general bugs category: "Some features didn't work properly"

"Specific websites or content on websites didn't display properly" is a little wordy. How about, "Some web pages didn't work properly"
Maybe good to put "What issues, if any, did you have?" into two columns, and make the Other comments or suggestions less massive.  

Point of my suggestion is to minimize (or remove) scrolling at least for 1024x768.
Please add top option:

Just temporary, I'm not planning to install Firefox again soon.


We want to make sure anyone who's having a positive experience to have a positive option to select.
I don't think the page is daunting.  When clicking on a label, the user is given the opportunity to fill in specifics or move on to the next row.

So, though there are a lot of text fields, at least the fields are associated clearly with the question it is relevant to.

Brian, I agree with your wording comments, will make changes accordingly.

Andrew, don't you mean:
"Just temporary, I'm planning to install Firefox again soon."

You said "not planning", and that's a bit negative.

So -- plans are to go ahead with the form as-is, with a smaller textarea and wording changes.  I'm working on the SQL today for the inserts and verifying that the form saves correctly.  Will update when complete.

Thanks again for all the feedback!  :D
Okay, done.

Example:
https://update-staging.mozilla.org/~morgamic/survey/webroot/1/Mozilla%20Firefox/1.5%20(en-US)/exit.html

Code for review:
http://lxr.mozilla.org/mozilla/source/webtools/survey/

Caveats:
* added the $_SERVER['HTTP_USER_AGENT'] to entries, just in case
* needs a rewrite to redirect to script in order to properly pass in args
* all data is optional so there's basically no error checking (other than proper escaping of query strings, etc.)

Please review code and markup and let me know if this would work or not.
You have "Other (please specify)" twice in the first question.  
Yeah - that was leftover.  It's gone now.
I agree with comment 13, the text boxes are too much. The user can just write anything he has to say in the comment box.
As someone to fill out that form I'd call those mozilla folks rather optimistic to
describe problems with 20 chars.

What's the l10n plan for the web app?
Since the uninstaller is not localized we don't have any useful information about what language the user was using, so I don't think that for this pass we have any way to worry about l10n.
Since locale is passed as a parameter from the installer, it would be possible to switch output based on this param.  Until that param comes in, though, there's only one form locale.
> Since the uninstaller is not localized we don't have any useful information
> about what language the user was using, so I don't think that for this pass we
> have any way to worry about l10n.

The uninstaller is not localized, but the parameter to the uninstaller is.  "uninstall.exe /ua 1.5 (en-US)"

That information is forwarded to the web app.  Therefore, it should be possible to localize this web app.
Isn't that a chicken-before-the-egg situation?
> Isn't that a chicken-before-the-egg situation?

The parameter to the uninstaller is configured by the installer, which is localized.
My question is whether the link pointing to the possibly localized web app is localized.

Even if the URL param is from the installer, the uninstaller accompanying text needs to be translated in order to make localization of the web app worthwhile.
> Even if the URL param is from the installer, the uninstaller accompanying text
> needs to be translated in order to make localization of the web app worthwhile.

Agreed.  However, this won't happen until FF 2.  For FF 1.5.0.x, we are stuck with an English-only uninstaller.
So I think we should plan on localization once the uninstaller supports it.  I don't see an english link leading to a localized survey as being very practical or useful... :\

As for how "busy" the form is, the text fields are for very specific notes on "what didn't work" or "pages wouldn't display right"...

Anything not very specific would go in the comments box.

The importance of having these is really to be able to pull out this information and generate a simple spreadsheet or list of common offenders (sites, plugins, broken features, etc.).

Is there a compromise between the two that isn't "just throw everything in a huge textarea"?
(In reply to comment #29)
> Is there a compromise between the two that isn't "just throw everything in a
> huge textarea"?

I'm not a very big fan of this idea, but it is possible to have the textboxes hidden by default and make the respective one show when you check a box.

I noticed it is not possible to uncheck a box by clicking on its label.
Alright, well, I'm not all excited about overengineering this.  At the very least we can pull the text based on which problems were chosen.

The additional text fields were a part of the original mock -- so is it agreed that these fields aren't needed and we can instead point to the textarea???  Darin?
> The additional text fields were a part of the original mock -- so is it agreed
> that these fields aren't needed and we can instead point to the textarea??? 
> Darin?

Sounds good to me.
Agreed, this looks great.  Thanks for catching my earlier typo also.

A few minor suggestions that shouldn't gate launch, but will get us the best responses:

1. Rather than "Other Comments or suggestions", we can be more directed with something like: 

"Please use this space to elaborate on your responses above and for comments or suggestions on how to improve Firefox"

This is likely to increase response rate

2. Place "Some web pages wouldn't work" closer to the top - I think this might be a common answer and we want to make sure people see it.

3. To be nit-picky about wording once more, the second question should read: "What issues or problems, if any, did you have when using Firefox"

Again, looks excellent, thanks for working on this!
Andrew, I like your suggestions but they are too wordy.

I adjusted it to be a bit more simple and direct.  Please see the link.

How does this look overall?  Ready to go?

I like the changes you made to the opne-ended section - clear and concise.  

I was thinking about the second question and wondered why won't be more straightforward and ask:

"Why did you uninstall Firefox?"

That means we'd have to change:
"Security" to "Concerns about its security"
"Printing" to "Problems with printing"

for completeness, we should also have an "Other, please specify ______" box at the end.
I made the section title change.  We can change the text for any answers at any time (they are pulled from a table, so we can adiminister them later).

As for the "other" field, I think we have that covered by the textarea.

If there isn't anything else, we should focus on getting this deployed.  I think Darin is getting antsy, and I don't want to nitpick the UI forever.

Sound good?  :D
Yes, let's move this into production! :)
Agreed - thanks!!
This is ready to be installed.  Moving to server-ops.

Notes about installation....

Code is at mozilla/webtools/survey.

Files to be configured (read comments in file for info):
./inc/config.php (copied from config-dist.php).
./webroot/.htaccess (copied from htaccess.dist).
./sql/survey.sql (import to db layer, and set up config to point to this)

The only server dependency is PEAR::DB, which I believe already lives on LVS.

Let me know if there are any questions.
Assignee: morgamic → server-ops
Status: ASSIGNED → NEW
Component: Web Site → Server Operations
Product: Update → mozilla.org
Target Milestone: 1.0 → ---
Version: unspecified → other
Deployment of the server-side survey pages blocks release (and full testing) of Firefox 1.5.0.2
Severity: normal → blocker
Assignee: server-ops → aravind
Jotting down some thoughts for the future of the survey:
* keep in mind that the questions are generated from the db to make management easier -- might want caching or creating a static survey form periodically if we get unpredicted load (I did not expect people to be uninstalling firefox over 500 times a second... I really hope that won't happen)
* we need to discuss the overall scope of the survey app
** map out localization for Fx 2.0
** map out multi-app support
* need to accomodate audit trails for changes in questions
* we should discuss admin tools requirements
** what info to glean
** what format it should be in

If you anyone has comments about the scope of this app, or legitimate concerns about performance, please speak up.

I'm pretty confident that the DB structure / form / code should be flexible enough to make adjustments in the future should we decide to add things.
Website deployed. url is survey.mozilla.com
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
The url requested by the survey, <https://survey.mozilla.com/1/Mozilla%20Firefox/1.5%20(en-US)/exit.html>, returns an error.

The page appears to work if I replace https with http.

Status: RESOLVED → REOPENED
Resolution: FIXED → ---
I was told that https is not needed on this.  If it is, please let me know and I will add an ssl cert to it.
empirical evidence suggests https is required.  Please add a ssl cert.

Everyone else - who needs to verify the contents of the page?
Arg.  Next time we should add it to the bug before hand.  The SSL requirement was in a related bug (bug 320504).
Sorry Mike, I didn't think to mention it since your staging URL was using HTTPS :(
It's okay - it's my fault for not noticing, too.
A couple of nits....
* I would add a title/header to the page that 1) identifies that this is a survey, and 2) entices the user to respond.  Could be something as simple as "Please tell us what you think..." or something else more clever.
* I would expand the "other" text field to a slightly larger size, 40 cols or so
Hm, I should have checked in some comments earlier. None of these are ship-blockers, just a couple of nits from your friendly user experience wonk:

- s/How did you intend to use Firefox when you installed it?/Why did you install Firefox?/

- s/To fully replace my previous web browser/To use as my default web browser/

- s/Hard to use/confusing (menus, display, etc.)/Difficult or confusing to use/

- s/Plugin compatibility/Didn't work with my media players or plugins/

- I'd move "missing features" to be next to "some features didn't work"

- I'd add a "It kept crashing" checkbox to reasons for uninstall

- I'd add an "Other: [         ]" checkbox to reasons for uninstall
Will there be an about:config option / registry setting / ini setting / group policy setting / whatever to disable the exit survey? (for example, corporate deployments where it is not needed)
No. But most corporate deployments don't use the uninstaller or use it in silent mode.
Can the url change to survey.mozilla.org, instead of survey.mozilla.com?  This would make adding the ssl cert much more easy.  It would also give us an easy way to add this app into the lvs clusters.
That would require client changes.  You'd have to ask on mozilla.dev.planning about the possibility of respinning Firefox 1.5.0.2 for such a change.
Since there's some discussion of the text of the survey, note also bug 330913.
I am working on this and we are planning on deploying this on the lvs during the maintenance window tomorrow evening.
https://survey.mozilla.com is now active.
Status: REOPENED → RESOLVED
Closed: 14 years ago14 years ago
Resolution: --- → FIXED
*** Bug 331640 has been marked as a duplicate of this bug. ***
As marcia notes in bug 331640, the survey does not actually work.  When the submit button is pressed, the page times out.

Also, the Firefox survey is presented to Thunderbird users who elect to view the survey during un-install, even though the url is different.

Survey URLs:
https://survey.mozilla.com/1/Mozilla%20Firefox/1.5%20(en-US)/exit.html
https://survey.mozilla.com/1/Mozilla%20Thunderbird/1.5%20(en-US)/exit.html

Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Aravind,

Can you check the production system?
Spoke with morgamic.  Appears that the problem is code related.

The app is redirecting users to a http page after they submit the feedback.  The http site has been disabled and hence the timeout.  Also the app currently does not have mult application support.  It only supports ff.

morgamic will give me a code refresh that should at least fix the redirect to https (instead of http) problem.
yet.(In reply to comment #42)
> ** map out multi-app support
>
> If you anyone has comments about the scope of this app, or legitimate concerns
> about performance, please speak up.

OKAY -- so we need multi-app support.  We will have to add another table for application, so we can use that to switch off questions/text/presentation per-app.

Aravind will be posting a comment about the timeout and SSL... fixing that right now.

What is the timeline on adding multi-app support?  Estimated time would be about 2 hours to add that in.  I would also need a mock for Thunderbird questions.  Try to fit it into the same format -- just different issue/intend text.
Assignee: aravind → morgamic
Status: REOPENED → NEW
Mike, could you have a future-compatible eye on these changes?
It looks to me like exactly the thing is happening that I envisioned. We start out
simple, without any need for l10n, then rush in complexity and end up with 
something that deserves a rewrite when I come back and say "is this localizable?"

To be clear, I don't require that this we deploy localizations of this right away,
but I do require that you have "this will be localized eventually" in your head,
and that, if we come up with "this has to be localized by then", we have a limited
problem to solve.
*** Bug 331632 has been marked as a duplicate of this bug. ***
(In reply to comment #64)
> Mike, could you have a future-compatible eye on these changes?
comment #23
comment #29
comment #42

Reasons why we aren't locked in to whatever is currently being served up:

a) flexibility of LAMP stack
b) URL params ensure we are getting all data we need from the client (i.e. locale)
c) form output is database-driven, so it can switch based on params
d) database is normalized so adding additional relationships is not a huge task

As I see it, here some steps required for localization:
a) add use multiple PHP templates (instead of one)
b) add db relationship for locales --> intends|issues
c) add app logic to switch based on passed locale parameter
d) come up with a process that allows people insert translations for form items

I see these steps as being modifications to what already exists, not a complete rewrite where we have to scrap the entire thing and throw our hands in the air in a big hissy fit.

Do you see specific problems with the code, database or server configurations that tell you we will reach a dead end?  I am pretty sure that PHP and a good database schema offer the flexibility we will need as long as we have the correct GET params coming from the uninstaller -- is that completely wrong?

If you see fatal flaws in the actual code that will prevent localization, please point them out:
http://lxr.mozilla.org/mozilla/source/webtools/survey/

In index.php, after line 62, anything is possible.  The source of any output can be adjusted based on params, and libraries or supporting classes can be added later as well.
Status: NEW → ASSIGNED
Mike - we should do the TB unisntall survey - but keep it simple (similar questions is fine - just as long as it says TBird instead of FF to not confuse folks).   Release date is targeted at around or after April 11 - so as long as we get this up in teh next week or so we should be fine.
Mike: Can we include a question in the Tbird survey that addresses the lack of a calendar client? Would be interesting data to have.

(In reply to comment #67)
> Mike - we should do the TB unisntall survey - but keep it simple (similar
> questions is fine - just as long as it says TBird instead of FF to not confuse
> folks).   Release date is targeted at around or after April 11 - so as long as
> we get this up in teh next week or so we should be fine.
> 

Note - did an end-to-end test with the hosted survery.mozilla.com application.  Confirmed that submitting data does in-fact get entered properly into the database.

Wanted to note -- I will talk with Axel and others next week and discuss localization for the survey app as well as AMO and other web services.  I'd like to get more people involved so we can get a better handle on best practices for localization -- use of gettext, translation tables, where we can find translators, etc.  Until then, I will work on getting the latest wording nitpicking and multi-app stuff done prior to April 11th.  :)
I am done with installing the survey application and that the application is working.  I don't think there is any more pending work for server ops on this one.  If nobody has any objections, I will go ahead and resolve this bug.  

For content updates, and things like that, please open different bugs as the need arises.  If you would like to keep this bug open, please assign it to the right component.
Per Aravind's comment - this is complete.
Status: ASSIGNED → RESOLVED
Closed: 14 years ago14 years ago
Resolution: --- → FIXED
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.