Category: "HTML / CSS"

Half JAX

AJAX can be implemented in many different ways.

Options:

  • Place all the interface logic on the client side, and have the server act only as backend functionality. For a complex application, this method may be prohibitively difficult. The overhead of placing all the logic on the client side, and managing its delivery and execution is probably not worth the performance gains.
  • Segmenting the pages and populating them with HTML and related logic from the server. This would be using something similar to dojo content panes, which are HTML content. Similar to iframes.
  • Half JAX. Run the pages as HTML templates, augmented with AJAX navigation/population. Thus, the HTML remains static for the page, but the AJAX is used to fill the fields and provide advance features. With an efficient template engine and a sophisticated architecture, this is an excellent approach.
  • Use straight HTML pages, with a template engine. There is no law that AJAX must be used. :)

Delivering the HTML, with AJAX for form population and rich interface features is a nice compromise. The pages remain fairly fast, the rich features are available, and the complexity is limited. This is best implemented with a good architecture of reusable/common components.

Choosing javascript Libraries and Toolkits

If you want to add sophisticated client side functionality to a site, and are considering a javascript library like jQuery, dojo, scriptac….us, etc, remember:

  • Powerful tooks often add significant overhead. It isn’t worth using a library to support a single pull-down menu.
  • Try to find on-demand loading, where only the code required is downloaded.
  • Consider themes offered by the toolkits before designing the site. They can greatly improve your design and will work better with the library functions.
  • If you’re using AJAX, definitely use a library.
  • Remember that you can limit the library’s impact by placing it only on those pages which truly require the functionality.
  • Set up caching headers for the library code and CSS. They will probably never change (you shouldn’t change them).
  • Try the libraries out before choosing one. Use more than one if you feel it is worthwhile.
  • Use a CDN.
  • Be prepared to invest a significant amount of time in learning curve.

Reduce your 'net print

Bandwidth reduction will soon be a priority. The proliferation of RIAs exponentially increases the bandwidth requirements of initial page loads, while potentially reducing that of subsequent requests.

  • Use public CDNs - both to access and distribute libraries. Public CDNs are built for this purpose and often compres content. If you have your own CDN, use it.
  • Use and allow the use of logo images from their original sources. For example, the logo for your product could be displayed, from your server, on many sites. This allows headers to be set for browser caching, such that subsequent requests for the images will be served from the client, not the server.
  • Use compression where appropriate. Optimize images and ensure text is text, not images.
  • Examine your file and page architecture. Strive to deliver only that content required for each page.
  • Check the stats to find where the bandwidth is being used and focus on improving page performance for those pages. Use http://websiteoptimization.com
  • Use AJAX.
  • Develop locally, use XAMPP or VMWare.

Software etiquette

Many web development projects are done outside conventional version control environments. The overhead of version control simply can’t be justified for a small application or the customization of a site. However, it the development is performed by a team, particularly a distributed team, common etiquette should be observed.

  • Don’t change other people’s code. Either request they change it to your specifications, or ask if it is okay for you to make the change. If you receive such a request, reply promptly and act promptly, otherwise, you should assume the requestor will make the change.
  • Keep your own backup. This is a good practice anyway. This includes the database.
  • Use a site architecture that makes it easy to separate design and logic, and communicate it to the team. For example - all CSS/HTML/templates are the domain of the design team, all PHP/applications/installations are engineering.
  • Identify an authority to resolve any conflicts, and clearly document any likely exceptions to the file architecture above.

Notes

An image is worth 1000 pixels

Rich interface applications require careful designs, and should almost always be multi-lingual capable. One of the best ways to achieve this for small page elements is the use of images as labels.

Examples:

  • Red circle with line through it - means ‘you can’t do this’
  • WYSIWYG labels - are so prevalent most people understand all of them, including links, images, bold, italic, etc.

Page layouts

Many times, a page has more content than can be displayed. Accordian panes and tabs are a great way to make additional content available to the page viewer, without requiring them to scroll or navigate away from the page. dojo

eZ publish integration

Add these .htaccess to easily allow additional applications or files to be added to an eZ publish site. I haven’t tried them with eZ yet - but they work with b2evolution. Be sure to place them carefully. :)


# Redirect anything that's not an existing directory or file to index.php
#
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f