Just a quick note that I undertook this recently and it was quite a painless process. I needed to create a server socket which is only possible with the AIR API. Pretty much all I did was to change the frontal_renderer.fla’s publish settings to create an AIR application and that was it! All of the AIR API’s are automatically available. (In a few cases these are incompatible with the Flash Player’s API so if your publishing to both environments you may have to switch off the value of flash.system.Capabilities.playerType.)

After I had success with that, I decided to publish to AIR for Android. (This is available with a free extension to Flash Profession CS5 from labs.adobe.com.) After fixing a bug where I was trying to set the context menu in Document.as even if the target platform doesn’t support context menus, it worked just fine. I loaded the resulting Frontal app onto a Google Nexus phone and got really nice performance. So cool to see it running on a phone! Can’t wait to try it on and Android tablet.

Theoretically this should work no problem on an iPhone or iPad as well but I don’t feel like shelling out the money to develop for a device I already bought. Maybe someone else can try it?

Questions? Post them on the forums.

Jacob at Six Revisions asked me for my perspective on Apple and Flash.  Here it is:

http://bit.ly/a4amUb

When you think about it, Flash is far and away the best positioned to become the leading cross-device development platform.  How can Adobe make this happen, and get past the Apple issue?  Focus on Flash performance and openness.  Actually Adobe, if you focus on taking the plug-in to the next level, we at Frontal are more than willing to take care of openness.

As Barborak announced a couple of days ago, we’ve decided to take Frontal open source.  We received a lot of valuable feedback from users over the past 8 months – around 25 live sites were built using Frontal during that time.  Many of them were HTML sites that strategically used the language for specific interactive features like video, animations, scrollbars, etc.  During this time, it became clear to us that developers want to use Frontal the same way they use open standards like HTML, JavaScript, CSS, etc – employing each one to do what they do best.

Luckily, we created Frontal to be web-native – it’s a language that embeds and works seamlessly within the HTML/JS ecosystem.  (As opposed to standalone technology that sits beside web standards, like what Flash is today.)  However, to fully achieve this web-native vision, we realized that it wasn’t enough for the language itself to fit this ethos, our usage model needed to fit it as well.  So after a lot of conversations internally and with our partners, we’ve decided to take Frontal open source.  And we’ve gone all the way by adopting the OSI-approved New BSD license model – one of the most open open source licenses in the market.  By taking this step, I believe we’ve done something pretty momentous – we’ve made Flash open source.  There are a number of huge implications as a result.  Here are three ‘the tip of the iceberg’ examples:

You can now use Flash in bite-sized pieces – Creating in Flash has traditionally required a substantial upfront investment in time and money.  Through Frontal, Flash can now be used where, when, and how it’s needed.  No new file creation is necessary, just place the Frontal code into your HTML and run it.  And because Frontal uses the same standards as HTML, JavaScript and CSS, understanding how to use it is easy for most web designers.

Flash collaboration is now unleashed – Making Frontal open source and transparent means that designers / developers can now easily share interactive content approaches with each other.  All you have to do is mouse-over a Frontal element embedded in a page, right-click and select ‘View Frontal Source’.  For the first time, designers can easily copy, paste and customize interactive content and apps for their own use – all for free.

The most practical interactive web content solution – Now running video and creating animations in HTML pages is dead simple.  This simplicity is driven by two factors – the Frontal language’s standards-based approach, and the fact that 98% of browsers have the Flash plug-in.  (An added bonus – Frontal is both search engine indexable and supports deep-linking.)  This leaves you free to create lightweight interactive website features quickly and easily, without having to develop workarounds for different browser implementations of HTML5.  As an example, here’s a simple interactive animation written in HTML5:

