blufive: (Default)
If you work in the business of generating web pages to display to users, you need to know: there's going to be some major changes in the browser landscape over the next year or three.

There are several things going on out there. Any one of them could make a serious difference to the web at large - but they're all either happening right now, or imminent.

Mobile devices are going be everywhere.

I'm seeing reports[1] that at least one major chipmaker is planning to ship a system-on-a-chip imminently which they reckon will allow roughly-iPhone-3GS-equivalent handsets to sell at retail, without contract, for ~$100. Those things are going to be hitting the high street in less than 6 months.

I'm not sure I believe that precise graph of price vs. time (or even that I read it right) but I don't think they're wrong by more than a factor of two on either axis. Smartphones (more accurately, pocket frackin' computers[2]) are going to go mass market, and soon.

In 2010, smartphones sold roughly 300,000,000 units. That's about the same as the number of desktop PCs sold in the same period, apparently. This year, they're going to sell more. When those $100 beasties hit, it's going to seem like everyone's got one.

Mobile devices are not second class web citizens any more

These things have proper browsers on them. Most are webkit-based (like Chrome and Safari) so they do proper standards-based rendering, including lumps of the new CSS3 whiz-bangs. They have proper javascript engines with better performance than you may expect.

I did some ad-hoc performance testing recently. Mobile safari on iOS 4-point-(mumble) on an iPhone 3GS was about a factor 10 slower than Chrome 8 on my workstation. So: only 10 times slower than one of the fastest browsers out there running on much beefier hardware. That's comfortably in the same league as (probably even somewhat faster than) IE8 on the same workstation. It leaves IE7 in the dust.

Add those two items together (low prices + web capability) and you get: mobile devices are going to become a very popular way to access the web. This is going to happen fast - if we're lucky, we've got a year or two to prepare for it. Right now, I'm seeing mobile safari at about 1.5% to 3% of sessions on the websites I work on. That's up from basically zero 12 months ago.

All those browser support conversation, where you say things like "we'll support all the browsers over 5% market share in our stats"? They're going to get gate-crashed by mobile devices in less than 12 months' time, quite possibly less than 6. Maybe not any one browser on its own, but in aggregate, it all adds up fast.

The only thing I can see slowing this down is the mobile phone operators, and their we're-not-price-gouging-our-customers-honest-guv data payment plans. Even on that front, for $100 or so, I'd be seriously considering buying one of these beasties for use via wi-fi hotspots only (hell, that covers my house and garden, for starters - anything else is a bonus) and screw the phone people.

It's the browser wars all over again

All these new devices come with their own browsers and, unfortunately, there are loads of the buggers [3]. They're all subtly different. They're all running on different hardware, with different screen sizes. You're really, really, really, going to have to test on the real damn hardware.

