Archives

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.

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:

1. 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.
2. The JavaScript framework chaos will continue. The OpenAjax alliance will continue to be ineffectual in promoting things like widget interchangeability.
3. 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.
4. 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.
5. MS Volta will do nothing. It is just a FUD shot across the bow of GWT.
6. Everyone except Craig’s List will have some form of Ajax on their site.
7. 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.
8. GWT’s compiler will produce more efficient code than 98% of JavaScript developers can do by hand.
9. With the new browsers, a cross platform Canvas/SVG will be a reality by the end of the year.
10. 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

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.

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

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

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.

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.

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.

Related Services:
Ajax Rich Internet Applications, Custom Software Development

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.

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….