All posts tagged ‘Ajax’

“The page you’ve requested does not exist.” So cold and unforgiving. Unlike a bad database connection or an unresponsive server, the 404 Page Not Found error has a finality to it — this link is dead and it’s never coming back.

But now we have Catch404 by Addy Osmani, a jQuery plug in that handles broken links with style. Deploy Catch404 on your site, and instead of seeing a page reporting a broken link, the user is presented with an Ajax modal window (also called a hop-up, or a lightbox) informing them the linked page isn’t there. The windows also offers some alternate destinations they might want to check out.

We’ve been trying to make 404s go down a little easier for years now. The custom 404 page is a popular solution. It’s available on just about every web CMS out there. You can do it yourself, too. Browsers are also taking it upon themselves to beautify the broken link with custom pages, offering suggestions or inviting users to search for the page using a built-in search box.

Catch404 takes both of those ideas — the custom alert and the suggestions of what to do next — and places them into the user experience before the link is even loaded. The plugin, which requires the jQuery framework, sends the link off to Yahoo’s YQL engine to check to make sure it’s alive. It only performs this check for external URLs; local URLs don’t require the check. The check is performed behind the scenes, using an Ajax request. If all is good, the user goes about his or her way. If the check results in a 404, the user sees the modal window.

You’ll notice one obvious downside, which is that your users will have to wait an extra half-second or so while the YQL call completes. So why use it?

When a user is browsing your site and clicks on a link you’ve provided, then sees a 404 error, it’s your problem whether you’re responsible or not. Linking to dead pages makes you look like a sloppy curator, and the user will place some, if not all, of the blame for that error on you. Catch404 is more helpful than an impersonal error.

If the speed hit from the cross-site link checking bothers you, consider adding Catch404 only to legacy content — those years-old pages filled with links that may or may not still be alive.

Activating Catch404 is simply a matter of assigning a class to the link, so you can invoke it only where it makes sense.

If you hang out with designers and developers at all, then you’ve probably heard the term “Ajax” by now. It’s the official buzzword of Web 2.0. But it’s also an extremely useful web development technique.

In the course of this tutorial, we’re going to look at what Ajax can do. Then we’ll use a JavaScript class to simplify your first steps toward the ultimate in speedy user interactivity.

First, what is Ajax? It stands for Asynchronous JavaScript And XML. In simple speak, Ajax allows us to use JavaScript to grab an XML file (or any other text) without reloading the whole web page.

Ajax has been used for a lot of things, but it is most impressive when many small updates are needed in a short period. Think streaming stock quotes or draggable maps.

So, since the last time you brushed your teeth, Ruby on Rails has only grown in popularity. The list of web applications using the exciting new web framework has grown to such an enormous size, it has exceeded the 50K per page limit of the wiki used to host it. Lesser languages like Java and PHP are copying the stylish efficiency of Rails with their own frameworks like Trails, Trax and Cake.

In the tutorial Ruby on Rails for Beginners, we went over the very basic basics of Ruby and Rails:what it is, why it’s so mindblowingly cool, which celebrities are using it, and so forth. As soon as the article went live, letters flooded in, offering me book contracts, movie deals and exotic snacks — I haven’t gotten so much attention since my Ajax for Beginners article. In fact, this poll from the redoubtable Lifehacker.com says that Ruby on Rails and Ajax are among the two most popular things in the world, and plainly it pays to follow the trends, so what if we combined the two of them? No, that would be excessive. You don’t want to read about that. You do? Hmmmm, OK, I suppose we can take a quick look.

Online maps are a popular way to spice up a site. To get the most use out of them, you need data to plot: addresses from a database, location clicks from the user or at least coordinates for the map’s center. With any map, you have to start somewhere.

If you’re low on data, you can fill in the map with local listings, such as those you’d find in the Yellow Pages. You can show coffee shops or pizza joints right along your other data, or even on its own.

In this tutorial I’ll show how to use Yahoo Local to search for nearby businesses and landmarks, then plot those locations on a Yahoo Map using the Ajax API.

Developer Mark Pilgrim has posted a fascinating look at how the HTML img tag came into existence. The history Pilgrim digs up — mailing list conversations between the creators of the first web browsers like Marc Andreessen and the webs early pioneers like Tim Berners-Lee — show that far from being a carefully planned specification, the lingua franca of the web evolved a bit like the early universe — out of a murky chaos.

That from the chaos we got a workable — some would argue good — solution for creating the web is proof on some level that conversations and not abstracts, proposals and design by committee are the key to HTML’s success.

As Pilgrim writes:

HTML has always been a conversation between browser makers, authors, standards wonks, and other people who just showed up and liked to talk about angle brackets. Most of the successful versions of HTML have been “retro-specs,” catching up to the world while simultaneously trying to nudge it in the right direction.

You might be wondering, why did img succeed where other proposals, like an include or an icon tag failed? The answer is simple, because Marc Andreessen shipped code — Netscape Navigator — while those backing the other proposals, for most part, did not.

Of course that doesn’t mean that just shipping code is always good plan. Shipping code before a standard doesn’t necessarily produce the best solutions, as Pilgrim says. Or, put another way by a commentator on Pilgrim’s post, “shipping doesn’t mean you win, but not shipping means you lose.”

From those who shipped without the official blessing of a standard, we’ve come to have an img tag, the basis for AJAX, all of the HTML5 tools available in browsers today and much more.

Critics of HTML’s disorganized evolution will be quick to note that we’ve also come to have the blink tag, cross-browser rendering issues and other pains of web development.

Indeed we’re not suggesting that shipping features without at least engaging in the conversation is a good idea, but, when it comes to the future of HTML, if browser makers don’t ship HTML5 features before the standard is official we’ll be waiting until 2022 to use the new tools.

But while the future of HTML5 might be moving at a rather slow and convoluted pace. Pilgrim’s post is reminder that HTML has always progressed that way.

Perhaps the truly remarkable part is that, for all its flaws and convoluted evolution the core tech behind the web remains essentially the same now as it was then. “HTML is an unbroken line… a twisted, knotted, snarled line, to be sure… but still… Here we are, in 2009, and web pages from 1990 still render in modern browsers.”