Quite an impressive open source implementation of HTML5′s video. It aims for a cross-browser, consistent implementation of a modern video player. It’s fully featured and includes a lightweight Flash fallback (yes, that’s still both applicable and important).

Additionally, you can piggyback the CDN-hosted version, or go ahead and do it yourself. Lots of good included here.

Advertise here with BSA

Edge is touted as “A tool for doing HTML5 animations” but personally I’m guessing this is how Adobe plans to handle the whole “Flash” situation as time goes on.

A number of things struck me as I watched the video:

Layer palette “is the DOM” which (directly?) translates into divs which are given the properties defined in other parts of Edge (e.g. the name is the id). That’s an interesting approach, but I’m curious to see how quickly (if) things get out of control on a markup level.

Timeline based. Edge is actually timeline heavy which is a turn off for me, but it’s simply gravitational for new users. Adobe is attempting to lower the barrier for entry with HTML5 animations and become a leading company through the masses.

Uses Webkit, which is credited for providing the HTML5 features Edge is based upon. We’ve all been waiting for a tool that is a true-to-life WYSIWYG preview of our work. I don’t mean WYSIWYG in the terms of the lameness that earned the name WYSIWYG, but a pixel-accurate view of what our work will look like in browser.

Edge requires jQuery and a number of other jQuery-based dependencies. It’s great to see jQuery satisfying another need.

I’m curious how far Adobe will take Edge. We all know that as great as HTML5 is, tools like these can produce the same junk we have no problems complaining about on a daily basis. We’ll see what happens.

Advertise here with BSA

I wanted to jot down some of our thoughts on Adobe’s Flash products so that customers and critics may better understand why we do not allow Flash on iPhones, iPods and iPads. Adobe has characterized our decision as being primarily business driven – they say we want to protect our App Store – but in reality it is based on technology issues. Adobe claims that we are a closed system, and that Flash is open, but in fact the opposite is true. Let me explain.

The piece tackles the main issues brought up against Apple in an attempt to outline the significant reasons as to why Flash is absent on the iPhone OS platform. First, the opinion that Flash is an ‘open’ format is put to bed.

The next argument surrounds the opinion that “the full Web” is limited on the basis that Flash powers the mass majority of video on the Web. While true, all of the major players have already adapted to the open standard format that is HTML5 video. Next.

Next is security. Flash is plagued with Windows XP syndrome in that since it’s so popular, it’s a prime target for cracking. There have been plenty of security bulletins and emergency releases on the Flash platform and while it’s nothing specifically against Flash as inferior in any way, it’s a fact of its position.

Battery life is a huge concern when it comes to Flash. While hardware acceleration is coming; it’s not here yet and the Web has already progressed through HTML5. The Web moves too fast and by the time hardware acceleration is common place, the dust will already have been settled.

We also need to keep in mind the interactions we have with Flash. It’s all via mice. Touch doesn’t translate very well and Steve goes on to explain a bit more about that in the piece. Long story short, much of the Flash stuff people are smitten with would need to be (at least in part) rewritten to function properly.

Last, Steve touches on what he mentions as the most important reason: the third party aspect. He explains that Adobe’s first goal with Flash is cross platform development, and that often leads to sub-standard experiences and applications. He dictates that Adobe “has been painfully slow to adopt enhancements to Apple’s platforms” — so true.

Our motivation is simple – we want to provide the most advanced and innovative platform to our developers, and we want them to stand directly on the shoulders of this platform and create the best apps the world has ever seen. We want to continually enhance the platform so developers can create even more amazing, powerful, fun and useful applications. Everyone wins – we sell more devices because we have the best apps, developers reach a wider and wider audience and customer base, and users are continually delighted by the best and broadest selection of apps on any platform.

I whole-heartedly recommend that you read the piece, in its entirety, without any bias you may have. Thoughts on Flash.

My stance: regardless of this fighting, that coffin is so full of nails it looks like it were made of stainless steel.

Advertise here with BSA

When it comes to websites though, seeing a website built in Flash is a near guaranteed turn off personally. To me, a website built in Flash forks away from the inherent purpose of a website, and turns into a novelty. From the most generic standpoint, my opinion doesn’t even generate from the accessibility and performance concerns that come from a website built in Flash. It’s the usability of the website, the fact that it’s just, different.

