Category Archives: Flash

Attention Web Designers

Please stop doing the following.

Creating external links without a default target=_blank. You might be against it for whatever religious reason, but this doesn’t change the fact that people expect this behavior. I’m looking at you, Reddit.

Unnecessarily modifying the URL as you scroll through a page or highlight text. This makes me have to hit the back button 20 times.

Loading your title tags up with SEO garbage instead of my location on your page. This doesn’t help your SEO, and it makes tabbed browsing frustrating.

Infinite scrolling. Unless you can save the user’s position after they return to the page from clicking something, don’t do this. The user will have to scroll all the way from the top, wasting the user’s time and wasting your bandwidth even more.

Creating floating divs that pop up when you hover over text. I’m trying to read here.

Designing a website to be mobile-first without appropriately scaling up. This is just as bad as making a non-responsive website.

Needlessly using custom scrollbar solutions. These tend to break a lot and suddenly snap me back to the top of the page, or stop scrolling altogether. They also don’t scroll the way the user expects.

Using Hashbangs for AJAX crawling. That is so 2010. There are better ways to do this now.

Making black and white, animated on hover, circular cutouts for your About Us photos. Good lord, this is overplayed.

Outsourcing your blog to Tumblr. This is tacky. And what’s the point? Are you trying to anger the Google Gods? Or has Rails backed you into a corner with bad WordPress knockoffs?

Using slow CDNs. It sorta defeats the purpose.

Requiring users to use an app or sign in with Facebook. I leave every time, no exceptions.

Populating the meta keywords. No search engine since the 90s uses these. All you’re doing is giving the competition a glance into your marketing strategy.

Skeumorphism. No more cloth and wood backgrounds.

Java and Flash. The world really needs to move on now.

Every year, it goes something like this…

CEO: I just read in Forbes that…

2013: …all websites should be written in Scala. Let’s rewrite our Java to Scala, by next week.
2012: …relational databases are dead. Let’s migrate 30 years of data to MongoDB, they’ll be around forever.
2011: …all websites should use responsive design. Make it pop.
2010: …all websites use Ruby now. Let’s hire Rails experts; there should be tons of them, and willing to work cheap.
2009: …millennials only buy through social media. Let’s make a Tweeter, whatever that is.
2008: …SEO is the future. Let’s buy tons of backlinks, spam up blogs, and set up microsites. No way this plan will fail.
2007: …all websites should be web 2.0. Let’s market ours as web 3.0!!
2006: …all websites should use Flex. Let’s rewrite our entire website in Flex, but don’t use any Flash.
2005: …all websites should have a blog. What, you mean we have to pay someone to write articles for it?
2004: …all websites need an RSS feed. Content? What’s that?
2003: …IE won the browser wars, and no other browser will ever compete. Let’s only write for IE now.
2002: …ASP.NET is going to revolutionize the industry. This is how all web applications should be developed.
2001: …we need a Flash landing page to sell customers on our branding. Make it so.
2000: …e-commerce is the future. Let’s sell pet food online and advertise at the Super Bowl, this is going to be HUGE.

Thoughts on Flash

Yeah, I know I’m a little late to this discussion.

It’s been two and a half years since the famous Steve Jobs letter, and the web has definitely seen some changes because of it. jQuery has replaced most of the incidental interactive uses of Flash. Many canvas IDEs have started popping up on the market, though many are in their infancy. Video and audio tags have become popular fallbacks for Flash video, though they have not replaced Flash due to H.264, MP3, and IE8. Some tools, like Google Swiffy, exist to help facilitate the conversion of assets from Flash to HTML5, though they are slow and rudimentary. IE9 marks the return of Microsoft finally taking web standards seriously. Nearly all games are still made in Flash, but everything else has seen a significant drop in Flash use.

Bottom line on all this? HTML5, as a Flash replacement, has gained some real momentum, but it is still woefully lacking in most ways. A/V tags have caught on as fallbacks only, if at all, due to the standard’s inability to support DRM technologies and fullscreen modes, as well as the spotty format implementations that cause some serious production considerations. jQuery, though a great replacement in many ways, lacks a lot of the advanced keyframing, masking, 3D, etc. that really made Flash captivating. Canvas, though growing by leaps and bounds in Webkit, is still unsuitably slow in most web browsers and mobile devices, often incapable of a consistent 30fps for games that would easily get 300fps in Flash. The latter begs the question: is the V8 Javascript runtime the savior of HTML5 like we think it is, or is there still more work to be done? A lot more?

