Forum Discussion

  • If you want to practice working with APIs, I recommend starting with Google Cloud Speech-to-Text. This is a free API that converts speech to text. That is, the student speaks the words, and this API translates them into text. Then you can store these words in a variable in Storyline and perform some actions.

    I recently did a review of this API on YouTube in the context of using it in Storyline.

    The case is as follows: a dialogue simulator where instead of selecting one of three response options, you articulate your response. The case looks interesting. It does have a huge number of limitations, but as a training exercise, it’s a great option.

    Below, I'll leave a link so you can see how it works. The video is not translated into English, but you can use automatic subtitles... however, the mechanics of how the case works will be understandable in any language.

    https://youtu.be/3X2KpIK5CXA

  • I had experience using the Open AI API (Chat GPT) in education. I created a dialogue simulator where you had to speak with an avatar and sell the company's services. In fact, the nuances of use will be similar to those with HeyGen (and as I understand, you are interested in HeyGen in conjunction with Chat GPT).

    To connect services via API, you need a server. This applies to any paid APIs and those where you manage some data (practically any APIs are like this). The reason is that to connect to the API, you need a username and password. You can, of course, add the code to Storyline, and the API will work, but your username and password will be visible to anyone. In other words, if you paid for the HeyGen API, anyone can open your course, copy your username and password, and use the API in their own project, while you will be the one paying for it.

    When using a server, your username and password will be stored on it and will not be public.

    Another issue with using such APIs is information security concerns. Many companies (virtually all large ones) will be against using such technologies in training materials. The reason is that you are transmitting data to a third-party company, which that company can use however it pleases. Most of the time, information security personnel will not go along with such risks.

    One more important nuance to keep in mind is the complexity of budget forecasting. You pay for each action taken by a user. Some might complete a task in one attempt, while others might take twenty-one... some will spend a long time looking at the avatar, etc. You will pay for all of this. In fact, until you launch the first product, it will be extremely difficult for you to even approximately forecast the budget. When launching subsequent products, you will be able to refer to the costs of launching the first product, but in any case, the figures will vary significantly.

    As a result, before developing such products, you need to clarify with information security whether it is possible to use such technologies in the company and resolve the issue regarding the server.