This all-Flash interface (screenshot) is a complete reimplementation of the WordPress blog interface; One single Flash widget fills the entire browser page, and implements not only the home page, but categories, comments (including posting), and article pages. It sounds like the author intends to use it to replace the HTML interface to his blog entirely. It’s a great example of why you should never build an entire website purely in Flash.

I don’t intend to pick on this demo Flash application in particular; I’m sure it was an interesting and useful technical challenge¹. There are lots of websites that use Flash for all, or most, of their interface. And using Flash to build the majority of a website is Wrong, with a capital W.

There are things that Flash is good for. Games. Video. Google finance. Embedded widgets. Weird interactive sites that make no sense. Replacing HTML, CSS and JavaScript and showing images, links and text content is not one of those things.

Why not? In no particular order:

1. Users can’t (usually) right-click on a link and open it in a new tab, or window. This example has a small right-click menu, but it doesn’t match the context menu for any browser under any OS.
2. Users can’t copy content and paste it into an email, a comment, or into their own blog to respond. Preventing users from copying text is not a feasible way to protect your content; Arguably, if you don’t want people quoting your content, don’t put it on the web.
3. Users can’t (easily) save embedded images. Preventing users from downloading images is also not a feasible way to protect them. Again, if you want to protect your content, don’t put it on the web.
4. Most Flash webpages don’t let users bookmark specific “pages.” This one is using a URI fragment trick (similar to what I’m doing on Spydentify) to generate bookmarkable “pages.” I have returned to all-Flash sites that I knew were selling something I wanted to buy, and given up rather than re-navigate through all forty-three pages of products to get to the page with the product I want.
5. The scroll bars don’t work like the native OS’s scroll bars. Native scroll bars on all OSes have the arrows in predictable positions. They show at a glance what percentage of the viewport is visible. Clicking in the empty part of the scroll bar scrolls the viewport in that direction. If you’re reimplementing a scroll bar in Flash, it will be a lot of effort to match the OS’s behavior, and I’ve never seen one that even gets close. Can you find the scroll bar on the screenshot above? Novice users might not even notice that the Flash app has a scroll bar.
6. The scroll wheel, if does anything, almost never scrolls the Flash app at the same speed as native scrolled windows. This is confusing, and it either makes the page seem slow, or makes it scroll too fast.
7. Keystrokes almost never work as expected. Page up and page down should scroll whatever iframe, text area, or overflow:scroll region has focus. Tab should tab through links. Enter should select links. If you make users reach for the mouse, some of them are going to use it to click on the back button.
8. Inline search (in Firefox and Safari) doesn’t work. Laugh all you want, but if I’m searching for something, and I follow a link to a page and inline search doesn’t turn up my search term, I’m gone. I don’t have time to read the last fifteen articles on your blog to find out if you really wrote about underwater basket-weaving.
9. Buttons, form fields, checkboxes, and other elements don’t look like, or work like, the native OS widgets. Sure, Windows XP has some damned ugly checkboxes. But lots of people (who don’t spend all day drawing prettier checkboxes) aren’t going to realize that that thing you drew is a checkbox. People know what to do with native widgets. Use them. Don’t make your users think.
10. Users can’t scale the font size up or down. The user’s minimum font size setting is useless. You might be a eagle-eyed graphic designer with a high-contrast, thirty-inch flat panel, but your grandmother can’t read a word of your beautiful site on her eight-year-old monitor.
11. Flash is slower than HTML everywhere, not just on the iPhone (and it’s really slow on Linux). You might be a high-powered graphic designer with an eight-core, next-generation Mac Pro on your brushed-steel desk, but unless you’re also a very generous grandchild, your grandmother is is waiting five seconds each time she scrolls the Flash “page” or clicks on a Flash “link.”
12. Screenreaders and other accessibility tools Just Work™ with HTML. In Flash, you have take extra care to make them work.

Next, is there anything that Flash lets this designer do that he couldn’t do with JavaScript & CSS?

1. The progressive page loading effect? I’ll put aside whether this is a good idea or not (it’s not; it makes the page feel slow). This could easily be done with JavaScript.
2. Fancy scroll effects? The page slows slightly as it stops scrolling. This one makes the page feel slow too. You can do this with JavaScript and the onScroll event handler.
3. Fancy delayed fade-out when you mouse over links? You can do this with JavaScript and onMouseOver/onMouseOut events.
4. Fancy animated effects when you hover over the four header links? These could be done by replacing an image with an animated GIF when you hover over them. (Don’t like animated GIFs? Try aPNG, in a year or so.)
5. Fancy animation in the page header? I had to pop epilepsy pill when I saw that animation, but if you really want to do something like that, you can, again, use an animated GIF.

Using a high-quality font, like Gotham, that most users don’t have on their system, is the only thing that you can’t do in HTML & CSS. Only WebKit supports² CSS font-face style that links to downloadable fonts. (Microsoft should be motivated to add this support to Explorer to mitigate one more advantage from Silverlight’s competitor. And Firefox should add it because it’s in the CSS spec, and they’re just nice like that.) And it’s not clear how downloadable fonts for webpages fit into typeface licensing agreements anyway.

So, to recap, we have twelve reasons why you shouldn’t use Flash, five things that people usually do in Flash that can actually be done with JavaScript, CSS, and animated GIFs, and only one solid benefit, having total control over fonts, to using Flash. Does total control over fonts outweigh the twelve reasons not to use Flash? No.

Sorry to break it to you, but your Flash website sucks.

1. Update 2008-03-15: In response to George Coltart at Number Eight Wired, the author of the Flash WordPress interface mentioned above: you seem to have misunderstood this post as some sort of personal attack, which it is not. Rather, it is a complaint about all Flash websites, of which there are many. I chose your Flash site as an example only. I found your Flash site via your post on Typophile, where you explicitly ask for feedback on it. [↩]
2. Update 2008-03-17: Thibaut Allender pointed out that Microsoft implemented downloadable fonts in Internet Explorer as far back as 4.0. Technically, this is true, but the font files must be in the proprietary EOT format, rather than in any of the three the industry standard formats TrueType, OpenType, or PostScript. In fact, Netscape also support(ed) downloadable fonts as well, but again only in the little-known TrueDoc format. This doesn’t count. Imagine if IE, Firefox, or Safari announced that they were going to support embedded audio in web pages, but instead of supporting MP3, AAC or WAV audio, they were only going to support an audio format that nobody had ever heard of. The web would scream bloody murder and nobody would use that format. Safari’s font embedding supports the industry standard TrueType, so it’s the only support that counts. Read more about this issue here. [↩]