Advanced Interactive Design: Final Website

on

Advanced Interactive Design: Final Website
06/06/2026——31/07/2026
GeXianjing / 0377636

Kids’ Safety Guardian

Final Website Process Documentation

1. Project Overview

Kids’ Safety Guardian is an educational interactive website designed to help children learn basic home-safety knowledge through exploration, animation and simple decision-making activities.

The idea came from my Task 1 proposal. I noticed that children are often taught safety through repeated verbal warnings, posters or text-heavy materials. These methods may explain what is dangerous, but they do not always help children understand what might happen after an unsafe action.

Therefore, I wanted to transform home-safety education into a small digital adventure. Instead of reading a long list of rules, children enter a virtual house, explore different rooms, discover hazards and receive immediate animated feedback.

The primary users are children between approximately five and thirteen years old. Parents are the secondary users because they can explore the activities with their children and reinforce the same safety habits at home.

The final website includes:

  • Opening and loading pages

  • Main homepage

  • Explore House page

  • Kitchen safety activity

  • Bathroom safety activity

  • Living-room safety activity

  • Safety Tips page

  • Parent Guide page

The website was developed in Adobe Animate using the HTML5 Canvas format and exported as connected HTML and JavaScript pages.


https://www.canva.com/design/DAHLziTXcnE/YERJP25tzoDfEhc6OGE8IA/view


2. From Task 1 Proposal to a Detailed Production Plan

My Task 1 proposal established the main concept, target audience, visual style, colour palette and possible interaction ideas. However, many of the animations were still described broadly.

Before starting the final production, I reviewed each page and created detailed handwritten notes over my interface designs. I used arrows, circles and short descriptions to identify:

  • Which objects should move

  • Which areas should be clickable

  • Where the animation should stop

  • What should happen after a click

  • How the user moves to another page

  • How correct and unsafe actions should be shown

  • When warnings, cards or buttons should appear

This planning stage helped me turn the website into one connected journey:

Enter the website → meet the characters → explore the house → identify hazards → watch the consequence → learn the correct behaviour

At first, I imagined many decorative animations. When I began planning the timing more carefully, I realised that too much movement could distract children. I therefore divided the animation into three purposes.

Environmental movement creates atmosphere, such as moving clouds, floating circles and small character loops.

Interaction guidance shows the child what can be clicked, such as bouncing arrows, pulsing buttons, hover changes and shaking danger objects.

Learning feedback explains the result of an action, such as steam from a kettle, a child slipping on water or falling from a sofa.

This made the final experience more organised. Every important movement needed to support the story, guide the user or communicate a safety message.










Figure 1. Hand-drawn interaction planning , clickable objects and animation timing.

3. Visual Asset Preparation

After finalising the website flow, I began preparing the visual assets.

Rather than importing each character as one complete image, I separated the child and dog into smaller movable parts. These included:

  • Head and hair

  • Facial expressions

  • Body and clothing

  • Arms and hands

  • Legs and shoes

  • Different walking, waving, sitting, jumping and falling poses

This process took longer than expected because even a short movement required several carefully organised parts. For example, the child needed different arm positions for waving and falling, while the face needed separate versions for blinking, smiling and reacting to danger.

I also prepared multiple dog poses to create walking, blinking and tail-wagging loops.

The backgrounds and interface elements were separated as well. Trees, grass, bushes, clouds, the sun, navigation text, dialogue panels and buttons were kept as reusable assets. This allowed me to animate or revise one element without rebuilding the entire page.

The final artwork continued the pastel visual direction from Task 1. I used soft pink, green, yellow and blue colours to create a friendly learning environment. Stronger orange and red accents were mainly reserved for hazards and warning feedback.


Figure 2. Character sprite sheets and interface assets separated into expressions, body parts, buttons and environmental elements.

4. Building the Website in Adobe Animate

I built each major section as a separate Adobe Animate HTML5 Canvas file.

Inside each file, I organised the content into layers for:

  • Background

  • Characters

  • Navigation

  • Dialogue and information cards

  • Interactive buttons

  • Sound

  • Action code

  • Invisible clickable areas

Repeated elements were converted into symbols and Movie Clips. I used a combination of motion tweens, frame-by-frame changes and JavaScript-controlled timeline movement.

After publishing, Adobe Animate generated HTML pages, JavaScript files and sprite-sheet atlases. The files use CreateJS structures such as MovieClip, Tween, ButtonHelper, canvas scaling and event listeners. The exported pages also contain responsive canvas functions that resize the stage proportionally when the browser window changes.

One important lesson was that every interactive object needed a clear instance name. If the code referred to an incorrect name, the button would not react. During development, I gradually replaced unclear default names with more recognisable names connected to their functions.

Because each major section was created as a separate HTML5 Canvas file, I needed to connect the pages using JavaScript.

