Strategic Consulting

Adobe has recently released some new versions of Adobe Media Server. However, if you discussed them or noticed that they’ve been released you may be encountering confusion around the versions 5.0.4 and 5.0.5.

Adobe Media Server – Version 5.0.4

AMS 5.0.4 runs in the cloud on Amazon Web Services. Here’s a list of the AMIs and a link to the help documentation. (Note: The documentation still says 5.0.3 and the AWS product page still says 5.03)

Adobe Media Server – Version 5.0.5

AMS 5.0.5 is a maintenance update released on 3/31/14 to address product issues and is the on-premise version of AMS. You can download the updater from the AMS/FMS Updaters Index. Feel free to take a look at the issue fix list in the release notes to see if this update applies to your situation. (Note: There is no 5.0.5 branded documentation as far as we know, so for now you can reference the AMS 5.0.3 documentation.)

So there you have it, a breakdown on the current AMS 5.x versions and some helpful links to curb the confusion. Enjoy!

I was recently asked how the Varnish Plus cache interacts with the objects created to support HTTP Dynamic Streaming (HDS) via a backend origin Apache/Adobe Media Server.

This was a valid question, especially when you think of how HDS delivery works. In a nutshell, HDS delivery consists of a manifest(s) file and then a large number of HDS fragment files. Due to the number of files involved in streaming just one video it’s important to have a basic understanding of how an edge cache works.

Here’s some quick tips to keep in mind when using Varnish Plus with Apache/AMS:

1.  Varnish Plus uses an object time to live (ttl) to determine expiration and then a least recently used (lru) algorithm to decide what to boot when the cache is full and the remaining objects haven’t yet expired. Here’s some more details.

2. When monitoring your Varnish Plus server, you can keep an eye on how often things are being purged with the varnishstat command’s  n_lru_nuked field. Monitoring this counter will allow you to know when the size of your cache needs to be increased.

3. When sizing your Varnish Plus cache, you need to keep in mind that Varnish Plus has a tracking overhead of about 1k per object. This means that for any video you need to factor in the overhead. Take for instance, a 5 minute video being streamed via HDS. With a default Apache/AMS configuration streaming that 5 minute video will require an F4M manifest file and then 75 fragment files. (The AMS/Apache default fragment size is 4 seconds) So for that video there will be about 76k of overhead.

Using the tips above, you should be able to calculate the size of cache you need and keep an eye on it as well. However, if you find yourself in need of any Varnish Plus or Apache/AMS consulting, feel free to reach out to us!

We’ve been assisting a client with implementing a secure HTTP streaming Enterprise Content Delivery Network (eCDN). We utilize Adobe Media Servers (AMS) with the bundled Apache server to stream via HTTP using the Protected HTTP Dynamic Streaming protocol (PHDS) and Protected SWF Verification from behind a hardware load balancer at the origin. In addition, end clients are accessing the streams via Varnish caching servers via reverse proxy.

During our testing with the client we ran into an issue where the Varnish servers were returning PHDS fragments that resulted in unsuccessful video playback. (Black screen) We worked with the client to troubleshoot the issue and determined that it happened when the origin load balancer would hop traffic from one of the backend AMS/Apache servers to another AMS/Apache server. The weird thing was, when using the dev tools in Chrome we could see that the client was receiving the PHDS fragments successfully. (Chrome dev tools was showing HTTP 200 status codes for the fragments)

The 200 status codes made us suspect that something was going on with PHDS so we turned off PHDS and tested with unprotected HDS. With standard HDS the players were playing back content successfully even with origin server hopping.

Here’s where the quick tip comes into play. When using PHDS, there is a file that is used to derive the Content Encryption Key used by AMS to DRM protect the HDS fragments served via PHDS. This file is created by the AMS Installer and so it will differ from one install to the next. It’s called common-key.bin and is located in {AMS_INSTALL_ROOT}/creds

PHDS Info in AMS 5.0.3 Docs

Quick Tip: In the case of PHDS with multiple AMS/Apache servers clustered at the origin, you need to make sure that all of them have the same common-key.bin file. Otherwise fragments from each server will be protected with different Content Encryption Keys and video playback will fail on the first server hop.

In closing, as soon as we synced up the common-key.bin files on each of the AMS/Apache servers and cleared caches, the eCDN was back in business and the video players were happy as clams.

