![\"\"](\"\/blog\/images\/inline\/evolution.jpg\")
<\/p>\n<\/p>\n
So I just read the statement from the Mozilla Foundation<\/a> which predicts 10% of the world’s web browsers will be Mozilla-based by the end of 2005. While some people seem pretty excited<\/a> 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. 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.<\/p>\n 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.<\/p>\n 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<\/em> 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.<\/p>\n * 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.<\/em><\/p>\n 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.<\/p>\n Compare this to a Flash upgrade. Flash is completely transparent to the user. There is<\/em> 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.<\/p>\n 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.<\/p>\n 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<\/em> 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.<\/p>\n 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<\/a>.<\/p>\n 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<\/em>.<\/p>\n 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.<\/p>\n “We’ve noticed your browser needs to be quickly tuned. The necessary components have already been downloaded. Click here to tune-up.”<\/p><\/blockquote>\n 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.<\/p>\n 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.<\/p>\n 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:<\/p>\n 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.<\/p>\n 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<\/em> and backwards-compatibility in code<\/em>. 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.<\/p>\n 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%.<\/p>\n * 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.<\/em><\/p>\n In digesting these views on backwards-compatibility, please keep in mind that I am not advocating throwing user<\/em> accessibility aside in any shape or fashion — only user agent<\/em> 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.<\/p>\n 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?<\/p>\n 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.<\/p>\n 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<\/em> 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<\/em> 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.<\/p>\n 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:<\/p>\n 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.<\/p>\n We need to quit settling.<\/p>\n 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<\/em> when we can have what’s right now<\/em>. 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.<\/p>\n","protected":false},"excerpt":{"rendered":" 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…<\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[282,39],"tags":[],"class_list":["post-44","post","type-post","status-publish","format-standard","hentry","category-original","category-technology"],"_links":{"self":[{"href":"https:\/\/mikeindustries.com\/blog\/wp-json\/wp\/v2\/posts\/44","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/mikeindustries.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mikeindustries.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/mikeindustries.com\/blog\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/mikeindustries.com\/blog\/wp-json\/wp\/v2\/comments?post=44"}],"version-history":[{"count":0,"href":"https:\/\/mikeindustries.com\/blog\/wp-json\/wp\/v2\/posts\/44\/revisions"}],"wp:attachment":[{"href":"https:\/\/mikeindustries.com\/blog\/wp-json\/wp\/v2\/media?parent=44"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mikeindustries.com\/blog\/wp-json\/wp\/v2\/categories?post=44"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mikeindustries.com\/blog\/wp-json\/wp\/v2\/tags?post=44"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\n<\/p>\nLeadership and control<\/h3>\n
Transparency of operation<\/h3>\n
Ease of upgrade<\/h3>\n
Isolation of the rendering engine<\/h3>\n
Setting the standards<\/h3>\n
\n
Backwards compatibility<\/h3>\n
Next steps<\/h3>\n
\n
Conclusion<\/h3>\n