In order to convert my puzzles to work with Google Gadgets, I’ve shifted from a page-reload mechanic to an AJAX-y XHR-driven one. As a result I’ve discovered first-hand that the new thing isn’t always better. I’m sure that this has been covered before, but here are a few ways in which an AJAX approach is inferior to a more explicitly REST-ful one.
Address Bar
With a traditional approach, you can use the browser’s address bar to convey information to a user. A meaningful URL can help explain what a page is, and can be manipulated by sophisticated users to navigate your site more easily. An AJAX-y approach tends to yield generic URLs that are only loosely related to the content of a page. This means that navigation information and controls must be added to the page content.
Navigation (The Back Button)
Under a REST-ful regime, the browser’s back (and forward) buttons work as the user expects, for free. With AJAX, getting these buttons to do something meaningful, let alone intuitive, becomes not only more work, but also a design exercise. At a minimum, this seems like re-inventing the wheel.
Bookmarks and Email
Bookmarks are another feature that must be re-invented, tweaked, or cheated once you decide to move to AJAX. This is related to the issue underlying the first problem: URLs are only loosely coupled to the content a user sees on a page once AJAX is in play.
Another consequence of dynamic page content is that a user can no longer grab the URL from their browser (or the link that led them to a page) and e-mail it to another person, confident that the recipient will see the same page.
Summary
In general, AJAX is neat because it can update a page more fluidly and flexibly than a system driven by reloads of static pages. The price of this is that the content of a page is described poorly, if at all, by its URL. The user experience of the web is based around the expectation that URLs describe the contents of the resources they retrieve very well. (I.e. even if the URL isn’t meaningful to a human, a given URL will retrieve a resource that will be pretty much the same “thing” at all times on all platforms for all users.) Violating this expectation has costs. AJAX may be the right choice, but it’s not obviously the right choice in all cases.
Future Work
I’m a little behind on my widget conversion; I’ve got a prototype working, but want to review some of the changes I’ve made before releasing it. My increased ad budget is resulting in more money being spent, and more clickthroughs to the whitepaper, but only a gradual increase in traffic. My quality scores are holding pretty steady for my core keywords; I think I might try dumping the marginal keywords and ratcheting down my bids in order to try to get my CPC down. This all remains experimental, since I have no good way to monetize the trickle of traffic the site gets, but it will be interesting to see what happens nonetheless. In the queue:
- Finish widgetization
- Better aStore placement
- Puzzle forum postings
- Add social features to widget (?)
- Drop maximum bid, see if CPC can be lowered
Yesterday’s Stats
Stat | 21st |
---|---|
Visitors | 33 |
Visits | 36 |
Pageviews | 164 |
Pages/Visit | 4.56 |
Avg. Time on Site | 8:14 |
Follow Along
You can subscribe to my RSS feed, if you’d like to follow along with this month’s project, in which I attempt to create and popularize a puzzle site.