Part 2: 2014 RealEyes Speaks!

Posted on February 12, 2014 at 1:04 pm in Strategic Consulting

In January we listed out the first three places we’re scheduled to talk in 2014. Today we’re glad to announce that we’ve been invited to speak at the premiere conference for managing the configuration and deployment of your infrastructure and applications:

ChefConf 2014

On Thursday, April 17th at 2:35PM Pacific, our own Jun Heider will be giving a lightning talk about how to utilize Expect to script interactive installers such as Adobe Media Server.

Title - Automation: What to expect When Expecting Your Interactive Installers

Description - Chef is an excellent platform for automating the deployment and configuration of your infrastructure. However, there will be times when some annoying interactive installer will throw a monkey wrench into the works. Try in vain to make it play nice and there’s not one command line argument that can make it run in an unattended fashion.

Enter expect.

As defined by the manpage expect is a “programmed dialogue with interactive programs”. During this session you will learn how to leverage expect in your Chef recipes to automate the un-automatable through working example and walkthrough. By the end of the session you will have the knowledge and samples needed to get your feet wet with expect to automate your interactive installers.

Register now with an early bird discount – expiring 2/28 – to see what Jun and the rest of the Chef community has to offer at a $300 discount!

Wowza is at it again, folks. But this time they’re teaming up with Microsoft to bring content protection to the next level and reach even more users than they already do. But in this case, they’re using MPEG-DASH (Dynamic Adaptive Streaming over HTTP) for live broadcast streaming delivery with Common Encryption. This is a big plus in the streaming media world and a big win for Wowza and its customers.

Why is this so important? Because it’s shaping the next level of delivery standards for both live and on-demand content.

When I am discussing use case(s) with customers, content protection (also referred to as DRM) is brought up about 95% of the time.

Way back when the Internet was in its infant stages (remember Prodigy?!). And I will admit that I wasn’t very familiar with DRM (or any other three letter acronyms; aka TLA’s for that matter) until about eight years ago.  I knew about the emergence of file sharing networks such as Kazaa, LimeWire, and eDonkey2000, but that’s about as far as it went. Oh, and who could forget Metallica’s lawsuit against Napster?

So here we are now, and the immediate need for content protection seems to be at an all-time high. Why is that? YouTube doesn’t need to leverage any encryption on their content, right? Their motto is ‘Broadcast Yourself.’ Well, not so fast. Have you ever wondered what kind of rights you’re potentially surrendering if you upload a video that you recorded of your kid smacking a baseball into your nether regions to publicly available sites like YouTube? You did take the video – and the shot to the groin – so it’s safe to say that it’s your intellectual property. However, my father always taught me to think before I speak and to consider the consequences before I take action, and that’s how I approach life. So even with something like uploading a video to YouTube, I might want to take a gander at the digital rights management that applies on YouTube.

In the last few years, I guess have become a little obsessed with DRM schemes and technologies, the reason being because documentation was few and far between in terms of availability. But, since online delivery of content is at an all-time high and definitely not going away any time soon, knowing how the content I upload and put online is going to be protected is paramount.

When an entire digital business model revolves around on-demand content being at your fingertips, it isn’t that simple.  The gang at Netflix has managed to garner an exponentially higher customer base due to their reach with an online distribution business model. With that said, the majority of the content that they’re distributing is not proprietary, so they apply an industry-approved DRM technology to the content to ensure protection. And it works.

One thing I’ve learned in my researching DRM is that it truly isn’t just about applying protection. It’s about protecting your intellectual, proprietary property.

I had the pleasure of speaking to Danielle Grivalsky at a couple of weeks ago about DRM, and she directed me to their descriptions of the available DRM technologies, and I must say that they nailed it.

Don’t hesitate to contact us to find out more about how leveraging Wowza and MPEG-DASH can work for you!

Captivate vs. Presenter: Which one to choose

When should I use Presenter and when should I use Captivate?

That is a great question. But, the answer isn’t very clear. However there are some clear differences between the tools that we can use to isolate the best use case, and hopefully get building projects, instead of scratching your head.

Adobe Captivate versus Adobe Presenter: The Ultimate Showdown


Let’s start with Presenter, it is a simpler tool.

What is Adobe Presenter?

