Policy on third-party JavaScript integration on SE sites

Question

Topic

Should Stack Exchange sites utilize third-party scripts or libraries to augment the user experience on the SE sites in such a way that they provide additional information without the need for clicking through to other sites? Should design restrictions be imposed on how such third-party information is displayed if it is deemed allowed?

Background

There is a discussion/feature-request over on Gaming about integrating a specific JavaScript utility from a specific third-party site (Wowhead) to allow mouse-over tooltips on links to that site to facilitate a quick reference for information related to an item or spell in a game (World of Warcraft). That discussion is covering the merit of that specific case, but I think it touches on a larger issue that should be addressed: whether or not Stack Exchange sites want to get in the habit of allowing third-party libraries and under what conditions they should allow such libraries.

I believe that a decision would need to be made on this overall policy before Gaming gets too much further on the merits of the specific case being addressed there. If the overall SE policy is "we don't want to do that", then further discussion on Gaming would not be worthwhile. If the overall SE policy is "sure, if you can justify it" or "sure, if you can justify it and make it look pretty", then the discussion will need to address those points as necessary.

Possible Outcomes

• Do not allow third-party scripts regardless of utility. If users want to use them, instruct them to include them as part of browser-side technology such as Greasemonkey.
• Allow them as they are deemed to improve the user experience.
• Allow them as they are deemed to improve the user experience, but enforce style requirements that must be met before the script is incorporated into the site.

Caveats

• Hosting: Including code hosted on another site means that SE site is dependent on the code of that other site. Hosting that code locally instead means the SE site doesn't have the most up-to-date version of the code.
• Performance: Additional code can slow down page loads.
• Aesthetics: If a style is not enforced, it can lead to clashing creative assets. If a style is enforced, the cost of development needs to be incurred on either the third-party site, the SE staff, or a volunteer.

Answer 1

I was hoping to hear some opinions before I clouded the thought stream with my own opinion, but it's been a few days. :)

I'll address each point separately.

Inclusion

The goal of SE sites, at least from the user's perspective, is to relay information that helps them answer questions. Scripts such as tooltip scripts make it easier to collect such information in the answer without having to click away from the SE site. From a user's perspective, this answers their questions more elegantly.

Hosting

I think the SE site would need to host the script so as not incur usability issues when the third-party site is unavailable. In addition, I think some regular (perhaps automated) check for updates to the script would be a good idea so new features can be discovered and incorporated.

Performance

In the case of the Gaming example, the script is only needed for certain tags on the site. Including or activating it on just those pages mean that people who never visit questions for that tag will never incur the penalty of the performance hit. Alternatively, if the script is deemed to be lightweight, it could be included on all pages. In either case, the scripts should cache intelligently.

Aesthetics

I keep going back and forth on this item. On one hand, users who ask for such augmentation to the site are probably reliant on the design aesthetics of the particular item being included for the purposes of scanning for the information they desire. In addition, including it as-is would be easier and quicker.

On the other hand, including something with a design that clashes will make the site less attractive. Forcing everything to match the site design (for example, making outside tooltips match the tag tooltip style) would fix that problem but could possibly make the information harder to parse for people used to specific style elements. Plus, this would slow the process due to the need to restyle.

As a user, I'd probably prefer that the tooltip maintain its original style unless it can be restyled in such a way to match the site aesthetic without making it harder to parse information in it.