Here’s the original post on my blog.
New: Add your own mistake or edit this list
List
Notes
Using Ajax for the sake of Ajax Posted 6 Jun
Sure Ajax is cool, and developers love to play with cool technology, but Ajax is a tool not a toy. A lot of the new Ajax applications are really just little toys, not developed for any real purpose, just experiments in what Ajax can do or trying to fit Ajax somewhere where it isn’t needed. Toys might be fun for a little while, but toys are not useful applications.
Breaking the back button Posted 18 May
The back button is a great feature of standard web site user interfaces. Unfortunately, the back button doesn’t mesh very well with Javascript. Keeping back button functionality is a major reason not to go with a pure Javascript web app.
Not giving immediate visual cues for clicking widgets Posted 18 May
If something I’m clicking on is triggering Ajax actions, you have to give me a visual cue that something is going on. An example of this is GMail loading button that is in the top right. Whenever I do something in GMail, a little red box in the top right indicates that the page is loading, to make up for the fact that Ajax doesn’t trigger the normal web UI for new page loading.
Leaving offline people behind Posted 6 Jun
As web applications push the boundaries further and further, it becomes more and more compelling to move all applications to the web. The provisioning is better, the world-wide access model is great, the maintenance and configuration is really cool, the user interface learning curve is short.
However with this new breed of Ajax applications, people who have spotty internet connections or people who just don’t want to switch to the web need to be accomodated as well. Just because technology ‘advances’ doesn’t mean that people are ready and willing to go with it. Web application design should at least consider offline access. With GMail it’s POP, Backpackit has SMS integration. In the Enterprise, it’s web-services.
Don’t make me wait for Ajax Posted 6 Jun
With FireFox tabs I can manage various waits at websites, and typically I only have to
wait for a page navigation. With AJAX apps combined with poor network
connectivity/bandwidth/latency I can have a really terrible time
managing an interface, because every time I do something I have to wait
for the server to return a response. God help me if it has to go to the
server’s disk before I can continue. Apps like that might even make me think Ajax wasn’t cool.
Sending sensitive information in the clear Posted 6 Jun
The security of AJAX applications is subject to the same rules as any web application, except that once you can talk asynchronously to the server, you may tend to write code that is a very chatty in a potentially insecure way. All traffic must be vetted to make sure security is not compromised.
Assuming AJAX development is single platform development. Posted 6 Jun
Ajax development is multi-platform development. Ajax code
will run on IE’s javascript engine, Rhino (Mozilla’s js engine), or
other minor engines that may grow into major engines. So it’s not
enough just to code to JavaScript standards, there needs to be
real-world thorough testing as well. A major obstacle in any serious
Javascript development is IE’s buggy JS implementation, although there
are tools to help with IE JS development.
Too much code makes the browser slow Posted 18 May
Ajax introduces a way to make much more interesting javascript applications, unfortunately interesting often means more code running. More code running means more work for the browser, which means that for some javascript intensive websites, especially poorly coded ones, you need to have a powerful CPU to keep the functionality zippy. The CPU problem has actually been a limit on javascript functionality in the past, and just because computers have gotten faster doesn’t mean the problem has disappeared.
Not having a plan for those who do not enable or have JavaScript. Posted 6 Jun
According to the W3C browser usage statistics,
which if anything are skewed towards advanced browsers, 11% of all
visitors don’t have JavaScript. So if your web application is wholly
dependent on JavaScript, you’ve immediately cut a tenth of your
audience.
Inventing new UI conventions Posted 18 May
A major mistake that is easy to make with Ajax is: ‘click on this non obvious thing to drive this other non obvious result’. Sure, users who use an application for a while may learn that if you click and hold down the mouse on this div that you can then drag it and permanently move it to this other place, but since that’s not in the common user experience, you increase the time and difficulty of learning your application, which is a major negative for any application.
Changing state with links (GET requests) Posted 18 May
As I’ve referenced in a previous posting, Ajax applications introduce lots of problems for users who assume GET operations don’t change state. Not only do state changing links cause problems for robots, users who are accustomed to having links drive navigation can become confused when links are used to drive application state changes.
Blinking and changing parts of the page unexpectedly Posted 18 May
The first A in Ajax stands for asynchronous. The problem with asynchronous messages is that they can be quite confusing when they are pop in unexpectedly. Asynchronous page changes should only ever occur in narrowly defined places and should be used judiciously, flashing and blinking in messages in areas I don’t want to concentrate on harkens back to days of the html blink tag.
Not using links I can pass to friends or bookmark Posted 18 May
Another great feature of websites is that I can pass URLs to other people and they can see the same thing that I’m seeing. I can also bookmark an index into my site navigation and come back to it later. Javascript, and thus Ajax applications, can cause huge problems for this model of use. Since the Javascript is dynamically generating the page instead of the server, the URL is cut out of the loop and can no longer be used as an index into navigation. This is a very unfortunate feature to lose, many Ajax webapps thoughtfully include specially constructed permalinks for this exact reason.
Not cascading local changes to other parts of the page Posted 18 May
Since Ajax/Javascript gives you such specific control over page content, it’s easy to get too focused on a single area of content and miss the overall integrated picture. An example of this is the Backpackit title. If you change a Backpackit page title, they immediately replace the title, they even remember to replace the title on the right, but they don’t replace the head title tag with the new page title. With Ajax you have to think about the whole picture even with localized changes.
Asynchronously performing batch operations Posted 18 May
Sure with Ajax you can make edits to a lot of form fields happen immediately, but that can cause a lot of problems. For example if I check off a lot of check boxes that are each sent asynchronously to the server, I lose my ability to keep track of the overall state of checkbox changes and the flood of checkbox change indications will be annoying and disconcerting.
Scrolling the page and making me lose my place Posted 18 May
Another problem with popping text into a running page is that it can effect the page scroll. I may be happily reading an article or paging through a long list, and an asynchronous javascript request will decide to cut out a paragraph way above where I’m reading, cutting my reading flow off. This is obviously annoying and it wastes my time trying to figure out my place.
Blocking Spidering Posted 6 Jun
Ajax applications that load large amounts of text without a reload can cause a big problem for search engines. This goes back to the URL problem. If users can come in through search engines, the text of the application needs to be somewhat static so that the spiders can read it.
扫一扫
383
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