It is a plug-in to PowerPoint (2003-2010) that allows you to and add audio, video, flash and quiz functionality to a Power Point presentation. It will then output the presentation to a web-ready format to be delivered delivered with Adobe Connect or a web server. There are also additional output format – a PDF file, which displays the interactive portion in a single page PDF.

OK, great Captivate can do that too right? Yes and no.

Captivate can add audio, video, flash and quiz functionality to a Power Point, but some control and quality is lost.. Because Presenter is a plugin and work inside of PowerPoint, you can maintain control of the slides and changes, update and modifications are simple. Updates in captivate are a little more involved.

Presenter Point #1 : If your content is in PowerPoint, or can be easily created in PowerPoint, then use Presenter.

Think simple, don’t over-complicate the process. If the above statement applies to your eLearning project, then stick with Presenter, no if’s, and’s or but’s about it.

Presenter Point #2: Use simplicity to your advantage.

You can build text and image based presentations in Captivate, and I know groups that have walked away from PPT/Presenter to use Captivate exclusively so they only deal with one software application, but, honestly, it is easier in PPT and Presenter. Simplicity is Presenter’s main attraction to me.


Captivate is a wonderful and powerful tool for producing eLearning content. Captivate is a screen/workflow capture application that allows you to create interactive or non-interactive eLearning projects. This is where people can get themselves in trouble. Captivate can tempt users down a road of over-complication and update-nightmares. To simplify the concept - Captivate’s bread and butter functionality is the workflow capture.

Captivate Point #1: Do you need to show or simulate software? Yes? Use Captivate.

Sure, you could do it in PPT and Presenter. Think about all the screen shots and text you’d have to write and arrange. What could take you days in Presenter/PPT will take a few minutes in Captivate.

Captivate Point #2: Looking for more advanced animations, widgets, or branched scenarios? Use Captivate.

If you are looking for more robust animations, better video support, the ability to use widgets, or any of the many additional features that Captivate offers, don’t fight with Presenter, use Captivate.

Now, Presenter vs. Captivate isn’t the best way to think about these two tools. Using the tools together can enhance your eLearning content and make your life easier. Use both tools to save time, and create some top-notch content.

Are you interested in learning more? Do you need help creating content with these tools?

We provide expert training for both Presenter and Captivate or we can create your content for you. Contact Us for more info.

Customer Support: Is it a Lost Art?

Posted on March 30, 2012 at 2:22 pm in Blog, Strategic Consulting

Customer Support: Is it a Lost Art?

In today’s economy, it seems that many organizations have sacrificed customer service as a way to reduce their overhead. Many groups now use overseas support and may not have any actual staff to help with customer issues. Proudly, we have kept our customer-centric focus here at RealEyes Media.

What has this meant for us and our customers? It means that our clients have purchased from us with the confidence that they are getting the right tools the first time. They also have access to our team of experts who use the tools we sell.  Finally, they have access to our certified trainers for official Adobe Authorized training, or custom application development and training as needed.

How does this make your experience better? Think about the last time you purchased software from a company that sells every software application you could want (SHI, CDW, BestBuy, etc.).

How much did your sales rep know about the software you were purchasing? More than what was on the back of the box?

Did you ever try calling them back with a question about using the software? I would guess that you didn’t find much help. This is just the tip of the iceberg of how customer support can make a better experience for purchasing and using software.

Why are the benefits of using a company focused on the software you’re interested in? Companies that focus on specific products are going to be better suited to assess whether the tools are right for you, and what licensing will best suit your specific needs. They can then help you assess and track your usage and help identify where you can make things more efficient or where you can expand to grow your business, not to mention help with adoption of new tools or versions.

Keep this in mind as your organization looks at purchasing software. It is worth the extra effort. You get better support, and someone else “in your corner”.

All of us here at RealEyes are 100% committed to our client’s success and growth with the tools and services we provide, and we look forward to working with all our clients, new and old.

Ready to Put RealEyes inYour Corner?

Case Study: Listen to the problem & provide the best solution

The other day a call came in from from a customer who had questions about Adobe Flash Media Server and if it would be the right software for their situation. After listening to their questions and exactly what their requirements were, I moved on from there.

As a product specialists, solutions engineers, developers, and trainers, the team here wear multiple hats. So in this case, I put on my solutions engineer hat, and began assessing their needs case.

