Robert Accettura's
Fun With Wordage

Apple’s MobileMe will not support IE 6. Per an email to subscribers:

To use the new web applications, make sure you have one of these browsers: Safari 3, Internet Explorer 7, or Firefox 2 or later.

37signals is now doing the same, and will be dropping IE 6 support.

For most things that I’m in developing, IE 6 still has to much market share to ignore. That said, I can’t wait until the day we can kill IE 6. It’s from a previous generation of web browsers. It’s time for it to go.

Considering IE 7 is a free upgrade, or you could download the awesome Firefox 3, or Safari 3 it’s about time. I suspect we’ll see more and more sites start to do this, and likely in 2009 see some larger mainstream products no longer support IE 6.

It’s great to see the process starting. I can’t even begin to estimate the hours I’ve wasted getting IE 6 to work with something trivial on all other browsers.

The advantage of killing some old browser support is that it’s easier to take advantage of some of the features in more modern browsers that have much more robust features and better CSS support. Not to mention PNG transparency that doesn’t suck.

Modern web browsers like Firefox invest a lot into features to allow for a better web experience. Killing support for old browsers means they can be used. It’s the start of a better web.

John Resig has an interesting blog post on embedded JavaScript. It’s something I’ve been thinking about for a little while.

It would be awesome to see a PHP extension to embed SpiderMonkey into PHP. As far as I’m aware Facebook is the only one that’s taken a step in that direction with FBJS, which uses Mozilla source code. Perhaps that could be a starting point.

Considering the ubiquity of JavaScript, using SpiderMonkey, which is already available for Perl and Python, or Rhino (for Java) would make sense. It would allow for JavaScript to be for logic what XML is for data. In my mind that is nirvana for the web.

XML made our data portable. JavaScript can make our logic portable. Seems practical enough right?

For those who question security, it’s really up to the client to decide if it should parse JS, and what subset it should allow (perhaps no eval()). Having an API based on JS is really no less secure than any other language including one that’s home made. It’s advantage is that it’s used everywhere else and makes your API easier to work with.

This could be cornerstone of Web 3.0. Web 2.0 was largely about shared data and isolated small services. Web 3.0 could be about shared data and shared services.

As a frontend developer I’ve long argued the magic formula for a good website is:

Usefulness + Speed = Users

This is based on the fact that the best websites on the internet are pretty spartan in appearance. When you look at many of the successful ones (Google, Yahoo, Craigslist, Facebook), they’ve all taken the approach of simplicity on the frontend. They keep the user interface as minimal as possible, and they keep the technology and code as minimal as possible.

An interesting quote from CNet:

The same effect happened with Google Maps. When the company trimmed the 120KB page size down by about 30 percent, the company started getting about 30 percent more map requests. “It was almost proportional. If you make a product faster, you get that back in terms of increased usage,” she said.

Emphasis mine.

Just goes to show that faster things become more than useful to users. They become a convenience. Users don’t really care how it looks or they would have switched from boring Google a long time ago. They just find it so convenient and quick they can’t stop using it.

I suspect this is why digital clocks are so popular.

Most people find an analog clock to be “classy”, in particular when there are roman numerals. But when you come down to being practical, they aren’t as quick to read for most people since we rarely deal with roman numerals. The solution used to be using Arabic numbers to increase usability and speed:

This is better, but not perfect. Still slow to read, and your estimating the minutes. These days, we have the technology to produce low cost digital time readouts with Arabic numbers. These are more accurate since they show the minutes, and maybe even seconds, and can be read at a glance with almost no effort.

Despite hardly looking fancy, this is what you see in most train stations, airports, etc. The older clocks are still around, but mostly for aesthetic purposes. People are willing to sacrifice looks for convenience. That’s why they walk around with digital watches rather than the more classy ones. Both can be found for cheap, but one can easily be read (even with poor vision, and in the dark).

Simplicity always rules. Unless your a nerd with a binary clock (which is cool).

I suspect this rule also holds true for software. If it’s faster, people are more inclined to use it. People moved from IE 6 to Firefox because it’s faster. Given that Firefox 3 is even faster… I’m hoping this trend will be proven yet again with an improved adoption rate.

Another upcoming test of this principle will be the Apple’s 3G iPhone. Will the average number of minutes browsing the web increase with the additional speed of a 3G network? Will faster performance make people use the device more? I suspect so. I also think it will increase adoption as many people were turned off on the idea of spending that much for EDGE. For 3G, that’s a different story.

It’s really pretty interesting stuff. People often associate usability with user interface design, and never performance. But that data really does seem to point to performance being one of the easiest ways to make a product more usable.

Images: Grand Central Terminal clock © 2004 Metropolitan Transportation Authority, Clock in Kings Cross, LCD Clock Grey via Wikipedia

It’s happening again. Once upon a time, browser vendors started adding their own features without consulting with each other and agreeing upon standards. What they created was a giant mess of inconsistencies across browsers and platforms that is still in effect today. Ask any web developer and they can tell you of the pains that they have suffered trying to make seemingly trivial things work everywhere consistently. It’s no easy task. Before IE 7, even an ajax required something along the lines of:

var httpRequest;
if (window.XMLHttpRequest) { // Mozilla, Safari, ...
    httpRequest = new XMLHttpRequest();
} else if (window.ActiveXObject) { // IE
    httpRequest = new ActiveXObject("Microsoft.XMLHTTP");
}

That’s right, IE 6 didn’t support the native xmlHttpRequest object (more here). This is just one of many examples in JavaScript and CSS. document.all anyone?

The end result of this problem became to be known as the “Web Standards” movement. Simply put it’s an idea that code should follow a standard that results in consistent output across all browsers on various platforms. Write once, run anywhere. While it’s taken years for this to manifest, it’s slowly become a reality. Firefox, Safari, Opera have fairly consistent rendering (at least in comparison to the mess of just a few years ago on the browser scene. IE 6 was fairly poor in terms of modern web development, but IE 7 made progress, and IE 8 is Microsoft’s greatest effort to date to bring their browser up to speed.

(more…)

As a heads up to developers, Cross Site XMLHttpRequest (XHR) has been removed from Firefox 3, despite being in earlier betas. To quote a draft relnote from Mike Beltzner:

Due to late changes in the Cross Site XMLHttpRequest specification which made our implementation incomplete, it was decided to remove support for this technology rather than include only partial support.

Hopefully things will be more stable by the next release and it can be re-included.

There are still quite a few websites that use a Favicon on a white background. While this looked OK in older browsers, these day with browsers like Firefox 3.0, they don’t look so great. It’s about time to make them transparent. Here are a few examples:

Here’s a tab with a nice transparency:

buzilla.mozilla.org

Here’s one that isn’t transparent:

wordpress.com

Here’s a URL bar over http:

yahoo.com

Here’s a URL bar over https:

safepasswd.com

Here’s a URL bar over https with an EV SSL cert:

ebay.com

Here’s a URL bar over https that doesn’t have a transparent favicon:

chase.com

If your a photoshop user and use an ICO favicon, you can use this plugin to generate them on Mac/Win with pretty much any remotely modern version. It’s available under GPL. I recall you can easily do so using GIMP as well, though I’m no GIMP pro, so I’ll leave it to someone else to document the best way to do so. PNG also supports transparency through pretty much any program that can save PNG’s.

So spread the word. Designers, it’s time to start fixing up those few pixels of whitespace. It would make things look so much better.

So the format war of Blue-ray vs. HD-DVD is over. There are still several other rather significant battles going on in the tech world right now that aren’t Microsoft vs. Apple or Yahoo vs. Google. For example:

Adobe Air vs. Mozilla Prism vs. Microsoft Silverlight

Google Gears vs. HTML5 Offline support

Android vs. iPhone SDK vs. Symbian

Ruby On Rails vs. PHP

Not every case will have a true “winner”. That’s not really a bad thing. Choice is good. In some cases they will merge to form one standard, such as what’s likely for offline web applications.

What is interesting is that SQLite really dominates right now. Adobe Air, Mozilla Prism, Google Gears, Android, iPhone SDK (likely through Core Data API), Symbian, Ruby On Rails (default DB in 2.0), PHP 5 (bundled but disabled in PHP.ini by default). It’s becoming harder and harder to ignore that SQL survived the transition from mainframe to server, and now is going from server to client.

No longer is the term “database” purely referring to an expensive RAID5 machine in a datacenter running Oracle, MySQL, DB2 or Microsoft SQL Server. It can now refer to someone’s web browser, or mobile phone.

This has really just begun to have an impact on things. The availability of good information storage, retrieval, and sorting means much less of these poorly concocted solutions and much better applications. Client side databases are the next AJAX.

Edit [2/27/2008 9:14 AM EST]: Added Symbian, since they also use SQLite. Thanks Chris.

In the past day I’ve been doing a fair amount of reading on what others think of this meta stupidity. A few suggested remedies are particularly good and worth a post linking to. My two favorites both from Mozilla hackers are these:

David Baron has a must read blog post. Since the bulk of these older sites are on intranets, why not just allow administrators to enable compatibility mode on intranets? Seems like a perfectly logical solution that doesn’t hold back the web, and allows them to achieve their goals.

Daniel Glazman has another idea that I think is very valid.

• Microsoft should freeze, and I really mean it, its current IE6/IE7 HTML 4 engines, and drop that META tag idea.

Ditto. That needs to be a very deep and reliable freeze though.

As Robert O’Callahan, John Resig, Anne van Kesteren all point out, this idea of using a meta tag to select a rendering engine is bad. Here are my personal thoughts on the issue. Not as a browser developer but as a web developer.

Essentially the argument by the IE team is this: Rather than fix the problem, lets create a larger problem so the smaller one isn’t very noticeable.

Yea, that’s how I parsed the blog post. For anyone who disagrees, perhaps I interpreted it wrong because they didn’t select the correct parser because they didn’t include the following:

<meta HTTP-equiv="X-UA-Compatible" content="IE=8;FF=3;raccettura=serious;OtherUA=4" />

All joking aside it’s an insane idea guaranteed to set things back.

(more…)

As everyone in the industry knows, Nielsen/NetRatings no longer relies on page views instead preferring total time spent. This makes sense since ajax applications can have 1 page view, but keep a user for an hour. Not to mention other things like video or Flash. The use of time spent is likely much more accurate. In my mind “time spent” is time actually spent on the site (I’m a literal guy).

This of course raises an interesting question. How do tabs influence this metric? Take the following situation as an example. A user visits a home page, and opens a link in a new tab. Then finds another link and opens it in a new [background] tab. That’s 3 tabs in 1 visit (assume visit to be 30 minutes).

Before tabs, most browser sessions would look like this:

There’s now an increasing number that will look like this (gray is a tab not in view):

If we assume total time on the site is time between the first and last page, we potentially undercount the total time on sites that list information (for example Digg). The total time to make those clicks could be < 10 seconds, but the time spent reading those two page alone might be > 10 minutes. Many tab power-users from what I’ve read around the web over the years essentially use them as a way to bookmark their “to read” list (including myself). It also undercounts sites like Gmail which are ajax based (1 page) but can be used for several minutes.

If we use javascript to “ping” (call back by placing a tracker gif) the analytics service every x seconds to see if the page is still open, we potentially double count since a user can’t be in 3 tabs at once. The clock would be counting 3 seconds for every 1 second the user is actually looking at the page.

This raises the question: are sites that are heavily used by Firefox, Safari, Opera and IE7 site underestimated or overestimated because of the way users browse the site? How do you accurately tell how long a view is when a user can have multiple tabs?

Another example is someone who keeps their webmail open in a tab all afternoon for easy access. They may only check it 1x measuring no more than 1 minute in actual attention. But it’s open for 5 hrs. What is the real time on the page? You can measure my interaction (opening/closing mail). But what if I’m reading an email for an hour (it’s a really complicated one)? How does that compare to just leaving it open in the background?

This is really no different than using new windows, the difference being that most people seem to have found windows to be annoyance, while tabs are a “feature”. The increase in usage and popularity in a time where visit length matters raises an interesting question. How do you measure it?

One assumption is that it’s just a small percentage of the population, which is likely true. The problem with this assumption is that it’s one subject to change as the browserscape matures and users learn about new features. Another assumption is to just account for all time a page is open, even if it’s not visible. The downside I see here is that it’s pretty inaccurate. As a content producer I’d like to know if my content is used, or just loaded on a users computer. If I were an advertiser I’d care even more.

I’m not sure how analytics firms approach this. In a sense it’s similar to the “hotel problem“. Perhaps just something you need to decide upon and live with.