Perhaps there were those who felt that, with HTML the clear victor of the battles, sailing would be much smoother. With Flash out of the way, everyone could just unify around HTML, and start producing some kick-ass cross-platform experiences.

Unfortunately, such expectations were quickly revealed as unrealistic. Instead of clean, cross-platform apps, games and experiences, designers, developers and the firms who hire them have discovered an incomplete HTML specification (particularly lacking on audio and video, which are core elements of many rich experiences), and suffering from painfully significant variations in implementation across browsers and platforms.

It’s now been just over a year since the poorly-handled Adobe press release announcing the end of the Flash Player for mobile devices — the culmination of the multi-year battle between Apple and Adobe, between HTML and Flash. While the market for Flash took a big hit that day, in retrospect, I think many will agree that what was lost was actually something quite different and more significant. Gone, along with Flash as a viable cross-platform technology, was Adobe’s widely under-appreciated investment into making the web (particularly the rich web) work — regardless of browser or operating system.

And so, without a satisfactory replacement for Flash, what really disappeared last autumn was the prospect of a clean, write-once, publish-everywhere technology, that enabled firms and individuals to communicate easily (and relatively inexpensively) with any user, viewer or reader, regardless of the device with which that individual chooses to experience digital content.

And, make no mistake: while both a history of personal animosity between Jobs and Adobe, as well as some valid technical concerns, both played into Apple’s strategy with respect to Flash, what really was at stake was control over the experience-layer of iOS. Delivering rich, compelling experiences in a browser directly threatens Apple’s walled-garden App Store strategy. Flash was a threat and a target precisely because it presented an effective means to communicate with users of Apple’s popular devices, in a manner that did not involve Apple (i.e., through the browser).

Indeed, looking back at the web tech wars of the past few years, it’s hard to find any “winners”, per se, other than Apple. That’s not to say a lot of firms aren’t doing just fine — it’s just hard to see who, other than Apple, has actually directly benefited from the increasing difficulty of delivering consistent, rich experiences inside of browsers.

Apple was best positioned to win in this fragmented landscape, because iOS provides both user-mass and platform simplicity and stability. Apple’s devices are not only bestsellers in their categories, but users of iPhones and iPads use them a lot more than their Android counterparts (at least for browsing and apps).

Whereas, catering to Apple’s iOS means developing for relatively few devices, all running the same Safari browser (albeit, with different versions), developing for Android means building for dozens of different devices, hardware configurations, screen sizes, form factors, OS flavors, and browsers.

As a result, if you want to cater your rich content and experiences to mobile traffic, catering to iOS is relatively cheap (one browser, three form factors) and gets you a huge chunk of your most active mobile users. Building for Android costs much more (because of the variety of devices on which Android runs) and serves a smaller segment of your potential viewers. While there are rich sites and apps that run on Android, there are many fewer than for iOS.

The economics are clear. And Apple wins.

So, inside One Infinite Loop, the disruption to web technologies has been a tremendous win, strengthening Apple’s control over the experience of their users. In an otherwise tumultuous sea of devices and browsers, iOS and the App Store provide an island of controlled simplicity, to which content owners, developers and consumers have flocked.

Outside Apple’s walls, however, the outcome of these tech battles has been quite different, as much of the world has come to the realization that they were sold an Apple-hued bill-of-goods when it came to the purpose, potential and intended role of HTML5. And, as a result, we see apps costing more to build (sometimes, a lot more), and offering fewer features to a decreasing portion of users. While many in the tech press discuss the industry in terms of “what’s possible with HTML,” the reality on the ground is guided more by “what’s possible with our budget.” And the answer is “less than before.”

Designers of experiences destined for the web have their visions stifled and constricted, because much of the functionality that both designers and consumers have come to expect from a decade of rich web experiences, is just no longer practical or possible inside of the browser. And developers, who are expected to just make things work, are left picking up the pieces to forge professional-grade experiences, despite the absence of professional-grade technology to create and deliver these experiences.

Just make it work on these….

2012 has revealed a landscape that is defined by platform fragmentation, and in which corporate warfare precludes the potential for solutions that are effective to engage *ALL* users. It is a world in which the costs and complexity of communicating to consumers through custom software continues to increase. Many firms — particularly smaller ones — simply can not afford to create the experiences they envision. It is a world in which Apple dominates mobile platform discussions in the way that Microsoft once dominated the desktop discussion.

While this feels like some steps backwards (and I do not believe this outcome was the inevitable one) this is just another step in the maturation of our 20-year old industry. And we now know what to expect for the foreseeable future. There are no identifiable trends on the horizon that look to change things.

Indeed, if anything, the future is likely to become more complicated; it seems to me unlikely that Apple will be able to sustain its single-handed dominance of mobile platforms over an extended period, with lower-priced alternatives featuring compelling media offerings (right now, Amazon appears to be a not-insignificant threat; no doubt there are others brewing). When that happens, supporting mobile becomes even more complex and costly.

And thus the irony is revealed: while Apple used its market dominance to help create a world in which cross-platform communication is increasingly costly, Apple’s dominance of mobile platforms is now what is helping keep that inflation in check. When Apple’s dominance weakens, the rate of inflation in the cost of delivering a feature to a consumer will increase even more than we’ve seen to date. And, I do not see any large firms properly incentivized or positioned to attempt to change this fundamental dynamic of non-interoperability.

That’s not to say that HTML will stand still. It’ll get better. It’ll get more feature-rich and performant. The older browsers will eventually die off. The web will move forward — it’ll just be moving much more slowly compared to the pace of innovation in features and performance that Flash had enabled inside of browsers for the prior decade. A lot more slowly.

In the immediate-term, I believe that 2013 will be a lot like 2012. But, we all now have a much better idea of the challenges we are facing, so there will be less uncertainty as we continue to cope with the ramifications of platform fragmentation.

Beyond next year, where are we headed?

Are we going to a place where production of great experiences for all audiences is once again reasonably affordable, and fosters outstanding innovation in creativity and problem solving? Or, is our path one in which the pace of innovation remains slowed by difficult technologies, and only the largest firms and brands have the pocketbooks to build solid cross-platform experiences — with the rest of the firms out there forced to pick and choose what features to support on which platforms?

Will web development again return to a place where creativity and user experience are the driving forces, or will we remain in a state where details of technological limitations and implementations drive the conversation?

Will great experiences remain on the web, where they can be accessed by anyone, at any time, regardless of who controls the OS and the App Stores? Or, will more feature-rich experiences migrate to native apps, which offer much greater performance, but must often be distributed through controlling third parties?

In part, my experiences of the last 20 years, and in part, the optimism found in so many in the tech industry, leads one to assume that the outcome to these questions is at least partially in our control — that we have the power to affect how this plays out. The ‘open standard’ veneer of HTML (and related technologies) strengthens these assumptions.

But, in my opinion, that assumption is erroneous. To me, if the last year has demonstrated anything clearly, it is this: these questions will be answered by large corporations who have extremely limited interest in cooperation, no interest in enhancing user experiences on any platform other than their own, and no interest in making cross-platform development easier, cheaper — or heck, even possible at all. To crudely paraphrase Noam Chomsky, we’re looking at an era of “Manufactured Incompatibility”. Because, fostering incompatibility is perceived to be more profitable than enabling interoperability.

And so, we are set for an extended period in which coping with platform fragmentation remains the primary trend in interactive development, stifling creatives, stymying developers, frustrating clients, trimming functionality, and straining budgets to deliver features to users across devices.

Good thing we’re all getting used to it.

But, of course, none of these projects exist unless a sale is made.

Earlier this year, Yakov Fain penned a provocatively titled post, “Will HTML5 Force You to Lie,” confronting many of the issues inherent in selling solutions around a not-quite-fully-baked-and-implemented technology. After a year of selling projects and deals in this much less predictable environment, I’ve found that, while HTML5 hasn’t forced us to lie, it has altered the nature of our sales process in some tangible ways.

What to Expect When You’re Expecting (an HTML5 App)

A sales process is many things, but it is essentially a process of putting a nice bow around some type of promise. Any proposal essentially says “we’ll do X, we’ll do it in this particular way, and it will cost you Y.” The promise you state, and how you state it, does a great deal to establish the client’s expectations for the project and product.

The root cause of today’s disruption is enormous platform fragmentation.

Making such promises in technology can always be a tricky process, and one that is inherently risky. Any software solution implicitly requires the interaction of multiple pieces of hardware and software technology — the number and complexity of which is prone to yielding unpredictable outcomes.

Today’s platform fragmentation notably exacerbates this persistent problem. The variety of devices and browsers significantly increases the likelihood of bugs or other issues impacting production. In other words, the tech landscape today makes the establishment of expectations and promises even trickier—or more susceptible to operational risks—than before. The more complex your projects are (such as custom video and game apps), the more vulnerable you are to these risks.

Today, our proposals more explicitly reflect the degree of uncertainty, in an attempt to establish the client’s expectations more accurately. How so?

Agility in the Face of Uncertainty

As I say, while these challenges may be greater now, they are certainly not new. Coping with uncertainty is just a fact of life for those who work in virtually any aspect of software development. The more functionality you want, and the more platforms you target, the greater the degree of uncertainty facing the production.

Frustrated by the strain of many years running large-scale waterfall software projects, a few years ago Almer/Blank converted to agile production. Agile can mean different things to different teams and companies, but one of the core differences between waterfall production and every flavor of agile that I’ve seen, is a fundamental shift in the nature of the contractual relationship. While we do make promises as part of how we practice agile, these representations are quite different from the fixed-price/fixed-scope/fixed-time contracts typified by traditional waterfall.

Perhaps unsurprisingly, one of the biggest challenges we encountered as a firm in our switch to agile was figuring out how to sell this process to customers, most of whom come in the door expecting some sort of fixed-price/fixed-scope proposal. Indeed, most clients have budget restraints with respect to any new work to be contracted to an external vendor. While agile is a powerful production methodology that makes sense in many contexts, it can be exceedingly challenging to get certain customers out of the ‘fixed-price, fixed-scope, fixed-time’ mindset.

Flexibility is the best way to maximize chances for success in the face of uncertainty.

Instead of promising to deliver a fixed set of features for a fixed price, promise that you will run a project that will be flexible to the change that is inevitably encountered. Do not promise a field of roses; instead, promise a team that is skilled at navigating the mine field that lay ahead, and a process that enables them to address as-yet-unknown challenges as they emerge. Make the client aware of the potential pitfalls and hurdles that can emerge in a landscape in which new browsers, devices and operating systems are released on an almost daily basis.

A key part of this approach involves a shift from discussing technologies, features and functionality, and instead focusing on business goals.

A Focus on Goals

Try to focus the discussion around the customer’s business goals, instead of features and technology.

What is the goal of the project? What is the business pain that this software is meant to address? What benchmarks will create the return-on-investment (ROI) that will justify the project budget to the stakeholders?

Questions such as these are vital. In contrast, questions about whether the project is completed in HTML5 or just plain ole HTML, or whether you are using the WebM codec to deliver video to Firefox are essentially irrelevant. The sheer complexity of today’s platform landscape means that discussion of technical details in the context of a sales process is generally unwise.

