I really like the picture (by Reimar Juul) and the fact that the article mentions both Justaddwater.dk and Copenhagen Ruby Brigade. Woot!

Click image to view larger version

For the benefit of the Danish speaking readers, I really want to include the entire text from the article here to make it searchable and quotable for the benefit of everybody who is also interested in Ruby on Rails for enterprise use. Currently I’m awaiting permission from Børsen to include the article here. Also, I’m awaiting a direct link to the Børsen article if you like to read it in it’s original domain.

Further information:

• Today’s Newspaper Børsen: avis.borsen.dk, page 47 (requires login/authentication). Link is probably only working today. Capgemini Nordic resources probably have access through corporate intranet via our IP number.
• Børsen article Alternative link (containing the date 2007-02-13) (probably also requires login/authentication)
• Justaddwater.dk: Ruby on Rails as rapid prototyping tool
• Justaddwater.dk: category “businesscase”
• Copenhagen Ruby Brigade (copenhagenrb.dk)

Technorati Tags: justaddwater, ruby on rails, rails, interview, newspaper, showcase, capgemini, thomas watson, jesper rønn-jensen

From the mail:

Joel Spolsky wrote about the choice of implementation technology for enterprise projects, making two great points:

(*) There are three platforms that are all known to work, so pick one of them, avoiding the fancy, but risky ones that don’t have a sufficient ecosystem.

(*) As long as you use one of the safe platforms, success or failure of your project will not be due to which technology you chose, so go with the one your software architect knows the best.

> http://www.joelonsoftware.com/items/2006/09/01.html

Joel’s second point matches with our findings from intranet portal projects: what makes a good portal is not the technology (they all suck), but how you fit the tech to your company’s needs:

> http://www.nngroup.com/reports/intranet/portals

Unfortunately there is no newsletter archive available for his newsletters. This is not a violation of any of his usability guidelines, but there will probably be no guideline for it before he has an archive up and running — Linkrot for email content is almost as bad as linkrot on the web, I guess.

Please ignore for a moment the way the story ends in a selling proposal for one of the portal studies. The most interesting about this story is actually not here! David Heinemeier Hansson commented on Joels story with some making some brilliant (and fun) points about Joel’s article.

Joel finishes off with a prize so good you can’t help but wonder if he’s pulling your leg or not. So in summary, Ruby and Rails are both immature, right? A decade for the language, two-something years for the framework. Tens, if not hundreds, of thousands of programmers exposed between the two. Okay, I buy that this could be seen as “immature” if you’re into comparing quantity of programmers or deployed applications against, say, Java or PHP.

Now strap yourself in and reach the final paragraph:

FogBugz is written in Wasabi, a very advanced, functional-programming dialect of Basic with closures and lambdas and Rails-like active records that can be compiled down to VBScript, JavaScript, PHP4 or PHP5. Wasabi is a private, in-house language written by one of our best developers that is optimized specifically for developing FogBugz; the Wasabi compiler itself is written in C#.

So Joel and friends invented their own language, which has to reasonably compile to three and a half different ones. Yes, they’re building their Serious Business Stuff application on a 1-off, closed language. So please do as I say, not as I do, dammit. And pick something mainstream and “safe”.

I swear I couldn’t make this stuff up even if I tried. Joel, you’re my new hero of irony. And as soon as you start selling those t-shirts with “Serious Business Stuff”, I got green ready to flow. Short of that, I’d take a red teddy bear with the embroidering “Someone is Going to Get Fired”.

Jakob Nielsen puts the discussion above in perspective. I really enjoy David’s reflections that are going in a completely other direction than Jakob Nielsen’s (who seems focused on ending his reflections with a selling proposal of his own material).

Ruby on Rails for enterprise use

The point David touches here is whether you could consider an “Immature” technology in the enterprise. Joel and David seem to disagree on this point. And Joel seems to disagree with himself. For the case of Ruby on Rails considered immature for the enterprise, i strongly disagree.
As I wrote previously, Ruby on Rails has proven to deliver:

• Very high fidelity prototypes that can use real data. The high fidelity give much better findings in usability testing.
• Consistent productivity gains compared to any other prototyping tool.
• Very few lines of code makes it easy to change prototype.
• Doesn’t have to be thrown away after building prototype.

This is not only about prototypes: Massive productivity gains between 2 and 20 times faster development alone should make you consider Rails before other alternatives. The community around Rails is massive compared to other frameworks, and I see there is a strong will to make it even better, increase quality, performance and ease of use (even though I consider Rails to be way in front of competition on this point).

