There are many Flash only websites out on the internet, and although some can be quite well built, there are still problems that should restrict its use.
Despite all the issues I have with Flash, it is useful. Perhaps not for building the whole website, as I will discuss later, but for:
I am sure there is many more good uses, but it should be a case of using the correct tool for the job.
How visitors will get to the website is usually the first issue.
As many visitors use search engines (even to type in a domain name), the search engine needs to know about the website and its content... and they do this though the use of spiders.
Unfortunately most search engine spiders completely ignore Flash, although some do have the ability to extract "basic text" from Flash.
The reason the search engine spiders are limited to the "basic text" is because text stored in images (to make the text "pretty") and Flash files which pull in content from external resources, put the content out reach, and cannot be indexed.
So, if the search engine spider cannot index the websites content, then it cannot determine the subject of the website. And unless there are lots of good quality links pointing to a website, a search engine will never consider the website to be "relevant" to a standard search query.
Taking the user has found the fully Flash website, then its quite likely the first thing they will see is a loading screen.
From previous projects I have worked on, a typical Flash website should expect to loose about 15-20% of the visitors when they see a loading screen. I can only presume this is because users associate the loading screen with previous bad experiences of other Flash websites.
In contrast to a Flash website, a HTML webpage does not (typically) have loading screens, and as such, the visitor can begin interacting with the page before it has finished loading. This might explain why users can be more forgiving with a slow loading HTML pages, as they get to see content quickly, and before it has loaded in its entirety.
The next step is for the visitor to actually use the website.
Flash is a very powerful tool when it comes to giving designers exactly what they want... and that can be the problem. Designers are very clever and create wonderful designs that "engage the visitor", but they typically like to be different, they like to try something new. This is great for websites like JKRowling.com, where the visitor is invited to explore the site... but for most websites, visitors just want to get on with it.
For example, if animated navigation bar is used, the visitor is expected to learn how it works. Ultimately the website visitor could misunderstand it, make a mistake and get lost. And a lost visitor will quickly become frustrated, then if there are no standard interface components to help the user orientate themselves, there is little stopping them from closing the website.
Remember the wonderful Jakob's Law: users spend most of their time on other websites. If something as simple as a navigation bar requires instructions, then there might be a problem.
An area that Flash has problems with is standard user interface components, which includes things like text fields and scroll bars.
Text fields, drop down menus, check boxes, etc, all have to be created within the Flash file, they are outside of the browsers control, and as such, do not get (by default) the features visitors expect. For example, in a text field, trapping of the "select all" command for copy/paste is flaky, the ability to tab to the next control is unreliable, spell checking probably does not work, and the field usually has a custom look and feel... a common issue is that visitors don't know how to interact with Flash based forms because the fields don't look like the fields they are used to.
Perhaps another example of a custom component is the scroll bar... it's very common to see a scroll bar that does not work with the mouse scroll wheel (see flash paper as an example)... how can this be considered acceptable?
If a visitor loads a page which is not relevant, they should be able to quickly return to the previous page by using their browsers back button.
This is very important, as the back button is one of the few controls which is available on all websites... although its technically possible for a Flash website to provide their own custom back button, it cannot be expected of the visitor to see and use it.
If a Flash website is built using one main file (most Flash websites are), how are people expected to link to a specific page within the website?
In the case where the visitor wants to tell their friend about a really good page, they should be able to copy the address from their browsers address bar, and simply send it to their friend over email, Instant Messenger, etc. They should not then be required to provide further instructions how to get to the relevant page.
Also, it should be noted that the links within Flash movies are not really links, they are "hit areas" which follow some custom code... this is important, as it's outside of the browsers control, and as such, stops the user from performing the usual actions that can be done with a link... for example, right click and open the URL in a new browser tab.
As a general rule "make Flash the destination, not the way of getting there" - ref Nick Livingstone.
It does seem to be quite a small group of people who don't have Flash, but they do exist. Take a large company as an example, where each computer can be locked down so extra software cannot be installed. Typically this is to guard against malware. But ultimately a Flash only website will always exclude some visitors/customers.
Because Flash is continually active, it makes it really easy to create distractions like animations. These are great if the websites author wants to attract the visitors attention... but if the visitor is trying to read some text, they might get distracted and decide to move on (instead of reading the important content).
As an additional example of developers having too much control is though the use of background music. Don't do it! Many visitors may already be listening to music, music that they like. If a website starts playing music, the first thing the visitor is likely to-do is either leave, or go for the mute button on their computer. True, there might be a 'music control panel', but most visitors don't even look for it, as it could be anywhere (if one even exists). The only time visitors expect music is if they have actively requested a movie or sound track and have pressed a 'play' button.
Yes, Flash can be made accessible to screen readers, keyboards etc... but it seems that very few developers use any of the accessibility features, even though they are quite powerful.
The same is true of some HTML developers, who manage to create completely inaccessible websites. But ultimately its harder to get it wrong in HTML, as most of the accessibility features are enabled by default and just need a bit of thought to pull them together - like being able to resize the text with the browsers native functionality.
With Flash, it is too easy to only think of the visitor with the mouse, who has perfect vision for the fixed 10px fonts, who are able to read fast enough before the text disappears, without being distracted by any animations.
Ultimately, if you are going to create a Flash website, you will need to create a Flash alternative. This is to avoid discriminating against people who cannot install or use the Flash plug-in (e.g. corporate users and search engine spiders)... and this usually means creating two websites, which can double the cost of development.
An alternative to creating the whole website in Flash, is to create a simple HTML website, and add Flash when it is relevant... as discussed at the beginning of this article.
This means that the correct tool for creating websites (HTML) is being used, and the elements within the page (Flash, images, links, etc) are created with the correct tools.
Any feedback would be greatly appreciated, I don't include comments due to the admin time required, but if you email me, I will reply and make appropriate updates. Also, if you would like to take a copy of this article, please read the terms this article is released under. This article was originally written Thursday 23rd November 2006 and was updated on Sunday 9th September 2007.