On 25 July 2017, Adobe announced that Flash Player would be retired at the end of 2020. The announcement was about the end of a technology—not the end of websites that move, respond or let people explore.
That distinction matters. A business can become attached to the way an experience was built and forget the reason the experience exists. The animation, selector or presentation becomes the thing to preserve, even when the customer needs something simpler: an explanation, a useful choice or a way to ask for help.
Flash’s retirement offers a more interesting lesson than “old technology loses to new technology”. It asks what should survive when the mechanism beneath a website changes.
The history below comes from Adobe and Apple’s published accounts. The interpretation about customer experience is our own. It is not a claim that one kind of interaction guarantees enquiries or sales.
The announcement was a transition plan, not an overnight switch
Adobe’s dated retirement announcement described a changing relationship between plugins and browsers. Its account was that capabilities previously supplied through plugins were becoming available through open standards, including HTML5, WebGL and WebAssembly.
The company planned to stop updating and distributing Flash Player at the end of 2020 and encouraged creators to migrate existing content. It named technology partners involved in the transition, including Apple, Facebook, Google, Microsoft and Mozilla.
Adobe also acknowledged businesses built around Flash in gaming, education and video. This was not simply a matter of replacing a decorative detail. Content and working experiences needed another route.
Our interpretation is that the interesting part of the announcement is the separation between capability and delivery. A particular player could retire while the things people wanted to do remained relevant.
For a website owner, that is the beginning of a better question. Do you need to preserve the exact mechanism, or the useful task it enabled?
A different experience already existed on Apple’s devices
Apple’s WebKit team published its own account on the same day. It stated that iPhone, iPad and iPod touch had never supported Flash.
For the Mac, it described a transition beginning in 2010, when Flash was no longer pre-installed. By the time of that 2017 post, installed Flash was off by default and Safari required explicit approval for each website before running the plugin.
The team also pointed to browser-supported alternatives for video, graphics and animation. Its message was not that rich content should disappear, but that it could be delivered differently.
These statements document Apple’s account of its products and browser at that moment. They do not prove that a particular website lost customers or that one company caused the entire retirement.
The practical implication is narrower and more useful: an experience that works in one viewing environment is not automatically available in another. A design presentation cannot settle that question by itself.
There were two important end dates
Adobe’s end-of-life information distinguishes the end of support after 31 December 2020 from the blocking of Flash content in Flash Player beginning on 12 January 2021.
That distinction is worth keeping. “Flash ended in 2020” is a reasonable shorthand, but it does not explain the separate support and playback milestones.
The company’s notice also explained that updates and security patches would no longer be issued after the end-of-life date. It recommended uninstalling the player.
This article is historical context, not instructions for restoring obsolete software. A business encountering an old dependency should have the actual situation assessed rather than follow a nostalgic workaround.
Our reading of the episode is that a website experience has more dependencies than the visible artwork suggests. Continued usefulness requires attention to those dependencies, not just to the appearance people remember.
What exactly are you trying to save?
Suppose a hypothetical business has an interactive presentation that helps people compare three products. The old implementation no longer works as intended.
There are several possible responses. Rebuild the same arrangement. Replace it with a different selector. Present the three choices plainly on the page. Remove the comparison because the products themselves have changed.
These are not equivalent decisions, and the historical existence of the feature does not choose between them.
Begin with the customer’s task. What did the comparison help somebody understand? Which differences still matter? Was interaction necessary to explain those differences, or was it mainly part of the presentation?
This hypothetical example is not a client case study. It shows why a replacement brief needs more than a request to reproduce the old effect. The useful thing to preserve may be the explanation rather than the interface.
Interactive does not have to mean spectacular
A meaningful interaction can be quite ordinary. A visitor opens an answer, chooses a relevant category or checks the detail of an image.
The test is whether the action changes something useful for that person. Does it reveal information they need? Narrow a real choice? Make the next step clearer?
A moving element can be impressive without doing any of those things. A quiet control can do all three.
This is not an argument against ambitious creative work. A game, demonstration or visual explanation may have a genuine reason to be interactive. The point is to identify that reason instead of treating interaction itself as the benefit.
For an ordinary business page, write the intended benefit in plain language. “Help visitors compare these options” is a clearer starting point than “make the section more engaging”. The former gives the review a task to inspect.
Give the visitor control over movement
Movement changes the conditions in which someone reads. An element that continues moving beside an explanation is not the same as a demonstration a visitor deliberately chooses to start.
The W3C’s explanation of Pause, Stop, Hide specifies conditions for controlling automatically starting movement presented alongside other content. For moving, blinking or scrolling information lasting more than five seconds, a pause, stop or hide mechanism is required unless the movement is essential. Automatically updating information has a related rule without that five-second threshold.
Those are defined accessibility conditions, not a blanket statement that every animation is forbidden or that five seconds makes every effect acceptable.
Our practical recommendation is to ask who controls the encounter. Can the visitor choose when to inspect the information? Can they read without an unrelated element repeatedly changing?
The control should support the task. Making the page busy is not the same as making the customer involved.
A pointer should not be the only route
A design review often happens with a mouse or trackpad. That can leave other ways of operating the page outside the conversation.
W3C’s keyboard guidance describes functionality being operable through a keyboard interface without specific keystroke timing. Its exception concerns an underlying function that genuinely depends on the path of a movement, not merely its endpoints.
This does not discourage mouse input. It establishes why an interaction needs consideration beyond whether it responds to a pointer.
For a business feature, ask how someone reaches the control, understands it and completes the action through the supported ways of navigating. Do not assume that an attractive clickable arrangement has answered those questions.
This article does not certify any website’s accessibility. A few useful questions are not a full conformance assessment. They are reasons to include operability in the brief before the finished presentation is approved.
Do not make an interaction the price of finding the answer
Some information benefits from exploration. Other information should simply be available.
A customer should not need to solve a visual puzzle to discover what the business offers. Nor should a decorative introduction become a compulsory step before finding contact details.
Ask what would happen if the visitor did not use the feature. Would they still understand the main offer? Would the intended next action remain clear?
This is our proposed design test, not a claim that all content must always be visible at once. A detailed answer can sit behind a clearly labelled control when that arrangement genuinely makes the page easier to use.
The distinction is between helping somebody reach the detail and making them perform an unnecessary action before receiving basic information. Interactivity should remove work from the journey, not manufacture work to justify its existence.
Review what happens after the first action
A feature can be easy to begin and confusing to finish. Clicking a choice is only one part of the experience.
What changes afterwards? Can the visitor recognise the selected option? Can they revise it? Does the next step reflect the choice they actually made?
For a hypothetical product finder, a useful result should explain why the displayed options fit the selected need. If the result is merely another unexplained list, the interaction may have moved the uncertainty rather than resolved it.
If an enquiry follows, decide which details belong in that conversation. Do not ask the visitor to enter the same information again without a reason.
These are planning questions, not promises about a particular system or integration. The actual functionality needs assessment. A mock-up should not imply that a connection or workflow has already been built.
The replacement needs an owner, not just a launch date
Useful interactions often depend on information that changes: product choices, examples, destinations or availability.
A business therefore needs to know who will keep the feature accurate. An arrangement that was correct when approved can become misleading if its underlying content changes.
Identify what needs maintaining, how it will be checked and what should happen when an option is removed. This is part of understanding the proposed website, not an optional concern after launch.
The Flash episode does not prove that every contemporary tool will follow the same path. It does remind us not to confuse a working presentation today with a maintenance-free promise.
Our recommendation is to assess the continuing responsibility alongside the initial design. A useful feature should fit the business’s ability to keep its information dependable.
Judge a feature by the task, not its novelty
A new interaction can attract attention. Attention does not establish that the visitor understood the offer or completed a useful next step.
If a feature is intended to help people choose, review whether the choices are clearer. If it is intended to explain something, inspect whether the explanation is understandable. If it supports an enquiry, check the actual enquiry journey.
Do not treat time spent on a page as automatically good or bad. A visitor may be interested, confused or interrupted. The number alone does not identify which explanation applies.
Likewise, a rise in enquiries does not isolate the effect of one design feature without suitable evidence. Record what is known and distinguish it from a plausible interpretation.
The historical sources here do not provide conversion figures. We have not supplied invented ones to make the lesson sound more commercial.
A better brief for an interactive feature
Describe the customer task before naming a technology. Explain the choice or uncertainty the feature should help resolve.
Then identify the verified information it will use, the action a visitor can take and the practical result of that action. Include how the experience will be checked through different supported ways of navigating.
Ask what remains available when the feature is not used, and who will maintain the information afterwards.
If you are discussing a new site or a change to an existing one, see our website design service. Tell us about the required pages, content, design work and functionality, including migration, integrations or support needs. Projects are assessed and quoted individually.
Call 062 61524 or visit the Cashel shop to discuss the requirements. This is not a promise that every proposed interactive feature, specialist application or integration is suitable.
The experience is not the player
Flash Player retired. The need for useful explanation, exploration and choice did not.
That is the distinction worth carrying into the next website project. Technologies are ways of delivering an experience, not reasons for making the customer endure it.
Keep what genuinely helps. Reconsider what merely looks familiar. Give the visitor a clear purpose, understandable controls and a dependable next step.
The strongest brief is not “make it interactive”. It is “help this person do this useful thing”.
Sources and scope
The historical record comes from Adobe’s July 2017 announcement and end-of-life information, and Apple’s July 2017 WebKit account. The accessibility references link to W3C explanations of keyboard operation and controls for moving or updating information.
Hypothetical examples and practical recommendations are Time for Designs’ interpretation. They are not completed client projects, measured conversion results or a full accessibility assessment. This article provides no instructions for installing or restoring obsolete Flash software.