Wednesday, February 08, 2006



AJAX, an acronym for Asynchronous JavaScript and XML, is the latest technology buzzword. Asynchronous means that you can make a request to a server via Hypertext Transfer Protocol (HTTP) and continue to process other data while waiting for the response. This means, for example, that you can make calls to a server-side script to retrieve data from a database as XML, send data to a server-side script to be stored in a database, or simply load an XML file to populate pages of your Web site without refreshing the page. However, along with all of the benefits, AJAX sparks some unquestionable debate over issues with the Back button.

Defining Ajax

Ajax isn’t a technology. It’s really several technologies, each flourishing in its own right, coming together in powerful new ways. Ajax incorporates:

• standards-based presentation using XHTML and CSS;
• dynamic display and interaction using the Document Object Model;
• data interchange and manipulation using XML and XSLT;
• asynchronous data retrieval using XMLHttpRequest;
• and JavaScript binding everything together.

The classic web application model works like this: Most user actions in the interface trigger an HTTP request back to a web server. The server does some processing — retrieving data, crunching numbers, talking to various legacy systems — and then returns an HTML page to the client. It’s a model adapted from the Web’s original use as a hypertext medium, but as fans of The Elements of User Experience know, what makes the Web good for hypertext doesn’t necessarily make it good for software applications.

The traditional model for web applications (left) compared to the Ajax model (right).
This approach makes a lot of technical sense, but it doesn’t make for a great user experience. While the server is doing its thing, what’s the user doing? That’s right, waiting. And at every step in a task, the user waits some more.
Obviously, if we were designing the Web from scratch for applications, we wouldn’t make users wait around. Once an interface is loaded, why should the user interaction come to a halt every time the application needs something from the server? In fact, why should the user see the application go to the server at all?

How Ajax is Different

An Ajax application eliminates the start-stop-start-stop nature of interaction on the Web by introducing an intermediary — an Ajax engine — between the user and the server. It seems like adding a layer to the application would make it less responsive, but the opposite is true.
Instead of loading a webpage, at the start of the session, the browser loads an Ajax engine — written in JavaScript and usually tucked away in a hidden frame. This engine is responsible for both rendering the interface the user sees and communicating with the server on the user’s behalf. The Ajax engine allows the user’s interaction with the application to happen asynchronously — independent of communication with the server. So the user is never staring at a blank browser window and an hourglass icon, waiting around for the server to do something.

The synchronous interaction pattern of a traditional web application (top) compared with the asynchronous pattern of an Ajax application (bottom).
Every user action that normally would generate an HTTP request takes the form of a JavaScript call to the Ajax engine instead. Any response to a user action that doesn’t require a trip back to the server — such as simple data validation, editing data in memory, and even some navigation — the engine handles on its own. If the engine needs something from the server in order to respond — if it’s submitting data for processing, loading additional interface code, or retrieving new data — the engine makes those requests asynchronously, usually using XML, without stalling a user’s interaction with the application.

AJAX & Interface Design

When any new technology undergoes fast and widespread adoption, there’s always an opportunity for unintended misuse. So it’s no surprise that the World Wide Web has seen its fair share of mishandled technologies:
• Download-heavy Java applets for simple page navigation
• Flash movies for superfluous intro animations
• Frames that disable simple book-marking and URL-sharing
• The overuse of images when simple HTML text would do
Some of these technologies have been permanently scarred by excessive misuse. Flash is synonymous with Skip Intro and Java applets within Web applications are often shunned.
Now as a flurry of interest in AJAX sweeps the Web, it’s worthwhile to consider the design implications of this technology lest we end up with “Skip AJAX” in the future.

• Fast & Incremental

AJAX enables faster, more responsive Web applications through a combination of asynchronous Javascript, the Document Object Model (DOM), and XMLhttpRequest. What this means for Web interface designers is that a DHTML-based Web application can make quick, incremental updates to a user interface without reloading the entire screen. In the AJAX model JavaScript calls to the server can update a single element in the UI with data retrieved from a server. Because the full screen does not need to be reloaded, the application is much more responsive to user actions.

