Ajax
A lot of frameworks have come out recently that are designed to tackle the offline problem; the frameworks' approach is usually to run a database on the client. The database can cache data from the "home server", and if the user makes changes while offline, that database can write the changes back to the "home server" when it becomes available again. These frameworks don't do anything about all of the back and forth requests to the app server that AJAX applications generate.
Some developers try to tackle this problem by loading a miniature application server on the client via Java (or similar "applet" style technologies). This approach works. However, after a certain point, I wonder how many hoops someone needs to jump through to compensate for an inherent shortcoming of a particular technique before it becomes clear that a technique might not meet their needs.
Even assuming that you can put a miniature application server and database server on the client that can cache and sync with the master servers whenever possible, you still have not solved the problem of "saving a Web page". The user doesn't think they are using an "application"; if it runs in a Web browser, they treat it like a Web page. Users are always clicking the Back button (which messes up AJAX apps) because they expect it to work like the Undo button. And incidentally, it does work like the Undo button in a more traditional step-by-step forms-based application. Ironically, one of the biggest issues that AJAX addresses in traditional Web development is the stateless nature of the HTTP protocol -- and yet it suffers from its own lack of state.
Let's take a "product finder" application as an example. In the application, the user selects various options as "must have" and "nice to have" features. Some of these are Boolean selections, while others might be numeric ranges, and one or two might be "one-of-many" or "many-of-many" options. Now, let's imagine that our user has narrowed her choices down to four products from the original 50. She decided to save the Web page to disk so she can email it to her boss or co-workers for review. Whoops! Her boss and co-workers will likely have a problem if they try to bookmark the page or email the link. In a traditional Web application, if the developer is smart, he or she will use GET rather than POST for these scenarios to ensure that the link accurately represents the application's state, and the page is quite easily saved in its current state.
I am not saying that AJAX applications cannot function like this; however, until users get used to the idea that the traditional model no longer applies, developers will want to find smart and creative ways of addressing this issue. One way of doing this would be to periodically "tag" the state with a hash code and redirect the browser to a URL that calls that hash code. This way, if the user hits the Back button, she goes back, say, two minutes in time (or 10 operations) rather than back to the beginning. Also, the user can email (or bookmark) that link. Developers often build in Email This Page, Bookmark This Page, or even Save This Page buttons on their site, but it takes effort to build in the buttons, and users often miss those buttons or assume that they do the same thing as the similarly labelled browser functions.
I think that developers who work hard can find some creative, workable, and usable solutions for this issue, and their users will appreciate it.
About Programming
Add cool features to websites, or building custom web applications to make life easier
D3Script offers professional web programming services to build things like:
Searchable Databases
Online Forms & Registration
Surveys
Custom Web Applications
If you're looking for adding some functionality to your website and easier control , look no further !
Just contact us for more details ...
About Designing
Our Web Development Lab designs and builds web sites and web applications. We also offer support for people using Macromedia Dreamweaver, and more.
The best web designers , and the best price.
Here at D3Script , we offer a full range of professional web services, including:
Site Design & Redesign
Usabilty Testing
Accesibility Consulting
Site Maintenance and Updating
UConn Template Conversion
Our professional artists and programmers collaborate to deliver stunning websites that meet the individual requirements of our clients.
Whether you're looking for a traditional UConn look with a few tweaks, or a highly creative identity, D3Script is here to help building a site that is both visually compelling, and in compliance with all University Web Standards.
Take a look at the sites listed in WORKS section, I think you'll find that our work speaks for itself. If you have any questions, you can contact us right now.
How much does it cost?
Unless you are purchasing a fixed price solution, prices can range depending on the caliber of designer you have chosen, and the type and size of solution you are after.
A typical small business website can range from between 1500 LE for a basic site not including hosting and domain name, to over 8000 LE for an integrated e-commerce and business resource planning tool. Larger projects usually begin at around 6000 LE , and quite easily push to 6 or 7 figures, given these projects are quite often integrated to existing (legacy) IT systems or core marketing activities.
If your project has the potential to increase revenues or reduce costs, then work on a return on investment (ROI) basis. A site that costs you 8000 LE to produce, but produces more than 10,000 LE in value to the business over the course of a year is entirely viable for ANY business .
Work with your developer early to discuss the ROI potential for your project.
Some developers also offer convenient payment options to further support the ROI argument.
If you are comfortable with a partnership, then why not suggest a Contra or revenue share arrangement to share both the risk and reward? This is a perfectly legitimate arrangement for online developments and is more common than most would think.
When dealing with potential developers or a chosen partner, provide a definitive brief and request an itemised breakdown of hours and rates. Industry standard rates are anywhere between 80 LE and 400 LE per hour depending on the designer/developer. Remember, you do get what you pay for, but without fully understanding both your requirements and the process to be undertaken, mistakes can be made if the fit between developer and client is inadequate.
Are our works compatible with other browsers ?
We answer proudly with "YES" , it's from our priorities to test our works on alternative browsers such as Firefox, Opera, Netscape, etc... before presenting them to our customers.
How do you shape up?
Use of alternative browsers has only been going up, they are no longer a niche community made up of "techies" and anti-Microsoft advocates, they are your everyday user, your potential customers.
If you haven't done so already I would suggest that you look at your website in some of the other common browsers available. These include:
Mozilla (http://www.mozilla.org/download.html): This is currently the top browser after IE6 and it is one of the most feature rich browsers available today. I would personally suggest looking into Firefox Mozilla's next generation browser as apposed to the entire Mozilla suite due to its end users friendliness and feature rich environment.
Opera (http://www.opera.com/): The Opera browser has been making its way up the competitive ladder of the browser arena since 2000 when Opera Software ASA released Opera 5. Though it is free to download and use if you want to access some of the browser's features you are required to pay a small registration fee.
Netscape (http://channels.netscape.com/ns/browsers/): Since Netscape provided the code base for Mozilla in 1998 when they made the source code for their flag ship product Netscape Communicator open-source there is little difference between the two browsers. Still it never hurts to see how things shape up between the two, and since they are ultimately two different browsers checking with them both is not a bad idea.
Additionally there are programs available that can test your site for you in different browsers and screen resolutions and return their findings. One such program is Browser Photo (http://www.netmechanic.com/browser-index.htm) from NetMechanic.
What can you do?
Okay so lets say that our site www.ihaveanerror.com comes up with a couple of errors that cause it to render incorrectly when we look at it in some of the alternative browsers. How are we going to fix the problem? Well the first thing we want to do is stay away from any propriety tags a certain browser type might offer. These tags will only work properly in the browser they are designed for and may cause trouble for you in others. An example of a proprietary tag would be <marquee> in Internet Explorer.
Another thing you should make a habit of is to validate your pages through the World Wide Web Consortium (http://www.w3c.org/) (W3C for short). Founded in 1994 the W3C has made it its obligation to guide the development of the Web and create a common basis to build upon. One of the services that the W3C offers is syntax validation. This is a useful tool when you are trying to ensure that your visitors will get roughly the same experience when they visit your site. Validation is easy, select the language your site was designed in and use their free validation tools to track down any errors that might occur. If there is an error in your source the validation system will highlight it and provide you with possible solutions for correcting it.
Why should you conform your site to the World Wide Web Consortium's guidelines? The answer is that it is these guidelines that browser developers use as a basis to display pages on the Web. While browsers like Mozilla conform strictly to the W3C's guidelines Internet Explorer is more relaxed. In fact Internet Explorer will render just about anything you throw at it. You can leave out the tags, tags, or forget to close a tag all together and IE will 9 times out of 10 be able to work with what you give it.
Be weary of Microsoft's FrontPage. While Microsoft makes some of the world's most powerful and end user friendly applications in my opinion, FrontPage has a tendency to do things IE's way. What I mean when I say this is that FrontPage will overload a web page with a lot of overhead that is either out of place or incorrect. If you plan on using an editor of this type consider Adobe's GoLive, this application at least has the ability to built a page according to W3C standards and has a built in syntax checker that can help you ensure your site will meet their requirements.