In part, focusing on goals sounds obvious. And in part, this is deceptively difficult. Because, after all, we are selling software; the obvious temptation is to focus on details of how the project is to be built.

But the more detail about features and technology you incorporate into your proposals, the more opportunity there is for the conversation to veer off-track, focusing on irrelevant technical details. Or, as a current client of ours frequently states, “let’s not get stuck in the weeds here.”

More importantly, the more such detail you include, the more you will have established expectations on those points, and thus the less the flexibility you will have throughout production to shift or alter functional and technological aspects of the project in order to meet the business goals. If you find that discussions necessitate a high-degree of technical detail, then strongly consider first running a Discovery phase (outside of the sales process) to provide that definition, prior to production.

Remember: Customers don’t actually want to buy code or software or any technology. They want to buy a solution to their problem, a problem that is likely more complicated to solve today than it would have been three or four years ago. Regardless of what the client believes when s/he walks in the door, at the end of the day, the client actually cares about whether the business goals were met.

So, within the sales process, maintain as much focus as possible on the actual purpose and business justification of the project. Try not to sell a feature list, but instead sell the skills of a team that knows how to translate business goals into user experiences, and has been down this road before. (I believe this is especially true if you do not compete on price, but on some other qualities.)

It is simply not possible to promise smooth sailing, when the seas are as stormy as they are today; instead, promise a professional, skilled crew that has experience dealing with uncertainty and solving challenging technical problems that are currently unknowable.

Technology Chops

Given how many technologies can be involved in a single solution, find ways to mention all of those with which you have experience.

While shifting the conversation from technology to goals is advisable, it is obviously also important to reinforce your customer’s confidence in your skills with technology. To accomplish this, we cite relevant past work as well as the individual achievements of our senior engineers.

Following the shifting technological landscape, given how many different technologies are now involved in most projects, we find it useful to communicate our skills and experience with as many different technologies as possible — far more than one or two years ago. Of course HTML5, JavaScript, CSS, iOS, Android, Objective-C and Java are all mentioned. As are numerous coding frameworks and other specialized engineering tools. All of these are mentioned in our proposals, with context.

However, we do not go into much detail on these points; if the customer wants more information on our experience with specific technologies, we are happy to answer any of their questions, but that level of detail need not be included in the proposal itself.

In this manner, we are able to communicate our skills and experience with a wide variety of technologies, without getting into technical details about the current project.

Taking a Pass

Following the emergence of a stormier technological landscape, with platform fragmentation complicating productions and rising costs, we increasingly see potential projects that are just not possible—or, more accurately, impossible for the available budgets.

Taking projects with lean budgets has always been a risky business; today, it just does not make sense.

There are many more clients today for whom satisfactory answers do not currently exist. When we encounter such clients, we must take a pass on the opportunity. And we find this happening more frequently now, than just one or two years ago (again, especially in the realm of video).

So another way in which the shift to HTML5 has altered the sales process, is by having us demur from a higher percentage of sales opportunities. Today’s production uncertainties are so much greater than those in 2010, that lean-budget work presents far too great a risk. To accomplish great, cross-platform experiences in 2012 takes a lot of money. If the client is not willing to spend that money, the client’s business goals will simply not be achieved.

Conclusion

At the end of the day, the changes to the sales process in 2012 have been more subtle than overwhelming. But when the landscape shifts in such dramatic ways as it has, there are going to be ramifications to all aspects of production — including how such projects are sold.

Recognizing the impact of this shifting technological landscape on the sales process, I recommend:

• Being up-front about the risks and uncertainties inherent in producing cross-platform experiences today.
• Focusing on goals, rather than features or technologies.
• Conveying expertise in as wide a variety of technologies as possible.
• Seriously considering passing on opportunities that do not pass the reality-check smell-test. It’s always been risky to try to build great experiences on the cheap; today, I think it’s just shy of insane.

Overall, I believe that the landscape has shifted in such a way to favor those firms that are comfortable selling uncertainty. Abstract technological detail from the discussion and focus on creating plans that have high probability of achieving business goals, despite uncertainty. Incorporate the uncertainty. Own it.

Obviously the battles between HTML5 and Flash have certainly garnered much of the attention as a source of disruption in our industry. However, this much publicized conflict isn’t really the issue at all. The HTML5/Flash conflict has been more of a symptom, rather than a cause.

The root cause of today’s disruption is enormous platform fragmentation.

The root cause of today’s disruption is enormous platform fragmentation. There are simply a tremendous number of devices out there in the hands of consumers, and developers are expected to make their creations work on so many of these different hardware options.

Yes, we are told, HTML5 works on all of these devices — but, as any developer who has tried to create a rich interactive, multi-platform experience in HTML5 will tell you, HTML5 has distinct functional limitations and tends to work differently in many different contexts, requiring a tremendous amount of effort to achieve a consistent cross-platform performance and experience.

And not only does HTML5 work differently on all of these devices — the landscape can literally change on a daily basis, as a new browser version is released, or Samsung updates the version of Android on their Galaxies. Many do not realize that the HTML5 spec is, itself, still in flux.

This is a remarkably tenuous environment in which to be producing experiences — vastly more temperamental and less stable than at any prior point in the 20 years since I began building websites.

And so, in an attempt to quantify some of this thinking, I designed a brief survey intended to gauge factors that are indicative of instability. The survey featured seven multiple-choice questions — six regarding factors indicative of difficulty or annoyance in the execution of work. The seventh is about overall satisfaction. Then, respondents could optionally respond to three open-answer questions.

The First Six Multiple Choice Questions

The results clearly demonstrate that the day-to-day work of a developer in 2012 is more difficult and/or frustrating than it was in 2010: on each of the six points (Learning Technologies, Managing Expectations, Building Features, Testing Features, and Prevalence of Bugs) things were better in 2010 than they are today.

Technologies

By a whopping 38-to-1 margin, 76% of respondents claimed that they must learn more technologies today in order to execute their jobs, compared to only 2% who say more technologies were required in 2010.

Do you need to master more technologies, fewer technologies, or about the same number of technologies, today in 2012, than in 2010?

Expectations

69% of respondents believe that it was easier to establish realistic expectations in 2010, compared to only 10% of respondents who believe it is easier today in 2012.

Is it easier, harder, or about the same level of difficulty, to establish realistic expectations with your clients or bosses, on features, user experience and performance, today in 2012, than in 2010?

Estimation

55% report that it was easier to estimate effort in 2010, compared to 20% who say it is easier today.

Is it easier, harder, or about the same level or difficulty, to estimate effort today in 2012, than in 2010?

Features

51% report spending more time on features today, compared to 24% in 2010.

For any given average feature, do you spend more time, less time, or about the same amount of time building that feature in 2012, than in 2010?

Testing

49% report spending more time testing and validating their code today, compared to 33% who say more time was required in 2010.

Is it easier, harder, or about the same level of difficulty, to fully test your code and deliverables today in 2012, than in 2010?

Bugs

And, 51% of respondents explain that more time is spent in bug remediation today, compared with 20% who report more time spent in bug remediation in 2010.

Do you spend more time, less time, or about the same amount of time fixing bugs in your work today in 2012, than in 2010?

 

As far as these results may be considered valid, from them we can ascertain that, today in 2012, developers:

• must learn more technologies in order to execute their jobs;
• find it harder to establish realistic expectations on feature performance;
• find it harder to accurately estimate their work;
• find it takes longer to build features;
• find it takes longer to test builds;
• find that more time is spent in bug remediation efforts.

Thus, on six critical dimensions, work today for most developers is more difficult, burdensome and challenging than in 2010.

These results are inline with what I had assumed — though, the margin on some of the responses was striking. For example, that developers report, by a 38-to-1 margin, requiring more technologies to execute their work, is a striking statistic, and one which leads me to conclude that exceedingly few developers have been unaffected by the technological tumult.

Open Ended Responses

The survey also included three optional open-ended questions. The first asked for the biggest improvements to emerge in the past three years; the second asked for the biggest detriments to emerge in the past three years; and the final left room for additional comments.

Many of the responses to these open-ended questions confirmed that platform fragmentation is the root cause of these changes over the past three years, and that developers are intimately aware of this fact. One such comment read:

We are back to cross browser testing, in some ways worse than it was before. We’re jumping hoops to do things that use to be easy. ie. the embedded “video” of the iPhone 5 on Apple’s site – a ridiculous solution required for a problem of their own making. So many HTML5 demos are nice, but pale in comparison to the performance they would have had in Flash and only work in some of the latest greatest browsers.

Platform fragmentation was, indeed, the single most commonly cited detriment to have emerged in the past three years. Other responses, which touch on this issue in one way or another, included:

• “Extreme fragmentation everywhere. From multiple devices to endless options in terms of frameworks and dev tools.”
• “Platforms have been emerging too quickly (and dying too quickly). That is really making things jittery”
• “I’m back to where I was back in 2001 — doing HTML projects again. The same issues, the same concerns, and the same incompatibilities as when I used to do them before. Programming in HTML / JavaScript is not elegant nor fun — everything is a hack one way or another.”
• “fragmentation has grown exponentially”
• “compatibility with all those devices out there”
• “Cross browser bullshit.”
• “HTML5 bullshit.”
• “Removal of flash on IOS browsers. HTML hype”
• “you have to use inferior technologies to fulfil the wishes of the clients”
• “Flash Player removed from mobile browsers and never been on iOS browsers. HTML 5 being hailed as the savior of the web but in reality not ready or available ESP on safari. Removal of design tools by adobe for flex development. Move by adobe to focus on flash for gaming and abandoning flash for application development. Annoyance of apple for not progressing and supporting HTML 5 features. Annoyance at web community for not really solving the issues flash is trying to solve. (needs to be a HTML 5 plugin and alliance to solve issues).”

While, in my personal observations, the market has calmed significantly from last year’s peak battles between HTML and Flash, and we are seeing more reality and accuracy in discussions and media coverage, other comments identified ‘FUD’ (Fear, Uncertainty and Doubt) as a major detriment to their work:

• A much more poisonous atmosphere in the general populace due to untruths precipitated by the “tech media”.
• Steve Jobs’ remarkable ability to get people to believe things that aren’t true.

Given the difficulties and variabilities identified above, it is unsurprising then, that many respondents included comments indicating an increase in difficulty communicating with clients:

•  “Some client perceive that development costs should be lower now than there were a few years ago.”
• “Customers have become more sensitive on time, effort and cost. This makes it difficult to do things logically. in terms of developer attitudes as well as calibre, I have observed a more casual attitude towards learning. Anything which needs digging into and hard work is looked down upon.”
• “”Customer/Client” confidence in certain technologies has made it harder to sell products w/ said technologies; even when that is the best choice.  The evolution of mobile devices and especially native apps may make future development more difficult if you have to accommodate for them.  I am not yet in a position where that is important to my clients.”
• “clients need more educating”

Finally, several respondents cited Adobe’s haphazardly-executed 2011 change in strategy as one of the sources of today’s difficulties:

• “Adobe’s hopelessly inept management of the future of Flash.”
• “not being able to rely on Adobe anymore.  They USED to be an asset to the technologies they support, now they’re a hindrance.”
• “Adobe gave up on Flash. Flash was cool but now it’s a joke.”
• “There are no good alternatives for flash and Adobe’s pulled back support on several fronts because they can’t get flash on iOS and HTML 5 is not ready nor has the tooling behind it that targets all browsers”

