- We design and build extraordinary applications for companies looking to make the next great idea a reality.
- learn more
Two Years of Agile Ajax: Web Killed Off GUI Techniques Just in Time for Ajax to Need them Again
I launched this blog just a little over two years ago, on March 21st, 2006. Appropriately enough, my first post was about User Experience (UXD) and Ajax. The blog has come a long way since then -- we've added another full-time blogger (Brain Dillard), published nearly 700 articles of original Ajax and Agile related content, and covered the major new innovations in Ajax and Web 2.0 -- but in many ways Ajax technology is still struggling with the same issues that I wrote about back then:
As it stands, Ajax is still in its infancy (or in its wild west phase -- pick your metaphor), and Bill's simple three part "patterns" are emblematic of this.
Topics: Ajax Development, Design Patterns, Desktop RIA, Web 2.0, Web Development
Stop, Reload, Error Loading Page 404: Converting Web 1.0 to 2.0
OK, onwards in our effort to convert Web 1.0 apps to Web 2.0. Today we'll focus on some of the differences between Web 1.0 and 2.0 from the user experience perspective. When we think about our web interface, we usually think about the links, forms and controls we've put in place. But the reality is that often things go wrong with our app -- sometimes network problems, system problems or application errors -- and we get errors like 404 or 503, or a "page did not load." How does the user respond to these issues?
Usually they make use of the Stop, Reload, Back and Forward buttons. Most times application developers see the use of these browser buttons as a problem, to be mitigated ("Please don't submit this form twice..."; "Don't use the back button or your order will be submitted twice..."). If you think about it a little more carefully, you'll find that these buttons form a vital safety net for web applications, without which users would be crying in frustration at the "Unable to connect..." pages and spinning cursors that have brought your app to a halt.
Topics: Ajax Development, Best Practices, Tutorials, Web 2.0, Web Development
Plug: Designing Invisible Interfaces Webinar
My colleagues Matt Nolker and Shalom Sandalow have put together a nice little webinar entitled "This Won’t Hurt a Bit": Designing the Invisible Interface.. For those of us writing Web 2.0 applications, there are some key insights here, such as: "interacting with the software is not the primary goal or responsibility of the user." So when you use those nifty Ajax widgets, think about whether you are placing a usability burden on the user or are using the power of Ajax to make the interface disappear.
Technorati Tags: uxd, webinar, invisible interfaces, usability
Switching Back and Forth
You'd expect that a blog post titled 7 reasons I switched back to PHP after 2 years on Rails would generate some controversy. Derek Sivers wrote just that on O'Reilly's Ruby blog last week, summarizing his experience as follows.
I spent two years trying to make Rails do something it wasn’t meant to do, then realized my old abandoned language (PHP, in my case) would do just fine if approached with my new Rails-gained wisdom.
The post has elicited a metric oodle of comments, many of which are of the form "But don't you know PHP is ugly?" or "Thanks for finally speaking the truth about that overrated Rails stuff", neither of which is really all that helpful.
I confess my first thought on seeing the headline was disappointment, couple with the knowledge that inevitably, I'm going to suggest using Rails for a project and somebody will come back with "But didn't that CDBaby guy switch back to PHP? Doesn't that prove Rails doesn't scale to the enterprise?" Sigh.
I think, though, that there's actually less here than meets the eye. I even think that Sivers' experience is actually a good thing. Even for Rails fans.
By Sivers' account, he wanted to replace the existing, somewhat messy PHP code at CDBaby.com from scratch, in Rails. After two calendar years (which doesn't seem to have been two years of continuous work on the project), they gave up. At that point Sivers went back to PHP and coded the whole thing up in two months.
Admittedly, to a hardcore Rails advocate like myself, the story sounds a little strange, almost like giving up your automobile and discovering you can walk to the grocery store at 200 MPH.
I'd be interested to get a little more detail on what the Rails issues were -- Sivers says things like
Jeremy could not have been more amazing, twisting the deep inner guts of Rails to make it do things it was never intended to do. But at every step, it seemed our needs clashed with Rails’ preferences.
and later,
I love SQL. I dream in queries. I think in tables. I was always fighting against Rails and its migrations hiding my beloved SQL from me.
So I suspect the problem was, on some level, a clash between the existing database structure of CDBaby and Rails' expectations for database structure (and maybe, to a lesser extent, the clash between how Sivers wanted to structure the program, and how Rails did). This actually isn't surprising. Rails has very strong opinions on what databases should look like, it'd be more surprising if an existing project matched those preferences exactly.
What's a little bit more surprising is what Sivers did when he went back to PHP.
It’s the most beautiful PHP I’ve ever written, all wonderfully MVC and DRY, and and I owe it all to Rails.
He took the best parts of Rails, jettisoned the parts that didn't fit his project, and applied the principles to the code that he built. The logic is in the right place, and as a result, the line of code count is an amazing 15% or so of the original. That must have taken a fair amount of discipline to do in PHP, but it clearly worked, so good for him.
I guess I'm supposed to be upset that he walked away from my team, but actually, I'm fine with it. It's easy for me to get caught up in the particular choice of technology, especially now when Rails is in my job title. But ultimately the point is to build solid programs that bring value to the clients and users.
Rails is great, but it just isn't designed to be the One True Framework for all people. It does contain ideas and design principles that are applicable to almost any piece of software. These ideas should be implemented all over the place -- that's how all our tools get better.
I mean, it's hard to see Sivers as writing some kind of slam on Rails, when the post contains the statement:
Rails was an amazing teacher. I loved it’s “do exactly as I say” paint-by-numbers framework that taught me some great guidelines.
Or closes with this:
All that being said, I’m looking forward to using Rails some day when I start a brand new project from scratch, with Rails in mind from the beginning.
Sounds good to me.
Topics: Open Source, Ruby on Rails, Trends, Web Development
An Event Apart Chicago: Day 2
Tuesday saw the conclusion of An Event Apart Chicago 2007, the two-day web-development conference from the folks at A List Apart. Here's my sequel to yesterday's day-one overview. I'll be back Friday with analysis and afterthoughts.
Jeremy Keith, author of "Bulletproof Ajax" and "DOM Scripting," led the day. His topic? "Be Pure. Be Vigilant. Behave," wherein he outlined the concepts behind "Hijax," the application of progressive enhancement to Ajax functionality. A staunch proponent of unobtrusive JavaScript, Keith warned against throwing web standards out the door when developing Ajax functionality. His examples demonstrated how to separate behavior from content and presentation by abandoning such outmoded techniques as the
Next up was Luke Wroblewski, a Yahoo product designer whose resume includes work on the original Mosaic web browser. Wroblewski covered "Best Practices for Form Design" using exhaustive research from his forthcoming book on the subject. In case study after case study, he demonstrated how simple choices in the design and deployment of HTML forms - from the widths and alignment of inputs and labels to the placement and visual differentiation of cancel and submit buttons - can cut the time it takes to complete them in half. Wroblewski's most persuasive argument, however, was conceptual rather than technical. He made a powerful case that because forms are barriers between users and the things they want to do - buy your product, join your site or begin creating content - you should make them as easy to get through as possible. This central thesis added considerable weight to his many practical how-tos.
Accessibility advocate Derek Featherstone closed off the morning with "Accessibility: Lost in Translation." Featherstone looked at how markup choices can make a site transparent to assistive devices - or render it totally opaque. Using real-world examples from Amazon and other sites, he demonstrated how screen-reading software actually parses markup. His live examples proved that the lack of semantic markup and the absence of ostensibly optional HTML attributes can render a site worthless for disabled users. Featherstone then went beyond the basics, explaining how source order - the sequence in which nodes appear in your markup - can be used to enhance accessibility. By placing your central content first, then positioning chrome above it with CSS and providing jump navigation to skip past inessential modules, you can achieve the presentation you want for typical users without shortchanging disabled ones. In another example, Featherstone examined the ways in which meaning can be encoded in the color and position of elements on the page - and how to replicate that meta-data in a way that disabled users can understand. As with many of the other speakers, Featherstone's examples argued persuasively for the continuing relevance of web standards.
After lunch, CSS expert Eric Meyer again took the stage, this time to explore "The State of CSS in an IE7 World." Using the recent release of Microsoft Internet Explorer 7 as a springboard, Meyer illustrated the concepts that have governed the changing of the browser guard for more than a decade. His overall premise was that developers need to use their own server logs to gauge when support for an older browser can safely be dropped for their site. For most of us, IE6 isn't going away anytime soon, so we need to get creative if we want to harness advanced functionality. To that end, Meyer delved deeply into the details of IE7 techniques, filters and hacks. He praised the browser for the strides it makes over IE6's CSS engine in such areas as child selectors, adjacent sibling selectors and attribute selectors. His real-world examples demonstrated how such functionality adds power and elegance to our code. To cope with IE6's continuing market share, Meyer advocated the use of Dean Edwards's IE7 compatibility script, a JavaScript library that adds IE7 capabilities to older versions of the browser. The take-home message was that older browsers may take a long time to die out, but creative programming techniques can harness the future of CSS now.
The final two sessions for AEA Chicago 2007 were a little offbeat, which was a relief after 10 technical sessions in the previous 32 hours. In the highly anecdotal "Selling Design," ALA publisher Jeffrey Zeldman used stories from his own long career to illustrate best practices for handling difficult clients. His thesis was that collaborative work requires us to deal with a wide range of other people, so we should hone our ability to influence our collaborators - and pick good clients to begin with. Agency owner Jim Coudal closed things off wittily with "Dealing With the Both of You," a slide-free presentation about the crossover between personal projects and professional work-for-hire. Coudal assembled a number of satirical short films to drive home his point: Because most web developers are curious and easily bored, we should strive to marry passion with professionalism whether our clients are external or ourselves.
An Interview with ZK Creator Tom Yeh
Anyone who has been following the development of AJAX frameworks has heard of ZK, the server-side component GUI framework that allows you to write applications like you would a desktop app. It has become one of the most popular projects on sourceforge and has been nominated for a 2006 Sourceforge.net Community Choice Award.
Recently I talked with one of ZK's creators, Tom Yeh of Potix, about the Framework's popularity and future.
ZK Background
DK: How did you come up with the idea for ZK, i.e. an AJAX framework that allows you to write webapps like you would a desktop app?
TY: As I mentioned in http://zk1.sourceforge.net/faq.html#Why, it is the result of frustration.
I was a fan of thin-client computing since leading a wonderful team to develop Network Computer and Window Terminal in 1995. I truly believe in the so-called utility computing. Accessing applications should be as simple as using tap water.
It is crazy that someone should carry tons of water when traveling, since tap water is available everywhere. However, we still travel with notebooks, even though Internet connectivity is everywhere. Similarly, the Web edition of MS Outlook has been available for years, but we are still using the desktop version. Why? Frustrated user experiences and excessive development costs. In other words, it is too costly to develop a Web UI from scratch or add-on to 'legacy' apps, and people won't use the Web UI even if it is provided.
After trying different ways to apply Ajax in the projects on which we consulted, we found that applying Ajax at the client side, as most frameworks did, only solved the half of the problem -- though it did result in a lovely interface. That is why ZK was born.
DK: Who is Potix?
TY: Potix is a consulting firm providing expertise in Web development and project management. We also develop applications on an ODM-basis. ZK is the consequence of this work. However, due to strong demand, we mainly focus on ZK now.
Potix is also a house of old dogs. Most of us have more than 15 year of experience, ranging from developing Windows/Linux/Web applications, to embedded OS and GUI frameworks. ZK is my second OSS project; the first one, called OpenPam (GUI for embedded devices), was not very popular.
DK: How are you planning on making money with ZK? Nextapp, the makers of Echo2, sells an Eclipse plugin for around $400. Is that a business model you are examining?
TY: Dual license (as MySQL did). You might also take a look at one of my posts: http://sourceforge.net/forum/message.php?msg_id=3605162
Other Frameworks
DK: Echo2 seems to be the only other server-side AJAX framework out there. How would you compare yourself with Echo2?
TY: Echo2 assumes UI designers are Swing programmers, while ZK assumes many of them are not programmers.
Markup languages, like HTML, XUL and XAML, scripting languages, like PHP and Ruby, and the object oriented approach are the three most important developments since GUI was introduced. Unfortunately, Echo2, WebOnSwing and similar frameworks only focus on the object-oriented approach.
In addition to BeanShell, we are looking at the possibility of using Ruby and PHP in zscript. It looks to be, so far, quite feasible.
DK: There's lots of talk now about the Google Web Toolkit. Do you see it as a competitor to ZK or a complement?
TY: Both.
From a technological viewpoint, it is a complement. GWT is a client-side solution and quite good for developing Ajax components. On the other hand, it is never a good idea to replicate the business logic to the client, which eventually brings us back to the maintenance headache of fat clients. In addition, loading huge JavaScript files into the client and executing them there is not fun at all. At the end, you need a server-side solution to handle the business logic and presentation tier.
It would be great if we can leverage GWT's power to simplify the effort of component development (as we did with DOJO and FCKeditor).
From a perception level, users might see it as a competitor. Google is now at a sweet spot with plenty of resources and a good reputation, as Microsoft was in the 1980s. Developers love to explore any kit Google puts out there and exaggerate what it can do as if Google was the first to invent it.
DK: Do you envision developers writing ZK components using GWT?
TY: Sure, GWT does a good job for non-JavaScript programmers who want to develop Ajax components. I expect that some results of this will show up in next few months.
However, what makes Ajax programming difficult is not JavaScript itself. Rather, it is the incompatible and buggy API (to communicate with DOM). The ability to do Java-to-JavaScript is important, but I am also hoping for some benefits from the standards efforts of OpenAjax.
The true value of ZK is its architecture. We look forward to adapting components to ZK as decent (client-side) Ajax components become available.
DK: What other AJAX tools, frameworks or technologies do you think are noteworthy or interesting?
TY: DOJO has an amazing set of components, though it is too heavy (one of the reason we didn't build the ZK Client Engine upon it). Atlas has great integration with Visual Studio. Anyone who wants to provide an authoring tool should take it as an example. Google Spreadsheets is an excellent Ajax application. You should unplug the network connection and see how it reacts, though. It's cool nonetheless.
Strengths and Weaknesses
DK: What would you say are the strengths and weaknesses of the ZK framework?
TY: Strengths: boundless. But seriously, great richness and excellent productivity, if we can put in a sentence.
Many of ZK users appreciate that they can design a rich Web application without programming. Many have thanked us for the intuitive event model and feature rich components that have saved them countless hours. Many enjoy the power of prototyping so they can change the look and function right in front of their customers. For more information, you could take a look at the executive summary (http://zk1.sourceforge.net/wp/ZK-exesum.pdf).
Weaknesses:
- Stops working if the connection is broken. It would be better if a subset of functions still worked (such as read only viewing).
- Round-trip latency, though hardly observable. To minimize the effect of this, we plan to, in addition to Client Side Action, add visual effects that execute solely at the client and notify the server only when necessary.
One other weakness shared by all HTTP-based solutions is the lack of Server-side push. Though someone has implemented so-called "reverse Ajax", it introduces too much overhead on the server. This -- server-side push -- is the next important step beyond Ajax.
DK: There aren't any production applications out there using ZK. Do you see that as a problem and, if so, what are you doing to address it?
TY: According to the profile of our customers, adopting ZK is still in the development (and evaluation) phase. By and large, adopting Ajax for most companies is still in an early stage. It is just a matter of time. I'm not really that concerned about it as long as the growth of ZK's acceptance is strong.
DK: Right now, the framework doesn't seem to allow for easy customization of the look and feel (window color, font, etc.). First, is that correct and, if so, do you have any plans to address it?
TY: Not correct. The look and feel are well separated by CSS and molds. What prevents users from customizing the look is the lack of documentation and samples. Also, the customization of the sophisticated components is sometimes not intuitive. It forces users to look at DSP files (the templates used to generate HTML tags). We realize this is an issue and we will provide documentation in the Developer Reference guide.
DK: I've noticed in the code that you spawn another thread to handle events. Can you explain the design to me? Also, how does this fit in with the Servlet standard and doesn't this make it difficult to cluster a ZK application if the user session has non-serializable information and context?
TY: It is common that an application has to confirm with users about, say, whether to delete a file. It is unbelievably costly for Web developers to implement such functions. Why? Users get no response until the servlet has completed, while the servlet requires user's confirmation to decide whether to proceed further.
There are many solutions to this problem, but the most elegant one is modal dialogs. ZK is one of the first Web framework that really enables the server-side modal dialog. The magic is to process events in another thread. Then, users can suspend and resume the processing anytime they like -- including but not limited to modal dialogs.
It does make clustering difficult if there is a pending thread in a session. We are working on the serialization issue now. A basic idea is to send the application a notification, and it can decide how to handle pending threads. Of course, if there is no pending thread, there is no notification at all.
DK: What is your favorite ZK feature?
TY: Macro components, the threading models, and zscript.
DK: Are there some cases where you wouldn't use ZK to develop an AJAX-based web application?
TY: Hard to imagine unless clients want the application to be functional even if the connection is off. Oh, action games, but it might not be a good idea to use Ajax there at all.
DK: It doesn't appear that you are using JUnit in the ZK code. Is this true? And if so, why?
TY: Only common utilities are tested with JUnit (refer to pxcommonTest in SVN). I am still thinking about which is the best way to test ZK components. We will come out with something in the near future.
Future Plans
DK: What is the biggest feature enhancement request you are getting from the users of ZK?
TY: Safari support and design patterns. By design patterns I mean information on how to really write an application with ZK. An illustration with Pet Store is a common request.
DK: On your road map you mention plans to provide a mobile version of ZK. First, what is the time frame for this? Second, how are you planning to do this architecturally? Can users write one application and dynamically re-target their apps to a different front end?
TY: We originally planned to provide a J2ME-based client engine, but we are keen on developing a Flash-based solution now. Architecturally, we have to do three things to support a new client: client engine, server engine and components. Users have to do two things accordingly: use a different set of components and adjust their UI to fit into small screen. We will keep the component API very similar (and also provide common interfaces that make developer's code polymorphic).
It is possible to let users use the same set of components, where components would be smart enough to detect the client and behave differently. However, we're not considering this approach because it makes the development and maintenance of components too complicated. Of course, we can use the factory pattern to chose the correct implementation, but it makes the instantiation of a component too complex for most users.
DK: You've stated that ZK is at the interface layer. Do you plan to introduce components that punch through to the data layer, sort of like the .NET datagrid?
TY: Yes. We will add more data-layer utilities, such as zkplus's DelegatingVariableResolver, too. After all, most ZK applications will have to access a database. However, we may not do a similar deep integration as Ruby on Rails did -- I don't like to make so many assumptions about how applications might be built.
DK: What do you see as the major challenges facing the AJAX community today?
TY: There are too many frameworks, such that many users prefer to wait. There isn't even a well-recognized categorization for them (such as server vs. client). A comparison chart or something similar would be very useful.
A standard like OpenAjax will help (at the client side), but I've never seen an alliance really work.
DK: Care to share any other plans you have for ZK?
TY: We are interested in adding mega-components, such as spreadsheet, forum and wiki. Part of the success of PHP is because the availability of plenty of off-of-shelf stuff. We won't develop all of these components ourselves. Rather, we prefer to help other developers deliver them either as OSS or commercial components. We will have a ZK.forge website to promote such collaborations.
Topics: Ajax Components, Ajax Frameworks, Ajax Products, Ajax Tools, Ajax Widgets, Design Patterns, Echo2, Flash, GWT, Web 2.0, Web Development, Web/Tech, ZK
ZK - Documentation & Tools
Documentation
The quality of the ZK documentation is very high by Open Source standards. The documentation includes:
- A 13 page PDF Quickstart guide - shows how to set up the demo application and a hello world app.
- A 169 page PDF Developer's Guide - steps you through the ZK framework with lots of small examples illustrating components and concepts.
- A 43 page PDF Developer's Reference. Documents component properties and behaviors. This document is only about 40% complete.
- A 1 page PDF Executive Overview.
- A 16 page PDF Product Overview - gives information on the motivations behind ZK and the architecture of the product.
The reference guide will need to be completed, otherwise developers will be guessing at specifics of components and the ZUML. Also, the documentation on CSS and "molds," i.e. the templates for components, is spotty. This will make it difficult for developers to change the look and feel in any significant way.
Tutorials
While there is a ZK demo application that shows off various components, there appear to be no tutorials or example/reference applications available to the would-be ZK developer. There is a wiki with a how-to/cookbook page, but just like the developer's guide, it consists of short examples, not a substantial application. There is also a port of a struts application over to ZK, but it seems to make use of so little of the AJAX capability of the framework that it can't really be considered a tutorial or reference app. For now the forums are probably the best source of information and support. Also, there is a "small talks" section of the project site that has some bits of information on integrating ZK with things like the Spring Framework.
Usability
Overall the framework is a joy to use. The ZUML makes it easy to do quick iterations -- edit, test, edit, etc. -- without a long compilation step. The ZUML is also easy enough so that non-programmers can compose or modify a UI. Exposing effects such as drag-and-drop, async update, etc., as components or attributes further eases the development of complex user interfaces for non-programmers and programmers alike.
Tools
As of this writing there is no IDE integration for ZK. This is really a crying shame, since the ZUML makes a WYSIWYG UI layout tool a natural fit.
CMS and AJAX
Back in April, CMS Watch published an article entitled Ajax and Your CMS. The article looks at the impact of AJAX on CMS systems from both the content author's and the site visitors perspective. From the author's perspective, the news is all good and pretty conventional as far as AJAX articles go: fewer click, drag-and-drop, faster, more powerful UI. There are a few noteworthy points to the article, however. For one, content management with AJAX enabled, single-page sites puts a premium on managing assets:
If you are going to use a heavily-Ajax-driven interface on your websites, then it is worth considering a CMS to manage intra-page snippets and interaction as discrete elements. In practice it could be difficult to manage a rich, interactive site that uses single page interfaces without a CMS, since at this point you are managing content components rather than entire "pages." The whole notion of "pages" tends to dissipate, which would call for a more component-oriented -- rather than page-oriented -- CMS for those looking to manage Ajax-driven websites.
So, if you're publishing content rather than constructing an application, then composing a bunch of widgets together using a CMS sounds plausible. However,
Web CMS tools are notoriously poor at managing stylesheet elements and client-side scripting in particular. The rise of Ajax should prompt some improvements here.
Improve or die, I guess.
The few bad patches for the content author are things that people are already working on: back button, refresh/reload an state, etc. Previewing content from a single page interface is a problem not just restricted to CMS's. You can identify the "states" within the single page interface and preview those, i.e. "show me the state after a restaurant has been picked."
That's It?
The fact that CMS Watch really struggled to find much more to say about AJAX than "will make it easier to use, may make content harder to manage," I think points out that nobody really has a clue about how to effectively use AJAX for content sites. All of the major AJAX enabled sites these days seem to be collaborative filtering excercises like digg and dzone. There must be better ways than this to apply this nifty technology.
I think we can come up with a few ideas. What are some of the content display issues we can tackle with AJAX? Let me give three off the top of my head:
- Screen real estate - we can summarize an article and expand the full test into a new reading context when the user navigates to it. I have a primitive little example here. Just click on one of the text boxes to read the full article in place.
- Breadcrumbs on steroids - this is more about providing a better reading metaphor. We can make the sections of the paper fold and unfold, allow the reader to rapidly navigate through tabs or trees. No more slow postback means we can try more stuff.
- Contextual control - the WSJ already has the capability to right click on a selected word and perform a search. But contextual search, navigation, and other operations are the next step. Imagine an online newspaper where a reader can right click in an article about their neighborhood and get restaurant review listings for nearby establishments. You no longer have to cram every single relevant thing into the sidebars!
The day is still young on CMS and AJAX. Think outside the box and share your own thoughts on what AJAX can do for CMS.
Steps to AJAX Mastery
No, I wouldn't call myself an AJAX master, but, in the words of Laurence Peter, "A man doesn't know what he knows until he knows what he doesn't know." I definitely know what I don't know. And I do know a little (I've been around long enough to have written LiveScript, so I'm old in Internet years if nothing else), so I thought I'd share with you all the Javascript, CSS, XHTML and XSL reading I've done (and haven't done). Maybe you can share your own favorites in the comments.
Yes I've been a big proponent of Component GUI's and writing just Java in developing AJAX applications. Stay in one language and don't mess with CSS, Javascript or XHTML. Reuse the components that others have already written. That way lies productivity. There's only one problem with this approach: who is going to write the widgets and the framework in the first place? Someone has to write Javascript and CSS and XHTML, otherwise nothing will get done. As Billy Preston sang, "nothing from nothing leaves nothing."
So if someone has to write all those widgets, why not you? You know a little Javascript and have written a XPath expression or two. And your girlfriend really liked the CSS you put together for her homepage. So what's stopping you? Well, the truth is that having a passing familiarity with Javascript and the other technologies that make up AJAX is just not enough. Not even close. Your knowledge of Java may actually hurt you in this regard. You have to know this stuff cold to make it sing and dance.
My approach to learning any programming discipline has been as follows:
- Read books, the right ones.
- Read code, lots of it.
- Write code, lots of it.
The Right Books
Where to start? Picking up a tome like Ajax in Action 
seems like a good place to start, but it's really just a crash course in those fundamental technologies you'll need, sort of like skipping over Calculus to take Algebraic Topology as a freshman, or, for those non-math geeks, trying to get a job in Paris after only one lesson in French. You need a better grounding.
In my opinion, the right place to start is by understanding the browser. That's because Javascript has two parts to it: Core and Client-Side. Client-Side is all of the browser specific stuff, so if you try to learn Javascript without understanding the browser, it's just jibberish. Get to know all you can about CSS and XHTML and XSL before you tackle Javascript and you'll save yourself a lot of pain.
I recommend starting with XHTML first, then move on to CSS. (The problem with some of the better books, as you'll find, is that they're a bit long in the tooth, i.e. they have publication dates from as far back as 2001.)
None of the books that I learned on for HTML/XHTML are still relevant. The fifth edition of the O'Reilly book HTML & XHTML: The Definitive Guide is so out of date and focused on old browser quirks that it's a sheer waste of time. My instinct is to stay away from something like the CSS and XHTML combo Head First book. At 658 pages, you'll be well into next year by the time you've read it all. As you'll find out, you've got plenty of reading to do. Plus the whole Head First series is annoying to read. Still, I'm not sure I have any better suggestions. Until AJAX came along, browser technology was considered uninteresting, so nobody published in that category.
For CSS I'd recommend two books: Cascading Style Sheets: The Definitive Guide and CSS Mastery: Advanced Web Standards Solutions. The second is a more advanced text, so read it after working through the first. You may also want to supplement your reading with CSS examples from the CSS Zen Garden. Also check out Open Source Web Design for some 1600+ examples. Finally, Position is Everything is likely to have more recent updates on browser quirks than any book you are likely to buy.
For XML/XSL, I'd recommend an old text (originally a Wrox book, now put out by APress): Beginning XSLT. Get the first one, not the 2.0 book. The examples in this book are not for the browser, so you'll also need some more info on how to do it in Javascript. For this, look to Professional JavaScript for Web Developers. Chapter 15 is probably the best intro to the topic in print.
Finally we've arrived at Javascript, for which I have two recommendations. The latest edition of the JavaScript Bible by Danny Goodman is still the definitive work. The other book is 
the ancient JavaScript: The Definitive Guide by David Flanagan. The latest edition is from 2001, but it really is the only book that deals with Javascript the language.
Only now that you've swallowed these tomes whole are you ready to move on to the Ajax in Action book. All those bits of jargon that were confusing before are now old hat. This book will fill in some of the missing pieces around XHR that those other Javascript books left out.
Now I've left out lots of other books that are useful and should probably be required reading. You should probably bone up on OOAD, an Operating System or two, a server-side development language, networking, etc.. My intent here was to give you a minimal set of books, not an exhaustive one. Even the books that I have recommended could be considered to be exhausting if not exhaustive. Anyone keeping score will have noticed that these books clock in at over 5700 pages. That's a lot of reading. That huge page volume, however, is simply a reflection of the fact that you are learning four different languages and combining them all together. Maybe you don't have to read all of those page, but even half that number is a commitment to many nights at home. I wish I could recommend small 100 page books on each subject that are more than simple "Hello World!" pamphlets. If anyone is aware of any, please let me know.
Reading Code
Books will only tell you so much. To really get a feel for how things are done -- best practices, so to speak -- you have to read code. Preferably good code. Avoid generated code like that produced from Tibco GI or GWT. Stick to hand-coded Open Source stuff like Prototype, Scriptaculous, Dojo and the like. At this point you'll probably know enough to decide for yourself what to read. There's a good book on how to read code, but I'll spare you another tome.
Make sure to get some tools so you can read and debug the code. I personally like the Firebug for spelunking around the DOM and Javascript, but there's a whole list of other tools available over at ajaxpatterns.org.
Writing Code
Now, five years later, you are ready to start writing some code. Use what you've learned. Good luck.
Stomping out the Misconceptions
A reader pointed out this blog entry from Infoworld, Mercury: AJAX has its drawbacks. It's from the middle of April, but it is still worth responding.
"AJAX is incredible where people are starting
to adopt it and it immediately causes a lot of problems because it's
not very structured," said Rajesh Radhakrishnan, vice president of
Application Delivery at Mercury. Several Mercury executives met with
InfoWorld editors at Mercury offices in Mountain View, Calif. on
Tuesday morning."We've seen tons and tons of problems," with AJAX, Radhakrishnan
said. In testing for functionality and regression, Mercury has seen an
increased number of regressions in AJAX, said Radhakrishnan.As a workaround, Radhakrishnan suggests using AJAX for the cutting
edge part of UI development, to enable interactions between the client
and server in which the server is able to respond to client requests
later. "For the rest of it, you don't really use AJAX,""Radhakrishnan
said.
It is precisely using AJAX for the "cutting edge" parts of a UI that causes the problems. Calling an architectural principle like AJAX "not very structured" betrays an ignorance of the topic. It's like calling web service "not very structured" because people are using raw java.net sockets to do everything. This post is from April of 2006, not 2005 when this sort of comment would have been excusable. Now there are several stable intermediate forms such as DWR that allow for fairly structured development of AJAX solutions on top of existing webapp frameworks. Further, there are already some more advanced forms such as Tibco GI, OpenLaszlo, ZK and Echo2 that allow for development of sophisticated desktop-type apps. Mercury may be trying to discourage folks from developing AJAX apps until they've had a chance to update their testing software to keep pace. I suggest that they work harder on their next release instead.
Struts and the Tension Headache
I'm spoiled. This past week I had to go back and revisit a Struts application I developed back in the early days, before Hibernate, before EJB's. I found myself developing an anger headache as I bounced between the struts-config.xml, the web.xml, the jsp's, the home-brew ORM layer, and the various validators, actions and pieces of business logic. Even using an IDE and with well documented code, it was a real pain to make just a handful of modifications. Each time I made a change, it seemed that I had to modify three or four files to make it work. A little XML, a little JSP, a little Java, a little SQL. Oiy!
Why did this stuff make me so angry? Hadn't I designed my code in layers to avoid all this mess? Well, it was actually pretty painless for a struts application. The problem is that struts, and most frameworks, expose too much of the plumbing and force developers to repeat themselves in several places and in different languages and formats.
Why didn't I just accept that this was the way things were? Because I'd spent the last 7 days working on an AJAX newspaper interface using Echo2, and I hadn't spent one second writing HTML, Javascript, XML plumbing or SQL. Just Java. And now here I was back in the bad old world of the web worrying about sessions and postbacks, repeating myself over and over again in different languages.
Yes, things today aren't as bad as in the early days of struts. Hibernate and Spring have made things easy on the ORM front, so I write little or no SQL. Web application frameworks like Webwork and JSF are moving toward components and a higher level of abstraction. But the problem I have with their MVC is that all three really should be realized in Java, not a mix of different languages. That's the only way to stay DRY (Don't Repeat Yourself).
So, why isn't everyone embracing this new, pure Java (or C#, or Ruby, pick your poison) way of writing apps?
Paradigm Shift
People tend to overuse the term "Paradigm Shift", which was coined by Thomas Kuhn back in 1962 in his book The Structure of Scientific Revolutions. What does it mean, Paradigm Shift? It happens when a scientific theory can no longer explain the facts, i.e. when enough anomalies have cropped up to invalidate it. When this occurs, it isn't just the theory that is discarded but the whole worldview from which is comes. From the Wikipedia:
When enough significant anomalies have accrued against a current paradigm, the scientific discipline is thrown into a state of crisis, according to Kuhn. During this crisis, new ideas, perhaps ones previously discarded, are tried. Eventually a new
paradigm is formed, which gains its own new followers, and an
intellectual "battle" takes place between the followers of the new
paradigm and the hold-outs of the old paradigm.
Yes, we're not fighting about Ptolemaic versus Copernican cosmology and if the latter meant that man was no longer the center of all creation. In our case the paradigm is not how which questions we ask and what experiments we do, but rather how we build web applications now that AJAX has come along. The worldview is not whether the planets revolve around the Earth or the Sun, but what exactly web applications can do. The battle is between those who want to build web applications with the old methods -- sort of a souped-up struts with AJAX -- or with the component GUI approach.
I for one am on the side of the component GUI's. I can't stand the tension headaches.
X Windows and Ajax: Two Kinds of Display Servers
X11 is a client/server display system that realizes user interfaces by sending asynchronous messages back and forth between a display server -- that manages a display, mouse and keyboard -- and clients such as xterms, Firefox, GIMP, etc. Some of the drawing, windowing, events and other operations that the X protocol supports look suspiciously like some of the things flying around in Ajax these days.
Now there are some substantial differences between X and Ajax. For one, X clients (the equivalent of the http server) open up persistent connections to the X server (the equivalent to the browser), while the 'Ajax server", aka the browser, has to poll the "Ajax clients" (the apps on the http server) for messages. X is typically used in a LAN rather than a WAN setting, for this reason. Persistent connections usually don't hold up very well in a WAN context. Also, there's no embedded scripting language like Javascript in X.
One definite similarity is that both X and Ajax don't have any widget standards. In X you've got several different widget sets -- Motif, Qt, Gtk, etc. -- while in Ajax you've got a few early frameworks with their own widgets.
So, what's to be learned from all of this? First, while user interfaces may well head in the component GUI/widget directions, we'll likely have quite a number of different widget sets in the long run. Second, there are a few design lessons to be learned from X Windows. For example, the creation of windows with a specific look and feel is controlled by a window manager abstract factory.
Some of these design solutions may not be appropriate for Ajax, but I think it's worth mining this trove of design solutions. Might we some day have an Ajax desktop that unifies multiple independent Ajax applications?
Update 1: Bill Scott makes a similar point (though much earlier -- more coffee, I'm sure).
Webtop - I Already Hate It
A reader emailed me this old article from CNN Money discussing the concept of the webtop, i.e. that
A killer app no longer requires hundreds of drones slaving away on
millions of lines of code. Three or four engineers and a steady supply
of Red Bull is all it takes to rapidly turn a midnight brainstorm into
a website so hot it melts the servers.What has changed is the way today's Web-based apps can run almost as
seamlessly as programs used on the desktop, with embedded audio, video,
and drag-and-drop ease of use. Behind this Web-desktop fusion are
technologies like Ajax (asynchronous JavaScript and XML), Macromedia's
Flash, and Ruby on Rails. We'll spare you the technical details;
suffice it to say that these technologies are giving rise to a new
webtop that may one day replace your suite of desktop applications.
I already hate the term "webtop," though I've used it myself in the past. The article goes on to discuss the various webapps that are starting to move into areas once reserved for desktop applications, then lists of a few noteworthy apps, such as 37signals campfire chat client.
The conclusion? We'll all be doing our word processing over the web from now on.
Now I like a little bit of breathless hype as much as the next guy, but this is over the top. Yes, webapps are going to change, but there are certain limitations to the medium that will make the webtop a much tamer place:
- Reliability and performance - why aren't most desktop apps in corporate environments served up as client/server apps? The technology is there; the kinks of client/server have mostly been worked out. License sharing could save tons of money. The benefits of reliable, centralized storage and ease of collaboration seem pretty obvious. Yet the most we see is networked storage of documents. The reason? Even on a corporate network, performance and reliability are not high enough to make client/server computing for desktop apps attractive.
- It's more than just CRUD on speed - even after the widespread introduction of the WIMP (Windows, Icons, Menus, Pointing device) environments in the 80's, it took a while for programs to mature beyond GUI versions of Lotus 1-2-3. We didn't see precursors to Photoshop until a few years after the introduction of the Mac. Most webapps today are still glorified CRUD (Create, Read, Update, Delete) engines. Writing the more substantial applications will take a good bit of work, not just a few cans of Red Bull (or Jolt!, sniff).
- Writely ain't Word - more like Wordpad. If Writely was out as a desktop app, it wouldn't get a second look. Yes, there is a need for a Word-compatible, easier, less bloated, free word processor, but they never seem to make it. Yes, a web based word processor that saves your work more frequently than an occasional submit is kinda cool. But the truly cool part is the collaboration feature of Writely, and honestly, there are other, better solutions for that.
- Can I Use it Offline? - You're not going to be online all the time. The moment you have desktop versions that can function independent of the server, is it still Ajax or a Javascript/Browser app with save capability?
This hype around Ajax is really starting to remind me of the first dotcom boom (See FauxJAX for a good sendup of this). I had a few venture capitalists back then asking me to look at business plans that added "the web" to their business models. My rule for evaluating these was always the same: what does the web add? Most times it didn't change anything; it was just another marketing channel. For others, like online classifieds, it removed distribution costs. For the social networking type businesses, it made it easier and less costly to jumpstart the network effect.
So, for those going gaga over Ajax, ask yourself, what does Ajax add? If you can't come up with a good answer, odds are it doesn't add a thing.
Upcoming Talk - Back to the Future: Component GUI’s and Ajax
I'll be giving a talk at the Chi2 monthly meeting on Wednesday, April 26, 2006. The highlights are:
- Why web applications are they way they are and how things are changing
- First attempts: frameworks and toolkits that extend current practice
- How Ajax has turned the browser into a desktop
- Component-based GUI's and how they cut down on Ajax Development time
- Which frameworks get it right
For more information see here. If there is a podcast, we'll try to make that available along with the presentation.
Asynchronous Processing in Ajax Apps
Most web applications are still request driven, i.e. the browser makes a request and backend state is updated as a response to that request. There is some backend processing, but usually that processing is very losely coupled with the webapp, updating a backend data store.
Many more advanced apps make use of web services, MDB's, JMS, and other approaches to perform asynchronous processing. The need for asynchronous processing in webapps has been mostly confined to some special cases, requiring extreme scalability or performance. But now with the advent of Ajax, many new webapps are going to have to perform ongoing background processing in order to update front end displays. Some of these processes are going to exceed the time you want an XHR to be open. Or maybe you want to perform some backend processing tightly coupled to the session and UI, rather than loosely tied to the persistent store.
I've used open source tools like Mule, ActiveMQ and the like for some of these things. It does make life a bit easier when doing async processing, but moving to these new technologies will involve a bit of a learning curve for most webapp developers. Sorry, guys, the pain isn't over.
About Pathfinder
Recent
- 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
- TankEngine: New plugin for Rails iPhone Development
- Symphony of Ruby on Rails and Flex through RubyAMF
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