Ajax Sucks Most of the Time 510
Vo0k writes "It seems that everyone is excited with what AJAX promises, and only few look at what it breaks as well. The article at Usability Views offers a critical view at the new Microsoft technology, pointing out some problems it creates, like breaking bookmarking, making the 'back' button useless, problems with printing, accessiblity and more. The single-sided view from the article provides a good counter-balance for all the craze."
as in all new directions... (Score:5, Insightful)
Up front Disclaimer: I realize the article is "just saying no to Ajax" with constraints. My post here is to the objection I think the article states Ajax problems too harshly.
Reading the article it seems to me:
From the article:
Huh? So? Is this unique to only Ajax?
Also from the article:
When an article wants to rant or complain about a technology, an un-cited and broad statement like this is a huge red flag. It doesn't state what the percentages are, it doesn't state the reasons for preferences. In the middle of an article espousing "no Ajax", this is a non-sequitor. Please expand.
I'm having great fun experimenting with AJAX and am getting interesting new approaches for old solutions improving customer and user experiences. I'm not about to walk away from this until a more thorough trial. So far I'm liking what I'm seeing. Yeah, there are glitches to solve, isn't that kind of what we're here for?
Misleading (Score:4, Insightful)
Sure, putting ajax on the companies webpage may not be the best idea, but how often are you using bookmarks on gmail (a web application)? And if you want to print from gmail, it shouldn't be a print of the screen, but a specially built printable html page.
I think the article writer was focusing mostly on webpages where AJAX is clearly geared towards the web application developer.
Implementation (Score:5, Insightful)
ajax (Score:5, Insightful)
Improving web accessibility? (Score:3, Insightful)
Wouldn't it be nice if Frontpage or Mozilla Composer would allow a plain HTML page to be saved and linked along side one with javascript, flash, and other advanced web designs?
It really annoying too how Tab-clicking at javascript link ends up producing a blank tab in Firefox. That AJAX breaks the Back button is nothing new too. All sorts of sites tell you that you'll be re-submitting data if you press Back on a screen you've just sent information from. That's essentially a broken Back button. And printing a webpage? Good luck if it isn't plain HTML.
Nielsen? Never mind. (Score:1, Insightful)
I am a strong proponent of usability and user interface issues, but this guy doesn't even like using different colours for links.
What does interest me is he makes a lot of money by going around telling people this. I want to get in on that action.
Not always that bad. (Score:5, Insightful)
1) Content.
2) Applications.
For (1) ajax _does_ suck most of the time for all the reasons stated, but for (2) is makes sense because it makes the app behave more like a desktop app. "back" and "bookmarks" stop making sense anyway. You wouldn't expect to have those features in your desktop apps, so why in an app delivered over the web.
The great shame is that these two opposing requirements have not forked into the data-web and the application-web. Things went wrong IMO the day someone thought of putting forms in html.
Re:Misleading (Score:5, Insightful)
Sure, putting ajax on the companies webpage may not be the best idea, but how often are you using bookmarks on gmail (a web application)? And if you want to print from gmail, it shouldn't be a print of the screen, but a specially built printable html page.
I think that pointing these things out NOW is a great idea being that AJAX is now one of the biggest buzzwords in the industry. With marketing and management raving about AJAX and demanding AJAX applications be put everywhere including locations they shouldn't be, I think it's about time someone put an article out there that describes the negative effect that AJAX applications could have on the web.
Hopefully more media outlets will start picking this up and not just touting the successes of AJAX. Remember, buzzwords = $$$ in the eyes of those that are clueless.
Flash (Score:5, Insightful)
Some flash developers get what I call "flash happy" and write the entire website in flash. This is lunacy. For a start, (and this is possibly a problem with AJAX heavy sites too) your site cannot be indexed by any search engines if it's navigation is entirely flash based. No search engine in the world is going to evaluate your flash files or run your AJAX scripts in order to attempt to crawl the site. If AJAX is used sparingly where necessary, then I'm pretty sure it won't cause any major problems. It's not like Flash seems to have suffered...
Re:It's a spoof (Score:5, Insightful)
Re:It's a spoof (Score:5, Insightful)
When is a spoof not a spoof? (Score:4, Insightful)
It's interesting to note that while the article is apparently a spoof, many of the objections still apply. (Sure, this is way over-generallzing, but work with me here for a minute.) Also, note how frames went through a period where everybody used them, then use gradually taper off. I think people realized that much of the time, frames just got in the way and the "old ways" worked just as well, if not better.
It does seem like the computer world loves to make the same mistakes over and over and over and over again. We keep doing it. (ObRef to The Mythical Man-Month by Fred Brooks.) What's that about not learning history?
Re:as in all new directions... (Score:5, Insightful)
I swear, I've heard the same argument about PHP, Perl, C, and even the concept of object oriented programming. In every case the person uttering those words was an idiot or simply too entrenched in their chosen language to accept a new way of doing something. It all reminds me of a line from Scott Adams' Dilbert Principle. As best as I can recall it went something like this.
"Every technology has its detractors. I'm sure that somebody once stated that the pointy stick would never replace the fingernail as the fighting man's weapon of choice."
As for my disclaimer, the only thing I know about Ajax is that its not effective as Mr. Clean.
Flash (Score:2, Insightful)
The main problem is people want to be able to serve miniature applications via the web, whilst even with new standards it's still about providing glorified word documents with a smarter navigation.
Huh? (Score:3, Insightful)
Let's get a few things straight (Score:2, Insightful)
-- quoted from http://developer.mozilla.org/en/docs/AJAX [mozilla.org]
In otherwords the technology is not new and isn't a Microsoft Technology. Although to give them due credit they did invent the XMLHttpRequest object which makes AJAX possible.
Personaly I think the article is nothing more a than an annoying rant. Every technology has it's weeknesses and it's strengths. And just as you should do with any technology you must weigh up the pros and the cons of using it for your specific goal before you do. Saying something is trash and that it should not be used at all for anything is down right stupid.
Re:as in all new directions... (Score:4, Insightful)
For "valid at one point" consider using "always valid".
Re:An odd complaint here.... (Score:3, Insightful)
Sure, it can be moved -- but that doesn't mean it should be [w3.org]. Keeping a page at a particular location makes it much easier for people to find it, whether via search engines, their own bookmarks, links on other sites, etc.
This doesn't mean it can't change. Linking to, say, a product page on Amazon is extremely useful. You can expect the price, reviews, recommendations, etc. to change over time, but you should expect the same product to be there the following year as long as they still sell it.
All of this can be solved (Score:5, Insightful)
And yes, we've had all of this from day one - months before google maps. Admitted, many AJAX apps still dont bother to do any of this - I'd say let's adress that instead of abandoning AJAX.
Re:Flash (Score:4, Insightful)
Except perhaps...er... what was the name of that search engine...you know...er...
Re:It's a spoof (Score:3, Insightful)
so close... (Score:3, Insightful)
My first clue that something was wrong with this was in the article summary... since when is AJAX considered a "Microsoft technology" ? If there's a defining AJAX app, isn't it Google Maps ? Is there some Microsoft AJAX app or developer kit I should be aware of ?
I'm going to have to disagree with something you've said, though :
we all need to evolve past the "You are looking at a flat page" ideology.
Why ? Flat pages are very useful for documents. Hyperlinks are great for linking documents. "Plain old web pages" remain, IMHO, the most useful aspect of this thing we now call "the web"... cool apps like Google Maps are cool and all, but they'd be just as cool ( probably cooler ) outside of a browser. Requiring a high-speed connection and robust ( or even particular ) Javascript implementation on the client side just to view your web page is what doesn't make sense, at least to me.
Then again, maybe I'm just getting old, but back in the day, we just had static web pages and forms, and we liked it!
Re:as in all new directions... (Score:5, Insightful)
The author talks about how "the page" is the basic idea that was behind the Web. Well, I hate to break it to him, but after 12+ years, things have evolved. The notion of the page has long since been an area of limitation with web applications and usability. This is why we've seen the uprising of many technologies in an effort to have more dynamic content interfaces. Users don't like having to wait for a full page load to make a small request within an application. There is complaint about the time it takes. Granted, this is largely a perception thing, but it is the reality of users.
The type of information being presented on the web has gone beyond thesis papers and simple static articles. The information that users are becoming used to is more complex, as the average user's understanding of relational information grows.
Now, the author does make some good points... but mostly these are when using AJAX in "pages". In this respect, I agree that overzealous, and possibly inexperienced web developers have gone overboard. But a good web developer considers the effects their choices have on a user, and they make the choice to go with one advantage over the loss of another. I am conscious that search engines can't necessarily index my content... so what! If I don't want it to be indexable, so be it... they can index the more "content" oriented parts of my sites, and users can then find the "features" and applications that use better technologies. The complaint about printing... please! A best practice is to take length articles and break them up into multiple pages. Ummm.. this has the same problems with printing. He kind of neglects to point that out.
As was stated previously, many of the arguments are presumptuous that the web is all about "pages". I also question the interpretation of his statistics. 1. Old browsers are likely unpatched browsers. With the vulnerabilities and security issues today, compatibility with AJAX is the least of their problems. Upgrade! 2. Mobile browsers have problems with MOST page content. Websites are designed for a minimum of 800x600 these days, if not 1024 wide. Websites still need to provide special pages to serve up content to mobile devices anyway.
So, I know this is a spoof article by the author about a previous article about Frames back in the 90's... but I think he sticks too much to the premise that existed back then, that the web was all about simple content and "pages", without recognizing that the information complexity has evolved, and that "applications" are becoming more and more necessary for usability of the information. Yes, improvements are needed. Yes, back button support should be support (but not required). Also as was said in an earlier post, many of the problems are not an issue with just AJAX, and many are an issue with the lack of understanding of the effects of the choices made when using ANY new technology.
-Alex
Re:as in all new directions... (Score:4, Insightful)
Personally, I think it's great for UI tricks and acynchronous form actions (checking for currently used user names, submitting to a shoutbox, and so on). If people think AJAX itself is bad, they should see the comments on Digg to AJAX articles. There are more comments like "If I see one more damn article on this..." than there are dupe notification comments here on Slashdot!
I think this new use of JavaScript has great potential, but the real message of the article can be gleaned in the first few paragraphs: Don't go overkill.
Re:The wiki is wrong - history lesson (Score:3, Insightful)
IFrame refresh hacks are not "asynchronous" because the user can see them happening, just by watching the browser load icon.
They also break the back button even worse than Ajax. With Ajax at least the back button takes you back a page, if you are doing iframe nonsense and do not know what you are doing (ie, using location = instead of location.replace) it frequently just moves the iframe back a page, resulting in it doing nothing, or worse, sending/retrieving duplicate data.
Re:The wiki is wrong - history lesson (Score:3, Insightful)
That's not quite what being asynchronous means. Asynchronous means not sitting idly by waiting for a (remote procedure/http) call to finish. For example; while you're loading one thing, you might be sorting a table of data (even if the javascript isn't even on the page, check out the handy sort table bookmarklet [squarefree.com]).
It's OK for the user to know things are going on in the background; for example, when you press the Print button in Microsoft Word, it doesn't make you wait for the print job to finish, it continues in the background. You won't get your hardcopies any sooner (so you might still have to wait for that job to finish to do the next thing you have to do), but the program isn't stuck waiting for the call to finish.
The Gmail interface is actually not such a good example of asynchronisity. It makes you wait while it's sending mail, for example..
An (I)frame refresh hack might be slightly more visible, but if you can still use the application (i.e. its javascript functionality), it's still asynchronous.
Re:as in all new directions... (Score:2, Insightful)
I mean -- look at these 'statistics'
The November 1996 browser statistics from Interse show the following distribution of browser usage:
Netscape 2: 13% of users
Netscape 3: 47% of users
Internet Explorer 3: 28% of users
Other browsers or earlier versions: 13% of users
Percentages sum to 101% due to rounding. Thus, 13% of users would not even be able to see a site with frames.
[Frames Suck Most of the Time (Jakob Nielsen's Alertbox December 1996): Link: 9612.html [useit.com] , Dec07th, 2005]
Great when used for appropriate situations (Score:2, Insightful)
If you save AJAX for the projects that will actually benefit from it you will benefit from it much more, instead of annoying your end users.
AJAX is for on-line applications, using it everywhere is not a good idea.
Example of poor use:
A site that uses AJAX for navigation across the entire site. In this situation you now can't bookmark a specific article or piece of text, nor do you necessarily (depending on the site) have the ability to bookmark that particular section.
Example of a good use:
I built an on-line calender for scheduling various events within my organization. Before I added AJAX to the code the entire monthly calender view had to be reloaded on when you click an event to zone in on its details. The old way caused the entire months summary to be reloaded, reparsed, etc just so the end user could see the details for one event. Now that it uses AJAX one can click each event and have the details load almost instantly without regenerating the entire month view.
AJAX is the new XML (Score:2, Insightful)
AJAX is a tool like any other. Like XML before it, all the hype will cause it to be used and abused for all sorts of things for which it is not suitable (remember "We don't need a database, we have XML!"?)
After the hype subsides, AJAX will become just another tool to be used when appropriate and eschewed when not.
Re:as in all new directions... (Score:3, Insightful)
It seems that almost everyone that argues against me on this keep bringing up simple, static, content pages as their support. But if you people bother reading my postwith the context of THAT POST (as opposed to the bucket your charged up brain has placed it into), you'd see that I am focusing on Web Applications. These are not pages that generally need to be bookmarked. These are not pages that NEED a back button.
I mean, bitch about the limitations of Banking websites all you want. The dynamic content is what allows you to HAVE a banking website. The limitations have little to do with the JavaScript or AJAX. The limitation that you can't go BACK on those pages has to do with general state and flow management. And the "Back button" issue that you mention has nothing to do with the "Back button" issue the article's author mentioned. Your back button issue has existing since the beginning of dynamic web pages/web applications. It is specifically THESE limitations that have driven technologies like AJAX. I mean, if you process a transaction for a transfer, and then try to hit "back", bringing you back to a processing page and the interface just lets you... you're more likely to make a mistake of retransferring money (duplication). The choice your bank made is to not let you go back. Others handle it by just not processing a resubmit on a transaction, but let you back button all you want. Another option would be to use AJAX within the scope of a transfer transaction "application". Hitting the back button would take you to the page you were at before the transfer request. This would actually be idea, since loading into the middle of a completed transaction's form is simply "invalid use".
Hmmm... I think your issue with your bank's "back" button restrictions is actually an argument FOR something like AJAX!
So, once again... your arguments are not with AJAX or similar technologies. Your argument seems to be against poorly implemented applications. The back button issue you descrobe, not allowing simultaneous windows, etc... these are not issues with AJAX or similar technologies. These are issues with the back-end session and transaction management of the application. But since much of that level of backend development isn't inherant to existing frameworks, it becomes a lot more development (and QA/testing) to support. AJAX could actually help alleviate your specific issues, by reducing the client behavior that causes banks like yours to be so restrictive.
-Alex
Re:as in all new directions... (Score:3, Insightful)
Re:as in all new directions... (Score:2, Insightful)
Hint #1: I don't like web applications. Gmail is all nice and cool, but I don't give a damn about it, I'm very happy with my IMAP server.
Hint #2: *I* will decide what I want to bookmark and what not, thank you very much.
Hint #3: *I* will decide when I want to use the back button, instructions not to use it will never cease to annoy me.
And yeah, I know about the back button being a way to re-submit a transaction. But any bank should be sane enough not to process it again, which is exactly what I want: To go back to the previous page, without harmful consequences.
The particular problem with my bank comes in even before attempting a transfer. I have two accounts, numbered something like #2342342343 and #2342342532. The balance screen lets me see my balance. The transfer screen lets me make a transfer. However, since it's dumb enough to show me just account numbers, sometimes I want to go back to the previous screen (balance) to find out which is which. At this point the site complains that I shouldn't use the button, and forces me to start the process from the beginning, of course losing any data I had already entered in the form. All of this is before trying to confirm the transfer.
I fail to see why couldn't there be "balance.cgi", "transfer.cgi", and "rechage_cell_phone.cgi", and a complete lack of all this weird magic.
If the bank for whatever reason wants to offer a richer interface they can do it perfectly well with say, a Java application which won't have any of the problems all this AJAX mess has.
Re:as in all new directions... (Score:3, Insightful)
I said it was a possible solution to the "issues" you stated regarding your banks interface. Your issues have little to do with AJAX, JavaScript, or any other scripting. They are issues inherant to a web application not designed to handle specific cases as gracefully as you would like (but they could, if designed to).
Um... your bank interface is a web application. Search engines are web applications. Pretty much anything that does logical user interaction is a web application! So, you don't care for most websites these days? Oh yeah, slashdot is a web application!
Interesting. Can you bookmark results on POST submits? No AJAX, but certainly can't be reflected in a URL. But then again, form submissions/results are a web application, but I forgot... you don't like using them.
Not if the site is designed to not give you the page. Considering that the website is likely more responsibile for effects of misuse, are the ones that DESIGN and GIVE you an interface and workflow to use, I think it's well within their right to control workflow on THEIR website. If you don't like it, don't use it. Now, a properly designed site will make these choices either seemless or unobtrusive to their users. So, again, you aren't complaining about AJAX, JavaScript, or other scripting, but rather a poor implementation. But place blame with it belongs, not on the first thing you notice to be related to the issue.
What crack are you smoking? Do you KNOW what AJAX is? AJAX is not something that is going to send up a warning because you hit your back button. That's JavaScript, yes... and probably what I'd call annoying as well. But AJAX is a way for a single web page to make requests behind the scenes without stepping from page to page. If AJAX were used for specific transactions, hitting your back button would present NO risk as it sounds like there currently IS with your bank. There would be a "transfer" page, and the steps of the transaction would not load a new page, but just be handled on that one page with requests done in the background. You could then hit back and forward all you want with little risk to transaction or your account. It would give you the freedom to use your back button without stepping into pages that are invalid or "dangerous", but still go to pages that ARE stable landing points.
And as for using Java as a solution to your issues? Why would this be? Java is just another programming language for the backend, unless you're talking about a servlet. It is prone to the exact same problems as PHP, Perl, C#, ASP, or even C (God forbid) would have in a stateless protocol. If something that uses Java on the backend IS behaving better, it's only because the implementation of the site has chosen to handle flow control better. But this could be the same regardless of the underlying language.
AJAX, as I said could be ONE solution to help with the problems you mentioned. Personally, I think it would also make the overall "steps" easier
These Articles are foolish (Score:2, Insightful)