Overwhelmingly, the biggest improvements respondents identified as having emerged in the past three years, are the number of “available frameworks” (as well as plugins, libraries and other tools) for getting work done. I believe this is indicative of a process of rapid maturation of technologies, as they are adopted into professional-grade workflows. Some such responses included:

• “Maturity of available frameworks for HTML and flash”
• “tools, more to help you get those nasty bugs or strange issues”
• “IntelliJ and Sublime getting mo-hottah.”
• “Better initiative from the community to create frameworks and development tools that ease the pains of using/learning new technologies.”
• “Many plugins and libraries help builing coll stuff”

The Surprise

As I said above, much of what this data reveals was not surprising. I executed this survey to test some of my assumptions of current trends. After all, it’s one thing for me to continually argue (as I have repeatedly done on this blog, such as this post) that work is getting more complex and expensive; it’s another to have a statistically significant chunk of the community report similar experiences. This, to me, provides some tangible confirmation of my assumptions.

But, there was one piece of data in the results that I found very surprising.

The seventh multiple-choice question was geared to measure overall job satisfaction among respondents. I had assumed that the responses to this question would roughly correlate to what the first six questions revealed, indicating a drop in developer satisfaction with their jobs. After all, if the day-to-day jobs of developers is becoming more onerous and challenging on numerous dimensions (as indicated by the responses to the first six questions), then it is reasonable to assume that developers would have less satisfaction in their jobs.

Instead, this was the only of the seven questions on which “2012” outperformed “2010”. By a relatively slim margin, 37% of respondents indicated that developers are more satisfied with their careers today, than in 2010; an additional 27% indicated that they have maintained the same level of satisfaction.

Thus, 64% of respondents indicated that they are at least as satisfied with their careers today, as in 2010.

Overall, are you more satisfied, less satisfied, or do you have about the same level of satisfaction with your chosen work/career today in 2012, than in 2010?

What gives? If so many quality-of-job metrics have declined in the past few years, why hasn’t developer satisfaction, as well?

I do not have an answer, and the survey did not include any additional questions to illuminate this. I do, though, have a few possible explanations for this rather surprising result.

1) The Mess Hasn’t Sunk In

One possible explanation is that, while developers are clearly aware that their jobs are harder today than in 2010, not enough time has passed for this awareness to sink in. In other words, developers haven’t yet had time to realize their jobs are harder, and that they are thus, less satisfied.

I do not find this explanation particularly compelling; though, the phenomenal rate of change with which developers must cope on a daily basis does add some believability to this notion. After all, if all of your time is spent just keeping up with your job (learning new technologies, managing client expectations, and delivering quality code), it is quite possible that you just haven’t sat back and thought about job satisfaction.

2) Developers Like Messes

Many developers derive joy and satisfaction from solving complex problems. Indeed, the more complex the problem, the greater the sense of joy and satisfaction that can be achieved from overcoming it. If one frames today’s messy technological landscape as a tapestry of complex problems, then I can see a portion of developers deriving great satisfaction from solving those problems, and developing great experiences that perform reliably, across platforms, and up-to everyone’s expectations.

In other words, it could be that developers like big fat messes, and derive satisfaction from overcoming them. While the platform fragmentation may thus be a drag on client budgets and customer experiences — perhaps the opposite is true for developers (or, at least for a portion of developers). (Hence the title of this post.)

3) HTML5 May Be Difficult, But Not As Difficult As Homelessness

The final possible explanation I have considered is that, well, the economy still sucks. It’s one thing to be frustrated by spending your day fighting with varying HTML5 implementations; it’s another to be frustrated spending your day fighting with bill collectors and mortgage holders.

Yes, our industry may be in a difficult period now, but we’re not in anything like the shape of the rest of the American manufacturing, construction or real estate sectors.

Given where we could be right now (and where many of our neighbors, relatives and friends are), dealing with platform fragmentation is just not that big a drag. In fact, an argument could be made that the massive platform fragmentation is actually stimulating the developer economy (requiring more labor to execute similar features).

Again, these are just potential explanations, and it is possible that none of them are accurate.

But, of these, I prefer the second one: that developers like messes. Programmers enjoy problem solving and overcoming challenges. This sounds most like reality to me.

A few weeks ago, Robert Reinhardt of VideoRx.com said that “if Hollywood had to make films with technologies like HTML5, they’d strike.” Maybe, given the results from this survey, a corollary to that statement could be, “…and if developers had to make apps with tools as stable and reliable as those used in Hollywood, they’d get bored.”

Complexity Costs Money

While I continue to ponder the results of that seventh question, to me, the key takeaway of this survey confirms what has been my personal experience this past year: building interactive applications is a more complex endeavor, requiring the intermingling of more technologies in a process that consumes more time.

Platform fragmentation has created a landscape in which it just costs a lot more money to deliver the same feature to the same percentage of your audience, than just three years ago.

And this is why interactive development costs more in 2012 than in 2010.

Given that, what does 2013 hold? And 2014 and 2015? At what point does the rate of platform fragmentation first stabilize, and then possibly reverse? Alternatively, will any technologies emerge that help us overcome platform fragmentation (as Flash once did in the pre-iPad era) with less difficulty than is required today? Until that happens, I do not see any possibility of reversal of the trends covered in this post.

Technology is supposed to move forward, and as it does, things are supposed to get better and easier. Ideally, technological progress is intended to improve happiness.

Is this what we’re seeing?

So I thought it might be instructive to set up a very brief survey (7 multiple choice questions, and three optional open-ended questions), to see if what I’m hearing offline is actually a trend.

The Google-hosted survey is embedded below. If it does not load, or, you’d like to send the survey to someone else, here is the direct survey link.

I sincerely appreciate your time in responding to this survey. The more data I collect, the more meaningful the results will be. I will summarize, and attempt to contextualize these results in a subsequent post.

Thank you,

-r

THE SURVEY IS NOW CLOSED
Results will be covered in a subsequent post

Adapting to the 2012 Web

This process of adapting interfaces is not the same as porting experiences to new platforms. So-called platform extensions involve porting existing experiences to new platforms — the process of, for example, converting a website into an app for the iPhone or Nintendo Wii.

No one expects Netflix on the Wii to present the same experience as Netflix in a desktop browser. This is a platform extension, rather than an adaptable GUI. Users do, however, expect Netflix to offer the same experience in IE and Chrome.

When executing a platform extension, one generally builds a new piece of software from scratch, designed to exploit unique characteristics of the target platform. Netflix on the Nintendo Wii is, for example, a platform extension of Netflix. No one expects Netflix on the Wii to present the same experience as Netflix in a desktop browser. People use desktop browsers and their Nintendos differently, in different contexts, with different peripherals. Users expect the experiences offered by platform extensions to be different — if they weren’t, they’d be poorly designed.

While platform extensions render experiences differently on new platforms, adaptable GUIs render experiences as identically as possible, within different configurations of the same environment — in this case, the browser. The purpose of an adaptable GUI is to present as consistent an experience and feature-set as possible, despite challenges in implementation and support of HTML functionality.

Ensuring cross-browser compatibility of one’s work has always been an issue in web development. Today, the process is something much more complex and intricate.

Of course, ensuring cross-browser compatibility of one’s work has always been an issue in web development. But today, in 2012, as more and more functionality is rammed into the browser, these issues have become significantly more burdensome to production efforts. Video-based projects, in particular, are ones in which the challenges of adaptable GUIs are readily apparent.

A 2012 Video Player

Let’s take the example of a basic video player intended to run inside of desktop and mobile browsers. This simple player will have only three features:

1. adaptive streaming video delivery;
2. the ability to pause and resume the video;
3. and full-screen functionality.

While today YouTube offers multiple types of video players, including HTML5, YouTube launched, and ran for years, offering only Flash video.

Back in 2008, this would have been very simple. There was really only one technology that people used to display video inside a browser — Adobe Flash. HTML did not support video playback, almost all viewers had Flash installed, and it was a quick download for those who didn’t (much smaller than any other video playback plug-in). And, though Flash video didn’t really work on mobile, mobile was not a significant chunk of anyone’s market.

In 2008, building a Flash video player with the above three features could literally take as little as an hour, and possibly up to a few days — and (depending on your user base) more than 9 out of 10 visitors could immediately watch, without downloading any new software.

Fast forward back to today, and building a ‘Flash video player’ is no longer an option. Right off the bat, you will necessarily eliminate all iOS users, and an increasing number of Android viewers. Building video players in Flash is necessarily going to omit a large, and growing, segment of your potential viewers.

Thus you will want to utilize HTML5 for in-browser video delivery.

Catering to a Fragmented Market

Fantastic! We have an answer. Flash may not work for us anymore, but we have HTML5 video. But this satisfaction is short-lived, as we come to realize that HTML5 video is not going to solve all of our problems.

According to Long Tail Video, 74% of the market can play HTML5 video (up from 66% in the last quarter, and 50% from a year ago).

While relying on HTML5 for video delivery may work for 100% of your mobile viewers, many desktop viewers will be left behind. According to Long Tail Video’s continually-updated census, 74% of the market can play HTML5 video (up from 66% in the last quarter, and 50% from a year ago; although, the conflation of mobile and desktop in those statistics obscures how many desktop viewers still can not view HTML5 video).

Thus, somewhere in the neighborhood of one-quarter of your viewers can not watch HTML5 video. That’s an awful lot — nay, an unacceptable number — of viewers to leave behind. So we see that HTML5 alone can not meet our needs. What can you use to fill in those gaps?

Well, there’s really only one option… Adobe Flash. Using HTML5 and Adobe Flash together, to deliver video inside of a browser, ensures that almost 100% of your viewers will have immediate access to your video content inside a browser, on desktops, smart phones and tablets.

So it now seems that we have a clean answer. We’ll just use both HTML and Flash video, to ensure that our content is accessible to our viewers.

Unfortunately, it turns out that integrating multiple technologies to deliver a seamless experience across various browsers is a bit more complicated than it may appear on first glance. Indeed, there are a series of challenging trade-offs that must be addressed, when specifying even a simple video player that exploits both HTML and Flash for video delivery.

Feature Implementation

Central to the challenges of building successful adaptable GUIs is the fact that HTML5 and Adobe Flash do not support all of the same features — this is particularly the case with respect to video playback. Heck, not even all the browsers that support HTML5 video, support all the same features. Thus, there are certain features that will only be available in certain environments.

Today, only iOS reliably supports adaptive streaming in HTML.

For example, adaptive streaming (streaming video at a quality level based on the viewer’s connection speed, detected on an on-going basis throughout video playback) has been commonplace in Flash video players for years; today, however, only iOS reliably supports adaptive streaming in HTML. It is not possible to deliver adaptive streaming HTML video in, say, Internet Explorer, Chrome or Firefox.

Another such feature is full-screen video playback, which Flash has supported for several years. Yes, full-screen mode is part of the HTML5 specification, but (again, per the Long Tail Video census) approximately half of your viewers will use a browser that does not support full-screen.

