A journal that focuses on Flash Platform development, and a little bit about what I am up to on any given day.

Thursday, June 30, 2005

Why have a projector, when you can have an application

Another thought has occured to me, after considering Central and how it will develop into the future. I have never understood why Macromedia has never spent any time on the Flash Projector shell that is published by the Flash IDE.

The projector provides no advantages to authoring other than being able to allow other people to view Flash content without the Flash Player. This puzzles me because it seems like Macromedia could easily take a bite out of the RAD development industry that many had hoped for on the desktop with tools like Visual Basic, Delphi, and these days .NET.

Tools like Director, SWFStudio and Screenweaver(others as well) have allowed this to occur and done a great job doing so. I personally am a fan of SWFStudio and have used it for many big projects at Teknision, but again I do not understand why Macromedia hasnt really got behind this.

Of course much competition exists especially with .NET, but in order for Flash to grow as a Platform, i see this being nescessity. More than that, when I think of Central and changing into more of a shell around RIAs as opposed to an application aggregator, I also think that the same functionality should be exposed in the Flash Projector.

Anyways, as a footnote, I have a pretty good relationship with Tim and the guys at Northcode, so I am not suggesting that Macromedia put them out of business or anything, but rather to take a closer look at what they are doing. When I consider the Flash Platform, a robust and flexible Desktop Application Shell is certianly in the spec in my mind.

My Central Priorities

In response to John Dowdell's post on the future of Central I just wanted to clarify my list for Central.

First off I wrote this a few weeks back, so lets clarify from that:


1/ No Central Brand or shell, Call it Flash Application Player.
2/ Apps should launch by instance.
3/ Allow desktop shortcut icons, as well as System tray icons for Central apps.
4/ No lisencing (kills adoption), there has to be another way for this to make MM money
5/ Window launching containing swf ui's.
6/ API's for other controls eg:Browser, Windows media,etc
7/ Drag and Drop files from desktop
8/ Application Masks, allowing unusual shapes (like Apple Widgets)
9/ System Tray Menu control

In a way what I am looking for is a product like SWFStudio that i can launch and download through the Flash Player like a Central app.

[addition]

I mentioned the SNL Merger Model application that we developed for SNL Financial in the previous post. This application would have seen major benefits, being able to be pulled to the desktop , but the Central enviornment really encumbered it. We would want power users to pull down the application if they so desire, but we would not want that application to come with all of the community features that Central has currently.

We want the ability to store large amounts of data locally, and to perhpas generate PDF, FlashPaper, and Excel documents on the desktop rather than at the server. We do this at the server right now, but it is potentially the most heavy operation of the application. somehow facilitating this being done at the desktop would be a huge advantage for an application like the SNL Merger Model.

Those types of capabilities are what I would like to see in a desktop shell.

Wednesday, June 29, 2005

SVG vs Flash still.

I was in a presentation today on a topic that I haven't heard about much in a little while. The presentation was about SVG Tiny, J2ME and a variety of other emerging standards and technology related to this plaform for mobile content and application development.

We will be experimenting in developing some content on this platform, so as you can imagine (being the Flash advocate I am) that I had many questions to ask, and rose many uncomfortable debates on the Flash player vs SVG in this arena.

Now, many say that SVG and SWF do not really compete, but that is not true in the mobile industry. SVG has much more traction than the Flash Player does currently in most mobile development platforms(according to the presenters).

As a Flash developer, I am actually really excited about getting a chance to play with these different tools, and I am sure our presenters will benefit from the feedback I can give in terms of the experience developing content in contrast to developing content using the Flash Platform.

It seems that there are a few great examples of SVG being used for mobile applications, but from what I can see Flash Lite is also featuring just as many (if not more) great examples already. As the conversation continued we began discussing authoring as one of SVG's main challenges when facing off against Flash. There is a suite of tools I will be using, but I can already tell you that those tools are no where near as fully featured and intuitive as Flash is.

To get a decent application(not animation) off the ground, you have to be familiar with SVG, J2ME, and other APIs that allow them all to talk to each other. This seems to be the biggest issue for developers that I can see. It is cool all of these standard technologies talk to each other, but Flash does it all under one roof. This is definitely something that I see carriers taking into consideration for the specifications they put out to device manufacturers.

