IE6 and Mobile Sites

IE6 turns nine years old tomorrow. Ironically, it’s now old enough to ride most rides… and those rides are turning it away. The latest is PBworks, formerly PBwiki. They’ve announced that IE6 users are about to start getting a warning message that they have two months to upgrade.

Here’s the intriguing part: after that date, they will be directing IE6 users to their mobile site. And that, I admit, is a solution I hadn’t considered. Most mobile browsers, after all, have stronger standards support (and better security) than IE6. But most mobile sites also offer stripped-back functionality, making them frequently compatible with IE6′s limited standards. If your mobile site has scaled-back features, and those features aren’t especially demanding on modern browser features, punting your IE6 users to m.yoursite.com can be a great way to get rid of headaches.

Here Is Why Web Developers Hate IE6

This humorous graphic speaks 1000 words.

Flash In the Pan

IE9 has announced they’re giving decent support to the <video> tag.  And that, my friends, spells the beginning of the end for Flash.

I’m a Web-standards guy, so my inclination has never been toward Flash anyway.  Admittedly, there are some things for which Flash is ideally suited — namely, for animation and video.  To date, there really hasn’t been a reliable way to do that kind of thing, other than the fairly ubiquitous Flash plug-in.

My big beefs with Flash, though, are:

  • it doesn’t play well with others.  CSS z-indexing is tricky.  It also steals keyboard focus, preventing Tab and (on Windows) Alt-Tab from working normally.
  • that designers use it for things like site navigation and to display text, be that out of a control-freaky desire to control all things related to the user experience, or out of a lazy refusal to learn how to do such things in DHTML/CSS.

The latter has become a real issue now that I have an iPhone.  Sites with Flash splash pages, but no HTML “skip this” link, prevent me from seeing their site.  Sites done up entirely in Flash, as is very common for musicians and artists, prevent me from seeing anything.  Recently, while driving, my wife and I thought about visiting a new restaurant nearby, so we called up their site to see their menu.  The site was all Flash.  That restaurant lost business that day — and we still haven’t eaten there.  If you can’t be bothered to give me your menu in HTML — a text medium! — I can’t be bothered to find ways around the all-too-familiar iPhone brick icon.

Now, when I mention the iPhone, neither here am I defending Steve Jobs.  On the one hand, his public position that the iPhone wants to support HTML5 over proprietary standards is a good one.  His refusal to allow Adobe’s tools to export into an iPhone-friendly format, insisting that iPhone developers use only Apple-endorsed tools, shows his real motives.

But Jobs is right about one thing: HTML5 is a big win.  With it, we get video, audio, and lots of other good stuff that, to date, has required us to use Flash.  IE has, as always, been the laggard; that IE9 will support these HTML5 technologies is a big win for the Web.  Mind you, it’ll be years and years before IE6-8 have been suitably flushed out of our system, but we’ll at least be able to plan for the future.

HTML5 doesn’t do everything that Flash can, as Ajaxian points out.  Flash will do full-screen video, for instance, which none of the browsers will currently do for HTML5 video.  That, however, is a problem for the browser makers, not a problem with HTML5.  Hop to it, ye browser coders!

Nightmareweaver

My friend Jeremy, a stellar screenwriter/game designer, decided he needed a professional Web site, and so asked our friend Angi Shearstone to do the design, because she’s a terrific artist who has done some beautiful work with professional sites. Jeremy’s site worked fine on his local machine and on Angi’s server, but when he uploaded it to his server, it broke all over the place, so he asked me if I could take a look.

The problem turned out to be some sort of CR/LF issue, where the uploaded files were getting their end-of-line characters stripped, presumably due to a configuration with his client. As a result, the whole page ended up all one line… meaning that everything after the first // in the script got treated as one giant comment. Result: JavaScript errors all over the place.

But I told Jeremy that I was professionally obligated to fix not just the particular problem, but to rework all the code for his site. You see, I’d looked at the source.

Angi admits she’s not a developer, and so uses Dreamweaver. I can hardly fault her for that. Dreamweaver is a tool aimed at, and marketed to, people like her, and so I don’t hold her at fault one bit. However, one peek under the hood and I wanted to drive out to Adobe’s offices with a crowbar. The resulting code looked pretty good… if it were 1998.

(To be fair, I don’t know which version of Dreamweaver Angi is using, but I feel pretty confident she’s not using a copy from the mid-Clinton administration, because the page was using an XHTML DTD.)

