By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Find out why internal apps are ripe for replacement with Ajax-based apps, what common mistakes users make when debugging apps and where you can find helpful toolkits for simplifying Ajax development.
How can corporate IT managers use Ajax in their workday lives?
Eichorn: Ajax is a great solution for internal applications. Environment control lets you reduce the complexity of Ajax development and high speed networks remove any latency-related performance problems. This makes internal applications a good target for Ajax-powered usability improvements. Just upgrading any multi-process search selection process to a Google Suggest style, search-as-you-type dropdown will save you large amounts of time on a daily basis.
What are the advantages for IT managers of working with Ajax applications versus non-Ajax apps?
Eichorn: The biggest advantage is that Ajax opens up a new set of problems to Web-based applications. The rich user interface and easy access to large datasets makes it possible to replace the last holdout Visual Basic applications with easy to manage, upgradeable Web-based applications.
Ajax-powered user interfaces can also dramatically improve the usability of Web-based applications which, in turn, improves productivity.
Could you offer some basic tips for determining when a non-Ajax app would benefit from having Ajax technologies added to it?
Eichorn: When deciding to add Ajax technologies to an existing application, I normally start with a review of what the application does. The biggest targets are slow, multi-step processes and interactions with large datasets. Any time you're creating a pop-up window to accomplish a task, you'll normally have a good target for Ajax usage.
My overall rule is to see if completing a task in the application take too long time complete. If that's true, then I look to see if the slowness is related to the accessibility of application data. If that's the truth, then you have a good target for Ajax.
In your book, you offer a start-to-finish update of a non-Ajax app. What are some key processes in this update approach?
Eichorn: Identify areas where adding Ajax would have the greatest benefit. Pick a library or libraries that will provide the tools to you need to implement your chosen targets. Implement any back end changes that are needed. Test those changes before adding in the Ajax Update. Let the end users review the usability of your changes and add in visual queues. Provide feedback to your users so they know what is going on.
What are your three favorite toolkits for simplifying Ajax development?
What are the most common mistakes people make when debugging Ajax?
Do you see Ajax technologies expanding outside of Web app development in the future? If so, how?
Eichorn: The basic focus of Ajax is adding an invisible communications channel between the server and the client. From that perspective, Ajax really isn't anything new. Client-server applications have been doing that for years.
But Ajax does allow you to build service-oriented applications where much of the application state and logic fit in the browser, and the server just exports a generic set of operations that can be consumed by any client. This idea is a lot broader than Ajax. If you use Ajax to implement SOA applications in your browser, I think you'll also follow that same pattern into your thick application development.
Did you find this tip helpful? What tips would you like to see? Email us and let us know!