328-firefox-4

Firefox’s rapid release schedule has not been the success Mozilla hoped. Most web developers agree it’s good for HTML5 feature evolution but it’s not without problems:

  • Add-on compatibility. Most of us use extensions which cannot keep up with Firefox’s development progress.
  • Increased effort. The majority of IT departments must test mission-critical applications before a browser update can be deployed throughout the enterprise.
  • Confusion. Few people understand the rationale behind major version increments. Why shouldn’t Firefox 6 be version 4.2?

Mozilla is replicating Google’s release model but Chrome does not necessarily exhibit the same problems. It’s add-ons system is far simpler; more akin to bookmarklets than integrated code. The browser also has fewer legacy hurdles and has silently updated since the early days. Those using Chrome either understand this concept or don’t care.

One solution Mozilla considered was the removal of version numbers from Firefox’s “Help > About” dialog. Mozilla’s logic:

  1. Few users understand version numbers.
  2. Removal would simplify the UI.
  3. Users would be informed when the last check occurred, whether they were using the latest version, and how they could update (if Firefox had not automagically done so).
  4. If you really needed the version number, it could be found in about:support.

Uproar ensued on Bugzilla and the associated newsgroup discussion. The majority of respondents detested the idea (although a large volume of ranting and spam appeared when Mozilla’s intentions went public).

The organization put forward some reasonable arguments but ultimately backed down. Mozilla’s Robert Kaiser:

Can we close this bug report?

Version numbers in software are like coordinate systems in physics: irrelevant and necessary at the same time — it’s completely irrelevant how you do them, but they provide necessary reference points. Not more, not less.

Where ever we go with this, I don’t think it will have either a large impact on version number messaging or on making Firefox useless, so I think the rage on both sides is overrated.

The reply from VanillaMozilla:

Done … I’m having a hard time finding anyone at all who thinks this is a good idea.

The argument become overheated but Mozilla’s proposition had a number of flaws:

  1. It went against established UI conventions that span OSes and 20+ years of IT development. There may be better ways, but removing version numbers is not likely to be the best solution.
  2. The proposal was too simplistic and did nothing to tackle Firefox’s rapid update issues. Version numbering was never the cause or the cure.
  3. Users may not understand version numbers, but removing them was a non-issue. Firefox wouldn’t suddenly become easier to use.
  4. There are multiple versions of Firefox in the wild. Some would have version numbers, some wouldn’t. None of the older editions would state they were out of date.
  5. Version numbers are important to developers and IT support staff. What’s the first question you ask when someone reports a problem in a specific browser?

Version numbers have been rendered meaningless in Chrome and Firefox. Few people know or care what version of Chrome they’re running. Perhaps, one day, the same will be true for Firefox — but we’re not there yet.

Firefox is an older browser with far more baggage and a large, passionate user community. Mozilla ultimately listened to their demands, but the the proposal and subsequent onslaught did nothing for the browser.

522-browser-trends

Despite the ongoing Firefox releases, the browser market has remained quiet during the summer months.

So here are the latest statistics. I’ve changed the table so Firefox 4, 5 and 6 are amalgamated into one; it makes little sense to analyze the separate figures since most of those users update their browsers as new versions appear:

BrowserJulyAugustchangerelative
IE 9.07.27%8.05%+0.78%+10.70%
IE 8.026.30%25.68%-0.62%-2.40%
IE 7.05.45%5.07%-0.38%-7.00%
IE 6.03.42%3.09%-0.33%-9.60%
Firefox 4.0+17.66%18.10%+0.44%+2.50%
Firefox 3.6-10.30%9.39%-0.91%-8.80%
Chrome22.17%23.17%+1.00%+4.50%
Safari5.15%5.18%+0.03%+0.60%
Opera1.66%1.67%+0.01%+0.60%
Others0.62%0.60%-0.02%-3.20%
IE (all)42.44%41.89%-0.55%-1.30%
Firefox (all)27.96%27.49%-0.47%-1.70%

The table shows market share estimates for desktop browsers. The ‘change’ column shows the absolute increase or decrease in market share. The ‘relative’ column indicates the proportional change, i.e. another 9.6% of IE6 users abandoned the browser last month. There are several caveats so I recommend you read How Browser Market Share is Calculated.

IE9 had another good month. Its progress is remains relatively sedate, but there are two solutions if Microsoft want massive adoption:

  1. Offer Windows 7, the hardware which runs it, installation, migration and training services to everyone. For free.
  2. Alternatively, release a version of IE9 which is compatible with XP. The other vendors support XP and still manage to offer fancy features such as hardware acceleration. And CSS3 text shadows.

IE’s overall drop has slowed a little this month, but I suspect that’s a statistical blip while business users enjoy a summer break.

Firefox 4/5/6 is rising but not at the pace Firefox 3/2/1 is falling. While the rapid releases are mostly good, users are becoming frustrated with add-on compatibility failures and memory usage problems on Mac OS. Mozilla is addressing the issues but they’re losing users who may never return.

There’s little to report for Opera and Safari. Both browsers made modest gains, but neither is setting the market alight.

That leaves us with Chrome. It’s the same story: usage continues to grow at 1% per month — sometimes more. If the current trend continues, Chrome will overtake Firefox in December 2011. It’s already occurred in the UK where Chrome has 23.41% lead over Firefox’s 21.75%.

Personally, I like Chrome and regularly recommend or install the browser; it’s fast, simple, stable and updates without fuss. However, I primarily use Firefox (on Windows 7) because it has a range of essential add-ons for power-surfing and development. I thought others would think the same but, having asked the question on Google+, it appears not. Developers are switching to Chrome in droves. Mozilla is losing the technical evangelists who once promoted Firefox.

Mobile Browser Usage

Desktop browsers account for 92.88% of web activity. The remaining 7.12% is mobile access and it’s evident more people are using their phones for general web browsing. The applications they primarily use are:

  1. Opera Mini/Mobile — 21.61% (down 0.46%)
  2. Android — 19.72% (up 1.55%)
  3. Nokia browser — 16.99% (down 0.11%)
  4. iPhone — 14.91% (down 0.19%)
  5. Blackberry — 11.64% (down 0.66%)

Note there are significant regional variations:

  • In the US and Canada, Android takes the top spot with 34.2% followed by the iPhone with 26.1%. Opera accounts for less than 4%.
  • The iPhone is most popular in Europe at 33.7% with Android second at 23.7%.
  • For Oceania, the iPhone has an almost monopolistic lead of 56.7%. Android is way behind at 19.4%.
  • It’s Asia, Africa and South America where Opera and less-expensive Nokia devices reign supreme.

Remember that these figures are collated from internet access — not sales trends. Users with an older mobile are less likely to use the web than those with the latest 3G handset. That said, in the developing world, users may not have access to a PC so mobile is the only option.

506-google-page-speed

Google has announced their new Page Speed Service. In essence, it’s a combination of proxy servers, Content Delivery Networks (CDN), and web page optimizers which Google states will produce speed gains of 25-60% for most websites.

The service is being offered to a limited set of web developers at no cost. After the trial period, Page Speed will be released to everyone and, although there are no details, “pricing will be competitive” (source: Official Google Code blog).

To use the service, it’s simply a matter of registering and adding a new DNS CNAME record to your domain. As well as providing a gzipped proxy server for static files, the service can also rewrite your pages for web performance best-practices:

  • CSS files can be combined, minimized, and moved to the HTML head
  • JavaScript files can be combined and minimized using Google’s Closure Compiler
  • images can scaled and optimized

All features are optional so you can, for example, disable the Closure Compiler if it breaks your JavaScript code.

Google provides a page test comparison service at www.webpagetest.org/compare. It estimated that SitePoint.com’s home page would enjoy a 13% speed increase — I suspect that’s primarily owing to JavaScript file concatenation.

Tremendous or Troublesome?

Depending on the price, the Page Speed Service could be ideal for inefficient static pages running on slow servers. It may be more cost-effective than spending money on further development or hosting.

Unfortunately, there are a few downsides:

  • Bare domains are not supported, i.e. you must use www.domain.com rather than domain.com. That’s a shame — I’ve been dropping the “www” from my sites.
  • HTTPS pages are not supported.
  • Flash, streamed audio, streamed video and files over 50MB are not supported.
  • POST requests greater than 2MB are not supported.
  • You’re unlikely to experience significant speed gains on web applications running server-side code.
  • Domains hosted on Blogger, Google Sites or Google App Engine are not supported.

Speaking as a web developer, the service makes me slightly uncomfortable. Like many, I ensure my sites are optimized by combining files, minimizing the code, reducing HTTP requests and using CDNs where possible. For Page Speed to be attractive, I wouldn’t want to lose control, configuration would have to be easy, I wouldn’t want my code to be rewritten, and the price would have to be cheaper than upgraded hosting.

Risk is another factor which needs to be assessed. Will Page Speed offer additional redundancy or two points of failure? I suspect it will depend on the quantity of static vs generated content on your website.

Finally, are you willing to hand your website keys to Google? Their services are more reliable than most, but this is a new product which could experience teething problems. Conspiracy theorists will also see this as another step toward Google’s global domination. Google Search considers page speed factors so could the company become an all-powerful web host which undermines sites not using their network?

Technically, Google Page Speed an amazing solution which should boost the download speeds for most sites — especially those which are inefficiently coded. However, I’m not convinced many good web developers will adopt it. And would bad developers understand the service or care enough to recommend it?

Time will tell if Google’s Page Speed Service is a success. Please let us know your opinions…

549-ie10-conditional-comments

Microsoft added many features to Internet Explorer over the years. Several revolutionized the web forever (XMLHttpRequest, the DOM, XML tools, font embedding, browser add-ons). Some never caught on. Some were truly awful.

The team intends to remove several of the less-successful legacy features in IE10 (perhaps they read #7 in 10 Ways Microsoft Could Make Us Love IE Again?) I suspect you’ve never coded XML Data Islands and Element Behaviors, but you’ve almost certainly used Conditional Comments. They’re about to disappear from IE forever.

Conditional Comments 101

Ensuring you web site or application works in all browsers is tough. It’s made particularly difficult when you have to support older editions of Internet Explorer. IE6 was released in 2001, IE7 in 2006, and IE8 appeared in 2009. Whatever your opinion of Microsoft, it’s unreasonable to expect a 10 year old browser to render the same as Firefox 5 or Chrome 12.

Web developers are particularly scathing about IE6. Many months are spent building fantastic web sites and applications only to find they break in IE6 at the eleventh hour. Fortunately:

  • IE6 bugs are well-documented and it’s possible to overcome the majority of issues — especially if you test early and often.
  • Microsoft provide Conditional Comments so developers can add custom CSS and script fixes which target a specific version of IE.

Examine the source of almost any HTML5 page and you’ll find this code in the head:


<!--[if lt IE 9]>
<script src="http://html5shiv.googlecode.com/svn/trunk/html5.js"></script>
<![endif]-->

It loads a shim in IE8 and below which allows the developer to style new HTML5 elements such as header, article, and footer. It’s not required in IE9 and other browsers with native HTML5 support — they ignore the script.

Conditional Comments are incredibly useful but, personally, I always felt a little uncomfortable using them:

  1. They smell a little like browser sniffing — which stinks.
  2. They’re rarely necessary. The majority of IE6 problems can be solved with a display:inline; here or a position:relative; there. While competing browsers don’t require those properties, they don’t have a negative impact other than a few bytes of extra bandwidth. I prefer my CSS properties in one place rather than distributed between two or more files.
  3. Conditional Comments are abused. I’ve had the misfortune to work on systems where developers created three or four separate stylesheets which targeted individual browsers. Simple property updates required changes to every file.

Why Remove Conditional Comments?

IE8 is normally well-behaved and you’ll only require the HTML5 shim (see above). With a few CSS3 exceptions, IE9 renders as well as any other browser. Hopefully, IE10 will catch-up — or even overtake — Firefox, Chrome, Opera and Safari.

Conditional Comments are not required. There’s no need for “[if IE 10]“ because pages will render (mostly) the same in all modern browsers.

That said, it’s not the end of feature detection and progressive enhancement. Not every browser supports CSS3 transformations, web sockets, geo-location and client-side storage. Even with support, the user can often disable or refuse permission for an operation.

In addition, Conditional Comments will not disappear from IE6, 7, 8 and 9. You can still target those browsers should the need arise but it will become less necessary over time.

I applaud Microsoft’s decision. It’s a bold move since they could have easy kept Conditional Comments and I suspect its removal will horrify some developers. However, the company is adhering to its “same markup” philosophy and ensuring HTML, CSS and JavaScript just work regardless of the browser or version.

It’s the right thing to do. Let’s hope the demise of ActiveX, Compatibility View and the old IE7 toolbars won’t be too far behind!

As we move though the book, we’re going to meet some relatively complex code for recreating native effects and behaviors. Thanks to some (fairly) standard hooks and APIs, however, there are a few tricks we can employ to add a bit of pizzazz to our apps without having to do much work at all. 3.1. Nifty Links For security reasons, mobile web applications are sandboxed away from many built-in features of the mobile device; for example, unlike native apps, they’re not able to retrieve a list of a user’s contacts, or take a photo with the device’s camera (yet).

Read More:
BuildMobile: Mobile Web Apps: Quick Wins

531-banishing-url-bar

Google wants Chrome to be a clean distraction-free browsing experience. They’re possibly about to take their most radical step yet. Interface minimalism will reach it’s ultimate zenith with the removal of the address bar.

Madness?

Perhaps. But Mozilla are considering the same UI move.

The idea has received an overwhelmingly negative response from technical users. However, before you reach for your soapbox, be aware that it’s only a proposal which may never see the light of day. If it does happen, it will almost certainly be an option and “compact view” might only be permitted on application tabs. When enabled, the user may have to double-click a tab to view the URL.

So why does Google think a 30-pixel gain is so important? It would provide an extra 5% of space on some tablet and netbook screens, but there are deeper reasons…

I use the address bar. You probably use it too. But many users don’t. Non-technical users rarely understand URLs; it’s plainly obvious when you observe them type www.whatever.com into Google’s search box. So why retain a feature few people use?

We should also consider how web use is changing. We know the browser is a separate application but it’s likely to evolve as operating system vendors attempt a more integrated approach. Icons, application tabs and pinned sites are just the start. The distinction between online and offline is already blurred and, within a few years, users won’t know or care where an application resides.

There’s also been a noticeable shift in internet marketing. While companies still promote their URL on advertising media, many now publish more memorable search keywords for Google or Facebook.

Finally, there are commercial incentives. Without the bar, users must resort to a search engine; they’ll aways see a page of results and revenue-paying adverts before reaching their destination.

But what about the drawbacks? If you can’t see the address bar, it’s more effort to enter a URL. If users really don’t want the bar, it can usually be hidden or they can switch to full-screen mode (F11 in most browsers).

Web developers also depend on the URL — especially when testing web applications or REST services. Removing the bar will make our lives more difficult.

Finally, without the address bar, it’s more difficult to ensure you’re on the correct site or check security settings. Those involved in phishing scams will be eagerly anticipating the UI change.

The idea makes me uncomfortable. Users may not understand URLs, but removing the bar won’t help them learn. I’m sure many car drivers don’t understand hydraulics but that’s not a reason to remove their brakes (OK — bad metaphor, but a web without URLs is not without danger).

I’m all for UI simplification, but this seems like a step too far. If it happens, Google should rename their browser: “Chrome-less” would be more apt.

What do you think? Should the address bar go? Could it be an option? Are the risks too great?

Thumbnail

This is an excerpt from the upcoming book “Build Mobile Websites and Apps for Smart Devices” by Earle Castledine , Myles Eftos and Max Wheeler . Over the coming weeks BuildMobile will exclusively publish a complete chapter from the book, the chapter on Mobile Web Apps. Enjoy.

More:
BuildMobile: Mobile Web Apps: Setting Up Shop

Napster founder and Facebook founding president Sean Parker lashed out at the movie The Social Network at a conference in Europe today, calling it “a complete work of fiction.”

As you can see in the video above (skip to 5:20 for this part), Parker admires the production values of the film, but objects to the way his character was portrayed. He particularly dislikes the scene where he writes a check to Facebook co-founder Eduardo Saverin:

“The part of the movie that frustrated me is actually the scene at the end where the character played by Justin Timberlake — who happens to have my name — basically writes a check to Eduardo – who I’m also, I consider Eduardo a friend of mine, and I’m one of the few people at Facebook who still interacts with Eduardo – and throws it in his face and has security escort him out of the building. And I mean, that’s just rude. This guy in the movie is a morally reprehensible human being.”

Parker made the remarks in an on-stage interview at the DLD Conference 2011 in Munich, which started today.

In an interview with Mashable three months ago, Zuckerberg wouldn’t say whether he liked the film or not, but thought its audience size was minuscule compared with Facebook’s: “We build products that 500 million people see… If 5 million people see a movie, it doesn’t really matter that much.”

[via YouTube/KiTTGTR]

More About: discussion, DLD Conference 2011, facebook, interview, quote, sean parker, the social network, trending, video