However, many clients are attracted to websites built entirely in Flash. To me that comes from an interest rooted in everyone: motion. Things that move are, by default, more interesting to look at. I think I’ve discovered that my distaste for such things comes from a personal appreciation that has evolved as a Web designer. To me, a website with a solid design, solid information architecture, is extensively more pleasing than something that glows and animates left to right simply for the sake of visual stimulus. Information architecture, to me, is that visual stimulus, and making it move around completely detracts from my experience.

I don’t mean to say that a Flash site, by default, lacks anything from an information architecture point of view. In fact I’ve seen many Flash based websites that were designed terrifically, I simply would have preferred to view it as markup and style. I have the upmost respect for Flash designers & developers, as some of the work is simply stunning. I’m speaking from an abstract personal preference here, full of my own bias. I don’t mean to offend and I hope this isn’t coming off with any sort of attitude.

Working with Flash as a front end developer

I think my opinion of Flash based sites comes from my position as a Web designer. Specifically I’m a Web designer with a focus on front end architecture, quite different from a Flash designer. I’m a big believer in great teams working very well together, and my company has some terrifically talented Flash developers that I work with every day to create stunning pieces that please our clients. I need to put my opinions aside and make sure that the client gets what he wants, all the while making sure the website has an equally effective and useful alternate site to use. That involves a revised design to accommodate the variation in medium, as well as the development and deployment of that website for use.

One of the greatest things to ever happen to Flash, in my opinion, is SWFAddress by Asual. SWFAddress is:

SWFAddress is a small, but powerful library that provides deep linking for Flash and Ajax. It’s a developer tool, allowing creation of unique virtual URLs that can point to a website section or an application state. SWFAddress enables a number of important capabilities which are missing in today’s rich web technologies including:

• Bookmarking in a browser or social website
• Sending links via email or instant messenger
• Finding specific content with the major search engines
• Utilizing browser history and reload buttons

Basically, what SWFAddress does is give Flash the ability to behave that much more like a regular website by enabling the built in functionality of the browser within the Flash movie itself.

Using SWFAddress is necessary when working with a Flash website, not only for the inherent functionality improvements, but also to the benefits of your alternate site. The Asual team has included many examples of SWFAddress as well as documentation for each, the one to focus on is the SEO Example. This sample demonstrates what SWFAddress can do to integrate your Flash site with your alternate site seamlessly, allowing for effective search engine indexing, as well as equivalent access to your alt site.

The demo provided gives you access to a bit of PHP that handles quite a bit of redirection when it comes to processing a URL request. The script will help to determine if the visitor does indeed have Flash/JavaScript and in turn provide the proper “enhanced” URL, while passing site content to a user without the ability to view the Flash site. Clean URLs are retained and it’s actually a very effective solution.

Making an effective alt site

Building a Flash site is quite a bit of work, not only on the Flash side of things, but the development and maintenance of the alternate site as well. SWFAddress will route your traffic effectively, but you’ll need to manually distinguish which pages should serve which content and make sure equivalent content is represented in both websites.

With a content management system, you’ll be able to pull the same data per page via XML or otherwise, allowing both the Flash version of the site as well as the alt site, to pull from the same data source which will remove any discrepancy when it comes to content.

The inclusion of SWFAddress helps to tackle many of the baggage of Flash, and allows Web designers to create a very effective alt site both for the sake of search engine saturation, but even more importantly the benefit of accessibility.

What do you think?

What’s your opinion on Flash? Has that boat sailed when it comes to full websites? Will we see Flash only used when really necessary, for rich site widgets, video (until HTML5 becomes available), or other implementations limited to Flash? Does it bother you when you find yourself at a website built entirely in Flash? Does SWFAddress help with any issues you’ve got with Flash? With the advancements in front end technologies such as CSS3, CSS animations, canvas support, and O3D, do you think Flash is steadily taking a back seat for things to come? I’m just not sure if I’m alone here, and would love to hear some other opinions.

Advertise here with BSA

Advertise here with BSA