Their initial inquiry was about streaming Flash based content within their Intranet. The customer was searching for a way to package internal asset videos and SCORM based training content together into one piece that could be uploaded to their proprietary Learning Management System (LMS). He had mentioned that they also had full motion videos, and that they too would like to be able to bring those recordings into the training piece.  He asked about Adobe Captivate initially.

Seems easy enough, right? Give them Captivate.

Not so fast.

This Flash based content was quite complex and not as efficient as it could be. I recognized this as something I could use to minimize the clutter, and streamline the content from start to finish. The quick and easy route to a solution would have been to use Captivate and a couple other software applications. This would have worked, but it wasn’t the best solution. I’m a firm believer that less is more when it comes to software applications. The goal was to make it easier for end users to navigate and comprehend, as well as easier to manage for the content creators.

The solution actually turned out to be pretty simple – I had gathered all of the necessary information, the keywords of SCORM and LMS were a big help, from him and I decided that Adobe Presenter would be a better solution because of its simplicity. LIke any good customer, he questioned the solution & I explained it this way:

  1. Presenter has the ability to import the internal asset videos (already in .flv format).
  2. The full motion videos were already in .swf format, and Adobe Presenter can import those, as well.
  3. Presenter is a SCORM compliant eLearning content authoring tool, so you can leverage its quiz functionality to build the quiz, as well as deploy it to any LMS that utilizes SCORM as its reporting engine.

In the end, this was the solution that the customer ended up using. He appreciated the simplicity factor. And since he had really only been tasked with this project as a result of an employee leaving the company the simplicity was important to him since this wasn’t his primary role. A big win for the customer.

The point of this post is to emphasize just how important it really is to listen to all of the requirements before making any judgments and beginning to endeavor down that solution’s path. There are always multiple solutions to a problem. We help to determine the best solution.

The team at RealEyes excels at proposing the best solution for the situation. We take great pride in being an Adobe Solution Partner and Adobe Certified Instructors.

Looking for a solution to a problem? Contact Us!

5 Tips For Getting More From Your Training

Posted on November 22, 2011 at 2:36 pm in Strategic Consulting, Training

5 Tips For Getting More From Your Training

Ever sit through 8, 10 or more hours of training and come out feeling like it was a big waste of time? Regardless of the instructor and class content, there are some things that you can do to improve and benefit from any training that you attend.

The following 5 tips are based on observations that I, as both a trainee and trainer, have found to improve the experience and overall learning retention achieved from training sessions. These benefits apply to both short, 1-2 hour sessions, as well as longer, 3-5 day sessions. So take note and see if these improve your next training experience.

Make sure the training uses labs for practical experience

Your training is for more than just passing an exam, right? If you want to learn how to do your job well, make sure whatever training you invest in provides real experience performing tasks with hardware, operating systems, and networking. Even better, find training that combines this hands-on experience with practice exams, expert video instruction, and written reference material for a complete training package. There’s more than one way to learn, so be sure to incorporate different methods in your training. Each method will build on the others and reinforce what you’re learning.

Don’t limit yourself to the prescribed steps

This doesn’t mean that you shouldn’t go through the steps. Go through them, and then after that, add in your own changes ideas and tests. This will give you a better and deeper understanding of the concept.

Make sure you get the fundamentals

Before you venture out on your own, away from access to an instructor, make sure you understand the main processes and concepts. That way when you are on your own, you will be able to more quickly resolve issues and problems without having to “start from scratch”.

Ask questions

Make sure you are getting the training you want and need. Let the instructor know when you have specific questions or when you’d like to discuss something further. Instructors love to help. Lead them to where they can help you the most.

Create context

If the content doesn’t relate to what you are currently working on or something you have worked on in the past, it will more difficult to retain. Look for ways to relate the training material back to you. Email yourself ideas, code snippets and thoughts as reminders.

Don’t stop after the training is over

Make sure you review and use the materials and information you were provided. The more you use and review, the more benefit you will gain.

Excited about your next training session now? We thought you might be.

Check out the training that RealEyes offers. Or, you can contact us directly about custom training and consulting for your specific needs.

The past week has brought a series of announcements from Adobe that has elicited myriad speculation and concern from the Flash Platform and Adobe community.  As a leading Adobe Solutions provider for Flash Platform solutions, RealEyes wants to address these announcements and how we see their impacting our focus in the technological ecosystem.