Here’s a real world scenario for you. You have a client with an animation and video-intensive project for you. They want it to run on IE8, Firefox, and iPad, among others. Simple, right? Well, no. here’s the situation. IE8 has no canvas support. iPad has no Flash support. What technology do you use to create the animations, and what technology do you use to play them? Guess what, I’m faced with this problem right now, and many others have also. The answer usually ends up being, you can’t use animation, and you have to double up on video formats. For this particular project, not using animation wasn’t an option, so the solution we came up with was: Flash as an animation IDE. Swiffy to create HTML5 fallbacks. Flash and H.264 for video, canvas as a fallback, Flash as the fallback-fallback for absence of H.264 support. Why is this so stupidly complicated for such a simple thing? Microsoft and Apple, that’s why.

As much as I dislike Flash, I don’t really see it going away anytime soon. More like what happened to Java applets; you see fewer and fewer as better technologies become more capable of replacing it (Flash). This is already happening with Flash, but Flash is still a lot more suited for certain projects at this time. Just off the top of my head, here are a few pointers canvas could learn from Flash:

  1. IDE is king. Flash is two things: a runtime plugin technology, and a development environment. Canvas currently has no de-facto, and what is available is not fully-baked yet. Creating animations in Flash was so easy. In canvas, it usually means a Javascript nightmare to get something awful-looking.
  2. Sub-pixel accuracy. This was in Flash from the start, and so well-integrated it was a little annoying. But useful. Maybe this can be done in WebGL at some point, but right now I don’t think it’s possible.
  3. Speed. Really, this should be at the top of the list. Speed, people. Get it together. We want fast frame rates. No tearing. No lag. No major browser inconsistencies. If there’s a problem with Javascript, then it needs to be solved.
  4. DRM. Sure Javascript can be obfuscated, but there needs to be ways to protect media from getting jacked, if so chosen. This is easier said than done with the way the internet works, and I’m aware of that, but it would be nice.
  5. Asset containment. It would be nice to be able to shove all data into a single binary, instead of having PNGs, MP3s, etc. scattered all over your server and needing to be downloaded individually. Maybe the canvas IDEs of the future will have the option of base64’ing everything, but that may make the problem worse (filesize and whatnot).
  6. A/V synchronization. Flash can be easily synced so that animation and music don’t go rogue. Also, ways to read audio levels to make interactive queues, and ways of generating custom audio during runtime. Not sure if there’s a way to do any of this in canvas. Doubt it.
  7. 3D. Okay, so WebGL. The other browsers need to get with it, because Flash seems to be years ahead on this. How it will compare to Flash remains to be seen.
  8. A common binary runtime. This is the only way canvas will ever be nearly as fast as Flash. Right now, your runtimes have to be written in Javascript. Every IDE has their own. What if there was a binary runtime to hook into, that every browser supported? Oh wait, I guess that’s what Flash is, and what canvas will never be. Heh.
  9. Compatibility. Not really canvas’s fault, but not even half the web supports canvas. IE8 and below, plus mobile devices are still far behind… and when they do support canvas, they’re too slow. Flash, even if its mobile forray was short-lived, at least had a faster implementation than canvas.
  10. Camera and microphone support. Seems like Chrome might implement some of this, but as far as I know there are no common APIs for this like there are with GPS.

And I could go on. Some of it is nitpicky, I know, but a lot of it is incredibly important to designers and animators.

Bottom line, it’s unfortunate that the late Steve Jobs felt it necessary to start a war over two technologies that aren’t necessarily mutually exclusive. In a way, I’m glad Flash has gone back to what it’s supposed to be (a runtime for when performance, presentation, compatibility, and heavy dependence on animation and object-oriented programming), but it saddens me a little to see the web step a few years back in time, in order to bend over backwards for mobile devices. The result seems to be that the web is a more boring place, and canvas so far has failed to solve the basic problems it claimed it would.

Here’s how I see the future. Eventually, Adobe will make Flash capable of compiling to canvas directly. That way, canvas will be available as a fallback for when Flash isn’t available. If that doesn’t happen, eventually converters will get better, or Adobe will come up with a new IDE. And no, I’m not talking about Edge, Hype, or Muse. Please, Adobe, no more garbage toys; give us what we want. But anyway. At any rate, we’ll likely continue down the path of Flash really finding its niche, and browsers continuing to offer no real solutions to canvas’s shortcomings.