I added clickable navigation elements that open:

  • openingpage.html
  • loading.html
  • mainhomepage.html
  • housepage.html
  • safetytip.html
  • parentguide.html

5. Opening, Loading and Homepage Development

The opening sequence introduces the playful personality of the website.

The pink circles move around the background while the title enters the screen and briefly changes scale. The title then becomes an interactive button. After it is clicked, the timeline continues and reveals the downward arrow that leads to the loading page.

The exported opening-page file shows that the title and arrow were created as separate button symbols. The arrow remains hidden during the early frames and becomes visible later in the timeline. The page also connects the arrow button to loadingpage.html.




The loading page contains a rotating house icon, moving circles and animated loading text. The final entry control appears after the loading sequence and opens the main homepage. I also added a click sound to make the transition feel more responsive. The loading page contains a dedicated animated button sequence and code for sound and page navigation.

On the homepage, the child and Max the dog introduce the experience. The environmental animations remain gentle, while the introduction card and Start Adventure button guide the user towards the main activity.

Compared with my original proposal, I simplified the permanent navigation so that the most important sections remained easy to understand:

Home · Explore House · Safety Tip · Parent Guide


Figure . Using the Actions panel in Adobe Animate to assign navigation functions to the menu buttons and connect different website pages.

This reduced visual crowding and made the page clearer for younger users.




There were also some problems when the animation popped up. For example, I wanted to use the teacher's teaching method to make him the effect of a gradual pop-up, but I found that he would repeat this process instead of being fixed there.

So I have to give up this option because I don't know how to fix it yet
Figure 4. Development of the opening, loading and homepage sequence from separated assets to the final animated pages.

6.Connecting the House and Room Activities The Explore House page functions as the central activity map.

The main page contains separate clickable areas for:

Kitchen;

Bathroom;

Living room.

These buttons open the corresponding HTML pages. The same global navigation is repeated across the main activity pages so the user can return to Home, Explore House, Safety Tips or Parent Guide.


This screenshot shows how I created the interactive room buttons on the Explore House page. I used the button timeline in Adobe Animate to set different states, including normal, hover, click and hit areas. When the mouse moves over the Kitchen button, it changes to yellow, making the clickable option more noticeable for children. I used the same method for the Bathroom and Living Room buttons so that the page has consistent interaction feedback.

7. Kitchen Interaction Development

The kitchen page uses hidden danger points placed over objects such as the kettle, stove and knife.

The initial scene asks:

“Can you find the hidden dangers around the room?”

I added warning icons to suggest which areas might contain danger, while still allowing the child to explore the scene.

When the user selects an object, the interface changes to a larger warning panel. For example, the stove-fire section presents a stronger red warning, a visual demonstration and short safety advice. I kept the instructions brief so that children could connect the animation and the message quickly.

During development, I adjusted the size of the kitchen image and warning panel several times. In the original sketch, the animated card occupied a larger area, but in the final version I needed to keep enough space for the characters, navigation and instruction box.

The final recorded demonstration shows that the kitchen page combines object recognition, warning animation and short written guidance rather than presenting all safety information at once.





Figure 5. Development of the kitchen hazard interaction from the original annotated plan to the final warning-card layout.

8. Bathroom Interaction Development

The bathroom was one of the more complicated pages because it needed to communicate movement, water and electrical danger.

I created separate invisible clickable areas for two main interactions. When a user clicks the first area, the timeline moves to one animation sequence. Clicking the second area moves the timeline to another sequence. In the exported code, these interactions use gotoAndPlay(165) and gotoAndPlay(218). 

this.gotowindcard.addEventListener("click", function () {
    this.gotoAndPlay(165);
}.bind(this));

this.gotowater.addEventListener("click", function () {
    this.gotoAndPlay(218);
}.bind(this));

For the wet-floor interaction, I created multiple movement frames showing the child moving, slipping and falling. I also added water-droplet elements and a warning message explaining that children should not run or jump on a slippery bathroom floor.

The second hazard uses visual warning symbols to communicate the danger of water near electrical equipment.

I wanted the consequence to be clear, but I did not want the scene to become frightening. I therefore used exaggerated cartoon movement and immediately followed it with Max’s safety message.

The bathroom code also includes sound registration and a check for a suspended audio context. This was added because the click sound sometimes stopped working after moving from one HTML page to another. Before playing the sound, the code attempts to resume the browser audio context.



Figure . Bathroom timeline showing the clickable hazard areas, slip sequence, warning feedback and sound-control code.

9. Living-Room Choice and Consequence Animation

The living room contains more decision-based interaction than the other rooms.

The first hazard involves medicine placed on the table. When the user clicks it, the child approaches the object and the website displays a clear medicine warning.

The sofa activity gives the user two options. I created separate button symbols for the different decisions and connected each choice to a different timeline section.



