The Flash RAD framework, SEO and HTML5

Posted on January 31, 2010

2


Let’s begin with the conclusion of this post:

Reasons why I use Flash with XHTML, Viewstates and CSS

  1. Logical – why invent something new that – at the end of the line – reflects something already existing?
  2. Scalability – HTML is per definition scalable. The web as a whole is the best example for that
  3. Search Engine Optimiatizon – building the content-part of the site in XHTML makes it searchable by any spider
  4. Flexibility – changing behaviors, interaction models and visuals via XHTML, CSS and Viewstates is easier than via code (when done properly)

What the Framework does (a short summary)

Within the Flash environment I have created a library of objects that represent / wrap all basic components you need to build a site. Added to that is a singleton to deal with interactions and events, called the “Central Event Handler” and a set of classes class that wraps behaviors like “move an object out of sight using a tween” and “make a button glow when you mouse over it” and applies all the good of CSS to the objects in the Flash movie.

It helps me to skip the nitty gritty of copying, pasting and changing existing code to build something new. It also allows me (and you) to build entire websites using XHTML, CSS, Viewstates, Events and Actions and change behaviors and look and feel without having to recompile the AS3 code. All of it in clear text and loaded as XML, loaded on demand.

I basically marry the benefits of both HTML and Flash for my own gain.

HTML 5 and the framework

Screenshot of the classes now defined in the simple factory

I did not and do not intend to create a library in Flash to render or “replace” HTML5. Using HTML as the basic descriptive language and CSS to define styling is simply the most logical choice for the framework as HTML as a discriptive language is already there and quite well defined.

The current “war” on Flash and the death of Flash

People who dislike Flash for memory use, CPU use and it’s “closedness” seem to find support in the current developments regarding HTML 5 in both the browser and the new iPad. The main arguments used in Flash bashing are: “banners”, “skip intro’s” and “video in HTML 5”. “Finally flash will be killed”.  “2010 is the beginning of the end of Flash”.

In my opinion, there is only one reason that Flash will fail and kill itself: where Adobe will not be able to resolve the performance and memory issues.

When HTML5 will grow and sited in HTML5 become richer, they will face the same issues as Flash: rendering cost processor time. Current HTML sites use no processing power BECAUSE they do nothing when loaded. Current flash sites use no processing power WHEN they do nothing. Here is an example of a site using Canvas and Sound. Keep an eye on your processor usage before and when it is playing. On my machine the CPU usage goes up from 7% to 60% and further up to 85%.

To quote Sebastian Salzgeber: “but Flash is a good enviroment so create the same look and feel in every browser without getting problems of implementations each browser will have with HTML5.”

History

Six years ago I wrote the “Fluid Flash Interfaces Engine“. The FFIE was initially developed for use by me. What it was designed for and did was this:

  1. Load in a few seconds
  2. The site was entirely defined in XML definitions and CSS-like statements
  3. Using these definitions, the framework rendered the entire GUI in Flash using the drawing capabilities in flash: including tabsheets, scroll-lists and user forms.
  4. Using standard routines in the engine, dynamic content was addressed using constructions like <list src=”/scripts/books.asp?genreID=[genreID]”
  5. Using stylesheets and design settings in XML (with, height, colors, line styles), sites could easily be redesigned without recompiling the Flash movie

The core library was 34 KB and loaded fast. Rendering took some time, but the overall experience and maintainability was better than the “old way”.

Big shift from classic Flash development

It was a big shift from the classic way of building sites in flash: where the core movie counted 200 MB and took at least 10 seconds to load before you saw anything of interest happening. Where even the smallest redesigns meant you had to do a lot of work as one site could easily comprise of 200 or more elements in the Library.

Where the FFIE failed

The FFIE failed because it was too abstract. Building a site in Flash is like making stuff in Photoshop: very visually oriented. Building a site in the FFIE was like moving back to NotePad and page-reloads in the browser to see the result. Also, the “discriptive language” was not HTML but some home brew something. All in all very counter-intuitive.

