Category: Web Development

2.7 Billion Served: Mobile Phone Usage Dwarves Everything Else

Cameron Moll’s new book on Mobile Web Design points to an enlightening article by Alan Moore in which he compares mobile phone adoption to other technologies. The key paragraph:

Now we have context. 800 million cars, 850 million personal computers, 1.3 B fixed landline phones, 1.4 billion credit cards, 1.5 billion TV sets. How many mobile phones in use today? In use today, yes, 2.7 billion (technically 2.7 billion in January, not December). They sold 950 million phones last year and the total worldwide mobile subscriber base grew from 2.1 billion to 2.7 billion. Three times as many mobile phones as automobiles or personal computers. About twice as many mobile phone owners as those of fixed landline phones or credit cards. And almost twice as many mobile phones in use as TV sets.

2.7 billion. That’s a staggering statistic. Add to that the buzz around the iPhone and rumors of both a Google and possibly a Yahoo phone, and it isn’t possible to ignore the mobile web any longer.

I’m excited. So much opportunity for new discovery, new applications, and ways to make people’s lives better.

Internet Explorer Doesn’t Support HTTP

I was recently pointed to an article on an obscure IE bug that occurs if you name a textarea “tags”. This reminded me of an IE bug that plagued us for months. We solved it when we find a Microsoft Knowledge base article acknowledging that Internet Explorer does not fully support HTTP. Yes, that’s right. Microsoft still does not support the core protocol of the web.

Here is the scenario:

Some Internet Explorer users were encountering problems downloading files from links sent via email. Clicking on the link from the email would not work; however, visiting a web page that linked to the same location and then downloading the file worked.

When we replicated this problem, we could see the file delivered from our servers correctly and a temporary file put in Internet Explorer’s cache for the download. Internet Explorer then starts another application like Acrobat Reader to open the file. Internet Explorer then deletes the temporary file from the cache before the third party application can open the file. Because the file no longer exists, Internet Explorer displays an error message that says:

“Internet Explorer cannot download from the Internet site [filename] from [site].”

In the specific case of downloading files via links sent in email, we believe we have identified the underlying problem. Under some circumstances, Internet Explorer is unable to handle proper usage of an HTTP Header called Vary. An exhaustive examination of the problem can be found here:

This is a bug in that only occurs in Internet Explorer. All other browsers handle the HTTP specification correctly. Microsoft has been aware of the problem since 1999, and instead of fixing it to support the full HTTP specification, Microsoft implemented a hack that works most of the time, but fails in certain circumstances. In fact, Microsoft’s own knowledge base acknowledges that Internet Explorer is at fault when it comes to this issue. The knowledge base states that Internet Explorer does not support the HTTP specification fully:

My hope is that by documenting our findings will help someone else from needlessly trying to troubleshoot the same issue.

Reading a lot about OpenID

I’m reading a lot about OpenID. I’m trying to determine whether or not it seems viable or likely to be adopted by the larger, non-technical audience of Internet users.

These recent blog post, OpenID: Great idea, bewildering consumer experience, captures better than I can how confusing OpenID can be if you set out to use it. It is worth reading the whole thing, but I want to highlight three points from the post:

The process of selecting an OpenID provider will stump the average consumer. They’re being asked to pick an ID that they will, in theory, use everywhere and forevermore to gain access to everything they own. They’re supposed to obtain this ID by making an effectively random selection from a group of providers they have never heard of.

This is where I get stuck every time. I’ve selected my web site host, domain, and email address based on longevity. Trying to decide which OpenID provider will be around in a couple of years is a difficult task. I’m not certain what other criteria you would use to make a decision.

Various OpenID sites also promote the notion that users should set up their own OpenID provider.

We’ve looked into creating an OpenID provider service from our applications. Yesterday, I saw someone asking for development of a plugin for Jive Software that would ideally make Jive’s Clearspace product an OpenID provider. It seems like every additional OpenID provider will be contributing to the confusion instead of helping.

[UPDATE: See the note below from Matt Tucker, CTO at Jive Software. In re-reading what I wrote above, I wasn’t very clear. Until Matt’s comment below, I didn’t know Jive intended to do anything with OpenID. I just saw someone asking for a plugin that would make Jive’s Clearspace profiles provide OpenID URIs. It more of a comment on desiring more OpenID providers rather than a comment on adding OpenID to any particular application. As I noted in the comments, I’d like to see more applications accept OpenID and fewer provide their own OpenIDs so that it is easier to get over the indecision about choosing an OpenID provider. Sometimes less choice is a good thing. Thanks again Matt for taking the time to clarify.]

