Topic: Trends

Flashback: The iPhone and the Early Days of the Web

Dietrich Kappe, Friday, February 5, 2010 @ 3:19 pm

photo credit: B Rosen

I remember my first real grownup and serious web project outside of the university environment. It was 1994 and SSL was a novelty. People were making insane predictions that one day up to $600 million (think Dr. Evil) worth of consumer goods would be sold on the web worldwide. In 2007, just Canadian B2C sales were US$12.9 Billion.

Some folks, especially startups and smaller companies, saw the web as an opportunity to shake up the established order and establish a new sales channel or an entirely new business model. They invested what they could in building the first of what became known as e-commerce sites. Among established players, and some more conservative smaller players, there was initial hostility toward the new medium. When in 1994 I proposed to Ameritech (now part of SBC/AT&T) that they bring their lucrative print yellowpages online, I was run out of Hoffman Estates on a rail.

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development

2009 Prediction – The End of Ajax

Dietrich Kappe, Tuesday, January 6, 2009 @ 4:00 pm

It has been a good run, but Ajax the buzzword will dip below the radar in 2009. That's not to say that we'll all stop writing JavaScript and using XHR in the coming year -- quite the contrary. Full 100% of web applications will incorporate Ajax technologies, we just will use the "Ajax" buzzword less and less, much as "HTML" became just another acronymic noun in the early days of the web. So that's not really controversial.

What's really going to happen in 2009 that will impact all of us RIA developers? The first raft of Ajax-enable webapps will be undergoing maintenance. Supportability is the real test of frameworks, architectures and designs. How easy are they to support? How painful is the life of a maintenance programmer working on a Dojo codebase versus a JQuery codebase?

We've been emphasizing the use of application level MVC frameworks here of late.Why? Because we feel that the best and most sustainable metaphor for RIA's is that of the desktop component GUI, not of the souped up webapp -- client/server making its triumphant return. Without this guiding principle -- that we are writing applications that consume backend services rather than backend services that display interfaces -- we face escalating development and maintenance costs.

I hope then to see two front end web development trends for the coming year:

1. Abstraction away from the underlying browser platform. Widgets, components, whatever you call them; the average front end web developer shouldn't have to tangle with the DOM or low-level browser events.
2. Adoption of application level MVC frameworks like PureMVC. A standard way of wiring up complex GUI's will save us from ourselves. See Swing for a cautionary tale of woe.

What are you predictions for the coming year?

• Digg
• Reddit
• del.icio.us

Comments (2)

Software Development

Ajax and Browsers: Recapitulating the Early Days of Personal Computers

Dietrich Kappe, Friday, December 21, 2007 @ 10:20 am

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

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (1)

Software Development

Blogging from the GWT Conference: GWT as a Replacement for Java Swing Apps

Dietrich Kappe, Tuesday, December 4, 2007 @ 11:44 am

Just here a short while and I've already heard some interesting notions from some hardware vendors (SANS, Firewalls, etc.) about how GWT might be the key to solving their deployment problems. Right now, many of them use Java (write once, run anyware, etc.) to write the desktop administration applications that manage their hardware. But Java is not trivial to package up and deploy for different OS's. Many of these vendors seems to be considering GWT as an alternative, i.e. you get the RIA experience without having to deploy anything past a browser on the client.

More evidence that the browser is being viewed as an application platform, i.e. an operating system.

Technorati Tags: ajax, gwt

• Digg
• Reddit
• del.icio.us

Comments (2)

Software Development

Desktop Applications Dying, Dying…

Dietrich Kappe, Thursday, October 18, 2007 @ 11:07 am

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

• Digg
• Reddit
• del.icio.us

Comments (1)

Software Development

The Desktop Application is Dead…Almost

Dietrich Kappe, Tuesday, October 9, 2007 @ 10:12 am

The report of my death was an exaggeration.

  -- Mark Twain

Why is the desktop GUI dead? Is it dead? Tell it to Microsoft, which still ships enough copies of Office each year to exhaust the capacity of all of the world's toxic waste dumps. So maybe its not totally dead. But in one important respect the desktop GUI is disappearing: the custom app developed for and by small to midsize businesses (SMB's).