Further reading:

• DHH: Fear, Uncertain, and Doubt by Joel Spolsky
• Joel Spolsky: Language Wars
• Justaddwater: Ruby on Rails for the enterprise: Business perspective
• Justaddwater: Ruby on Rails as rapid prototyping tool

Technorati Tags: jakob nielsen, joel spolsky, david heinemeier hansson, ruby on rails, joelonsoftware, businesscase, business case, railsconf

Watir stands for “Web Application Testing in Ruby”, you write a few lines of Ruby that fires up Internet Explorer, and then clicks around, fills in form fields, submits, etc.

My colleague used a couple of hours to write a few lines to integration test a complex system for a financial customer. He modified it to repeat the same test in three different environments and via timers found out that one of the environments performed very badly.

I saw my colleague demo it yesterday, and both testers and developers present were absolutely impressed by the jar-dropping demo. Comments: “We could have used this much earlier”, “Despite that I don’t know Ruby, It’s easy to understand what it does”. Everybody in the project room went around smiling (David Heinemeier would probably say “happy”)

It’s nothing new that automated browser testing can be done, but when I ask about the alternatives, I’m told that they’re too complex to get started with, and sometimes take forever to set up.

Watir gets started with just four lines of code:

In my opinion, Watir + Ruby is a winnner. So easy to get started. So great payoff for a small amount of time invested. Jaw-dropping reactions on developers and testers that don’t even know Ruby. It’s a definite winner.

Technorati Tags: ruby, enterprise, business case, watir

As I wrote previously, Ruby on Rails has proven to deliver:

• Very high fidelity prototypes that can use real data. The high fidelity give much better findings in usability testing.
• Consistent productivity gains compared to any other prototyping tool.
• Very few lines of code makes it easy to change prototype.
• Doesn’t have to be thrown away after building prototype.

But this was focused mostly on rapid prototyping as an obvious sweetspot for Rails. Here are the other articles I found for this roundup:

Mentalized.net: One day with Scott Raymond by Jacob Skjerning

Thursday marked a major step on the path to exploring Rails as an alternative for BiQ. As I’ve mentioned earlier I’ve been looking for someone to come and present Rails for us.

[...]

The advice that in particular struck a chord with me was a pragmatic “fail fast” advice. Dig into the meaty parts, get your fears out of the way, or fail now, before you’ve spent months with nothing to show for it.

Monday will hear the decision of wether we’ll move ahead. Currently, I have no reason to believe otherwise.

Their task is to consider rewriting an ASP/VBScript system:

At the day job I’m the sole developer and maintainer of a legacy ASP/VBScript system. Yes, ASP/VBScript. No, not .NET. And yes, it’s driving me insane. The code contains around 42000 lines of VBSCript drivel and 30000 lines of supporting Python code.

The other day I told my boss that I thought we should really, really consider rewriting the application. The existing one is getting cumbersome, hard to maintain, and let’s face it; it’s sucking my soul dry. My suggestion for a new platform is, for a lot of reasons, Ruby on Rails.

Ruby on Rails is web2.0 on rocket fuel by Dion Hinchcliffe:

I could spend a lot more time talking about the details of Ruby and Ruby on Rails but the important point to take away is that it puts extreme power in the hands of the average Web developer by collapsing the common tasks from literally days to just hours or even minutes in some cases. I’ve seen some of the demonstrations in person (most recently Hansson’s talk at Real-World Ajax) and am continually impressed by how fast and easily that working software can be created with Rails. Creating blog or wiki software from scratch can literally take just a few minutes.

Web 2.0 software development has its own set of expectations and best practices: rapid feature evolution, real-time feature monitoring, all functionality available in both the GUI and as Web services so others can use them in their own apps, and more. Rails makes all of these easy to do using one of the highest productivity languages out there. That’s not to say Rails is perfect, it’s so new it couldn’t possibly be fault-free, but there is clear evidence today of its reliability, scalability and ease-of-use (once you get past a brief learning curve.)

Ruby on Rails enterprise ready? by Jon Mountjoy:

Something else that’s interesting is that issues like this [distributed transactions] are not stopping adoption of Rails. Companies like 37signals are forging ahead creating great solutions, deployed and live. Obviously Rails is “good enough” – its lack of many enterprise features, distributed transactions being another important one, doesn’t prevent adoption. Perhaps 37signals do something funky with their database connection handling, or perhaps it just doesn’t matter for the vast majority of applications out there. I suspect that the latter is closer to the truth.

