According to new research from HTTP Archive, which regularly scans the internet’s most popular destinations, the average size of a single web page is now 965 kilobytes (KB), up more than 30% from last year’s average of 702KB.

This rapid growth is fairly normal for the internet — the average web page was 14KB in 1995, 93KB by 2003, and 300KB in 2008 — but by burrowing a little deeper into HTTP Archive’s recent data, we can discern some interesting trends. Between 2010 and 2011, the average amount of Flash content downloaded stayed exactly the same — 90KB — but JavaScript experienced massive growth from 113KB to 172KB. The amount of HTML, CSS, and images on websites also showed a significant increase year over year.

There is absolutely no doubt that these trends are attributable to the death throes of Flash and the white knight, if-only-the-internet-was-a-damsel-in-distress emergence of HTML5 and its open web cohorts. It’s curious that the amount of Flash content hasn’t shrunk, though, which suggests that this year’s 33% increase in web page size is mostly down to a significant increase in website complexity and functionality, and not some kind of wholesale shift from Flash to HTML5.

The only real problem with the data is that HTTP Archive only began operating in October 2010 — and so there’s no way to find out the long time growth (or decline) of Flash. HTTP Archive, incidentally, constantly scans 16,000 websites — a list that was cobbled together from sources like Alexa and Fortune 500 — and records the total data downloaded, the number of individual HTTP requests required to fetch all of the content, the size of the JavaScript, Flash, and image content, and a bunch of other metrics. If you’re wondering about the odd spike towards the end, that’s where HTTP Archive increased its sample size from 16,000 to 50,000 — so presumably, the web’s top sites are smaller (or better written?) than the dregs.

So, what’s the actual significance of web pages that are almost 1MB in size? Not a whole lot, when you consider that caching will reduce that amount by 70 or 80% — and the more important statistic, at least as far as latency and rendering times are concerned, “total requests,” only increased from 74 to 85 over the last year (and again, caching will reduce that by 70% or more). One valid concern is mobile 3G and 4G surfers, where carrier data caps certainly haven’t increased by 33% over the last year — but even then, many popular sites have mobile versions that use significantly less than 1MB, and again, caching!

We would now expect the size of web pages to slow down a little, too. 2011 will have been the year in which many developers switched from Flash (or other technologies) to HTML5, and it’s unlikely that their first attempts will have been all that optimized. In 2012, JavaScript libraries will be refined, and cleaner ways of using CSS and HTML will be popularized. Even so, expect more mobile offerings that compress data, like Amazon Silk and Opera Mobile, to emerge as well.

This checklist is not all-inclusive but it covers some major areas that need to be tested with any major development.