Now I have worked in the IT industry as an employee, a contractor, a freelance consultant, and, for last decade, as a partner in a outsourced software product development firm. In that last role, I've had to turn down an unusually large number of projects recently. Why is that?

In a phrase, opportunity cost. Clients come to us with products, existing or new, and we usually agree to work on them for a fee. Sometimes you have to turn down project A because project B is much sexier and you can't do both projects. That has happened a lot of late and mostly with prospective clients looking to develop purely desktop applications. Unless there is a compelling reason, we just can't get excited about a desktop GUI project.

So, by way of eulogy, let me present a numbered list of compelling reasons for developing desktop GUI's instead of Desktop RIA's.

1. It is unwise to expose the application to the outside world. Example: power plant management software.
2. The application calls for integration with custom hardware or mobile devices. Example: scientific software that integrates with custom measurement devices.
3. The application requires fine control of the underlying video/audio hardware. Example: first-person shooters.

That's a pretty short list. Note that there are a number of other applications you wouldn't do as a Desktop RIA, such as grep, but then you wouldn't do that as a Desktop GUI either (yes, yes, there are visual grep tools, but they don't function in quite the way that the easily piped command line grep does). Also, some of the examples above may have Internet integration (think XBox, etc.), but their architecture, runtime and user interface are pretty different from that of your typical Desktop GUI.

Note what isn't on that list: presentation software. I've argued in the past that Powerpoint was the one place in the office productivity universe where the Web 2.0 clones would fail. How many times have you been in a conference room without connectivity? No net? No presentation. But with the Desktop RIA runtimes, browser support and framework support coming out, online/off-line hybrids are becoming possible.

If you can add to the above list, great, but for the most part, I think the Desktop GUI is a vanishing breed.

Technorati Tags: ajax, desktop GUI, desktop RIA

• Digg
• Reddit
• del.icio.us

Comments (1)

Software Development

Switching Back and Forth

Noel Rappin, Tuesday, October 2, 2007 @ 10:59 am

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.

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development

Cognitive Load, Portability and the Superiority of Client-Side Frameworks

Brian Dillard, Tuesday, September 4, 2007 @ 4:59 am

The recent introduction of TrimPath Junction got me to thinking about Dietrich's widely read post on Cognitive Load and the Superiority of Server-Side Ajax GUI Frameworks. GWT's big advantage is that it mobilizes armies of Java programmers to write browser-based applications without having to learn JavaScript. This is clearly of enormous benefit to organizations with lots of Java programmers, few client-side resources, and a burning desire to build powerful webapps. Yet for the similarly huge army of client-side programmers out there, GWT is pretty useless. Why learn a foreign language just to have it translated back into your native tongue?

I haven't yet had a chance to play with TrimPath Junction, but it sounds pretty cool. Using the open-source Helma framework, it offers Rails-style MVC scaffolding in a JavaScript syntax that executes the same code on the client and server. Basically, it's RoR meets Adobe AIR for JavaScript programmers. I hope to give it a test drive soon.

Server-side JavaScript has been around for ages, but it's never really become a common development model. I remember writing ASP Classic apps in server-side JScript back at the turn of the millennium and having people wig out on me. "Why not write in VBScript like everyone else," they'd ask. My answer: "Because I can save time by running the same validation libraries on the client and the server ... and because I can write the entire app in one language." I obviously have no argument with Dietrich's thesis on cognitive load. It's just that my brain features a JavaScript compiler, not a Java one.

GWT is a great piece of engineering that keeps getting better; just check out the new non-beta 1.4 release. But I think there are a lot of advantages to frameworks that mobilize the JavaScript masses to write front-to-back webapps. The same cognitive efficiencies can be achieved, plus client-side programmers already know all the pieces of the UI puzzle. Ask a room of Java developers how to build accessibility and usability into standards-compliant XHTML and CSS. Nine out of 10 wouldn't have a clue.