The exported code connects:

  • newlef to frame 253
  • keepin to frame 157
  • the medicine warning to frame 73
  • the character warning to frame 132 

bindWithSound.call(_this, "newlef", function () {
    _this.gotoAndPlay(253);
});

bindWithSound.call(_this, "keepin", function () {
    _this.gotoAndPlay(157);
});

The unsafe result shows the child jumping and falling from the sofa. The safer result changes the character into a sitting position and displays positive feedback.

To create these animations, I used different body poses and combined them into short Movie Clips. The living-room file contains sequences for sofa jumping, sitting, running, falling and feedback messages.

This page was useful because it changed the user from an observer into a decision-maker. Instead of only discovering an object, the child chooses what the character should do and then sees the result.




Figure 14. Living-room choice buttons and separate timeline paths for the safe and unsafe outcomes.

10. Safety Tip and Parent Guide Pages

The Safety Tip page collects the information introduced in the room activities.

I organised the content into a card-based layout. The cards are arranged like a carousel, with left and right arrows framing the information. The exported safety-tip file includes the card animation, arrow symbols, navigation buttons and looping timeline structure.

The final page includes safety advice for the kitchen, bathroom and living room. Rather than repeating the full room animations, it presents the most important lessons in shorter sections.

The Parent Guide uses a different visual tone. I kept the pastel style, but the page contains more text and larger information cards. The content explains the mission of the website, how children learn and how parents can continue practising safety habits at home.

In the final website, the Parent Guide visually appears as overlapping cards. This helps separate the information into smaller sections and avoids presenting the parent with one long paragraph.




Figure 15. Final Safety Tip card layout and Parent Guide information-card design.

11. JavaScript and Page Interaction

The visual animation was mainly created in Adobe Animate, but JavaScript was needed to make the website interactive.

The code was used for:

  • Click events

  • Timeline control

  • Page navigation

  • Button sound effects

  • Hover and button states

  • Reusable button-binding functions

  • Browser audio handling

  • Responsive canvas scaling

For the living-room page, I used a shared function to combine the button action with the click sound. This was more organised than writing separate sound and navigation listeners for every button.

function bindWithSound(btnName, action) {
    var btn = this[btnName];

    btn.addEventListener("click", function () {
        playClickSound();
        action.call(this);
    });
}

The same structure was then applied to different decisions and page-navigation buttons. The living-room file confirms that multiple actions were connected through this approach.

The navigation currently opens several pages with window.open(..., "_blank"). This helped me test different pages without losing the previous screen, but it can create multiple browser tabs. In a future version, I would change the navigation so the pages open in the same tab and feel like one continuous website.

12. Sound and Interface Feedback

Every major page contains its own background audio file.

The project includes separate tracks for:

  • Opening page;
  • Loading page;
  • Main homepage;
  • House page;
  • Kitchen;
  • Bathroom;
  • Living room;
  • Safety Tips;
  • Parent Guide.

I also added click.mp3 to provide feedback when the user selects buttons, navigation items or choices.

Browser audio behaviour became one of the technical challenges. Some browsers do not allow audio to begin until the user performs an action. For this reason, the click sound was connected directly to button events. In some pages, I also added audio-context handling so that the sound could resume after a page transition.

This made the interface feel more responsive and helped confirm that the user’s click had been recognised.

13. Publishing and Responsive Settings

The Animate publishing settings export:

  • HTML;
  • JavaScript;
  • Image atlases;
  • Sound files.

The images are placed inside the images/ folder, while audio is placed inside the sounds/ folder. The sprite-sheet limit is set to 2048 × 2048 pixels.

I enabled:

  • Center Stage
  • Make Responsive
  • Export Images
  • Export Sounds
  • Export HTML

The published pages therefore scale the complete 1280 × 720 canvas proportionally when the browser window changes.

However, this is still canvas scaling rather than a fully reorganised mobile layout. The elements become smaller together instead of changing into a new mobile information structure. A future version should include a more flexible mobile design with larger touch controls and a vertically reorganised layout.

The final HTML pages use CreateJS to reproduce the Animate timelines, symbols, buttons and tweens in the browser. Much of the long exported JavaScript is automatically generated by Adobe Animate; I did not manually write every exported CreateJS class.

14. Testing and Debugging

After publishing the individual files, I tested the complete website in a browser and recorded the final interaction process.

I checked:

  • Opening and loading transitions;
  • Background music and click sounds;
  • Character animation;
  • Page navigation;
  • Kitchen hazard cards;
  • Bathroom consequence animations;
  • Living-room decisions;
  • Safety Tip cards;
  • Parent Guide content;
  • Return buttons;
  • Browser canvas scaling.

Several problems appeared only after publishing.

