- We design and build extraordinary applications for companies looking to make the next great idea a reality.
- learn more
Mash Note: Ninjawords online dictionary
In keeping with my new year's resolution to laud as many good Ajax apps as I trash bad ones, please allow me to celebrate the simplicity, beauty and utility of Ninjawords. An online dictionary developed by Phil Crosby, Ninjawords offers a fast, minimal Ajax interface built on the Ruby on Rails and Mootools frameworks.
When you visit the Ninjawords homepage for the first time, you see nothing but a Google-esque single-field search form and two buttons. When you type a word into the text field and click the "look up" button, a single definition for that word appears almost instantly. Most definitions come from the open-source Wiktionary; these definitions are linked to their respective Wiktionary pages and may also include a list of synonyms. For words not covered by Wiktionary, Ninjawords defaults to the Princeton Wordnet dictionary, which doesn't offer synonyms or linkable pages.
Topics: Ajax Applications, Mash Note, Ruby on Rails
Ajax Predictions for 2008
I'm a little early this year for my 2008 predictions. No matter. I seem to have been a bit early with my 2007 predictions as well, and as they say in the venture capital biz, "too early is the same thing as wrong." Some of my predictions did come true -- Ajax is no longer such a big buzzword; a number of framework specific books (GWT, jQuery) have been published at the end of 2007; Microsoft's Ajax stack continues to limp behind the rest. A few others did not, notably the ho-hum release of IE7 and the delay in FF3. So, let me try my hand at some more prognostication:
- Elegant, good looking frameworks like Ext and myGWT will gain traction. The more out-of-the-box good looks you can give them with CSS and bundle images and icons, the more acceptance they will gain.
- The JavaScript framework chaos will continue. The OpenAjax alliance will continue to be ineffectual in promoting things like widget interchangeability.
- Security will become a big headache, as less sophisticated developers start to venture into the wonderful world of Ajax, littering the web with state and control logic on the client side.
- Towards the end of 2008, FF4 and IE8 will start to change the landscape of Ajax and Web 2.0 with an update of JavaScript and new browser features.
- MS Volta will do nothing. It is just a FUD shot across the bow of GWT.
- Everyone except Craig's List will have some form of Ajax on their site.
- Desktop RIA's through Google Gears, Adobe AIR, etc., will start to make an impact in the second half of 2008. Look for desktop/web hybrids of the office productivity tools, such as word processors and Powerpoint clones, to see greater use in the corporate IT space.
- GWT's compiler will produce more efficient code than 98% of JavaScript developers can do by hand.
- With the new browsers, a cross platform Canvas/SVG will be a reality by the end of the year.
- IE8 will still leak memory like a sieve.
Have any of your own predictions? Feel free to add them in the comments.
Technorati Tags: ajax, 2008 predictions
Topics: Ajax Applications, Ajax Development, Ajax Frameworks, Analysis
Ajax, Browsers, Running Out of Time
History repeats itself, first as tragedy, second as farce. -- Karl Marx
I can remember the day, back in 1994, when I abandoned the Mac for Windows. It was a gloomy, overcast day when I made that bittersweet decision -- I was a Mac and Unix nerd all through college -- but after my twelfth or thirteenth crash of the day, I had had enough. Photoshop, Netscape, Secure Shell and Word were just not meant to run more than one at a time on Mac OS 7. Had I stayed with Apple through that rough patch I'm sure I would have been slimmer, sexier and happier, but NT 3.51 only crashed twice a day, so my hand was forced. I ran out and bought a PC that very day.
Now I fear history may be repeating itself. Yesterday, I had Firefox 2 for linux crash 5 times, and IE7 for XP crash 7 times. The cause? Too many fat Ajax applications. Zimbra, the whole Google bestiary of applications, Yahoo Mail, etc.. These are all long running applications that I keep open for most of the day. Then all of a sudden the Browser is gone and I have to relaunch and login all over again.
I'm not alone in this. Colleagues and friends report similar problems with Safari/Mac, IE7/Vista, Firefox/Mac. I've even checked with a friend that runs the helpdesk for a large firm: reported problems with browsers are up. The only one who seems blissfully unaffected is the lone Opera nerd in my office. He just keeps chugging along with what seem like 200 open tabs.
The cause should be evident to everyone. We've taken what was first called LiveScript -- a crufty embedding just good enough to validate a form or two -- and we've abused it into being the foundation for a whole new kind of application platform. The browsers have just not kept up and the situation will only get worse with the accelerated proliferation of Web 2.0 apps.
Help is on the way, in the form of bytecode interpreters and vm's for Safari and Mozilla, though the future of IE is still cloudy (still, there is a plan to bring Tamarin to IE). But if the new Browser version don't arrive quickly enough, or if they don't fully solve the problem of browsers crashing once an hour, then a mass migration to Opera may be the best we can hope for. At worst, content and application producers will opt for more stable non-Ajax alternatives such as Flash or Silverlight.
Ajax and the browsers it depends on are running out of time. If the notion spreads that it isn't reliable, it will be as dead as the Java Applet, never to be heard from again.
Topics: Ajax Applications, Browsers, Editorial, Firefox, IE, IE6, IE7, Javascript
New Ajax for Old Iron
In the rush to develop entirely new Web 2.0 systems based on Ajax, it is often easy to lose sight of how it can be used to improve the so-called "legacy" enterprise systems. Over at the Ext JS blog, there's a post about German developer who put together a reporting/BI application to front-end RPG code running on an AS400.
The backend serves up JSON data (together with this old article about reskinning a Spring MVC application with Tibco GI, it makes for a solid approach for refactoring existing webapps) to the Ext JS/Flash front-end. Slick. You can view a demo (unfortunately in German for you non-German speakers) here.
Technorati Tags: ajax, ext js, as400, flash, json
Topics: Ajax Applications, Ext JS, Flash, JSON
Tibco GI/Craigs List Bashup
Over at Ajaxian you can read about a pretty cool remix of Craig's List, somewhat similar to what I've been working on with GWT. I've termed this a "bashup," rather than a "mashup," because it kind of mashes things up against one or more of the participants wills. Now, whereas my solution will be injected into the site's page via a bookmarklet, this mashup proxies Craig's List through it's local server. I'm pretty sure that violates Craig's List's TOU (see article 12, ACCESS TO THE SERVICE).
Technorati Tags: ajax, tibco gi, craig's list, mashups
Topics: Ajax Applications, Ajax Frameworks, GWT, Mashups
Google Docs presentations: A beta is a beta is a beta
By now everyone has probably heard that Google finally released its long-discussed presentation webapp yesterday. Not too many surprises here: It's been rolled into Google Docs; it offers a nice set of basic features; but it's got a long way to go before it becomes the "Powerpoint killer" breathlessly anticipated by the mainstream tech media.
Like all of the productivity webapps under the Google Docs banner, the new addition offers a decent level of functionality for entry-level users; a fairly snappy web interface; and the opportunity for multiple users to collaborate online without having to forward a bunch of versioned attachments. It's also got a lot of the same problems as other Google apps: The auto-save function can be a little slow and annoying; power users are unlikely to find all the features they're looking for; and new features are often slow to come on a free, beta service.
Still, I gave it a whirl and found that I could create, collaborate, share and publish a set of slides quickly and easily. I may not be able to create cheesy transitions, but I can choose from several themes and upload my own images without a hitch. Playback was a little glitchy when large images were involved, but overall, this would be perfect for your typical class presentation or talking points for a staff meeting.
Between MS Office, iWork, OpenOffice and Google Docs, there hasn't been this much consumer choice in the productivity market since the early days of the PC explosion. It would be nice, however, to see a webapp that really challenged our tired assumptions about how presentation software worked - the same way Gmail's threaded conversations and instantaneous search rendered hierarchical folders and idiotic "advanced search" wizards obsolete. Maybe once all the big players have rolled out their "me, too" offerings, we'll start to see some real innovation.
To close, let me offer this disturbing/amusing 2005 news story I found when Googling the term "Powerpoint killer." For those without a Washington Post or BugMeNot login, let me point out that the lead to this article is "Did PowerPoint make the space shuttle crash?" Food for thought, and a cautionary tale for the folks in Mountain View.
Topics: Ajax Applications
Cognitive Load, Portability and the Superiority of Client-Side Frameworks
The recent introduction of TrimPath Junction got me to thinking about Dietrich's widely read post on Cognitive Load and the Superiority of Server-Side Ajax GUI Frameworks. GWT's big advantage is that it mobilizes armies of Java programmers to write browser-based applications without having to learn JavaScript. This is clearly of enormous benefit to organizations with lots of Java programmers, few client-side resources, and a burning desire to build powerful webapps. Yet for the similarly huge army of client-side programmers out there, GWT is pretty useless. Why learn a foreign language just to have it translated back into your native tongue?
I haven't yet had a chance to play with TrimPath Junction, but it sounds pretty cool. Using the open-source Helma framework, it offers Rails-style MVC scaffolding in a JavaScript syntax that executes the same code on the client and server. Basically, it's RoR meets Adobe AIR for JavaScript programmers. I hope to give it a test drive soon.
Server-side JavaScript has been around for ages, but it's never really become a common development model. I remember writing ASP Classic apps in server-side JScript back at the turn of the millennium and having people wig out on me. "Why not write in VBScript like everyone else," they'd ask. My answer: "Because I can save time by running the same validation libraries on the client and the server ... and because I can write the entire app in one language." I obviously have no argument with Dietrich's thesis on cognitive load. It's just that my brain features a JavaScript compiler, not a Java one.
GWT is a great piece of engineering that keeps getting better; just check out the new non-beta 1.4 release. But I think there are a lot of advantages to frameworks that mobilize the JavaScript masses to write front-to-back webapps. The same cognitive efficiencies can be achieved, plus client-side programmers already know all the pieces of the UI puzzle. Ask a room of Java developers how to build accessibility and usability into standards-compliant XHTML and CSS. Nine out of 10 wouldn't have a clue.
The other big advantage to developing UI code in its native language is that you can port it to any server platform. With GWT and similar frameworks, you've got to rebuild much of your UI from scratch if you want to change course in mid-stream. With purely client-side frameworks such as Prototype, jQuery, YUI or MooTools, switching libraries may entail rewiring some of your code to a new API. But switching server platforms, from J2EE to .Net to PHP to RoR, can be done without much work at the UI layer. "The right tool for the right job" is a truism for a reason. Pure client-side development of UI code allows for the development of reusable components whose only dependency is on the standards bodies and browser vendors who control JS, CSS and HTML. GWT and its peers are useful for some teams and some projects, but they're not the only answer to webapp development.
jQuery vs. Prototype: OO JavaScript with or without training wheels
After brushing up on jQuery via a little light reading, I've started to play with the framework in code. I'm demoing a scrolling news ticker and decided to write it using jQuery and its Interface plug-in. Future iterations will probably include the history and easing plug-ins, too. In the meantime, though, it's been two steps forward, one step back. I really dig the elegance of the jQuery API and its concise method-chaining. But there's one integral element of the Prototype/Script.aculo.us framework that I miss: The Class object and the OOP training wheels it provides.
For developers like myself - long-time UI folks who have used JavaScript's Object datatype for years but lack significant experience writing in a strongly typed, truly object-oriented language like Java - Prototype has been a revelation. It doesn't enforce OOP principles, but it encourages them. And its source code is like a Rosetta Stone for how to implement them in the dynamically typed, prototype-based world of JavaScript.
There's been lots of discussion over the past year about the deficiencies of Prototype's inheritance scheme. A lot of the syntax is ugly, and Object.extend is easy to overuse or misuse. The new 1.6.0 release candidate appears to address some of those weaknesses by augmenting the Class object's API. Regardless of your position on this debate, though, it's hard to ignore the fact that Prototype has helped a lot of front-end folks improve their half-assed understanding of OOP. Personally, I wouldn't even be in a position to follow the discussion if I hadn't spent the last 18 months or so writing Prototype-backed JS classes. Thanks to the patterns to which this library has exposed me, my grasp of JavaScript - and of software engineering in general - has grown by leaps and bounds.
Once I started using a different library, though, Class.create was suddenly useless. I had to figure out different inheritance and encapsulation strategies. The training wheels were off, and I had to find my own of balance. My first hurdle was figuring out how to organize my jQuery procedures into reusable methods. I felt totally adrift without the built-in ability to bind functions to their execution environment; the this keyword was always assigned to a DOM node. I thought about simply porting Prototype's Function.bind and Function.bindAsEventListener methods, but that seemed at odds with the design of jQuery's own API. Finally, I turned to Douglas Crockford's module pattern for JavaScript. Now I had a new way to organize my objects and methods in a reusable way that worked well with jQuery. By defining private methods inside of a closure, I could access those methods with simple function calls, no binding necessary. As with Prototype, a whole new world opened up.
A lot of developers worry that Ajax frameworks make for lazy programmers, but in my experience the opposite is true. Each new design pattern or framework that I play with teaches me new approaches to JavaScript and OOP in general. Folks coming at UI development from, say, a C++ background may want a framework that enables a well-defined inheritance model. But OOP scaffolding is a separate concern from Ajax and DOM tools. Prototype provides both, while the base jQuery library provides only the latter. Still, somebody could easily write an OO plugin for jQuery - or several of them, each implementing a different inheritance model.
Simon Williamson's recent post on jQuery for JavaScript programmers does a good job of explaining how jQuery encourages good OOP techniques. The walled-off namespacing represents a different conceptual model from Prototype's. Until you understand both, it's difficult to see all the strenghts and weaknesses of either. As with other tool, the key to these frameworks is learning what tricks and tradeoffs each one supplies, and why. Up next: YUI and Ext.
.Mac improvements: That’s it?
Amidst all the hardware news at Apple's Mac-focused media event last week, it was easy to overlook the announcement of some tweaks to the widely reviled .Mac web-services suite. Easy to overlook not because the announcement got no play, but because the improvements were so underwhelming. Even with 10 times the online storage space (10 gigs, up from 1 gig) and a slick new Ajax-backed photo service, the upgraded .Mac suite still costs $100 a year. Meanwhile, most of its individual features continue to lag behind the functionality and performance of free services from a host of other providers.
Commentators here, there and everywhere have predicted - and in many cases advocated - the death of .Mac for a long time now. I wonder if Mac newbies' continuing propensity to pony up for the service has something to do with Google's inability to parse the period in ".Mac" and return some relevant search results for such phrases as ".Mac user reviews." [Here's a hint: search for "dot-mac sucks" instead.] There's no shortage of users who find the service disappointing, and the latest tweaks aren't likely to change that.
Based on the demo I've seen of the new .Mac Web Gallery, I can see why an iPhoto junkie might be persuaded to dump Flickr and give it a whirl. But why settle for syncing Safari bookmarks when you can use a social bookmarking service or a bookmark-syncing plug-in for your browser of choice? Why settle for viewing your Address Book entries from a primitive web interface when a service like Plaxo lets you edit them online, too? Why merely view iCal entries online when you can actually edit your Google or Yahoo calendar from any browser? Why use .Mac's painfully slow, frequently buggy online backup service when you can switch to Amazon's S3? Why use the old-school .Mac webmail client when all the major free webmail vendors offer snappy Ajax interfaces? Why host your personal site with iWeb when so many other free or low-cost solutions offer more flexibility and power?
No webapp is perfect, and no single provider offers the breadth of .Mac in a single suite. But cheap or free a la carte services from best-of-breed providers work better for all but the most dedicated (or lazy) Mac users.
Leander Kahney over at Wired stayed up late the night before Apple's presentation to say a prayer that Jobs & Co. would radically overhaul the service. But the best that can be said about the "new" .Mac is that its developers finally seem to be dimly aware that there's this whole Web 2.0 thing happening out there. The future promises some upcoming, though as-yet-undefined, .Mac webmail improvements that could help modernize the service. But the suite's most compelling features are the ones that link one Mac to another, such as Leopard's forthcoming Back to My Mac application. True Apple fanboys may get a lot from such utilities, but they're useless for people in the real world - the ones who log onto Windows boxes at work every day and still want access to the data from their personal MacBook Pros.
My real problem with .Mac isn't that its webapps are sub-par. It's that Apple's overall strategy in the PC marketplace is still so focused on a single, unified desktop experience geared toward the mythical "average user." (Thanks, Walt Mossberg, for making that the most overused phrase in technology writing.) It's such a Microsoftian strategy: continually cramming all the the things a typical customer might need into a suite of pretty-good apps and services whose only real advantage is their supposed integration.
Given that Safari is being positioned as the platform for iPhone software development, it seems likely that core pieces of the OS X desktop experience will eventually get better browser-based simulations. But as a Mac user, I want the data on my machine to play well with third-party webapps, too, in my user-agent of choice. The whole advantage of the web desktop model is that all of my data lives in the cloud and, thanks to public APIs, I can interact with it through a broad range of providers. I can use the out-of-the-box UI or create my own. I can aggregate Remember the Milk into my gCal with a widget instead of waiting for Google to come up with a first-rate to-do list manager. I'm not locked into a single piece of hardware, operating system or software vendor. But locking me into a monolithic suite seems to be the whole point of Apple's desktop strategy, .Mac included.
Right now, all .Mac does is sync data between Macs and allow me to access a subset of that data, in read-only mode, through the browser. That's simply not good enough, and it hasn't been for a couple of years now. Apple should be integrating each of its elegant, easy-to-use but fairly vanilla desktop apps into a web-services architecture. That way, I can use my Mac as an oasis of no-fuss desktop computing at home, but still have the power and the flexibility to do what I need to do from any other machine or physical location.
I get why Apple's user interfaces are geared toward somebody with my grandmother's level of technical proficiency. But why not set up .Mac so that third parties can create more powerful and varied UIs on top of the underlying services? That might actually be worth $100 a year. In the meantime, .Mac and the Macintosh platform are positioned as one-size-fits-all, all-or-nothing propositions. And there's nothing new about that, media event or no.
Topics: Ajax Applications, Business Reasons for Ajax, Google, Mashups, Safari, Web 2.0, Web Services, Widgets
Mash note: Remember the Milk
You've got to love a Web 2.0 startup manned by a dev team of 2 that manages to add every feature on your wish list just before said feature's omission really starts to bug you. That's the case with me and Remember the Milk, a to-do-list webapp developed by an Australian company and supplemented by awesome new features with astonishing regularity.
Although they're a commercial entity, they've got a beta API that's allowed the development of a handful of really cool mash-ups. They've had iCal integration and a gCal plug-in for ages. They got on the Twitter bandwagon really early. They were one of the first non-Google companies to port their application offline with Gears. Last but not least, they've got a powerful (though still not perfect) user interface. (More on that later.)
A little background: I've been an obsessive to-do-lister since high school. GTD is my mantra. During my years at Microsoft-centric companies, I used Outlook to manage my entire life. But these days I find myself on Windows, 'nix and OS X machines in disparate locations for hours or days at a time. A webapp is clearly the only way to go for my to-do needs. But after years as an Outlook power user, I need something that will slice and dice my many lists (work, play, home, shopping, whatever) with exacting precision.
I gave Apple's iCal a shot, but its list functionality was way too primitive. I need multiple lists, categories, tags, flexible sort criteria - you get the picture. Ta-Da Lists from 37signals was even more stripped-down than iCal - plus I found its interface surprisingly clunky for something developed by a well-regarded Ajax shop. I thought about todo.txt, but I'm not enough of a command-line purist to completely abandon the GUI - even after years of suffering through Outlook's hideous hidden menus. Then, about a year ago, I stumbled on Frank Gruber's Do More: Online To Do Lists Compared. I didn't agree with his conclusions, but at least he gave me several more options to explore. Luckily for me, Remember the Milk was the first one I tried.
There's a lot to love about RTM, especially its UI, so just let me gush for a minute.
- Flexible organization: You can create multiple tabbed lists, apply arbitrary tags to your tasks, and create saved searches based on any criteria.
- Keyboard navigation: Except for a few advanced functions, such as moving items from one list to another, you can do almost anything from the keyboard. Create tasks, set priorities and due dates, apply tags, edit multiple items ... most functions take only a single keystroke.
- Natural language entry: You can set due dates and repeat intervals using some pretty flexible natural language. It ain't perfect, but with a little training the syntax becomes second nature.
- SMS, IM and email reminders: The service can nag you quite effectively via a wide range of communication protocols.
- Email, gCal, Atom and Twitter integration: You can create tasks or lists of tasks using a special email address; add or edit tasks directly from gCal and Yahoo plug-ins; and use Twitter or Atom as syndication services. The public API means that mash-ups and cross-pollination will only proliferate.
- Built-in collaboration capabilities: There are a host of features dedicated to assigning, sharing and collaborating on tasks.
- Serious accessibility: The main app is fast, powerful Ajax all the way, but the mobile version works just as well in a variety of more specialized user-agents.
There are a few things to hate:
- Poor multi-list view: The main Overview page list all of your tasks that are due, overdue or due tomorrow regardless of which list they're on. But it separates the Today, Tomorrow and Overdue tasks into separate tabs. The gCal plug-in does a much better job of showing all of your most important uncompleted tasks in a single, unified view.
- Recurring task weirdness: Delete a completed instance of a recurring task, and you've just deleted the master version of that task. After any previously spawned instances are completed, the task will no longer recur. This is a very strange user experience, especially for folks who like to purge their completed tasks every once in a while.
- Poor sortability:
Tasks are sorted by their priority. Period. This shortcoming doesn't account for the fact that a low-priority task that's a week overdue is probably a high-priority task by now.
See the strikethrough text above to see exactly what I meant about the RTM team rolling out your must-have features before the lack thereof becomes too annoying. I've been dying for flexible sortability on RTM since I started using it. But no sooner did I start this post than I noticed an RTM blog post announcing just such a feature. It would be nice if you could set your sort preference globally as well as one list at a time, but that's a minor quibble.
So what can we learn from my ramblings, besides the fact that I really, really love this platform? I think there are a few powerful lessons for developers of any RIA:
- You don't have to sacrifice brawn for the sake of simplicity: Pleasing power users doesn't mean hopelessly confusing everybody else - at least not with smart UxD. (Apple could stand to learn that lesson, but I digress.)
- You don't have to sacrifice accessibility in the name of Ajax: Let your mobile app function as your accessible app, too.
- You don't have to fear Web 2.0 trendiness: Rapid adoption of emerging protocols such as Twitter can only help you differentiate your product and find new users.
- You don't have to lock your app down, even if you're a commercial enterprise: Public APIs - and the cross-pollination they enable - can only strengthen your foothold in the marketplace. In our Googlized world, this one's kind of a *duh*, but it bears repeating.
- You don't have to hide from your users: An active blog and well-maintained user forums are far more powerful marketing tools than terse release notes on Google Code.
I can only speculate as to the future of GTD's business model or exit strategy. Their logo carries the ubiquitous "Beta" tag, and their pages carry no ads. Where's the funding? It seems like somebody's waiting to get snapped up by a big player....
Lord knows it would be nice to have the old Outlook/Palm OS quintet of email, calendar, contacts, notes and to-do lists available on a single web-based platform; personally, I would prefer that platform to be Google, though I can't really see them acquiring a start-up just for this one capability. Still, it would be a shame if a product as solid as Remember the Milk got lost in the shuffle or edged out by inferior offerings from bigger players. Only time will tell....
That’s so 1999
Lots of trees (and pixels) have given their lives over the past 10 or 12 years to fuel the endless debate about graceful degradation, progressive enhancement and the separation of style and behavior from content. The web standards movement has gained traction by boiling the argument down to one simple assertion that geeks can sell to suits:
If you're in the business of hawking something - vintage hockey memorabilia, advertising impressions, "Harry Potter and the Deathly Hallows" or even plain old editorial content - then you should probably build web sites that make it as easy as possible for as many people as possible to give you their money...
... even people who can't or won't enable JavaScript in their browser/phone/whatever.
It astounds me that we still have to belabor this point in 2007. But a random sampling of large commercial websites reveals that even the big players haven't yet taken this lesson to heart. United Airlines, Sears, Expedia and Amtrak, for example, fail in various subtle or spectacular ways when you disable JavaScript or employ a user-agent without it.
(If you're using Firefox, just install the Web Developer Toolbar, use the Disable menu to turn off all JavaScript, and load one of these sites.)
When you load United's new(ish) multimillion-dollar booking engine sans JS, you get a search form with empty date dropdowns and a bunch of links and buttons that don't work. Sears.com is even more insidious. With a little bit of work, you can get some products into your cart. But when you click the checkout button, nothing happens.
Once upon a time, most commercial sites would at least use a <noscript> block or a server-side browser sniffer to warn you that their sites required JavaScript to function. That's how Amtrak does it today. So does Expedia:
"To enable great site features that are currently disabled, simply make a few adjustments to your browser settings ...." And what, pray tell, qualifies as a "great site feature"? Apparently, the ability to search for flights at all:
I can understand how a start-up like Kayak - with its innovative Ajax UI - can afford to demand a modern, scriptable browser. That will all change when they have a mature business model. But a travel behemoth like Expedia?
Look at the biggest successes of the eCommerce gold rush. Amazon, eBay, Yahoo and Google just plain work on all sorts of user-agents. Often, they offer separate interfaces optimized for mobile or assistive devices. Disable JavaScript on these sites and you can shop, search and browse to your heart's content. How can a site like Expedia not emulate them? Last time I looked, travel was a low-margin, high-volume business. Even if you're throwing away only 1 percent of your business, that's still a _lot_ of wasted revenue.
I'm also at a loss to explain how what's left of our pathetic national passenger-rail service can afford to squander potential customers by requiring them to use a technology that opens up untold security holes in the browser used by the majority of the planet.
Most places, I'm the biggest JavaScript dork in the room. I'm writing on a blog called Agile Ajax, for god's sake! But I still expect my favorite sites to work when I'm stuck on a Windows machine whose network admin has ratcheted up the security to absurd proportions. When I borrow a pal's iPhone, with its five-second script timeout, I expect to be able to do _something_ on the sites I visit. Ditto when I'm on a tediously slow connection on a laptop overseas.
I don't mean to pick on these sites. Heck, in a former life I worked for one of Expedia's competitors, and our site failures in non-JS environments were often of the silent but deadly variety. Even earlier, I was a contractor at United itself, and I'd sooner page through my junior-high yearbook than look at the still-live JavaScript code I wrote for them. Back when I was at Reflect.com, a now-defunct customized-cosmetics emporium in San Francisco, I used to generate the entire homepage with JavaScript, just because I could. I was having fun learning the language.
That was then, this is now. Jeffrey Zeldman's "Designing With Web Standards" is in its second edition. Any number of blogs, articles and books spell it out for even entry-level developers exactly how they can architect web applications that benefit from all that JavaScripty, Ajaxian goodness without turning away users who can't or won't partake.
We have the tools. We can do it. When we don't, it's a deliberate choice. The next time you're gathering requirements for a consumer eCommerce application, sit down with your client in front of a zippy new Vista PC running IE7 with JavaScript disabled via the security settings. Then try to buy some slippers from Sears, or a hotel room from Expedia, or a ticket from United. I don't think you'll have much trouble selling progressive enhancement as a fundamental part of the solution you're building.
InstaCalc - Shared Calculations
You may have already seen InstaCalc talked about elsewhere, the "sharable online calculator." Lots of the comments on Ajaxian (admitedly a tough crowd) back in March were largely negative. "Why bother?"; "Not slick enough."; "Too simple to be useful," were just some of the abuse heaped on Kalid Azad, the developer behind InstaCalc.
Since then he has polished up this Prototype/Scriptaculous based tool and added canvas-based charts (pie, bar and line). So it is a touch slicker than it was back then, very responsive, though I'm not sure it can ever be slick enough to satisfy all of the Ajaxian Web 2.0 grumps. And I think even before the latest improvements his app provided good value.
When I look at my own use of Excel, probably 95% of that usage is for small, parameterized calculations. I ask questions lik "If I bump up the memory, and reduce the disk space, what will that do to my cost?" and so on. I don't need to full power of Excel for this sort of thing, and given the increased use of Wiki's in development projects and corporate collaboration, the less information I have to stick in a seperate document, the better. This is precisely where a simplified tool like InstaCalc excels.
If I see one shortcoming, I'd have to say that it really doesn't need to be a freestanding application but should instead be integrated as a plugin into Wikis and other collaboration tools. This, folks, is the punchline to my question of whether collaborative spreadsheets were the killer Ajax app. Yes and no. Embedding simple "calculators" like instacalc will remove the need for most spreadsheet use, both offline and online.
Topics: Ajax Applications
Most Popular Ajax/Web 2.0 App?
I conducted an informal survey a while back on which Ajax-based apps people actually used. I got back a good number of responses and the results are in. With the exception of a smattering of applications such as GMail and Yahoo! Mail, far and away the most popular type of Ajax-based app was the RSS Reader. When you think about it, it is an online application designed to perform what is essentially an online activity: reading blogs. Mail, on the other hand, has lots of offline aspects to it (attachments, a history of offline reading, etc.).
I guess this result isn't too surprising, but I'm not sure what it says about the future of Web 2.0, all online apps. Do we all have to be weaned from our dependence on offline apps? Is this a thing "the kids" will be embracing, and not us elders? Or will we have to wait until there is truly robust online/offline functionality in Ajax/Web 2.0 apps, through platforms like Adobe's Apollo and the mysterious (does it even exist as more than an announcement and a slide show) Project Flair from Sun?
Topics: Ajax Applications, Analysis, Web 2.0
Review of Practical Ajax Projects with Java Technology
At a quiet time during my 40th birthday extravaganza, I finally had the chance to finish reading Practical Ajax Projects with Java Technology by Frank Zammetti from Apress. I've read enough good, hands-on Apress books by now to get a warm and fuzzy feeling anytime I see their distinctive bumble bee black and yellow covers, so I came to this volume hoping to find an Ajax treatment in that mold. The result isn't an unqualified success in that regard -- it goes broad rather than deep -- but if you're an experienced Java developer looking to get caught up on some of the Ajax developments of the last year and a half, this book is for you.
The book assumes a good foundation in server-side Java development, but little or no experience with the technologies that make up Ajax. Part 1 of the book, which is comprised of Chapters 1-3, is an excellent review of Ajax technology and architecture along with a basic review of Java webapp development. Part 2 consists of seven chapters, each of which develops an Ajax application.
- Chapter 1 gives a good overview of Ajax and the paradigm shift in web development that has caused. It also prompts the reader to consider questions such as when, where and why to use Ajax, as well as considering when fat clients or Flash are more appropriate for a Rich Internet Application (RIA).
- Chapter 2 is a crash course on Javascript, DOM, CSS and XML. You'll see some variation on this chapter in most beginning Ajax books, but this one does a better job than most. There are a few technical nits I have, mostly with inheritance. Specifically, the code in the book
MySubclass.prototype = MySuperclass.prototypeshould really be something likeMySubclass.prototype = new MySuperclass()so that modifications to the subclass's prototype don't affect the superclass. Otherwise, both the superclass and subclass inherit from the same prototype and are siblings rather than parent-child. But beyond this small technical oversight, the chapter is quite strong. - Chapter 3 is a review of Java web application development using open source technologies, specifically ant, Tomcat, JSP's, Servlets and Jakarta Digester. If you're already familiar with Java webapp development, you can safely skip this chapter. The one exception to this condition is if you've only worked with commercial application servers and just need a quick kickstart on the open source tools.
As we said previously, part 2 consists of seven chapters, each of which develops an Ajax application. Each application makes use of a different Ajax framework or toolkit, so the treatment of each is not particularly deep. One other curious thing about the examples is that the last two don't make use of frameworks while the first five do. This seems a bit backwards to me, since frameworks provide a level of abstraction over the underlying technology which hides its workings. As a result, you end up not understanding the why and how of how it works. I would have started with simpler projects in the first two chapters that made no use of frameworks, going on to higher level of abstraction as we moved along.
- Chapter 4 is a type-ahead suggestion application ala Google Suggest, i.e. you type in a few letters and it brings in a selectable list of possible completion. The example makes use of AjaxTags, part of the Java Web Parts (JWP) tag library. If you want to quickly add in Ajax to an existing application that incorporates JSP, this is one way, although after looking at all of the the different configuration and other files you have to write or modify (web.xml, ajax_config.xml, jsp, javascript, java), you might not think it's so easy.
- Chapter 5 demonstrates the use of Direct Web Remoting (DWR) for developing a POP3 web email client. Most of the language in the chapter is taken up with development and explanation of the Javascript code that makes the application tick.
- Chapter 6 develops an RSS reader using the Ajax tags from Java Web Parts (JWP) and the ROME RSS parser library. Among other things, this example illustrates how to deal with cross browser security restrictions, i.e. how do you grab RSS feeds and content from third party sites.
- Chapter 7 develops an image manipulation and sharing application called PhotoShare using Dojo! and the JWP tags. Dojo is truly huge in its scope and this chapter focuses on just two packages: Events and I/O. This app definitely has the most wow factor of the bunch. There's something about manipulating and sharing images that makes you say, "you can't do that with a webapp."
- Chapter 8 develops the first application in the book to make use of a database. The example program is an organizer and makes use of Prototype, WebWork, Spring and hsqldb.
- Chapter 9 implements a chat application based on Struts and custom Javascript code not based on any library. This might have made a good chapter 2 application, since we get to go a little deeper into the practical workings of Ajax. It also illustrates the technique of "pushing" updates to the browser via periodic polling of the server.
- Chapter 10 is also "naked" Ajax, i.e. no toolkit or framework. It is a rather fun little game in the style of Zork called Ajax Warrior. This is the first time we get to see JSON. The application also kicks the handling of XML, both on the client and server side, up by several notches. This is the most complex application and illustrates some strategies for implementing a complex flow. Ironically, this application is probably the easiest to understand because it makes no used of Ajax/Javascript libraries and could have made for a good Chapter 3.
Throughout the book, DTO, DAO and other classic Java webapp patterns are used and extended to work with Ajax and client-side Javascript. For those who haven't used Spring or some of the other open source Java libraries demonstrated in these applications, there is even some non-Ajax learning involved. Zammetti's writing is clear and to the point and his humor doesn't get in the way of reader understanding.
My main issue with the book -- a lack of depth -- is really more a problem with Ajax itself and the proliferation of frameworks. In truth, despite its depth, the book barely scratches the surface of what's out there now in terms of frameworks. The great pace of development means that since this book was put to bed, probably in the third quarter of 2006, several of the frameworks used in the chapters, such as Dojo and Prototype, have seen one or more releases. Still, this is a problem any Ajax book that references frameworks will have to deal with. Despite these shortcomings, I recommend this book to any Java developer who is looking to "learn by doing" with Ajax.
Topics: Ajax Applications, Books
Moving from Applets to Ajax
Say you're a big company and you've invested heavily in Java Applets as your RIA solution. Java is healthy, developers are plentiful, and life is good, right? Well, no, not exactly. There are still many things to worry about. While Java is still going great guns on the server, it's future in the browser is much less certain. Sun will continue to make sure that Java runs on Vista and it's successors and is as easy to install as possible, but it's clear that Microsoft's unbundling of the JVM started a slow but inevitable decline in Java penetration on the browser. These days, Flash is a better bet if you want a non-Ajax RIA on the browser.
So, if you are said Big company, what are you to do? You have a significant investment in Java and in a code base that works. You do business all over the world and have worked out issues such as internationalization and security. Switching to a technology like Ajax, which seems to splay your business logic into the browser for everyone to see, and has a bewildering set of platform-version-OS combinations for you to support, must be a frightening prospect to a product manager. Also, are you going to have to retrain your developers to work in Javascript and Java? Adding languages and environments adds cognitive stress and makes your development slower and more error prone.
If you can convince yourself that Ajax has all the features and capabilities you need, you are still faced with a choice of Ajax framework. This is a hard choice, and there are no easy answers. It partly depends on your long term IT and business strategy, so making generalizations on which framework is appropriate is a little dangerous, but I'll give it a shot.
- My first reaction would be to stand pat with Applets/Swing and go with a framework such as Wiser, a widget server that will let you write Swing code but deploy to Ajax, Applet or Application. These technologies, however, don't seem to be fully baked and the companies supporting them seem to be small -- not the sort of entities that can pass the big company technology selection process.
- Next I'd consider Echo2, swing-like (though not Swing) and fairly mature. It has some tooling and keeps your business logic on the server side. Your Java developers will feel right at home working with it. There are some drawbacks, however. First, Echo2 needs the whole browser. It is an application framework, not an applet framework and makes assumptions about it's control of the browser. If you've developed applets as a way of plugging in RIA into a more traditional web site, this may be an obstacle you cannot overcome. Second, to develop custom components, you will still need Javascript developers -- better ones than you currently have, though fewer than with a . Third, debugging is a bit of an art as yet. Fourth, backed by a small company, again. Finally, you're moving much of your UI processing to the server, which will increase your server capacity requirement.
- If you can expose your backend logic as XML-based services, Tibco GI may be a nice approach. It's slick, WYSIWYG, but again will require your developers to learn Javascript. Also, exposing your backend as a set of services may be biting off more than you can chew. No one says they have to use your GUI client to interact with your services, and letting customers write their own clients can have unforeseen consequences. Last, Tibco GI is designed for intranets and thus supports only relatively recent versions of IE and Firefox -- not acceptable if you need to work with the general public.
- GWT would allow your developers to write and debug in Java. There's good tooling as well. For the transition from applets to Ajax, I like this one the best. The drawbacks are many, however. First, it's not an officially supported product and is still under active development. The developments are all interesting and inspiring, but you're shooting at a moving target right now. As such, the widgets that are available right now are relatively limited and borrow heavily from traditional Javascript libraries such as Scriptaculous. Still, your Java developers can write new custom components in Java, though they will need a working knowledge of Javascript and the DOM.
If you can afford to wait a bit, I'd suggest putting a little bit of money into exploring GWT and see what develops. Then in six months to a year, you and GWT may both be ready to take the plunge.
Topics: Ajax Applications
About Pathfinder
Recent
- Roles Testing For Security
- Blackbird takes the pain out of JavaScript logging
- Making GWT JSON not Quite so Painful
- IDEA - preconference workshop 06 Oct 08
- HTML5, Ajax history management, and The Ajax Experience 2008 Boston
- A Look Back At Past Posts
- Flash Player on iPhone gossip
- Microsoft to Jump on Board EC2
- TAE Boston 2008: The Unsexy Presentations
- The Ajax Experience 2008: Hope to see you in Beantown
Archives
- October 2008
- September 2008
- August 2008
- July 2008
- June 2008
- May 2008
- April 2008
- March 2008
- February 2008
- January 2008
- December 2007
- November 2007
- October 2007
- September 2007
- August 2007
- July 2007
- June 2007
- May 2007
- April 2007
- March 2007
- February 2007
- January 2007
- December 2006
- November 2006
- October 2006
- September 2006
- August 2006
- July 2006
- June 2006
- May 2006
- April 2006
- March 2006
Topics
.NET
2d physics
3d
3D GPS
3D physics
37signals
Accessibility
actionscript
activerecord
Add new tag
Adium
ADO.NET Entity Framework
Adobe
Adobe AIR
Advertising
agile
Agile Development
AIR
Ajax
Ajax Applications
Ajax Bookmarking
Ajax Components
Ajax Development
Ajax Examples
Ajax Experience
Ajax Frameworks
Ajax history management
Ajax Intervention
Ajax libraries
AJAX Obfuscation
Ajax Performance
Ajax Products
Ajax Tools
Ajax Widgets
Amazon
amf
Analysis
Android
Announcement
Announcements
antennae
Apollo
Application Architecture
Application Development
AS3
ASP.NET
Asynchronous Processing
awards
Back Button
Benchmarking
Best Practices
BitmapData.draw
BJAX
Blaze Advisor
blog
blogging
Books
Browsers
Business
Business Reasons for Ajax
Business Rules
C#
Canvas
Case Studies
chess
Chicago
Cloud Computing
CMS
COBOL
code art
Code Generation
Color
COMET
Conference
Consistency
Content Management
CRM
CruiseControl
CSS
Custom Flex Component
data visualization
Degrafa
Design
Design Patterns
Desktop
Desktop RIA
Developer's Notebook
Diagnose
Dojo
Domain Knowledge
Drools
EC2
Echo2
Echo3
Editorial
ERP
Ethnographic Research
events
externalinterface
Ext JS
Facebook
ferret
FileReference
Firefox
Firefox Extensions
Flash
flash awards
flash player
flash player 10
Flex
flexunit
Flock
Flow
Frameworks
front end
front end development
Games
Gauge Component
getting things done
Git
Google
Google calendar
Google Gears
Grails
Graphics
Greasemonkey
Groovy
GStreamer
GTD
Gwittir
GWT
Healthcare
Hibernate
Hudson
IDE
Ideation
IE
IE6
IE7
IE8
ILOG JRules
Information Architecture
Innovation
Instructional Design
Interaction Design
Interview
iPhone
iTunes
Java
Javascript
JavaScript frameworks
Javascript Libraries
JBoss Rules
Jess
Jetty
JIT
Jobs
jQuery
JSF
JSON
JSR-94
JsUnit
Lazlo
Legacy Systems
lightweight
LinkedIn
LINQ
logging
Logical Model and Conceptual Model
Low Pro
Mac
Mash Note
Mashups
Meebo
MetaWidget
Methodology
Microformats
Microsoft
Mobile
Mootools
mouse scroll
mouse wheel
Mozilla
Music
MVC
MySql
NetNewsWire
Object-Oriented
Object Relation Mapping (ORM)
Office
OOP
Open Screen
Open Source
Opera
Oracle
ORM
osx