The other big advantage to developing UI code in its native language is that you can port it to any server platform. With GWT and similar frameworks, you've got to rebuild much of your UI from scratch if you want to change course in mid-stream. With purely client-side frameworks such as Prototype, jQuery, YUI or MooTools, switching libraries may entail rewiring some of your code to a new API. But switching server platforms, from J2EE to .Net to PHP to RoR, can be done without much work at the UI layer. "The right tool for the right job" is a truism for a reason. Pure client-side development of UI code allows for the development of reusable components whose only dependency is on the standards bodies and browser vendors who control JS, CSS and HTML. GWT and its peers are useful for some teams and some projects, but they're not the only answer to webapp development.

• Digg
• Reddit
• del.icio.us

Comments (1)

Software Development

Some Thoughts on Silverlight

Dietrich Kappe, Thursday, July 12, 2007 @ 10:38 am

I'm not going to dig into the how and why of Silverlight, or write an inflamatory article bashing Microsoft. What I do want to set down are some simple observations on Silverlight. All of us who design RIA's need to keep an eye on emerging technologies, especially if they're backed by the market clout of MS.

So, what is Silverlight, and why should you care? It's has been described as Microsoft's Flash, but that misses the point just a bit. First, from the MS marketing droids:

Microsoft Silverlight is a cross-browser, cross-platform plug-in for delivering the next generation of .NET based media experiences and rich interactive applications for the Web. Silverlight offers a flexible programming model that supports AJAX, VB, C#, Python, and Ruby, and integrates with existing Web applications.

Lovely. Cross-browser and cross-platform (Windows and Mac). File that away for future reference. For a better explanation, we can go to a report from Mix 07 from Miguel de Icaza (a mono project contributor):

Silverlight 1.0 uses a retained graphics system (a canvas) that exposes the internal structure to the browser DOM. It has no scripting capabilities built into it, all the scripting support is actually done by the Javascript interpreter in the browser and all changes are done by talking to a Javascript object exposed by the hosted Silverlight surface.

The scene definition is done using the XAML markup using a subset of the WPF primitives available in the full-blown WPF. Then the big announcement came:

The second edition was Silverlight 1.1, and this one is a different beast altogether. 1.1 extends the model by embedding a complete Common Language Runtime.

That's right, the dreaded CLR , the JVM of the .NET world, in your browser. The CLR, of course, is supposed to support many different languages, and so VB, C#, Ruby, Python, Javascript, etc., etc., are all supposed to be supported eventually in Silverlight. With the Dynamic Language Runtime (DLR), scripts can even be embedded in the page and compiled at runtime. In venture capital there is a saying that "too soon is the same thing as wrong"; let us all shed a tear as Java applets are carted off to the dumpster.

There's lots more research to do on this, but I have neglected the second question: why should you care? The obvious answer is that Silverlight doesn't just compete with Flash, but also with Ajax. Silverlight also seems to have more hooks into the browser (definitely some security research needs to be done there), so it is possible that it can be more of a complement to Ajax than Flash has been.

But looking beyond the next 12 months, it is clear that Silverlight will be part of MS's solution for Desktop RIA's, i.e. the emerging online/offline application space represented by Apollo/AIR, Google Gears, Firefox 3 (with it's embedded RDBMS), etc. Another thing that becomes clear is that language support and performance are likely to become more important, i.e. we need to be able to develop in more than just Javascript/ActionScript for the browser and Flash. And the performance of those browser runtimes needs to improve drastically to support the large and sophisticated client-side (ooh, the return of the fat client) apps that are likely to be developed.

GWT addresses some of those issues, as does the commercial product from Morfik. For performance, the inclusion of the Tamarin VM (kindly donated by Adobe) in future versions of Firefox will address some of the performance issues, but at the end of the day that is less than half the equation. If MS doesn't improve IE (where's the announcements about IE8?), Ajax apps will still perform like crap on over half of all browsers.

Last idea for the moment on Silverlight. Will OpenLaszlo target their framework to compile for Silverlight? Since they are the one group that actually targets their framework at more than one runtime (Ajax and Flash), they are well positioned to do the same for Silverlight. Stay tuned.

Technorati Tags: ajax, flash, silverlight, openlaszlo, mono

