Now it’s piling up for Flash again: Steve Jobs is crusading against Flash accompanied by the entire HTML5 consortium. Atop of this all major video-service providers, mobile phone makers, and a whole lot of others are now leaving Flash behind in the dust.

Once so close to web domination with virtually cross OS and cross browser support, Flash has bailed me out of many a worry of making things work in all browsers (remember IE6 anyone). Flash’s biggest blow may have been when they couldn’t make their player a web standard and include it in the DOM (as a seemless part of every browser).

Here we are stepping right in the core of the problems; Flash is run in a plugin… A “browser” inside a browser, so to speak. A semi-propritary technology is not wise to include in any standards. So that leaves us all to download a plugin in order to run the Flash content. We don’t really like this, but most of us are willing to forgive this if the content is worth it, and it suprisingly often is (IMHO).

Part of Flash’s problem is how easy things are to create. Everybody can make something in Flash, there are grandmothers making things in Flash! However when it comes down to dynamic applications using webservices, remoting and object orientated code libraries many fall off the wagon and start improvising. Uh-oh. This is where you shouldn’t improvise at all, and all over the web your bombarded with error-messages and applications stopping working.

Would you let your local baker do brainsurgery on yourself, or leave your car at the hot-dog-cart for a full haul-over. Not likely. But it’s OK for your web-shop to be designed by a developer and developed by a designer? Lets face it, it’s the perfect combination: A developer needs only two hours to “design” any solution, and the designer needs only a day “to make it work”. So good times then, or shouldn’t someone start raising the red flag here?
This scenario is unfortunately a not uncommon in the world of Flash as “everybody” can do “everything”. However, there’s more and more Flash-projects being done more correctly now adays as Adobe has created a more intuitive work-flow.

Flash is pinpointed for the web. The web have never had any unified organisation going through all webpages and flashs approving them for the web, like Apple does for their platforms. This means that a lot of crap-application and banners etc are loaded on overy page out there. No wonder people are eager to kill Flash.

Of course there’s also a lot of technical issues with flash making people dislike it. Like it doesn’t support touch-screens, it lacks abilities for SEO and WAI (Search engines and accessibility), it’s CPU-heavy, device-problems and a lot of other things.
All of these technicalities I believe Adobe must pay attention to in order to keep the Flash platform alive. It really shouldn’t be that difficult. Adobe should do one more thing, maybe more important than the technical issues, they need to rethink the philosophy behind Flash and where to go with it. Maybe not so easy to foresee the iPhone, but now that iPhone has been around for a long time, Adobe has not really adopted to it, but rather started a defensive verbal argument.

So will Flash die a slow painful death now? Of course it’s a time for everything. One day Flash will be history, as will the iPhone and most of the things we see and use, but it’s not the time for Flash quite yet.

Why not let Flash do what Flash does best, be the icing on the cake or the heavy-lifter of data-structures. It’s still perfect for animations, components, games and applications (hey, wasn’t that what it was supposed to do?). When HTML and other thechnologies don’t work or takes too long time to make, Flash is still a good alternative, but we developers need to look out for backups on devices that doesn’t run Flash, or don’t support mouse-devices.

Now that CS5 is out with no support for iPhone and really no whole-hearted solution to support the flow of devices thrown at us we need to await Adobes next move…I hope it’s an offensive one

Recently Google announced that there is another element which all webmasters should take into account while thinking on Google search results: SITE SPEED.

Site speed shows us how quickly a website responds to web request.

It’s obvious that speeding up the website is important for both visitors and site owners. Users spend more time on the sites which loads faster. Of course it won’t fix the content or user experience problems, but definitely it matters. And this is why Google has been starting to affect search queries by the site speed.

There have already been some tools on the market which can evaluate the speed of the site:

- Page Speed – Firefox add-on that evaluates the performance of web pages and gives improvement suggestions

- Webmaster Tools – inside Labs > Site Performance webmasters can check site speed and see the results in the chart

