This is precisely what I am talking about. We slice the pear in the middle and somehow end up choosing one side over another. True, a:hover is a deprecated form of menu control in HTML, but it is in Flash, too. Again, how you use the tool. Damning an entire developer base based on miscreant use is not a compelling argument. Sorry, but it isn't.
That's being a bit generous in favor of Adobe - the majority of the Flash development sphere is practically what one would consider "miscreant use".
Here's my impression of the different sorts of Flash use, based on my journeys on the web:
- Videos/Audio: Easily replaced by HTML5, and better too. More readily hardware accelerated, behaves as part of the core browser instead of a hijacking addon (e.g., Ctrl+T while focused on a Flash applet = no new tab), and much better battery life on mobiles.
- Crappy restaurant websites and other crimes against humanity: These should just die, and HTML5 will hopefully inspire better design ethic than this. I don't buy the argument that hovering is no longer common used as a critical navigation feature in Flash - I see it everywhere, especially for crappy restaurant websites. Flash is also impossible to crawl which reduces the usefulness of the web overall. Hell, you can't even LINK to content in a Flash site. IMHO the "full Flash site" (as opposed to Flash being a component of a page) needs to die a fiery, painful death.
- Games: The only place where Adobe has even a remotely legitimate claim that Flash is an empowering product rather than a crutch.
When I think of Flash these keywords come to mind: slow, buggy, crashy, badly designed, usability nightmare, gimmicky, unprofessional, and just plain bad.
The vast majority of websites in general are poor. It would be no surprise to see that the majority of Flash sites would also be poor. Both sides have exceptions, though.
> Videos/Audio: Easily replaced by HTML5, and better too. More readily hardware accelerated, behaves as part of the core browser instead of a hijacking addon (e.g., Ctrl+T while focused on a Flash applet = no new tab), and much better battery life on mobiles.
I don't disagree. I am grateful that HTML5 can handle this, but it took a "standards" committee several years to roll this into a questionably viable model. The immediate fanfare for the slow implementation raises my eyebrow a bit. We're all happy about having something we've needed for years. The company that created the fold so we could have sites like YouTube today? The devil.
> - Crappy restaurant websites and other crimes against humanity: These should just die, and HTML5 will hopefully inspire better design ethic than this.
It won't. Cheese is forever. If HTML5 can accomplish cheese, people will create cheese. We're all hopeful, but the human condition comes into play.
Example: We just wrapped up Restaurant Week here in Seattle where a bunch of local establishments offered up prix-fixe specials for a couple of weeks. The website for this event was done up all in Flash, and made it impossible to crawl for a search engine, or even to link or bookmark a particular restaurant for later retrieval.
What did we exchange for this cheese and gimmicky design? Everything.
There's no regulating for good taste - you're right, most websites in general are poor. They, however, are still accessible - neon green text on black background with an annoying MIDI track in the background is still information that:
- you can link to
- you can bookmark
- you can copy and paste
- you can search for in-browser (doubly important if the website fails at layout, e.g. most Flash sites!)
- you can search for on Google/Bing
Those are pretty important.
I agree that if you don't follow the proper protocol you will end up with an undesirable site. I can't argue that Flash == HTML in terms of accessibility. There are ways within Flash to harness some accessibility but it is up to the developer to implement these. An informational site in Flash is a bad choice. I would never suggest the use of Flash for broad use. A fun site (like http://www.myspace.com/fanvideo) is more appropriate.
> - you can link to
> - you can bookmark
Named-anchors and proper implementation (same as AJAX RIA)
> - you can copy and paste
"Selectable text" is an option in any Flash text field.
> - you can search for in-browser (doubly important if the website fails at layout, e.g. most Flash sites!)
> - you can search for on Google/Bing
Flash exports text within to the container. Google also can search SWF.
> Those are pretty important.
Agree.
Is copying/pasting it to the OS (or app) pasteboard an option? If so, will it use the same UI as native apps have? Or will it force a funky widget of its own in the middle of an app that otherwise looks like the rest of the OS?
I'm only asking because I've never had copy/paste from flash work well on the desktop.
So if you're going to have a Flash-y data visualization component, say, it's easiest and most natural to have the controls for it (buttons adjusting parameters, display of those parameters, navigational controls) made in Flash too -- just expand the content rectangle of your Flash component out and drop in the controls.
In HTML5, the 'environment' of the <canvas> object is that of the surrounding HTML page. Adding buttons and other controls around the edge of your visualizer is most straightforwardly done by using "native" HTML <button>s and other such elements.
So it would be surprising to see <canvas>-using pages end up being done in a way where the <canvas> is essentially the whole page — it would require more programmer effort — whereas in Flash that's by far the easiest way to do it.
I will be the first to admit there are a lot of poorly designed Flash sites, but from an interactive design perspective, Flash still gives you the most freedom to create more innovative ways for user interaction. IMO this isn't something that should be dismissed so quickly.
// note: Deleted this comment and readded it, since I originally replied to the wrong comment. Whoopsies.
What's your battery life playing an intensive game or using a processor intensive app?
We do other things on the iPhone. I don't want to make the choice between watching a video and then restricting my own usage just so my phone has enough juice to make a call. I'd rather watch videos and use my phone, and the more power efficient everything is, the more the user can do this.
To put it in perspective, if Apple's numbers are to be believed, running Flash alone doubles the power consumption of the device. That's insane.
> "With that I answer: a:hover {}"
a:hover is no longer (it certainly used to be) a common tool used for site navigation. Which is to say, rollover dropdown menus are out like parachute pants - it's a non-issue on the web today. Just about every site works with "clicks", which is Apple's primary form of interaction with websites on touch devices.
The most compelling argument made though we've already been aware of for some time: cross-platform toolkits encourage lowest common denominator design. In Apple's world of pixel-perfect mockups and obsessive attention to detail this is abhorrent - and I'm inclined to agree. The iPhone's chief strength is its remarkably polished user interface - which for the most part remains true across its 3rd party app sphere, thanks in no small part to Apple's obsessive HID enforcement.
A Flash-compiled-to-iPhone app destroys this in the same way that a Linux Qt app hastily ported to Windows is the same.