Of course updating only certain elements of a Web application interface is possible without AJAX. If an application is designed using frames or iframes, specific content within a frame can be refreshed with server-side data without affecting the rest of the interface. But with AJAX, just about any element defined with the DOM can be dynamic and data can be loaded in the background without user action –making it readily available if needed. (The poster-child of this process is Google Maps, which loads potentially useful map images behind the scenes.)
AJAX allows every element within a Web interface to be individually and quickly updated without affecting the rest of the interface. This, of course, is not what most Web users are accustomed to. Initiating an action within most Web sites triggers the inevitable blank screen and page loading process. Though not very responsive, the full-page update makes it very clear to users that their action has resulted in a reaction and that a response will be available as soon as the page is refreshed. Because AJAX-based updates are very fast and incremental (often affecting only a small portion of the UI), users may not notice them -especially when they are used to seeing full-page rewrites.

• Communicating Change

In order to communicate content updates to users, many AJAX applications have adopted attention-getting techniques to highlight interface changes. Color change and animation are two of the most common approaches.

Using color alone to indicate change requires establishing significant contrast between the updated element and the rest of the interface. Colors that sit opposite each other on the color wheel (referred to as contrasting colors) are good candidates for creating contrast. When used with equal brightness, these colors have a tendency to compete with each other for attention (a phenomenon referred to as simultaneous contrast). As a result, they can be used effectively to bring attention to areas of change.

Animation is also effective because of our instinctual attraction to motion. Incorporating a simple animation in an interface lets users know something is happening in response to their action. 37signals’ yellow fade technique (below) uses a combination of both color change and animation to highlight updated interface elements. Animation can also be used to slow down an interface update to make sure users notice it. Though this approach may seem to contradict the responsiveness that makes AJAX applications great, if users don’t know their change has been made they may assume “no responsiveness”.

In addition to communicating to users that an update has been made after they have taken an action, it’s also practical to communicate pro-actively and let them know what response their action will trigger. Jamie Hoover’s form groups (below) define the area where an update will occur through a single-pixel bounding box. Change the value of the drop-down menu and the bounded area is updated.

It’s also useful to note that quick updates within a Web application may be too pronounced. When a large amount of content is added to a Web page, the screen may “jump” (to use Eric Costello’s term) to make room for the new elements. This behavior may result in a loss of context for users as they find themselves needing to scroll up and down to find their place again. Minimizing the amount of screen “jumps” helps to retain valuable context.

• Lessons from the Desktop

Though communicating change in the interface before and after a user action may seem a bit excessive, it is a direct result of Web applications absorbing more of the rich interactions that have been available in desktop applications for years (drag and drop, auto completion, responsive & incremental updates, etc.) coupled with the fact that Web users are not accustomed to such interactions online.
In 2001, I wrote a paper titled Design Considerations for Web-based Applications that tried to bridge the gap between Web application and client application interface design guidelines. Client application graphical user interface (GUI) guidelines did not cover the interaction possibilities available on the Web (hypertext, etc.), nor did they take into account the conventions and behavioral patterns that emerged as the Web became widely used. Available Web usability guidelines, on the other hand, were not flexible enough to accommodate the new levels of interaction needed within Web applications and often were not appropriate because a Web applications user's motivation differs from a Web site users' goals. The inadequacies of these existing guidelines, in my mind, necessitated the development of new Web application-specific interface design principles.

Though the guidelines themselves have become a bit dated, the underlying principle is valid: a lot of the interaction problems that come up when designing AJAX and other types of Rich Internet Applications have been solved before in desktop applications. And the right solution is often a marriage of existing client and Web interface guidelines or patterns.

Though some might argue that Web application guidelines will emerge organically online via mimicry, we run the risk of “standardizing” non-optimal interactions: not confirmed with user testing and not leveraging years of client application design. For instance, Jeff Veen brought up the difference in documenting Web site designs (as pages) and Web application designs (as states, sequences, etc.). As Dave Heller pointed out, desktop application design documentation can be effectively leveraged to meet this need.

• Keeping Conventions
While leaning on client application interface design solutions is valuable, we can’t lose sight of exiting Web conventions when developing Web applications. Though auto-saving form elements is possible with AJAX (each input can be sent over to the server as a user fills it in), removing the Submit or Save button is likely to cause users to question whether or not their data was stored. Likewise, because Web users have the back button available to them at any time, ensuring changes they have made to content via AJAX are visible when they navigate back is important.

As AJAX applications become more widespread and users begin to expect more of the rich interactions they enable, some of the over-communicating happening today may not be necessary. Until then, however, it’s necessary to consider the expectations users have and meet them accordingly.

