For Swiva, we decided to keep some of these tasks out of our main backend and move them closer to the user, to the edge. In our case, this means using Cloudflare Workers. A Worker is a small serverless function that runs on Cloudflare’s global network, close to the user. It can handle a request, run a bit of JavaScript or TypeScript and return a response without needing our main backend at all.

That makes Workers a good fit for small features that need to be fast, but do not need a full backend route, database connection or heavy infrastructure.

The problem with app store redirects

A simple example is our app download link. When someone scans a QR code on a poster, sticker or social media post, they should end up in the right place. iPhone users should go to the Apple App Store, Android users should go to Google Play and desktop users should go to our website.

The normal solution would be to send everyone to a page on our website. The page loads, JavaScript runs in the browser, checks the device and then redirects the user. That works, but it is not ideal. The user may see a blank page or a short loading screen before the store opens. For an app download link, every small delay matters.

A smart redirect at the edge

Instead of loading a full page, we use a Cloudflare Worker. The Worker runs before the request even reaches our main server. It checks the user agent from the HTTP request, decides if the user is on iOS, Android or desktop and immediately returns a 302 redirect. So the QR code does not point to a heavy website. It points to a tiny edge function.

A simplified version can look like this:

export default {
  async fetch(request, env, ctx) {
    const userAgent = request.headers.get("user-agent") || "";

    const isIOS = /iPhone|iPad|iPod/i.test(userAgent);
    const isAndroid = /Android/i.test(userAgent);

    const targets = {
      ios: "https://apps.apple.com/at/app/swiva/id6769160022",
      android: "https://play.google.com/store/apps/details?id=app.swiva",
      desktop: "https://swiva.app",
      fallback: "https://swiva.app",
    };

    let platform = "fallback";

    if (isIOS) {
      platform = "ios";
    } else if (isAndroid) {
      platform = "android";
    } else {
      platform = "desktop";
    }

    return Response.redirect(targets[platform], 302);
  },
};

This is not a huge feature. But it solves a real problem in a very clean way.

Tracking without a heavy analytics script

We also want to know where our downloads come from. A QR code on a poster, a link in a story and a link on a website should not all look the same. Instead of loading a full analytics script, the Worker can read a source parameter from the URL, add UTM parameters to the final link and count the redirect in Cloudflare KV. The important part is that this should not slow down the redirect. For that, we use ctx.waitUntil().

const source =
  url.searchParams.get("src") ||
  url.searchParams.get("source") ||
  "direct";

targetUrl.searchParams.set("utm_source", source);
targetUrl.searchParams.set("utm_medium", "smart_redirect");
targetUrl.searchParams.set("utm_campaign", "app_download");

if (env.DOWNLOAD_LINK_REDIRECT_STATS) {
  const today = new Date().toISOString().split("T")[0];
  const key = `${today}:${source}:${platform}`;

  ctx.waitUntil(
    (async () => {
      const currentCount =
        (await env.DOWNLOAD_LINK_REDIRECT_STATS.get(key)) || "0";

      await env.DOWNLOAD_LINK_REDIRECT_STATS.put(
        key,
        (parseInt(currentCount) + 1).toString()
      );
    })()
  );
}

The redirect is sent back immediately. The statistic update happens in the background. That is exactly the kind of small task where edge functions feel perfect.

Why this works well for Swiva

This setup works well because each Cloudflare product has a clear job. Our marketing website runs on Cloudflare Pages, which is made for hosting static websites and frontend projects. This is enough for a lightweight app landing page like swiva.app and keeps the website separate from the redirect logic.

The redirect itself runs as a Cloudflare Worker, because it needs to be fast and should happen before a full website loads. For simple tracking, we use Cloudflare KV. KV is a key value store, so we can save small pieces of data with a key, for example how often a specific QR code source was used on a specific day.

This gives us lightweight redirect tracking without setting up a full database or adding a big analytics tool. For this kind of use case, the free limits are more than enough. Cloudflare Workers currently include 100,000 requests per day on the Free plan, which is a lot for a smart redirect service.

Try it yourself

You can test the redirect yourself using this link or by scanning the QR code.

If you scan it with an iPhone, it should open the Apple App Store. If you scan it with an Android device, it should open Google Play. If you click the same link on a desktop device, it should redirect you to the Swiva landing page.

That is the nice part about this setup: one QR code can work for every platform, without loading a full website first.

Open the Swiva smart redirect