Thus, of the three features I’ve noted as requirements of our video player (listed above), two — full-screen and adaptive streaming — are not cleanly implemented across the multiple technologies we are planning to use. The inconsistent availability of these features creates the potential for a complex or confusing user experience.

Feature Consistency and Availability

Given that some of our features are impossible in some of the environments in which viewers access our player, we essentially have three options:

1. Remove the Inconsistently-Available Features
   The simple answer, from an engineering perspective, is to enable only those features supported by the current technology. So, for example, if someone is viewing the HTML version of our video player, in a browser that does not support full-screen mode, we simply do not render a full-screen button. In other words, we totally remove the inaccessible features from the GUI.
    
   While this is a simple answer, it is also quite a poor one from the viewer’s perspective. The same viewer may access our player from IE 9 at work, and Chrome 22 at home. This viewer would likely be quite surprised — and frustrated and confused — to see features added to and removed from the interface at different times of the day. After all, we’re not talking about two totally different devices; these are just two different desktop web browsers, and users have become accustomed to having consistent experiences offered in different desktop browsers.
2. Message Unavailability
   Another alternative is to message the lack of availability of certain features. For example, for those users viewing our player in a browser that supports HTML-video, but not HTML full-screen, we could simply render the full-screen button in a disabled state (e.g., grayed out).
    
   If the viewer then attempts to interact with the button (say, by mousing over it) we could display a message explaining that the user is viewing the player in an old browser, and if they wish to use full-screen mode, they should upgrade to a newer technology.
    
   (It is important to remember that, while we can know what browser the viewer is currently using, we can not know what other browsers the user may already have installed. In these instances when features are not supported in the viewer’s current environment, we are also largely unaware if the viewer may have the required browser already installed on their system. For this reason, our messaging can not say definitively whether the viewer must download new software, or switch to another browser already installed on their computer.)
    
   This option works, resolving any confusion that would have emerged from simply ripping the full-screen button out of the GUI. However, forcing viewers to think about browser technology (and implying that they must download new technology to fully enjoy the experience) has the potential to intimidate certain viewers.
3. Auto-Swap Tech
   The ideal solution is to have the interface respond, automatically and invisibly switching technologies to enable to requested feature. So, let’s once again return to our example of the user viewing our HTML video in a browser without full-screen support. Instead of graying-out the full-screen button, we could enable that button. If the viewer clicks the full-screen button to enter full-screen mode, we could automatically swap from HTML video playback to Flash video playback, and send the player into full-screen mode.
    
   While this may be the ideal option, it is also significantly limited. Recall, we can not know what other browsers the viewer may already have installed. Thus, in our example, we can auto-swap between Flash and HTML for certain features, but we can not switch between different browsers that may already be installed on the viewer’s computer. So, this solution will only work for some, but not all, of our features.

As this last point indicates, these options must be evaluated on a feature-by-feature basis. The solution you devise for full-screen mode, may not be the same one that you wish to pursue for support of adaptive streaming. Each feature that is supported inconsistently across your target environments requires individual consideration for the proper cross-environment treatment.

The Dividing Line

Our player must utilize both Flash and HTML for video playback. So, the rest of the GUI can be either Flash or HTML or both — it’s up to us.

Our player must utilize both Flash and HTML for video playback. But that does not speak to the rest of the interface. Of course, a Flash GUI can control Flash video playback, and an HTML GUI can control HTML video playback, but the opposite is also true: a Flash GUI can control HTML video playback, and HTML can control Flash video playback. So, the rest of the GUI can be either Flash or HTML or both — it’s up to us.

Of course, we could just rebuild the entire player in both Flash and HTML — so that we are, in effect, creating two, separate video players. But that’s a lot of extra engineering effort, both now (as we build this first version of our player) and in the future (as we maintain our code, and add additional features). This is feasible, but comes at a significant cost (basically, we’d have to build everything twice) and will be seen as an undesirable option in many cases.

Well, if we don’t want to build our player twice, then we could build the GUI in either Flash or HTML. But, as we’ve already discussed, building the GUI just in Flash prevents our player from working on mobile, or on desktops without Flash player installed. So, it seems that the smart option (in this generic example) is to build the GUI in HTML, and have that GUI control video playback in both HTML and Flash.

At least we have a relatively clean resolution here. Except for one major issue: full-screen. Returning back to the earlier issue of full-screen behavior, let’s say we want to support Flash for full-screen video playback in older browsers (that do not support HTML full-screen). Building the GUI in HTML, but relying on Flash for full-screen mode, creates two annoyances:

1. We can not display our HTML GUI in full-screen mode — our player can only display Flash content while in Flash’s full-screen mode. So, if we build our GUI in HTML, and wish to utilize Flash’s full-screen mode, we will have to rebuild our GUI in Flash, as well. (Meaning, we will have to build our GUI in both Flash and HTML, after all.)
2. For security reasons, Flash full-screen mode can only be triggered by a mouse or keyboard click inside of the Flash movie. This means that, even with an all-HTML GUI, if we use Flash to deliver our video, then we must ensure that the full-screen button (part of the HTML GUI, recall) is actually a Flash element. In other words, even once we’ve resolved on an HTML GUI, at least one element of that GUI (the full-screen button) must be Flash.

Alternatively, if we do not support Flash’s full-screen mode, then we will only offer full-screen functionality to approximately half of our viewers.

This is fun, yeah?

Tech Defaults and Upgrade Paths

Ok, we’ve answered all of these internal questions so our awesome new video player is designed and ready, utilizing both Flash and HTML technology to deliver a fully-functional experience to all of our viewers.

Now, a viewer loads the player. This viewer has the ability to view both the HTML and Flash versions of our player. Which version should the viewer see?

A viewer with the ability to view both HTML and Flash loads the player. Which version should the viewer see?

Perhaps we wish to default viewers to HTML for video playback. Fair enough, but then we must be ready to sacrifice adaptive streaming in the majority of our player instances (as only Safari supports HTML adaptive streaming). Perhaps we want to default our desktop viewers to the Flash version, while sending mobile viewers to the HTML version. Perhaps we only want our desktop viewers to see the HTML version if they are in a browser that supports HTML full-screen mode.

As you can see, the question of default technology selection is one that is complicated by many of the considerations discussed above. With these questions, there are no right or wrong answers. You just have to decide on the defaults, and then realize the implications in user experience that will result. As different technologies offer different features and functionality, choosing which viewers encounter which technologies is a core determinant of the resulting user experience.

Related to this is the question of upgrade paths. Let’s say another viewer attempts to load our player, but this viewer is in IE8 (which does not support HTML video) and Flash Player 7. So, this viewer does not have any technology installed to view our video player. What do we tell this viewer? Should he upgrade his browser? Or his Flash Player? And is this influenced by any constraints of our viewers (e.g., if we cater to enterprise users with limited ability to install new technology on their computers)?

Technology Transparency

We have already discussed ways in which we might wish to automatically switch the viewer from Flash to HTML, or vice-versa, in order to provide seamless feature support in multiple environments.

Do we want to offer our viewers the ability to manually switch player technology? E.g., do we want to allow a user viewing HTML video, to intentionally opt to view the Flash video instead?

How transparent do we want to make our rather complex technology of the adaptable GUI?

On the one hand, we’ve gone to all this trouble to build our player in multiple technologies; why not make these different options accessible to our viewers?

On the other hand, the entire point of this endeavor is to provide invisible support for a consistent cross-browser experience; actually allowing users to switch between technologies detracts from the simplicity and transparency that is our intent.

I do not believe there is an obvious answer here — it depends on your priorities. If you wish to opt for simplicity in the user experience, then I believe you should not provide viewers the explicit ability to switch back and forth, from Flash to HTML for video playback. If, on the other hand, you wish to provide more flexibility to your viewers (and, your viewers are not the type who are intimidated by terms like ‘HTML’ and ‘Flash’), then perhaps it makes sense to provide this option to your viewers.

A Continuing, But Solvable Mess

Production talent in 2012 is encountering a new set of issues and challenges: creating consistent and accessible experiences, across multiple browsers and devices, through the integration of multiple technologies in a single codebase.

Production talent in 2012 is encountering a new set of issues and challenges: creating consistent and accessible experiences, across multiple browsers and devices, through the integration of multiple technologies in a single codebase. These are not simple challenges. Feature support, functionality, user experience, business goals and engineering considerations must all be considered together, as one approaches a series of complicated trade-offs. This is all leading to the need to consider the design and production of software GUIs for web apps differently today, than before.

The notion of adaptable GUIs — having applications adapt to their environments, at such a detailed and subtle level as discussed in this post — is essentially brand new. Before the current era of fragmentation and mobile devices, Adobe Flash provided a consistent platform across browsers — none of the questions discussed in this post were relevant. Prior to the era of Flash, users just did not expect this type of cross-platform consistency (and it was essentially unattainable for all but the most vanilla of experiences).

True consistency in functionality, behavior and experience remains the goal (as it has been for years), but for complex in-browser experiences, it is a goal that is becoming increasingly unattainable. The number and variety of devices continues to expand, and the resulting mix of technologies is even more complex today than six months ago, much less three years ago. Instead of building a truly consistent cross-browser experience, we approximate it as best we can, through a series of trade-offs, custom tailored for our audience, balancing their preferences and usage patterns, along with our business goals.

Today, these issues are readily found in the HTML/Flash divide (particularly in the realm of video). How long this era of adaptable GUIs will persist is unclear to me. It is possible that it is a by-product of the results of the Flash/HTML war of the past few years, and will fade away as those battles finally conclude.

I suspect, however, that the market fragmentation we are seeing (that is the root cause of these new complexities and costs) will continue to expand, and with it, so will the need for consideration of adaptable GUIs, as we designers and developers seek to make invisible the browser-and-technology-induced discrepancies that would otherwise impede the user’s experience.

With all of these forces working against browser based mobile Flash content, designers have been searching for alternative ways of delivering similar experiences to these devices. There are a number of emerging alternatives, most being restricted to motion design and basic interactivity. Adobe themselves have produced two workflows for getting animated content onto restricted devices: the CreateJS libraries available as a part of Flash Professional CS6 and Adobe Edge Animate. While the CreateJS workflow is great for those wanting to retain the familiar environment of Flash Professional – Edge Animate is a whole new creature… although many concepts been inherited from its older sibling. This article will focus upon Edge Animate and a few of those concepts.

• Adobe Edge Animate
• Stage
• Properties
• Library
• Publish Settings
• Timeline
• Keyframes
• Labels
• Symbols
• Actions

Adobe Edge Animate

Adobe Edge Animate is an all new tool from Adobe which seeks to enable the authoring of motion and interactive experiences through HTML5, CSS3, and JavaScript in a manner consistent with other Creative Suite applications. Edge Animate is able to create such experiences at this time, due to advancements in browser technology and the need for a consistent, cross-platform solution which is able to function across desktop and mobile operating systems. This article will attempt to showcase the many conceptual similarities between the two workflows.

Adobe Edge Animate in its current form.

Stage

The Stage can be thought of as the canvas upon which we are able to paint our scenes, or the frame within which all our action takes place. The Stage in Edge Animate differs from this in Flash, in the way that its dimensions are controlled and the background color is applied because in Edge Animate, the Stage is effectively just another Symbol. In recent previews of Edge Animate – the Stage itself can be made to be a responsive object, adjusting to different screen flows. This is great for targeting multiple screen sizes.

