Improving intranet compatibility

Some organizations are reluctant to keep their browsers up-to-date because they worry that internal websites might not be compatible.

Organization-internal sites can have unusual compatibility constraints. Many have small numbers of users, yet are highly sensitive to downtime. Some were developed with the assumption that the web would always be as static as it was in 2003.

Rapid releases help in some ways: fewer things change at a time; we can deprecate APIs before removing them; and the permanent Aurora and Beta audiences help test each new release consistently.

But frequent releases make manual testing impractical. (Let's pretend for now that the roughly-monthly security "dot releases" never broke anything.)

As with the problem of extension compatibility, overlapping releases could be part of a solution. But we should start by thinking about ways to attack compatibility problems directly.

Automated testing

A tool could scan for the use of deprecated web features, such as the “-moz-” prefixed version of border-radius. This tool, similar in spirit to the AMO validator, could be run on the website's source code or on the streams received by Firefox.

There is already a compatibility detector for HTML issues, but my intuition is that CSS and DOM compatibility problems are more common.

User testing

Not all visitors have the technical skills and motivation to report issues they encounter. In some organizations, bureaucracy can stifle communication between visitors and developers. Automating error reports could help.

It would be cool if a Firefox extension could report warnings and errors from internal sites to a central server.

Depending on the privacy findings from this extension, it could become an onerror++ API available to all web sites, similar to the Web Performance APIs. This seems more sensible than adding API-specific error reporting.

Sample contracts

We could suggest things to put in contracts for outsourced intranet development.

Often, the best solution is to align incentives. That could take the form of specifying that the developers are responsible for maintenance costs for a specified length of time.

When that isn't practical, I'd suggest specifying requirements such as:

Channel management

There is a roughly exponential distribution of home users between the Nightly, Aurora, Beta, and Release channels. This helps Mozilla and public web sites fix incompatibilities before they affect large numbers of users.

Large organizations should strive for a similar channel distribution so that internal websites benefit in the same way. It might make sense for Mozilla to provide tools to help, perhaps based on our own update service or Build Your Own Browser.

Counterintuitively, the best strategy for security-conscious organizations may be to standardize on the Beta channel, with the option to downgrade to Release in an emergency. This isn't as crazy as it sounds. Today's betas are as stable as yesteryear's release candidates, thanks to the Aurora audience and the discipline made possible by the 6-week cadence. And since Beta gets security fixes sooner, they are safer in some ways.

The loss of release overlap takes away some options from IT admins and intranet developers, but rapid releases also make possible new strategies that could be better in the long term.

4 Responses to “Improving intranet compatibility”

  1. skierpage Says:

    You’re on fire today, thanks for a fine set of posts.

  2. Wladimir Palant Says:

    I must bow down to you. That’s a great set of ideas to tackle a very hard problem. It could indeed be the compromise everybody is looking for when dealing with corporate usage.

  3. Steve Fink Says:

    A “me too” comment — these posts are great! They should really be mandatory reading for anyone wishing to contribute to the rapid-release fallout discussion, because you’re doing a great job of deflating myths while still highlighting the very real problems. That discussion so far has been overwhelmed by noise — people with mistaken assumptions (“everything used to be perfect, why did you screw it up?” “Mozilla thinks they totally have everything under control so I’d better yell loudly!”), people correcting other’s mistaken assumptions, etc. There’s a lot of signal, too, but it’s drowned in all the posturing and repetitive rehashing of old arguments and counters.

    I, at least, intend to start pointing to your blog posts as a way to get up to speed on the real state of things. Thanks!


  4. IntranetLounge Says:

    Improving intranet compatibility – Jesse Ruderman…

    This article has been submitted to IntranetLounge, a website with a collection of links to the best articles about intranets…