- YSlow – a free tool from Yahoo! with optimization suggestions

More tools can be found here:

Speed Tools

Site speed is not and will probably not be the key parameter for search ranking algorithms, but for sure it is worth mentioning element when it’s about SEO, and all webmasters should think about it while creating websites.

“Moving forward, RIA developers and rich web content producers won’t need to amend existing and future content to make it searchable—they can now be confident that it can be found by users around the globe.”

Two years later we have experienced that some of our Flash solutions does not get many results when googling them. Now why is this? Has Adobe/Google/Yahoo! failed or is it just that we have missed out on the details on how to really make the Flash more search optimized? Adobe stated in 2008 that all existing SWF solutions, across all versions of the SWF file format should be supported. That is without taking any grips to improve existing solutions for SEO. Can this be true? There are a lot of rumors and myths about Flash and CEO around on the web. I’ll try in this article to figure out what the real facts are…

What does it really take to make your Flash site optimized for search engines?

[Fact] The technology that Adobe is cooperating with Google and Yahoo! to achieve is to allow the search engine spider to crawl through a SWF file, navigating as is it was a normal user. The spider would then collect all text and links that occur at any state of the application, which then can be used in search results to the end user.

[Fact] External resources loaded into Flash are also indexed by the search engines. This was not the fact from the beginning but Google announced this in June 2009. This means that if the Flash file loads a XML-file containing the Flash solution’s text, this text will be associated to the Flash file.

[Fact] The search engine crawlers do support JavaScript techniques for embedding Flash (SWFObject & SWFObject2). This was not the case before the summer of 2009.

[Fact] There are ways to improve (and help) the search engine spiders to index your Flash content. Deep-linking is one way. Using one of the many solutions for deep-linking SWF content may improve how links can drive relevance to specific parts of an application and reflect a specific state of the SWF content. I have successfully used SWFAddress for this purpose in more than one occasion.

For complex sites you can also use techniques such as a site map XML file to highlight specific URLs to the search spider. Create multiple HTML files that provide different variables to the SWF and start the application from the correct subsection. This way you can get the benefits of a site that is indexed as a suite of pages. Read more about sitemaps for Flash here.

[Fact] Avoid using too much Flash. If you can, avoid creating the entire site in pure Flash. Though it is possible to make it optimized for search engines, it is usually discouraged. One reason for this is that you can’t weigh the different elements in Flash to tell the search engine how important they are. This is possible in HTML by placing information in header tags and so on. Though you are able to use CSS and HTML coding in your Flash text fields, it probably won’t weigh the same way as in HTML.

To make the best out of it build HTML into the Flash text fields (using .htmlText of the TextField class) and make sure you build the HTML-code to enhance the importance of the text elements as if you build the site in HTML. Use links, headings and other HTML tags.

HTML fallback

It is always good to provide users with a HTML fallback. This helps in many ways. Users without the proper Flash Player installed or maybe running without JavaScript will fail to see your conent when opening your site. A pure HTML fallback solution with provide them with the information they need but without the user experience that the Flash solution is there for. Another big advantage is that the HTML fallback will provide info for the search engine crawlers and index the content on your site.

Does it work?

How good do the search engine crawlers really index Flash content? To be honest I’m not sure and I am not completely convinced that they do their job good enough. But there is really not much more to do with it. Let’s hope Adobe and Google/Yahoo! take this seriously enough to continuously improve their crawlers to index the SWF content out there.

Sources:

http://www.hochmanconsultants.com/articles/seo-friendly-flash.shtml
http://www.adobe.com/devnet/seo/
http://www.adobe.com/devnet/flash/articles/ora_seo_flash.html
http://www.adobe.com/devnet/flashplayer/articles/swf_searchability.html

I must say results were disappointing and showed far too much difference than what’s acceptable. It may have something to do with this specific font, like the font-hinting.

It’s sad to see that Opera is not supported at all, even though the latest versions have native support for font embedding.

All the tests were done on a Windows 7 PC.

