Connect with us


My take on the Flash controversy



Reading all the comments for, against, and otherwise on Adobe Flash on mobile devices have been quite enlightening. I am mostly ambivalent about it, which is why I haven’t come out with a solid position yet. But since everyone else has shared, it’s only fair that I reciprocate.

Flash, Silverlight or other, they’re all plug-ins. Flash is the most popular, but the concept is the same: a separate application running in your browser to view and use content. This is fine for forms of content that cannot be displayed correctly or adequately within a browser. I support plug-ins as a means of overcoming the limitations of a web browser. What I don’t like about Flash and others is overuse, i.e., being used in place of what can and should be done right in the browser.

For example, one thing I really hate are Flash-based navigation menus. Using Flash to display content is fine. Using it to get to content is bad. The problem stems from lack of accessibility. A properly coded HTML page can be translated by an online language translator or read by accessibility software. A Flash menu can’t. It’s not simply an obstacle to accessibility but a hazard, less like not having a wheelchair ramp and more like putting a one-foot high step at your door.

This problem isn’t limited to folks who can’t or don’t read the language. Mobile devices typically have limited screen space and alternate forms of interactivity, such as touchscreens. Mobile web browsers can interpret web pages appropriately for the device. The same can’t necessarily be said for Flash-based pages. It’s not just about scaling but also recognizing input, such as cursor hover when there is no cursor. Adobe is overcoming this with their new version of AIR, but that requires developing Flash apps specifically for the device type. Again, that’s fine for games and apps but not basic navigation.

So basically, I think Flash, Silverlight and other plug-ins have their place. That place, however, is not as an alternative to basic web languages read by the web browser, such as HTML, XML, Javascript and CSS. If I need Flash to run a web app, fine. If I need Flash to read a simple web page, that’s no good. I’m not in favor of dumping Flash entirely for HTML5, but it definitely needs to be reined in. All things in moderation.

Update: Turns out I wasn’t the only one thinking about Flash interactivity on mobile devices this weekend. More thoughts on it from AppleInsider and RoughlyDrafted, specifically about the mouseover issue.




    02/21/2010 at 11:39 am

    and that view on plugins is also the reason why i find myself groaning whenever someone mentions that firefox or similar can just make use of windows media player or quicktime to handle h264 video. End result, it do not improve on the status quo. Heck, its going backwards to when realplayer was the king of streaming media…

  2. GoodThings2Life

    02/21/2010 at 12:22 pm

    I agree with your points, Sumocat. Although, I’d go as far as to say that I don’t *like* Flash or Silverlight, but I accept their need and install them and maintain them for sake of compatibility until better means are available. I also, as a web developer, make it a point to code my sites using real web content.

  3. Corrupted Mind

    02/21/2010 at 12:47 pm

    I am able to agree with you on the point about plug-ins.

    But, I’m a bit worried about those who “display” content dictating to those that “create” content what tools they should use when creating their content.


      02/21/2010 at 1:41 pm

      one thing to keep in mind is that the html5 spec writers expected that one format would not be enough, so they made the video and audio tag flexible enough that one could have multiple stream files within it, and allow the user or browser to select what to show.

      the ogg issue is one of defining a expected minium, so that at least one format can be expected to work any where, any time.

  4. Joe

    02/21/2010 at 1:21 pm

    Yeah, I’m of the opinion that it’s nice to have the option when I want to use it.

    I think what Adobe is doing for mobile devices is sort of incorporating a “Flash Block”-like setup for 10.1 which is nice. Basically, I believe it shows placeholders, and then if you want to use the Flash section, you tap on that to display it. I’ve at least seen that behavior on demos for the Pre, haven’t really watched demos on other devices.

    To me, that’s the perfect way to do it.

  5. PF

    02/21/2010 at 3:41 pm

    Just like in HTML, cursor hovers in Flash are usually used as an extra indication that a screen element is clickable. So most flash apps should work fine on touchscreens.
    The only times I’ve had to use hovers as part of the functionality of an app, has been in banner ads, as clicking anywhere in it is usually reserved for sending the viewer to advertisers site. But since ads have very short lifetimes, a few weeks at most, this is one sector that doesn’t need to worry about legacy issues and will be the quickest to adapt.

    (BTW: It’s multitouch that flash doesn’t support yet, but will probably included in the next version. On the other hand, as far as I know, multitouch is not part of the html5 spec and so it’s an open question as to when we will see native browser support for it.)

    Games that use keyboard shortcuts would pose a problem, but this could partially be solved having a device show a mini keyboard with just spacebar, eneter and arrow keys for example so it doesn’t have to take up too much screen estate.

    While for most sites, creating them entirely in Flash is not a good idea, Flash does have the advantage that it can easily detect the screen size and show an appropriate and possibly an entirely different interface depending on whether you’re viewing the site on a smart phone or on a desktop. I wouldn’t be surprised if the API will also be able to tell you whether the screen is touchscreen or not. It already has such functionality for detecting if audio, mic, camera.. capabilities on a users machine.

    But probably the best reason for supporting flash on mobile devices is that it will benefit everybody, desktops too. It will force flash developers to spend more time ensuring their apps don’t waste unnecessary resources such as cpu and memory.

  6. Bill

    02/22/2010 at 7:03 am

    Just move to Silverlight for Mobile in March. Natively multi-touch enabled. Problem solved.

  7. Bfdonnelly

    02/22/2010 at 7:39 am

    I know that Flash uses a lot of resources, but phones aren’t standing still, while a lot of websites are. I know a lot of architects who use Flash extensively, but who aren’t going to update their sites any time soon. In the meantime, the ability to view Flash may be a deciding factor in some phone purchases.

    I agree, by the way, about the accessibility problem, but that’s a problem endemic to any technique that uses images for navigation.

  8. Chad Essley

    02/22/2010 at 12:35 pm

    Let’s not forget that the reason that a “controversy” around flash has been brewing, is specifically because Apple and Steve J are looking to protect their Itunes video / games and app market.

    Denying any one standard on a platform to protect your revenue, then telling your users that it’s because of lazy coding and crashes is just plain dishonest.

    I agree. All things in moderation. Flash was created to actually address problems with standard html, and do things HTML just can’t do. I’ve seen html navigation that’s terrible, the same way I’ve seen flash navigation being terrible. Speaking of scaling, the vector capabilities of flash are actually a strong point of flash as far as screen dimensions go. Buttons and controls scaling without loss of resolution to fit the display. Something you’d have to make special code and seperate graphics to achieve in html.

    Let’s hope that Apple can support all standards, and give it’s users a choice. I’ll be staying with Android or Windows (or any other OS) until they do!

Leave a Reply

Your email address will not be published.

As an Amazon Associate I earn from qualifying purchases.