Who’s Using Ajax

Google is making a huge investment in developing the Ajax approach. All of the major products Google has introduced over the last year — Orkut, Gmail, the latest beta version of Google Groups, Google Suggest, and Google Maps — are Ajax applications. (For more on the technical nuts and bolts of these Ajax implementations, check out these excellent analyses of Gmail, Google Suggest, and Google Maps.) Others are following suit: many of the features that people love in Flickr depend on Ajax, and Amazon’s search engine applies similar techniques.

These projects demonstrate that Ajax is not only technically sound, but also practical for real-world applications. This isn’t another technology that only works in a laboratory. And Ajax applications can be any size, from the very simple, single-function Google Suggest to the very complex and sophisticated Google Maps.

At Adaptive Path, we’ve been doing our own work with Ajax over the last several months, and we’re realizing we’ve only scratched the surface of the rich interaction and responsiveness that Ajax applications can provide. Ajax is an important development for Web applications, and its importance is only going to grow. And because there are so many developers out there who already know how to use these technologies, we expect to see many more organizations following Google’s lead in reaping the competitive advantage Ajax provides.

Is Ajax the right choice for your Internet Application?

Ajax is a methodology for making Rich Internet Applications(RIA) using proven technologies. It combines the strong points of Javascript, XML, CSS, XSLT and most importantly: the XMLHttpRequestObject. It becomes really powerfull if you combine it with a serverside scripting language and a database. If you never have made a Internet Application this may seem a long list but don't worry about that. You will need most of them anyway if you are serious about developing Webapplications.

Ajax biggest competitor in the RIA-community is Flash. Flash is around for a few years now and will probably stay here, but it has some big disadvantages. The Macromedia product doesn't let you manipulate every element on the page, only the elements in the Flash applet. And another big disadvantage is that Flash is owned by one company, this is known by economist as a lock-in. If they decide to not longer supper a feature that you use, you will have to be very creative. However the graphics of Flash are superb and Flash is very wide spread as you can check for yourself here. Ajax on the other hand allows you to manipulate every object on and of the screen and is also cross-browser compatible. The biggest disadvantage is that it is only supported by the latest browsers. You can always check the latest information about the browsersupport here. For me the biggest advantages over Flash are that I have one communication file that I use for every application I make and it is really easy to integrate in your CMS. Recycling at its best, isn't it?

If you use Ajax properly it can greatly reduce the size of communication between your server and the client. You will only need to send information of a couple of hunderd bytes whereas downloading the whole page with one imaga will cost you at least 30 kB. This will lead to more speed. And speed as you know,is a very important factor for user comfort. In fact researchers at IBM found that you have less then 10 seconds to hold the full attetion of the user. Beyond 10 seconds users would try to engage in another task, such a reading a magazine, while also using the webapplication. But even worse, you only have a split second for maximimum productivity of your user. The end conclussion is faster is better and this is the specialty of Ajax. Immediate respons at user actions. Given the fact that it is difficult to draw with Ajax I would recommend you to use Flash if your site is heavily build on animation. In the other case use Ajax, and you're lucky combine the strength of both of them and you will have a really good Rich Internet Application.

Why is AJAX so hot?

Google deserves the credit for that. Google has kept surprising users with amazing user interfaces on Gmail, Maps, Suggest and what not. We saw GMail, we said "Wow this GMail interface is awesome!", assumed that the Google guys had worked very hard on their Javascript and forgot about it. We knew there was some bigger explanation to it, but we didn't care.

However once this Google approach got a name and a following, it could not be ignored. It now became something that every techie had to atleast be aware of.

As most developers would know, even making a basic HTML + CSS app work the same way across Opera, Firefox, Netscape and IE, is no mean task. If you want to support multiple versions of each browser, things become even worse. Now if my HTML + CSS is struggling, how am I supposed to make my complex javascript work across browsers? And that too when there currently are no standards behind AJAX.

With many users moving to fast broadband connections, making server trips isn't as bad today, as it was a few years back. So making the app use XMLHttpRequest and reducing old fashioned server trips isn't much of a benefit if is going to mean that my development time will go up significantly. Also for serverside development, I have compilers, debuggers, IDEs, components that I can plug in and so on...for client side development there isn't much available. So it is very likely that I could end up creating 100s or 1000s of lines of irrepairable Javascript mess.