• Accessibility (SortSite http://www.powermapper.com/products/sortsite/)
• HTML Validation (W3C http://validator.w3.org/)
• JavaScript Validation (JSLint http://www.jslint.com/)
• CSS Validation (W3C http://jigsaw.w3.org/css-validator/)
• Performance  and speed (GTmetrix  http://gtmetrix.com)
• Design (PixelPerfect http://pixelperfectplugin.com/)
• Test in all browsers listed in the requirements
• Test without JavaScript, Flash and other plug-ins
• Print version

Lastly take a look at the logic and code itself to ensure that it follows Web Standards, Best Practice and the KISS principle (http://en.wikipedia.org/wiki/KISS_principle).

Both GreyBox and Flowplayer are free third-party resources for pop-ups windows and online video, respectively.  Combining the two makes a great video player that is easy to maintain and design.

Download the source files:

• GreyBox
• Flowplayer (GPL License)

Both will be packaged in ZIP files.  Unpack them and place their contents into their respective directories as shown below:

You will also need to add a folder called ‘videos’ unless you choose to deviate from this tutorial.  Your index file will be a page with the links to the video.  First, open your index file or whatever page you are working with that will display link to the pop-up videos.    These lines of code are required in the <head> tag to get GreyBox to work:

<head> <script>var GB_ROOT_DIR = "/greybox/";</script> <script src="greybox/AJS.js"></script> <script src="greybox/AJS_fx.js"></script> <script src="greybox/gb_scripts.js"></script> <link href="greybox/gb_styles.css" rel="stylesheet" type="text/css" /> </head>

Then, within the body of your document, set up links or image links using this format or similar format found on the GreyBox useage page:

<a rel="gb_page_center[560, 450]" title="NAME OF POPUP TITLE" href="player.html?filename=videos/VIDEO_FILENAME">

You can set your own title up here or your own popup window size.  All of your anchor tags will refer to the document specified in the ‘href’ attribute, which we will create next.  This prevents us from making a new HTML file for every video you may have on your link page.   Create an HTML file in the same directory as your video links page (index.html in this example) and name it ‘player.html’.  This page will dynamically (using JavaScript) to serve the video based on the filename provided in the links page anchor tag. These lines are needed to get the Flowplayer working within the GreyBox popup:

<html> <head>  <script src="flowplayer/flowplayer-3.2.4.min.js"></script> </head> <body> <script>  var page = window.location.href;  var position = page.indexOf("filename=");  page = page.substr(position+9);  document.write("<a href='");  document.write(page);  document.write("' id='player'></a>"); </script> <script>  flowplayer("player", "flowplayer/flowplayer-3.2.5.swf"); </script> </body> </html>

The dynamic page allows you to just modify your anchor tags ‘href’ attribute in the file that calls the player page.   This page can also be written in ASPX or PHP pages to accomodate your site.  If this is the case, the JavaScript can be replaced with code to get the filename variable from the URL. Your directory should now have a setup like the following:

The index page will look something like this in a browser:

And once the link is clicked, you should get a pop-up player that looks like this:

It’s not uncommon now-a-days to hear this weird jargon thrown around called ‘AJAX’, but what does it stand for?

I’ve yet to read a better history and break down than what Jeremy Keith wrote in his book entitled “Bulletproof AJAX“. So without further ado, I’m going to quote Keith a bunch:

“Jesse James Garrett is an information architect, author and founding partner of the San Francisco-based company Adaptive Path. In February 2005, he published an essay on the Adaptive Path Web site titled ‘Ajax: A New Approach to Web Applications.’ In this essay, Garrett coined the term Ajax to describe techniques used by a new kind of Web application…. It was originally intended to be an acronym standing for ‘Asynchronous JavaScript and XML.’ ”

Keith goes on to explain that the acronym implies that asynchronous and XML are requirements within AJAX, which just isn’t true. (JavaScript is definitely required in most cases, but the AJAX behavior could be done through Flash or Java as well, just to name a couple.) “Jesse James Garrett later updated his essay, making it clear that Ajax is not an acronym.” The technology has been around before Garrett as well but coining the term made it possible for most of us to talk about a set of technologies, that when used together, create a new user experience. So think of AJAX more as a user experience than a certain set of technologies.

Garrett created the term AJAX so he could more easily have a conversation with clients and his developers alike. So why is the AJAX behavior different than your traditional development? 

Example
- Tradition: You login at a web site and notice your  browser has to think for a bit while it either refreshes your current page or goes to a new one. This makes you have to reload the same content or be forced to load new content.
- AJAX alternative: You login at a web site, it gives you a little notice saying that you’re now logged in. That’s it. No loading required on your end.

What AJAX does is allow the user to send and receive information back from the site without ever having to load content. It’s not that the technology is that much smarter, or psychic, but that all the loading happens behind the scenes, putting the burden on what matters the least, in the code. What matters most is the user and their experience on your site.

So why ask for it?

AJAX allows for a faster, smoother user experience. It’s becoming so mainstream lately that it’s making more traditional web development seem bulky and slow to use in comparison. Ever used Google Maps? Yep, all AJAX. Even the competition switched over to use their techniques – Mapquest and Yahoo, to name a couple.

It’s also pretty neat on our end too. This affords us with some pretty neat effects we can do easily for our clients’ sites, like animation.

Now that you’re just a little more knowledgeable on the subject, I hope your next web site will include a lot of AJAX implementation to give your users a smoother experience. Feel free to contact us for more information regarding AJAX implementation on your site.

Adobe Flash (formerly Macromedia Flash) began as vector-based animation software that was embraced by artists, designers, and animators. Its application on the web initially began as a cool tool that designers used to try and make the web more visually interesting by making things animated.

Knowledge of computer programming was not a requirement in order to build Flash animations, and for several years many Flash designers and developers had little knowledge of code or computer science fundamentals, while some Flash designers and developers had no knowledge of programming at all. Flash provided a growing but limited development environment using ActionScripting, so for many, Flash was simply an animation tool and not much more than that.

During its early web implementations, many users will remember Flash applications as those annoying “flashy” banner ads that were found on lots of web sites. These animations were annoying because they caused sites to load slow and also because users had no control over the animation and often found them distracting. Then there were those web sites which when a user tried to visit the site, they got the infamous Flash splash “Intro” page or the “Enter Site” page. Many users hate these pages because they’re viewed as barriers to the information they are trying to access. Even now, many users do not understand that there was often an underlying reason for those pages to be there. “Intro” and “Enter Site” pages were often used as a check to see if a user had Flash capabilities since there was no universal cross-platform way of checking to see if a user had the Flash plug-in installed. These pages also served as a method of offering users an option to view the Flash version of a web site if they had a higher speed internet connection, or to view the static HTML non-Flash version of the web site for slower internet connections. But users did not care that the developer was trying to give them an option. They expected to be able to access the site immediately and these Flash “Intro” pages were often seen as an annoying hindrance.

On top of robbing users of controlling their internet experience, Flash applications and web sites were often big and bulky which is the reason that they were best viewed on higher internet connections. Even with higher bandwidth, some Flash content still loaded slowly. This made accessing information or just navigating within a Flash web site a time-consuming and frustrating process that quickly caused users to lose interest in a site. In addition, some Flash developers went overboard when trying to showcase the interactivity possible with Flash applications and created web sites that were a usability nightmare. Because of this, when many clients hear “Flash” it conjures up bad memories of negative user experiences, of sites that were too complicated to use or utilized functionalities that users were unable to control. Thus many folks are quick to express their disdain for anything Flash.

Their complaints are, at least on the surface, well founded. A large majority of Flash used on the web fell into this category. These specific instances often contained large amounts of graphics, images, text, and audio with complex animations that were all contained in one file, which had to be downloaded all at once. Often these files contained more information or data than was necessary to display at any given time. It was an all or nothing situation, where the user had to download the entire web site at once, yet all they needed to access was the home page.

The good news is those days are in the past. Flash does not have to be a bad memory and there are several reasons for this. First, there have been drastic changes in the use and capabilities of the web. The web is now many things to many people and is becoming more and more media driven. Studies have shown that users respond more positively to web sites with high modality, in other words, multiple pathways of communicating information to a user, as opposed to sites with low modality. A web site with high modality would incorporate multiple channels of information communication such as text, images, interaction, and video, whereas a web site that has low modality is one that consists of text alone.

Secondly, there has been a tremendous growth in the capabilities of Flash software. Flash has gone from a vector-based animation application to a full-fledged robust development environment. ActionScript is the programming language used within Flash and it has evolved from a basic scripting language to a fully developed object-oriented programming language with the latest version, ActionScript 3.0. Flash now has the ability to seamlessly combine graphics, text, animation, audio, video, and logic driven interactivity that also allows integration with XML, JavaScript, Classic ASP, ASP.Net, PHP, and Cold Fusion. This integration allows Flash applications and web sites to be built in a more modular fashion, where content is loaded dynamically based upon user interaction. What this means is that instead of downloading an entire site or application, the user downloads only what is necessary for the specific content requested, which can be updated in real-time based on user interaction, without having to refresh the entire page. Integration with JavaScript and the ability to load dynamic data allows Flash web sites to have page specific URLs, which means that users can bookmark or navigate to individual pages within a Flash site, which is a critical factor in implementing Search Engine Optimization functionality such as page tracking. In addition, there is also the ability to add browser history functionality within a Flash site, which means if a user hits the browser’s “Back” button they can actually navigate forwards and backwards in the browser’s history, so that there’s no more “accidentally” hitting the back button and watching as the whole site reloads and takes you back to the beginning—which was a major complaint of many users.

Lastly, there has been a shift in the technical abilities of Flash designers and developers, so that many are proficient in programming concepts and capable of developing robust applications. This has led to much better implementation methods while making Flash’s past uses a gross misrepresentation of its current and future potential.

Flash is now a powerful development environment, which can offer many advantages when implemented correctly. Yet I do not believe that Flash is always the best solution. I am a large proponent for using the right tool for the job whether it’s Flash, ASP.NET, AJAX, Java, or simply XHTML. However, I do believe that due to its disreputable past within the IT industry, Flash is sometimes overlooked in situations where it could play a vital role in creating ideal solutions to complex needs. When considering using Flash technology as a part of your web site, it is important to choose an IT company that can properly assess the efficiency of having a Flash solution and implement it in a way that serves your business, whether it’s a simple image transition promoting a marketing message, or interactive modules that concisely display complex information, or video capabilities that spotlight products, services, or serve as educational tools.

One of the most interesting and rewarding aspects about my job here at Beacon Technologies is the fact that we are constantly looking for ways to integrate technologies together.  As a CMS Specialist, I’m always looking for ways to use our Content Management System, Hannon Hill’s Cascade Server, to further allow our customers to manage their sites on their own…completely on their own.

We all know about Flash:  a widely-used, extremely popular Web technology that allows site owners to jazz up their site with quick-loading animation.  But how would a site owner even think about maintaining that Flash application?  Have you ever seen the code that Flash is written in?  It’s complicated to say the least.  So we needed a way to allow our customers to have Flash applications on their site, but also allow them an easy way to maintain their images and content.

Enter Cascade Server.  With our innovative solution, customers can use Cascade’s Microsoft Word-based editor and intuitive interface to edit content and images within a Flash player that Beacon custom-built for them.  Since Cascade Server is based on XML, and Flash is a pro at reading XML files, you have your integration of technologies.  Cascade Server can take the content that you put into it, publish it out in XML-format, and the Flash application reads that XML and displays the changes.

We took this solution even further, and built an all-Flash site.  Instead of an HTML-based site calling a few Flash applications here and there, this site is completely built with Flash, and managed by Cascade.  Using Cascade, our customer can add, remove, and delete pages, edit content using the Word-based editor, and insert images and tables.

It’s just another way that we create innovative Web technologies for our customers.  To learn more, visit our Web site at http://www.beacontechnologies.com/.