What makes this really interesting is that elements can be positioned by either absolute pixel coordinates or through a percentage-based coordinate system within a responsive Stage. This allows for some interesting adaptive layouts as individual elements can be pinned in relation to any of the four corners.

The Edge Animate Stage.

Properties

The Properties panel in Edge Animate works exactly as any Flash Professional user would expect it to. Most of the time in Animate, we are working with a number of basic elements: DIVs, IMGs, textual elements, and Symbol instances. There is almost always a wide group of shared properties across any of these element types – but also a number of properties which are accessible only on certain elements.

For instance, only Symbol instances can have Playback Actions attributed to them because only Symbols have their own, encapsulated Timeline. This is very similar to how MovieClip symbols work in Flash Professional.

The Properties panel adapts to whatever type of element is currently selected.

Library

Flash Professional organizes Symbols, Fonts, and Assets within a project Library. The Library panel is an organizational approach to provide easy access to the Symbols. With Edge Animate, we have a similar concept which also stores any Symbols, fonts, and image assets created for a project within that projects Library, exposed through the Library panel.

We even have the ability to export and import Library items across Edge Animate projects or to share with the greater world as Edge Animate Symbol files. These files are basically archives of full Symbol definitions including all assets and font definitions used by the Symbol. Very convenient.

The Library is a repository for imported image files, font definitions, and Symbols.

Publish Settings

The major difference between publishing an Edge Animate composition from publishing a Flash Professional project is the actual output. Flash Professional will produce a compiled binary .swf file for embed within a browser – while Edge Animate produces a group of related .html and .js files along with a set of directories and any assets or references to other resources used in the composition.

While these items can be archived for backup – the eventual distribution requires a bit of care when considering composition publication. Edge Animate will minify and optimize a lot of the .js that is produced when publishing for the web though.

Though we are dealing with HTML & Friends – we can still optimize it for publication.

Timeline

While Flash Professional and Edge Animate do share the concept of a Timeline; that is where the similarities end. The Flash timeline is frame-based while Edge Animate includes a time-based Timeline similar to what is found in After Effects. In the end, these are just two ways of working with motion across time – in essence, this is what we are dealing with in either case. Many Flash Professional users find the fine-grained Timeline of Edge Animate quite compelling.

The Edge Animate Timeline is more like After Effects than Flash Professional.

Keyframes

Both Flash Professional and Edge Animate give the user the ability to define keyframes across the project Timeline. Keyframes are points of distinction which define or modify various properties of an element across time. This is the most basic way in which motion is achieved in either program.Keyframes in Edge Animate behave to a great degree like those from Adobe After Effects.

An advantage of this type of keyframe over those used by Flash Professional is due to the time-based nature of the Timeline itself. Selecting all keyframes will allow us to easily resize everything across time – thus relatively extending or shortening the entire composition duration.

Keyframes can be set on a per-element basis across the Timeline.

Labels

Labels are a mechanism by which we can mark up the Timeline at certain points. These can be used for both visual reference while authoring, or through code to navigate to certain areas of the Timeline based upon the label itself. These items can also be used as simple visual cues when authoring a composition. Honestly they behave just as you may expect them to, if coming from Flash Professional.

We can set Labels to easily jump to different points in the Timeline: sym.play(“JumpPoint”);

Symbols

Symbols are reusable assets whose instances can be used across a project. In Flash Professional, these may be MovieClip, Button, or Graphics Symbols. In Edge Animate, there is no such distinction – though Edge Animate Symbols are most similar to Flash MovieClip symbols in execution.

Just as in Flash Professional, Symbols have their own, internal Timeline. Animation and other content can be easily nested and this animation can be controlled by the parent Timeline through the use of Actions, Triggers (Timeline Actions), or a new concept called Playback Actions which are unique to Symbol instances.

For a great overview of using dynamic data with Edge Animate Symbols – have a look at this video from Lee Brimelow.

Symbols can be instantiated multiple times upon the Stage.

Actions

Actions in Edge Animate can be compared with those in Flash Professional (Macromedia Flash 4). Each program has an Actions panel which can be opened and closed as needed to access simple program instructions. In Edge Animate, we can apply Actions to elements on the Stage, and to the Timeline through Triggers placed at certain specific timecode. While Flash Professional uses ActionScript for programming Flash content, Edge Animate employs JavaScript.

In the figure below, we can see that we have a number of helper snippets at our disposal along the right side of the Actions panel. These snippets provide common functional bits to be inserted and modified when applied to certain evens such as mouse click or hover events. Any events that have been applied to an element are listed along the top of this panel as tabs.

Alternatively, we can use the Code panel within Edge Animate to edit the full JavaScript file without a lot of the constraints placed upon this Actions panel workflow (or even open up the .js file for editing in something like Dreamweaver or Brackets).

Edge Animate has an Actions panel which even includes a set of snippets.

Closing…

While things can certainly appear quite different from Flash Professional when working in an environment like the one Edge Animate provides, there are many similarities to take advantage of as well. The most important thing to realize is that both of these applications are tools with a base set of very similar purposes. Designers will find that once familiar with both tools, each one has strong points and weak points. This can be expressed in the type of output the tool produces – to the specific workflows provided by each tool when authoring – to how well the tool handles specific internal tasks. Learning a new tool like Edge Animate is great fun… and as a HUGE bonus; we don’t have to leave the older tools behind either!

Joseph Labrecque is author of a number of publications focusing on the Adobe Flash Platform and related technologies including the recent “Adobe Edge Quickstart Guide” and the upcoming “Learning Adobe Edge Animate” books.

I was first introduced to JsTestDriver while reading Test Driven JavaScript Development, by Christian Johansen. I’ll refer to JsTestDriver as JSTD for the rest of the post.

What is JSTD?

JSTD is a Java based server packaged as a .jar file. It is not another unit testing framework. To use JSTD you will have to choose a unit testing framework that is compatible with JSTD. JSTD has several unit testing frameworks that it is compatible with. Of course, you are free to build your own adapter if your unit testing framework of choice is not supported. Personally I’ve been using JSTD with the Jasmine BDD framework.

So, if JSTD is not a unit testing framework, and its described as a server, what does it do as a server? JSTD uses a capture url that you can navigate to with any web browser and ‘capture’ the browser so the JSTD server can run JavaScript with it while it is captured. This essentially makes the browser, or browser tab, a slave to JSTD.

Using JSTD

For example, if you started a JSTD server you would run a command on your command line that look something like this:

This would start up a new JSTD server on port 8080. You can double check that the server is running by navigating to http://localhost:8080 in your browser. You should see this page below:

Port 8080 is arbitrary, you can make it any port number that isn’t already in use. Also good to know is that JSTD will also use the next port up, so if you wanted to start a different server type you couldn’t do it on the next port, instead of 8081 you would use 8082. Not common but good to know.

Now that the server is running, the next step would be to capture a browser with JSTD so it can run JavaScript against it. To capture a browser with JSTD simply point your web browser to http://localhost:8080/capture or you can click one of the links in the index page.

Once you capture a browser the count will increase on the page that looks like below, the green bar indicating that you have established a connection with JSTD and the browser is waiting to run tests. This provides a lot of possibilities with the amount of browsers that you can run your JavaScript tests against. You can capture as many browsers as you want and each of your unit tests will be executed on each captured browser. Let me say that again… you can capture as many browsers as you want and each of your unit tests will be executed on each captured browser. This includes browsers from remote computers connecting to your JSTD server. This opens up a lot of possibilities in testing set ups, including using services like BrowserStack which has an API for starting up different browsers in virtual machines and running unit tests via JSTD on their machines. But I’ll get more into that in a different post.

Once you have captured browsers with JSTD you can then run unit tests against those captured browsers.

Configuring JSTD for your project

JSTD uses a YAML configuration file where you can configure a lot of different aspects of your test run.

The configuration file above would be for a simple example, the structure of that project is below to help visualize what the files look like. The locations of everything can be changed, the conf file understands relative paths so you can use paths that start with “../” and it will understand.

The JSTD.conf file lets us define which JavaScript source files to load in the first section named “-load”. This example is written with Jasmine so it is loading the Jasmine library JS file, then the JasmineAdapter.js, which is needed so JSTD can communicate with the Jasmine unit testing library. The lines after the adapter are for the JavaScript production files that you want to test.

The section after the “-load” list is “-test”, here is where you set paths to where JSTD should find unit test files to run. It is also a list so more paths can be added. Or you can make several .conf files that run different sets of tests.

It also has a “-timeout” setting you can set for the test run. You can set it to however many seconds you want to allow your test runs to take. You may have to increase it if your suite gets huge, I haven’t had to mess with it much.

The first line of the conf file is a “-server” setting. This lets you configure the address at which the tests should be run. Although you are using the .jar file to execute the tests you can point it at the server that was started using the same .jar file. It sounds confusing but being able to use the .jar file this way and with the .conf file the possibilities for build set ups is very flexible.

JSTD is very unobtrusive, so you don’t have to add anything to the tests that you would normally write in Jasmine or QUnit, or whatever your usual JSTD-supported unit testing framework of choice is. The spec file and the unit test remains the same, as you can see below, there is nothing added specifically for JSTD.

So without changing any of your unit tests you can start to test across multiple browsers, quickly, with JSTD and be ready to use JSTD in an automated CI set up. The JSTD wiki has examples for basic JSTD integration with Atlassian Bamboo and QUnit.

Running Jasmine with JSTD

Once your project is configured running the tests with JSTD is simple. The following command would run all the tests it found with the configuration specified, assuming the project structure pictured in the image above.

java -jar JsTestDriver-1.3.3d.jar –tests all –config jsTestDriver.conf

This would run the tests and you should see output that looks like this:

Of course if there are any errors the output will also display what you would expect from Jasmine normally, giving you stack trace info and failed test info, like below.

Continuous Integration setups

This example assumes that the CI set up you are using is running on a computer that is also running the web browsers that you will be running your unit tests against. The –browser flag lets you tell JSTD the paths to the web browser executables so it can open the browser and navigate to the capture URL. But what if you’re running JSTD on a headless Linux box and you want to run tests against multiple browsers? To do this you have to break up this command into several steps:

java -jar JsTestDriver.jar --port 4224 --browser open --tests all --testOutput .

This command is performing several steps. First it is starting a new JSTD server on port 4224. Then it is telling JSTD to open the default browser on the computer running JSTD to run the tests on. Next its instructing JSTD to run all of the tests that it can find within the definition of jsTestDriver.conf in the directory where this command was run from because there is no –config flag to define which .conf file to use. Finally, it is instructing JSTD to generate test output, using “.” to indicate that JSTD should generate those XML test reports in the directory where JSTD was run from. When this command completes it automatically shuts down the JSTD server that the command started at port 4224.

This sequence of events needs to be broken up into separate steps if you want to use JSTD to run tests on browsers that are on a different computer, or if you just want more control over the different steps as you prepare a test run in a CI configuration, like a Jenkins set up.