It is known that North America doesn't seem to take full advantage of data services over connected devices yet. Obviously the carriers are going to want to ramp that up in the future, and it is really hard to beat a platform that has the development community that Flash has. The major difference is that our designers here could create top notch Flash content for phones, or even Joe Blow that messes around with Flash here and there could easily create Flash Lite content, the same way they do all their other content. SVG does not have that approachability and limits it to developers with specialized skills.

As the conversation came to an end, we really started talking about the future. I put this question to them:

"Now that Macromedia and Adobe are merging, do you think it is likely that the Flash Player could eventually become an SVG player? It already does consume SVG Tiny in Flash lite. And above and beyond that, what if Flash also allows you to export SVG right from the same authoring enviornment? Wouldn't that be a crushing blow to the current SVG compeitors."

This would obviously be a crushing blow, but there is more to the Adobe SVG story here that we discussed that shed a bit of a different light on things.

They surmised that Adobe slowed(stopped) much of it's work on SVG. As the standard started to get around, companies in the print world started to see it as an open-standard(free) alternative for print systems. That would make it a free alternative to PDF which rules that world right now. If that is truly the case, then it makes even more sense why Adobe has turned to Macromedia and Flash rather than go to SVG, because SVG could compromise their cash cow. This was all just talk and guessing. No one can actually confirm this as fact, but it is a good theory.

Anyways, it was a great presentation and conversation, and I am looking forward to blogging about my upcoming venture into content development on the other side.

Tuesday, June 28, 2005

ITunes Podcasting (4.9)

Podcasting

Many of you already know about this, but Apple has released ITunes 4.9. The new version features podcasting. I am really impressed that Apple has embraced this movement, it is really an open oppourtunity for anyone to start publishing content.

I have not delved too deep into it all yet, but I noticed that Apple does allow you to publish your podcast RSS feed through the ITunes music store. I wasn't expecting this, I thought it would be more of a manual process of discovering the feeds yourself on the net and adding them in.

In my mind this is so empowering. A true democratization of broadcasting is happening here. A few of us are already starting to talk about creating podcasts of everything from the Flash Platform, to what kind of trouble we got into on the weekend!

Anyways, my 40 gigs of IPOD space will be filling up alot faster now.

Monday, June 27, 2005

Macromedia Podcast #1

Podcast Link

I really enjoyed this, it was nice to work and listen at the same time. For it to be really useful it would be nice to have them weekly at least, cause most developers that would listen to it are probably already up to date on the topics.

The interview with Mark Anders was good and with all the new stuff on the horizon, I'm sure there will be alot more of these.

On another note,

they discuss the Deep linking or REST concept towards the end of the Podcast. Kevin Lynch, did post about this awhile ago, but the first time I really remember seeing it being used in Flash, was in Robert Penner's early work overcoming the Back Button:

http://www.robertpenner.com/index2.html

In that back button example it doesn't show the deep linking idea on the browser, but the technique in the background was one of the things that led Flash developers to start considering application state and the browser.

I had a few interactions with Penner around that time, just as Flash MX (6) was being released. and i implemented many of those techniques into our now venerable Teknison site. We use anchors rather than query string for state:

http://www.teknision.com/siteVersions/tek2/#Sony%20Walkman

that for example takes you directly to a specific section of our site. It is not only useful for deep linking, but bleeds over into bookmarking. That is more the reason we implemented it.


All and all though, thumbs up on the podcasts!

Friday, June 24, 2005

Flash Player, A Trojan Horse

I was just going over these articles today on the MXNA:

http://www.pbs.org/cringely/pulpit/pulpit20050623.html

http://www.flashinsider.com/2005/06/24/i-cringlely-looks-at-the-future-of-flash/

which talks about the usual great advantages of owning the Flash Player, and John Dowdell's response:

http://www.markme.com/jd/archives/007956.cfm

Now in a way I would have to say that the first article is not as far off as it may seem. The Flash Player actually is a serious Trojan Horse and that can be leveraged in a big way in the future.

John states that it is Flash Player features that make it great and that is true, but there is a hidden little ability in the Flash Player since Flash Player 6 that not alot of people know about. That feature is:

var foo = new System.Product("AdobeVoipClient");
foo.download();

This feature is used to pull in Macromedia Central, Central Applications, and The Macromedia Breeze Player to the desktop. This feature is potentially a "Trojan Horse" if you will.