Will AJAX Prevail?

Despite the cross-platform challenges -- and some developers point out that there is little reason for Microsoft to make its browser completely compatible with Firefox or Opera -- this new model shows promise. AJAX applications can have much if not all of the functionality of client-side applications. Many programmers react with surprise when they see editors such as Bitflux, FckEditor, or Kupu written entirely in JavaScript, but applications such as these are likely to become commonplace, and even more features are bound to emerge.

Some companies see an opportunity here. Thomas Lackner's development group at ModernMethod is rolling some of its development efforts into an open source library Lackner calls SAJAX, short for Simple AJAX. JackBe, on the other hand, sells a collection of small libraries that abstract away many browser incompatibilities. A programmer can add Excel-like spreadsheets or forms to a Web page and the JackBe libraries will handle much of the interaction with the client.

Which brings us back to the future as the Web finally discovers what Eich and the original team at Netscape imagined long ago. When asked what held it back, Eich speculates, "It was hampered by incompleteness, a rush to standardize, the browser wars killing Netscape, and a dependence on Java to do 'real graphics' and 'real network input/output.'" Now that JavaScript has matured beyond those problems, Eich is enthusiastic to see what comes next.

Pros, Cons & Criticism


• Interactivity

Ajax applications are mainly executed on the user's machine, by manipulating the current page within their browser using document object model methods. Ajax can be used for a multitude of tasks such as updating or deleting records; expanding web forms; returning simple search queries; or editing category trees -- all without the requirement to fetch a full page of HTML each time a change is made. Generally only small requests are required to be sent to the server, and relatively short responses are sent back. This permits the development of more interactive applications featuring more responsive user interfaces due to the use of DHTML techniques.

• Portability

Ajax applications utilise well-documented features present in all major browsers on most existing platforms. Though this situation could feasibly change in the future, at the moment, Ajax applications are effectively cross-platform.
While the Ajax platform is more restricted than the Java platform, current Ajax applications effectively fill part of the one-time niche of Java applets: extending the browser with lightweight mini-applications.

Cons & Criticism

• Usability Criticisms

One major complaint voiced against the use of Ajax in web applications is that it might easily break the expected behavior of the browser's back button (see Jakob Nielsen's 1999 Top-10 New Mistakes of Web Design). The different expectations between returning to a page which has been modified dynamically versus the return to a previous static page might be a subtle one. Users generally expect that clicking the back button in web applications will undo their last state change and in Ajax applications this might not be the case. Developers have implemented various solutions to this problem, most of which revolve around creating or using invisible IFRAMEs to invoke changes that populate the history used by a browser's back button. Google Maps, for example, performs searches in an invisible IFRAME and then pulls results back into an element on the visible web page; it is possible to track user behaviour via callbacks which are called whenever the back button is pressed, restoring the application state that existed at the time.
A related issue is that the use of dynamic web page updates makes it difficult for a user to bookmark a particular state of the application. Solutions to this problem have likewise begun to appear, many of which use the URL fragment identifier (commonly known as the anchor, or the portion of the URL after the '#') to keep track of, and allow users to return to, the application in a given state. (Many browsers allow JavaScript scripts to update the anchor dynamically, which allows the Ajax application to update it in parallel with the contents of the display.) These solutions also address many of the issues related to lack of back button support.

• Response-time concerns

Network latency — or the interval between user request and server response — needs to be considered carefully during Ajax development. Without clear feedback to the user [1], smart preloading of data [2], and proper handling of the XMLHttpRequest object [3] users might experience delay in the interface of the web application, something which users might not expect or understand. [4] The use of visual feedback to alert the user of background activity and/or preloading of content and data are often suggested solutions to these latency issues.

• JavaScript must not be disabled
While no browser plug-in is required for Ajax, it requires users to have JavaScript enabled in their browsers. This applies to all browsers that support Ajax except for Microsoft Internet Explorer which additionally requires ActiveX to be enabled along with ActiveScript. The XMLHTTPRequest object used in Internet Explorer is ActiveX. Security settings might cause Internet Explorer to not support Ajax (e.g.: ActiveScript or ActiveX might be disabled). It is possible to use inline frames (IFRAMEs) to avoid this ActiveX problem.