My first App consisted of an image of the iPhone “homepage” with some basic touch-behavior. Tapping the left side would make the image spin, rotating the Y-axis 180 degrees (.rotationY). Tapping the right side would spin the image the other way, while tapping on the top or bottom the image would rotate the X-axis (.rotationX). I used the Tweener-class to animate the rotation, using a “easeOutElastic” transition effect. The animations where of course quick and responsive on my computer, but how will the iPhone react to this? I worked very fine indeed. I tested on a iPhone 3GS and my old 3G. Both reacted as quick and responsive as it did on my computer. Nice! But hey, this was very basic…

I expanded my tests by using the new Accelerometer Class in AS3, making the image change its rotation-parameters according to how I held my iPhone. This also worked very well and my belief in the Flash iPhone packager continued to grow.

Time to build a real App!

Using a WebService that returns all contact info about the employees at Making Waves, I started to create an App that should present these data in an ‘iPhone-kind of way’. So I started off just like I would when creating a Flash solution, connected to the WebService, parsed the data and started to build a view. So far it worked like a charm on my iPhone. The view consisted of the employee name and department, three buttons, one to make it possible to call directly the person, one to send a sms and one to send mail. Finally it had a image of the employee. When the view is presented you should be able to switch between employees by swiping your finger to the left and right, just like you usually do it on an iPhone. To make it a little more interesting and different I made the view rotate its Y-axis when it is dragged according to how much it is dragged. The next and previous view/employee is automatically dragged according to the main view (take a look at the image on the top). The result was quite nice. Looking like a normal iPhone App but with a little twist. Using the TouchEvents that is new to AS3 was easy and combining it with the normal MouseEvents was no extra effort. Developing was quick and easy in a normal Flash development way, and I was thrilled to see the result on my iPhone. Time to put it to the test!

Since I didn’t have access to the iPhone 3GS I had to test it on my own iPhone 3G. The result was devastating. My first version was without the call/sms/mail buttons and the view of the first employee was presented pretty fast and it looked nice. But when I tried to swipe left or right the fun was definitely over. I worked but it was very slow. Performance was way under what is expected. I tried to read up on how to make performance to improve. GPU-rendering, cacheAsBitmap and so on. I added some functionality, improved the way to switch between views, tried to follow performance tips and tried again. Crossing my fingers and hoping that my last changes would do magic. Magic was unfortunately not the word. This time the app crashed each time I tried to start it. When trying to insert the image the iPhone didn’t want to handle the performance issue any more and shut down.

As a Flash developer I was really hoping that the Flash iPhone packager would be good enough to use to develop iPhone Apps in a easy and quick manner. The result after my first test was unfortunately as bad as they could be. I will not give it up just yet. There are probably a lot of things I could improve in my code to make it more iPhone friendly. At least I hope so! But one thing is for sure. Developing an iPhone App using Flash will not be the same as developing for the web. There is going to be a lot of issues to be aware of and as expected the performance issue will be the main issue.

I continue my test and will test my App on a iPhone 3GS when it gets available. I’ll try to improve it, I’ll do anything to try to prove that Flash CS5 will be a good platform to create applications for mobile devices. So far I have a long way to prove just that.

Most web developers agree that the ability to play video on webpages is a must, however the jury is out on how these videos should be played. I’m of course referring to the HTML 5 video format controversy. Throw FlashPlayer into the mix and you’ll end up with a humongous fight leading fast to nowhere. Based on this, focusing on finding a solution, I tried to piece together a player using both HTML 5 video, and FlashPlayer for less capable browsers like Internet Explorer. You can find a demo alpha version of the player here: http://makingria.com/demo/html5/videoplayer/

Browser support

The player supports the following browsers:

• Internet Explorer 7 (FlashPlayer, H:264 video)
• Firefox 3.6 (Native playback, OGG Theora video)
• Google Chrome and Apple Safari (Native Playback, H.264 video)
• iPad and iPhone (Native Playback)
• Opera 10.5 (Native playback, OGG Theora video)