The post Microservices at the Edge: Why We Use Cloudflare Workers for swiva.app appeared first on Mobile USTP MKL.

That’s why Figma’s new Chrome Extension immediately caught my attention.

The Inspiration Workflow We All Know

For years, screenshots have been my go-to method for collecting design inspiration. With a screenshot, you can identify colors, typography, layouts, and maybe even recreate some components like buttons or cards. But screenshots only show the surface. They are static. You can look at them, but you can’t really interact with them. If you want to understand how a design is built, you often have to rebuild it yourself. You need to recreate sections, estimate spacing, and manually analyze the structure. It can be a useful learning process, but it takes a lot of time. And let’s be honest: rebuilding a website just to inspect it isn’t always the most exciting task.

What Figma Just Announced

A few days ago, Figma revealed its new Chrome Extension on social media. The announcement immediately caught my eye. Figma wrote:

At first glance, it sounds simple. But if it works as advertised, the impact could be huge. Instead of taking screenshots, designers can capture a website and bring it directly into Figma as editable layers. What was previously just a reference suddenly becomes something you can inspect, move around, edit, and experiment with. For me, that’s a completely different way of learning from existing designs.

Why This Excites Me as a Designer

One of my favorite parts of design is studying other people’s work. Whenever I discover a website that feels particularly well-designed, I don’t just focus on the visual style. I want to understand the decisions behind it. How is the content structured? How much spacing is used between sections? Why does the hero section feel balanced? How are users guided through the page? Finding answers to these questions usually required a lot of manual work. I often ended up rebuilding parts of the design myself just to understand how everything fit together. Now I can potentially import the design into Figma and inspect it directly. For someone who enjoys learning through observation and experimentation, that’s incredibly exciting.

A Huge Time Saver for Redesign Projects

What excites me even more is the potential for client work. Imagine a client comes to you with an outdated website and wants a redesign. Usually, one of the first steps is recreating parts of the current website inside Figma so you can explore improvements and test new ideas. This process is necessary, but it can also be very repetitive. You spend hours rebuilding something that already exists before you can start doing the work that actually creates value. If this extension can accurately recreate a website inside Figma, that entire preparation phase could be reduced from hours to minutes. Instead of rebuilding the current design, I could immediately focus on improving it. And that’s where the real design work begins.

Will Tools Like This Replace Designers?

Whenever a new design tool appears, the same question comes up:

Will this replace designers?

To be honest, I have mixed feelings. Like many people working in creative industries, I sometimes wonder how AI and automation will affect the future of design. Every few months, a new tool appears that promises to make parts of our job easier. And yes, that can be a little scary. But at the same time, tools like this don’t understand users, business goals, or brand strategy. They don’t know why one design decision is better than another. They don’t know how to prioritize user needs. And they definitely don’t know what a client actually wants. What they can do is remove repetitive work. And honestly, that’s exactly what good software should do. The best tools don’t replace creativity. They create more room for it.

Final Thoughts

The more I think about Figma’s new Chrome Extension, the more I believe it’s one of those features that seems small at first but could have a big impact on everyday workflows.

Will it completely revolutionize web design?
Probably not.

But for my own design process, I can already see how much time it could save. Less time spent rebuilding existing websites means more time spent analyzing, experimenting, and improving designs.And at the end of the day, that’s the part of design I enjoy the most.

Sources:

https://www.figma.com/downloads/chrome-extension

The post Is Figma’s New Chrome Extension a Game Changer for Designers? appeared first on Mobile USTP MKL.

I chose this topic because before writing this blog, I honestly didn’t really understand how websites actually get found on Google. I also didn’t know what you can do to improve visibility or why some websites show up everywhere while others basically don’t exist in search results.

A lot of people think that once you build a website and put it online, it automatically appears on Google. But that’s not how it works. Search engines first need to find the website, analyze it, and add it to their system. Only after that it can show up in search results.

What does indexing mean?

When a website goes live, it does not immediately appear on Google. Instead, search engines use automated programs called crawlers. These crawlers constantly scan the internet, follow links from page to page, and collect information from websites.

When they visit a page, they read the content and store it in a huge database called the index. You can imagine this index like a giant digital library. If your website is not inside this library, Google simply does not know it exists.

Why being online is not enough

Just putting a website online is not enough to be visible. Many websites stay invisible because search engines cannot properly find or understand them. This often happens when the technical structure is weak or when the website is not clearly organized for crawlers.