<!DOCTYPE html>
<html xmlns=”http://www.w3.org/1999/xhtml”>
<head>
<style type=”text/css”>
#h34
{
cursor: pointer;
height: 50px;
background: #e36b00;
width: 50px;
-webkit-border-radius: 25px;
-moz-border-radius: 25px;
padding: 0px;
display: inline-block;
position: absolute;
left: 100px;
top: 30px;
}
</style>
<script text=”text/javascript”>
function loadDemo ( ) {
var vendor = (Browser.Engine.gecko) ? ‘Moz’ : ((Browser.Engine.webkit) ? ‘Webkit’ : ”); // Firefox or webkit
if(vendor == “Moz”){ // extends mootools styles for Firefox
var newStyles = new Hash({
‘MozBorderRadius’: ‘@px @px @px @px’,
‘MozBoxShadow’: ‘@px @px @px rgb(@, @, @)’
});
}
if(vendor == “Webkit”){ // extends mootools styles for Chrome and Safari
var newStyles = new Hash({
‘webkitBorderBottomLeftRadius’: ‘@px @px’,
‘webkitBorderBottomRightRadius’: ‘@px @px’,
‘webkitBorderTopLeftRadius’: ‘@px @px’,
‘webkitBorderTopRightRadius’: ‘@px @px’,
‘webkitBoxShadow’: ‘rgb(@, @, @) @px @px @px’
});
}
if(vendor == “Webkit” || vendor == “Moz”){ // set up an animation for each. Very messy
$extend(Element.Styles, newStyles);
$(“h34″).set(‘morph’, {duration: 300, transition: ‘Back:out’, onComplete: function(){
}});
}
if(vendor == “Moz”){ // errr hideous code, but it was late. (I’m so ashamed)
$(“h34″).setStyle(“MozBoxShadow”, “0px 0px 0px #43280D”);
$(“h34″).addEvents({
‘mouseover’: function(){
$(“h34″).morph({‘MozBoxShadow’: “-6px 8px 0px #43280D”, ‘left’: ‘106′, ‘top’: ‘22′, ‘background-color’: ‘#ff7e00′});
},
‘mouseout’: function(){
$(“h34″).morph({‘MozBoxShadow’: “0px 0px 0px #43280D”, ‘left’: ‘100′, ‘top’: ‘30′,’background-color’: ‘#e36b00′});
}
});
}

if(vendor == “Webkit”){
$(“h34″).setStyle(“webkitBoxShadow”, “#43280D 0px 0px 0px”);
$(“h34″).addEvents({
‘mouseover’: function(){
$(“h34″).morph({‘webkitBoxShadow’: “#43280D -6px 8px 0px”, ‘left’: ‘106′, ‘top’: ‘22′, ‘background-color’: ‘#ff7e00′});
},
‘mouseout’: function(){
$(“h34″).morph({‘webkitBoxShadow’: “#43280D 0px 0px 0px”, ‘left’: ‘100′, ‘top’: ‘30′,’background-color’: ‘#e36b00′});
}
});
}
}
</script>
</head>
<body>
<div id=”h34″></div>
<script src=”http://ajax.googleapis.com/ajax/libs/mootools/1.2.4/mootools-yui-compressed.js” type=”text/javascript”></script>
<script text=”text/javascript”>
window.addEvent(“domready”, loadDemo);
</script>
</body>
</html>

Notice all of the Webkit and Mozilla workarounds.  Here’s the same thing written in Frontal:

<style>
#h34
{
left: 100px;
top: 30px;
width: 50px;
height: 50px;
background-color: #e36b00;
background-shape: ellipse;
bg-shape-ellipse-width: 50px;
bg-shape-ellipse-height: 50px;
shadow-color: #43280D;
shadow-strength: 1;
shadow-distance: 0;
shadow-angle: 135;
shadow-blur: 0;
style-tween-duration: 8;
}
#h34:hover
{
left: 106px;
top: 22px;
background-color: #ff7e00;
shadow-distance: 8;
}
</style>
<div id=”h34″ />

Of course there are many more implications that we’ll be discussing over the next few months, after we’ve had a chance to fully wrap our heads around them.

So we’re excited as hell!  If you’re a practical web developer who believes in using any technology that’s open and works well, then we think we’ve given you a powerful tool.  One that will help you deliver great user experiences.  And one that will help you leverage your existing skill sets to make more money – people who can develop Flash content and apps tend to make more than standard HTML/JS coders.  On the other hand, if you’re a religious developer, and believe that HTML5 will someday do all of the interactive things you’ll want to do, then this news probably doesn’t mean much (though we hope to convert you at some point!).

For those who fall on the practical side, please join us – the community needs your brain and enthusiasm.  We’ve set up the Frontal Open Source Project on Google Code:

http://code.google.com/p/frontal/

If you’re ready to get your hands dirty, just go to our home page and follow the directions to get started:

http://frontalcode.com

And if you need any help, have suggestions, or want to submit bugs, please visit our Forums area:

http://www.frontalcode.com/forums/

We’re psyched to work with you to create the next generation of web design!

If you were about to buy a Frontal license… stop! Frontal is now an open source project. This not only means that you no longer have to pay to use Frontal or be restricted in any way by its license validation scheme, but it also means that your ActionScript developer friends can see and modify the source code! This is a very exciting development for us, and we’ll be discussing it more over the coming weeks. Here is the link to the Frontal open source project and free deployment package downloads on Google Code:

http://code.google.com/p/frontal/

Now we haven’t reflected this change in our main website yet – that will be coming soon. But we didn’t want that work to hold up this announcement. So please, go forth and Frontal. Openly!

Thanks to a few questions posted in our forums, we’ve done some work showing how to integrate with YouTube and Twitter from Frontal. Check out this Twitter feed demo and this YouTube player demo. And don’t forget the Flickr showcase example we did showing an integration with that service. (Type in mbarborak as the Flickr id to see some old photos of mine.)

For more details on the Twitter integration, see this post in the forums.

And for more on the YouTube integration, see this post in the forums.

Integrating with Frontal is really one of its coolest features in my mind. There’s so much you can do and it keeps proving to be an incredibly flexible and open platform. And the integrations are all right there in plain text for you to change and re-use as you need.

We won best demo at the NY Video Meetup last night!  Barborak gave an Oscar-winning performance — showing how Frontal works and presenting some cool video work that some of our customers have done (I’m sure the Victoria’s Secret demo swayed a few voters).

It was our first time presenting the technology, and it really meant a lot to see the enthusiastic response.  If you’ve never attended the NY Video Meetup, I highly recommend it.  It’s a great group run by Yaron Samid, who does an outstanding job of curating each and every event (and he provides decent pizza).

I was also very impressed with the other companies who presented.  Here’s a quick rundown — check them out if you have a moment:

• Speakertext — video transcript development, navigation and search
• Klickable — service that makes it easy to make your video interactive
• PNG Labs — live video feed software for journalists

Yaron, thanks again for including us.  And to everyone who attended last night, thanks very much for your response and support.  We look forward to being in-touch.

The lists of sites built in Frontal is getting longer all the time. (And this doesn’t include the 50 or so sites that were built on the similar technologies that preceded and informed Frontal.) Given that, I thought it would be interesting to share some of our real world experiences with Frontal.

First, I should mention that Frontal has a close friend in the New York-based digital agency BASIK. It is this agency that has embraced Frontal the most and whose experiences I want to discuss.

BASIK is a boutique agency of around 10 people. A typical project will be handled by a project manager, a designer and a developer with the partners stepping in as needed to ensure the highest levels of professionalism and achievement. This is not an unusual arrangement and many agencies fit the same description.

What’s perhaps different about BASIK, though, is their project life cycle. It’s a life cycle in which designers, developers and even project managers contribute at all stages of the project in a very smooth and productive way. The key to this is, what else – this is the Frontal blog, Frontal!

Typically, when a rich-media project is accepted by BASIK, they first sit down and brainstorm the big ideas. These are a small number of points that will really drive the design and implementation of the project. As such, it is very important that the visual aspects of these big ideas be clearly presented to the client as full buy-in is essential. Sometimes this means putting together a storyboard of static images but often it means putting together an interactive piece. In that case, BASIK prefers to turn use Frontal.

The reasons BASIK chooses to do its prototyping in Frontal are first, because it’s easy. In fact it’s so easy that designers often do their prototyping without the help of a developer. And in those cases where a developer is involved, the designer is expected to pitch in. That is, the developer will do the heavy lifting and then the “styling” as BASIK calls it is left up to a designer. So, all those little fine tuning things that designers want but often have trouble communicating to developers, that developers tend not to want to do and that clients swoon when they see them are kept where they should be – in the hands of the designer.

And by the way, you know all those complications of allowing a bunch of people to work on a Flash piece simultaneously? With Frontal, they easily disappear for two reasons: first, 99% of a Frontal project is text-based and any source code control system (BASIK uses CVS) can handle merging changes to text files very well. And second, because the binary assets of the project may easily be broken into multiple SWFs and then loaded for use via Frontal. That is, binary assets become ancillary to the main framework of the site and so it’s easy to partition them to be work on by several people.

The grizzled veteran of the web world is cynically accusing BASIK of not employing pure designers but rather designer/developers – that rare breed of person that can do both design and development. Well, they don’t. And not that they wouldn’t it’s just that those people are elusive to say the least. In fact, at BASIK they call them unicorns because they’re more mythical than real. Nick Law of R/GA puts it on a graph. No, they use pure designers and pure developers. What they’ve found is that Frontal enables designers to do more development than they thought possible and enabled developers to work with style sheets such that their changes come out looking good with little effort.

So after prototyping and selling the big ideas is done, BASIK moves into design mode. Does this mean scrapping all those prototypes and what not? Absolutely not. The reason is that much like selling big ideas, selling designs requires a highlevel of buy-in from the client or else inevitably there will be major changes requested the week or day before the scheduled launch. And for the same reasons that BASIK chooses Frontal for prototyping, it chooses it for presenting certain aspects of design.

And when a design gets sign off and development begins, do they start from scratch then? No again. Those prototypes that made it out of the big idea and design phases became the basis of the production site. Ah, reusability. Music to my ears. And Frontal delivers it. So many interactions and functions get reused from one project phase to the next and one project to the next that often times what needed a developer at one point does not need one at another because the designer knows where to get the code and how to apply it. (It’s most often just copying over some declarations from a style sheet and maybe some markup that goes along with it.)

A great example of reusability with Frontal is the Google Analytics integration that BASIK uses. You simply include the file in your Frontal documents and you’re done! The integration piece is smart enough to track user interactions like changing sections, playing video and clicking on links with no effort from the developer or designer. Sweet.

Of course there will be change requests before a project is completed. Some of the most annoying are those little copy changes that the client needs. They’re annoying because traditionally the project manager has to capture them, enter them into the bug tracking tool, schedule someone to do them, wait for the result to be posted, verify them and so forth. So it’s not that they represent a lot of work in themselves, it’s just that they represent a lot of coordination. But what if the project manager could simply make these small changes themselves? With Frontal it happens. BASIK reports that they let their project managers check project files out of the source code control tool, make minor copy changes and check them back in. And they report that this approach is successful. Why? Because such changes are so simple with Frontal that even if things get botched, they are easily resolved. The overall savings support this approach then.

Now the grizzled Flash developer reading this is saying, “I’ve been using XML data files for years in my Flash work. I do that for just this case.” First, using Frontal is not the same as using XML data files. That’s because Frontal includes markup with content just like HTML. Why is that important? Well, what if that XML file has 10 entries that say “click here?” When I’m looking at the final site, which one maps to the one I want to change? In Frontal, that text will be in the context of the layout and so the editor will be able to figure it out. Also, as grizzled a Flash developer as you may have, in a one-off project they will not spend the time to make their XML data files as generalized as possible. And if they do, then they don’t have their priorities straight and are wasting time. But Frontal was designed from the ground up to solve every design problem and so while it certainly doesn’t achieve that, it does provide a very general solution. (By the way, that’s only clever in that we at Frontal noticed that HTML and JavaScript are effective technologies. It doesn’t take a genius to make that observation.)

So in the end, BASIK is very happy with their process based on the efficiencies and group dynamics that Frontal enables. As importantly, their clients are happy. (BASIK tells me that in one case, their  client began updating their Frontal documents themselves with no training and not even any encouragement!) It seems they’ve found a good way to achieve pixel-perfect designs which any
good designer will tell you is the difference between a good site and a great one. And that way is to keep the whole team involved in the production and not just the aesthetically-challenged developers.

And finally, I saved what I think is one of the most important aspects till last. Many of BASIK’s Frontal-based sites are content managed. How did they do it? They simply used the tools they developed to publish HTML sites. Instead of publishing HTML files, they publish Frontal documents. Now that’s cool.

As a test of Frontal and its abilities, I decided to try out the new Portfolio Site Cookbook Code. I was curious to see just how long it would take me to create a full-fledged portfolio site, from start to finish. Now of course, I’m already familiar with Frontal, so to be completely fair I limited myself to following the steps exactly according to the Cookbook.

The first site, which you can see here, took me about a day (and I mean 8 hours, not 24!). This was my first time using the Cookbook code—which was developed by another one of our team members—and I have to say I was pretty impressed. Not only was the Cookbook easy to follow, but I found that having the process organized in clear steps removed a lot of the annoying leg-work that goes into creating a portfolio site for yourself. I found that, once I had my idea for the design, I didn’t have to even think about typical “build” issues like whether to first define font styles or colors or layout structure. All these decisions had already been made for me, I just had to follow the simple steps. It was like portfolio-by-numbers.

In fact, it was so easy, I made a second one to see how long that would take. The result? About half the time of the first one. Pretty sweet. I’ve posted both of these along with the original site the Cookbook used as a starting point. Feel free to check out the code and customize it for your own projects.

What a crazy summer it’s been. Based on feedback from friends & family over the past couple of months, we’ve built a few things which we hope will be useful to Frontal’s small (but growing!) band of users. Here they are:

Portfolio Site Cookbook Code

One of the most painful things for a designer, graduating ones especially, is to build your portfolio site (gives us the shakes just thinking about it). Which is why we’ve developed step-by-step code & a guide for setting up your own unique online portfolio! We hope you like it. Barborak’s mom is even using it to set up a site for her watercolors.

Bailey-the-Intern Tutorials

Follow our intrepid intern as she learns Frontal, using her newfound knowledge to win admiration from colleagues and respect from clients. These are built for those of us with little or no HTML experience — those of you who were coding in the womb are probably better off checking out our Reference section. (Inspired by O’Reilly’s Head First line of software books, which rock.)

Frontal Intro Videos

For people who’ve just heard of Frontal and want to get a general sense of what it is. The first video gives an overview of the language, the second shows how to use the Workspace. Both can be found on the home page.

And of course, we’ve been continuing to make Frontal better, and to build out documentation (turns out that languages require a lot). We’ll be at this for a while. The good news is that we’re now starting our open user trial, which we’ll be in for the next couple of months. So if you haven’t already, please give Frontal a whirl and let us know what you think. You can get any questions answered in our Forums section, and report any bugs either there, or via the ‘Report a Bug’ links located in the bottom site nav and in the Workspace editor nav.

Looking forward to a rockin’ fall!

How your audience sees your site is important. And by audience, we’re including not just humans, but also the robots sent out by search engines. Because without catering to that second population, it’s unlikely that many from the first will ever find you.

Traditionally, this has been a big problem with rich media sites. The humans see it just fine, but the robots? Not so well. In fact, until recently, they didn’t see Flash movies at all. And now? Well, its better, but still nothing like the way you see them — the robots still have a very hard time understanding the relationships between elements within a Flash movie.

Frontal has changed that. Because Frontal is so similar to HTML, it’s possible for us to generate an almost exact HTML translation. And what does that mean? It means those little robot visitors can now enjoy your site as much as the humans. And that rich media sites created with Frontal can be fully indexed by Google, Yahoo, Bing, etc. So now there’s no need to trade-off between amazing interactive user experiences and search engine optimization.

Here’s an example. That’s a screen-shot of the Frontal site on the left as our human visitors see it today. And on the right is how the robots that Google sends out see it.

Here’s the robot version as an HTML page:

The Frontal Site As Seen Through a Robot’s Eyes

As you can see, the robots get to see pretty much everything you do. (I’m assuming you’re human.)

All of this is done automatically via the Frontal SEO Module (you can also do it manually via the SEO Converter, found in the Frontal Workspace). To see this in action, the easiest way is to go to the home page on the Frontal site, disable JavaScript (check out your browser’s help contents to learn how — it works well with Firefox) and then refresh the page. You’ll see what our robot friends see. (You can do this for other Frontal-rendered pages as well including anything you submit from the online workspace.)

For more information about the SEO Module, check out the Reference section.