An interaction could work correctly in Adobe Animate but fail in the browser when:

  • An instance name did not match the code;
  • An event listener was placed on the wrong frame;
  • The target frame number was incorrect;
  • An object did not exist at the frame where the code ran;
  • The browser blocked the sound;
  • A page link used the wrong relative path.

To solve these problems, I checked the Actions layer, compared the code with the instance names, republished the page and tested it again.

I was the first website to test the version, but I found that there was no sound effect and background music after clicking 

 Test release (failed version)      https://kidsweb-test1.netlify.app/

So I can only ask for AI monitoring software to help me check the configuration of all files to see if there is any code that is not bound.

The living-room page includes console messages that helped me confirm whether each control was successfully connected. This made debugging more manageable because I could identify the specific missing button instead of checking every animation layer.

The final screen recording demonstrates the full journey from the animated title to the Parent Guide. It also provides evidence that the separate HTML pages, animations, sounds and navigation were successfully connected.

YOUTUBE VIDEO LINK    

https://youtu.be/jy4y8Fo159A


Published public links （Tap the screen to start the music. This project supports interaction via mouse clicks and scrolling.）

https://kids-safety-guardian.pages.dev/?ksg_build=20260729-6


Google Drive 


15. Evidence of Original Authorship

The development process is supported by several forms of evidence:

  • My original Task 1 proposal;
  • My handwritten page and motion planning;
  • Separated character and interface asset sheets;
  • Nine editable Adobe Animate FLA files;
  • Layered timelines and keyframes;
  • Named symbols and button instances;
  • Custom Framescript placed on the Actions layers;
  • Published HTML, JavaScript, image and sound files;
  • Development screenshots;
  • Final browser screen recording.

The FLA files show that the website was built through individual layers, Movie Clips, symbols, tweens, keyframes and action frames. The project is therefore not only a set of finished screenshots or an automatically generated website.

16. Final Reflection

This project changed the way I understand animation.

At the beginning, I mainly thought about movement as something visual. I wanted the characters, clouds, buttons and warning objects to look lively. During production, I realised that an interactive animation also needs logic.

Every movement raised another question:

  • When should it begin?
  • When should it stop?
  • Should it loop?
  • What should the user click?
  • Which frame should play next?
  • How can the user return?
  • What happens if the sound does not work?

Separating the characters into many parts was repetitive, but it gave me better control over the poses. Managing nine different Animate files was also challenging because the page names, instance names and navigation links needed to remain consistent.

The most difficult part was combining the visual timeline with JavaScript. A small change in an instance name or frame number could stop an entire interaction. However, repeatedly testing and correcting these problems helped me understand the relationship between interface design, animation and front-end interaction.

The final website still has areas that could be improved. Opening each page in a new browser tab can interrupt the journey, some animation transitions could be smoother, and the responsive version is still based on proportional canvas scaling.

Despite these limitations, I successfully transformed my Task 1 proposal into a complete interactive educational website. The project improved my skills in:

  • Adobe Animate;
  • HTML5 Canvas;
  • Character asset preparation;
  • Motion and frame-by-frame animation;
  • Interface hierarchy;
  • Interactive storytelling;
  • JavaScript integration;
  • Sound feedback;
  • Browser testing and debugging.

Most importantly, I learned that an interactive website is not only about making the page look attractive. The design, movement, code and user decision must work together as one experience.

18. Reflection and AI Disclosure

I used ChatGPT to generate and revise selected JavaScript code during the development of this project.

ChatGPT mainly supported the following coding tasks:

  • Creating button click event listeners;
  • Writing gotoAndPlay() timeline controls;
  • Connecting separate HTML pages;
  • Adding click-sound playback;
  • Creating a reusable button-and-sound binding function;
  • Explaining browser audio-context problems;
  • Helping debug missing or unresponsive button instances.

ChatGPT did not automatically generate or assemble the complete website.

I personally completed:

  • The project concept;
  • Target-user decisions;
  • Page structure;
  • Visual direction;
  • Interface layouts;
  • Handwritten animation planning;
  • Character and asset preparation;
  • Symbol creation;
  • Layer organisation;
  • Adobe Animate timelines;
  • Frame selection;
  • Instance naming;
  • Page composition;
  • Code placement;
  • Browser testing;
  • Final revisions.

The long JavaScript files included in the published folder were mainly generated automatically by Adobe Animate from my timelines and symbols. I did not manually write all of the exported CreateJS code.

For the custom interaction code, I used ChatGPT（Codex） as a coding assistant. I still needed to place the code on the correct Actions frame, replace the suggested instance names, choose the correct frame numbers, change the page paths and repeatedly test the result.

Some generated code did not work immediately because ChatGPT could not directly see the internal structure of my FLA files. I needed to compare the code with my actual timeline and adjust it myself.

Therefore, ChatGPT supported the coding process, but the final design decisions, animation production, technical integration, testing and final website construction remained my responsibility.



Comments

Post a Comment