Even a well-designed website can have almost no traffic if it is not technically optimized for search engines.

SEO and why it matters

SEO, which stands for Search Engine Optimization, plays a very important role here. It is one of the main factors that decides how visible a website is on Google.

SEO is influenced by things like page titles, high-quality content, fast loading speed, and especially mobile optimization. Today we live in a “mobile first” world, which means websites are mainly evaluated based on how they work on mobile devices.

Keywords are also a big part of SEO. These are the search terms people type into Google. To make a website visible, these keywords need to be used naturally in the content. But it is not about adding random words everywhere. It is much more important to understand the search intent behind them. People usually search either for information or for products and services, and the content should match that.

Local visibility and Google Business Profile

For local businesses, regional visibility is extremely important. A Google Business Profile helps companies appear in local search results and gives users key information like opening hours, address, contact details, and reviews.

For small and medium businesses especially, this can make a huge difference because many customers search for services “near me”.

Security also affects ranking

Website security is another important factor. Websites should always run on HTTPS because Google prefers secure connections. If a website does not have an SSL certificate, it can not only reduce user trust but also negatively affect rankings.

It is also important to keep platforms like WordPress updated. Outdated plugins or insecure configurations can cause performance issues and even create security risks.

Google Search Console as a key tool

One of the most important tools in technical SEO is Google Search Console. It helps you control and monitor how your website appears on Google.

With this tool, you can submit your website directly to Google, upload a sitemap, and request indexing for specific pages. It also shows whether there are crawling issues, which pages are already indexed, and which search terms bring users to your website.

For new websites, this tool is especially important because it speeds up the whole indexing process and gives clear insights into visibility.

Traffic and what happens after indexing

Once a website is indexed, the next step is improving traffic. Getting indexed is a big milestone, but real success starts when people actually visit the website.

There are many ways to increase traffic. A big part of it is networking and simply getting the website out into the world. Sharing it on social media helps a lot, as well as using business cards, flyers, or even adding the website to directories and online listings.

The more places a website appears, the more signals it sends to search engines that it is relevant and active.

Conclusion

Before my first real website project, I thought building a website was mainly about design and development. I assumed that once a site is online, it will automatically be found.

But in reality, it is completely different. Visibility depends on many factors working together, like indexing, SEO, technical quality, content, and external signals.

A website is not just something you build once. It is something you need to optimize and maintain if you want it to actually be seen.

And yes, traffic matters a lot. Google basically thinks: “If nobody visits it, is it even worth showing it?” So the more real users interact with a website, the better it performs in search.

So, in true “help a student”. I’d really appreciate if you could do me a small favor and click on the links below. No pressure… but Google definitely loves attention.

Swiva: https://swiva.app/
RKZ Metall Design GmbH: https://www.rkz-design.gmbh/

Sources:

https://webgo.de/blog/bei-google-gefunden-werden

https://www.media-company.eu/blog/website-bekannt-machen-bei-google

https://www.peaknetworks.ch/blog/wie-wird-meine-website-in-google-angezeigt

https://developers.google.com/search/docs/fundamentals/get-on-google?hl=de

https://webdirwas.at/website-fuer-google-sichtbar-machen/

https://www.domainion.at/suchmaschineneintrag

The post Why Your Website Doesn’t Show Up on Google (And How to Fix It) appeared first on Mobile USTP MKL.

This project was especially interesting for me because my father works at the company, which gave me a closer connection to both the business and its challenges.

Why This Project?

You might be wondering why I suddenly included this project among my master’s projects.

The answer is quite simple. The company had received very few customer inquiries in recent months. During trade fairs and exhibitions, potential customers often mentioned that they could not find the company online. After taking a closer look, it became clear why.

The existing website had several issues. It suffered from poor performance, weak SEO, and limited accessibility. Important legal pages such as the imprint and privacy policy were also incomplete and contained errors. Overall, the website did not represent the quality of the company and its products.

Because of this, I offered my support and took on the challenge of creating a new website from scratch.

Project Scope

One of the biggest problems with the old website was that it had been developed entirely in React. While this worked from a technical perspective, it made content management almost impossible for non-technical employees.

The company wanted a website that they could update themselves. They wanted to be able to change texts, upload images, and maintain content without needing programming knowledge every time.

This became one of the main goals of the project.

Core Features

Before starting the design and development process, I spoke with the client to understand what they needed from their new website.

