Agile Ajax

Ajax on Way Out? Slide Down Hype Curve Exaggerated

Aidan Henry over at MappingTheWeb asks whether Ajax is on the way out. Aside from observing that the "frenzy ways of web 2.0 are over," he opines that:

My quarrel lies in the fact that many web designers and developers choose to overuse this technology to the point of stupidity. It is meant to simplify the experience, not complicate it. Using AJAX for the sake of using AJAX isn’t valid reasoning. Some sites incorporate it in an elegant, intuitive way, while others saturate the experience with an absurd amount of on-page activity. A threshold needs to be established based on user intentions.

Yes, the froth may be off the Web 2.0 bubble because of the economy (venture-backed firms take their value from IPO's and acquisitions, which slow tremendously in a recession), but Web 2.0 entrants into the marketplace are here to stay, and O'Reilly's Web 2.0 principles have been vetted by the marketplace.

Agile Business, Microsoft and the Threat of Cloud Computing

Competition is the keen cutting edge of business, always shaving away at costs.

-- Henry Ford

I've been working with Java and Microsoft technologies -- .NET most recently -- in one form or another for quite some time. My company, now headquartered in Chicago with an office in NYC, was actually founded in Seattle by a group of four developers that had met around developing an Exchange-based bulk email system to replace the sendmail-based ones that Microsoft was using at the time. In that span, despite all of the food fights about total cost of ownership (TCO), etc., I haven't seen any evidence that Linux, Windows, Mac, Java, .NET, etc., puts you at a significant business advantage one way or the other. Until now.

Another Brain Fart on Why Open Source is Bad

Every so often, someone scrawls a manifesto about why closed source is good and open source is bad. Usually the parties involved are technical ignoramuses (like in this Economist article) or industry hatchet men. But Jaron Lanier should know better. He isn't a hatchet man and is far from a technical ignoramus, yet he engages in the same sort of sloppy thinking that characterizes those other brain-stain graffiti artists.

His article for Discover Magazine, entitled Long Live Closed-Source Software!, is a case study in bad examples in the service of a simple argument. His argument goes as follows:

1. Open Source == Linux
2. Linux is a derivative if qualitatively better version of the closed-source UNIX.
3. Therefore the open source movement can only produce derivative works, and nothing as breathtakingly revolutionary as the iPhone.

He goes on to speculate about some of the causes for this failing, likening closed source to cell walls that help organisms differentiate and speciate. Open source, by contrast, is like the primordial goo.

 

Ajax and Browsers: Recapitulating the Early Days of Personal Computers

I guess its my turn to spin out historical analogies. Does anyone remember GEOS? That's right, a GUI OS for the Commodore 64. In those early days, everyone rolled their own GUI  (character mode windowing...yum). Some were good, some were bad, some were downright ugly. GEOS was an attempt to bring the unifying influence of an OS that provided the basics of a GUI to the C64, something that Windows brought to the PC and the Mac OS brought from the beginning to the Macintosh. GEOS and the C64 faded away, but the days of the custom crafted GUI were numbered. All that stuff is and should be baked into the OS.

We're in a very similar situation when it comes to the browser and Ajax/Widget libraries and frameworks. Everyone is rolling their own widgets, developing their own DOM and Ajax utility libraries and frameworks. I think the next step should be obvious. Bake an Ajax library into the browser. Can you imagine having Ext already present and available in your JavaScript runtime? Imagine the boon this would be to standardization, code reuse, etc.?

 

Humor: Bubble Video

An amusing little video on the Web 2.0 bubble.



Technorati Tags: ajax, video, humor, web 2.0

Eating Some Crow on ThinWire

OK, so I was wrong in ThinWire. The issues around having to position and size components is obviated through the existence of two layout managers -- SplitLayout and TableLayout. These layout managers calculate size and positioning for you (and override any values you may have explicitly set). They certainly make developing in ThinWire much less tedious than I previously thought. For an excerpt of the ThinWire handbook that discusses the two layout managers, see here.

For more sophisticated or fine grained layouts, you'll likely want to develop your own layout managers. I'll officially remove ThinWire from my list of 2007 Ajax Turkeys.

Technorati Tags: ajax, thinwire

Ajax Turkeys for 2007

Every American school child has heard vague rumors that Ben Franklin once suggested that the Turkey would make a better national symbol than the Bald Eagle. What they haven't heard, of course, is that the Turkey is "though a little vain and silly, a Bird of Courage," compared to the Bald Eagle which was "a Bird of bad moral Character." I wouldn't put too much stock in old Ben's suggestions, though. After all, he once proposed that the Rattlesnake was the most appropriate symbol of America's temper and conduct.

So in the end it is still appropriate to use the Turkey as a symbol of failure or incompetence. So, without further ado, my Ajax Turkeys for 2007:

• GMail 2.0 - this puppy should be put back in the shed. It fries browsers from coast to coast. If there was ever and argument against the bloated Ajax beast, this is it.
• ECMAScript 4 - the bastard child of JavaScript, Java and Ruby, this beast tries to please everyone and instead falls between the chairs. If you want the advantages of both dynamically and statically-typed programming languages, make sure the browser can run more than one language (VM and compilers, anyone?).
• Thinwire - any framework that makes you specify position and calculate height and width of every widget is a productivity killer. Update: I was wrong on ThinWire. The Layout Managers simplify this. Mea culpa, mea maxima culpa.
• The Book of JavaScript, Second Edition - I didn't have the heart to review this one when it came out. Thau was "the man" back in the 90's when it came to JavaScript. If you wanted to validate a form or set a radio button, Thau's tutorial's were your first stop when it came to learning the ropes. Well, it's 2007, and if you want to learn how to validate a form or set a radio button, you've come to the right place. As far as OO JavaScript, DHTML and XHR? Sorry. The state of the art has passed him by.
• GWT wrappers for Rialto - if you and your widgets are going to jump on a bandwagon, make sure you get it right. These widget wrappers didn't subclass Widget. Please fix.
• Vista - nuff said. (OK, IE7 and Vista.)
• Framework fanatics - don't get me wrong, I love the frameworks, but the JQuery and Mootools fans can really get on your nerves. They remind me of Ron Paul supporters (also known as "Paulbots") -- someone mentions Ron Paul and immediately the post gets 500 "Ron Paul is great" comments.

Well, that wasn't so bad. I'm sure everyone has their favorites or may in fact disagree with some of my gobblers. Who made your Turkey list?

Technorati Tags: ajax, editorial

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.

The Importance of Pair Programming

It turns out I've been following agile principles for longer than I realized. Back in the early 90's, I was living in a grad student coop at the University of Chicago. The house manager -- a 50-year-old physics Ph.D. who handled all of the plumbing, electrical and other assorted house maintenance -- had decided to leave. In a house populated with humanists and social scientists, all eyes turned to me, the lone "scientist." I didn't bother telling them that computer "science" isn't really a science, and to top it all off, I was studying mathematical comp. sci., which meant I was a fair hand at Combinatorics, but I couldn't tell the business end of a soldering iron from a ground wire. Still, I had helped my dad install some drywall back when I was in junior high (mostly I held the drywall in place, while my dad did all the work), so I agreed to be the new house manager.

I set two conditions, however. First, I was not going to live in the house until I was 50, and second, we would have two house managers, whose terms would overlap by 6 months. An early form of pairing. As a result, I and my pair house manager did not feel as overwhelmed as we might have if each of us had been on our own. Further, we shared information, documented it and now, over 15 years after I introduced pair house managing, the coop still uses the practice to good effect.

I know I have mentioned my 4 commandments of Agile development: iterative development; pair programming; test driven development; continuous improvement. It is hard to point to a "most important" one of the commandments -- as far as I'm concerned this is really the bare minimum of what is necessary to practice good agile development -- but pair programming seems to be the one that is most often left on the cutting room floor. The excuses are endless: "we don't have enough people," "we have an odd number of developers," "we have too many tasks to pair." The list goes on and on. For anyone that has practiced pair programming, the only objection that holds water is the "odd number" one. It is hard to pair with 3 developers, and rotating pairs or three-somes don't work so well -- someone is always the odd man out. ;-)

So what does pair programming give you and why and how does it work? In their hilarious article All I really need to know about pair programming I learned in kindergarten (May 2000, Communications of the ACM, Volume 43 Issue 5), Laurie Williams and Robert Kessler describe some of the reasons for its success. First, in a survey of developers they found that overwhelming majorities of developers were more confident of their solutions and enjoyed their jobs more. Happier programmers produced better solutions, no surprise there. But the fact that stereotypically introverted developers would enjoy a more social, collaborative work environment seems counterintuitive.

According to the article, another key benefit of pair programming is the constant code review that it provides. As it turns out, developers working in pairs think of twice as many solutions and work more than twice as fast as two developers on their own. Anyone who has seen the parabola of bug fix expense in action, i.e. bugs are much more expensive to fix the further you get toward deployment, will appreciate how valuable this constant code review is.

The article goes on to describe some best practices for pair programming, couched in kindergarten term -- "share everything," "clean up your mess," "play fair," "don't hit people." One principle that I adhere to, and that the article mentions, is that it is permissible to work alone for up to 50% of the time -- "nap time." I'm not really an advocate of the "one monitor, keyboard and mouse approach," but rather prefer the shared desk model. That way you can collaborate, but are not exhausted by the constant engagement that the shared terminal forces on you.

One additional benefits of pair programming that I've observed is that developers reach their potential more quickly, i.e. they move from junior to senior to architects or leads more quickly. They learn from others (got to keep switching the pairs from iteration to iteration), they get to make decisions on design and architecture instead of taking dictation from a tech lead, and they feel empowered. No wonder they progress and learn more quickly than developers working along.

Back in the mid to late 90's when I first tried to introduce agile methods on Wall Street, pair programming was the practice that garnered the most pushback. I usually convinced skeptical managers by convincing them that developers would spend less time surfing the web. They nodded knowingly and agreed to give it a try. I got my way, but for the wrong reasons -- managers didn't trust their developers. That points out another agile principle that fits hand in glove with pair programming: trust your people. Or, as the Agile Manifesto puts it

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

These days, I have a much easier time of selling pair programming to clients, which is all to the good.

Technorati Tags: agile, pair programming

Joel Spolsky and the Perils of Reasoning by Historical Analogy

Reasoning by historical analogy can be dangerous, especially if such reasoning is untempered by recognition that no two historical events are identical and that the future is more than a linear extension of the past.  The instructiveness of historical events tends to diminish the greater their distance in time and space from the day and place they occurred.

-- PERILS OF REASONING BY HISTORICAL ANALOGY: MUNICH, VIETNAM, AND AMERICAN USE OF FORCE SINCE 1945 by Jeffrey Record

It may seem a little hyperbolic to quote from a paper published by the Air War College in advance of a critique of Joel Spolsky's latest strategy letter, but lessons about historical reasoning can apply just as well when the question is the future of software as it does when the question is war and peace. So, how exactly did Joel screw up in his analysis of the future of Ajax? Well, first to what he got right:

• He got the bit about the Forms-based interfacre (Green Screen, etc.) right. Web 1.0 was like the mainframe apps, Web 2.0 is like the desktop GUI. Welcome to the club, Joel, over a year and a half later. ;-)
• Large JavaScript apps will download faster over bigger pipes (or "tubes" or "trucks") and run faster in newer browsers with better JavaScript runtimes. So nobody cares about the 3k do everything library anymore, just like features are more important that memory footprint and performance in Desktop UI's. Again, welcome to the club.
• The portable programming language is not likely to be Javascript in the long run. Think VM, like Tamarin or Silverlight. The same developments that make JavaScript run faster in the browser will ultimately make it irrelevant.

