The Non-Techie Manager's Introduction to AJAX
An explanation for people who don't know or care about programming.
By Tiffany LeFargebuzzword generator, coming up with terms which, to all appearances, exists only to make the speaker incomprehensible. The developers clearly enjoy trotting out the new jargon during business meetings, especially those in which they propose the company dump the technology the tech team ballyhooed last year, and demand (demand! the nerve!) a budget for a whole new setup.
Worse: if you don't understand what they're talking about, even their well-meaning "explanations" leave you feeling like you couldn't find a clue at a clue farm during clue mating season. Techies have a nasty habit of diving into the details when all you want is a clear and straightforward definition.
We can't help you understand everything your programmers do; their affection for foosball is beyond our comprehension, too. However, we can bring you up to speed on at least one major trend in software development, called AJAX.
Don't panic: we don't expect you to know anything about programming. This is a short-and-sweet introduction. Its only purpose is to keep your eyes from glazing over, the next time the developers start talking about their latest toy. To achieve that goal, we'll oversimplify -- but you don't want to know more than the basics, anyway.
The shortest summary of AJAX's promise we can give you -- yes, we know you're already late for a meeting -- is that AJAX applications are, or will, blur the distinction between a "desktop application" and a "web application." You won't have the sense of "filling in a form" and waiting for a web site to respond; instead, the application will be as immediate and interactive as the program you use to manage your personal accounting. Or so its enthusiasts say.
A Very Short History
You probably have a vague idea of what is involved in web development. There are a few elements involved:
- the content, i.e the actual data that you see on the screen, such as columns of numbers, product descriptions and photos, or marketing text.
- the presentation of the data, which includes everything from the page's background color to the fonts used to the boxes in which the content appears.
- where the data is stored: on the client (that is, the user's computer) or on the server. The data might be stored on your company network, or it might be data from a partner's or a public site, such as amazon.com or weather.com.
- the format in which the data is kept, which could be anything from a spreadsheet to a dedicated database to files that come from a business partner.
- the rules for managing and updating all the above, which is the whole point of paying a programming staff.
These elements were split up between different departments in your company, over time, especially once the Marketing department realized that they didn't want the programming staff creating the company's web page, and after the CEO saw the developers' idea of Cool Graphics. Developers are left to contend with the data formats (though some companies have the database administrators responsible for this) and with turning business rules ("when the credit card is rejected, we should...") into code. Ideally, in your view, they should accomplish all this over the weekend, but that's another discussion.