Tables for layout? You bet. Paragraph tags with nothing in them but a non-breaking space? Of course. Lots of whitespace in the images instead of neatly-trimmed images with CSS margin or padding? Uh-huh.

…but every single link with an href of “#”? Good God. Yes, every single link relied on its onclick handler to shift the user to the next page. (Needless to say, with most of the JavaScript inadvertently commented out, this caused quite a few problems.)

I know I’m a code snob, with high standards about, well, standards. I also recognize that an automated tool is going to have limitations and can’t do things as cleanly as a human. But this episode really served to demonstrate the value of semantic code and of MVC separation. By changing the headings to actual heading tags like H1 and H2, and by moving the layout into an external .css file, the resulting HTML was tiny… and very human-readable. And that was some pretty big added value for Jeremy, who will have to maintain these pages going forward; he’d have had a lot more trouble trying to deconstruct and reconstruct Dreamweaver’s piles of glop. By moving the complicated, heavy-geek part (the CSS) into an external file, the resulting HTML was small, lean, and manageable.

Look for yourself. Note: as of right now, we still haven’t solved the CR/LF issue. Also note: since Jeremy needed the site up and running before a conference this week, what you’re seeing is not the finished product, but rather what I could deliver to him in time. I still need to add more SEO, address accessibility issues, and get it to format nicely on an iPhone. But as a first cut, from only a couple hours’ worth of work, it’s a big improvement over the bad dream that came from Dreamweaver.

I Can’t Get A Group, Er, Grip On This

From the HTML5 spec (emphasis added):

The hgroup element represents the heading of a section.

The header element represents a group of introductory or navigational aids.

That’s right, “hgroup” means the heading, and “header” means a group of stuff. Yeah, I’m sure that won’t be confusing at all.

Google: So Long, IE6

Big news on the IE front, as the 800-pound gorilla of the Web announced that it’s going to start phasing out IE6 support next month:

Many other companies have already stopped supporting older browsers like Internet Explorer 6.0 as well as browsers that are not supported by their own manufacturers. We’re also going to begin phasing out our support, starting with Google Docs and Google Sites. As a result you may find that from March 1 key functionality within these products — as well as new Docs and Sites features — won’t work properly in older browsers.

Meanwhile, noting that IE6 was the weak link in the Chinese hacks on Google, a petition in the UK government is calling for an abandonment of IE6.

In light of those attacks, France and Germany advised their citizens to switch from IE to a different browser altogether; the UK government, in the person of “Lord West of Spithead”*, said that simply upgrading to the latest version of IE would be sufficient.

* no, seriously, that’s his name.

TLC

When it comes to hiring contractors, you want TLC. Too often, you think that means “The Lowest Cost”. What you actually want might be “Tender Loving Care” instead.

Let me start out by saying I don’t mean to give a blanket condemnation of contractors. I know many diligent, attentive contractors; I’ve been a contractor myself and like to think I fit into that category. But there’s the other kind of contractor, too, and that type crops up more often than you’d want.

You know the story: the company has a big initiative to do. Doing it in-house would take away resources from other projects, and would cost more. “Let’s hire some contractors! We’ll save money!” Six months later, the contract is done, the project is up and running – but your full-time geeks are now untangling snarled-up code.

The catch, of course, is that contractors don’t have a vested personal interest in the long-term success of the project. They have a vested personal interest in the success of the contract. If all those terms are met, the contractor is all set. Now, you’d hope that the contractor would give full attention to detail, and many do – but only if they have a sense of pride in their work. It doesn’t affect their bottom line.

(Well, it can, indirectly, in that contractors with sub-par work can get a bad reputation. But to be honest, the people a contractor is going to give you as recommendations are not people who are going to bad-mouth his/her work. It’s hard to get an honest sense of a contractor’s full work history.)

Full-time employees, by contrast, know that they not only have to build it, but also maintain it, update it, and improve on it. They don’t just want the car to run, because they know they’ll be back under the hood time and time again. Full-time employees will put TLC (Tender Loving Care) into their code. Contractors might do so. Doing the project with full-timers might cost more up front, but may also save you money afterwards.