• Digg
• Reddit
• del.icio.us

Comments (3)

Software Development

YouTube Killed the Video Star

Dietrich Kappe, Thursday, July 5, 2007 @ 6:00 am

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

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development

More CMS and Ajax – What About CDS?

Dietrich Kappe, Wednesday, September 27, 2006 @ 12:17 pm

We talked about CMS and Ajax back in June, so I thought it was about time to see what had transpired in the world of CMS. Back then, it seemed that the CMS side (Content Management, i.e. the part your editors and authors use) had the most immediate promise for using Ajax, but that the CDS side (Content Display, i.e. the part that the actual readers see) was a different matter, with lots of headaches for managing scripts, style sheets and interactions. In essence, the domain model for most of these CMS's out there does not account for the fine-grained interactions of Ajax on the CDS side.

So, what are some of the more noteworthy developments for CMS and Ajax? All of the commercial vendors I've checked with, Interwoven, etc., have either added or are planning to add Ajax to their CMS apps, but not CDS so far. Beyond that, here are some highlights:

1. MODx, a CMS and PHP application framework has been getting lots of press. The actual "Ajaxiness" of the app seems a little limited. And by their own admission, their focus is to introduce more of it into the CMS side, i.e. the "Manager" rather than the CDS. It does have "live search" and some Ajax powered voting, however.
   
   

   MODx is the first free PHP CMS to offer an API that fully supports Web 2.0 Ajax technology thanks to script.aculo.us. Expect to see this grow more and more into our manager over time, but you can make use of it today in your own custom applications including live search, web effects, Ajax communications and more.

2. Micro CMS v.3.5 is a commercial CMS that also touts it's Ajax capabilities, again in the CMS side.
3. Skeletonz is another CMS where the manager interface features AJAX and the CDS does not. This one is written in Python.
4. MuraveyWeb, a Ruby on Rails CMS, seems to have closed up shop. The original files are still available on RubyForge.
5. MooFlex CMS Demo - just a demo at this point. Not much more info than the Ajaxian article. I'd expect a little more Ajax in the actual demo from the Mad4Milk crowd.
6. The Drupal CMS project has been busy adding Ajax to its CMS and CDS according to this levelheaded Ajax manifesto. They've settled on JQuery for their core Ajax library. They seem to be the most aggresive in adding real Ajax to the CDS, such as a real-time chat room. While we're on the topic of JQuery, check out the maiden issue of JQuery Magazine.
7. Ajax Fly is a add in to the Mambo/Joomla Open Source CMS.

So far, I like the looks of Drupal and its Ajax CDS integration. Overall, people seem to be doing rather than thinking. I expect some folks are in stage two of Joe Walker's 4 stages of Ajax Adoption -- progressive enhancement -- while others are already in state three -- the second site. Stay tuned for more on what is likely to be a fast changing Ajax CDS landscape.

Technorati : ajax, cms

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development

Salaries Go Up for Ajax Jobs

Dietrich Kappe, Sunday, September 24, 2006 @ 11:55 am

This survey by IT JobsWatch shows that things are looking up for Javascript programmers. Over the last year, the average salary for Brit Ajax slingers has gone up 33% from £29,375 ($55,853) to £39,228 ($74,588). I'm sure these numbers are representative of trends in many other countries. Based on my own project experience over the last few years, the lowly Javascript programmer has gone from being a servant of the "design team" to a star, whose time is often more valuable than that of the programmers that make up the traditional "application team."

What's ahead for companies that are developing Ajax applications (and at this stage, that seem to be just about everyone)? There are those that will double down on traditional languages and skillsets via Javascript code generators such as GWT. But there will be enough companies going the pure Javascript route to drive up salaries even further. And behind the demand will come the training and certifications, the standards, tools and blessed frameworks, and the army of freshly minted Ajax programmers to fill all of those well compensated jobs. If you're considering selling all of your Java books and moving to a Javascript commune, do it quickly.

Technorati : ajax, jobs, salary

• Digg
• Reddit
• del.icio.us

Comments (2)

Software Development

Digging Behind the Numbers: 3 in 4 Use Ajax