The good news is that they mostly follow the standards. If you can:
  • persuade the photoshop weenies to give up on pixel-perfection ('cos the screen dimensions are all over the show)
  • do at least a bit of work to tailor the design to the realities of small screens (by dumping cosmetic fripperies and focusing on making the site suitable for whatever it's supposed to actually do)
  • refactor all the UI stuff to cope with touch instead of/as well as mouse interactions (which is quite a big deal, especially if the site's supposed to do any quantity of data entry)
  • avoid the real bleeding-edge stuff like webGL
...then you shouldn't have too much trouble keeping the browsers mostly in line.

Javascript performance has just gone up like a rocket.

IE is still the biggest desktop browser, and it sucks, especially the older versions. On the desktop, almost everyone still has to support IE6/7[4]

All the other desktop browsers are an order of magnitude faster than IE8, which is itself significantly quicker than IE7 and 6. IE9 is going to be seriously competitive with everyone else. Don't get me wrong, performance is still an issue, but the browsers are now probably less of a bottleneck than your code is.

Now, that's not bleeding-edge, but it's sure as hell quick enough to run non-trivial things at a sensible speed. Remember: there was a perfectly-playable port of Lemmings to JS done years ago, before all this optimisation occurred. Some of the stuff that people are doing out there in browser-specific-tech-demo land is amazing (like, real-time-chromakey[5], real-time hardware-accelerated 3D graphics[6])

So: You can now write real app-scale code in websites browsers. This has started to get through to people, though I still see a lot of comments like "javascript is a toy, you can't do anything serious with it" from people who really should know better, if only because it's been smacking them in the face for a year or two now.

Conclusions

Mobile devices are going to become at least a significant way of accessing the web within months. In the long run, a good chance of becoming the dominant way. That's long run in internet time - I'll go out on a limb and say: 5 years, maybe. Mobile devices are probably going to be what finally rams the stake through the hearts of IE6, 7 and maybe 8 (with Firefox and Chrome cheering from the sidelines).

The possibilities for mobile devices to run really cool things via pure web tech are much greater than most people realise - and web tech runs on all of them without having to port to a zillion different native development environments, or get sign-off from Apple before you can ship anything. [7]

The references I can be arsed finding, with added footnotes


[1] http://tech.fortune.cnn.com/2010/12/22/2011-will-be-the-year-android-explodes/

[2] Not that long ago, the state-of-the-art in phone games was "snake". An iPhone 3GS (which is now moderately old hat, tech wise) has far more computational shove than the system I used to play Half-Life all the way through. Yeah, these things happen to be phones, but, first and foremost, they're full-on pocket computers. People just haven't really cottoned on to that bit yet, because the future just went and snuck up on us.

[3] http://www.quirksmode.org/blog/archives/2009/10/there_is_no_web.html [8]

[4] On sites I interact with professionally, I'm still seeing IE6 at about 5-8% and IE7 at 12-20%. I can't quite pull the trigger yet, but IE6's days are numbered.

[5] https://developer.mozilla.org/samples/video/chroma-key/index.xhtml works in firefox 3.5 and up, allegedly. No idea about other browsers.

[6] http://webglsamples.googlecode.com/hg/aquarium/aquarium.html. You'll need a Firefox 4 beta or another WebGL-enabled browser (I believe the pre-release chrome builds can do it too, though I've not confirmed it personally)

[7] I hear the cry: "How do people make money from web apps?". That requires rather more prognosticating than I'm willing to commit to right now. One possibility is Operator Billing - it's going great guns in Africa. But that requires the mobile phone networks to be more forward-sighted than "give us $LOADSAMONEY-per-byte, and Get Orf Our Land Network" and "new handset is 10% better than old one, upgrade now!", so colour me somewhat skeptical for the moment.

[8] On the subject of mobile browser landscape and mobile web, just read everything PPK writes. Even if/when he's wrong (not often, on past track record) he's wrong in interesting and educational ways.

IE8

2008-02-04 22:03
blufive: (Default)

So, it turns out I was wrong about Microsoft's IE8 standards-mode rendering switch - they're proposing that web authors use either a meta element or an HTTP header as an opt-in.

My initial gut reaction: wow, that sucks.

cut because it's web-geeky and looong )

So: flip the default around, and this is a good idea. Otherwise, it sucks.

Finally, a word from the lemurs.

blufive: (Default)

A few weeks back, via the Web Standards Project, I learned of the Email Standards Project, a similar effort to encourage the adoption of HTML/CSS standards in email clients when rendering HTML emails.

All I can say is: about bloody time. Getting HTML mails to render consistently across different mail clients is a monumental pain in the arse. There are mail clients out there with HTML rendering in the same league as Netscape 4.x (translation: horrible) and it ain't just small fry, either. The ESP people highlight Google Gmail, Lotus Notes 8 and Outlook 2007 as among the worst offenders.

I'm disappointed, but not surprised, to see the announcement immediately attracted the usual rants about how HTML mail is evil and should never be sent/encouraged/tolerated/etc. I've encountered this viewpoint many times before, and while I'm sympathetic to most of the technical arguments1, I have to say: get over it, people.

To get rid of HTML email at this point in proceedings would require removing functionality (in some cases, default behaviour) from the top 10 or so email clients (yeah, Microsoft are soooo likely to do that2) and significantly altering the behaviour of 99.9% of the email-using population of the world. You'd probably need to kill every marketing person in the world too. People like HTML mail. They like to be able to use bigger text, fancy fonts, and even (shudder) marquee and blink elements.

Ranting against HTML mail is an exercise in futility. The horse hasn't just bolted, it's sired offspring from every mare in the country, taking time out half-way to come back and nick the mints out of your pocket. Trying to shut the stable door at this stage just makes you look like a foolish, dogmatic, elitist zealot. This is the sort of thing that leads people to view standardistas/open source advocates/linux-weenies as a group of wild-eyed lunatics who should be avoided like the plague, and it's counter-productive, because it drives ordinary users away from even contemplating a better way of doing things.3

The ESP is an important part of a far more productive approach: make HTML mail work better for everyone. Speak to software vendors, and get mail programs to respect user wishes better, so that those who want to sent plain text mail can do so easily. Get mail readers to render HTML mail in a sane way (this, in itself, stands a good chance of significantly reducing the badnwidth usage - a lot of the current bulk is because people have to use 1997-vintage table layouts and tag soup to make it look sensible in major mail clients). Get mail senders to include plain text alternatives and build the mail properly so that people who read text-only can still read them. The last couple add up to improve accessibility, too.

1saps bandwith, harder to construct programmatically, etc. There are compatibility arguments re: older mail clients, but most of them involve badly constructed mails which don't include text alternatives (see! they're trying to save bandwidth by not duplicating stuff!) or mails which have fallen foul of the appalling HTML rendering of some mail clients.

2Though they did completely shag the HTML rendering in the last outlook release - previous versions of Outlook were much better than Outlook 2007.

3To borrow liberally from a stock response to spam "solutions":

Your approach advocates a:

(x) technical ( ) legislative ( ) market-based (x) vigilante

approach to making email better. Your idea will not work. Here is why it
won't work. (One or more of the following may apply to your particular
idea, and it may have other flaws too.)

(x) Users of email will not put up with it
(x) Microsoft will not put up with it
(x) Most other software vendors will not put up with it
(x) Requires total cooperation from all email software vendors at the same time
(x) Requires total cooperation from everybody in the world
(x) Many email users cannot afford to alienate potential employers/customers

Specifically, your plan fails to account for

(x) Lack of centrally controlling authority for email
(x) Popularity of presentational twiddly bits like colours and fonts
(x) Public reluctance to accept removal of existing functionality
(x) Huge existing software investment in HTML Email
(x) Outlook
(x) The entire marketing industry

(and probably a whole bunch of other reasons I left out)

Profile

blufive: (Default)
blufive

April 2017

S M T W T F S
      1
234 5678
9101112131415
16171819202122
23242526272829
30      

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated 2017-09-24 12:05
Powered by Dreamwidth Studios