First you have to start the JSTD server. Second, you must automate the process of navigating a web browser to the JSTD capture url for each of the browsers that you want to run tests against. Once all the browsers are captured you can then tell JSTD to execute the tests. Finally, you’ll probably want to shut down the server, or you might want to leave it running, shutting it down at this point is personal preference. I like to shut it down. JSTD makes all of these steps easily separated into different commands.

Start server

java -jar JsTestDriver.jar --port 4224

Run Tests

java -jar JsTestDriver.jar --tests all --config myJstd.conf --testOutput path/to/xml/reports

Shut down

curl http://localhost:4224/quit

These JSTD commands are also easily integrated into CI builds using ANT, Phing, or whatever way your particular CI system lets you execute shell commands. I usually use ANT with Jenkins to integrate JSTD into my automated builds, perhaps another topic for another post.

IntelliJ Setup

There is an IntelliJ and an Eclipse plugin if you want a visual runner integrated with your IDE, or you can just run the tests via the command line using the JSTD commands. I find myself using the IntelliJ runner more, but sometimes I run it via Terminal when I’m also writing and running cucumber.js tests on the command line (another topic for another post).

To use the IntelliJ runner open Preferences and select Plugins from the list on the left of the window. Then press the Browse repositories… button and scroll down to the JsTestDriver Plugin entry. Right click it and select ‘Download and Install’.

Once its installed and IntelliJ has restarted there will be a tab at the bottom of IntelliJ labeled JsTestDriver Server. Click on it to open the JSTD server area. It will have a red bar indicating the server is not running, to turn it on press the green play button in the top left, the bar will turn yellow, indicating the server is running but no browsers are currently captured. The pane has icons for the different browsers, you can press the Google Chrome icon, for example, and it’ll open a tab in Chrome and capture the tab. Once you do that the bar will turn green and you’re ready to test.

To run the tests from IntelliJ navigate to the JSTD .conf file and right click the file. Select the Run option to run the conf file and IntelliJ will run the tests and show the output in the test runner.

Hopefully everything is good with your code and you get a green bar, like below! Running tests directly from IntelliJ is a nice feature to have. I don’t like leaving the IDE if I don’t have to.