Dietrich Kappe, Wednesday, September 13, 2006 @ 8:00 am

By now you've probably already heard about the SD Times article summarizing a survey by their sister company, BZ Research, that claims that three in four developers have either launched or are planning to launch applications incorporating Ajax. It sounds like Ajax is spreading like a cold in an overworked development team. But you really have to look behind the numbers to understand who is answering the survey and exactly what use they are planning to make of Ajax.

SD Times is targeted at software development managers, so it isn't a developer focused nuts-and-bolts publication. You're mostly talking about corporate IT departments here. Just looking at their table of contents will tell you that they deal more with software business issues -- which vendor is releasing what, who is acquiring whom, what the government is doing about topic X -- and not at all with development, design, and architectural issues. You can almost hear these managers in their weekly status meetings say to their CTO, "yeah, sure, we've got Ajax in there."

So exactly what kind of Ajax is "in there?" A quote from the article is revealing:

"We are looking into using the technology for a Windows-like interface to our embedded system," said Wendi Whitcomb, a senior systems engineer at ZoZo Engineering, while Jeffrey Price, president of Price Performance, explained, "Customers demand desktop application look and feel. Citrix/Terminal server approach [is] becoming cost prohibitive due to licensing costs." Scott Finnerty, technical director of Barkley Evergreen & Partners Interactive, said, "We've embraced Rich Internet Application development as being key to the future of user experience for our clients."

These folks are from a class of companies who want to move their GUI desktop apps to the Web (see 10 Business Reasons to Use Ajax, reason #3). In particular, the number of companies that use Citrix to give remote access to their applications is legion. They most likely have a large development staff with expertise in VB or Visual C++, and were just getting comfortable with .NET when Ajax came along. These people are a long way off from re-architecting and re-implementing their systems as Ajax-based RIA's. It's easy to consider; it's harder to do.

I'm sure another large group of these enthusiastic adopters are those incrementally improving their webapp's user experience by folding edit forms into a single page. The barriers to entry for splicing an XMLHttpRequest into a page are not that high. Their users won't have to make as many clicks to get their work done, but it's a long way off from a true document based, direct manipulation application -- no desktop GUI here. Also, layering another technology like Ajax on top of your creaky struts/J2EE application, has its own hazards for productivity and software quality.

Last, a fair number will be scared off by sheer ignorance:

Security seems to be a common concern, with AJAX being "too much exposed for the client side: Some delegated checking should be double-checked in server, since in the client side it seems to be exposed to crack it," said Paulo Soares, general manager of Central Call.

It's not the Ajax, it's a poorly designed applications that let users persist executable artifacts, such as JavaScript and Flash, which can then be pushed to other users via their browsers, where the compromise occurs. And of course you validate data coming from the client in the server. Why wouldn't you?

What does this survey really tell us? Simply that Ajax has high buzzword awareness, that some major vendors like Microsoft and Tibco are lending credibility to its use, and that certain early adopters such as Google, Digg, and various e-commerce sites, have proven that it can be used to gain a competitive advantage. It's enough to make even a conservative software development manager feel the itch to make plans.

Technorati : ajax, development, security, trends

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development

Punctuated Equilibrium and Ajax Innovation

Dietrich Kappe, Wednesday, August 30, 2006 @ 9:00 am

I remember reading in one of Stephen Jay Gould's books about punctuated equilibrium in evolution. The basic idea is that instead of continuous gradual change, evolution happens rapidly or not all. An illustrative example that is often given is where the less fit individuals in a population reside on the edge of the habitat and, because of the harsh conditions, evolve until they can kick the ass of the previously fitter individuals in the heart of the habitat.

An analogous phenomenon happens in the business world. After World War II, the Soviet Union (and France and Great Britain to a lesser degree) dismantled many factories in the West and East zones of Germany and transported them back as war reparations. As a result, West Germany had to retool its entire industrial infrastructure from scratch, resulting in a competitive advantage over the Allies and the East Bloc, who were stuck with Germany's antiquated prewar factories.

Why the history and biology lesson? I'm sure you all saw the Evans Data Corporation findings that more developers are using Ajax in emerging markets than in North America. According to their survey, Brazil and India lead the pack, while China rivals North America in its adoption of Ajax. These findings pretty much square with my readership data, where Brazil, India, and China outstrip Western and Eastern Europe.

Evans only surveyed 400 developers, which seems too small of a sample to be representative of worldwide development activity. From their methodology discussion:

The EDC panel of developers includes about 20,000 professional developers in more than 70 countries. The EDC panel, having been recruited and assembled over the last five years strictly from neutral developer lists represents the finest example today of an unbiased and representative sample of developers. As the panel continues to grow, the same principle of neutral recruitment will continue to be applied, thus assuring clients of the most representative sample possible.

Still, the results somehow do feel right. The United States, with its proliferation of credit cards, definitely did steal a march on Western Europe and emerging markets in the e-commerce arena, and holds similar leads in investment in other online categories. But heavy investment in legacy technologies begins to look like stockpiles of steam engines and Betamax. While developers in corporate America are busy maintaining existing applications or laboriously retrofitting Ajax onto them, developers from emerging markets are free to start from scratch. And as anyone who has ever maintained a mature web application knows, starting from scratch is often the best way forward.

So while Ajax may have started in the United States, much of the activity and thus the innovation will be happening in emerging markets like Brazil and India. And the United States will continue to retrench until we are left with the one domain where we think we excel above all others: the efficient allocation of capital. Good luck with that.

How does one say "Agile Ajax" in Portuguese?

Technorati : ajax, brazil, china, india, innovation, trends

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development

Business Reason #1 Revisited – ASP’s with Existing Apps

Dietrich Kappe, Monday, August 14, 2006 @ 9:00 am

OK, so it's not called Application Service Provider -- ASP -- anymore. Rather, it's SaaS, or Software as a Service. I suppose that's just as well, since ASP was often confused with the Microsoft's Active Server Pages.

Back in May, in my article 10 Business Reasons to Use AJAX, my number one reason to use Ajax had to do with SaaS's (or SaaS 2.0, as it's called now):