I’ll get it out of the way early by saying that this update has absolutely no effect on the repercussions of using Flash when taking accessibility concerns into mind. This algorithm change is purely search engine technology with a separate listing of pros and cons.

What’s different, technically?

From what’s been posted about the algorithm update, the only big change as far as Flash indexing is the fact that Google can now see any text included in a Flash piece. The update also includes the ability to crawl any referenced URLs in the movie as well.

It’s important to keep in mind what content will remain absent from the indexing algorithm:

At present, we are only discovering and indexing textual content in Flash files. If your Flash files only include images, we will not recognize or index any text that may appear in those images. Similarly, we do not generate any anchor text for Flash buttons which target some URL, but which have no associated text.

Also note that we do not index FLV files, such as the videos that play on YouTube, because these files contain no text elements.

The limitation here runs parallel to that of the indexing of HTML, but that’s not to say HTML and SWF are on the same level. When considering HTML, Google is able to see alt attribute information for images in HTML documents, which should contain valuable information outlining the content of the picture.

Something else to keep in mind is the provided list of limitations with Google’s updated ability to crawl Flash:

There are three main limitations at present, and we are already working on resolving them:

1. Googlebot does not execute some types of JavaScript. So if your web page loads a Flash file via JavaScript, Google may not be aware of that Flash file, in which case it will not be indexed.
2. We currently do not attach content from external resources that are loaded by your Flash files. If your Flash file loads an HTML file, an XML file, another SWF file, etc., Google will separately index that resource, but it will not yet be considered to be part of the content in your Flash file.
3. While we are able to index Flash in almost all of the languages found on the web, currently there are difficulties with Flash content written in bidirectional languages. Until this is fixed, we will be unable to index Hebrew language or Arabic language content from Flash files.

The list really gets me curious to see how things will go as far as dynamically injecting Flash into a document and whether it will be beneficial for search engine saturation. For instance: what if Google does execute the JavaScript which inserts a Flash movie into my document, but the alternate content I provided was much more search engine friendly? How do I ensure that Google indexes the content I intended to be indexed as opposed to the more limited Flash version? There are plenty of questions to be asked in reaction to this update.

What does it mean for us?

This update from Google will probably have some interesting repercussions. For instance, it doesn’t take much time to infer who exactly was making the multitude of requests for SWF indexing. If you’re not well aware of effective ways to provide alternate content, who else are you going to blame when your client is asking why they don’t show up in any search results?

I’m not sure if anyone else shares this type of concern, however. Taking a step back and thinking about it; is an improved algorithm that indexes Flash content going to act as a benefit to the general public? I’m not so sure. It’s as though the update can be viewed as both a positive and a negative at the same time. On one hand, it could be very beneficial when implemented properly, ensuring equivalent alternate content continues to be provided. On the other hand, many developers will now (lazily) opt out of providing alternate content simply because Google can read their text content.

My initial reaction to this update was mostly negative and partially positive. One of the major reasons I felt that way was after reading this paragraph from the more detailed post on Webmaster Central:

We’ve developed an algorithm that explores Flash files in the same way that a person would, by clicking buttons, entering input, and so on. Our algorithm remembers all of the text that it encounters along the way, and that content is then available to be indexed. We can’t tell you all of the proprietary details, but we can tell you that the algorithm’s effectiveness was improved by utilizing Adobe’s new Searchable SWF library.

The scariest thing to read in that paragraph for me is “We can’t tell you all of the proprietary details…” Now, I’m not so ignorant as to say that Google shouldn’t have some secrets guarding how they remain the big name in search, but that statement was a big reminder that virtually everything surrounding this update is behind closed doors of both Google and Adobe.

The use of Flash is remarkable as far as plugin saturation is concerned, but I think it’s something that should be kept in mind with updates like this.

How does this change SEO?

I’m very interested to see how much weight is given to Flash content with this update. Do you think Google will treat text found in Flash equally to that of content found in an HTML document? It’s a strange notion to consider, and I’m not sure I could make an educated guess quite yet, but I’d be very interested to see what Google has to say about it over the coming months.

In the grand scheme of things, in an attempt to not think like a Web developer, this update will probably be beneficial for the general public. Poorly developed Flash sites will now be that much easier to find. Stepping back into professional opinion, I’m very leery of the update. It’s as though we’re taking a step back in a way, but are we? Flash is obviously going nowhere; it’s here to stay. Should we be glad that Adobe and Google are working together to improve the technology? It’s hard to say that we’re worse off as a result of this update. Like all things, we can only hope it’s not taken advantage of.

Advertise here with BSA

As an update to the list of things I was looking to complete during my time off, it was just the thing I needed. I was able to spend some much enjoyed quality time with Carrie (she got us a Wii!) and I was able to get a number of things done with/for my family.

Some technical details

It was good to try and unplug for a short amount of time and focus on some other things going on. At the same time, however, it was great to have some more time to read up on some things I’ve been meaning to teach myself for some time. I recently cracked open Essential ActionScript 3.0 and try to get myself more versed in that area as well as Flex and AIR. I’ve been meaning to get into Flash for (literally) years, so what better time than now? My question to you is this: are you at all interested in me writing pieces on the topic of Flash? I’d love to start writing and thinking about the general effect the technology has and will continue to have on Web development, but I’d like to know if anyone is at all interested before doing so.

On top of that, I’ve been playing a bit with the Fireworks CS4 beta and (partially) opposed to some people, I’m loving where things are headed. I’d like to post updates on the application side of things as well, including text editors, FTP clients, and some of the other tools I find myself relying on quite a bit. My issue with that, however, is that the posts would turn out to be heavily Mac oriented, and I’m not completely comfortable writing articles that aren’t useful for everyone. Are readers using Windows/Linux opposed to articles written about Mac software? Please take a second to leave a quick note regarding your stance on the matter, even if you’re a Mac user, I’ll base my decision on whether or not to write articles of that type on the comments.

Please bear with me for just one more week

All in all, I hope I didn’t lose too many subscribers, and you can expect some new articles to be posted starting a week from today. Stay tuned!

Advertise here with BSA

The spark that ignited

While the debate may have been smoldering under the surface, the post that [more or less] caused the blaze to ignite was Dear W3c, Dear WaSP by Molly E. Holzschlag, in which she states:

Pay attention, W3C and anyone who cares. We have serious problems. On the surface:

• HTML 5 serialization under W3C
• Run Time Environments such as AIR
• Personal agendas overriding agendas that serve the greater good

I call on my colleagues, my friends to talk about this.

…

Are you all just dumbed down by the fact you’ve got a job or what? Tell me. Let’s fix it. W3C, WaSP, whatever. We have problems.

Let’s talk about them and figure something out.

In her post, Ms. Holzschlag takes a firm stance behind her position regarding the state of the Web and those behind its advancing. She plainly asks for commentary on the issues in an effort to get them resolved.

The wide range of response

I strongly urge everyone to read the thread of responses posted in reaction to the entry (as well as the follow up entry), as the authors are many we have come to respect as industry leaders. Reading comment threads such as those illustrates wonderfully the point I was trying to make in 9 Ways to Improve Yourself: read and talk as much as you can.

The responses range from whole-hearted support to all out opposition, each with strong points to support each case. Many designers and developers sympathize with Ms. Holzschlag in saying too little is being done and that little bit is taking way too long. Others argue that something so large in scope must be approached slowly, with every aspect researched, supported, and understood.

One of the most notable, direct responses was What crisis? from Mr. Jeffrey Zeldman. In his reaction, he states:

Certainly the W3C moves at a glacial pace. It’s why we write float when we mean column. But a glacial pace isn’t all bad, especially if you’re driving off a cliff (which I gather we are). Driving off a cliff at a glacial pace affords you the luxury to turn around. I loves me some glacial pace.

The glacial pace of the W3C has given browser makers time to understand and more correctly implement existing standards. It has also given designers and developers time to understand, fall in love with, and add new abilities to existing standards.

Mr. Zeldman, as many others, is simply asking for a [somewhat detailed] breakdown of the crisis as viewed by so many, because he isn’t aware of such. There are also many other great, well thought-out responses to be read, so be sure to read what you can.

My personal opinion on the matter

I tend to have an opinion on many things, but in this specific circumstance, I must admit I’m quite divided. I can see strong points from both sides, and I am unable to stand firmly behind one side over another. I am very much in support of the advancement of Web standards, and understand that adjustments should be allowed ample time to become established. On the other hand, the time for implementation can be measured in decades when it comes to the W3C, and that can become frustrating.

I can completely support wonderful write-ups on this issue (and again great comments) by legends such as Jeff Croft, and I can also see where Zeldman is coming from. Implementation can’t be rushed when you’re working with such an entirely huge project. Taking a snippet from the comments on Mr. Croft’s post — it would be great if browser manufacturers began to push updates to the browser rendering engine itself (as opposed to the entire browser) in an effort to speed this process along. Flash has been operating this way for some time, and it does in fact seem to be working out.

In conclusion, I can’t really say that I am completely fed up with the way the W3C operates — mostly because I am still trying to establish myself in completely understanding the process and those involved. I do not see myself as enough of an authority to have an established opinion on these issues yet. Yes, I work with the Web on a daily basis, and try to make the Web a better place with what I do, but these men and women have made the Web what it is today. I can completely understand where veteran, industry leading designers and developers are becoming frustrated, and I love reading what they have to say. Their knowledge and experience is some of the best information we can read. Me being able to read intelligent arguments from both sides greatly helps in my decision making process.

Many people view (X)HTML/CSS as stale in favor of a (flashy) Flash application, and it’s hard to blame them. Nothing dramatic has happened on the markup and style front in quite some time, and Flash has really taken the spotlight because it’s able to innovate and globally deploy and become adopted at an extraordinary rate. In my opinion, it would be fantastic if the W3C aimed to work at that speed.

Most importantly; what about you?

If you haven’t spoken your mind about this issue ten times over thus far, I’d love to hear your opinion on the matter. Do you think the W3C is too glacial for anyone’s good? Would you rather have browser rendering engine upgrades a la Flash player? What other thoughts do you have on the issue?

Advertise here with BSA

A short history of custom type on the Web

We can all remember back to the days where finding bits of information about font requirements were found next to the screen resolution requirements as well as browser requirements. Many times, the fonts were supplied with a quick hyperlink and after a quick download, unzip, installation, and restart of your browser you were ready to go! Luckily, providing a requirement such as that seemed to be short lived (although you still run across the issue as well as browser and resolution requirements to this day). With the implementation of CSS, developers and designers had much more to work with and were now able to use more effective techniques in their designs.

CSS based image replacement

Using CSS image replacement caught on like wildfire and many designers use it in nearly all of their work. Personally, I find myself using the technique at least once in nearly every project I work on, including this website. There are many different methods used for image replacement, each with their own set of pros and cons. A great resource to read about and view examples of various techniques is a post on mezzoblue entitled Revised Image Replacement. A number of methods are detailed including a short description, code sample, and live examples of each.

During the second revision of this website, I had come up with a technique for image replacement that I hadn’t seen anywhere else. The details are included in the write-up, but essentially it was the best way I could find to not bloat the code with extra markup while retaining accessibility as best as possible. Instead of trying to hide any of the content in the first place, I attempted to camouflage it using the color of an image. Please read more about my latest take on image replacement.

What is sIFR anyway?

As taken from WIKI.NOVEMBERBORN:

sIFR (or Scalable Inman Flash Replacement) is a technology that allows you to replace text elements on screen with Flash equivalents. sIFR is the result of many hundreds of hours of designing, scripting, testing, and debugging by Mike Davidson and Mark Wubben. Mike, Mark and an invaluable stable of beta testers, supporters, and educators like Stephanie Sullivan and Danilo Celic of Community MX completely rebuilt a DOM replacement method originally conceived by Shaun Inman into a high quality cross-browser, cross-platform typography solution for the masses.

In my opinion, sIFR is, in and of itself, quite a good idea as well as an evolved technique. Earlier versions of sIFR became available some time ago, and it is still being researched as well as developed to this day. The new beta releases are including new features, as well as rethinking implementation itself. My main question is: why is sIFR not more widely implemented? Is it because of the requirements placed on the reader in that they need to possess a third party plugin as well as have JavaScript enabled to run a check for that plugin?

While requirements placed on the reader may be slightly overbearing, sIFR was developed in such a way where it will gracefully degrade for your readers. Am I mistaken in my observation that sIFR is not implemented as much as you’d think?

In closing

As with any story, there are two sides with both CSS based image replacement as well as sIFR as choices for custom type in headings. There are accessibility issues attached to image replacement, and user requirement issues when dealing with sIFR. Which do you think is the better choice and why?

P.S. I’ve ended posts with questions before in hopes of getting some opinion from readers as I value their opinion. I’m hoping that those of you who don’t normally write a comment after reading the article can find a few minutes to do so on this. I’m truly interested in the reaction other designers and developers have regarding the two techniques. Thanks a lot in advance!

Advertise here with BSA

The disaster that was

Back in the days of media player badges and codec requirement notification paragraphs, it would take a large effort from your reader to successfully view any piece of video you wanted to share. They had to have the proper credentials to view the clip or else they would be faced with various ‘missing plugin’ notifications either from their media player or browser. With any luck a reader would be provided with instructions on how to obtain the proper software in order to play the file, and after installing the new software, they could hit your page and try again. In my personal experience, that process left much to be desired, including repeated browser crashes and general failure of properly viewing the video.

What’s interesting is how determined people are in their stance behind getting video on their webpages. Time after time, new techniques were thought up to try and improve the state of video on the Web. More often than not, the new methods were just as bad as the previous, until one method came along that would rule them all. A method which uses technology the majority of your readers would have anyways.

The rise of Flash video

Flash video (FLV) has been available since Flash version 6, but until fairly recently it was ignored in a way. The evolution of certain video based websites really pushed the use of Flash video into the mainstream at a rapid rate. Through these huge Flash video based websites, the ability to make Flash based video was easier than ever for anybody to do. Not only was it easy to create, it was easy to do what you wanted with it. Including the pieces of video just about anywhere was now arguably simple for someone to do. Viewing the video was also quite nice — the ability to fast forward, rewind, pause, adjust the volume, and perhaps most importantly: stream, were all present and it seemed to ‘just work’ (unlike many previously accepted techniques).

Beyond the convenience of actually using FLV, designers have the ability to customize the player in which their video is played. Unlike using one of the various media players which inherit their native interface, a FLV player can be designed to really mesh well with the project you’re working on.

So why is Flash video so great?

The true benefit to Flash video, in my opinion, is the ability for Web developers to provide effective alternate content for the content. Flash video has its own accessibility benefits, including the ability to provide subtitles and captions for the video. Not only that, a developer could use unobtrusive Flash detection via JavaScript to see if the reader has the proper version of Flash. If they don’t, links to download the content in other video formats could be included. Personally, I think we can do better than:

This site uses Flash 8. You need to upgrade your player to view this content.

“Alternate content” such as that puts us back at square one — you may as well have a WMP badge linking to a download page. Links to download the video in other [popular] formats would work better here, in my opinion. Beyond that, different alternate content could be provided entirely. Instead of providing download links, equivalent text could be provided, outlining the dialog of the video if necessary.

In defense of the strictly based video sharing sites, a message similar to that used above may be acceptable; after all, the sole purpose of the site is to display a piece of video. Much of my opinion surrounding alternate content for video is when it is included as a piece of information to be absorbed by readers.

In summary of Flash video

While I personally feel that Flash is sometimes overused just to say it’s there, I think for video, FLV is by far the best solution. I think that we’re at a point where Flash can be included within a document in such a way where it is not obtrusive to anybody. While some may argue that you are neglecting the population that chooses to browse the Web while having JavaScript disabled, my argument is that through the production of effective alternate content, it shouldn’t be a problem. Your reader should be provided with equivalent content, and theoretically not even know they missed out on a Flash based video.

All in all, I believe using FLV in combination with unobtrusive Flash detection to include video is currently the best solution. The benefits to design are secondary to the ability developers are given to provide effective alternate content. The most difficult genre of multimedia to provide alternate content for would have to be video; animated visuals in sync with audio does not convert to something text based very easily. The development of FLV and functional Flash detection techniques are a step forward.

Advertise here with BSA