Of course, the products had to be presented clearly. Beyond that, they wanted customer reviews, information about partners, a contact form, and an overall more modern appearance.

My personal focus was on creating a website that performs well in areas that are essential today: responsive design, SEO, and accessibility. A website should not only look good, it should also be easy to find and easy to use on all devices.

Since the company had almost no digital presence beyond its website, I also created a Google Business Profile and set up Google Analytics to help them understand and improve their online visibility in the future.

Design, Tools, and Technologies

The design process started in Figma. The client requested a visual style inspired by water and waves to reflect the company’s connection to flood protection.

At the same time, I wanted to keep the design clean and professional. The target audience is mostly businesses and homeowners looking for reliable protection solutions, so the website needed to maintain a strong industrial and trustworthy feel.

To make content management easier for the company, I decided to build the website with WordPress instead of creating another fully custom solution. This allows employees to manage content themselves without needing technical knowledge.

To customize the website and provide all required functionality, I researched, installed, and configured several WordPress plugins that support performance, SEO, security, forms, and content management.

What I Learned

This was the first time I created an entire website completely from scratch.

I was involved in every step of the process, from researching hosting options and planning the structure to designing the interface, setting up WordPress, configuring plugins, creating the Google Business Profile, and integrating Google Analytics.

On top of that, I made sure the website worked well on different screen sizes and followed SEO and accessibility best practices.

The project was definitely time-consuming, but it taught me a lot. I gained a much better understanding of how many different areas come together when building a professional website. It was not only about design or development, but also about planning, communication, marketing, and long-term maintainability.

Conclusion and Future Steps

At the moment, the project is not completely finished yet. I am currently waiting for feedback from the company, and some final content such as photos and text material is still missing.

Once these assets are available, I will make the final adjustments, complete the remaining content, and submit the website for indexing so it can be found through search engines.

After that, the company will finally have a modern web presence that better reflects its expertise and helps potential customers find its services online.

Check It Out Soon

The new website will soon be available at:

https://www.rkz-design.gmbh

Feel free to take a look once it goes live.

The post PROJECT | Building a New Website for RKZ Metall Design GmbH appeared first on Mobile USTP MKL.

One feature we had planned for a longer time was sharing links directly into the app. For example, a user sees a recipe on Instagram, a restaurant on Google Maps or an activity on TikTok and shares the link to Swiva. The app should then create a useful activity from that link, with a title and a short description.

At first, I thought the main challenge would be the AI part. But during the project I realized that a much bigger part was actually getting good information from the shared links.

The real problem: getting the content

Before the AI can generate a good activity, the app needs useful input. For that, I used two general strategies and one special case.

The first strategy is Open Graph metadata. This is the information many websites use for link previews, for example when a link is shared in WhatsApp. It often contains a title, description and image, which can already be enough to understand the basic content of a post or website.

The second strategy is oEmbed. This is used by platforms like TikTok to provide information for embedded content. In some cases, this gives better structured data than normal page metadata.

Google Maps was more difficult. The official APIs are based on place IDs and structured requests, not just random shared Maps links. Also, Google has strict rules around scraping. Because of that, I did not scrape the page directly. Instead, I tried to resolve the link and extract the place name from the final URL when possible.

I also decided to send these metadata requests from the app instead of my backend. If the app scales, I do not want my server to send too many requests to platforms like Instagram or TikTok and risk rate limits or IP bans. Sending them from the app distributes this better and keeps the backend simpler.

On-device AI and fallback

For iOS, I used the Callstack React Native AI package with Apple’s on-device AI capabilities. This worked well and was quite easy to use, because the API is based on the Vercel AI SDK.

My original plan was to also use Google ML Kit GenAI for Android. But the support I wanted in the React Native AI package was not available yet, and I did not want to build a custom Expo module just for this. Since I had already proven the on-device concept with Apple, I used a cloud fallback for Android and unsupported devices.

The fallback sends a request to my backend, which uses a Gemini Flash-Lite model to generate the activity. At first I used Gemini 2.5 Flash-Lite, where the results were comparable to Apple’s on-device model. Later I tested Gemini 3.1 Flash-Lite, and I was much happier with the generated titles and descriptions.

What I learned

My original goal was to compare on-device AI and cloud AI and see if the quality could be similar. I did not fully reach that goal, because the newer cloud model gave better results for my use case.

Still, the project was a useful experiment. I learned how to use Apple on-device AI in a React Native app, how to build a fallback strategy and how important link metadata is for this feature.