How to build it

My approach to building the player was based on my not so patented “falling down the stairs” method. In plain English this means that playback methods are ranked in a list, falling down the list as support for the wanted playback method is not found.  To accomplish this we utilize the HTML5 video tags ability to hold a list of different source videos. If no support for html5 video is found the video tag will be replaced by swfObject using the Modernizer JS framework.

The list looks as follows:

1. HTML5 video using the H.264 codec – high-res (WebKit browsers and iPad)
2. HTML5 video using the H.264 codec – med-res (iPhone)
3. HTML5 video using the OGG Theora codec (Firefox/Opera)
4. FlashPlayer video using the H.264 codec (Internet Explorer)
5. Error message (Others)

I wanted the player to support play/pause controls, zoom control and outputting the current time and the duration of the video no matter what video playback method being used. I accomplished this by using JavaScript to control all of these aspects of the video, even when using FlashPlayer as the video playback method. If you want to see how this was done in practice, go take a peek at the JavaScript. The code for the FlashPlayer based player can be found here.

Performance

CPU usage is a challenge when playing high resolution video. On my computer, a ThinkPad Intel Core 2 Duo 2.66 GHz with 4 GB RAM (Windows 7 64 Bit) I found that the combination of HTML 5 video playback in WebKit based browsers using the H.264 codec gave the best results when playing a 720p HD video. Also notice the smooth scaling when testing the video in WebKit based browsers.

When using the Gecko renderer in Firefox 3.6, the CPU usage almost doubled compared to the H.264 playback in the WebKit browsers. And it needs to be noted that this was a huge improvement from Firefox 3.5 where native video playback was pretty close to unusable due to a 60-80% CPU usage. This spike in CPU usage is probably caused by the OGG Theora decoder in Firefox and Opera.

In Internet Explorer you’ll end up watching a FlashPlayer rendered video as Microsoft has yet to release a browser supporting the HTML 5 video tag. What’s interesting is the fact that the FlashPlayer renders video content far more efficient (CPU vise) that the native video rendering in Firefox and Opera. WebKit’s native video implementation is slightly more efficient that the one of FlashPlayer, but not by much. It should also be noted that this test was done in FlashPlayer 10.0. Not the mythical speedmonster (rumored) which is FlashPlayer 10.1.

One of the great news is the native support for the vector graphics language SVG.
SVG 1.1 became a W3C recommendation already back in 2003, so it’s about time we developers can start use this great technology.

Speedy performance

IE9 uses the GPU for graphic rendering through DirectX, and this gives good performance, currently beyond what all other browsers can perform.

Currently scores 28% in test

In this earliy build, only some SVG functions are implemented. This results in poor rendering of more advanced SVG files. See the SVG test chart where IE9 Preview 1 gets a score on 28% at http://www.codedread.com/svg-support.php

No plans to support SVG Filters

This is a slide Microsoft presented at MIX that show they unfortunatly don’t plan to support things like Filters and SVG fonts. This is disappointing. Let’s really hope Microsoft change their mind, and will commit to support the full SVG 1.1 standard, at least at the same level as competing browsers like Firefox, Chrome, Safari and Opera do today.

• new set of skinnable Spark components and skinning architecture which leads to better separation between data and view
• introducing FXG declarative syntax for defining graphics
• two way data binding

But if you want to explore full list of changes and improvements to framework, there is a “Flex 4 features and migration guide”, which could give you more information about it.

New set of Spark component architecture defines entirely new way of building application view. Now view and data are separated, and each of functional component can be skinned to look completly different than “default” one. For example you can skin radiobutton to look like button, but still have radiobutton functionality – single select or grouping. This feature is extremely useful, and makes life of developer much easier.

Spark components also adds some new features e.g better handling of text by RichText and RichEditableText controls which enables developer to handle text more efficiently and easily. My personal foe – Repeater could be replaced by Spark DataGroup component which behaves far more intuitive  and of course is suited to new skining architecture