JSTD is pretty simple to use. Although there are many command line flags (http://code.google.com/p/js-test-driver/wiki/CommandLineFlags) there are basically four actions you do with it. Starting a server, capturing browsers, running tests, and shutting down. And since it doesn’t require that you change your existing Jasmine, or QUnit tests you can easily integrate JSTD into your workflows unobtrusively and start catching problems in your JavaScript in specific browser environments more efficiently.

The part which isn’t as easily or quickly set up is automating a web browsers to navigate to the JSTD /capture URL so the JSTD server can capture web browsers, which would happen between starting the server and running the tests. In my next post I will go into detail on setting up JSTD to run tests and how you could use BrowserStack’s API to automate capturing browsers and running tests across as many browsers as BrowserStack has available (it’s a lot!).

Feel free to post any questions you have in the comments and I’ll try my best to help!

Download Source

Check the example source code on GitHub: https://github.com/s9tpepper/BasicJSTDExample

Dear Reluctant.js: I have a friend—not me—who’s struggling with a self-identity problem. For the last few years my friend’s handle in various online environments was a phrase that contained the “f-word” (Flash). That USED to be a good thing.  Now it appears there’s a full-fledged exodus–even denial of history—regarding Flash and its contribution to the downfall of desktop computers.  Most of my friends and I have already changed their usernames to remove all references to Flash.  I just wonder if it’s no longer politically correct or acceptable to associate with those describing themselves with the f-word. 

Also, can you help me identify terms that I can suggest my friend use to attract maximum popularity? Some of the usernames I have in mind are “mobile-phil” or “touch-era-phil” but maybe something more specific is good—say,  “html5-phil” or “javaScript-phil”.  What do you think?

Signed
A Once Proud Flasher

Dear Proud,
There’s nothing to be ashamed of except perhaps how all the “good Flash developers” have failed to rein in and stop the “bad Flash” folks (who built the true garbage) from defining Flash’s contributions.  A balanced and sensible look at history will judge Flash as what it was—the most widely deployed and arguably the most successful piece of software in history.  To think otherwise is tantamount to a revisionist’s wishful thinking.

The question remains as to what you name yourself (or your “friend”).  You could simply replace “flash” with “html5” or “code” or “javascript” although, some have tried and there just isn’t an easy way to transition a username like “flashfreaker” or “the flash bum”.  Even conferences face this challenge.  For example FITC, originally “Flash in the Can”, simply chose 4 words they thought were cool—so FITC is now “Future, Innovation, Technology, Creativity”.  You saw a similar thing when Adobe tried to separate Flash from the “Shockwave” brand—“SWF” no longer stands for “Shockwave Flash” but instead means “Small Web Format”.   Ultimately, it’s impossible to hide from your own history.

Despite the challenges in renaming yourself, I’d agree it’s always best to describe yourself in present tense terms and to use words associated with what you want to do tomorrow—not what you did yesterday.  To that end, yes, I recommend avoiding the word Flash when selecting a username.  But picking something that you’ll stick with is as important as picking the right term.

A deeper, more concerning problem, has to do with how you explain what you’ve been doing in the recent past (which can actually exceed a decade for some old-timers).  When you say you did Flash, say it loud and say it proudly.  There is a chance people will impulsively say “HTML5” and then give you a look of pity.  Something more interesting may happen. Instead of discovering an underground society of Flash sympathizers you’ll find that anyone who was in the tech business for the last several years surely knows the score.  In fact, if they’ve been doing cool cutting-edge client-side projects they were almost certainly using Flash.  Sure, it’s possible you reveal yourself to someone who has hated and avoided Flash since its beginning.  With those folks don’t fall into the trap debating (ultimately moot) differences between HTML5 and Flash but rather it’s best to smile and let them feel victorious allowing you to move on to getting some work done.  But please don’t grovel and apologize. Let the next letter serve as a model of how to react.
–RJ

Dear Reluctant.js: All u wineing flash “progmmers”…LOL.  if u had listened to me about webstandrds you wouldn’t be so sucking bad when adobe sux. ppl called me a masocist 4 doing ajax by hand… whos laughing now beotch? –code grocker

Dear “grocker”,
Yes, you win!  I’m sure that’s what you’d like me to say.  Okay: “Flash is dead and now you’re the only one who can help clients.  No one will ever want to hire a Flash developer again.”

Actually, Mr. Grocker, what you fail to realize is that now all those flash “fan boies” are showing up in their jeans and t-shirts and—except for an occasional improved odor—are indistinguishable from you.  In fact, if you see rates increasing because now there’s even more talent in the pool, feel free to thank your local Flasher.

“ur” welcome.
–RJ

Dear Reluctant.js: I’m a Flex RIA programmer (and sometimes I even dabble a little in ActionScript).  The corporation where I work let me take an 18 month sabbatical. I’m back now but no one even works in my department anymore!  I think they forgot to take me off the payroll, but I don’t even know who to contact. What happened? I started asking around and most people’s reaction to the word “Flex” is—“do they still make that?”

Was taking time off a bad idea?  And, more importantly, what should I do now?

Signed
Dude Where’s my Department?

Dear Dude,
I understand the world’s economists are now studying whether your vacation had anything to do with the shit we’re in now.  For many Flex programmers another date which will live in infamy occurred last November (11/11/11) when Adobe abandoned Flex. In the future, however, I’m sure you’ll look back and agree this was the beginning of something better.

The brick wall you’re facing with people’s willingness to discuss Flex is not exhibitive of the expected decline in the demand for Flex.  To the contrary, while I do expect a decline, the demand for Flex will be slow and gradual now that the initial shock has worn off and most folks have moved on.  But make no mistake: there’s a large base of existing code that is providing varying degrees of value—this code may need to be maintained or ported to other platforms.  If played right, you can provide clients with huge value and you with huge dollars.

Deep down I think your question is less “what happened?” and more “where do I go from here?”  Flex developers seeking insight where their future lies should consider taking the good part of a day to read Jesse Warden’s epic post discussing the viability of ExtJS being the next logical step for Flexers.  Sencha’s ExtJS does include very sophisticated components that will allow Flex hacks to hobble together Flexy looking monstrosities but it also lets “good Flexers” crank out powerful web applications.

In some ways the best framework is what everyone else is using.  One of the greatest assets Flexers have is their community. (The same goes for Flash/ActionScripters.)  I think the opportunities to leverage the community are huge.  It’s not as though the JavaScript community will notice if one or all Flexers show up to crash their party.  At best, Flex and ActionScript folks can help solidify more best practices.
–RJ 

Dear Reluctant.js: I guess I’m a bit of a purist.  My mom tells me I kept inventory on my legos and even had a schedule for the potty.  I think that’s relevant to my career in ActionScript because it let me keep everything nice-and-neat.  However JavaScript makes me feel dirty.

Before you assume I’m a Luddite, I should state some of my best friends are JQuery “programmers”.  I don’t have anything against JavaScript… but, no typed variables??!!  I won’t even mention global variables—but who was responsible for that? And now every project uses libraries—many of which depend on OTHER libraries!  It’s come to this: we need additional libraries to manage the libraries we have.  Isn’t there some point where someone will say “this isn’t right—we need a real language?” Can’t people see that? I’m not saying I have a problem with JavaScript—I just think it’s an outrage that it has such extreme flaws.  Some people are fighting back (like Colin Moock’s diatribe “the trouble with JavaScript” ). What else can we do?

Signed
Resigned to JavaScript (but not happy about it)

Dear Resigned,
On the contrary, I’d say you DO have a problem with it!  In the words of Tom Green’s boss “deal with it”. Are we not programmers?  Isn’t the whole idea of programming to figure out a solution?  And really, have you dug so deeply into JavaScript that you can truly say there’s no viable way to produce anything worthwhile?  Before you answer, realize people have built some pretty kick-ass stuff.  Plus the activity going on in JavaScript is moving so fast it’s unlikely you’re on top of it all.

Before you say that producing masterpiece software requires heroic efforts by teams of expert developers, realize that most projects have only moderate demands–they need not exemplify the state-of-the-art.  Your clients might need something simple or something complex—it depends what you’re trying to build.  Programming is just solving problems.  I’m sure you can put on your big girl pants and make something within the confines of JavaScript.

Having said this, I think it’s natural that when you study a language as you have, it’s important to highlight and understand its limitations.  However letting it turn into personal aggression is a mistake.  Here’s a story—I used to be an Authorware expert and I once contracted with a team that had been working full time on a large Authorware project.  They had produced and posted on the wall a list of all the “problems” with Authorware.  I think you’re exhibiting a similar kind of acting out.  Not only do such lists have the risk of embarrassing you later when you see you were wrong… they don’t necessarily help you avoid problems.  For example, saying JavaScript’s globals are a serious problem is silly unless you also point out that programmers can simply avoid the issue entirely by employing one of the many namespace patterns.  Notice if you pick a fight, you’ll get a fight. The master programmer, however, should look to avoid such battles.  It’s best not to fight it.  I’ll admit I had a real problem with the fact that JavaScript is loosely typed.  But I was smart and didn’t try to fight something that was just a fact-of-life.  If you are that hung up on typing I’m sure you can think of a workaround or use a tool/library that addresses this. Plus, check out this list of more than 100 tools that output JavaScript–often via another language entirely.

Finally, as to your point about relying on so many different libraries:  go ahead and write everything from scratch!  In fact, it makes more sense for smaller projects (especially when you’re learning). However, I think you’ll find using a few libraries can certainly help enough to justify the investment learning.  I will say that you’d face an impossible task if you tried to employ everybody’s personal favorite “best practice”.  In that regard, JavaScript is a mess right now… though you are seeing a few libraries surface as accepted standards.
–RJ 

Dear Reluctant.js: I don’t know why it has taken people so long to move on.  The writing on the wall was not exactly difficult to read.  I completely abandoned Flash 18 months ago and haven’t looked back.  I’m not sure if this advice column is helping or hurting the “Flash Holdouts”.

Anyway, I do have some JavaScript questions for you—why do I have to put a semi-colon after a function expression but not after a function declaration?

Signed,
Formerly Flash

Dear Formerly,
I’ll be the last one to suggest folks hold out for a Flash comeback. Whether you evolve beyond Flash today or wait until the last gasps of life are squeezed out of Flash and THEN move on, you won’t be any farther ahead in the great cosmic race of software evolution. It’s not a competitive sport after all.  I suggest folks just do what they can to make money.  There happens to be some real opportunities in Flash (albeit not “websites”). But… Flash folks should be taking every opportunity to suggest alternatives to Flash.  This helps you identify the places where Flash really does have a value proposition.  It may sound backwards but you’ll win either way and you’ll end up with the best solution (the one that withstood challenges from alternative technologies).

As to your JavaScript question, I was going to answer by saying this isn’t a JavaScript hotline but for that try (and, yes, this is real) toll-free JavaScript help hotline at 877-300-2187 http://javascript.pockethotline.com/

However, I don’t know if anyone can answer “why?”  “Why does it work the way it does?” –it just does.  Let me suggest that it’s often best not to ask why—but just to go along with code formatting rules from JSLint unless you know what you’re doing (that is, it works the way you want) and it offers something you can’t easily build another way.
–RJ 

Dear Readers,
I will gladly provide insightful answers to any questions–sincere or silly–that you post in the comments section below.
–RJ 

I gave the standard Director-centric response. “It’s a wind up toy.” I said.

“Get over it,” he said, “You are teaching it next semester.”

I installed the app – Flash 3– opened it and, 15 years later, I finally closed Flash CS 5.5 and walked away.

For me, the five years between 1998 and 2003, were the absolute best years. Nobody really had a clue what the app could do and, as is so typical in this business, we made it up as we went along. Branden Hall, some kid out on the East Coast, was doing amazing stuff with ActionScript. Eric Natzke was exploring Flash as an artistic medium. Hillman Curtis was quietly using it as a story-telling medium. Joe Cartoon put frogs in a blender and showed Flash could be a serious animation tool. Todd Purgason was moving Flash into the corporate market. Lynda Weinman was running FlashForward, which became the Flash equivalent of Woodstock. Local Flash User groups were springing up like weeds and the Flash Player was being installed at an astounding rate.

For me, my move away from Flash started, slowly, when Flash tried to go mobile.

In spite of all of the “Whiz Bang Smoke and Mirrors” presentations Adobe dropped on its Fanboyz at Max and elsewhere, they just never seemed to get it right.

My moment of clarity around that point happened in, of all places, Adobe’s Head Office in San Jose, California in 2009. I had just finished a presentation to the Adobe Education Leaders crew and someone in the audience asked me why I didn’t teach mobile to my students. My response? “I would rather drive chop sticks into my eyeballs.”

I went through my reasoning for that statement in typical academic fashion but the bottom line was something I had been feeling for over a year: There was no consistency of the experience. It changed from device to device and trying to develop a Flash movie that did that was futile.

When Adobe announced it was suspending mobile development of the Flash Player it was greeted with the usual storm of hair pulling, teeth gnashing and self-righteous sputtering. The way it was announced was “bone headed” but for me it was something I had sort of expected and I used my Google + page to explain my ambivalence and how I saw it as an opportunity to learn and teach something new. I also felt, in the immortal words of Yogi Berra, that this was “déjà vu all over again”. As I wrote:

“… A good example is the rise of devices and smartphones and, in a certain way, the death of Flash on these devices. Having lived through, and taught through, a few of these things – the rise of the internet, the decline of print publishing and the rise of Desktop Publishing, the rise and death of the Interactive CD, and the rise of web interactivity and motion graphics – the common factor behind this disruption is not a “new way of doing things”. It is a “new way of talking about it.”

That something “new” crossed my radar in the oddest place … a Flash Conference.

Doug Winnie, former Adobe Edge Product Manager, corralled me at FITC 2011 in Toronto, and asked if I was interested in looking at a new product – code name “Helium” – that was in the process of being developed. He sat me down in a corner, flamed up Helium and, as he handed me the laptop, said, “Tell me what you think.”

When I finished, all I could think was, “The magic is back.”

With the rapid pace of technological change within our industry we tend to have a short-term perspective on new technology. We focus on the immediate and the short-term future, which is dangerous but understandable, considering the pace of change we experience and embrace.

What we don’t tend to have is an historical view of this change. This sort of thing tends to arrive quietly, explode across the industry and disruption takes hold until we get a collective handle on the technology. Back in the late 80’s and early 90’s Digital Publishing literally wiped out art departments, type houses, printing shops, highly skilled trades (Film Strippers, PrePress, Typesetting) and, once the dust settled, a funny thing happened – these guys mostly went back to work once they discovered the computer was a tool and that nothing had really changed other than how we talk about it.

Are you seeing a trend here?

The current debate about HTML 5 and Flash, on this site and elsewhere, is nothing more than our dealing with disruption. Edge, through its use of HTML5, CSS3, JavaScript and so on, gives us a consistent experience across platforms ranging from the 32’ monitor on my desk to touch screen devices mounted in the back of taxis in Beijing to the smartphone in my pocket. How can this be a “bad thing”? The other point I have discovered is moving to Edge or other interactive motion graphics technology from Flash is not hard. The Flash skills developed over the years are easily transferrable to Edge. It is the same way of doing what we have always done. It is just a different way of talking about it.

Still Edge is a hammer . Flash is a wrench. HTML 5 is a screwdriver. They are just tools. This is something the HTML 5 zealots seem to overlook. Whenever one of those guys tells me HTML 5 is the way to go I simply flip them a video and ask them to get it to run it in a touch screen mounted on the back seat of a Beijing taxi crashing around the city. You use the tool best suited to the job at hand and if it is Flash … so be it. If it is Edge … then use it. Something else? Knock yourself out because the bottom line hasn’t changed: “Does it work?”

As I tell my students, nobody cares how you did it. They just care that it works.

So where’s the magic I was talking about? We are back where we were with Flash 3. We have a technology that is disrupting our lives and businesses and, this early in the game, we really don’t have a clue how to use it. Standards are in flux . Clients are confused. We are making it up as we go along and that is fine. It’s the way it worked in the past and is the way it will always work.

Deal with it because, in the final analysis, you have to admit …. Damn this is fun.

–

About the Author: Tom Green has been teaching with the Interactive Multimedia Program at Humber College since 1995. He was appointed to his current full-time faculty position in 2004. He is also the author of over a dozen books published by Pearson Education and Friends of Ed, including such best-sellers as Foundation Flash CS5 for Designers, Foundation Flash CS3 Video, and From After Effects to Flash: Poetry in Motion Graphics, and has produced an online and DVD video training series on Fireworks CS3.

Tom is an Adobe Community Professional, a member of Adobe’s Higher Education Leader Program in the post-secondary area, and a member of the Product Advisory Boards for Flash Media Server, Edge and Fireworks at the Adobe Corporation and the Camtasia Studio Advisory Board at TechSmith Corporation. He is also in great demand as a speaker and regularly does presentations at major industry conferences around the world, including D2WC, FlashintheCan, Spark Europe, TODCON, FITC, Adobe Max, Web Design World, and Digital Design World. He has conducted expert lectures at such post-secondary institutions as the Rochester Institute of Technology, Pasadena Community College, the Central Academy of Fine Arts in Beijing, the University of Wisconsin, the Sloan Merlot Consortium, the EMMA Foundation Master Classes for Post Secondary students in Hamburg, Germany and Toronto, and Red River Community College in Winnipeg.

Along with these industry efforts, Tom regularly contributes articles and tutorials to Layersmagazine.com, webdesign.tutsplus, the Adobe Design Center, and the Adobe Developer Center. His personal site is http://www.tomontheweb.ca.

I thought it would be helpful and informative to provide a brief round-up of what some others have saying on this subject over that time. This is not meant to be a comprehensive overview, but instead a representative sampling of what’s being said and written on these subjects.

The Realities of HTML5

I have read two fantastic posts in particular, about nuances in the consideration and adoption of Flash and HTML5. The first, by Noah Costello, specifically addresses how this shift in technologies is impacting interactive production in ad agencies. He addresses the details of actual implications of HTML5 adoption on agency workflows, budgets, and features. It’s just not an easy set of issues to confront:

Truthfully, HTML5 is a bit of a freight train right now.  The technical details don’t really matter, it has so much buzz and momentum that to stand in front of it and try to influence its path is a fool’s errand.  It will take a little time for it to run its course and for everyone figure out where it fits within the world of advertising and digital campaign concepting and development.

…

[Flash] was a great ecosystem for those involved.  Creatives could come up with big ideas and feel confident they were possible, without having to worry too much about the technology.  Developers were pushed to do some amazing work and often did amazing work on their own, which lead creatives to great new ideas.  One developer invents PaperVision 3D, another one figures out Augmented Reality Markers and next thing you know we have a live Big Foot interacting with you live on your webcam (www.livingsasquatch.com).

…

HTML5 cannot do everything Flash can.  In reality trying to create these sites in HTML5 is more like “Mission Impossible” and most of them would need to be re-concepted from the ground up; with creative and user experience design that was tailored to HTML5′s capabilities.  Could the ’Ethan Hunt’ of HTML5 Development pull it off? Maybe in a few cases, but what would be the cost and what percentage of the target audience will be able to view the site?  I know that with Flash sites, most clients were unwilling to allow a site published in the latest version of the Flash player until it reaches higher that 95% penetration.  Will a WebGL site that 50% of your visitors can use really be acceptable?  And we’ll often get briefs for Flash projects that have as little as a two or three week development timeline. Good luck with that in HTML5.

Ironically, most of the cutting edge, Flash-like HTML5 sites you see these days don’t work on tablets or smart phones either.  They either use HTML5 features that aren’t available in mobile browsers (WebGL), offer poor performance (Canvas),  or the layout and user experience design does not work properly.  This is perplexing since the primary argument for dropping Flash is compatibility on Mobile.

The technology aside, there are other fundamental problems with trying to make one site fit all. Screen resolutions are all over the place. Can you really expect to design something for a  22″ desktop screen that will look good on a 10″ tablet (iPad), a 7″ tablet (Kindle fire) and 3.5″ screen (average smartphone)? You also may not want the same amount of content on your mobile site, as lots of people like to find necessary information quickly and prefer more immersive experiences on a large screen when they’re sitting comfortably.

Costello concludes with real-world recommendations for agencies and developers:

 

• Don’t decide on the technology until you figure out your audience. Is the primary target mobile or desktop? What percent of your audience is on HTML5 compatible browsers?
• Figure out your clients goals. Are they ok with you targeting a smaller audience for the sake of industry buzz and awards? Or are they more concerned with overall reach to consumers.
• Creatives concepting HTML5 sites need to learn more about the technology and limitations.  You can’t assume everything you would have concepted for a Flash targeted site will be possible in HTML5.  Especially if it is running on tablets and smart phones.
• If the goal is a highly interactive site on the desktop that will reach a maximum audience, use Flash.
• If a site uses interactive video and/or alpha channel video, use Flash and don’t expect the same type of experience to be possible on mobile.
• If the site only requires basic animations (think animating layers of a photoshop document) and video in contained players, use HTML5.
• Deep content/copy heavy portals, corporate sites, and blogs should be HTML. This has always been a good rule.
• If the same site needs to work on the desktop and tablet expect less (in terms of interactivity, animation, and innovative UX).
• If the same site needs to work on the desktop, tablet, and smart phones, expect a lot less.
• Be careful not to expect a robust HTML5 site be built on a tight timeline. Extra time will be needed for build and more importantly QA/bug fixes. i.e. Don’t plan on approving creative two weeks before a site needs to go live.
• Understand that not all HTML5 features are created equal. Some work on mobile, but not desktop. Some work on desktop, but not mobile.  WebGL is a good example.  Currently it is not enabled in mobile browsers and Internet Explorer on the desktop.

Another post, from just last month, comes from Philip Donald writing about HTML5 misconceptions. In it, Donald gets into how actual feature differences between Flash and HTML5 should influence tech selection for different projects.

Firstly, HTML 5 offers a very convenient audio and video solution with some advanced functionalities. All well and good, but what many people ignore is the fact that these audio and video files are played within the browsers. Each browser has built-in plugins for audio and video but different browsers support different versions of the audio and video. Because of this, it becomes difficult to cater to the requirements of all browsers.

Secondly, the SVG and Canvas elements have definitely made it easier for developers to implement and integrate 2D animations, but it’s been observed that this animation has a detrimental effect on website performance. Also, HTML5 is proving to be weak when it comes to handling 3D animations, resulting in developers not being able to replicate an entire Flash website with similar efficiency in HTML5. There will always be limitations.

Thirdly, you can use HTML5 Rich Internet Applications, but don’t be under the misconception that they can offer you the same brand of efficiency and functionality that Flash/Flex can offer, for example Flash can directly communicate with remote services, whereas HTML5 cannot.

Now that you know what HTML5 cannot do, allow me to offer you a small list of things that HTML5 can do and, in fact, can do very well. This can also help reduce the misconceptions in a big way.

• You can create a single application that works on the iPad, iPhone, Windows etc. In other words, it facilitates platform/device independency — a huge benefit in itself.
• Helps develop a single website that works on the tablet, mobile, and desktop at the same time.
• If used well and the way it is supposed to be used, it can improve website performance.
• Enables the use of audio and videos tags across all platforms, but be prepared to do a bit of hard work.
• Video, audio and images are all written right into the codes, eliminating the need for any third party software.
• Quicker load time as compared to its older version because of WebSockets implementation.
• Offers great vector animations for graphics and light effect, but do not expect the moon, the sun, and the stars when it comes to animations; Flash is way ahead in this aspect.
• Provides appropriate built-in form validation and type declarations to offer specific keyboard support.

HTML 5 definitely has the potential of upstaging Flash in more ways than one, but it is presently a work in progress. Even in its current avatar it helps make mobile phone applications more accessible, and developers are now able to create universal applications for different mobile phones. Additionally, there is no doubt that it offers more flexibility in website creativity. For now, this is enough. What happens in the future is pure hypothesis.

I think that perhaps no post symbolizes the evolution of the online discussion as much as Long Tail Video’s post about HTML5. Whereas 2011 saw a massive (and often, uninformed) push to HTML5 video solutions, Long Tail Video (the makers of the JW Video Player) presents actual details about video playback features and format support, across browser implementations of HTML5 and HTML5 video. And (thank god) they go to the effort of keeping that post current, with new browser releases. This type of information was simply impossible to come by last year, but is essential to have when making tech decisions.

Adobe

The posts above demonstrate, Flash still supports many use-cases better than any available alternative technology. As just one real-world example, Giacomo Guilizzoni (founder of Balsamiq wireframing software, and better known as ‘Peldi’ to many in the Macromedia and Adobe communities) said in a recent interview that, while:

It’s fashionable to criticize Flash and Air these days, but the reality is that for certain kinds of rich, graphic-intensive, cross-platform applications, it’s still the only serious option.

…

We don’t have any current plans to switch to a different platform. A full rewrite is suicide for a startup, and like I said, our customers don’t care right now. Plus, I don’t really see an alternative right now either, HTML5 doesn’t even have full-screen support yet, let alone a good desktop installation experience or serious IDEs for JS development.

However, in the world of technology, many people make decisions not only on where things are (that is, what technology can do today), but also based on perceptions of where things are going. Flash and AIR, of course, are owned by Adobe, who significantly disrupted the markets for both Flash and AIR last November. Today, half a year later, while much of the discussion about HTML5 and Flash has evolved and become more nuanced, what is Adobe’s influence on explicating or defining a direction for web technologies?

One of Adobe’s primary initiatives around HTML5 is called Edge, which is a new HTML5 animation tool. Edge (for which Adobe maintains three separate URLs, here, here, and here on Adobe labs), though, is still not a released product. Similarly, Adobe is now promoting that the next version of Flash Professional will have the ability to export HTML5 animations. As of today, there is still no professional-grade HTML5 tooling from Adobe — everything remains in the future — leaving the community of developers with continued questions as to how these new tools will actually impact their work.

On Flash (and AIR), Adobe has attempted to reduce uncertainty and solidify expectations as to the direction and future support for the platform. Earlier this year, Adobe published a road map for Flash Player and AIR, reiterating their emphasis on Flash and AIR as a solution primarily for video delivery and gaming.

Looking forward, Adobe believes that Flash is particularly suited for addressing the gaming and premium video markets, and will focus its development efforts in those areas. At the same time, Adobe will make architectural and language changes to the runtimes in order to ensure that the Flash runtimes are well placed to enable the richest experiences on the web and across mobile devices for another decade.

There was “a lot of negative discussion [in the community] around the focus on gaming and premium video talked about in the whitepaper,” according to educator and developer Joseph Labrecque, who penned a defense of Adobe’s positioning of the technology in the document. Still, for a roadmap to be valuable, the markets and community must trust that it is accurate — and, in Adobe’s case, that trust was significantly reduced last November. So, for example, in a pair of recent Tweets, author, developer and community leader Phillip Kerman noted his concern that, despite the representations in its product roadmap, Adobe will drop support for mobile AIR (just as it did for mobile Flash Player):

As a case-in-point, earlier this year, Adobe promoted that anyone could send questions to Adobe CEO Shantanu Narayen (one of the top 10 most overcompensated CEOs in America, according to Mother Jones Magazine) by including the hashtag #askShantanu, and he would answer them in a conference keynote. All told, only six questions were posted. The most direct question was tweeted by developer and community leader, Peter Elst, who asked: “with respect, do you feel you’ve taken enough personal responsibility around the massive communication failure in November? #askShantanu”. As Elst elaborated on his blog:

It is in my opinion time for Adobe as a company to clean up its mess and move on, but to do so it needs to come to terms with the present situation and acknowledge its failures. If nothing else, I expect from a CEO to be willing to step up and defend his position.

At the scheduled event, Narayen did not acknowledge or respond to any of these #askShantanu questions — much less the one from Peter Elst. With this style of leadership emanating from the top of the organization, it is unsurprising that the once vibrant community around Flash (and Adobe’s web products, in general) continues to deteriorate. As Adobe Certified Instructor (ACI) Dee Sadler tweeted earlier this week:

• Flash isn’t supported in iOS devices
• Android is dropping Flash support
• Google Chrome support of Flash on the Mac seems to add new bugs that are out of our control in every new release
• Developers aren’t really excited about doing anything related to Flash

Meanwhile…

While the industry discussion is becoming more articulate, nuanced and accurate, this process occurs more slowly in the broader market. The sophistication of the tech discussion in sales and with clients (unsurprisingly) lags behind what developers know and understand. Earlier this year, Yakov Fain asked if “Will HTML Force You to Lie?”

Yesterday, one perspective customer asked me if we have an HTML5 version of this application. I said, “We can create one for you”. The next moment I realized that I lied and added, “I mean, most of it can be turned into HTML/JavaScript, but some heavy duty stuff we’re doing now would be too expensive to re-create in HTML/JavaScript”.

I didn’t start questioning why they even wanted to do a pure HTML5 version. I know what the answer would be: “Everybody goes HTML5, we want it too, and we want it now”. You can’t piss against the wind. You shouldn’t attack windmills unless your name is Don Quixote.

Clearly (and again, unsurprisingly), it will take more time for these discussions to approach reality. The education of clients often presents unique challenges in software; it is even more difficult in light of the legacy of the HTML5 and Flash discussion from the past two years, and will likely remain so for at least the next year or so.

At the same time, the technological landscape in which all of this is occurring is becoming increasingly fragmented, complicated (and expensive). As just one recent example, the introduction of the pixel-rich iPad 3 has led once again to basic questions (without easy answers) about how to deliver images inside of a browser (something that I think we all thought was resolved over a decade ago):

The problem is simple: you need to send smaller images to small screens and larger images to larger screens. Sending a huge iPad-optimized image to a device with a max resolution of 320×480 just doesn’t make sense. At the same time, when bandwidth isn’t an issue, most sites will want to serve high-resolution content to displays that can handle it.

The ideal solution would be to detect both the resolution of the screen and the available bandwidth. Then, based on the combination of those two factors, the server could offer up the appropriate image. Currently that’s not possible, though there are already proposals to extend HTML to handle that scenario.

The Responsive Image Working Group is a W3C community group hoping to solve some of these problems. The group is proposing a new HTML element, <picture>, which will take into account factors like network speed, device dimensions, screen pixel density and browser cache to figure out which image to serve up. Think of it as a much smarter version of the old lowsrc property. So far though it’s all hypothetical

And, as Amir Nathoo writes, if you are hoping to achieve viral success, you really do need to invest in proper experiences on all of these increasing varied devices. So, supporting all platforms bears increased cost; and ignoring platforms also incurs real costs. As I wrote earlier this year, “a 2012-dollar spent on interactive production will get you less functionality delivered to a smaller percentage of the consumer market than the same dollar spent only two years ago.”

In my inaugural post on this site, I explained that “while there are no clear answers, you can still make informed decisions”. More and more people are learning what variables and parameters influence informed decisions in this climate, and thankfully, some of them are taking the time to share them. In that sense, I think the industry is now moving into another phase. One in which more honest discussions occur, where there is a much less reflexive attitude towards technology evaluation and decisions, and these technologies are increasingly well understood by a wider segment of the industry who, on a daily basis, must confront the challenges of actually executing interactive experiences in a highly complex environment.

And that is most definitely a good and positive trend for the broader health of the interactive industry.