For Swiva, I currently think that one cloud strategy is probably the easiest solution to maintain. Gemini Flash-Lite is cheap enough for this use case, the results are more consistent across devices, and the architecture is simpler than maintaining separate strategies for iOS, Android and fallback.

On-device AI is still very interesting, especially for privacy, offline usage and reducing server costs. But in this case, the simplest and most stable solution might be the best one

Check out the feature by downloading Swiva here: https://swiva.app/download

Sources

• Callstack React Native AI: https://github.com/callstackincubator/ai
• Google ML Kit GenAI APIs: https://developers.google.com/ml-kit/genai
• Open Graph Protocol: https://ogp.me/
• TikTok oEmbed / Embed Documentation: https://developers.tiktok.com/doc/embed-videos/
• Google Maps Place Details API: https://developers.google.com/maps/documentation/places/web-service/place-details
• Gemini API Pricing: https://ai.google.dev/gemini-api/docs/pricing

The post Smart Import Feature for my app “Swiva” appeared first on Mobile USTP MKL.

I had already seen Agent Device before, because I also use Callstack’s React Native on-device AI package and follow some of their work. But the performance testing use case really caught my attention. The idea was simple but powerful: let an AI agent click through a mobile app, collect snapshots of performance numbers and check where frame drops or slow interactions happen. So I wanted to try it myself with one of my React Native builds.

What is Agent Device?

Agent Device is a CLI tool that lets AI agents control mobile apps. It can work with iOS and Android apps, including React Native apps, native apps and apps running on real devices, simulators or emulators.

Instead of only looking at code, the agent can actually interact with the app. It can inspect the UI, understand what is currently on the screen, tap elements, scroll, type into inputs, take screenshots, collect logs and repeat actions. That makes it useful for mobile testing, because the agent can behave more like a real user. It does not only follow a fixed script. It can look at the current app state and decide what to do next based on the UI.

Why performance testing?

Performance problems in mobile apps are not always obvious in the code. Sometimes a screen looks completely fine, but when you use it on a real phone, it feels slow. Maybe an animation drops frames. Maybe a list scrolls badly. Maybe opening a modal causes a short freeze.

That is why I thought Agent Device could be interesting for performance testing. My idea was not to replace proper profiling tools. You still need real profiling when you want detailed information about the JS thread, native rendering, memory usage or expensive renders. But Agent Device can help with the first layer of testing. It can go through the app automatically and collect signals about where the app feels slower or where frame drops happen.

My setup

For my test, I created a build and installed it on a real Android device. Of course, this could also work with emulators. But for performance testing, I think real devices make more sense. A real device gives you more realistic performance behavior. It has real hardware limits, real touch input and real rendering conditions.

After installing the app, I installed the Agent Device CLI. Then I used Antigravity with Gemini 3.5 Flash to control the agent. I used this model because the task was not really about deep reasoning. It mostly needed to follow instructions, use the allowed Agent Device commands and document what happened. Also, the free token limits were good enough for testing this kind of workflow.

Then I wrote a prompt that explained the use case. The agent should open the app, navigate through all screens, interact with different UI elements and take snapshots of the performance numbers. It should also watch out for frame drops, slow transitions and screens that feel less smooth. I also allowed the agent to use all the Agent Device commands it needed, so it could inspect the UI, tap elements, scroll and move through the app without asking every time.

Why this is useful

The biggest benefit for me is that the agent can do the boring part. Normally, performance testing often starts with manually opening the app, clicking around and trying to notice where something feels bad. This works, but it is easy to forget screens or to test in a different way every time.

With Agent Device, the agent can go through a defined flow again and again. It can collect snapshots, describe problems and give a first overview of possible performance issues.

This could be especially useful before releases. You could let the agent run through the main flows and check if there are obvious frame drops or slow interactions before shipping a new version.

What I learned

The most important thing is to see this as an extra testing layer, not as a replacement for proper profiling. Agent Device can help you detect where something might be wrong. But after that, you still need to investigate why it happens. Maybe the issue is caused by too many re-renders, heavy images, expensive calculations, navigation transitions or something happening on the native side.

Still, I think this workflow is really promising. It connects AI agents with real mobile app usage, not just code generation. The agent does not only write or review code. It actually uses the app and checks how it behaves.

I tested this workflow with my own app, Swiva. It is a React Native app for saving activities, places and ideas, and then swiping through them when you need inspiration. If you want to check it out, you can find it here: swiva.app

Final thoughts

I first saw the idea for performance testing with Agent Device on X/Twitter, and after trying it myself, I think it is a very practical use case. There are probably many more possibilities for this kind of mobile automation. QA flows, regression testing, onboarding checks, accessibility testing or release checks could all be interesting.

For me, performance testing was just the first thing that made the tool click. Letting an AI agent move through a real app, collect snapshots and point out possible slow parts feels like a small but useful step towards more automated mobile testing.

The post Automated Performance Testing for React Native with agent-device appeared first on Mobile USTP MKL.

The goal

Our goal was to create a prototype that plays media that isn’t just linear. We wanted a way to inject logic, like quizzes, info overlays, and decision points, directly into the media timeline. It doesn’t matter if it’s a certain position on a text or a specific time in a video.

To make this work across different platforms, we first had to define a standardized data structure. This led to the development of the WIMP format.

Another important part of this project is a media player that is highly mobile optimized and easy to understand, so that even a five year old can experience a WIMP interactive medium.

The project is split into two distinct layers: the data standard and the playback engine.

Architecture

1. The Format

Before building the player, we needed a predictable way to describe the media content. For this, we had to design a format that incooperates everything a WIMP user needs and will need in the future. This forward thinking and upgradeability of our format was one of the main challenges that we faced during this Wild Week. We ended up with an open-format JSON schema that defines a graph of “media nodes.” Each node can contain:

• Timed Events: Quizzes, info texts, external links and more that can be triggered at specific timestamps.
• Choice Events: Branching points that tell the player which media node to load next.

By publishing this as an NPM package, we integrated a validator directly into the workflow, ensuring that any content loaded by the player is structurally sound and free of dead ends.

Here’s an example format:

{
    "version_number": "0.0.1",
    "format_type": "wimp",
    "meta_data": {
        "id": "7f6b6d2d-8fb7-4bd4-9f2a-5a1e2d7c6b42",
        "created_at": "2026-04-23T00:00:00+02:00",
        "updated_at": "2026-04-23T00:00:00+02:00",
        "author": "Melanie Maier",
        "title": "What If Dinosaurs Still Lived Today?",
        "start_media_id": "dinosaur_intro_text",
        "description": "An interactive documentary exploring the hypothetical scenario of dinosaurs still existing in the modern world.",
        "tags": [
            "dinosaurs",
            "interactive documentary",
            "hypothetical scenario",
            "modern world"
        ]
    },
    "media": [{
            "id": "dinosaur_intro_text",
            "title": "Introduction",
            "type": "text",
            "resource_link": "https://wimplayer.media.ustp.at/media.php?name=dinosaurs_intro.html",
            "timeline_events": [{
                "type": "choice",
                "title": "Do you want hear about dinosaurs?",
                "position": {
                    "type": "seconds",
                    "value": 0
                },
                "event_context": {
                    "choices": [{
                        "label": "Start the journey",
                        "next_media": "dinosaur_audio1"
                    }]
                }
            }]
        },
        {
            "id": "dinosaur_audio1",
            "title": "Audio 1",
            "type": "audio",
            "resource_link": "https://wimplayer.media.ustp.at/media.php?name=dinosaur_1.mp3",
            "timeline_events": [{
                    "type": "quiz",
                    "title": "What would be the most likely immediate response from modern states once the existence of large living dinosaurs was confirmed?",
                    "position": {
                        "type": "seconds",
                        "value": 5
                    },
                    "event_context": {
                        "answers": [{
                                "label": "Opening all affected regions to tourism",
                                "is_correct": false,
                                "feedback": ""
                            },
                            {
                                "label": "Establishing exclusion zones and interdisciplinary crisis task forces",
                                "is_correct": true,
                                "feedback": ""
                            },
                            {
                                "label": "Immediately classifying all species as domesticated animals",
                                "is_correct": false,
                                "feedback": ""
                            },
                            {
                                "label": "Suspending all ongoing scientific research",
                                "is_correct": false,
                                "feedback": ""
                            }
                        ]
                    }
                },
                {
                    "type": "quiz",
                    "title": "Why would the discovery of living dinosaurs be more than just a zoological sensation?",
                    "position": {
                        "type": "seconds",
                        "value": 30
                    },
                    "event_context": {
                        "answers": [{
                                "label": "Because it would automatically replace all existing animal species",
                                "is_correct": false,
                                "feedback": ""
                            },
                            {
                                "label": "Because modern cities are already designed for giant reptiles ",
                                "is_correct": false,
                                "feedback": ""
                            }, {
                                "label": "Because it would challenge long-held assumptions about ecology, history, and risk planning",
                                "is_correct": true,
                                "feedback": "Still too high. Fast fashion is often discarded quickly."
                            },
                            {
                                "label": "Because dinosaurs could only survive in artificial reserves ",
                                "is_correct": false,
                                "feedback": ""
                            }
                        ]
                    }
                },
                {
                    "type": "choice",
                    "title": "Do you want to hear more about this scenario?",
                    "position": {
                        "type": "seconds",
                        "value": 60
                    },
                    "event_context": {
                        "choices": [{
                            "label": "Yes please",
                            "next_media": "dinosaur_audio2"
                        }]
                    }
                }
            ],
            "description": "Quick cuts of clothing store racks, online shopping scrolls, and factory workers sewing.",
            "media_length": 76
        },
        {
            "id": "dinosaur_audio2",
            "title": "Dinosaur 2",
            "type": "audio",
            "resource_link": "https://wimplayer.media.ustp.at/media.php?name=dinosaur_2.wav",
            "timeline_events": [{
                    "type": "quiz",
                    "title": "Which dinosaur group would likely be the hardest to control in a modern civilization?",
                    "position": {
                        "type": "seconds",
                        "value": 5
                    },
                    "event_context": {
                        "answers": [{
                                "label": "Small to medium-sized, intelligent, highly adaptable predators",
                                "is_correct": true,
                                "feedback": ""
                            },
                            {
                                "label": "Very large, slow-moving herbivores",
                                "is_correct": false,
                                "feedback": ""
                            },
                            {
                                "label": "Flightless species living only in remote areas",
                                "is_correct": false,
                                "feedback": ""
                            },
                            {
                                "label": "Species with strongly territorial but fixed-range behavior",
                                "is_correct": false,
                                "feedback": ""
                            }
                        ]
                    }
                },
                {
                    "type": "quiz",
                    "title": "Which societal conflict would be most likely if humans and dinosaurs had to coexist permanently?",
                    "position": {
                        "type": "seconds",
                        "value": 35
                    },
                    "event_context": {
                        "answers": [{
                                "label": "Whether dinosaurs should be included in school curricula ",
                                "is_correct": false,
                                "feedback": ""
                            },
                            {
                                "label": "The complete abolition of modern infrastructure",
                                "is_correct": false,
                                "feedback": ""
                            },
                            {
                                "label": "A global abandonment of agriculture",
                                "is_correct": false,
                                "feedback": ""
                            },
                            {
                                "label": "A conflict between species protection, public safety, and economic use of land",
                                "is_correct": true,
                                "feedback": ""
                            }
                        ]
                    }
                },
                {
                    "type": "choice",
                    "title": "Do you want to read more?",
                    "position": {
                        "type": "seconds",
                        "value": 55
                    },
                    "event_context": {
                        "choices": [{
                            "label": "Yes please",
                            "next_media": "dinosaur_end_text"
                        }]
                    }
                }
            ],
            "description": "Dinosaur audio",
            "media_length": 59
        },
        {
            "id": "dinosaur_end_text",
            "title": "End",
            "type": "text",
            "resource_link": "https://wimplayer.media.ustp.at/media.php?name=dinosaurs_end.html",
            "timeline_events": []
        }
    ]
}

2. The Frontend: Nuxt & Logic

The player itself is built with Nuxt. We chose Nuxt because its reactive framework is ideal for syncing a video’s progress with dynamic UI overlays.

For this we split our team into 2 departments:

• The UI/UX of the main page and components
• The player with the state machine

Main Page & Components UI/UX

For prototyping and designing our pages and components, we decided on using Figma with Nuxt’s components to help us out. Here are some examples of our pages and components:

State Machine

To manage the complexity of interactive playback, we implemented a state machine. The state machine coordinates:

• Syncing Logic: Monitoring the video’s currentTime to trigger overlays from the WIMP format.
• Interaction States: When a pause: true event occurs, the machine pauses the background media, putting the quiz or choice interface in the foreground.
• Dynamic Media Handling: When a user makes a choice, the machine resolves the next_media ID and updates the Nuxt state to swap the media and move forward in the decission tree.

The post Wild Week – Wyld Interactive Media Player appeared first on Mobile USTP MKL.