What’s the solution? Never hire contractors? Quite the contrary. Contractors can save you money, if you take the right steps.

  1. When you’re doing budget estimates, don’t assume that a contractor-built project will have the same maintenance costs as one built in-house. If the cost to maintain is 1.2 times normal, will you still save money? The answer might be yes, but you should make sure you know for sure. (1.2 is a number I created ex recto; I don’t have a real metric here.)
  2. Make sure contractors have oversight and periodic review by the folks who will take over the code when the contract is done. Keep the contractors on-track and adhering to your company’s standards. Consider giving the contractors a personal interest in quality: for instance, instead of offering them 1X as pay, offer them .8X with a .2X bonus if the project’s code complies with company standards. (When I was a contractor, I’d have happily gone along with this.)

You want TLC. Make sure you’re getting the right type.

Fake Steve Jobs vs. AT&T

Newsweek columnist Daniel Lyons, writing as Fake Steve Jobs, brings this rant (NSFW) about how AT&T is doing everything exactly wrong when it comes to their 3G network, by comparing the iPhone to Meet the Beatles:

Sales were crazy. I mean nuts. The thing was a huge smash hit. By April, twelve weeks after that album came out, the Beatles had the top five spots on the Billboard chart.

Now there was a lot of demand for that record — so much that the plant that printed the records could not keep up. Now here’s the lesson. Do you think the guys who were running Capitol Records said, Gee whiz, the kids are buying up this record at such a crazy pace that our printing plant can’t keep up — we’d better find a way to slow things down. Maybe we can create an incentive that would discourage people from buying the record. Do you think they said that? No, they did not. What they did was, they went out and found another printing plant. And another one and another one, until they could make as many records as people wanted.

…and he’s right.

Underscore.js

jQuery is lighter (and often easier to use) than Prototype, but it doesn’t have as rich of a set of functions. That’s why I’m intrigued by Underscore:

Underscore is a utility-belt library for JavaScript that provides a lot of the functional programming support that you would expect in Prototype.js (or Ruby), but without extending any of the built-in JavaScript objects. It’s the tie to go along with jQuery’s tux.

Underscore provides 44-odd functions that support both the usual functional suspects: map, select, invoke — as well as more specialized helpers…

Not that every site needs one more framework, mind you, but there are select places where I can see this being useful.

The Philip DeFranco Principle

Last week, when bored, I pulled out my iPhone, opened up the YouTube app, and decided to see what the most downloaded clips were for that day. Amidst the teen blather about Twilight and non-English clips of soccer goals was that day’s episode of The Philip DeFranco Show. There’s a lesson in that show.
(Warning: DeFranco’s show is not always SFW.)

DeFranco’s show is a three-minute monologue on the day’s events, sort of a late-night show monologue for the YouTube crowd, complete with more frank language. DeFranco knows how to play to the crowd; he’ll frequently mention some starlet, even if just in passing, and then work her name into the show’s title and use a photo of her as the show’s thumbnail. But that’s not the only thing contributing to his popularity; for that, you need to watch the editing.

View any episode and you’ll notice there’s a cut after practically every sentence (and sometimes cuts in the middle of sentences.) This makes the show not only fast-paced, with each line coming rapid-fire after the one before it, but also makes the show shorter. By removing every half-second of dead air, DeFranco shaves seconds off of his clips.

The savings are undoubtedly minor, but there’s a psychological value. Sure, that $3.99 item isn’t really much cheaper than the $4.00 alternative, but it feels that much cheaper because of the 3 instead of the 4. Similarly, a YouTube clip that clocks in at 3:18 isn’t that much shorter than one that’s 3:24, but it feels it. In an era of short attention spans (especially on YouTube) and lengthening download times, trimming off six seconds can translate into more page hits.

Does it work? Again, shaving off time is far from the only thing contributing to DeFranco’s success, but it’s at least a contributing factor: one of his clips from last week got 2.5 million views. That rivals some major-network TV shows.

What’s the lesson, not just for YouTube clips but Web development in general? Bandwidth still matters. Broadband might be widespread, but people still don’t like waiting. Unless they’ve clicked on something where they expect a long lag (like a video clip or mp3), users will drop off pretty quickly. Major sites like Amazon and Yahoo saw pretty startling dropoff rates when they increased their page sizes by small amounts.

So before you add one more 20KB banner ad or that 10K of analytics JavaScript, consider the tradeoff. Is it worth it? Will the added value outweigh the lower traffic? Or are you better off, like DeFranco, going leaner but with more hits?