In the earliest days of the Web, designers chafed against the constraints of the medium. The entire interaction model of the Web was rooted in its heritage as a hypertext system: click the link, request the document, wait for the server to respond. Any designer who asked if the basic call-and-response interaction model of the Web could be defied was met with the flat answer “No.”
Eventually, with the evolution of browser technology, that “No” became a “Yes, if…” Yes, if the user has the right browser and the right operating system. Yes, if the user’s connection is fast enough. Yes, if the user has the right plug-in or the right runtime.
For some designers working in some environments, “Yes, if…” was good enough. But for the overwhelming majority of designers, the caveats and restrictions were simply too great. So they returned to the task of making the Web work the best it could within the hypertext interaction model, developing new conventions for Web interaction that allowed their applications to reach audiences who never would have attempted to use desktop applications designed for the same tasks.
The rise of Ajax represents the new and widening recognition that the days of “Yes, if…” are numbered. It’s analogous to the realization we had a couple of years ago, when it became apparent that maturing browser support for CSS and XHTML would finally allow designers the flexibility and ease of maintenance the Web had always promised but never quite delivered. In both cases, the technologies aren’t new; what’s new is our ability to make the most of them on the broadest possible scale.
Proprietary solutions are never as compelling for Web designers as open standards are. Web designers are passionate about the Web as a medium, and that medium doesn’t belong to any technology provider.
It’s something that all of us, working together, are helping to build. For many Web designers and developers, crafting a new medium is what attracted them to the Web, and what keeps them engaged with the Web regardless of the ebb and flow of stock markets. Technologies that don’t work on a Web-wide scale are, by definition, not participants in this process.
What’s the difference between Oddpost and Gmail? One followed desktop interaction conventions, required a particular browser and a particular operating system, and gained a cult following. The other came along four years later, followed Web interaction conventions, worked across all modern browsers — and transformed its entire category. Some might argue that Oddpost is the more sophisticated solution. But Gmail is part of the larger Web in a way that Oddpost never could have been.
Gmail demonstrated to the entire industry that we don’t have to compromise anymore. Sure, there are still plenty of challenges, both for designers and for technologists, in creating Ajax applications that really work effectively for users. But the new wave of Ajax applications reflects the industry’s newfound (and still increasing) sophistication. We’re smarter about the Web than we were before, and that alone opens up new possibilities for interaction designers.
Those possibilities, and the unexplored ways we can evolve Web conventions without the constraints of the old hypertext interaction model, are why the recent Ajax explosion signals a new chapter in the history of Web design.
That in itself isn’t necessarily a crisis, but I prefer that the user has some indication that this will happen, so I’ve always performed asynchronous web applications using visible applets, so that the user is (hopefully) aware that the “page” they are on isn’t changing, only the applet that they are using within it. The Ajax approach is slightly reminiscent of a self updating frameset where the required parts of the page are updated, but the rest is still usable in the meantime and I’m sure that few people will fight that particular corner.
As I have already confessed I am not familiar with Ajax, so perhaps I am missing the point, but I have to ask, Jesse:
2. Doesn’t Ajax break the navigation model that, whilst flawed and far from perfect, at least pretty much everyone understands?
Ok, then, everyone. I’ve got my fire-proof underwear on ready. Start shooting.
Paul, wikipedia has a nice article with many links about Ajax: [http://en.wikipedia.org/wiki/AJAX].
My personal opinion about Ajax is along the lines of the Dawn’s (well, I’m a developer after all : this *is* a nice technique, but it’s a little difficult to admit it, because tools for this technique more-or-less already existed since a long time.
As an interaction designer, I agree with Jesse, AJAX is opening up a great box of new interaction possibilities. To me, Flickr is another great example where AJAX simplifies intraction (as it doesn’t take the user out of his current context) and improves the flow.
However, I would love to see results from user testing on this. Are users ready for stuff like that? This week’s OK/C comic takes a rather critical positioin towards AJAX. The question is: Who has actual data that supports any opinion pro/contra AJAX web UIs?
Thanks for the link, Michalis, and thanks for proving my expectations wrong. I was fully expeting a tirade of angry developers heaping coals on me for being so stupid as to question the latest “big thing”. I’m glad to have been wrong.
If your arm is broken and the doctor gives you a cast, you may grow to like the drawings and doogles your friends make on the cast. You may even appreciate your ability to wack your little brother in the head with your new body-club. But I bet you’re happy when the cast comes off.
The page is dead? Good riddance.
This does mean is that web designers will need to learn a new way of thinking. State transition, which was primitive on the page-based web, has now gotten more complex. State recovery, which was handled with back buttons and bookmarks, must now be managed in a more mature way–must be baked in to the structure of your application, rather than supplied from without. But if the application design is done well, users will not miss the *back button*, of all things.
Flash is good too, (Flickr for example) but then your dynamic stuff is stuck in a little box and none of the text/brower/OS tools are available in that box. To some extent, same with Java. Java is, unfortunately, in practice awkward and slow when loading, and on many browsers, broken.
Michalis, I also agree. But I’m an applications developer also I see AJAX as too constrained and limited, and still has to work around and fight against the fundamental document-request web architecture (HTTP).
I say, develop a new protocol and write new software. (So some of us did, see: http//www.interreality.org).
Of course, if you’re trying to actually deploy something *tomorrow* that needs these capabilities, accessible by everyone *tomorrow*, that approach is not realistic. But I think we need to do it for the future.
There are reasonably well-implemented methods of creating Ajax apps that don’t break the back/forward button or the history of a browser; a few of them are mentioned in that Wikipedia article, and a few of the toolkits out there (Dojo springs to mind) help implement the techniques. That being said, I’m also anxious for the day that browsers implement more intelligent back/forward buttons (perhaps by allowing apps to provide events tied into them on specific web pages).
I think some of the questions here point to the wider issue… you can only control the page and not really the browser. I think the browser itself needs to become more open. We have to duplicate menus, navigation buttons… basically everything IN the browser itself for our own pages. It is incredibly inefficient. But we don’t want one site developer to make the browser an unidentifiable thing… so what’s the compromise?
The “If…” is still here. “If you’re willing to break the fundamental page model of the web and rely upon a staggering amorphous pile of poorly connected, semi-reliable technologies, you can get a few fancy interaction elements”. AJAX is *not* a technology. It’s a colossal hack.
That doesn’t mean you can’t make use of it now to edge out your competitors (and I’m reluctantly available for hire to help you do so), but ugly hacks call for refactoring, not for use. The web is long overdue for an overhaul.
XUL and XAML are much more interesting approaches to this problem. What’s wrong with doing things the right way?
XUL and XAML are fine for me. Well, actually, XUL is great because it’s from open source and XAML sucks because it’s marketed by M$. But, basically, they are technologically OK.
XUL is only for Mozilla and derivatives. I surely use them (currently this means Firefox and Epiphany). But I would like to support also other browsers. Even if I would not care about poor IE lusers (but I have to care about them, because they are so numerous), there are still other browsers like Konqueror. And they don’t support XUL at all.
XAML is (will be ?) only available for M$ crap, so this is obviously also not a compatible solution.
The grand plan is clearly to merge the web and desktop experience. Microsoft’s plan is via WPF (Windows Presentation Foundation), which they will allow to run “everywhere” with WPF/E. XUL is comparable, but not nearly as ambitious.
FYI, There are open source efforts to build XAML-interpreting engines, most notably www.myxaml.com.
Some are told as SAJAX, XAJAX and so many which one standard? or explain the differece between the above things?
Where i get sample / example scripts?
AJAX is not a technology. It’s an umbrella term for a suite of techinques for creating web interfaces that are “richer” than just plain-old links and forms.
Strictly speaking, using a mouseover image to create a menu option is AJAX (due to the *J*avaScript involved), but there are more impressive efforts like Google Suggest (http://www.google.com/webhp?complete=1&hl=en).
Search the web for “AJAX” for more information, code samples, etc.
This is a very useful post. Thank you so much. Regarding the comments, well thank you too. Most of them confirm what many non developers (term used by one person was “lusers”-they apparently forgot who actually owns the Web. No one and everyone. However, “Visitors” (i dislike the term “Users” to describe a human being) are certainly the ones in charge.
Why do so many Web designers, back end developers, usability professionals, etc., seem to have such a need to “own” the Web, as if there weren’t a much more significant aspect to this relatively new phenomena? It’s called “context” or “the big picture” and technology is as important as all the other parts of the process of creating a rapidly evolving set of tools that are not is service to themselves, they are a response to human need-some of it very pressing in nature.
Instead of throwing insults at me (I am too use to it to be an effective strategy), try tell those listening what you think the answer to those questions are.
Asking WHY always produces better answers to HOW.
Michael: As for my post where I used the term “lusers”: I used the term “lusers” for “users that use IE (IE means Microsoft’s Internet Explorer)”.
My intention was just to say that IE is a bad www browser. Surely, I didn’t want to insult anyone (including people who use IE). “Visitors”, “users” are always respected. Even when they use software that I think is bad. Surely, users don’t have the time (and will) to try and compare various www browsers and judge which one is better. And users don’t have time to read some articles about why open source is better. That’s OK.
If user uses software that is bad, I criticise the software. It’s not the fault of the user that he uses the only www browser that was initially installed on his computer.
So my “insult” was only directed at the piece of software called “Internet Explorer”. Not at users. My apology if it sounded different.
So long as XAML is not an open standard format, it should not be considered a platform for web development.
See the gnashing of teeth regarding the Office XML vs. OpenOffice.org format.
Jeremy: You’re right, I am sorry if I implied that XAML was an “open standard”, though I do think those words are kind of slippery. Anybody will be able to write XAML code and create an platform that runs XAML applications, so although Microsoft will control the details of the specification, I think it’s pretty “open” of them to let other people use it freely.
Michael A: It’s not a question of *owning* the web, just *designing* it in a way that is a little less stochastic and messy. We’re a decade into developing web applications that still pale in comparison to what we could do on the desktop in the mid 1980’s. Why? Because of the insane feature creep of the browser wars and the willingness of developers to wade into half-baked technologies without adequate forethought.
The rise of AJAX is a continued extension of this unfortunate trend. It’s like a cold war—these techniques are wildy technologically inadvisable and horrific hacks, but we have to pursue them because everyone else is doing them. Why can’t we take a deep breath and figure out what users really want the web to be (as XUL/XAML desingers have done) and start to do things the right way?
If it only had been there a couple of years earlier, then we could have made the webapp truly cross-browser. Luckily the switch to AJAX isn’t that hard! Go AJAX!
“Ajax” signifies a collection of prior existing, relatively mature, mutually supporting web technologies that many of us have been using for years in roughly the same way Ajax describes. So what is it then? Nothing but a snappy label–with an increasingly heavy dose of hype.
Like Cayce Pollarda’s allergy to brands, I have an allergy to hype. It starts in the pit of my stomach with a squishy queasy feeling, and then moves up to choke my throat, and finally lands in my sinus cavity with throbbing pressure on my sensibilities. Ajax is starting to give me some mild queasiness.
Some of you may have noticed that Adaptive Path coined the term “Ajax” and is doing a terrific job of branding it (this well-written article is a fine example). Of course in branding Ajax they also brand themselves as THE go-to company for all your Ajax needs (sort of what Cooper has done with personas). This strikes my cynical side as more of an Adaptive Path marketing initiative than a genuine technology.
This is of course a fairly common criticism, even appearing in wikipedia’s entry on Ajax.
On another note I’d like to take exception to the Oddpost vs Google example. Garrett asks “[w]hat’s the difference between Oddpost and Gmail?” And then goes on to imply that the difference is Ajax, and that Gmail beats Oddpost hands-down because of it.
While I agree whole heartedly with the philosophical reasoning that open systems are ultimately superior to closed systems, I think Garrett presents a false dichotomy. The real differences between Oddpost and Gmail start with the fact that Oddpost was created by two unemployed guys with laptops sitting in a San Francisco coffee shop. While Google is a multi-national behemoth that’s starting to make even Microsoft worry.
Despite the resource constraints, Oddpost developed one of the simplest, most elegant UIs I’ve ever used. Its light-years ahead of Gmail and other webapps. It light-years ahead of most desktop apps. And I was happy to pay a mere $30 a year to have it. Meanwhile, I dread having to even look at Gmail, let alone use it.
Garrett concludes saying “the recent Ajax explosion signals a new chapter in the history of Web design.” I suspect that’s a bit melodramatic. The web has seen lots of hype come and go.
I think some of us are missing the point here: If the main reason to make a web application is zero maintenance and on istalling hazzle at the user end, then why should we maintanin the fundamental web page model, history and so on? Why not just open a new window for the application without any browser-like decorations and make the whole thing look like desktop application? Snap, you have entered the world of desktop application interaction (the surfing world is still there in the original window).
If the interaction will be like in desktop applications then the application should also look like one to help users create the right kind of mental model. Sure, back functionality is nice to have in many cases in desktop apps too, but the only proper way to make it work right if you are changing views without letting the server know, is to implement it in the application interaction logic. Make your own back button, mouse gesture or what ever to trigger returning to the previous state/view.
I’m sorry, but I’m just not at all convinced that this is a wonderful new dawning of interaction and not just a combination of buzzwords and marketing.
As far as I understand, AJAX is breaking the document logic of web applications and relacing them by an application logic which. This modifies the user browsing interactions. So there should be a separate protocol for AJAX so that browsers can identify them and provide adequate functionalities, or may be better, the same http port with a specific http header, so that the network layer protocol filters continue to work with no configuration change.
We’ve been soaking in these issues over at Writely.com. We decided to try to use “Ajax” (whatever) to build a word processor that was “of the web”, not just a clone of a desktop app.
I think the original article nailed it - we’re seeing a phase change here because the Ajax stuff is widespread enough that you can develop mainstream apps for it now, and reach a wide audience. This was one of the first things we looked at before doing the app, and we reach, I think, something like 85% of the installed base right now.
The client-side JS environment is really interesting to develop for. The comments above on having to have a more mature conception of state are spot on - we had to sweat bullets to make this work for our live collaboration feature. But…it’s what users want, and expect, and you just have to do it.
And the bottom line is, if you’re doing these kinds of apps because you can deliver value, users don’t care why or how you’re doing it. This is what we’re finding with Writely - it’s just better for lots of light document editing than the desktop, and we think we’ll see the same kind of migration from the desktop that the email market saw.
Like it or not, for this moment in the market, AJAX is “good enough” and is likely to push the rest of this stuff off the stage for a while. It has all the characteristics of a “wrong is right” technology.
Give us a try if you have time - I think we’ve made good choices about how to do an app like this, I’d love the feedback.
Sorry…meant “worse is better”, not “wrong is right”…need coffee.
This is what I’m talking about, if you haven’t read it:
Interesting points, to which I’d like to add a couple.
A scripted editor will not be as good as a desktop app, just as a scripted email client is not as good as a desktop one. That doesn’t mean that the scripted version is not useful, and it certainly doesn’t mean that the future is in the hands of good old-fashioned ‘desktop apps’.
Instead, what it means is that the features that are available to a desktop app prorgrammer should be made available to the web app programmer.
Some will disagree on even this first point, but with all respect to them that’s kind of irrelevant. People upgrade browsers all the time, and are even happy to try new ones, so there is no essential problem with adding better ‘application’ support to a browser.
In my view the key issue is not whether it will happen, but what form it will take. How should this new kind of programming be done?
MARK-UP AS A PROGRAMMING LANGUAGE
Part of the problem with desktop apps is not just that they don’t take full advantage of the web, but also that they use ‘heavy’ lanuguages such as C++ and Java. Web pages on the other hand are a narrow class of applications that are easily programmed with simple mark-up. For example, how much programming used to be involved in creating an area on your application that could be clicked with a mouse, and then in turn cause a new page to open. Thanks to the HTML ‘a’ tag, this functionality is available to just about everyone.
What we need for the next generation of web apps then–the ones that are more like desktop apps–is a language like HTML, that provides the power of C++ or Java.
Of couse, Microsoft might tell you the same thing, but it is difficult to see XAML becoming as easy to use as the HTML ‘a’ tag. I’d therefore suggest a different solution.
I’ve been involved for three years now in XHTML 2 + XForms, two standards coming out of the W3C. XForms is a full standard already, and works in a number of browsers, successfully capturing common web programming patterns ranging from error-checking, mouseover hints, through to submitting data via HTTP or email. (XHTML 2 is still in draft form.)
An example of how XForms Submission is as easy to use as the HTML ‘a’ tag is in my blog article XForms: An Executable Pattern Language.
The article describes firstly how the XForms submission element is far easier than using XmlHTTPRequest, but then, more importantly, goes on to show how the very same tag can be used to achieve functionality such as reading and writing to databases, sending email, saving and loading local files, and so on.
Whilst AJAX obviously has a place in providing a sub-set of this functionality–a means of communicating via HTTP–it is extremely important to be clear about where it fits in the ongoing evolution of rich-client technologies. It is not the end of the road, but it is a very useful transition point on the journey.
I believe the functionality we are all looking for is described in something like flash, but needs to be bigger and more robust. The next generation rich client solutions like
Curl http://curl.com/, or Laszlo Systems http://www.laszlosystems.com/ have the horsepower and the consistency more like that of an operating system to make what we need possible.
From the Ajax WIKI
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). Returning to the previous state may not be possible when a page is updated dynamically, since browsers typically record only static page visits in their history lists. The distinction between a static page, loaded in its entirety, and a page which has been modified dynamically might be a subtle one; users generally expect that clicking the back button in web applications will undo their last 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 the Ajax element on the visible web page; the Dojo toolkit allows tracking of Ajax requests via callbacks which are called whenever the back button is pressed, restoring the application state that existed at the time.)
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, smart preloading of data, and proper handling of the XMLHttpRequest object users might experience delay in the interface of the web application, something which users might not expect or understand. The use of visual feedback to alert the user of background activity and/or preloading of content and data are often suggested solutions to latency issues with AJAX.
There have been some critics of the term Ajax, claiming that Adaptive Path (the consultancy firm that coined the term or other proponents are using it as a marketing vehicle for previously-used techniques
There have been some critics of the term Ajax, claiming that Adaptive Path (the consultancy firm that coined the term or other proponents are using it as a marketing vehicle for previously-used techniques
Hello!!!!! people! all technological complaints aside, AJAX and browser-based applications at all are on people’s lips b/c of what Jesse and AP gang have done. By eliminating the techno-babble and creating a real achronym for people to get their heads around w/ an explanation of its viability has been a HUGE triumph.
re: the complaint about state management
Why do I always have to manage state? Do I bookmark every state in Outlook? So why would I want to save every state just b/c it is in a browser. Yikes, people! let’s not hold onto old conventions for not good reason.
Re: State Management
Imagine an AJAX-based interface that presents a list of links (say people who’ve linked to your blog).
To keep things manageable, the designers have restricted the display to list only 10 links at a time, though you might have 30 or 40 to display. Therefore a simple next/prev navigation scheme is set up.
Now, to keep page refreshes to a minimum and perceived performance to a maximum, the designers have decided to implement the next/prev architecture with AJAX too. So, as you go forward in the list, you’re just getting the partial page served, ala a standard AJAX interaction.
This all works well until you click on one of those links. When you click the back button to return, the state of the list is lost and you’re returned to the top.
One could argue (and I’m sure one will) that this wasn’t a good choice for AJAX. However, I think it’s premature to know what is a good choice and what isn’t. I think we need (a) to keep innovating and seeing where we can get past these obstacles and (b) become familiar with our tools and learn how we make good choices and what bad choices we should avoid.
Using Ajax technologies in web applications provides many challenges for developers interested in also 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.
Many popular applications using the concept have been created, including Google Mail and Google Maps, and Flickr. These high-profile examples of Ajax usage demonstrate the flexibility and utility of the web programming model. Google’s competitors have recently released similar Ajax-based websites
Sorry, just a wisecrack, because I’m as clueless/hyperhyped as the next guy; might serve as a comedy relief or tasteless troll but here it goes:
Next up on the battlefield: Achilles! Being shot in the foot will become legendary
two of our programmers used the Morfik IDE to build a desktop version of Google’s Gmail in 2 months
yes, and I’ve built a fully functioning SQL database using Excel 97 and VBA (don’t ask, just pray to whatever you hold dear that you’ll never have to do it). The point is not if you can do it, but if you should. I still can’t see anything that Ajax can do that Java can’t do better. If anyone else can then please show me the error of my ways.
I was doing AJAX and didn’t know it at a former client. The applications we created were the smoothest, sexiest looking applications.
At another client, we’re [I am forced to use it] using the prototypical J2EE/Struts/Tiles/Workflow layered approach.
Who needs a complicated workflow layer with AJAX? With AJAX the flow is kept in the page just like in Java SWING or MFC or VB applications. The user, intuitively, knows when to press the SAVE, ADD, DELETE keys because the AJAX programs I write only make these buttons enabled when all validated conditions are met. Complex checking to enable/disable buttons happens in the background. Imagine a field which requires 4 characters and which has 4 characters in it where the user hits the backspace. Now it only has 3. Instantly, some action button is disabled. The user immediately notices this (cause and effect) and knows, intuitively, that the field requires an exact or at least minimum number of valid characters. There is no better way to guide workflow than to have immediate and visual responses to a user’s input.
Calls to the backend are granular examples of service oriented architecture where each call requests something specific and gets it. This makes it very easy to debug and one call broken doesn’t necessarily impact other calls.
I developed POJOs (Plain Old Java Objects) to render [using FOP] PDFs from two “ingredients”: XML and XSL (stylesheets). From an AJAX application [running on client] I make a call to the backend to get an XML data result set based on user parameters. Then another call to get the specific XSL to that report. Then, from the AJAX client, open (open as new browers page or popup) a generic servlet page that only knows about the two ingredients and render the PDF on the new browser window.
Using AJAX allowed me to decouple the getting of the desired ingredients (in background calls) from the rendering based on those ingredients.
Java is a great programming language. The plug-in VM from Sun is just troubling, and if you g-d forbid want to do swing, your footprint is just huge. In fact the entire deployment factor of Java apps in scenarios with “locked” desktops by 3rd party providers is well just impossible. It’s a non-starter.
To me the problem is we are navigating this sea of data in a dingy with 21 holes and I only have ten fingers and ten toes.
Java, ASP.NET, CSS, Jscript and AJAX to mention a few all have their pro’s and con’s. They all have their place just like we all have our opinions.
The real problem here is standards. The fact that we are still hacking and working around browsers at this point in the game is boggling.
Racing for market share of something that is free, great.
I’ll end this by saying I have recently been using ASP.NET and have cut down on server trips greatly on things like user forms and data display. It does just that writes browser specific jscript to keep alot of processing on the client side to enrich/speed up the user expreience.
I bid you all a good day …now back to MONO.
I agree that stating that gmail is a revolution is a melodramatic.
I think it has been important in in the development community though because it has shaken up web developers to push the technology harder. I think design had gotten complacet before gmail. Basically gmail is a few simple tricks, i’m not sure it adds up to a fully functional application. Anyway; it does break brower conventions as well. I think this is a really important point. However, its not to say that you can’t have a very ajax powered site and still conform to browser conventions. It just depends on how you use it. one has to be smart about it. the problem is due to the relativly open way ajax works and the flexibality of DOM its very east to be Stupid with ajax applications. the reason the web works as well as it does is the limited tools we have for dynamic interaction inevitably lead to standards and conventions. Ajax looks to break all those conventions if misapplied.
joonk - There is no alterative to Ajax. It’s not an offering from a vendor. It’s something that is just there.
Rex, thank you for the feedback. I assure you that the Morfik IDE and JST are not hype and people will get a chance to see it in action next week during the Web2.0 conference.
As for the unplugged nature of Morfik applications, we do not claim any magic here either. Obviously if a web application is to continue running after being unplugged from the web, the browser requests must be handled locally. This requires an HTTP web server (or at least the relevant functionality of it), and such a local server is incorporated in Morfik applications. The same argument applies to database servers. Morfik applications incorporate an RDMS. In applications created with Morfik, all components are linked within a single executable and run under a unified computational space.
I hope this clarifies some of the mist. Stay tuned.
Chief Technology Officer
I just wanted to respond to Mark Birbeck’s comments above, and I find it odd that I appear to be the first to do so here.
It seems to me that Mark is one of several to approach the topic here, but he is actually I think the only one to come out in clearly stated support of W3C standards which, although not yet widely supported, offer IMNSHO (In My Not So Humble Opinion) the clearest vision of what the web can offer in the near future without compromising standards. I am referring to the XForms and XHTML 2 which Mark mentioned.
The more that I have worked with xhtml/css and (more recently) xml on a broader scale, the more amazed I am when I see web sites and applications still relying on HTML 4 with limited or zero use of css, or on older, often proprietary markups and data formats. I realize that the reasons for this are varied, but I would suspect that they generally relate to one or more of the following:
*Real or perceived lack of support across all or most clients (software) used by the vast majority of existing or potential clients (human). This is increasingly invalid as an excuse, although we all know IE demands significant hand-holding when it comes to css.
*Real or perceived ‘cost’ of rewriting legacy code. This understandably slows or limits the updating of many long-established websites, especially those with large archives or enterprise structures based on legacy code/data formats. But I would argue the cost of not updating will increasingly offset the one-time expense involved in bringing these sites to the 21st century. I say ‘one-time expense’ because xml/xhtml/css are standards which are designed for future compatibility, and they make portability a breeze.
*The perception on the part of some developers that these standards are fads, and that it is best to stick with tried-and-true technologies. Well, 5 years ago, I could see this as a valid excuse. But today, you must have your head in the sand if you try to argue this. Also, WHAT tried-and-true methods? They were all abominations!
*Lack of support for these standards in existing IDE’s/editors. This is a very real problem, which is not adequately addressed by ANY of the major players, although I think we can say that Macromedia has gone the furthest in the right direction with Dreamweaver (not Flash).
*Belief that it doesn’t matter what coding standrds are used, so long as it ‘works’. This is perhaps most significant, and most insidious in a way. This mentality (or some form/extent of it) is represented in many comments here, and it is entirely understandable. Unfortunately, it is also one major factor in preserving/reviving ‘bad’ practices and proprietary solutions.
There is considerable agreement here that AJAX is nothing new, but that it is an umbrella term for existing technologies. Now I think that this explains much of the hype. Why NOT be excited when you discover that the latest and greatest is already in your bag? And I think that this is a positive trend in many ways, in that there is a focus on changing the way we approach our existing technologies, in that standards-compliance is emphasized, and expanding on what we already know allows for rapid implementation of useful applications.
BUT (and there is almost always one of these in my rants), I agree with comments here that AJAX is near-sighted. Perhaps the most obvious and compelling reason for that statement is the fact (yes, fact) brought up by someone earlier: AJAX is a HACK. We are well-acquainted with hacks in the web world, and one might almost say that it comes with the territory (and so long as you have browser development in the hands of the likes of Microsoft engineers, this is not only possible, but likely). And due to browser limitations, the argument for AJAX is as compelling as it is near-sighted. After all, developers need to implement services TODAY, not 3 years from now.
So where to look for the standards of the future? Mark had it right, I believe, when he mentioned XFORMS and XHTML 2. While these may not hold all of the answers, I can assure you that they will set many of tomorrow’s standards (well, they ARE tomorrow’s standards). Somebody else mentioned Open Lazlo- from what little I have seen so far, I tend to agree that it is very forward-looking. So do what you have to do to implement what you must today, but prepare for a future that leaves behind widespread dependence on ugly hacks- I believe it is in sight.
Firefox 1.5 due out before the end of 2005 will support accessibility for AJAX and DHTML applications.
Take a look at http://www.mozilla.org/access/dhtml for more info.
DHTML accessibility, and accessibility in general, is something that IBM is contributing to the Mozilla open source effort. I’m the architect working on it.
I’m suprised at how close-minded a lot of the people appear to be on here that are posting replies. I don’t think AJAX is going to replace the traditional way of creating web pages. I think it’s a great method for an in-house webapp where the environment is controlled and you know for sure which browser your app-users will be using. I think the idea is to take a desktop app and replace it with a webapp, not necessarily to replace the company website.
Perhaps a naive question, but I was wondering why there doesn’t appear to be a push for a “browser” that is not a browser at all, but just supports viewing of web clients (I’m thinking Firefox without the menu bar, nav buttons, bookmarks, etc.–just a window with a title bar)? I realize that this will make the “browser” unsuitable for its original purposes, but why not have two tools for two completely different purposes–page browsing and web app interaction–or at least two completely different states for the browser?
In regard to all the comments about AJAX failing with state management, it seems to me that this is a result of displaying things built in an application paradigm in something which supports the page browsing paradigm. Joe writes: “the idea is to take a desktop app and replace it with a webapp, not necessarily to replace the company website”, but why are we trying to display both webapps and websites in the same environment? Once again, I’m assuming that this is a very naive question, but I’m curious if someone has and answer/feedback…
I don’t think the question is naive at all. I ask it all the time. There is though a simple answer. “B/c it’s there.”
Yup, that simple. What you are describing doesn’t exist, so the point is sorta moot in a way. BUT! there are examples that do come darn close:
1. Java Web Start. Click on a link in the browser and it opens up an application in its own instance state. Doesn’t need the browser once started.
2. XUL applications sorta do this, but again still start from a browser first (at least the first time you use it).
3. WinFX … check out microsoft.com/max … This is sorta a nicer-friendlier .NET application, but it has alot of the good points of a web/app as well.
I think AJAX is compelling first and foremost b/c for fairly simple rich behavior it requires nothing further to deploy other than the browser, which as we know is well, there already. XUL is there already too if you have a mozilla/netscape browser, but most people still don’t.
Flash is also already there for most people, but it has its own sets of problems.
What makes AJAX good is that you can scale with it. You can do something as simple as just designing a small widget with it, or you can do an entirely new page/state paradigm. And you can scale as slowly or quickly as you like.
Flash CAN do this too, but requires new skillsets that most web programmers don’t currently have by default.
Lots more … While you can look at one point and go Yay! or Nay! if you look at the total picture on all sides it is pretty darn complex.
I have to disagree with this statement:
“Proprietary solutions are never as compelling for Web designers as open standards are. Web designers are passionate about the Web as a medium, and that medium doesn’t belong to any technology provider.”
In my experience, Web designers have preferred proprietary technologies to open standards. I have not yet worked with a Web designer that hasn’t sighed “Oh, if only we could do the whole site in Flash” at least once (I admit, there have been times I’d wished I could do a particular homepage design as a huge image-mapped GIF). Many come from print or similar backgrounds, and they miss the amount of control they can have over pixel-perfect layout, fixed and predictable “page” dimensions,” and of course, their fonts of choice. They also like the degree to which Flash allows them to control the user experience and flow, like they would in a CDROM piece or TV commercial.
Mark, I think you are totally right. I think the above quote you refernce, really means “web programmers/coders” and not designers. Designers really don’t give a hoot about technology. They care about aesthetics, behavior, usability, brand, legibility, findability, and well success. Whatever gets the job done. A good designer SHOULD be technology agnostic. Often we aren’t well b/c we are marketing sponges.
Just an update to my previous post (and thanks Dave, for your feedback!): I found an interesting article by Jason Kottke musing about Google’s plans for web-desktop apps in the future: http://www.kottke.org/05/08/googleos-webos
Great discussion. Jesse, I envy your ability to trigger a passionate but not flaming discussion about an important new approach to a long-standing problem. I’m excited about Ajax for the same reasons many of you have stated here, but I suspect that in a year or two it won’t be Ajax per se that “wins out” in this effort. It will be something that merges Ajax with the likes of Laszlo Server.
This *style* of app — an app in the browser — must eventually win because it eliminates so many of the platform-specific issues inherent in today’s app development. Writing desktop apps in Java is a chore and the resulting products are often bloated. Plus, cross-platform UI stuff is still not quite there, at least according to my colleagues who do Java coding. I use a tool (Revolution) that really lets me build cross-platform applications quickly and smoothly but which is not suited to all kinds of apps (though it IS suited to 80% of all kinds of apps). That’s great but what I really want isn’t cross-platform software, I want platform-free software. And the browser offers the best possible current solution to that problem.
What we need, it seems to me, is a great IDE in which to build Rich Internet Applications (RIAs). We have such an IDE today — or at least most of it — in Dreamweaver, but DW is: (a) proprietary; (b) expensive; and (c) about to become the property of one of the worst software innovators on the planet (Adobe). So what’s needed is for someone to tackle the idea of an Open Source scaled-down DW clone that focuses all of its energy on enabling the creation of Web applications as RIAs.
I prefer the Ajax model to the Laszlo model only because I dislike relying on a plug-in, regardless of how ubiquitous that plug-in might be. Users who don’t have the plug-in won’t always download it and the company that made the plug-in is always somehow in the mix. As the Adobe acquisition of Macromedia demonstrates, you can’t rely even on the relatively large, stable companies to “do the right thing.” But until Ajax has a DW-like app for development in place, it won’t be able to get the kind of traction it will take to move the marker substantially away from desktop apps being so much better than Web browser-based apps that the latter become compelling.
On another note, Morfik does not seem to have been released yet. Did it actually debut at Web 2.0? If so, what is its status? The Web site still talks about the upcoming Web 2.0 trade show debut. Even if it is ready to go, however, unless the screen shots on the Morfik site are misleading, we’re not talking about a graphical IDE for the creation of rich apps with Morfik. It’s just a text editor/translator-compiler which may well have a lot to offer the community but which will fall short of a DW for Ajax or DW for RIAs.
Oh, yeah, and I tried Writely. I like it. A lot. I think it is a good demo of what *can* be done with Ajax (even though the developer here seems to be saying that doing it in Ajax was very difficult and challenging.
So I mused early on in this thread, and that musing turned into a big fat long article with screen shots and everything. So That doesn’t quite even fit in my own blog, but my blog can link to a PDF file.
Ok, why is it “Ajax” and not AJAX?
Is that jsut b/c it it happens to be pronounceable? Just curious? I know we do that for Laser and Radar, but those are acronyms that have been turned into regular words even in the dictionary. While I love AJAX as a term, I just don’t think its “arrived” quite yet.
I’ve just spent about two hours with OpenLaszlo Server (http://www.openlaszlo.org), a free, Open Source RIA creator that I tried about 18 months or so ago and found interesting but not quite ready for my level user. They’ve made great strides, are up to a 3.1 release, and it is truly an intriguing, powerful package. Release 3.1 says it includes the AJAX API. This means the built-in XML-based OO language includes an XMLHTTPRequest class that implements that class as specified by the governing consortium (here’s the spec page: http://www.whatwg.org/specs/web-apps/current-work/#scripted-http).
The range of UI components and the elegance of products made with Laszlo is pretty astounding. I’m not deeply enough into it yet to know for sure but this could be a really interesting tool for folks interested in AJAX.
I should have mentioned that Laszlo outputs .swf files natively rather than XHTML, so it’s not, strictly speaking, the same kind of animal AJAX is, but it does solve a similar set of problems and, as a tool, is very mature.
Ajax is a word. It’s the name of a product you can use to wash toillets. And now it’s an acronym you can use as a selling point to your customers.
Carlos, any new word can have derived meaning if you allow it to. Yes, it is marketing speak … but isn’t marketing speak about communicating an idea to people. If I said HttpXMLRequest (the real guts of AJAX) that really doesn’t have a lot of meaning. But now we have a word w/ hype that is quite useful. What’s so bad?
Dan, in response to your question, Morfik did actually debut at web 2.0 conference.
We are starting a Morfik pioneers program in the next few days. This will make a pre-release copy of the product available to selected developers ahead of the product release.
Morfik is a full featured visual design environment in the same class as Visual Basic and Delphi. Among other features, it includes a visual form designer, a visual report designer and a visual query builder. All graphical designers are specifically made for AJAX development.
Further, Morfik is designed for professional developers and includes comprehensive debugging and profiling facilities for developing high-performance AJAX applications.
Chief Technology Officer
Here is the bottom line.
Interactive web technologies give us the power to do things in the browser that were absolutely possible (and totally done) ten years ago with ancient hardware and comparitively primitive software.
Ajax isn’t a standard, nor a revolution. It’s a semi-functional accident. For the entire history of computing we’ve been trying to get applications to work everywhere, and we finally have sufficiently massive amorophous layers of software to get some kind of traction. Not that any of it is really very good.
I think if anything, we should be apologizing.
This has been a very informative thread.
I believe Web technologies is analogous to the saying… “too many cooks can spoil the broth”
So many features are far more superior for telnet type sessions, especially in relation to data entry performance and keyboard navigation. keyboard accessibilty is a big issue with browsers. Its almost like the keyboard became the forgotten interface when we jumped to HTML point and click technology.
If enterprise systems are to move to the web, things like keyboard accessibility needs to be properly considered in web apps - as its far more effective for navigation and data entry. I am currently trying to mimick an enterprise system our company uses into a web app… the problem is the current technologies don’t seem to the have the capabilities. You lose more good features than you gain!!!
Yes, let’s bow our heads in shame for 3 decades of bad desktop software, and even worse network integrated software during that time as well. Sure, let’s take the really negative and unproductive route, and hide our heads in the sand, while a new opportunity of growth is being spearheaded.
Yes, that’s what I’ll do.
And the other bottomline Robby is while people were doing that work for the last 2 decades no one cared or listened or saw value in how to apply it to a wider set of ubiquitous uses until well recently.
Revolutions in technology don’t necessarily happen when the technology is available, but when barriers to entry of its use are reduced. Some of your bottom lines are just NOT true, and don’t make sense when looking at the entire picture. Purely even on a technological level it isn’t true.
IE 3 coulnd’t do httpXMLRequest, and Netscape 1-6 couldn’t either. It always required the install of something else like a plug-in, which has a whole set of reasons that it isn’t doable for everyone.
So the bottom line is that you can sit there and complain about a new word meaning something old, or you can sit down, join the hype and start helping people to sell what people want to buy!
Shoot! even HTML itself is old compared to SGML. So???? Let’s not use that word?
I’m just proposing that we recognize AJAX for what it really is: a sign of failure more than success.
I think we can learn from the mistakes of the past, but it requires really understanding what went wrong. Mr. Garrett seems to characterize AJAX as a pinnacle of technical achievement. That’s just plain wrong. This was the original dream of Java; the underlying principle of POSIX, X-Windows, telnet and even Pascal p-code! All of those technologies were unable to gain enough traction to become *the* standard. Until we understand why they failed, I see no reason to believe why AJAX is not simply history repeating itself—or why the future, with XUL and XAML—will be any different.
There are two technological reasons why AJAX could succeed where Java, X, XUL and XAML woudn’t:
- because in its current form it’s an already tested and debugged programming environment
- and more important, because it’s already instaled in practically 100% of the desktop computers connected to internet! That’s an advantage that no other GUI framework ever had, not even MS ones.
Paul Brown raised some great points way back on Sept 16. He sites the lack of IDE’s and ease of development with Java, as concerns about AJAX.
ICEfaces from ICEsoft (www.icesoft.com) offers a framework compatible with any IDE, and a capabilty to develop AJAX applications in all Java. The ICEfaces framework handles the AJAX bridge for the developer and implements direct to DOM rendering. All the application code is pure Java.
Slightly off topic, but what I find intriguing is that Adaptive Path seems to be very eager to call out AJAX wherever they can, and thus posting articles all around. And yet, after this very interesting discussion that arose on this site, I see no reply from Jesse himself what so ever. Am I missing something? Is this just some exposre bling bling? (Me off course chicken for posting anonomously, but still an honest question). Cos for all it’s worth. AJAX isn’t really groundbreaking from a design-perspective.
I have a question — aren’t there some restrictions on xmlhttp that restrict the power of AJAX? For example, isn’t XMLHTTP restricted to only going to the domain that you are already in? And also I believe it cannot do any secure processing. Am I wrong about this?
If I am wrong, it is probably because I am having trouble finding a good XMLHTTP reference. MSDN just has bits and pieces. There must be something better somewhere.
As an, um… user.. I have a couple comments and a question.
Comments: Some of the posts about getting rid of the page metaphor remind me of early talk — and deisgn — out of wired.com, when the designers had all sorts of revolutionary ideas. The site seemed pretty unusable to me, and I guess others, because it pretty quickly settled down and designer settled for a lot of color. Meanwhile, as a longtime user, I rely on the back button and history, and I’d be very frustrated trying to use a site that didn’t allow them. Such a site — or service — would have to have superb navigation and design.
Now, my question: I think Hilary’s suggestion of something like a browser that only supports desktop applications would be a good way to go. Do some of the current standalone desktop applets, such as Konfabulator Widgets or Weatherbug, offer a good model for what you all are talking about? Something that I know will change on its own, that I don’t expect to behave like a browser?
I’m not a developer, but a technologist and a usability consultant, so my perspective may differ on those points.
I find it interesting that while everyone is up in arms about Ajax for one reason or another, no one has suggested that the problem/challenge may lie in the browser itself.
We have a horse and buggy and we’re trying to make it into a race car. It won’t work.
I’m drafting a requirements document for a new application, a bastardized browser if you will, that will provide a presentation mechanism for pages (with approprite associated controls) or applications (again, with the appropriate controls for that type of content). I believe this will be a step in the right direction.
Interested in joining in? Drop me a line.
I’m still attempting to grasp the way XmlHTTPRequest method works.
I followed this tutorial to build a zipcode database search - that fetches city and state based on the zipcode entered in a form. The tutorial resides here.
After that I decided it would be a nice feature to have a city lookup table. It was designed so if I pressed a button it would pop a new window populated with a list of city names based on my query from the parent window. That way I could scroll to the correct city and then select and jump back to the main page with the new city record.
However, I don’t know how to send the selected xmlHTMLrequest back to the parent page. The XML seems to stay focused on the new window. Does anyone know if the xmlHTMLrequest can populate the query results in a window other than it was initiated from?
AJAX is gonna be a nightmare of epic proportions.
Ron: Yes, the problem is the browser!!! It was never designed for this purpose and we’re trying to force it into it.
However, there’s no good reason to invent a new platform for application delivery. We’ve got lots of perfectly good platforms, ranging from Java to Flash to the Win32 APIs to Mac OS/Cocoa. The problem is not with the quality of the platform; it’s with rates adoption that are less than 100%.
If you really want to contribute to the problem, work on the Mono project or help out with MyXAML. We don’t need another browser.
I kind of like this Ajax thing.
Actually 5 years ago i started to use it and built
a generic engine for that.
you are welcome to go and check it out
Although late in the discussion, I just wanted to add my 2 cents.
A lot of the interactivity and functionality that many of us find so attractive in AJAX is reminiscent not simply of Java or Flash but also in some ways of frames as well. Using frames at least in some deployments was an attempt to maintain state on parts of the page.
The reason why I bring this up is that these technologies and approaches were the cause of considerable differences between groups of designers and developers earlier on.
So while I love the stuff, I still wonder if AJAX is simply going to be the next chapter in the WebDev culture wars. You know, AJAXsux and all that. Are the lines already forming?
Hasn’t everybody been doing this stuff ever since the xmlhttprequest object appeared on the scene and before that with hidden frames?
No. Probably not. But some of us have been. It’s good to see that it is finally getting visibility.
You are all missing the point: This is the greatest marketing scheme in the world to force or coerce organizations to move to proprietary solutions and to require users to move towards a web services model where all content requires a server visit to display.
These ideas are NOT new and have been around for 15 years or so and are simply being repackaged as a way to move towards vendor or site-visit lock-in.
Grow up and realize that a lot of us dont fall for marketing “strategies” such as these and wont be easily fooled to part with out budgets on these types of consulting ploys to assist us with such lock-in.
While I don’t totally understand how Ajax works, I’ve been reading, researching, and playing around with it. So far it doesn’t put a breeze up my skirt, but I see it working at Google and other places, so it works well.
But, even in my own experience I’ve found Ajax apps to go against many conventions I’ve learned since the web go big. Namely things like the Back button, page wait, etc.
The novelty of these apps is great right now, but when I watch people using Ajax pages - from my 60-year-old parents, to 40-something home PC people, to nerds like myself - they get confused because the rules they have struggled to learn are gone.
The rules might have been dumb to being with, but they were there all the same. People expect a wait and people are trained to use the Back button.
I work with so many people that are already afraid of technology (web or desktop) that they cling to what they know and don’t let go. In this case, they cling to the Back button, page refreshing, etc…and now that goes away?
I guess it’s the same learning routine as before when people needed to learn the web just to buy shoes and pay their bills, but it’s one I’m not looking forward to support. Developing, I can’t wait, but guiding and explaining is far from productive when I work (and live) in a world where it’s a mixed bag of technology to start.
“You can use the Back button with this tool, but not with that one.” Exceptions are not good and shouldn’t be pushed onto people, at least not when they have enough trouble as it is.
I don’t think Ajax is a marketing scheme. It has serious value. It’s something I’ll be learning how to use and build with. But it is (and has been) possible to build quality applications within the browser without Ajax.
Coming late to this discussion has its advantages. I’ve read through all of the posts and as a Web Application Designer and Information Architect it has been extremely interesting. Usability is something that I care very deeply about and each usability challenge/model is dependent on what is being done at the time. To paint all websites with a single paintbrush will only cause you a world of grief.
I’ve done a lot of user testing in my time, and I’ve found there is a very distinct difference in user behaviour depending on what type of site/application they are on. If the user is on a content driven site, they expect that the full range of browser buttons will work. Ajax is clearly the wrong way of approaching building this type of site (even if it is all driven from a database). However, when a site is transactional based, the back button is ignored. When this is the case, Ajax (and a broken back button) is not that bad.
We need to remember to approach all of this, not as an exercise in technology, but a effort to make our users life easier. Technology is a means to an end, and should be used appropriately.
Got to agree with you there Robert.
I think there is a distinct difference between a “Web Application” and an “Application hosted by the BRE (Browser Runtime Environment)”, I see a Web Application as something like amazon.com and an Application hosted in the BRE is comparable to a Swing Application hosted by a JRE (Java Runtime Environment).
With the Web Application model comes a set of conventions e.g.
1. Where the company’s logo appears (what happens when you click on it)
2. How you search for something
3. The “Submit” button
4. The “Back” button
With the Application hosted in the BRE model, which is evolving from the desktop model, comes a completely different set of conventions - it’s up to designers to apply the appropriate model.
To Robert’s point,
My experience is akin to yours but w/ a slight variation. While users change their behavior based on the type of product they are using, this does not manifest itself 100%. For example my studies (quite a few; over 100) with enterprise applications (BRE hosted to take David’s phrase) showed 2 interesting phenomena consistently that contradict each other based on Robert’s explanation:
1. They use the back button. Love it! Why? B/c the back button is also in the OS now. So it is not something specific to “the web”.
2. They go to the file, view, edit menu of the browser to do things. (This part supports Robert’s POV). And if there are two sets of menus as in my app the user goes to the browser version first and then to the one I intended for them to use.
But that being said, I have done some analysis of the “sucessful” AJAX sites out there and I have to say that there are patterns that can be derived and executed on that are quite usable in both usable and useful using AJAX type “effects” that should not “break” conventions that people seem to be holding so dear, despite the fact that most users have only been using them for about 5-7 years … not a long time when compared so to a door-knob, tea-kettle, or faucet. I don’t think there are any 2-D affordences in these conventions; thus, we can still explore, train, and see what works best over time. Usability labs fail at the “over time” aspects of designing a system.
Dave1, would you classify a Google Maps/Gmail type application as being hosted in the BRE? I’m trying to get my head around this concept without putting my own definition on it.
Dave2, It is interesting to see the differences in usage regarding the back button, which makes it all the more important to do user testing with your customer base. Unfortunately, I also find many users end up at the famous File Edit View menus of the browser.
Testing and analysing the existing applications are the only way to continue to improve our customer’s experience when it comes to this “new” type of web application and design. I just hope that companies realize this and spend the money up front, in order to save in the end.
In the end these web applications will work just like desktop programs across networks, and I’m sure future releases of the browser will support this approach.
Hi thanks for information.But i am not satisfied regarding ur doc’s.Please send one example to mail id as i given earlier.
problem:one webpage containing one or two text boxes and one submit button.If we press the submit button the data must goes to the servlet and displaying the data with out reloading the page.I need this example please.
If u people give this example then i can easily understand the real stuff.I hope that u will send.
As with several people, I’m coming in on the converstaion late. In my reading about the Ajax approach, here is what I’ve noticed:
“People complain about the ‘back’ button being broke.” Well, then Ajax might not be what you need for that particular instance. I’ve used several services online where the back button is useless or not even needed.
“You can’t use Ajax for …” Sure. I’ve never expected the Ajax approach to solve every problem. I’m a heavy Perl programmer. I don’t expect to solve every problem with Perl.
“The acronym Ajax is incorrect.” Whatever. It’s just a coined term. There are numerous acronyms and names that aren’t exactly correct. When I talk to people that understand what Ajax is, they also understand that you don’t have to use XML, etc.
I’m a technology whore. When a new technology comes out, I like trying to play around with it. I’ll play around with Ajax and see if I like it. If I don’t, then I won’t use it. I don’t need someone telling me, “It breaks your back button.” I say, “Really? Not the way I program it.” I think some people are trying to use it to replace something that’s not broken. I’m not going to go and try to re-write all of my webapps to use the Ajax method. They already work like they’re supposed to. If I do re-write some, it’s just to play around and see if it works.
i was wondering, is there any wawy in which AJAX can be modelled in sucha way that periodically the server sends responses, but the client doesnt request for it , like a page update or something. it more like TCP/IP based programming, if so how can it be achieved . plz help
polsih user forum: http://webdeveloper.pl/ajax,28,pl,0,0,forum_list.html
I write in the public sector and everything we do must be accessible, where possible to all users. Fine Firefox1.5 can do accessible DHTML but IE still has a huge market share which isn’t really going to shift much. In fact in the UK we have the Disability Discrimination Act which means by law sites should be accessible as well by 10% of the population with some form of disability. Shut your eyes and try using your ‘cool’ Ajax site?. Try using the tab key to navigate through it.
If Ajax is used to develop applications rather than for enhancing content then the search engine issue isn’t really a problem.
I think Ajax would be good for validating Forms on the fly as that can be a pain in ASP/PHP.
Designers/developers should be aware of this need and not get carried away with using Ajax, just because its been hyped and its this years flavour. Perhaps next year we’ll have ‘website duck’ or ‘domestos’
Im already developing an application with ajax, its one of the coolest techs I ever try. Its simple, elegant and you dont have to learn nothing new.
I been fooling around with .Net and Java, but Ajax + PHP makes the work easier, cleaner, and costless (since they are free, and uses less hardware).
Just try sarissa.js library.
Your clients will prise your name when they see what ajax its cappable of. For me, its the best choice for intranet app. (and better if you already have some xml sources working).
Announce in advance i’m yet a new guy who want to learn something like web application development, but I agree to Seth Steben and Mark Birbeck.
Why don’t we pay attention to XFORM, which could be an important standard for RIC.
I found ‘formfaces’ and ‘osp 3.0′, which you can seach from google.
A new type of reusable Ajax GUI Classes for JSP developers, which can be used as one uses GUI-API classes in Java/Swing:
I have been using the technology in AJAX for 6 years. It was interesting to me to hear about AJAX, as if were something new, and when I find out, that’s what I’ve been doing in my apps since 2006. It has it’s place and is very useful. I think anyone who talks about the browser history problems, back button issues, content not indexable by Google… does really understand how to implement what is now called AJAX.
Some reasons for using the technology, that are better than a roundtrip post include,
returning search results and returning database queries. If the data is in a database and the page is generated dynamically anyway, through regular asp or database objects, it’s not physically on the web page anyway, and Google doesn’t index that. The idea behind AJAX is porting information into/out of the page with minimal user distraction.
I have the technology throughout my survey program, at http://www.websurveypro.com/survey. Give it a try.
Alex Russell have recently written about COMET, the next stage of Ajax. Its the intresting to know the facts about COMET in coming future…
What’s the benefit in using xml over something else which uses a lot less data to transfer such as a pipe delimetered string? I have always thought that for something like this xml is a lot of overhead in tags to transfer to the client.
I think Ajax would be good for validating Forms on the fly as that can be a pain in ASP/PHP.
Ajax… no way. The surviving strategies are always simple and cross-browser, with for example Safari, some sites with Ajax are just blank pages. This is no web designing, this is wannabe-technology based on some spesifications, which do not apply in some cases and thus are something to merely forgot than remember.
I installed igoogle and I HATE it!! How do I get of the crap?
OK/Cancel is a comic strip collaboration co-written and co-illustrated by Kevin Cheng and Tom Chi. Our subject matter focuses on interfaces, good and bad and the people behind the industry of building interfaces - usability specialists, interaction designers, human-computer interaction (HCI) experts, industrial designers, etc. (Who Links Here) ?