The original Blogger's argument actually has more legs to stand on than it seems. I am sure Acrobat and other technologies can easily pull down other applications or content, but the Flash Player is different.

Being a web player with a massive install base it means that applications can easily be pulled down, with little or no interuption and annoyance to the end user. Getting that content is as easy as having the code above execute in a swf file. The Flash Player also has an auto-update mechanism that is beautifully designed. Very unintrusive. These in combination create a recipie for instant ubiquity if the owners of the Flash Player were to leverage it for this purpose.

I would seem to think that Adobe would be interested in this. For example, it is likely that Acrobat could be pulled in through this mechanism in the future, or potentially any other web player that adobe comes up with.

Think of Adobe Atmosphere. What better way to get a brand new web player out, than proxying it's launch through the Flash Player. The Flash Player could recieve the call for content, download the needed player and run the content. Anytime after that the Flash Player could again, recieve the request and launch the content direct.

So in final, many people are not aware of this Flash Player feature, and Trojan Horse it actually is.

Thursday, June 23, 2005

New FLV DRM????

I just did a little search trying to find any information on DRM in FLV And came across this little past discussion.

I have personally come across a few scenarios where DRM will be critical to roll out a project, and I am looking for any recsources I can to determine how to manage this in FLV. Obviously, I will not be able to determine the future until Flash 8 is released, and we can see if it has been addressed.

The point though is that it must be addressed. Flashcom is a great way to deliver video, but it is not the solution to every problem. FLV files must have this support in lieu of the flash player 7 ability to play an FLV file as a progressive download.

I have already come across one showstopper scenario, if I cannot facilitate DRM in FLV.

FLfile.write()"`\n" stripped

It seems to me that the traditional "\n" does not work with the FLfile.write method properly.

I was working on a little extension, and I would be passing String data up from a SWF using MMExecute(). IN JSFL, when i did a few alert or traces to check the string, eveything seemed fine, but when written to disk, all line breaks were removed.

For this extenion it was crucial that I have the line breaks, so I had to keep trying to figure out the issue. I determined that 100% FLFile was stripping them out. If i write the string to a file using the fl.ouputPanel.save(), they were in there.

So at the end of the day I just ended up doing a character code output and comparing the edifference between a file that was properly written vs one that was stripped. The difference was the missing char 10.

So instead of using newline(in AS) or \n in my string generation, I used this instead String.fromCharCode(13,10). Pretty simple, but it is annoying when documented examples of using this functionality fail, making you search through your own code trying to find the issue. A note should be made in the official documentation for FLfile.write().

Monday, June 20, 2005

Compile-time Shared Libraries

I have spent alot of time over the last while trying to determine the most efficient ways for developers and designers to collaborate on larger Flash projects, but I always find myself frustrated trying to enforce rules in how things should be built between teams.

Developers have a much easier time working together, our team uses VSS and we can easily share and collaborate on code and projects with no overlap or conflicts.

Whenever I try to bring designers into the process though things always seem to get complicated in the Flash IDE. There are many scenarios where breaking up content across SWF files makes sense, but there are many times that it does not make sense.

I spent time examining Shared Libraries recently, a concept that we hadn't really utilized, and I again realized why:

Runtime Shared Libraries: why must you define an absolute url on the shared assets? I never understood why this is needed. It freaks me out to think that I would have to forsee this url (when often I do not know it in advance). If I have missed something here please leave me a note in the comments.

Compiletime Shared Libraries: When a shared asset is linked, it is frustrating that any children of that symbol are just plopped into the destination file with no consideration of how those assets were organized in the source file. This really annoys me, because the reason I would use shared libraries in the first place is to ensure clean structuring of assets without excess tidying up.

So again I am looking for suggestions on how others out there working in a design/development enviornment may deal with this in an effective manner? Hopefully 8Ball may allieviate some of these issues. But in the meantime feel free to leave comments.

Fullscreen FLV

I don't know how many of you have encountered this, but in recent past I have had many flash projects in which the client has requested fullscreen video. Many clients speak of the ability of Quicktime and Windows Media Video to natively go fullscreen from the web players.

Even though this is very possible to do using javascript, and a popup window, I long for the Flash Player be able to do the same thing natively.