Before we begin this analysis, from our vantage point, the largest issue with these announcements is the way in which they were communicated—to the public, to partners, everyone.  There was much good news in what Adobe announced; unfortunately, their public relations team chose to focus largely on what was being deprecated, which colored the resulting dialog.

We’d like to take a moment to refocus this conversation for our customers and community.  Contrary to popular debate, Flash is NOT dead.  And here’s why:

Adobe Focus on Mobile Applications

Adobe announced that it would be more aggressively contributing to HTML5, with future Flash Platform development to focus on personal computer and mobile applications.  Great!  Our clients who are developing mobile experiences are universally doing so with the intention of making installable applications.  More Adobe focus in this area will only enhance the experiences that we are able to work with them to deliver.

The Flash Platform is still the best way to develop mobile application experiences intended to be deployed across the major application marketplaces: Apple, Android, and Blackberry.

However, what got the most attention in this announcement was that Adobe is discontinuing development of Flash Player for the mobile browser.  While this got many people up in arms, declaring the general demise of the Flash Player, we at RealEyes can respect this decision and see the validity of it.  For Adobe, the return on investment for this runtime simply wasn’t there, and with the fragmented nature of Android (and a few other issues that contribute to delivering an application to all browser, OS, and mobile hardware configurations) the continued development of the mobile Flash Player would be exponentially complex.

For application developers, the mobile Flash Player was never as good a runtime as the desktop one.

So, how is the discontinuation of mobile Flash Player affecting our clients? Really, it isn’t.

Because mobile device users are more likely to look exclusively toward installable applications for rich media content—and RealEyes’ Flash Platform applications largely deliver rich media content—our customers have been developing applications built using the Flash Platform and relying less on the mobile web.  Mike Chambers does a nice job of discussing the differences in how users consume rich content on mobile devices compared to the desktop, and we agree wholeheartedly that this is the way to go.

Because Flash Player doesn’t have the same ubiquity on mobile devices as it does for desktop browsers RealEyes was already advising our clients to create fallback experiences for their Flash content for mobile browsers.  For most of them we could achieve the same functionality in HTML as in Flash (video being the exception as you’ll see below).  Why not forgo Flash entirely and have a single HTML codebase to support?  Seems like a decision that makes good business sense.

Not that we aren’t sad to see mobile Flash Player go: we are.

If only because we don’t want the web to have missing plugin alerts. Having the Flash Player plugin available to Android and Blackberry mobile browsers was a convenience that offered a great marketing pitch, but, truthfully, delivered very little.  This is due, in large part, to the fact that the majority of the web was design for the desktop and was not meant for (nor is it very functional for) mobile phones – period, full stop.

In truth, we’ve seen just a very few Flash applications developed specifically for the mobile browser.  We at RealEyes have developed just one of these for commercial release. And this application was built before AIR for Android and was always intended to be a stop-gap until this runtime was available.

Now, tablets make a better use case for Flash’s place in the mobile ecosystem; however, the number of tablets that support Flash is under 30% of market share.  Given this and Apple’s seemingly prohibition on Flash, the Flash Player was just never going to achieve the same ubiquity as it has on the desktop for tablets, or for mobile phones for that matter.

Adobe Supports HTML5 Development

As Adobe is a multimedia creation company it will want to be at the forefront of whatever technology is defining exceptional user experiences for multimedia delivery.  And, for a few years now, Adobe’s been looking toward HTML5.  Unfortunately, the announcement from Adobe that contains the information about the discontinuation of the mobile Flash Player makes it sound like Adobe’s just jumping on HTML as a development platform.  That’s just not true.

Even more unfortunate in the present debate is a perception that Steve Job’s thoughts on Flash have somehow won and that this was just fallout from an Apple v. Adobe war.  Not so fast.  Apple and, to some degree Microsoft, have done much to market HTML5 development to the point that its perception overpromises what it can deliver.  Although Adobe has been working to educate its community about the benefits of the Flash Player over HTML5 and was backed by legions of developers, animators, designers, and content creators, they couldn’t overcome the tactics of a such powerful and cunning marketing machines.  While standing its ground on the mobile Flash Player, Adobe was, in many ways, able to achieve what critics said was not possible with Flash Player on mobile devices.