So where did Joel go wrong?

• For one, he confuses the categories of Hardware Platforms, Operating Systems, UI Toolkits and Application Software. Anyone remember the RogueWave GUI libraries, circa 1994, or Think's Lightspeed C for the Mac from way back when? Where are they now? (RogueWave is still around, as is Symantec which acquired Think C, but you wouldn't exactly say they were the "winners" when it came to GUI SDK's.)
• What are the applications, the 1-2-3's of the web age? Well, everyone who publishes a web site is an ISV. Some make very basic use of the platform's (browser's) features. Some who publish full on webapps make fairly sophisticated use of them. As a group they have more leverage over the OS/Browser than Lotus 1-2-3 and company ever had. That's why IE can't make crazy extensions W3C standards, just incremental ones.
• Compilers and languages have come a long way since C showed the way. The norm now is for runtimes to support multiple languages with a common API (see .NET, etc.). So no "single" language will need to be invented.
• NewSDK looks a lot like GWT. Sorry, Joel, Google isn't snoozing. They may still get overtaken, but your narrative is a little off the mark.

What is the hardware, the OS, the GUI SDK and the Application? You could take the naive approach and say that Intel is still the hardware, Windows XP/Vista is the OS, but that doesn't quite square with how I see things. I think that the browser is the OS, DOM and Javascript are the GUI foundation library, and Dojo, Ext JS, etc. are the RogueWave and ThinkC SDK's of the Ajax age. As the OS/GUI library changes (new features/standards in the browser, etc.), so these SDK's will have to scramble to keep up. They will be influential, but eventually more and more of core GUI functionality will make its way into the browser. The browser calls the tune, everyone else just dances along.

Technorati Tags: ajax, spolsky

Desktop Applications Dying, Dying...

My post the other day on the death of desktop applications got me a large volume of hate mail. I was alternately an ignoramus or a hater. One common refrain was that Web UI's still sucked and would never replace Desktop apps in terms of the user experience (OK, it was usually not phrased so elegantly). I guess many readers missed my point. My point was that it rarely makes sense to develop a pure Desktop app anymore, not that everything should be a webapp. Why is that?

1. In many cases and for many uses, Web UI's are as good as Desktop UI's. Look at all of the Ajax photoshop knockoffs (here and here), the various word processor or spreadsheet apps, and the direct manipulation interfaces such as Yahoo Pipes.
2. The choice is no longer between the Desktop app and the Webapp, but between just doing a webapp or using something like Adobe AIR or Google Gears to do a Desktop RIA and a webapp at the same time.
3. As the capabilities of browsers increase, with faster and more efficient Javascript engines, offline features, etc., and the maturity of Ajax frameworks evolve, the reasons for writing Desktop RIA's that can also work as webapps become more compelling.

Those that persist in yammering about how kludgey webapps are live in the distant past, confusing the Green Screen nature of the pre-Ajax (as I observed here in 2006, and Joel Spolsky did here over a year and a half later -- more on what Joel got right and wrong in a later post) with the current ability to develop Component GUI applications just like those Desktop apps. My point remains unchanged: spending significant resources to develop a purely desktop app only makes sense in specific circumstances, and unless you have tons of money to write your own network integration systems, you are best off using the already available Desktop RIA frameworks.

Technorati Tags: ajax, desktop RIA

An Event Apart: Wrap-Up

The dust has cleared from An Event Apart Chicago 2007. Now that I've gotten the basic reportage out of the way (here and here), on to the editorial page.

Three things I loved

• The wide range of topics: Despite increasing specialization in the web-development field, jacks of all trades still dominate our industry. An Event Apart offered sessions by and for designers, information architects, writers and developers alike. The most interesting sessions were often the ones that didn't cover my own specialties. Dan Cederhom and Jason Santa Maria both tackled visual design. There was little overlap between their presentations, yet each offered up practical device for folks who have to wing it with graphical design without much formal training. Similar cross-functional advice dominated the agenda.
• The skepticism about rules: Presenter after presenter - most especially Liz Danzico - prioritized guidelines over rules, research over dogma, and attention to one's own audience over one-size-fits-all solutions. One thing that usually distinguishes a great developer, or at least a mature one, is the ability to juggle a host of competing concerns without getting lost in the weeds. Accessibility vs. Ajax, beauty vs. usability, power users vs. Great Aunt Tilly - everything is a tradeoff. If there was on overriding message to An Event Apart, it was that we have to think deeply and often about our audience, our business and our objectives and make informed decisions.
• The focus on end users: It should surprise nobody that the ALA folks are usability nerds, standards geeks and champions of the end user. But it was inspiring to see how the speakers translated that well-worn agenda into series of discrete, actionable tips for everyday developers. As with any complex human endeavor, web development is all about picking your battles. With a potentially limitless number of improvements that could be made to any site or application, it's easy to feel overwhelmed. Most speakers showed how simple steps could provide incremental improvements in usability, accessibility, compatibility and profitability - all without starting over at the ground level.

Three things I didn't love so much

• The absence of concurrent sessions: Packing all 500 attendees into one room for the same 12 sessions (picture here) allowed ample cross-pollination. I'm an RIA developer, but I got the most out of the design, IA and BI sessions. Nevertheless, I longed for the ability to choose from multiple sessions, split off from my colleagues, and come back together during breaks to compare notes. It's not that any of the sessions were completely worthless. It's just that most were designed for intermediate skill levels in the same core technologies. I really didn't need to spend 15 minutes having xmlHttpRequest and getElementByID explained to me. It would have been great if some content had been pitched to masters as well as journeymen. The only way to make that work is through careful scheduling of multiple concurrent sessions.
• The dearth of programming content: A List Apart calls itself a site "for people who make websites," but not for people who make webapps. The broad range of topics very rarely extended to the programming realm. Only one session directly tackled JavaScript, and it was at an extremely elementary level. There was nothing on Java, Ruby, Python or .Net, let alone RIAs, widgets, mash-ups, Flex, Silverlight, GWT or JavaScript libraries. I know, I know, plenty of conferences already cater to those crowds. But as a programmer, I felt shortchanged. Again, concurrent sessions could have solved this, but I'm not sure programming - client- or server-side - will ever be on the ALA crowd's agenda.
• The lack of schmooze time: The schedule included some after-hours social events and a 90-minute lunch break each day, but I talked to lots of attendees who felt like they didn't get enough time to chat with other attendees. Other than a lonely bulletin board - and a social-networking site opened a few weeks ahead of time - there weren't a lot of structured opportunities to connect job-seekers and recruiters or peers from separate companies. Part of the problem was probably the cramped accommodations. When folks had breaks, they were too busy stretching their legs to schmooze. Still, I would have loved to see breakaway sessions aligned by job or industry categories.

Conclusions

For "people who make web sites," An Event Apart was probably a fantastic chance to hear practical advice and smart prognostication from industry leaders. For people who write client-side webapp code, it was a very good round-up of philosophies and techniques that too often get lost amidst the technical details. For pure software engineers, it probably would have been a waste of time and money.

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 javascript: URL pseudo-protocol. His most extensive example showed how to code a graphical widget for the assignment of star ratings so that it would degrade gracefully into a standard HTML select box in less capable browsers. After discussing the difficulty of making XHR functionality play nicely with bookmarks and the back button, Keith acknowledged that his parting message - when in doubt, leave XHR out - was a bit of a copout for the author of an Ajax manual.

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.

Bubble 2.0?

The sky is falling! Every publication has to have it's resident curmudgeon. It's a franchise, and PC Magazine's is held down by John Dvorak. Now he's moaning about a dot-com bubble redux involving Web 2.0 based companies.

Each of these bubbles had a distinctive theme. For the dot-com bubble, it was e-commerce—it really should have been called the e-commerce bubble. Everything was focused on how the Internet was going to destroy all existing brick-and-mortar operations. We were told that you'd be buying sandwiches over the Internet and having them delivered the next day by FedEx. Everything was about "eyeballs" and finding ways to attract customers, whether they bought anything or not. Every article in every newspaper in the country parroted the litany as to how you'd be out of business in a year or two if you were not present on the Web in a big way. Of course, this was all crap.

The current bubble, already called Bubble 2.0 to mock the Web 2.0 moniker, is harder to pin down insofar as a primary destructive theme is concerned.

He goes on to scoff at the various concepts that are in vogue in the Web 2.0 space, all of which could come tumbling down in a crash.

• Neo-social networking
• Video mania
• User-generated content
• Mobile everything
• Ad-leveraged search
• Widgets and toolbars
  

An economic bubble is defined as “trade in high volumes at prices that are considerably at variance from intrinsic values”. Is that really where we are? I don't see all that many "me too" or momentum investments in Web 2.0 companies -- just a $10 million investment here or there by some VC's. Facebook has a large valuation because they actually generate lots of advertising income (shoot, 1% of all online time is spent on Facebook), and online advertising it here to stay.

Most of the Ajax/Web 2.0 activity I see right now is existing companies retooling their online presence to take advantage of some of the new technologies and ideas.

Sorry Dvorak, no bubble here yet.


Technorati Tags: ajax, editorial, web 2.0

YouTube Killed the Video Star

Mr. McGuire: I want to say one word to you. Just one word.
Benjamin: Yes, sir.
Mr. McGuire: Are you listening?
Benjamin: Yes, I am.
Mr. McGuire: Plastics.
Benjamin: Just how do you mean that, sir?

Everytime I make a pronouncement about the way "the industry" is going, I feel like Mr. McGuire from the graduate -- old, pompous, irrelevant. Still, sometimes you have to call them the way you see them. So it is with the continued growth of video on the web.

To me, it looks like online video is about to do to cable and the networks what the web did (and continues to do) to newspapers around the turn of the century -- steal their customers and advertisers. There reasons for this trend are multi-factorial: cheaper and bigger bandwidth; faster laptops and internet enabled video devices; greater viewer comfort with watching content "offline," through DVR's like TiVo. These factors and the trend they drive will only continue to accelerate. Imagine a TiVo that will allow you to search, pick and record online content just as well as the "legacy" cable content.

Fake Steve has similar sentiments (if you're not familiar with the deeply tongue in cheek "diary" of Apple CEO Steve Jobs, do yourself a favor and add it to your RSS reader):

Trust me, I own one of these networks. I talk to the executives. They're clueless pussies who will never dare to take any risks because at the end of the day what they care most about is keeping their jobs and perks and fancy offices. Meanwhile the nothing-to-lose-and-no-FCC-rules Internet stuff is coming at them at warp speed. Worse yet, the networks have destroyed their own news operations, which was really the only part of their business where they were adding value. And this, by the way, is now the huge gaping opportunity on the Internet. Forget "Ask a Ninja" or "Naked News" or girls in bikinis on trampolines. Someone with money and brains is going to do an Internet version of what Ted Turner did with CNN in the early days of cable. Real content. High quality, good reporters, cheap cameras out in the field. Streaming news and on-demand, so you could go back and watch pieces over and over again, or email them to friends.

Just imagine what you could do in Iraq with twenty ballsy reporters armed with cheap digital cameras and no network brass to censor them. Imagine how you could cover the 2008 elections. Imagine the size of the worldwide audience. Imagine how stunned people would be if, for once, the people doing the news could actually tell you the truth. Imagine if the reporters were smart, funny and wise-ass, instead of Ken Doll robots with strings in the back of their heads. Imagine if you didn't have to abide by the stupid rules about equal time and fair play. Imagine if you got a handful of sales guys with TV experience (nobody over 40) to bring in the advertising. It'll happen. Wait and see.

Ouch!

So, what does this have to do with Ajax? We aren't just writing code that uses XMLHttpRequest objects. We are writing applications with a purpose -- to entertain, inform, sell, assist, create. And as web technologies and usages evolve, we have to make sure our apps evolve right along. People still read books, despite the popularity of TV. People will still use "traditional" webapps, without video, but video will start to play a greater role in more and more online applications. It is time for us to start thinking about how to make our Ajax-enabled apps take advantage of this trend.

Technorati Tags: ajax, video, youtube

Angry at GWT

Ryan Doherty is an angry man. What is he angry about? He is angry at GWT. Why is he angry?

The bottom line is GWT doesn't give a damn about the web and treats it as an inconvenient interface that needs to be avoided at all costs. And it does, but to a terrible outcome. The developers obviously do not understand the paradigms and principles of the web. It's amazing the amount of work they put into creating this Java based toolkit when quite possibly a lesser amount of time could have been spent working on a great Javascript/HTML/CSS library (YUI, jQuery, Ext, Scriptaculous) that would promote web standards.

Ryan sprinkles his gunpowder over four points in his blog entry, Why Google Web Toolkit Rots Your Brain:

• Any time you program one language in another, you lose all the benefits of the target language
• GWT completely ignores the fact you are creating a website, NOT an application
• GWT is bloated
• GWT does browser sniffing

Let me rebut the easiest ones first. So what I think that Ryan is trying to say with the web site versus applications statement is that we are developing web applications, not just applications. So emphasis is on "web." And Ryan thinks that if you are writing a web application, you should use web standards, not the funky, ugly code that GWT produces. I say make the code as ugly and funky as possible. Write clean Java code, then let the GWT compiler deal with generating the target Javascript code. As they improve the compiler, the quality of the HTML/Javascript/CSS will improve without my having to change my application code.

As for the browser sniffing, the GWT generates different code for different browsers and, once again, it is compiled. As new browser types and versions come out -- a very likely scenario in the world of mobile devices -- you don't have to decorate your code with lots of excess conditionals to test for browser properties. All those extra conditionals add up. And you'll have to rewrite your code (or library) to support other browser types and versions as they come out.

Now, is GWT bloated? Ryan's example is "Hello, World!" Not exactly a fair test, since most of the code there is setup and Java lib code; it would be better to look at a larger example. Plus, he counts in all of the alternate files for different browsers. Since they are generated by the compiler and don't have to be maintained seperately, you should count only one of them. Beside, he counts them in lines, not bytes. Last, lines of generated code versus lines of hand written code is misleading. Since many Javascript libraries do lots of initialization on loading and on object creation, you really have to count its memory footprint, not it's linecount.

As to losing the benefits of the target language, there are benefits and drawbacks to all languages. I'd say that for large, complex systems, a strongly typed language has its advantages. As I've already written, dynamically typed languages like Javascript have some pitfalls:

But code completion and tools are a bit of a red herring here. I've always felt uncomfortable with programming languages that depend on good programmer behavior -- essentially obeying code level idioms -- to allow for the development of large, interdependent systems. Alex Russell, in my interview with him, argued that Javascript was a "more powerful" language than Java and cited this paper by Lutz Prechelt that claimed to show that scripting languages are moe powerful and productive than the statically typed, OO languages (in part -- it's a simplification of the thesis). I agree that I can do in 1 hour in Perl what it would take me 10 hours in Java. I might even hope, as a single developer writing my own well understood style of OO Perl, to write a large application more quickly in Perl than in Java. But add in multiple developers, and you start to enjoy the complexity problem that Bruce Johnson mentioned. The same, in spades, goes for Javascript.

Ryan's complaints soundly eerily like those of the assembly language programmers throwing thier verbal sabots into the gears of early compilers. They would produce code that was bloated, poorly written, slow, etc. Programmers who used these higher level languages would rot their brains. That battle has been settled in favor of the compilers. No one would write substantial amounts of assembly code these days. The humans have lost.

With the likely inclusion of Tamarin (the ActionScript Virtual Machine 2) in future versions of Mozilla browsers, what's to say that future versions of GWT won't produce compiled bytecode for the Firefox platform?

    Technorati : ajax, editorial, gwt

My Mash Note to Microsoft, Newest Member of the OpenAjax Alliance

It is easy to be cynical about Microsoft's recent entry into the OpenAjax Alliance. After all, the alliance is mostly a marketing vehicle for it's members. The "technology" portion of the OpenAjax Alliance revolves mostly around things like playing namespace cop -- more problems of the Javascript language and browser platform than real framework issues -- and is making very modest progress. Beyond the bitching of the odd developer about Prototype not playing nice with other frameworks, the real problem with Ajax frameworks is that they each reinvent the wheel, not that they don't work well together. This sort of ad-hoc interoperability -- making sure that different libraries and frameworks don't clobber one another -- reminds one of the legislative process: when the parties are divided, a weak compromise is often the best for which you can hope. (See John Reisig's take on why the OpenAjax Hub is in fact not a very good technical solution.)

Not that these efforts are useless; they are better than nothing. But both Ajax and the browser platform are still moving targets. Investing heavily in a standard that may evaporate once the next version of the browser comes out or if Ajax development moves away from direct browser programming to more abstracted models (Echo2, GWT, etc.), seems like something you would want to do quite slowly.

So, is Microsoft's entry a sign that it really wants to play nice, or is this part of its diabolical plan to "embrace, extend and extinguish?" I think the answer is more the former than the latter, and that has me feeling all warm and fuzzy towards my blue badge buddies in Redmond. I think Microsoft, by getting rid of its annoying compatibility layer, is trying to embrace open source Ajax libraries. Why? Because they realize that writing fancy eye-candy DHTML/Ajax wizardry is hard and expensive. Much better to treat this little browser ecosystem the way they treat custom WinForm controls -- a marketplace too fragmented for MS to efficiently play, but whose vitality and diversity needs to be encouraged in order to add value to the base platform, .NET in both cases.

I think this apparent willingness to foster third-party Ajax libraries is the real news, not their entry into a very corporate ("Member of the OpenAjax Alliance"), very marketing oriented, marginally technically useful organization.

    Technorati : .NET, ajax, editorial, microsoft, openajax alliance, openajax hub

The Hazards of Blog Editing Software

Somewhere along the way in yesterday's post about JSONP, I made an edit and an empty DIV got swallowed. The result was a somewhat underwhelming demo where you pushed the button and nothing happened. I've fixed the post and, hopefully, it all works now.

Technorati : ajax, editorial

Is Javascript the Assembly Language of Web 2.0?

I went home for my father's 77th birthday last weekend. Besides catching a bad stomach flu that has laid me out for the last few days, I also had a little browse down the memory bookshelf. In with Plato's Republic I found a few of my less useful CS books -- 80x86 and 68k assembly language books, Fortran, PASCAL -- that I haven't bothered to include in my working programmers library. I rarely have to look at any legacy Fortran or PASCAL, and I haven't had to do any assembly language in forever. I've toyed around with assembly language for the JVM, but more as a curiosity. Unless you are a kernel or compiler writer, there just isn't much call to do it.

Now I've interviewed and worked with lots of developers over my career. Just taking the last seven, say since 2000, I've noticed a real drop off in those who have studied assembly language programming. Now why would I care about whether programmers are knowledgeable in a skill that I myself don't even use? Why should I value such an impractical skill? Well, because I think that solving problems using assembly language gives you a deeper insight into the workings of the underlying hardware and, more importantly, imposes a certain mental discipline on the problem solver. The same thing is true for programming with punch cards. I may be one of the youngest people around who actually wrote code on punch cards and fed it to an ever obliging Amdahl (an IBM mainframe clone at SUNY Binghamton, near the birthplace of IBM, eegads).

Having to retype your code a card at a time (no backspacing, baby, and no code completion) and waiting for up to an hour to find out you had committed a logic or syntax error, makes you ruthless and efficient in your debugging and problem solving. For guys like me, symbolic debuggers and all the crutches that an IDE provides seem like junk food for the programmer's mind. Of course, once you've used tools like Resharper, a plugin that makes Visual Studio a pleasure to use, you have to allow yourself a few development Fruit Loops.

I see the same sort of evolution with the browser platform. The appearance of well engineered frameworks that simplify, hide or eliminate the need to know Javascript, CSS or XHTML, is the beginning of the end of Javascript as a core skill set for web development. It may not seem obvious now, of course; after all, there seems to be more Javascript development going on than ever before, but the trend toward Javascript-free Ajax and web development is rooted in this furious framework activity.

And that trend disturbs me for the same reasons that the trend away from Assembly language disturbed me: a lack of mental rigor and an ignorance of the underlying platform. Maybe I'm a fuddy-duddy as described in On the necessity of removing "cruelty" from the teaching of computing by Tony Clear:

They bewailed the dumbing down of programming, with COBOL's grandiose claims to remove the need for good old assembly language programming. It was going to make programming easy, as later would fourth generation languages and all the subsequent over-hyped marketing exercises proposing the end of programming.

The impetus for this article was the talk by Edsger Dijkstra entitled On The Cruelty of Really Teaching Computing Science. He was arguing for the teaching of CS as a mathematical discipline. The debate has moved on, but one of my favorite statements on the mixed blessing of applying computers to real world problems:

The business community, which, having been sold the idea that computers would make life easier, is mentally unprepared to accept that they only solve the easier problems at the price of creating much harder ones.

It's good advice to keep in mind as we solve the "easy" problem of making web applications more powerful and easier to develop.

Technorati : ajax, education

The Business of Ajax - Google's Ajax Search API

Google actually relies on our users to help with our marketing. We have a very high percentage of our users who often tell others about our search engine. -- Sergey Brin

So spake one of the co-founders of Google. But what happens when your users start to tell others about your search engines in ways that you don't like? When they present your search results in ways that hurt or confuse your brand? You would probably try to control how those users used those results. That seems to be what Google has done with the release of their new Google Ajax Search API.

Somewhat lost in the hype around the release of the Ajax API was the discontinuation of the Google SOAP Search API. It's still available to existing subscribers, but no new ones are being signed up. To see why this discontinuation is an exercise in brand discipline, you just have to look at the terms of use for the Ajax API:

You agree that you will not, and you will not permit your users or other third parties to: (a) modify or replace the text, images, or other content of the Google Search Results, including by (i) changing the order in which the Google Search Results appear, (ii) intermixing Search Results from sources other than Google, or (iii) intermixing other content such that it appears to be part of the Google Search Results; or (b) modify, replace or otherwise disable the functioning of links to Google or third party websites provided in the Google Search Results.

The key terms here are that the order and appearance cannot be modified. And that is the essence of the Google brand: the order of the search terms. Fortunes are made and lost based on Google search position. Business plans are build around it. Millions of people around the world use the top ten results to find information, guide purchasing decisions, and so on. Mess with that order in some consistent way -- in some, god forbid, way that people find valuable -- and you've lost control of your brand, who you are, and likely your ability to advertise.

Now, with the new API, you can only use and display Google data inside a tightly circumscribed, parameterized boundary. Their order, their look and feel, their ads, their brand.

Of course there are many other ways of presenting search results. Many of the more interesting.ways to present the data reorder the results according to other criteria or third-party data (like other search results), or even dispense with a linear order. Now if you want to pull in search data and manipulate it in this way, you're going to have to use the Yahoo! REST API's. But will Yahoo! follow suit and get rid of their general API's in favor of brand-preserving Ajax widgets? Dave Megginson doesn't think so, but sees some clouds on the horizon.

Data APIs are not going to disappear, of course. AJAX widgets don't allow mash-ups, and some sites have user bases including many developers who rely on being able to combine data from different sources (think CraigsList). However, the fact that Google has decided that there's no value playing in the space will matter a lot to a lot of people. If you care about open data, this would be a good time to start thinking of credible business cases for companies to (continue) offer(ing) it.

I view this as a Hertz vs Avis opportunity for Yahoo! -- "we try harder" with web services. Where Google might have been the first choice for many developers, now many will build the Yahoo! API's into their applications and their frameworks. It takes just a few common plugins for packages like Drupal to boost market share.

Anyone want to buy a slightly used copy of "Google Hacks?" Drop me an email. I'll be busy helping Yahoo!'s marketing by telling other's about their search.

Technorati : ajax, google, search, web services, yahoo

Why Ajax Failed the First Time Around

I guess everyone else has commented about Alex Bosworth's talk entitled Physics, Speed and Psychology: What Works and What Doesn't in Software, and Why, so why shouldn't I? To summarize his points on Ajax, he says that Ajax didn't take off in 1997 because:

1. Trying to do Ajax over dialup was too slow.
2. Trying to run complex Javascript on CPU's of the time was too slow.
3. Deploying complex web GUI's with little customer support is a recipe for failure.

Now everyone has fast CPU's sitting on broadband connections, so everything is cool and the gang. Right? Not in my estimation.

I've been developing web sites and web applications (we called them "scripts" back then) pretty much since the beginning. From approximately 1997 until 2004 there were really two different contexts that I worked in -- Intranet apps running on uniform OS/Browser platforms over high speed LAN's, and Internet sites/apps running on heterogenous OS/Browser platforms and varying connections speeds. 1 & 2 were not really factors in the Intranet context, so why didn't it take off there?

In both environments we used the kind of IFrame-based proto-Ajax that most web developers are familiar with. We did it for all the reasons that people use Ajax today: it can reduce bandwidth and improve the perceived speed of the application. We tried to limit the complexity of our Javascript, partly for execution and download speed issues. But really, there was one reason we kept complexity low: IE in those days was a piece of shit.

The number of ways that QA tested code could fail in different versions of IE was mindblowing. My favorite was the order of installation bugs that kept cropping up, e.g. the order that Windows, Office, IE and other service packs and new versions were installed in could result in bugs that would wipe out a big part of your apps functionality. Try telling a big client that just migrated 15,000 users from Windows 2000 to XP that they need to do it over again because the order of install is causing your app to break.

BTW, #3 is a legitimate issue that is still with us. Until user experience standards and people's expectations for webapps catch up to the applications' capabilities, we're going to be in a situation reminicent of the early days of Win 3 and Mac OS -- everyone doing their own thing in the user interface arena to be "cool" or "different," and users bleeding from the ears because they are constantly learning entirely new UI paradigms.

Technorati : ajax, bosworth, editorial

Which Ajax-based Apps Do You Actually Use?

I've looked at a lot of Ajax-based apps in the last year and a half and have kicked the tires pretty seriously on over two hundred. I've recently taken stock of how many I actually used more than that first time. In the end, I don't use all that many of them. Why not?

• All those nifty proof of concepts that do a photoshop clone on the web are just too impractical, too slow.
• Not everyone feels comfortable using Google Spreadsheet. Getting out of the habit of using dekstop apps is not so trivial. There is a real angst when abandoning the desktop/email attachment paradigm.
• I don't use social bookmarking sites for the Ajax buzz. In fact, the social bookmarking sites I use most have the least amount of Ajax. It seems to keep the riff raff out and keep the signal to noise ratio high.
• Who really needs an Ajax OS? Maybe those hipsters in China that flit from cyber cafe to cyber cafe with their neon colored thumb drives. I already have a few too many desktops in my own computing environment without taking Ajax strays off the net.
• Collaboration on the web still sucks. In fact, computer mediated collaboration pretty much sucks everywhere. Wiki's usually need major first aid from a librarian after about 3 months of vigorous collaboration, and Wiki's are really the best metaphor for collaboration at the moment.
• After over a decade of getting used to the web and it's limited user interface, now I have to learn all sorts of new widgets and behaviors. The lack of standards in this domain can make Ajax apps somewhat challending to learn.

Most of the Ajax apps I use are bookmarklets and other subversive things I've put together to improve my experience on other sites. I also use Google Maps, but that could just as well be done in Flash (and in fact is, when you look at the Flash version of Yahoo maps). And of course there are a few pay applications that I use that are incorporating Ajax in their interfaces.

I'm curious to learn what sort of Ajax apps everyone out there is using on a daily or weekly basis. Drop me a line (ajax@pathf.com).

Technorati : ajax, editorial

More Articles Needed on How to Design Ajax Apps, not Just How to Program Them

I've been busy with yet another big launch (YABL), so I've only had time to read a few things on Ajax. I've long argued that Ajax wasn't just going to give us a few nice widgets, but that it would change the way we developed web applications (and how that will give you less of a headache). Apparently Christian Heilmann agrees in his juicy enchilada of a post entitled Event-Driven Web Application Design.

Rather than arguing as I do that the proper model for Ajax webapp development is the desktop GUI, he starts at a more basic level: the event-driven nature of Ajax webapps. He draws a distinction between the traditional way of doing event handling in Javascript -- page finishes loading, do some initialization; click a link, trigger another function; etc. -- and the DOM way of doing things -- adding specific event listeners to elements.

He goes on to describe how to plan an event driven app, how to add custom events, and walks through planning an example app. While I think that he's thinking too small (developing apps with Echo2 like a Swing app is the way to go), I think more articles like this are needed, not on how to add an Ajax widget, but rather on new ways to develop Ajax webapps.

Technorati : ajax, appdev

Web 2.0, Communism, Pet Rocks and the Wisdom of Crowds

In a typical month I get more questions about Web 2.0 than about Ajax. The Ajax questions cover a broad range of topics, the Web 2.0 questions are mostly "what the heck is Web 2.0?" I don't really have a good answer, but these frequent questions have caused me to ponder why Tim O'Reilly's definition seems so flabby. Here then is one of my infrequent meditations on Web 2.0.

It is well over a year since Tim O'Reilly laid out his ideas on Web 2.0. At the time he wrote his seminal article, "Web 2.0" had already been in common parlance for a year and a half "with more than 9.5 million citations in Google." Since that time, Web 2.0 has become synonymous with Ajax, social bookmarking, user generated content and other buzzwords of the day. It is my guess, however, that Tim didn't intend his 7 characteristics of Web 2.0 to be taken ala cart, or "like a fruit salad." But I do think that as the concepts of Web 2.0 have been proven out in the real world, some of his 7 characteristics -- especially the process ones -- are turning out to be best practices for any sort of web application.

And Then There Were Five

So which of the characteristics should we peel from Web 2.0? My first nominee is #4, "End of the Software Release Cycle." Also termed "the perpetual beta," it is the idea that systems will undergo constant change and that users should be treated as co-developers. Further, companies must have the operational chops to support this constant change. There is nothing wrong with #4 in principle, but there are a number of reasons why it isn't really a part of Web 2.0:

1. Let's be honest, we're talking about short release cycles, not no release cycles.
2. Early adopter will accept and even embrace quickly changing software. For the great mass of consumers and established businesses that depend on your service, rapid changes can be problematic.
3. Web based businesses have gone through cycles of innovation and consolidation since the early 90's. Small, nimble companies (including Yahoo!) pushed features into their Web sites and applications in short release cycles. Once these companies became larger, innovation took a back seat to stabilization and growth. Release cycles became longer and, as happens with so many large organizations, many of them stopped taking risks. But since innovations in browsers and other technologies change the terrain of the web so frequently, and the cost of distribution has remained so low (the price of a good colo remains quite reasonable, unless the sluggish behemoths that are against net neutrality get their way), the cycle of innovation and consolidation has remained consistently short. We'll rediscover the end of the software release cycle each time when Web 3.0, 4.0, and 5.0 all roll around.
4. Small, nimble startups are usually better able to push new functionality in short releases. In fact, it is often an unfortunate side effect of a lack of process. Big companies have to work hard on shortening their cycles. As such it is a triumph of governance and process rather than technology. Claiming this fundamental competitive advantage for Web 2.0 is overreaching. It is neither a necessary or sufficient condition for Web 2.0.

Characteristic #7, "Rich User Experience" is also a candidate for eviction. The concept here is that using Ajax you can deliver GUI style applications. The implication for Web 2.0 is that rich user experience will enable all sorts of apps not seen before:

We expect to see many new web applications over the next few years, both truly novel applications, and rich web reimplementations of PC applications. Every platform change to date has also created opportunities for a leadership change in the dominant applications of the previous platform.

While we are seeing new applications, such as Google's collaborative spreadsheet, we are seeing many more retoolings of traditional shopping cart and other Web 1.0 applications. Just like #4, #7 will not distinguish Web 2.0 from Web 1.0 apps -- i.e. it is not a necessary nor sufficient condition for Web 2.0.

Why bother trimming away at Web 2.0? I think there is some merit to the Web 2.0 meme, but making its characteristics so broad obscures its true nature. I think other concepts -- the wisdom of crowds, the long tail, and software above the level of a single device -- are necessary and sufficient conditions for Web 2.0.

The Wisdom of Crowds, the Free rider Problem, and the Paradox of Choice

Of all of the Web 2.0 concepts, I think the Wisdom of Crowds is the most import. In my opinion, all of the other principles are in service of enabling user generated content and more generally the "noodle of the mob", err, the wisdom of the crowd. But while it is the most important principle, it is also the most fragile; online communities have been around since before 1979 (Usenet, Compuserve, etc.). They all seem to have a lifecycle, however -- they rise and fall in a predictable arc.

That something so fragile and perishable should be at the heart of Web 2.0 is worrisome. I'm not sure that anyone has the answers as to why all online communities wither away, but I have a few ideas.

1. In knowledge management, there is the concept of tacit knowledge capture, i.e. a community does something together (a project, for example) and the artifacts that they produce -- discussions, documents, FAQ's -- are valuable knowledge. When you try to gather knowledge without "doing something," you have to insert more and more management -- librarians -- to make things work. Communities where users simply share testimonials about how great a product works is going to wither sooner than most or maybe never live at all.
2. When the incentives of all the participants are aligned, communities work well. When they are not, such as when commercial interests intrude, the community degenerates. This is how USENET eventually succumbed to a flood of spam. These are bad actors, as opposed to the free riders below.
3. At their best, online communities are like communism: From each according to his ability, to each according to his need. But why did communism fail? Because of the free rider problem. Free riders are actors who consume more than their fair share of a resource, or shoulder less than a fair share of the costs of its production. The free rider problem is the question of how to prevent free riding from taking place, or at least limit its negative effects. Unfortunately, it seems that online communities suffer from a massive free rider problem, with lurkers, occasional contributors and frequent contributors having about a 90-9-1 ratio.
4. Communities don't die because they are fads, like pet rocks. See this analysis of the Friendster collapse to see why it was more about #2 above.

The wisdom of crowds is the methane that fuels the torch of Web 2.0. As such it is important to solve some of the issues that plague the effectiveness and longevity of online communities.

Anyhow, that's it for my meditation on Web 2.0. Sorry I wasn't able to come up with a pithy Malcolm-Gladwellism to summarize my thoughts.

Technorati : ajax, web20

Ajax Predictions for 2007

Happy New Year! I took a little time off this holiday season to recharge the batteries and reflecting on the last year in Agile Ajax. Looking at my posts of the past year and the path that Ajax has taken got me thinking about what might be in store for the next year. Here then are my predictions for Ajax in the coming year.

1. Ajax will stop being the big buzzword. It will join terms like "HTML," "servlets" and "CSS" as part of the background noise. The Ajax focused books published at the end of 2007 will focus on specific frameworks, like Tibco GI, Echo2, OpenLaszlo and GWT.
2. Microsoft and Mozilla will add new features to their browsers to extend Ajax support. These features will address things like cross site scripting (making it easier and more secure), security, widgets standards support, extensions of Javascript, etc. The browser will evolve into more of an application platform than it is now.
3. Focus will shift from simple, one trick frameworks to complete client/server/tools solutions. Look for combinations of Dojo, GWT, Tibco GI, Echo2, ZK with other libraries and frameworks.
4. 2007 will see a new influx of WYSIWYG tools, the most innovative and powerful of which will focus on a specific Ajax frameworks. Visual Ajax widget designers make their first appearance, allowing people will moderate Javascript/CSS ability to roll their own.
5. Prototype -- with its lack of documentation and a development roadmap -- will begin fading away in favor of JQuery and other similar competitors.
6. Adobe Apollo is released, is really cool, will fail to make much of a dent in the application development market.
7. The Microsoft Ajax stack, with its lack of outside innovation, will continue to limp a little behind the Java and Javascript (and Python and Ruby) alternatives. No serious .NET alternative will emerge.
8. Still less than 50% of the top US sites will use Ajax by the end of the year.
9. A big security stink will cloud the future of Software as a Service and point out the difference between email and Excel spreadsheets (hint: for one you assume connectivity, for the other you do not).
10. Social bookmarking sites will finish 2007 still as the undisputed kings of the Ajax/Web 2.0 world.

In short, I see 2007 as more of an intermediate year of tools, evolution and experimentation. Look to 2008 as the year of really big developments.

Technorati : ajax, predictions

Echo2 Needs a Better Way for Third Party's to Contribute

There are two big dogs in the world of Echo2:

1. NextApp (with Echo2 creator Tod Liebeck) which releases Echo2, Echo2Studio (Eclipse Plugin) and Echo2Extras (more components).
2. EchopointNG (run by Brad Baker), a collection of more Echo2 components.

Aside from the fact that EchopointNG needs a real project web site of it's own instead of the Echo 1 stuff that's on there now, there is no easy way for developers to contribute components to Echo2. Right now you have to go crawling around the forums, looking for contributions in zip files. Someone should put together a contribution repository. I know that organizing and maintaining such a repository is no small thing, but components are the lifeblood of any component GUI. If Echo2 doesn't keep up with GWT, ZK, Tibco and all the rest, it won't matter how elegant its design, etc. Developers will go where the widgets are and two projects won't do the trick.

Maybe I need to step up to the plate. But I'd hate to have to drop it for lack of time. I need to think about this some more.

In the meantime, a new Beta 5 release of Echo2, Echo2Extras and Echo2Studio is out. A few fixes, many around IE6, and opacity-based fades for the TransitionPane component. The RC's for Echo2 are close.

Technorati : ajax, announcement, echo2, opinion

More from Hinchcliffe on Web 2.0

As you know, I don't really like to be a blog echo chamber. One post spawns hundreds of "check this out" links, but I suppose that's how I get some of my traffic, so maybe I shouldn't be such a fuddy duddy. But I'll still try to keep it to just those posts I think are worthwhile.

OK, so Web 2.0 is one of those frothy subjects -- even frothier than Ajax -- that spawns all sorts of overhyped, frothy posts and articles. Dion Hinchcliffe is a thoughtful and frequent exception to this rule. He's been posting on the subject on his Web 2.0 blog for over a year now and his latest post, The Habits of Highly Effective Web 2.0 Sites is particularly interesting.

Dion points out seven (is this coincidence?) characteristics of an effective Web 2.0 site:

1. Ease of Use
2. Open up your data
3. Aggressively add feedback loops to everything
4. Continuous release cycles
5. Make your users part of your software
6. Turn your applications into platforms
7. Don't create social communities just to have them

I think the first -- ease of use -- is clearly a winner. That is where Ajax can and does play a part. The fifth characteristic is at the heart of Web 2.0, the creation of social networks. More needs to be said on this point, especially when it comes to the Free Rider Problem. If you haven't read much about Communism and the reasons for it's demise, don't worry. If you've experienced the problem of spam on social bookmarking sites -- individuals who get a "free ride" on the work of others by selfishly posting links of dubious quality -- then you know what I mean.

A number of studies have been done on the free rider problem and it's relationship to the size of social networks. All of this research can be used to devise some technical solutions to social bookmarking spam. More on this later.

Technorati : ajax, web20

That Giant Sucking Sound is Ajax Turning Your Site into an Application

I have a simple rule of thumb for support costs: take the number of use cases, function points or whatever you use to estimate development effort, multiply it times the number of users who will be accessing your application, correct for the sophistication of that population -- Joe Hacker versus Grandma Moses -- and the amount of money that is on the line for both your users and your company, and voila! you have a three shift operations center and an army of developers wearing pagers. Actually, it gives you an order of magnitude figure for the kind of effort supporting your application will take.

Here it's common to distinguish between sites and applications. By sites we usually understand the simple content display where your use cases consist of browsing, search, emailing an article to a friend and viewing an article in printable form. Four use cases, give or take. Add in the occasional submission form, and your support team, such as it is, barely needs to break a sweat. Applications, if I may state the blindingly obvious, have many more use cases and thus much greater support costs.

Now at what stage does a site become an application? This is sort of like the riddle of Theseus' ship. (Theseus was the guy who slew the Cretan Minotaur.) His ship was preserved as a memorial. As planks and other wood rotted, it was replaced bit by bit until not one piece of the ship was original. Was it still the same ship? If not, at what point did it stop being the same ship? Fortunately for us, our question is not quite as hard. Ours is not a question of identity but of degree. A site doesn't magically become an application with one additional use case, it just becomes more complex. In fact, our distinction earlier between sites and applications was a false one -- a site is a simple application, with a simple purpose and simple task flows.

Now I started this post talking about support costs and ended up talking about wooden planks. My point is that as you go about replacing the rotted postback planks in your site or application with nice new pressure treated Ajax planks, keep and eye out for feature creep. Are you adding functionality to your site? Are you adding digg style voting to your content? Are you adding a portal so users can customize their experience? I'm not saying don't add them. By all means, take advantage of the opportunities the technologies give you, just be cognizant of any new features and use cases you add. You could find yourself sucked from the relatively safety of the content application -- or "site" -- to the deep water of the full on application.

When they pry the support pager from you cold, dead hands, you'll go to that Valhalla that is home to optimists, jaywalkers, chronic underestimators, and managers that think that product launch is the finish line.

Technorati : ajax, editorial