Closed Bug 459965 Opened 16 years ago Closed 7 years ago

Add standardized support for first-run pages to install.rdf

Categories

(Toolkit :: Add-ons Manager, enhancement)

Product:
Toolkit
Component:
Add-ons Manager
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: fligtar, Unassigned)

References

Details

(Whiteboard: [amo:want P1]) 

I'm not sure if this is a dumb idea or not, so I'm definitely interested in comments.

I would like to see an <em:postInstallURL> property added to extension install.rdfs (not other types of add-ons) that on first run after installation will open a new focused tab with that page. An example might be like this:

<em:postInstallURL>http://fligtar.com/firstrun?version=%ADDON_VERSION%</em:postInstallURL>

An additional property <em:postUpdateURL> would be used for when the extension is updated.

--
Why?

It's very common practice for extensions to have a firstrun page that welcomes the user and explains how the extension works. This may also be coupled with a modal dialog prompting for some sort of login information or wizard configuration.

Modal dialogs upon restart are horrible user experience, and we're now running into issues where if a user installs 2 or more extensions at the same time, which will become more prevalent as we start to offer add-on package installs, they both might pop up firstrun pages and login dialogs and the user has no idea what's what.

I would like to see a standardized method of firstrun pages that will play nicely if 2 extensions are installed at once so that we can encourage use of it and discourage use of modal dialogs and other firstrun devices. I would go so far as to say if we got this support enabled, we should disallow firstrun modal dialogs for extensions hosted on AMO, and instead the firstrun page should have the functionality there or provide a button to be clicked for the popup.

Advanced users might even want to set a pref to disable all extension firstrun/update URLs entirely if they want to task a risk not knowing what an extension does.

That's my primary reason. My secondary reason is it's just way more convenient to add this line than to look up what JS another extension used to create a firstrun page.

--

If this were enabled, it might also be possible for AMO to provide hosting of firstrun pages, which would allow us to give the developer better funnel information for stats.
Yeah I think something like this is useful. We're going to be adding support for apps to handle app specific content in the install.rdf with the switch to sqlite so this will depend on that.
Great idea.

Is there a way where we could have the option to offer a default page that we control which would supersede any first-run for an extension?  This would make for a better user experience and allow us to message a user in cases where add-ons are being bundled together.  For example, a get started message that a user would see on-first run with directions/information about what they just installed and what they should do next (vs. having a random first-run from one of the add-ons be the first to appear).
I suspect that there would be numerous ways for an extension to go around any superceding that is done so trying to supercede would be like playing whack-a-mole. Having a standardized first run page that extensions could opt-in to that would display basic information and allow the user to display the additional information on a per extension basis should be doable.
Mossop, Re: c#1

"...so this will depend on that"

Any bug on file so we can actually mark (proper) dependancies?
I guess bug 449585
Depends on: 449585
I made a blog post on this today (http://blog.fligtar.com/2008/10/16/responsible-first-run-usage/) and dolske commented with a specific problem he found using a first-run page:

"One contributing factor might be that it’s a bit tricky to open a tab for a firstrun page, because sessionrestore will clobber any preexisting tabs when it runs… You can listen for a sessionstore-windows-restored notification, but it’s a bit of a lie (it fires a bit too early), so you have to delay creating a page a bit more with a setTimeout. Authors might be hitting these issues and finding that it’s easier to open a new window/prompt instead. I ran into this when writing the Geode extension for Labs."

Having this standardized property will make sure first-run pages are properly opened and save authors from trying to debug problems like this.
There are a couple of things here that degrade the experience:

1) Installing multiple extensions at the same time with firstrun pages.
2) Is session restore pages pop-up login dialogs, it takes the focus to that tab making firstrun pages less discoverable.

Another alternative idea:
We can’t prevent authors running their own firstrun voodoo (some have said it is needed for configuration, for example), but if we provided them with an alternative then I think that their numbers would decline. I’m thinking something like a little widget, for example in the statusbar, that appears after an add-on is installed. You could choose to overlay a menuitem in there that when selected runs your firstrun bits. It would not go away until done, but that shouldn’t be an issue if it is discreet.

I’ve also never liked the Add-ons window opening after a new install. That experience could definitely be improved. The new install is commonly not even in view, and the visual clue is not obvious on some platforms/themes. But that is for another bug.
(In reply to comment #7)
> I’ve also never liked the Add-ons window opening after a new install. That
> experience could definitely be improved. The new install is commonly not even
> in view, and the visual clue is not obvious on some platforms/themes. But that
> is for another bug.

bug 422133 in fact
(In reply to comment #7)

> We can’t prevent authors running their own firstrun voodoo (some have said it
> is needed for configuration, for example), but if we provided them with an
> alternative then I think that their numbers would decline. I’m thinking
> something like a little widget, for example in the statusbar, that appears
> after an add-on is installed. You could choose to overlay a menuitem in there
> that when selected runs your firstrun bits. It would not go away until done,
> but that shouldn’t be an issue if it is discreet.

The firstrun page for this could be a chrome: URL that lets the user configure the addon (and possible runs the setup voodoo in the background).
Depends on: 461976
No longer depends on: 449585
This is a great idea, in lots of ways. I'm sure lots of extension developers would prefer adding 1 or 2 lines into install.rdf over writing or maintaining code to launch first-run tabs/pages/sidebars/dialogs, especially for those extensions which support multiple applications. Users would like the improved uniformity and predictability. And someone would be sure to create an extension which allowed users to customize the behavior of first-run pages (eg., "only show one at a time" vs "open them all in new tabs" vs ...).

I guess being the exemplar of extensions sticks Mozilla with the job of working out issues like this. Keep up the great work!
Whiteboard: [amo:want P1]
Now that Thunderbird has tabs, this would be nice there as well. Though perhaps that should be a separate bug?
Is there any news on this bug? I have a Thunderbird / Seamonkey / Postbox extension with  23,000 regular users and I would like to create a first run (after upgrade) web page to ask people for donations, and pointing to my various "how to use" / "version history" / "bug fixes" pages on mozdev. 

I have the latest version ready for release, which contains 4 important bug fixes and I do not want to release without at least pointing users to the possibility of donating; obviously I do not want to wait until TB/SM/Pb provide that possibility; although all of these mail clients provide content tabs I would prefer them opening a browser window [as IMO it is not a good experience to try to open a paypal page from a mail browser tab; it simply doesn't know (and doesn't have to) the passwords etc.] If this feature (firstrun URL in install.rdf) existed, it should be specifyable whether to open the link with the default browser or handling within the application (content tabs).

It would be great if somebody could post a generic stub or some code as a workaround.
The fact that this was quiet for 7 years is probably reason enough to close it, but now that install.rdf is nearly dead, there's really no reason to keep it around.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.