Flex 4 introduces also FXG declarative syntax, it is similar to Degrafa, and in simple words enable programmer to create vector graphics by writing piece of MXML code. This alone is not a big deal, but please remember that there is a data binding mechanism – and having those two together implementing a custom bar progress indicator or some fancy buttons is much, much easier.

Finally we have databinding that works both ways, so when connected to e.g. RichEditableText you will got property synchronized with it’s text. The only thing to remember is to have property that need to be bound declared as public.

Flex 4 is a big step ahead, it resolves a lot of problems that was a pain in Flex 3. I will encourage everyone to use it since it is far better than Flex 3, in my opinion, and could save some development  time especially in skinning of application. Together with Catalyst and Flash Builder it will create a powerful platform for building RIA applications.

Flash Builder (which is a succesor to Flex Builder) is currently avialable in beta 2 version for some time now. Since Adobe is still postponing release date of final versions I decide not to wait any longer and try to grasp it’s new features in some application more complicated than samples provided in tutorials that could be found around the webAfter dowloading and installing application we get 60 days of evaluation period, but it can be prolonged using valid Flex 3 license number.

Flash Builder looks much the same as it’s older brother, but even on the first glance there are small changes that could make developer’s life easier – “Flex Naviagtor” which showed file structure of project in Flex Builder is now changed to “Package Explorer” which basically serves the same purpose but it doesn’t stop on the file level – you could expand each as or mxml file to see its attributes. properties and methods. Of course click on method take you dirrectly to it’s implementation – in fact from file level it looks and acts exactly the same as “Outline” view (which is still there).

When looking into code one could notice slighltly different ways of colouring code. Also Code assits works much better and more up to date with current standards when it comes to development environments. For example you could filter to only show events of certain component without need to scroll through numerous entities on hint list. The feature I found very useful durring some day-to-day work is connecting Code assits with Adobe livedocs with could save a lot of time when looking for explanation of some rarely used feature. Finally the code generation got feature of generating getters and setters with makes any excuses for not creating them futile. One of the most irritating feature of FlexBuilder 3 is also gone: when importing project into environment there is only one path to set. It was such a annoyance to have to copy path to second input each time because otherwise my project got copied to some “workdir” under “My documents”.

My general immpression is very good, Flash Builder is stable (at least with comparison to Flex Builder), there are some very nice features that was absent in Flex Builder 3 , and for those who don’t want to use Flex 4 SDK  (which is still beta) you can use  3.4 SDK as well. If you are got used to Flex Builder switching into new environment will be no problem because after all the core is still Eclipse.

Different browsers have different “default” styles, which makes it a challenge to even make text appear the same way across all of them. When you want to accomplish this, there is a well known CSS trick that I’ve been using for a long time:

html {
    font-size: 100%;
}

body {
    font-size: 62.5%;
}

These rules will make 1em = 10px; font-size: 1.2em is the same as 12px. The method is particularly useful on sites where you want to let the user scale all content using links on the page. The links will adjust the base size on the body element which is inherited to all child elements.

This works for font scaling, but as I discovered, it is inaccurate when setting widths and heights of elements. 96em is NOT exactly 960px. I set out on the interwebs to research and found another method in a comment to an article about font sizes and ems:

html {
    font-size: 1.25em;
}

body {
    font-size: 50%;
}

Apparently, IE doesn’t allow for percentages with decimals, so 62.5% is floored to 62%. This isn’t a big deal for text, but when using it for dimensioning other elements, it’s a deal breaker.

The method above will set 1em = 20px for the html element and then halve this by setting the font size to 50% on the body.

This way is new to me, but after testing it in all major browsers (IE6 included), it seems to work. As you may understand, I’m not really sure about this, so I’m reaching out for you here. Do you have experience using any of these methods to set font and element sizes? Or do you have other methods? Will the latter method always work and in all browsers? Please use the comments if you have any input.