« FlashForward reports | Main | Quick links »
September 24, 2006
Top Anti-Flash Cliches?
Top Anti-Flash Cliches? Can you help expand this list of frequent objections to Adobe Flash technology and their rebuttals? Lots more Adobe staffers are now talking with the public about Flash (video, Acrobat, creative tools), and we're pulling together a one-page cheatsheet of the most frequent complaints, and the best info that can be provided in return. In the list I've already got bookmark/undo, search, filesize, accessibility, proprietary, workflow, security, audience size, standards, copy/paste, all-Flash sites. Do you have other ideas, either of frequent sticking-points when you're talking with people, or ideas you try to convey in response? Thanks!
Bookmark, undo: Browsers navigate webpages. They're not designed to monitor application states. It has long been possible to register presentation states in the URL, and this has recently been enhanced for Flex, but such interface convertions up to the individual content creator, as they deem most useful for their work.
Search: Frequently nonsensical... most high-profile sites use SWF, yet still manage, somehow, to be found. You've got to figure out which typed search terms you wish to target, survey the competition for those terms, and then make sure your HTML shell can be found with those terms. Having every word of bodytext or every database record in the major search engines is not as necessary as good TITLE, URL, keywords, and particularly inbound links, as Googlebombing proves.
Larger filesize: Not for comparable content... the built-in compression and default streaming design often make it faster to deliver. That's for comparable content, though... a presentation with many photographs, and perhaps some audio, will remain larger than a few paragraphs of text.
Accessibility: Not all know that Macromedia Flash Player 5 and above offer dynamic text feeds to screenreaders (overview). The Player's visual controls also offer more accesible viewing. There's also the angle of images, animation, audio and video increasing accessibility to global audiences, and those with varying linguistic or cognitive skills.
Proprietary: This seems mainly a branding/belief issue. Being able to change source code can be helpful in software which runs on your personal machines, but for software which runs on Other Peoples' Machines, we want predictable capability, not unpredictable configurations.
Workflow: Some people don't like timelines. That's just one workflow these days, though. Adobe Flex provides SWF-via-XML, and tools like Adobe Captivate, Breeze, Fireworks and the upcoming video generation all produce SWF as parts of other normal workflows.
Security: Macromedia, Allaire, and Adobe have a long and positive history of addressing potential security issues before they become exploits. Sometimes people interpet the list of security improvements as indicating that the software is intrinsically unsafe, but examing the actual issues shows otherwise.
Audience size: Fewer people may render SWF9 then HTML 3.2, true, but most people don't recognize that Adobe Flash Player is the most widely and quickly adopted software in Internet history. If you're doing simple media and interations then many technologies could work, but as the project becomes more advanced then SWF provides the most ability, to nearly everyone in the world today.
Standards: This is a hard one -- some people believe that technology should first be dictated by a Council of The Best and The Brightest, and then implemented (usually in various ways) by others. There's also the distinction between de jure standards, de facto standards, and mandated standards.
Copy/paste: Whether text can be copied is the decision of each content author. It's possible to have the browser's menu talk to the SWF content, but few choose this extra step.
All-Flash sites: This conversational gambit still comes up an awful lot. A SWF goes in an HTML page, and few sites use minimal HTML... usually SWF is an element in a page, using each technology for what it does best. With modern browsers converging on JavaScript/plugin intercommunication, it's practical to even send messages between the SWF and HTML interactions.
Posted by JohnDowdell at September 24, 2006 1:02 PM
Use of this website signifies your agreement to the Terms of Use and Online Privacy Policy (updated 07-14-2009).