So, if Steve didn’t win, who did?

Well, Adobe is still poised to win and … more importantly so is its community of developers and customers.  Look at tools like Adobe Edge and the new mobile enhancements to Dreamweaver.  Also, with Adobe’s acquisition of PhoneGap, Adobe developers are poised to deliver the best HTML5 experiences out there.  Yeah, it’s not Flash … but that’s OK. While it seems like Adobe’s making a sharp turn toward HTML5, from where we sit, they are more fully committing to a direction that Macromedia, and then Adobe, started in some time ago.  Remember the HTML and Flash being friends video from Adobe MAX last year?

And, with other recent innovations for mobile AIR such as the availability of native extensions, the future of mobile development is exhilarating for any Flash Platform developer.  We’re hopeful that Adobe will use this opportunity to sharpen their focus on native mobile functionality and continue the path of making the Flash Platform the best choice for developing multi-platform mobile applications with a single code base.

However, the perception that Adobe’s making a rash decision is very damaging and something that we’re working with our clients to help them understand.  The reality of the situation is that not much has changed; however, poor communication, horrible messaging, and virtually no community outreach from Adobe regarding this messaging has made the perception the accepted reality in the short term.

And, if that weren’t enough news for one week …

Adobe Really Open Sources Flex

In clarifying its future plans for the Flex SDK, Adobe announced that the Flex SDK will be contributed to an open source foundation.  The good news in this move is that the Flex community is mature enough to take on the governance of this robust framework moving forward.  This wasn’t the case in February of 2008 when Adobe released Flex 3 as open source (Adobe had been planning to open source it since April of 2007).

For several years now, Adobe has been moving towards a more open standard with their development and this decision to contribute the Flex SDK to an open source foundation isn’t something that’s Adobe has done in isolation, and not just to the Flash Platform.  Some other projects that are on this path are:

  • PhoneGap
  • BlazeDS
  • Flex SDK

And, in reading Adobe’s clarification to this open source announcement, we see even more reason to be excited.  They are also open sourcing tools that support Flex including an experimental one (Falcon JS) that cross-compiles MXML and ActionScript to HTML and JavaScript.  Now, that’s exciting!  And, we’re sure that more is on the horizon.  Maybe HTML and Flash can be friends after all.

And, let’s be honest, the original model that Adobe used to open source Flex didn’t go as planned.  While Adobe always said they welcomed contributions from the community to grow and improve the Flex SDK, the process for getting a change accepted was unclear and many community contributions were rejected for any number of reasons (valid or invalid).  Adobe simply did not have the process or the resources to handle the influx of developers who wanted to contribute.  It was a frustrating situation for the Flex development community (and arguably Adobe as well).

So, the vibrant Flex community answered back earlier this year by creating the Spoon Project to better organize and test Flex SDK modifications submitted by the Flex community.  It proved to be an excellent model, drove innovation of the Framework, and was an initial step toward the full open source move that Adobe just announced.

Who’s governing the future of Flex? We are!

In case the nuance in what’s different now versus Adobe’s 2007 decision to open source Flex isn’t apparent, the major difference is that the Flex community will extend the Flex code base without needing Adobe’s permission to do so.  A new governance, following Apache’s well-established community rules, will be formed to determine the future direction of the codebase.

Since our inception RealEyes has been in close contact with Adobe’s Flash Platform team, we’re excited for this change in governance. RealEyes has always been super excited about the Spoon Project, and our Development Manager (Jun Heider) is very active in this community as the Infrastructure Chairman.  We’ve seen that this is truly a community-driven initiative that is supported by Adobe to increase the volume, speed (and maybe even the quality) in which the Flex framework can grow.

We are excited to contribute further to the future of Flex and confident that, like other successful open source communities, the language will continue to evolve.

Also … Flex isn’t all of the Flash Platform

Sadly, many of the announcements that we’ve been talking about, including the open sourcing of Flex, led many to say that Flash is dead. That simply isn’t true.  Let’s talk about what the Flex framework actually is: a particular framework used to structure Flash Platform development.  Do you have to use it to develop Flash Platform applications? No. And, to be honest, RealEyes doesn’t use Flex in every Flash Platform project because sometimes that framework can make applications to “heavy”.  If performance is of paramount concern for a Flash Platform application, Flex often cannot replace pure ActionScript.