As with DHTML applications, Ajax applications must be tested rigorously to deal with the quirks of different browsers and platforms. A number of programming libraries have become available as Ajax has matured that can help ease this task. Likewise, techniques have been developed to assist in designing applications which degrade gracefully and offer alternative functionality for users without JavaScript enabled .

• Criticism of the Name “Ajax”
There have been some critics of the term Ajax, claiming that Adaptive Path (the consulting firm that coined the term [5]) or other proponents are using it as a marketing vehicle for previously-used techniques [6] [7] [8] [9].


Using Ajax technologies in web applications provides many challenges for developers interested in adhering to WAI accessibility guidelines. Developers need to provide fallback options for users on other platforms or browsers, as most methods of Ajax implementation rely on features only present in desktop graphical browsers.
Web developers use Ajax in some instances to provide content only to specific portions of a web page, allowing data manipulation without incurring the cost of re-rendering the entire page in the web browser. Non-Ajax users would optimally continue to load and manipulate the whole page as a fallback, allowing the developers to preserve the experience of users in non-Ajax environments (including all relevant accessibility concerns) while giving those with capable browsers a much more responsive experience.

Browsers that support Ajax

• Microsoft Internet Explorer version 5.0 and above, and browsers based on it (Mac OS versions not supported)
• Gecko-based browsers like Mozilla, Mozilla Firefox, and Netscape version 7.1 and above
• Browsers implementing the khtml API version 3.2 and above, including Konqueror version 3.2 and above, and Apple Safari version 1.2 and above
• Opera browsers version 8.0 and above, including Opera Mobile Browser version 8.0 and above
• iCab version 3.0b352 and above

Ajax Mistakes

Ajax is an awesome technology that is driving a new generation of web apps, from to to But Ajax is also a dangerous technology for web developers, its power introduces a huge amount of UI problems as well as server side state problems and server load problems.

I've compiled a list of the many mistakes developers using Ajax often make. Javascript itself is a dangerous UI technology, but I've tried to keep the list to problems particular to Ajax development:


1. Not giving immediate visual cues for clicking widgets.
If something I'm clicking on is triggering Ajax actions, you have to give me a visual cue that something is going on. An example of this is GMail loading button that is in the top right. Whenever I do something in GMail, a little red box in the top right indicates that the page is loading, to make up for the fact that Ajax doesn't trigger the normal web UI for new page loading.

2. Breaking the back button

The back button is a great feature of standard web site user interfaces. Unfortunately, the back button doesn't mesh very well with Javascript. Keeping back button functionality is a major reason not to go with a pure Javascript web app.

3. Changing state with links (GET requests)

Ajax applications introduce lots of problems for users who assume GET operations don't change state. Not only do state changing links cause problems for robots, users who are accustomed to having links drive navigation can become confused when links are used to drive application state changes.

4. Blinking and changing parts of the page unexpectedly

The first A in Ajax stands for asynchronous. The problem with asynchronous messages is that they can be quite confusing when they are pop in unexpectedly. Asynchronous page changes should only ever occur in narrowly defined places and should be used judiciously, flashing and blinking in messages in areas I don't want to concentrate on harkens back to days of the html blink tag.

5. Not using links I can pass to friends or bookmark

Another great feature of websites is that I can pass URLs to other people and they can see the same thing that I'm seeing. I can also bookmark an index into my site navigation and come back to it later. Javascript, and thus Ajax applications, can cause huge problems for this model of use. Since the Javascript is dynamically generating the page instead of the server, the URL is cut out of the loop and can no longer be used as an index into navigation. This is a very unfortunate feature to lose, many Ajax webapps thoughtfully include specially constructed permalinks for this exact reason.

6. Too much code makes the browser slow

Ajax introduces a way to make much more interesting javascript applications, unfortunately interesting often means more code running. More code running means more work for the browser, which means that for some javascript intensive websites, especially poorly coded ones, you need to have a powerful CPU to keep the functionality zippy. The CPU problem has actually been a limit on javascript functionality in the past, and just because computers have gotten faster doesn't mean the problem has disappeared.

7. Inventing new UI conventions

A major mistake that is easy to make with Ajax is: 'click on this non obvious thing to drive this other non obvious result'. Sure, users who use an application for a while may learn that if you click and hold down the mouse on this div that you can then drag it and permanently move it to this other place, but since that's not in the common user experience, you increase the time and difficulty of learning your application, which is a major negative for any application.