ASP's with existing applications. This ship has already sailed. The ASP's include GMail and Yahoo Mail, but extend to places like Salesforce.com, openair.com, and so on. The lower the switching costs, as in the case of email services, the more vulnerable you are to being overtaken by your slicker, more usable AJAX enabled competition. The argument for the consumers of ASP's is simple: reduced labor costs. If you can save 30 seconds on each operation, the ROI is easy to see.

I thought that it wasn't too early to check in on the progress here. Beyond the SaaS's mentioned above, Google has added the a spreadsheet and acquired Writely. Beyond Salesforce.com, other vendors are in the Ajax mix:

• NSite is building a portfolio of Ajax enabled SaaS tools, including quote and proposal management, channel management and purchase requisitions.
• Netsuite continues to invest in their Ajax based CRM and ERP dashboards.
• The Zoho suite of products now includes a CRM and online surveys.
• PushCRM is another Ajaxified SaaS CRM.
• 24SevenOffice is a European SaaS company offering CRM, ERP, Document Management, Calendering, etc.
• onProject is offering construction scheduling, project management and Sarbanes-Oxley compliance.
• I forgot 37signals and their suite of SaaS apps last time.

This is just the tip of the iceberg, I'm sure. Of course there are a ton of open source products that are incorporating Ajax but aren't technically SaaS, such as Sugar CRM and Zimbra (OK, had Ajax from the beginning), but these could be considered part of the trend.

One thing that hasn't really been considered here is that business has a tendency of getting impatient with IT. If you've ever consulted in the corporate world, you've come across the spreadsheet sneakernet, the MS Access CRM system, or the Visual Basic skunkworks in the marketing department. What happens when a business group decides to collaborate via Google Spreadsheet instead of waiting for IT? Given the hoops you have to jump through (two factor authentication, etc.) to log into a corporate Intranet these days, and the amount of time people spend working via broadband from home or the road, this sort of temptation may just be too great. Who is going to rope this mess in?

Technorati : CRM, ERP, SaaS, ajax, business reasons, trend

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development