Flash and Flex are not going away.  Adobe is still committed to developing tooling to support development for the Flash Platform. Further, Adobe hasn’t open sourced the Flash Player, the most installed piece of software in the history of the internet.  Adobe plans on steadily contributing to the Flex SDK in its open sourced project and we are working with the Flex community to make us contributors as well.

Adobe and Enterprise Applications

In a week of poorly handled communication, probably RealEyes’ largest concern was Adobe’s statement that “In the long-term, we believe HTML5 will be the best technology for enterprise application development.” Ouch.  Big enterprises have invested millions upon millions of dollars in the development and maintenance of Flash Platform applications.  At the very least that statement can erode the confidence that large companies (or companies of any size, really) have when building systems based upon Adobe technology.  Something that we feel is probably a bit of an over-reaction.

Also, without context this statement is very misleading.  Currently, HTML5 does not have full functional parity with the Flash Platform.  A few days after making this statement, Adobe clarified it by indicating what it intended as a timeframe for HTML5 to be able to truly complete with Flash Platform development: three to five years. That timeframe could be heavily extended when considering corporate browser adoption timelines.

There’s no enterprise that can wait three to five years for functionality.

As Adobe stated, “Flex has now, and for many years will continue to have, advantages over HTML5 for enterprise application development – in particular:

  • Flex offers complete feature-level consistency across multiple platforms
  • The Flex component set and programming model makes it extremely productive when building complex application user interfaces
  • ActionScript is a mature language, suitable for large application development
  • Supporting tools (both Adobe’s and third-party) offer a productive environment with respect to code editing, debugging and profiling and automation.

We see all that as being the case and some more:

  • Enterprise clients tend to have slower adoption rates for software, meaning that not all enterprises support the advanced HTML5 features that exist.
  • In particular, the video capabilities in HTML5 are not as robust as what is available in the Flash Platform including multicasting with integrated hardware acceleration and advanced security models.
  • The testing issues for supporting browser fragmentation can be daunting to enterprises, compared with supporting a Flash Platform application that can be deployed across desktop browsers with consistent display and functionality.

RealEyes will continue to recommend Flex and Flash Platform development to our clients where it makes real business sense to do so.  That said, there are reasons to use HTML over (or alongside) the Flash Platform, and we have plenty of clients we support who do that as well.

The Impact to RealEyes

So, what does all of this mean to RealEyes?  In the short term, it has meant a challenge to bring context to Adobe’s announcements and dispel rumors and misinformation to our clients. In the long run, it probably doesn’t mean a lot.

We have already been on a path of technology diversification with continued focus and adoption of HTML5, its supporting technologies, and native mobile development. Many of us are in the technology space because we enjoy the challenge of evolving our skills as the industry grows.  However, for the next few years, we anticipate that the Flash Platform will continue to be our predominant focus.

Our development specialty has been in delivering industry-leading streaming media solutions and multiscreen development. Flash and AIR are still the best solutions for this and will be for a while.  The timeline for that largely depends on Adobe and, as a valued Adobe Solutions Partner, we will continue to support them in as educated and balanced way as possible.

We are actively involved in the future of the Flex framework through the Spoon Project and excited about the potential for future growth for that project.  We are now even more apt to contribute to the betterment of this already robust framework for the benefit of the Flex community.

Finally, RealEyes has always helped our clients to choose the best technology to power a given project and we will continue to do this.  And, as HTML5 becomes a more comprehensive solution, we will likely recommend it more frequently. It is truly about what is right for the current and future on a case by case basis. Our clients and projects will continue to be industry leaders, no matter the technology behind them.


Now, we can’t see all of the news in a positive light.  And not all of it is positive – certainly not for the 750 Adobe employees who were laid off and their families. However, this degree of restructuring in the fourth quarter isn’t unprecedented for Adobe.  We’ve seen this over the past couple of years.  This year, as in years past, we lost meaningful relationships with Adobe employees that we’ve been happy to collaborate with on community and development projects.  We at RealEyes have close contact with Adobe and tend to focus on how individuals shape the platforms, products, and communities that we work with instead of quarterly earnings and fiscal projections.  While adjusting to this restructuring, we wish all of the affected employees only the best in their next moves and hope that they will continue to make positive contributions to the technical community they have helped to shape.

Additional Links: