Laptop running slow

So I just read the statement from the Mozilla Foundation which predicts 10% of the world’s web browsers will be Mozilla-based by the end of 2005. While some people seem pretty excited about this development, I can’t help but wonder if we are settling for too little here. 15 months? 10%? By comparison, every time a new version of the Flash plug-in is released, we get a predictable 80-90% penetration rate at the 15 month mark. Why can’t we expect this sort of development pace with browsers? Several reasons… some perhaps solvable and some perhaps not. This article will discuss several of the issues involved and recommend possible solutions.

Leadership and control

One of the biggest factors in the upgrade cycle differences between Flash and open source browsers like Mozilla is the lack of absolute control in open source development. When Macromedia sits down every year to plan their budgets and product releases, they need only to decide on an amount of money to invest in Flash development and a feature set. After these two decisions are made, the Flash team has their marching orders and they can begin setting things like release dates and migration strategies. Every member of the Flash team is paid a salary for their full-time dedication to the product over the next several months and since most Macromedia employees are in the same location, workplace synergies help to speed and enhance the development process.

Contrast this to the open source development process of the Mozilla Foundation. Mozilla, like all open source projects, requires the individual contributions of people who, for the most part, butter their bread elsewhere in the internet economy. While there are a handful of people working full-time on the project, a large amount of the contributions are made from people who pitch in after hours, on their own volition. This is the very spirit that makes open source what it is: a distributed group effort aimed at creating public good. While that goal is arguably more honorable than the goal of say, Macromedia, its built-in disadvantages are obvious. As far as I know, there is no single person in the Mozilla Foundation who can push through a feature set without the approval of many others. This is, of course, by design, but again, it carries its own disadvantages. There is also no open-source equivalent to a Macromedia manager awarding bonuses or extra stock grants to employees working overtime for a product launch. Since Mozilla participation is voluntary and only intrinsically rewarding, artificial motivation injection is severely sacrificed.

So you might be saying, “But you’re comparing Flash to a browser… that’s not fair”. Okay, well let’s look at Safari then. Safari took about a year and a half to become arguably the best browser in the world, on any platform. Why? Leadership and control. Dave Hyatt and the small team he worked with at Apple were able to take the little-used open-source KHTML rendering engine and set real objectives for it. Using the famous Steve Jobs mantra of “real artists ship”, Hyatt and his team not only improved the rendering engine itself by leaps and bounds but they built an entire framework for web browsing on OS X called WebKit. And on top of that, Apple’s improvements to KHTML were donated right back to the open-source community for use in other KHTML projects. Why did Apple do this? Because they realized that their strength on the web relies on interoperable, open standards. This is the opposite of Microsoft’s early stance that IE must contain technologies only available to it and not other browsers.

* I want to pause right here and make it clear that nothing in this article is meant as a knock against Mozilla, open source, or anybody involved in either. Firefox — now that it’s on the right track — is clearly the most important product in the browser world today and this article aims only to examine how to help speed its progress and adoption.

Transparency of operation

With each new version of any given browser, observable changes are made to the interface. New menu options are added. A new icon is sometimes designed and placed in a different place on the user’s computer than the old icon. Chrome looks different. Bookmarks are sometimes not carried over correctly. Toolbars and other customizations may be removed. The list goes on and on. Generally speaking, users hate change, and when change is introduced during an upgrade cycle, the first reaction in users is almost always negative. Sure, this feeling may subside once the user begins to appreciate the improvements, but it still creates “upgrade anxiety” as users are afraid of what changes any new browser will bring.

Compare this to a Flash upgrade. Flash is completely transparent to the user. There is no interface. In fact, this is what initially attracted me to Flash 2 back in the mid 90s. When a user upgrades Flash plug-ins, the only noticeable difference is that more robust applications are now available to them. And even then, applications which take advantage of the newest capabilities of Flash only begin trickling in over the next year or so. In other words, there is no shock, and hence there is no anxiety.

Ease of upgrade

Simply put, Flash has set the gold standard for software upgrades via the web. By marching to their own standard and using both the object and embed tags in a smart fashion, new versions of Flash are instantly and transparently available for PC IE users and pretty easily available to the rest of the world as well. A restart is usually not required, no user data is affected, and the size of the upgrade is anywhere from a few hundred kilobytes to about a megabyte in size. Over a broadband connection, the upgrade is usually complete from start-to-finish in a matter of seconds. Over a dialup connection, it may take a few minutes. But the most important aspect of the upgrade is that there is almost no possibility of confusion for the user. It feels more like getting a package in the mail than moving to a new city.

Browsers, on the other hand, are notorious for their difficult upgrade procedures. Now, when I say “difficult”, I don’t mean difficult to you and me. Any power user of web technologies and computer systems can figure out how to upgrade rather easily… and that is part of the reason we are always the first to upgrade. Take your average computer user, however. This is the person who thinks that little blue “e” icon on their desktop labeled “The Internet” actually is the internet. How many times have you heard the phrase “my internet won’t launch” or even from President Bush in the debates, “I hear there’s rumors on the Internets…” The fact is that part of the reason Internet Explorer has a 95% market share right now is that Microsoft has successfully reduced the concept of the internet down to a postage-stamp sized icon on your desktop.

You want to get people using Firefox? You need to do a lot more than just coerce them into clicking a “Download Now” link. You need to educate them on what a browser is and why it’s not a “different internet” but rather a different agent between them and the internet. It’s a tricky proposition because this revelation definitely adds a layer of complexity to a user’s perception of the internet, but at the same time, it’s an important layer to know about. It is an assistive layer, a navigational layer, and most importantly a protective layer. And so, the best way to introduce this layer is to succinctly spell out its advantages, as has been done very nicely on the Browse Happy site.

Isolation of the rendering engine

I separate a browser upgrade into two parts: The interface and the rendering engine. The interface is everything outside the viewport and the rendering engine is everything inside of it. For the most part, the interface is completely localized and does not materially affect the display of web content. It lets you do things like print a page, add a bookmark, or toggle between windows. The rendering engine, however, radically affects the display of web content and is codependent on things like HTML, CSS, and and Javascript in order to do its job. It is this sometimes-symbiotic, sometimes-antibiotic relationship between the rendering engine and the code we develop for it which causes the majority of headaches in web developers’ lives and retards web publishing by years at a time.

As much as I like tabbed browsing, more sophisticated autofill, and better bookmark organization, these are clearly user interface features within the browser itself and I’m happy letting users decide if and when to apply the upgrades which introduce them. But as for the rendering engine, I feel like this is the sort of thing that should be applied automatically every 1-2 years or at least pushed in front of the user in a persuasive yet polite way… a la Flash.

“We’ve noticed your browser needs to be quickly tuned. The necessary components have already been downloaded. Click here to tune-up.”

What got me thinking about this was one day several months ago when I launched my MSN Messenger client and was greeted with the message “Due to security upgrades, you must upgrade your version of MSN Messenger to 4.8 in order to log into the MSN Instant Messenger network”. Wow! As long as this doesn’t happen too often (it’s happened only once to me), it’s a spectacular way to get everyone on the same page. I bet Microsoft was able to upgrade their entire population of MSN IM clients within a month or two since the upgrade was more or less mandatory. Why do we settle for any less in browsers? If we could limit automatic updates to the rendering engine alone, users could scarcely argue that an upgrade was any sort of risk.

Furthermore, if this sort of reliable upgrade cycle started in the 90s, where would we be right now? CSS-7? We’re already at Flash 7. Look at all the progress that has been made between Flash 2 and Flash 7 and apply even 50% of that progress to the browser space. Would it cause more frequent redesign cycles for web sites? Sure. But all that does is create jobs in the industry and it is certainly a legitimate investment in technology. Instead, companies are spending their money producing commercials with sock puppets. Additionally, when HTML and CSS specs are written, they are usually written in such a way which does not infringe on existing sites. Therefore, a company may still wait however many extra years they want before redesigning… they will just be missing out on possible extra site features.

Setting the standards

The specter of automatic, benevolent rendering engine upgrades re-introduces the question of control. If Safari, Mozilla, Opera, and IE are to release upgrades around the same time which introduce roughly the same rendering engine enhancements, clearly one of two things needs to happen:

1. The W3C needs to draft a Kyoto Treaty of sorts and convince all major players (currently 4) to apply W3C recommendations to their rendering engines on perhaps a biennial basis. The W3C would draft the specs, the browser makers would have a month or two to discuss it and offer revisions, and then the final spec would be delivered. The spec would never be considered a finished product and thus it would never be committeed to death in the pursuit of perfection. How is this different from what happens today? Easy. There is currently no agreement and there are no hard timelines. We are dealing in recommendations which may or may not manifest themselves at some point in the future and that is why we see such slow progress. If someone asked you right now when you’d expect multi-column text flow to be supported in 90% of browsers, what would you say? I couldn’t even make a guess. If someone asked me when they could expect alpha-maskable Flash video to be viewable by 90% of the population, I could almost tell them the exact month.
2. Representatives from the four major players in the browser world could just get together and decide on this stuff themselves. I’m not talking about a room full of people. I’m talking about a tent full of people. Camp David style. If they were smart, they’d expand the group with a Doug Bowman, a Shaun Inman, or other persons of noble repute, but the group would have to stay intimately small to be effective. Additionally, there would be little tolerance for idealism if it impeded speed. XML purists need not apply. The WHATWG is the closest thing I see to this right now. They are a small group self-charged with readying specs for next-generation web applications, and in many cases, they are the exact people I’d want on this board — people with the power to walk into their companies and order immediate product changes.

Some people will look at these two options and wonder if all parties would actually agree to such things. Well, maybe not, but I’m pretty sure 3 out of 4 would agree to some degree of it, and that’s enough to eventually push the 4th into irrelevance or acquiescence. If the recent success of Safari and Firefox has shown us anything, it’s that “open” wins in the long run, and if you aren’t producing what the community wants, the community will eventually not want you.

Backwards compatibility

The bane of the web developer’s existence, in many ways, is backwards-compatibility. It is important, however, to separate the concepts of backwards-compatibility in browsers and backwards-compatibility in code. If Mozilla, Apple, Opera, or Microsoft were to release a new browser, it must clearly be backwards-compatible with existing web sites which use older coding standards or just very poor coding practices. Without this backwards-compatibility, no one would adopt a new browser. Both Mozilla and Opera have struggled with this issue over the past few years, with plenty of sites (well built or not) not displaying properly in them. But now that smart error-tolerances have been built in, Mozilla and Opera are a joy to use. Standards purists will say that new browser versions shouldn’t have to deal with error tolerances and that web developers should just always build error-free sites, and they are right… but they are also ignoring the reality that most web sites will not be 100% standards-compliant for quite some time, if ever. Validation aside, there is other error-correction necessary in browsers related to various CSS quirks and how they affect the display of content on page.

So, backwards-compatibility in browsers is a must, and it will likely always be. But what about backwards-compatibility in code? This is going to make some people mad, but I have to admit that I am not for 100% backwards compatibility in code, in perpetuity. Let’s say I have an audience of 100 people who visit my site. Let’s say if I code and design with method A, it will produce good pages viewable by all 100 people. Now let’s say that if I code and design with method B, it will produce GREAT pages viewable by 99 of the people. The one person who can’t view my pages is maybe clinging to their copy of Netscape 4. How many people would choose method A? I wouldn’t. I’d choose method B, because the aggregate amount of quality I’m producing for my audience is worth losing one audience member over. Now, my example is assuming a 99% success rate. What is the lowest you’d go? Clearly, different people have different thresholds. I think most people would fall squarely in the mid to upper 90s. 97%, 98%, 99%… around that area. So if you’re going to forsake 100% backwards compatibility in code, as I do, the whole goal of increasing the pace of web standards improvement becomes a lot more attainable. After all, as with Flash, it may only take months to reach the 90% penetration rate, but it may take a lifetime to reach 100%.

* In making a decision to drop support for certain user agents, it is obviously important to do your homework first. Different sites call for different practices. For example, an e-commerce site may lose a lot of money if only one customer cannot access the site… whereas an ad-supported site does not share this concern. This is part of the reason why the eBays and Amazons of the world still code the way they do.

In digesting these views on backwards-compatibility, please keep in mind that I am not advocating throwing user accessibility aside in any shape or fashion — only user agent accessibility. What does that mean? If a person cannot see a web page because their vision is impaired, I have sympathy for them. I want to design and code in such a way that helps them. But if a user cannot see a page because they are too unmotivated to stop using Netscape 4, I really don’t have any sympathy for them. A bit of pity, maybe, but definitely not sympathy. In fact, I feel like these people would be better off in the long run if every web site in the world turned them away at the door (as is starting to happen). Now, some people will just say “Build your site in such a way that it degrades gracefully in these sorts of browsers”. To that, I say fine, if your site is heavily text-oriented and stylistically sparse. But if you want to do things on your site which require some of the newer W3C standards and other interactive touches, the reality is that your site just may not degrade very well. Other people will say “Well just serve an unstyled page to these users”. Again, I say fine, but does anyone really enjoy sites with completely unstyled content? If you’re a layout-intense media site, your “unstyled” site is going to look and feel a lot worse than Yahoo’s intentionally sparse site, so the 1% of users who may see your unstyled page are probably better off going to Yahoo.

My point here is that I feel like for most sites, using modern coding standards with perhaps a tad less backwards-compatibility is okay to do. It’s your site. Why let such a tiny percentage of people dictate how you design and code it?

By the way, as a further footnote to this point, I am also not saying it’s ok to say things like “Okay, my audience is 95% PC IE so I’ll just code for that.” That is NOT the message. The message is, “Let’s speed the adoption rate of W3C standards and let’s also speed the rate at which we apply them on our own sites.” If that causes a few more people to upgrade browsers before they’d like to, so be it.

In most cases, you are providing your site to the world completely on your own volition. As much as people would like to believe otherwise, it is not the right of every citizen to be able to view it. If you wanted to, you could write your whole site in gibberish or you could password-protect the entire thing. It doesn’t matter. It’s your right to do so. The notable exception here is government agencies, who are required to provide certain information to all citizens within their region. The other notable exception, of course, is in matters of accessibility. Just as one should not discriminate on race, creed, color, or sex, one should not discriminate on disability. So before anyone comments on that, let’s be clear that when I suggest perhaps ditching some backwards-compatibility, accessibility is not part of what should get ditched. In fact, by adopting new accessibility standards, accessibility should actually be improved. Should we really be using all of these counter-intuitive image replacement techniques? With better standards and faster adoption of said standards, we can ditch the need for these tricks.

Next steps

So what can we do to help radically speed the adoption of better browsers and gradually raise the backwards-compatibility bar? Here are a few suggestions:

1. Help spread Firefox to every computer you can get your hands on. I’m talking about your parents’ computers, your coworkers’ computers, computers in public spaces, etc. Don’t just download it. Install it, import everything you can, and place its icon where the old browser’s icon was. Obviously don’t remove any old browsers, but make it as easy as possible for users of said computer to subtly modify their browsing routine so that it goes through Firefox. In cases where education is necessary, take a few minutes to explain why switching is a good thing. Use hyperbole when necessary.
2. Design and code your sites specifically with modern web standards in mind. Most of your testing, up through completion of the layout, should be done in standards-compliant browsers like Safari and Firefox, and then you can add whatever hacks you need after that to massage the layout into other browsers. I find these days that the only hack I generally even need is the underscore hack, which is extremely easy to implement.
3. If you are faced with a choice between forward-looking code and backward-looking code, choose forward-looking in all cases except where a significant portion of your audience may be alienated. A quick example of this is the Netscape 4 example. If 1% of your audience uses Netscape 4 and designing a Netscape 4-friendly layout creates 30% more work and 30% more code and isn’t as pure as you’d like it, consider ditching Netscape 4 compatibility. Go ahead and serve them an unstyled page if you’d like, but don’t get hung up on how it looks.
4. Continue to push the limits of the web and exert pressure on browser makers to continuously improve their products. I am so happy with how far Mozilla and Safari have come in the last couple of years and I’d love to see the momentum continue. Rendering current sites beautifully is a great start. Rendering future sites even more beautifully is the overriding goal. Give us drop-shadows for arbitrary objects. Give us multi-column text flow capabilities. Give us the ability to clear absolutely positioned divs. Without designers and developers clamoring for these improvements, we’ll enter another period of stagnation. Don’t settle for simple text-based bloggish layouts for everything you do. I, along with Shaun Inman, Tomas Jogin, and Mark Wubben, invented sIFR to give people richer, more beautiful typography on the web; but another reason we invented it was to show precisely how silly it is that it’s even necessary. Now that there are sites out there which make beautiful use of it, browser makers and standards bodies have at least a working model of what people are looking for.
5. Create the Rapid Browser Improvement Delta Force (or R.B.I.D.F.) I mentioned earlier in the article. I’m serious when I say that I’d rather have a handful of representatives determine actionable browser improvements and then immediate act on them than wait for initiatives work their way through years of committees only to result in hopeful recommendations. Please know that this is not a knock on the incredible amount of thought and effort coming from these committees… it is just a realization that sometimes the more people who are involved in a decision and the more perfect these people try to make that decision, the slower things tend to move. Sometimes you don’t need perfect decisions… you just need helpful, swift ones. If anyone has suggestions for such a panel of people, please post them in the comments. 10 or less people sounds about right to me.

Conclusion

I realize that some of my thoughts on browser development are a bit naive (seeing as I have never developed one myself), but I’ve been in this industry long enough to know that the inability for us to use newer coding standards shortly after they are released is largely self-imposed. We settle for browsers which don’t upgrade their rendering engines transparently, we settle for specifications which take too long to pass through large committees, and we settle for coddling to the 1% of the population who doesn’t see fit to upgrade with the rest of us.

We need to quit settling.

Do your part by helping spread standards-compliant browsers like Firefox, Safari, and (sometimes) Opera to as many computers as possible. With a little bit of help, I think we can obliterate this ultra-conservative 10% prediction by the end of 2005. Don’t stop with browser proselytizing though. Gather usage statistics on your site and plan migration strategies for a move to more modern code. If you reckon you’ll be able to dump support for Browser X in 12 months, begin laying the groundwork right now. And finally, keep pushing the boundaries of web design and development so that the people up in the hills who write stuff into stone know that we’re not going to wait for what’s right when we can have what’s right now. We need to get web publishing back on the fast track, and by rapidly speeding both the evolution and the adoption of modern web standards, we can create an efficiency and innovation boom this medium has never seen.

Incoming search terms for the article:

• can i speed up my browser
• old computer browser
• best browser on blackberry
• light browser for old computers
• pc running slow when browser is started

Incoming search terms for the article:

• why does my computer shutdown unexpectedly

203 Responses to “Can We Speed Up Browser Evolution?”