This would be useful for FLV video, especially with the announced improvements to FLV in Maelstrom, so I remain hopeful that potentially Macromedia could facilitate this in some way that could not be abused.

Another Debug/Trace Class

This topic has been discussed many times in the Blog world, but I just wanted to contribute my new approach to debugging complex Flash Applications.

After working on the SNL Merger Model application for 8 months, I realized I needed a more robust method for tracing and debugging. The application was huge, and it was all developed in Flash not Flex. Compile times could often surpass 2 minutes, and that made it really frustrating when debugging small glitches.

More than that, if you are a fan of using trace statements, many of you know that as an application grows, it can become unweildly to manage them unless you keep them in context with the process that creates them.

So at the end of the day, I wanted to force myself to behave as a developer, and do the right thing. I designed a simple little class that we use frequently to debug our work at Teknision.

Suprisingly I called it:

com.teknision.debug.TraceManager;

but in it's simplicity it is very useful. The point of it was just to get our whole team thinking on the same wavelength so that when we hand work to each other, we can easily pick up on certain parts without having to study the whole project.

Here is how we use it in Actionscript:

trace(TraceManager.get().getThread("Application").getThread("init").getThread("loadConfig").trace("config file loaded"));

the output from this in the trace window is the following:


201:Application.init.loadConfig{ config file loaded}


The first part is the timer count in which the line executed, and the rest is a path that puts the trace statement in context to your work. Note that using this alot in an application will add processor overhead, but in most ways it is really worth it.

Note that the whole statement is held within the trace() function. This may be a technique used by many, but it is a way to make sure that you can easily eliminate this logic when you deploy production work. The fact that it is all executed in the trace() statement eliminates it on compile if "Omit Trace Actions" is turned on.

As we started using this, I have found that our team has begun to think more alike, and work is easier than ever to pass around. We even built a desktop app to recieve the traces remotely and allow threads to be filtered. This makes focusing on certain pieces of a system very easy.

[update]: thanks Stace

Truly one of the best things about it, is that it exposes application bootstrapping. At a glance I can see the log of everything my application is doing as it runs. Debugging using it is great, but also, another developer can really get on board much faster when observing this output.

Repositioning Macromedia Central

Yesterday I had read this article on Macromedia Central development and whether or not it is worth it. It made me consider some of the experiences I have had as a Flash Developer since Central has been available to develop for. I am a fan of Central, and I do believe it is something that users would benefit from, but something is wrong.

Many times I have presented Central to clients we have developed RIA's for and each time I met resistance. The RIA's for those clients were often prime candidates for the technology, but clients would rarely even express interest as it as an option. As a result, I have compiled a list of a few things that I think would really help Central succeed:


1/Destroy the Central Identity.

Central's biggest flaw is that it is another piece of software with a visible brand. Clients do not like the idea of downloading yet another application to interface with their content or applications. However, I do not really believe that it is the enviornment they are scared of, it is the fact that it is yet another enviornment with another name. "We are building a Flash app, why do we need Central?"

When we were developing the SNL Merger Model, this seemed to be a major issue. The client was unwilling to introduce yet another name and brand into the mix when deploying their application, even though the application would see huge benefits in the Central enviornment. The developers there though had worked with the .NET framework in the past to deploy applications, and were totally prepared to deal with an enviornment outside of the browser, but Central was not a sell because of it's visible branding.

They were amazed at how it downloaded through the Flash Player though, and realized that it was alot more efficient than a .NET deployment, but the branding was a show stopper.

So the solution to this issue in my mind is to destroy the Central brand. Instead, give the perception that what is now Central, will be just an extension of the Flash Player itself. Perhaps call it the 'Flash Application Player' (that is dumb, but up that alley), just as long as it looks like an extension of the Flash Player itself.

With this change developers and clients will be much more open to the concept.


2/Application Cross Communication is not relevant actually undesired.

Many of our clients were actully turned off Central, when they saw that it had to behave with other applications. Blasting data is a truly innovative feature but clients immediately get worried. First off, if a compeitor's application has the ability to consume your data, that is a show stopper. This feature does make sense but only in the context of a suite of applications.

Seems selfish but it is true. Our bigger enterprise clients are not in the business of allowing their compeitors to leverage their tools, so even though this is cool, in the real world it does not seem to sell.