8. Not cascading local changes to other parts of the page

Since Ajax/Javascript gives you such specific control over page content, it's easy to get too focused on a single area of content and miss the overall integrated picture. An example of this is the Backpackit title. If you change a Backpackit page title, they immediately replace the title, they even remember to replace the title on the right, but they don't replace the head title tag with the new page title. With Ajax you have to think about the whole picture even with localized changes.

9. Asynchronously performing batch operations

Sure with Ajax you can make edits to a lot of form fields happen immediately, but that can cause a lot of problems. For example if I check off a lot of check boxes that are each sent asynchronously to the server, I lose my ability to keep track of the overall state of checkbox changes and the flood of checkbox change indications will be annoying and disconcerting.

10. Scrolling the page and making me lose my place

Another problem with popping text into a running page is that it can effect the page scroll. I may be happily reading an article or paging through a long list, and an asynchronous javascript request will decide to cut out a paragraph way above where I'm reading, cutting my reading flow off. This is obviously annoying and it wastes my time trying to figure out my place.

What's next after AJAX

The rapid spread of the term AJAX (Asynchronous JavaScript and XML) -- from Weblog to Wall Street Journal within weeks! -- might lead developers to assume it's a breakthrough that heralds the death of desktop applications. There's certainly a kernel of truth in that: The recent spate of new Web applications under the AJAX banner have redefined end-users' expectation of what's even possible within a Web browser by offering smooth scrolling, incremental updates, and more responsive input forms (see " AJAX breathes new life into Web apps").

Nevertheless, so-called fat-client UIs still retain one fundamental advantage over Web UIs: real-time event notification. AJAX alone does not address IM, stock tickers, and other collaborative applications that require "push" data streaming.

The key goal of AJAX-style applications is to decompose jarring transitions that download an entire new Web page into a series of smaller, more frequent transactions. Developers consider AJAX to be "asynchronous" because data can be updated without interrupting the user. For example, Google Maps dramatically reduces the perceived latency of scrolling a map by only downloading the newly visible tiles and moving the rest.

In the middleware community, however, the formal definition of asynchrony refers to the ability to send a message at any time, in either direction. AJAX provides the upstream direction, but HTTP would appear to make server-initiated transmission impossible.
Fortunately, clever developers have exploited a loophole in HTML to address this. Browsers are designed to display pages incrementally while downloading pages from slow Web sites. Using hidden frames and JavaScript tags, HTTP can be (ab)used to hold open a long-lived response connection, allowing an application to stream data into the browser.

The simplest way to exploit this is to turn the browser into a 21st-century "green screen" dumb terminal. Manuel Kiessling's open-source ARSC (A Really Simple Chat) uses AJAX techniques to send input lines upstream, whereas a modified HTTP server that holds open thousands of simultaneous connections rebroadcasts the chat stream to other users. Another example is KnowNow's SpeedReader product, which is useful for alerting employees to relevant RSS news items.

The subtler and broader implication of combining AJAX with asynchronous event notification is to extend publish-and-subscribe application integration across the Internet. Several open-source platforms provide powerful abstractions for connecting fully interactive Web UIs to enterprise applications and Web services. Nevow (nee Woven LivePage) and Pushlets extend the event loop familiar from model-view-controller GUIs for Python and Java, respectively. Mod_PubSub is designed as an event bus that uses URL path names as topics to implicitly invoke programs written in a wide range of languages. Commercially, KnowNow's LiveServer provides enterprise-class scalability (and even connects to and from Microsoft Excel spreadsheets).

The clear benefits of migrating desktop applications to the Web in terms of maintenance, security, and scalability must be weighed against the costs of slower response times, limited interactivity, and less-than-beautiful graphical interfaces. With AJAX, push technology, and the ubiquitous plug-ins for PDF and Flash, the Web is closer than ever to becoming a viable default platform for application development.


At 11:11 PM, Blogger Gizmo said...

I was a javascript/DHTML or as today called AJAX a very long time and I found another way to work around the cancer factor as I call it (javascript development). I call it WebGui and it is my new development environment it is basically WinForms like API combined with a AJAX unique communication layer making it possible to create complex applications like "Outlook Web Access" as simple as creating a WinForms application...

See my webcast here here
See my site here


Post a Comment

<< Home