Umbrella Today, which is a beautifully crafted site (CSS parallax effect!) that tells you whether or not you should bring an umbrella outside, does not work for me. See, it asks for a zip code—presumably limited to the United States only. But I don’t live there.
Now, I know, there are countless websites that exclude a certain demographic in every imaginable way, not just by geography. After all, on the Internet you’re free to do anything you want. But if you don’t like how something is working (or isn’t working), you’re free to blog about it as well.
Go local, be successful, then branch out
To all the developers out there: going local is a good strategy, but if you can help it, try to make your nifty little web app more accessible than just for your neighborhood.
And I’m not just talking about the one-person startups but also the bigger fish in the pond. I wonder how long it will take for Google Maps to completely and accurately cover the planet. (I don’t know if we should be excited when it does, either, but that’s a different story.)
True usability and accessibility
When we mention the term usability in terms of web development, we look at how comfortable users are in using and interacting with the interfaces that are created. Closely associated with usability is accessibility, which champions the idea of never leaving any differently-abled user out.
Doesn’t true usability and accessibility cover my dilemma with Umbrella Today, since I’m left out of its target userbase?
I do hope the makers of Umbrella Today and other people like them stop discriminating by zip code and start reaching out to other parts of the world.
Again, this is if they can help it. Because if there’s one medium that can make it possible, it should be the Web.
First the iPad, and now a debate on the relevance of Flash. Apple continues to ignore it and touts HTML5 as the future. Google is also pushing HTML5 on YouTube, with other video sites starting to follow suit. Even Mozilla is disabling it in its new mobile browser, Maemo. Clearly, the death knell for Adobe’s most controversial product is getting louder than ever.
But it’s still all talk, all noise. How about some real action? Thankfully, over at Binary Bonsai, Michael Heilemann has taken it upon himself to drop Flash for the whole month of February as a response to this tweeted challenge:
All those who think no flash on ipad is A-OK please uninstall flash from your current browser, use that for a month then get back to me.
Installing a Flash blocker isn’t really a groundbreaking exercise and is tamer than uninstalling Flash completely, but now is the best time to figure out how dependent we are on it.
So can you survive sans Flash? I won’t go out of my way to defend it nor suffer from withdrawal without it, but the status of HTML5 video alone seems troubling enough.
More importantly, most discussions cover only the question of replacing Flash video, not other applications like games. That would be an even tougher nut to crack, even with the dawn of purely Javascript-based games.
Google brought back the 80s arcade game Pac Man to celebrate its 30th anniversary last May 22nd in the form of a fully-working Google Doodle on its homepage (it’s been since moved to a dedicated page where people can still play it). The “I’m feeling lucky” button gets replaced by “Insert coin” and clicking on it lets you play. Click on it a second time and Ms. Pac Man joins in the fun.
Apart from hearing collective 8-bit cheers of delight upon discovering what could be Google’s most viral web toy yet, the Pac Man doodle was another display of its massive influence, both the good and the bad. more
Google is throwing its own hat into the web fonts ring with the Google Font Directory and the Google Font API. While it appears it doesn’t have any partnerships with the big names in typography like TypeKit does, just a handful of open fonts, it does have a partnership with TypeKit itself (as you’ll see below).
How the Google Font API works
Once you pick a font, you can embed it on a webpage by grabbing code that looks like this:
<link href='http://fonts.googleapis.com/css?family=Josefin+Sans+Std+Light' rel='stylesheet' type='text/css'>
And use it in your stylesheet like this:
h1 { font-family: 'Josefin Sans Std Light', arial, serif; }
You can also use other fonts using the WebFont Loader, which is a JavaScript library developed by Google and TypeKit.
Bane or Boon?
Although I won’t be ditching Font Squirrel anytime soon, one great thing about this new development is that the fonts are hosted on the most reliable servers in the world, just like the different JavaScript libraries are. The even greater thing is that this is Google, one of the strongest forces on the Web, is placing a stake another aspect of web standards.
Of course those things are scary at the same time. Google can just pick any endeavor under the sun, spend resources on it, and possibly dominate, if not dictate the market in no time. It may not get the purist designer types on board, since Google doesn’t exactly have the best reputation for great design, and its presentation has a bit of a developer slant, but it knows its web design technologies well. And in the case of web standards, where new practices are being adopted and old browsers are being discarded at a snail’s pace, Google’s massive resources and influence can only do well to speed things up.
Right now, so many major players in the web browsing space have turned to the WebKit project for its rendering needs—
- Apple: Safari
- Google: Chrome
- Nokia: Symbian web browser for S60
- Google: Android web browser
- Research In Motion: BlackBerry web browser
- and more
—that one has to wonder if web browsers should just stop running on their own and agree to just merge, possibly under WebKit, since it seems to be so popular across the board. To be clear, if Mozilla’s Gecko renderer had the same track record, I’d say the same thing.
It’s less a matter of killing healthy competition and innovation among vendors, more about eliminating the headache of rendering differences. People can probably file away all the browser bugs and inconsistencies across browsers and their various versions in a full encyclopedia set. (IE6 would take up at least a couple of volumes.) This tedious aspect of front-end development could be greatly reduced if all these browsers adopted the same rendering kit. Then the vendors can focus on improving and innovating in other aspects, like what Google did with its JavaScript V8 engine.
Mozilla can enjoy more time expanding its already large and loyal userbase, working on Labs products like Bespin and Weave, pushing for the WOFF web font format, and so on.
One can argue that if we should be able to choose browsers, then the same can be said for underlying rendering engines, and accept the differences as a a consequence of the freedom to choose. But does a consumer of the Web need to choose which rendering engine he prefers? Or are the differences something we can finally do without?
I, for one, would be thrilled if we didn’t have to worry whether websites looked the same in every browser, and just focus on making websites look and behave the best they can. And I’m pretty sure ordinary users don’t even think about rendering differences.
It’s been a couple of years since the height of the “kill IE6″ web campaigns, and it took that long to hold a funeral that finally seals its fate.
Of course, the IE6 Funeral is an arbitrary event held by the Aten Design Group last March 4, and this doesn’t really eradicate the browser on computers that can’t upgrade.
Over at TechCrunch, commenter Jeff Carlson jokes: “So if someone uses IE6 to browse the web tomorrow, will their web browser be a Zomb-ie6 browser?” You could say that. After all, IE6 is way past its expiration date, sucking the brains out of web designers and developers with its buggy, unstable, insecure features from an ugly past.
Even Microsoft acknowledges it’s time for IE6 to go, as it actually sent over flowers and this note:
Thanks for the good times IE6, see you all @ MIX when we show a little piece of IE Heaven. The Internet Explorer Team @ Microsoft
On March 13, Google will end IE6 support on YouTube, following the March 1 pull-out for Google Docs and Google Sites. Gmail and Google Calendar are next on the list, slated by the end of the year.
Combined with the European government security warnings to upgrade browsers, could Google’s systematic phase-out be the final nail in the IE6 coffin, or is this slow death going to take at least another year?
I really hope this is it.
A year or so after Google Chrome was first released, it’s now my default browser. While I still use other browsers on a regular basis, Chrome’s speed and minimalism has taken over. Take the omnibox, which merges the address bar and search bar into one. It searches your bookmarks, your recently visited pages, and even detects if the URL you’re typing has its own site search.
Most of these features are available in Firefox, whether by default or as an add-on, but the reason I’m focused on Chrome is that it’s a Google product, and this company can push both its browser and search forward by turbocharging the omnibox the way they’re continually adding new features to Google search.
The Chrome extension Google Quick Scroll, which highlights and jumps to portions of a page where one’s Google search query can be found, is a perfect example of Google search and the Chrome browser working side by side to improve the search—and more importantly, find—experience.
Google’s autocomplete search box is getting more powerful each day, so why not integrate it into Chrome? It probably won’t matter to those who can’t tell the difference between a web browser and a search engine, and use Google as a jump-off point to browsing other sites, but Google can significantly alter the whole searching-browsing experience if it so desires.
One downside would be eliminating the need to visit Google.com itself and contribute to the ad impressions, but that should only happen for quicker, smarter searches such as weather forecasts, currency exchange rates, stock quotes, etc. The fewer clicks, the better.
Web standardistas lament the outdated HTML and CSS support by IE6, but the biggest reason you should drop the browser stat is security, security, security. And if the following evidence from Google, the governments of Germany and France, and Microsoft itself do not convince you, I’m not sure there’s much else that will:
- The Chinese cyber attacks on Google (and at least 20 other large companies) got through because the exploited code worked only in IE6, on Windows 2000 and XP.
- The German and French governments have both asked its citizens to upgrade their IE6 browsers to prevent attacks happening to them.
- Microsoft released a security advisory warning against attacks specifically against Internet Explorer 6.
Mashable includes the three items above in its list, but the last one is the most compelling:
This will not be the last massive IE6 security breach: This flaw was unknown before Google’s groundbreaking China announcement. And it’s not the first flaw ever found with the browser — there are at least 142 vulnerabilities in IE6, 22 of which are not yet patched. Would you use armor that had 142 weak spots?
Internet Explorer 6 is a run-down browser with very little support for exploits. It’s more costly for businesses to leave it lying around like a ticking time bomb than exert effort to upgrade their systems.
The good news is, we’re getting bigger institutions stepping up against IE6. Let’s hope their spheres of influence really are that effective. You can’t get much bigger than European governments, Microsoft, or Google.
According to Ajaxian, the beloved tradition of learning by peeking at someone else’s source code is on the brink of extinction. Because Google is rewarding websites that load faster, people will stop at nothing to look good in the big G’s eyes, including code compression and more notably, obfuscation. This renders View Source useless.
While I feel it’s too early to call doomsday on View Source because of such speculation, like many I feel protective over it. It’s no surprise then that the Save View Source movement has been formed this early. The discussion is sparse, but Alex Russell elegantly explains why View Source matters, also reminding me why I love developing on the Web:
View-source provides a powerful catalyst to creating a culture of shared learning and learning-by-doing, which in turn helps formulate a mental model of the relationship between input and output faster. Web developers get started by taking some code, pasting it into a file, saving, loading it in a browser and hitting ctrl-r. Web developers switch between editor and browser between even the most minor changes. This is a stark contrast with technologies that impose a compilation step where the process of seeing what was done requires an intermediate step. In other words, immediacy of output helps build an understanding of how the system will behave, and ctrl-r becomes a seductive and productive way for developers to accelerate their learning in the copy-paste-tweak loop.
Even in compiling languages people learn better by looking at example code, but the culture of open learning can be felt strongest on the Web. Ajaxian posts a follow-up, in which I couldn’t agree more with this:
I personally feel like the ability to view source fit in perfectly with the culture of the Web, and was especially important early on. I am willing to bet that we have all learned from the notion of view source.
The freedom of access to tons of information on the Web is what it all boils down to. View Source is a sturdy consequence of that. It seems wrong to compare performance versus learning, but between those two, learning should prevail.
Then again, who can stand in the way of site owners desperate to turn up traffic and profit? Sounds like standards versus SEO all over again. What do you think—is the Save View Source movement an overreaction or a preemptive strike?
It’s not just about net neutrality or privacy anymore. Our future internet could be the very opposite of what it is today—free—specifically due to companies dominating their markets and the constant push to simplify the user experience.
Tim O’Reilly predicts a war is coming, one where we are at the mercy of the internet giants like Google, Facebook, and Apple: they stop making the services we are so highly dependent on interoperable.
It could be that everyone will figure out how to play nicely with each other, and we’ll see a continuation of the interoperable web model we’ve enjoyed for the past two decades. But I’m betting that things are going to get ugly. We’re heading into a war for control of the web. And in the end, it’s more than that, it’s a war against the web as an interoperable platform. Instead, we’re facing the prospect of Facebook as the platform, Apple as the platform, Google as the platform, Amazon as the platform, where big companies slug it out until one is king of the hill.
Chris Messina fears something similar as well: the death of the URL, as new formats for delivering web content are abstracting the website-going experience and letting ourselves relinquish control.
By removing our ability to navigate, choose, and share freely — these app stores are exchanging our freedom for a promise that they’ll keep us safe, give us everything we need, and do all the choosing of what’s “good enough” for us — all starting at ninety-nine cents a hit.
I know that if we always look at things with a worst case scenario in mind, we’ll never get any work done from here on out. But better to worry now than when it becomes impossible to undo things. I like how the Web is now, no matter how chaotic and crap-filled it can be.
That said, if the URL disappears, I know few people would be troubled by it, and an overhaul of the system may be needed anyway.
And as for the giants bullying us into a corner, it makes me wish the Long Tail would stand a chance.
*/