Where Central can improve in this area, is to again destroy the idea that everyone's application should play on the same field at the same time. Instead they should focus on applications launching by instance rather than all together under one roof.


3/ Give me a framework, do not give me a template

Central's concept of an Application, Agent, Pod, Notifications are pretty cool, but they force you into developing an application that is only semi useful. Each element, especially agents, are useful, but all together force a template mentality that does not benefit the bottom line. By this I mean, my clients do not want to develop a Central application for Macromedia, they want Macromedia to provide them with better tools to develop their application.

There are times where I would love to launch another window, but that window definitely has no business being a Pod. Agents seem useful but they can be more of a hinderance than anything else. Using SWFStudio for example I can create an application that has the application window, but also can be running in the system tray if minimized or closed. This would be preferable to managing handoffs between Flash Player instances for the different components of a Central App.

So again the solution here, is to realize that there is a demand for Flash Applications with increased access to the desktop, but the demand for a preconcieved application framework is not there. Macromedia made a mistake with Central in guessing that the end-user would like to behave within the template framework they had layed out for Central. The truth is that most large application providers that would create the killer apps for Central, do not see that framework as one that caters to their application. So in other words, there is not enough flexibility in that framework.


4/ Take on the Competition

It is unfortunate that Macromedia is being forced into direct compeition with Microsoft here, but hopefully they will rework Central to join the battle. I have seen some amazing things done with Smart Client technology on the .NET platform. Things up the alley of web applications interfacing with Excel and Word exchanging data directly.

It seems that large enterprises select a platform and try to implement it accros the board, and as Microsoft starts rolling out more and more Smart Client technology, the Flash Platform is going to have a hard time nudging out that level of compeition.

Microsoft is really focused on making business more efficient with their future RIA strategy under .NET. I though, have always sang in the Flash choir, and I want to see them focus on similar objectives. Flash is growing into a very signifigant platform. It has advantages like total ubiquity, and mind blowing small file sizes, but it will not win the future RIA battle that is coming unless the bridge to the desktop is brought to the forefront. Regardless of how much we all want to get away from the desktop, the true power of future RIA's lie in embracing it.

5/Liscencing.........

This has been a major issue since the start. I think it should be irradicated totally. Above I mention that Central should really just be an extension of the Flash Player, or at least appear that way. That empowers the Flash Platform and provides more incentive to adopt it in arenas where Smart Clients will dominate. The platform must be as powerful as possible, and liscensing the runtime will kill adoption, and therefore kill the concept.

Make money on the tools for development and content creation, the runtime is the incentive to adopt those tools. On this one, I am not speaking from my perspective, I am speaking from the view of an outsider that would have deployed an application on Central without those constraints.


Conclusion

Maybe the issue with Central has been it's target audience. I feel that it should have been designed to empower enterprise rather than developers and everyday internet users. The enterprise-level needs the heavy lifting of the desktop shell, but at the same time needs total control of the enviornment.

Perhaps the current Central concept is to far ahead of it's time.


Looking Forward

Now that Adobe and Macromedia are merging, I can't help but think of the fact that huge possibility lies in the idea of Central. The application Macromedia Central itself should be discontinued though. The reason for this,

No enterprise in need of high level RIA's will turn away from the idea of using one of their most familiar tools to run RIAs that bridge to the desktop.........

Welcome to Adobe Acrobat, your hopeful Macromedia Central of the future.

It would be interesting to see Acrobat evolve into something that blurs the gap between document and application. It could potentially change software methodologies totally, by reversing roles. Consider the idea of dragging an application on to data or content, rather than the idea of dragging a document onto an application.

You are working on a presentation, and when you are done you drag and drop a video conference right onto it and get started.

This would be a radical evolution for both PDF and Flash, but at the end of the day, you would be looking at a platform that could truly change the way that people interact with digital content.

On the Blog Scene

So after all this time I finally have got a blog started. I could have very easily just have used this Blogger acount awhile ago, but I was convinced that I would get one going on our Teknision server. But never got around to it, so for now I am going to join in the fun here.

After viewing everyone's Blog over the last few years I have contributed a ton of comments across the Flash Community, and I am hoping that I can turn this spot into a place where i can flap off my mouth, and maybe get some conversation started.

I'll get one of our design guys to skin me up over the next couple days.

So let's get going!