In J2EE land we tend to focus on solving the difficult problems, instead of making the easy problems easier to code. This is one of the biggest lessons that J2EE can learn from Rails – productivity.

Ruby on Rails from a Business Perspective via The Case for Rails: Talking to Management

It also helps that Ruby on Rails can crank out a system in about 1/3rd of the time as PHP, but that’s probably my own coding preferences talking.

Business case for Ruby on Rails vs. Java by Obie Fernandez (via Curt Hibbs)

Want a realistic example of what I’m describing? Two well-respected consultancies find themselves competing head-to-head for a project: a fairly typical internal web application, of the type that large corporate clients often request. Both consultancies follow Agile practices. Timely delivery for this project is critical (as usual), but delivering on-time is particularly important in this case. The client will get hit with severe regulatory penalties if the new system is not implemented within a year’s time.

The decision makers at Consultancy A propose a Java-based solution at a price of a million dollars, and they estimate final delivery within 10 months. Their bid is competitively-priced and they feel confident about it. They plan to allocate an experienced team using a mature platform (Java). They calculate, using rough figures, that 6 resources x $97 blended hourly rate x 10 months equals about $1MM, a gross margin of about 25%. A higher margin would be better, but all-in-all this deal is not too shabby.

The folks at Consultancy B also have extensive experience building the kind of webapp needed and they see a potential productivity arbitrage play. Instead of Java, they differentiate themselves by pitching a Ruby on Rails solution. Quite innocently, they undercut their competition by pricing their bid at $800K and promising delivery within 6 months. According to their calculations, (and once again, these are rough figures), 4 resources x $192 rate x 8 months equals about $800k. That rate ($192) represents a much higher gross margin, even taking into account that Consultancy B pays its consultants higher salaries.

Can you guess who won? Consultancy B won! At the contract signing, the client CIO says that it was a “no brainer” and lists the following reasons in order of increasing importance…

Thoughtworks (US technology consultants Martin Fowler, Obie Fernandez, etc.) mentions quite a few advantages on their technology page:

Our ongoing project work with Ruby and Rails proves that Ruby excels in the following applications:

• Web 2.0 applications that make use of REST and/or AJAX designs
• Small to medium Web-based applications with aggressive time-to-market goals
• Low-cost internal prototypes and pilot applications
• Highly-targeted internal applications and utility programs
• So-called ‘soft layer’ APIs on hardened transactional systems
• Build systems for complex enterprise systems

Justaddwater.dk Ruby on Rails as rapid prototyping tool by me:

At my work in Capgemini Denmark, we have used Rails for some months at work projects and it has proven to deliver:

• Very high fidelity prototypes that can use real data. The high fidelity give much better findings in usability testing.
• Consistent productivity gains compared to any other prototyping tool.
• Very few lines of code makes it easy to change prototype.
• Doesn’t have to be thrown away after building prototype.

Consider the fact that Rails can actually live on in the application development. I believe that Rails is a perfect match for making rapid prototype development. Also this approach is what Garret Dimon invented “just build it“, and it fits like a glove with the agile approach of the guys at 37signals.

Real world sucess stories: List of web applications running Ruby on Rails, and another list of Ruby apps (web applications at the bottom).

Do you know of any relevant articles out there? Please add to my list. I’m mostly looking for the not-so-technical and management targeted.

Vaguely related, the final word is from my blogging partner Thomas Watson, currently at JavaOne in San Fransisco, took this photo near the Golden Gate Bridge:

Sure hope that not everybody will follow the advice of San Fransisco Authorities to keep off Ruby on Rails.

Technorati Tags: ruby on rails, business case, enterprise

May 19 I’m speaking about rapid prototyping to make usability testing earlier and more often. The focus will be on the benefits and the business value user testing creates early in the process, so at this event, there’s really no focus on Ruby on Rails as the prototyping tool (but you can refer to my earlier post about that).
From Snitker & Co’s newsletter that is sent out today: (in Danish)

Gå-klogere-hjem møde fredag den 19. maj kl 13.30-15.30
Nye metoder:

Prototype-drevet udvikling der øger forretningsforståelsen — og brugeroplevelsen

Jesper Rønn-Jensen fortæller om et værktøj, der kan bygge prototyper op til 10 gange hurtigere – med følgende fordele:

• Flyt fokus fra corporate experience (hvad afsendervirksomheden ønsker) til user experience (hvad brugerne kommer til at opleve)
• Flyt fokus fra en papirprototype til en kørende applikation
• Nedbring fasen fra idé til testklar prototype fra måneder til få dage

Jesper Rønn-Jensen arbejder til dagligt i Capgemini og står sammen med Thomas Watson bag webloggen justaddwater.dk. Præsentationen er en snig-premiere på Jespers præsentation på reboot8 den 1. juni.

Gå-klogere-hjem-møder:
- handler om alt det vi er interesserede i (ok, om noget af det)
- er gratis
- tilmelding er nødvendig (vi har plads til 25) på thomas@snitker.com
- foregår i Bredgade 21B
- fredage fra kl 13.30 -15.30
- og ja der er kaffe.

Vel mødt!
Snitker & Co.

You can subscribe to Snitker’s newsletter and I think that you can still make it if you want to see the upcoming newsletter that the announcement above is taken from.

UPDATE: Link to webpage of Snitkers newsletter.

I’ll update this post later with a translation of the announcement.

I’d love to see a comment on what you think about this event.

Technorati Tags: event, speaking, presentation, usability testing, rapid prototyping, ruby on rails, snitker, business case

First time I heard about Ruby on Rails was when David Heinemeier Hansson, Jason Fried and Ryan Singer presented the “Building of Basecamp” workshop in Denmark June 2005. Basecamp was the project that sparked the development of the Ruby on Rails framework.

I recognize the reaction that Deane of gadgetopia describes:

So what was the biggest shock of the Basecamp seminar? Finding out that it was written in Ruby. Yeah, that’s right — that Japanese language that you thought no one was using. They’ve apparently put together a Web development framework for it which they’re releasing to open-source.

(from www.gadgetopia.com June 25, 2004)

I was immediately interested in the possibility of using Rails as a productivity tool, where in some cases a Rails application can be developed up to ten times faster than a similar Java or .Net application. Very promising.

Prototyping satisfaction survey

I’ve tried a lot of different prototyping tools: Paper, Photoshop, Powerpoint, Dreamweaver, HTML. Until Rails I was perfectly happy with HTML prototypes: I consider them easy to maintain, fast to produce, possible to search and replace during development.

My experience goes pretty well with the 2002 GUUUI survey where 52 people replied on their preferred prototyping tool and their satisfaction with it (people preferring HTML were the most happy with their tool).

Source 2002 GUUUI survey on prototyping tools.

Enter ruby on Rails

One thing I miss in HTML prototyping is the lack of real data. For instance, a user enters a date on one page. On the next page, the date is hardcoded. Chances are that users at a user test enter values that are different from what I hardcoded on the screen. Here Rails is perfect. In stead of building screens, we build the application front-end.

At my work in Capgemini Denmark, we have used Rails for some months at work projects and it has proven to deliver:

• Very high fidelity prototypes that can use real data. The high fidelity give much better findings in usability testing.
• Consistent productivity gains compared to any other prototyping tool.
• Very few lines of code makes it easy to change prototype.
• Doesn’t have to be thrown away after building prototype.

Consider the fact that Rails can actually live on in the application development. I believe that Rails is a perfect match for making rapid prototype development. Also this approach is what Garret Dimon invented “just build it“, and it fits like a glove with the agile approach of the guys at 37signals.

Whats your thoughts on this? What tools would you use for prototyping?

• Digital Web Magazine: Just Build It: HTML Prototyping and Agile Development
• Garrett Dimon: AJAX & DOM Scripting: Just Build It
• 37signals: Getting Real, Step 1: No Functional Spec
• Particletree: A Designer’s Guide to Prototyping Ajax
• GUUI: 2002 survey on prototyping tools

Technorati Tags: prototyping, html, ruby on rails, business case, capgemini, productivity

Anyways, I want to give you some of the details on why we decided to implement AJAX validations in this particular web application. I worked on a project for a Danish company in the financial sector. We had a complex interface where the user had to enter a lot of information about a lot of users. This is illustrated here with user #1, #2, and so on.

In this particular solution, the typical usage scenario is that an employee has data about multiple users to enter: That could for example be name, age, social security numbers etc.

Edit one object at a time

We originally looked at two different interaction models. Version 1 where the employee could edit one user at a time, and then go back to the main page, as shown below. I really can’t show the webpages used, but here is a sketch that shows the principle.

So, the employee clicks link to edit user #1, then back and continue to #2 etc. This was the standard setup of our development framework: Microsoft ASP.NET 1.1.

To edit one object at a time has some advantages:

• Very low development costs: ASP.NET framework out-of-the-box
• Data is saved while editing one user at a time.
• Focus on one object at a time: You can only edit one and only continue when that single object is edited and has no errors.

On the same time it is also annoying for users in certain situations if they’re not allowed to continue until all errors are solved and all required data is filled in.

I see two big disadvantage in this model:

• It requires a lot of clicks. Click to edit user #1, back to link page, click to edit user#2, etc. This is so-called “pogosticking“.
  Extra clicks yields extra time and thus … lower performance (XX todo: usability)
• Only to be able to edit one user at a time could be annoying under some conditions. It’s like an Excel spreadsheet where you can only edit one row at a time — It will work, but could be cumbersome when editing in a particular column.

So besides the expected extra time consumption, the real problem here is when data is entered in a non-linear way. To stay in the Excel example, if we decide to organize by rows, then what will happen if the user wants to edit columns: It will be absolutely cumbersome.

A few interviews and meetings later, we decided that this was not a solution that the end users could benefit from: Too cumbersome.

Edit multiple objects at the same time

In this scenario, we decided to support easier editing of all objects at a time. Like in the Excel metaphor it will be possible to edit by row or by column.

Some advantages of this screen layout:

• Significantly faster task completion (faster to fill out the form)
• Less pogosticking and therefore less back-and-forth navigation
• Easier to edit non-linear: In a prefilled form, it will be easy to edit just a few fields.

All in all: Easier to use, less navigation and faster completion of the form.
In the usability tests I’ve participated in, users always make errors, typos, misconceptions, etc. The real timesaver in this example are the AJAX field validations.

AJAX validations the big time-saver

For validations on the page, we wanted the application to validate each input field immediately. When the user moves on to the next field, the field value is sent back to the web server and validated. If field contents are not recognized, print an error message below field and set red background color on field.

This way, we give the user feedback as soon as possible without interrupting users work.

• Unobtrusive error messages (users decide when to correct the error)
• Error messages occur where errors occur
• Preserves the benefits from multiple edit

Also, in this way, we do all validations server-side. Here, fields appear to be validated client-side, but behind the scenes, field data is sent to the webserver. This means that no JavaScript validations have to be coded (which I usually see as a time-consuming task).

For security reasons, we always have to code server-side validations. In this way, we only code validations on the webserver, but use them on the client-side, which in this particular project is a big time-saver. For instance, there is a date field that only accepts days on which banks are open. This calculation is fairly complex for Danish companies because bank holidays tend to move every year. For this particular project, it might end with a database table lookup, so the validation would be impossible (or very expensive) using JavaScript.

Conclusion

The reasons we choose AJAX validations for this particular project are:

• Lower development costs: Only server-side validations had to be coded. These validations can then be executed client-side via the AJAX framework. Depending on browser compatibility, we have probably saved 20-40% of the time it took writing the server-side validations.
• Faster user interface: No unnessecary navigation back-and-forth to fill out data on multiple objects.
• Unobtrusive error handling: Errors can be corrected immediately and in an un-obtrusive way: The user can continue typing in other fields or correct errors as they happen. Compare this to the old variant, where an alertbox is triggered. Alertboxes say “correct me NOW before you do anything else”.

These are the details I can share with you, and it certainly does not fulfill the wishes of Andre Charland, Ebusiness-Apps who’s Looking for More AJAX Case Studies.

Technorati Tags: usabililty, ajax validation, javascript, interaction design, ASP.Net, AJAX.Net, business case

On January 10th, 2006, MacRumors.com successfully delivered live updates of the Macworld San Francisco Keynote speech to over 100,000 people simultaneously using the latest web technologies.

“By far the best mac keynote coverage I have ever seen. No constant page refreshing. No ‘page will update every three minutes’ even though they never do. I just let the page update every minute like it was supposed to. It was actually weird to get coverage without some sort of connection failure.” – MacRumors member, war

The live coverage web solution is basically a transscript updated frequently during the keynote. One article is about the traffic they experienced:

Our site was linked to widely across the web, including prominent links from Digg and Slashdot — two popular technology sites. These links caused no noticable “spike” in our number of visitors, illustrating the magnitude of traffic that MacRumorsLive was already receiving.

We peaked at approximately 103,000 simultaneous web visitors and 6,000 IRC viewers during the Keynote speech and transmited over 32 GB of data in a three hour period. If not for the efficiency of the MacRumorsLive AJAX update system, the same webcast would have required approximately twice as many servers and would have had to transfer almost 6 times as much data (196 GB).

With peak loads that reaches insane levels of almost 4,000 hits per second:

Hits/second (2)	3,812
IRC users	6,079
Simultaneous visitors	109,000
Bandwidth (3)	approx. 77Mbit/sec

They also posted an article about how they built the system which is insanely interesting

Traditionally, websites have coped with visitors during the keynotes by swapping to text-only pages, using HTML Meta Refresh to reload the page at set intervals, usually every three minutes, for example, MacRumors’ coverage from MacWorld in January 2005. As a result, the sites lose their identity and branding, and cannot make best use of the additional traffic for site promotion.

Even with all this simplification the sheer number of visitors can still take the server down. To provide the best coverage during live events an improved system is required.

As this system is retaining the normal layout of the site, all the necessary objects (CSS, images & Javascript) also need to be loaded. This increases the load placed on the web servers considerably in comparison to the old system, which only had a single text file to display. Even with the ability to use multiple servers, the web server software needs to be improved.

By using PHP to generate the necessary HTML & XML files every ten seconds, rather than each time the file is requested, it is possible to use small & simple web servers to deliver the public site, without the overhead of database usage. Two web server software packages are employed – lighttpd and thttpd – with Apache still being used for the administration interface.

The efficiency of these packages over Apache is considerable and allows quite modest hardware to be used to serve a large number of visitors. Benchmarks of lighttpd compared to various other packages can be found on their website. In our tests, thttpd was able to sustain in excess of 3,300 hits per second, whereas Apache managed only 600 hits per second for 20 seconds, before overloading the server due to memory usage. [1]

The use of these more specialised web servers allows a vast number of simultaneous visitors to be supported – as the system stands at the moment, in excess of 200,000.

This reminds me of Ajaxinfo (the guys behind AJAX usability metrics), AJAX ROI faceoff, where a traditional webapp is compared to an AJAX webapp. For the visually oriented, there is a video comparing the two applications at the end of the article.

Recently on Developer.com, I looked at ways for developers to communicate the value of Ajax in dollars and cents. Arguing for or against a technology usually creates some stress for developers, who tend to speak a different language from business decision makers.

Developers talk about Usability Bandwidth Ramp-up Cost of Ownership

Managers talk about Efficiency Transaction costs Training costs Return on Investment (ROI)

Right at the point. Performance website or not, the metrics he mentions above are almost like something Jakob Nielsen could have done. Conclusions:

Although every new technology should be greeted with a healthy amount of skepticism, there are clearly demonstrable, quantifiable advantages to using an Ajax architecture in a Web application. These cost savings originate primarily from time savings, but also from reductions in bandwidth requirements.

A representative test case showed that a business can save between 500 and 2,800 man hours per year on a 10-step hypothetical process, saving roughly 4 seconds per step (a between 30% and 70% reduction in labor costs).

Although the benefits of improved application architecture extend beyond mere time savings, when included in the decision making process, an ROI approach such as this can help make a solid business case for Ajax.

The benefits listed here are very similar to benefits when we’re arguing for web-standards: Reduced bandwith, training costs, cost of ownership, and increased return on investment. But for the time being I still believe that AJAX has increased learning costs for developers. (Although most developers are really keen on using AJAX and webstandards it still requires expert knowledge regarding libraries, backend integration and browser compatibility — to name a few).
I’d be happy to hear your comments on this. Please share more info here. Also check out Ajaxinfo’s Call for AJAX Studies.

UPDATE: Just saw Jonathan Boutelle’s Bandwidth Savings with AJAX blog post, that covers the same story and has a good point on AJAX fit frequently used applications:

The old-school RIA technology vendors always made the claim that using the RIA paradigm saves you bandwidth. Numbers on this were always hard to get, and hard to trust.

Theoretically it always made sense that an RIA would consume less bandwidth (in exchange for a larger initial download). The longer a user continues to use the application, the greater this benefit (so an RIA word processor might make more sense than an RIA news site).

Now, watching a keynote presentation takes at least an hour, so it’s definitely long enough to provide benefit. What we see in this case is really different though: AJAX is basically being used as a broadcast technique, grabbing new data every minute so that the user doesn’t have to refresh the entire page. For covering live events that have a large audience, this makes a ton of sense. Expect to see more content sites “pushing” content out to their users this way.

Technorati Tags: macrumor, ajax, performance, ajaxian, macworld, architecture, webdevelopment