Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×

An Ajax Reality Worth Worrying About 79

Posted by CowboyNeal from the ajax-world-order dept.
An anonymous reader writes "This article discusses the hype that currently surrounds Ajax and it's shortcomings. Reliable Ajax frameworks are still under construction, and you should worry about navigation history, bookmarkability, feedback, persistence, concurrency, and security. This article will help you avoid the major problems inherent in Ajax development."
This discussion has been archived. No new comments can be posted.

An Ajax Reality Worth Worrying About More

An Ajax Reality Worth Worrying About

Comments Filter:

  • Sessions (Score:3, Insightful)

    by shawngarringer ( 906569 ) on Thursday May 11, 2006 @06:28PM (#15313286)
    One thing I wish more webmasters would use on sites with AJAX and other technologies is sessions. When I hit "Back" in my browser, I want it to actually go back... not crap out and dump me completely out.
    I know... I know, I should be using whatever function is built into their website. But, I'm sorry, clicking Back or hitting backspace is just such a habit, its really a deal breaker for me...
    I have no idea how much time I've wasted refilling in forms on my bank's website because it cant figure out what I'm doing when I press back!
    • If you do online banking you really ought to check out Bank of America. I have an account there, and not only does back work, but it renders perfectly in Firefox (and for that matter, an old copy of Mozilla 1.0 I was forced to use). The interface for writing bills and scheduling payments is pretty nice too. My only complaint is that if you delete a contact with a payment scheduled to him, it deletes the payment as well as the default (that bit me when I wrote a final check to a utility when I moved then

      • Re:Sessions (Score:4, Interesting)

        by Dionysus ( 12737 ) on Thursday May 11, 2006 @06:51PM (#15313451) Homepage
        The BankofAmerica website even works with Konqueror.
        • All the bank sites I use work in Konqueror. On of them (Natwest) requires user agent spoofing, either to a recent version of Safari, or Mozilla Firefox.
      • Just make sure you block doubleclick.net in some way. The Bank of America site loads web bugs from doubleclick.net, even after you've logged in [spywareinfo.com]. I see them (adblocked) on the Accounts Overview page. It seems they were just doing this in the eastern US two years ago [google.com], maybe they're doing it elsewhere now.
      • I've also used the BofA site with Firefox for some time, and have had a good experience with it. One thing I have been wishing for (but having gotten around to trying to implement) is a way to download all my check images every month. I need them for tax stuff and insurance claims, but they only let you get at them for six months. After which they charge you several bucks for a copy, which I find annoying because I know it costs them nearly nothing to produce it!
        • Once they go offline they are probably stored in some sort of near-line storage (or worse, microfiche) that requires a human to retrieve and print. Then those have to be matched up with a cover letter and folded and stuffed into envelopes and presorted for the post office. Not quite "nearly nothing" to produce. They are probably losing money on check copies if not barely breaking even.

    • Blame HTTP Post (Score:2, Informative)

      by Anonymous Coward
      You can blame the HTTP Post mechanism for this. Do you want your confidential details appearing in a URL? No? Then you can't use GET, you have to use POST. And what does the POST spec [w3.org] say? Responses to this method are not cacheable. Not that this would work anyway; consider this, when you click back, is the old data still current? If you've just transferred money out of your account, then definitely not. The only way to ensure that customers don't see incorrect figures (which would draw too many complaints

      • Re:Blame HTTP Post (Score:3, Informative)

        by heinousjay ( 683506 )
        You don't need anything other than HTTP to support applications that don't require a constant connection. The redirect-after-post [google.com] technique does what you're looking for. It allows the browser view to always reflect model state, which is (or should be) the end goal.

        • You don't need anything other than HTTP to support applications that don't require a constant connection. The redirect-after-post technique does what you're looking for. It allows the browser view to always reflect model state, which is (or should be) the end goal.

          The interesting thing is that I, a total amateur, figured this out on my own when making my image gallery application, so how can any paid-for professional justify not realizing it ?

          Simply have each POST operation redirect to the same page a

    • I know... I know, I should be using whatever [back] function is built into their website.

      Don't excuse poor usability. Your browser already has a back button which as you say is often used reflexively. That's a good thing. Webpages that break your learned navigation skills are bad as they cause needless frustration and require uncecessary relearning. Sure, it's not a huge deal in the grand scheme of things, but add up a million tiny frustrations and before you know it you're tearing your hair out and gett

    • I would highly reccommend any one that even begins to contemplate using ajax in their web app to check out the Dojo Toolkit [dojotoolkit.org] and it's IO::Bind functionality. It transparently handles back/forward functionality and deals with bookmarkability quite well as long as you use it correctly. For small AJAX tricks like google suggest-esq autocomplete, this is a moot point, but if you are writing a serious web app that relies on asyncronous communication with the server, you need to deal with these issues.
  • ...but I can't take anything from IBM on web design seriously when their article renders in a tiny little font. If that wasn't enough, they actually go to the trouble to create and apparently use acronyms for "Tipping Point" and "Paradigm Shift". Great, now we get acronyms for buzzwords in a technical article? They're specifying font sizes in pixels, too. Shame on them.
    • Font size is the easiest thing there is for the end user to adjust to their preference if the page is designed correctly. My eyes are not at all good, but a couple of taps on ctrl+ made this page quite easy to view.

      What REALLY ticks me off about working with some designers is when they want to place text on a page in the form of images so they can force the user to look at the design exactly the way they want it shown.

      • Well, it makes some degree of sense since there is no means for sending font data to browsers. You can use sIFR but I'm not sure how it handles resizing, I haven't tried. I suppose you could also use a SVG graphic whose size is specified in ems, but that will only work in firefox 1.5+, or for people who have an SVG plugin. This does seem like it makes the most sense, though. Flash sucks.
        • Text as images has so many problems that there is no excuse for it. Anyone with any kind of disability has problems with it, the images are far slower to download, and making the text dynamic is nearly impossible.

          The main culprit as far as I have seen is people working as web designers who started as print designers. They are used to having their design rendered exactly as they envisioned it, but that is not how html works so they try to force it to the detriment of all concrned.

          • Text as images has so many problems that there is no excuse for it.

            If done badly, yes.

            Anyone with any kind of disability has problems with it, ...

            Are you aware of text image replacement [google.com]? Those of us who use it understand well how to create sites accessible to people with disabilities [webstandards.org]. Your remark suggests otherwise.

            ...the images are far slower to download, ...

            Thanks for the news flash. We'll take it into consideration.

            ...and making the text dynamic is nearly impossible.

            No, it is not [alistapart.com].

            • The articles that your search results point to generally contain warnings that text replacement techniques cause accessability problems. And as far as dynamic image creation, I dare you to try that on a server that is under any kind of significant load.

              Give it up. Text as images is a WTF. [thedailywtf.com]

            • >>Text as images has so many problems that there is no excuse for it.
              >If done badly, yes.

              it is *always* done badly. it is a bloody stupid practice, and there is no excuse for it.

              text-as-images makes the incredibly stupid assumption that the viewer's display is the exact same size and resolution as the author's display - if the viewer has a large, high-resolution display (e.g. 21" at 1920x1440) then any textual images created at, say, 1024x768 (or, worse, 800x600) will be unreadable.

              this is annoyin

      • Font size is the easiest thing there is for the end user to adjust to their preference if the page is designed correctly. My eyes are not at all good, but a couple of taps on ctrl+ made this page quite easy to view.

        Tapping ctrl+ gets old real quick, especially if you do a lot of page-hopping on a bad site. Fortunately Firefox/Mozilla users can enforce a minimum font size through either the font preferences panel (fails on a lot of sites) or a personalized userContent.css. If you wanna go the extra mil

      • Font size is the easiest thing there is for the end user to adjust to their preference if the page is designed correctly.

        I think the point being made by the post to which you are replying was that because the font size is specified in pixels, the text can't be resized by anybody using Internet Explorer for Windows, up to and including version 6. As you say, the page needs to be designed correctly, and specifying font sizes in pixels is wrong for as long as the dominant browser has this misfeature.

      • The issue is the credibility of a page on the topic of website design. It is easy enough to say that a web page is a bit like an ink on paper page and to translate print layout ideas to the web by analogy. So there is no need to read other persons vague analogies.

        The reason for reading somebody else's views on website design is the hope that they might have attempted to do the hard stuff, responding to the web as something new and thinking the principles of layout through from first principles. An obvious

        • A writer on website design who fails this basic test cannot expect readers to go to the trouble of using ctrl+ to read his pathetic drivel.

          The author's title at IBM is "Performance Engineering Team Lead". His bio mentions that he has worked on user interfaces in the past, but there is nothing to suggest that he is responsible for the www-128.ibm.com design.

    • Indeed, TP and PS are very, very annoying.

      • Take a look at the medical journal The Lancet. Its paper version is mailed all over the world and the publishers economise on mail costs by using small type on thin, high quality paper. Obviously one uses abbreviations to avoid wasting paper and incurring avoidable transport costs.

        What are abbreviations doing on web pages? Literate adults tend to recognise whole words or even whole phrases. Decoding the abbreviations slows us down. Sometimes we don't recognise the abbreviation, which brings us to a halt.

  • Ajax is not the problem (Score:5, Insightful)

    by Umbral Blot ( 737704 ) on Thursday May 11, 2006 @08:03PM (#15313933) Homepage
    The real problem with Ajax isn't java script or browser fickleness, or Microsofts hatred of standards, it is that we are trying to solve one a problem, distributed applications over the internet, within the wrong framework, a document viewer with scripting capabilities. What we really need is an internet application browser, that is desgined to be able to host such applications, render consistantly over multiple platforms, be stable and secure, ect. Then users wouldn't be confused concerning the behavior of the back button for example, because no one expects applications to have a back. It might make sense to have the broweser be able to launch the application viewer when needed, but more than that is just begging for problems.
    • Ten years ago, Java was so trendy that Netscape chose to name their scripting language JavaScript despite the fact that it had virtually nothing in common with Sun's language.

      I find it deeply ironic that after Java failed to transform the face of computing into a network-centric model, so many dollars are being funneled into JavaScript development for applications intended to supplement or replace native ones.
    • I think applications should have back buttons. Being able to undo everything is a brilliant concept.
      • I think you are confusing back and unod. If you POST data to a website, hitting the back botton does not undo that post. In fact, browsers even warn you when you go back to a POSTed page, saying that you might redo (rather than undo) the operation, which may cause problems.
        • True, but hitting back SHOULD undo anything that is possible. It'd be nice if it'd send some sort of special signal on back so that site's could undo. A built-in transaction model would be good too so that transactions could be started, rolled back, or committed in such a way that the whole task would group back and forward actions in a way that makes sense.

          Is the web to the point where it needs to improve the back and forward model without completely tossing it? What about refresh and stop? It all seems it
          • I not sure I agree with the statement that back SHOULD undo if possible. My concern is that this would essentially overload the back button to have two functions (navigation and application state). As a user, I would hate having to wonder if the site I'm browsing supports undo-on-back. However, as a user, I'd hate to have a new button to worry about.

            As for improving the back/forward, refresh, and stop issues, I don't think they are broken enough to justify changing them. I don't think they could be made si
            • I think apps should have to make it clear if back is functioning as an undo. Maybe if they had to overload the back button the back button could change colors and offer an option to prompt for permission to undo? "Doing this will undo your last change. Are you sure you want to continue? [Yes], [No], [Go Back]" I think in applications that back as undo and forward as redo makes sense but you have to make clear to the user when they are in an application and when they are in a document. Back as undo is a comm
    • Oh, you mean like NeWS [wikipedia.org], which was actually designed for efficient and elegant distributed applications?

      Nebekh it was never open-sourced.
    • Yes and no. It's true that asking a web browser to become an application client is a deadly blunder, but the underlying problem is that few sites today serve static content anymore. It's all about logins and forums and customization. Essentially we're going back to the 80's and 90's with BBS'es, where each sysop would painstakingly tweak and customize their server to offer a unique experience. Myself, I ran Maximus and I had pretty much rewritten every function using the MEX scripting language built int
    • You're absolutely right, but unfortunately the browser is the most widely distributed application delivery platform today. XUL might be nice and all, but it is supported on very few desktops. It's actually quite amazing how closely a modern web app can be scripted and styled to behave like a traditional application. As these web applications become more and more sophisticated they are increasingly outgrowing the traditional forms-based web paradigm, and features like the Back button can indeed become quite
      • Sort of the like Back button in Windows Explorer, that you somehow instinctivly hit every once in a while but inevitably doesn't do what you want.


        Funny, but I hit the back button in Konqueror all the time and it does exactly what I want, both when browsing the web or my local files.

      • I think you are correct with your comment about the back button. People claim that AJAX will break the back button, but as already stated, the back button doesn't always work with the normal style of dynamic website we're all now familiar with.
    • That's exactly what Java applets do. If you want to run an application in the browser, that's the appropriate mechanism.
      • Comment removed based on user account deletion

        • Trouble with FreeBSD too. I installed Firefox painlessly using the package system, but it came without Java because of some licensing issue that I didn't understand. My response has been to ignore websites that depend on Java. It is not as though I have read all the non-Java websites on the web and now have spare time to piss about with Sun's license SNAFU :-)

    • The whole advantage of AJAX is that it's available from pretty much any computer with internet access, due to the ubiquity of browser software. If I have to download a special "application browser" to run these apps, I might as well just download a real, compiled executable and get better speed out of it.
      • I think what the gp was saying wasn't that such a technology doesn't exist, but that there is not yet a standard "application browser" that is ubiquitous enough that it can be relied on.
    • --"no one expects applications to have a back"--

      I suppose no one expects applications to have undo/redo either...
    • Have you ever seen Rebol? Check out http://www.rebol.com/ [rebol.com]. I messed with it a bit in the past, and it kind of comes close to what you are talking about, although it has a very different programming syntax!

      SixD
    • What we really need is an internet application browser, that is desgined to be able to host such applications, render consistantly over multiple platforms, be stable and secure, ect.

      Well you've just described the rewritten (with applications in mind) and improved Flash 9, coming in 3 months...

      Even better, Adobe will release a free compiler and component framework for Flash 9, so the barrier of entry is $0.
  • Morfik http://www.morfik.com/ [morfik.com] has already worked on these issues and deal with them so you don't have to lift a finger when you build your application. Atlas is (reportedly) going to (eventually) make all of these issues go away as well. Since Atlas isn't handling these issues yet I can't comment on how elegant it is, but Morfik is unbelievable. States are just handled. Bookmarks, back, forward, and reload buttons are no longer an issue. What's even cooler about Atlas and Morfik is that they are RAD ID
  • I have been always worried about Ajax' impacts on current web analytics software (e.g. AwStats, WebTrends, Google Analytics?, etc., almost all of them are page or logfile based). How will they be able to track Ajax applications if there is no new page loads, tags?
    • AJAX still uses page requests, albeit in a rather exotic way. If you have a peak in calls to `functions.js`, you know you have a bunch of people starting sessons; if you have a peak of hits to `dynamicRefresh.php`, you know you have a bunch of people using your application. It's not hard, it just takes a slight "PS" (paradigm shift, TFA).
    • Why not just get a new bit of analytic software? In years of using different packages I've yet to see one I liked anyway. I use my own and it analyzes a lot more than any of the off-the-shelf options I've seen. I want to know everything about the people at my sites.
  • Ajax is wonderful, but it's not necessarily secure out of the box. I wrote about this back in February:

    Ajax security presentation for OWASP
    http://www.greebo.net/?page_id=329 [greebo.net]

    Just because Ajax is being used should you abandon years of security knowledge.
  • "When we were young, we were told that 'Everybody else is doing it' was a really stupid reason to do something. Now it's the standard reason for picking a particular software package." -- Barry Gehm

    I feel the same about AJAX! :) It may have improved the user interface and the browsing experience a lot, but AJAX pages eat up so much memory! Maybe its an issue with the browser implementation, but it does drag the system's responsiveness down. One should really think about it before one decides to go for AJ

  • goodbye accessibility (Score:3, Insightful)

    by Eil ( 82413 ) on Friday May 12, 2006 @09:33AM (#15316829) Homepage Journal
    Allow me to play devil's advocate for a moment here...

    Let's not also forget accessibility and backward compatibility. Neither of which you have if your site heavily relies on Ajax. Ajax is fun and all, but if you build a site or application that relies on Ajax (as so many do these days), you're completely leaving behind those with disability that prevents them from using a graphical browser and those who can't or won't use the latest versions of IE, Firefox, or Safari. (Let's at least be honest for a moment and admit that those are the only three browsers that Ajax authors ever attempt to target and even throwing Safari in there is a bit of a stretch.)

    For awhile there, we were making good progress toward better adherence to web standards. Now it seems like "oooh shiny!" is rapidly taking over web design again.

    Of course it's possible to build a site or application that is backwards compatible and accessible and thus uses Ajax only as a enhancement. But if the site works just fine without Ajax, why would you waste time implementing a few extra Ajax features just for show?

    • Of course it's possible to build a site or application that is backwards compatible and accessible and thus uses Ajax only as a enhancement. But if the site works just fine without Ajax, why would you waste time implementing a few extra Ajax features just for show?

      Most of your comments are right on the money - if you are building a site that relies on AJAX, you are building incompatibility into the site (for now).

      However, I must take exception with your last statement. Just because a site "works fine

    • There are people out there that are aware of the current pitfalls and limitations of AJAX, and use it in an appropriate way. My site worked fine without AJAX, albeit with the overhead of unnecessary page reloads and having to send and receive superfluous data with each request/response. Now I've used AJAX techniques in certain places to enhance the functionality and it works fine, not least of all the transactions to and from the server are now smaller and quicker and there is no need for a complete page

  • Stop the presses! (Score:1, Funny)

    by Anonymous Coward

    Reliable Ajax frameworks are still under construction, and you should worry about navigation history, bookmarkability, feedback, persistence, concurrency, and security.

    Stop the presses! Someone has discovered that AJAX applications should follow the same usability guidelines that have been researched, reported, and [often to a lesser extent] used in all other applications.

  • Those very relevant AJAX problems boil down to two: state management and security (including state integrity/privacy). So state management is the #1 priority for making AJAX apps work. Client-side cookies are about to finally gain the recognition they deserve for their necessity in handling those factors.

Slashdot Top Deals

"Protozoa are small, and bacteria are small, but viruses are smaller than the both put together."

Close