And all this is for—what, exactly? To save me from having to pick a user name and password? As annoying as that can be, it’s just not that hard! Remembering an arbitrary user name does cause real trouble, but simply allowing email addresses to be used as IDs can solve almost all of that problem. As more and more sites allow email addresses as IDs, the need for OpenID becomes less compelling to a consumer.

This final point is a key for me. It seems like OpenID is asking people to establish a new, long term identity. However, for those who can establish a long term identity, they’ve already done so using their email address. Asking someone to replace their email address, the address that they have been trained to believe is where they can be found online, is going to be a tough sell.

I understand the desire for single sign-on. I’ve certainly heard the desire for single sign-on from a lot of customers and have spent a fair amount of time building authentication integration.

And yet, when I look at OpenID and all of the obstacles it needs to overcome, never mind the competition from Yahoo BBAuth and Microsoft Live ID, I question whether OpenID will ever receive widespread adoption. The real shame is that there is a true desire, if not need, for a simple, open system to simplify logins for web applications and right now, I don’t see any of the systems solving that problem for the majority of people.

Trying to Follow the HTML Crisis

I’ve been lost over the last few days trying to understand the differing opinions on the status of the next generation of HTML code. Molly, who I’ve had the good fortune to meet and whose opinion I respect, raised the alarm about the state of the W3C development. Jeffrey Zeldman whose article “To Hell With Bad Browsers” kicked off the movement for standards-based web development doesn’t see a crisis at all.

It is pretty clear that something has been going on given the sobering testimonial of Roger Johansson who explained why he abandoned and then rejoined the W3C’s HTML Working Group.

Aside from trying to follow the problems (or lack thereof), I’ve been trying to sort out what the next generation of HTML is supposed to be. A few years ago, I convinced my company to standardize on XHTML. We worked our way through the rendering issues and finally had XHTML adoption throughout the organization.

Which is why I’ve been ignoring HTML 5. I drank the kool aid on XHTML, why would I go back to HTML now?

Seeing so much concern over HTML 5 today by the same people who advocated XHTML confused me greatly. What happened to XHTML 2.0? Why are we going back to HTML?

Come to find out, I missed a change at some point. I remember a lot of concern about XHTML 2.0 being unwieldy and a radical departure from HTML and XHTML 1.0, but I didn’t follow the outcome of those discussions fully.

Turns out HTML 5 is the agreed upon next step for both HTML and XHTML. HTML 5 is designed to resolve the issues between HTML and XHTML and converge them into one specification. While I still have some concerns about dropping the requirement or preference for well-formed markup, I’m now more reassured about the direction our core web technology is headed.

The new elements in HTML 5 sound  like improvements. The example of next generation web forms is too good to be true. The clarification of HTML 5 that those participating in the development of the specification have agreed to will be a welcome change and will hopefully prevent someone else from having to do the research I did to sort through the standards mishmash.

Molly’s call for action may have been more alarmist than it needed to be, but there have been some good outcomes from the discussion. If nothing else, I’m now excited about the potential of HTML 5 and finally understand that XHTML isn’t going away anytime soon.

WYSIWYG Editor for Safari

A few years back I helped build a content management system. At the time, Internet Explorer on PC was the only browser we could use for WYSIWYG editing. As a Mac user, I struggled with the fact that I was delivering a product that I could never use on a regular basis.

At the time, the great promise was sections of the DOM II specification on range. Bugzilla listed support for this part of the specification on its future work. I signed up for a list and monitored the ticket waiting for the day when Mozilla would support WYSIWYG in-browser editing.

Today I read that the Yahoo UI team has finally bent Safari to its will to support WYSIWYG editing. We’ve come a long ways since I was hanging out on the Mozilla developer lists and asking questions about the range implementation. Now that someone has conquered Safari, we are close to assuming that this foundation piece of the read/write web is available to all users.

YUI Compressor, Web Site Speed

Via Ajaxian I learned the Yahoo has released a new javascript compressor that reduces file sizes 18%. Compression of web site code is something that too many web site developers ignore.

A few years ago, our CTO and I read Andrew King’s Speed Up Your Site book and became consumed with improving performance of our customer web sites. We decreased download time for one site by 75%. These changes prevented us from hitting our network capacity long enough to move to a new hosting facility where we weren’t constrained by bandwidth.

What amazes me is how frequently developers ignore the simple things that can be done to speed up their web applications. Most web servers contain options to supply their content in gzipped form. This option alone can save tremendous time for users and bandwidth costs for companies.

I have a short list of books that I wish everyone who develops online would take the time to read. Speed Up Your Site is near the top of that list.

P.S. I was pleased to find that my new hosting environment appears to be using gzip by default. The home page would be 19K uncompressed, but is delivered to the browser as a 4K gzipped file.