The Flash RAD framework

In 2008 I picked up the concept of the FFIE again with two major strategic changes:

  1. Using XHTML as the descriptive language
  2. Offering 2 strategies to build the sites: in the Flash IDE or purely via XHTML

Flash, XHTML and SEO

The misconception has always been that “Flash does not do SEO”. The truth is: “many people building Flash sites do not take SEO in consideration”. It is not a problem of Flash, but a problem of the Flash community. You can build an entire site in XHTML, use Flash to read that XHTML and use it as pure data to present in Flash.

So the third reason for using XHTML in the Flash RAD framework is exact this: Search Engine Optimization.

Rapid Application Development

RAD in any environment requires the coverage of the following items:

  1. Layout and visual design – and easy ways to change them
  2. Interactions and interaction models – and easy ways to change them
  3. View states
  4. Presentation of data – including text, lists, images and data visualizations -and easy ways to change that
  5. Transfer, storage and retrieval of data – and easy ways to change that
  6. Feedback to the user – including error messages and “first do this, before do that” – and easy ways to change that
  7. The extra’s like streaming video and audio

XHTML, CSS, Viewstates and a framework in Flash

The fourth reason for using XHTML in the flash RAD framework is the possibilities it offers to change the behavioral models, layout and visuals (in principle) of a site in a clear and already well defined descriptive language.

Viewstates

Something that is not defined in HTML or CSS are Viewstates. A Viewstate is a definition of what is visible, hidden, enabled and disabled at what point of the interactions between the user, the application and the data.

==========

Side notes

Flash

Flash – at this point – is the only platform with a predictable render engine. What you see (design in Flash) is what you get in the browser without having to jump through hoops. When your application runs, it runs on a Mac, a PC, on Firefox, Opera, Internet Explorer, Safari and what have you. Flash also is a front runner in the implementation of the things that make building web applications fun: audio, video, camera input, audio input,  a drawing API and filters to cast drop shadows, glow, blurs and many of the basic stuff you can do in Photoshop.

When you design a site in Flash, it will look and behave exactly the same anywhere (provided you include the fonts and some exceptions taken).

What flash lacks

I wrote another article on why Flash (and everything else) sucks here. Brief version why it sucks: rendering over the CPU instead of the GPU and crappy memory management. What Flash lacks is the flexibility and scalability in design that HTML DOES have to offer.

HTML

For building complex sites, or large scale applications, HTML as a “front end technology” rocks. It is uncompassed in this until now. Writing HTML is visual programming using generic definitions. It is the most successful language to make something look good in a simple way and the same goes for it’s scalability due to it’s page based structure and easy model for distribution, whether it is for print or presentation. No other environment I know does this that good.

DHTML, HTML4, AJAX and all the likes

1998 was the exiting beginning of something new: DHTML. For the first time you were able to dynamically change the content of elements on your webpage. Not only that, but also you could load content in Frame 1, copy & paste that content via JavaScript into a variable and paste it somewhere else in the HTML document in Frame 2. Using the Document Object Model, you could hide and move objects on the screen, register mouse-clicks on those objects and read the X and Y coordinates of the mouse pointer allowing you to create drag & drop scenarios. It had everything to start building applications online that could match the applications you had on your desktop. The age of Web Based Applications began.

Where HTML4.0 got fucked

There were two problems back then: Microsoft and Netscape. Microsoft refused to fully comply to the W3 standards and instead installed a number of their own. Netscape basically started to self-sabotage every new release of their own browser implementing “X” in version x.0.12.34, breaking it in x.0.12.42 and fixing it partially in x.13.0.1. Then there also were Opera and two or three other minor players in the market doing their own versions.

The result of that is this: When you open any framework, you will see a number of browser-checks. Depending on the browser type, the OS it is running on and the version of the browser, exceptions and rules are applied to make a simple thing like an expandable menu work in your browser. Any new release of any browser can partially break the framework for dynamic things in HTML.

Advertisements
Posted in: FrameWork, Standards