# Moodle LMS Integration with Amazon Alexa: A Practical Experience
## 3 Method
### Alexa Skill Implementation
#### Implementation Problems and Workarounds  
Over the course of the development of the skill we confronted unexpected issues regarding the user experience when creating voice dialog from the information we got from Moodle Web Services. As mentioned in Section 3.1, we combine several Moodle functions to create the logic that would reach the calendar event data for the user. We utilize the function core_enrol_get_users_courses to retrieve the information regarding the course, such as the name of the course, and the function core_calendar_get_calendar_events to retrieve the actual information related to the events, such as name of the event, date of the event, etc. We encountered the problem that certain properties of the elements of Moodle, such as the name of a course or the name of an event, might be specified by the administrator of such element in such manner that would not be directly compatible with audio streaming. For example, some event titles might contain special characters to help understand that the event is aimed for a specific group of people (e.g., Project Presentation (Group 1) or Basics of Programming (Online)). Furthermore, course titles might be too long for an audio experience, where the user must listen to the full course name if events related are presented, which might exhaust the time and willingness of the user to listen to the full response for a long period of time. This problem with the user experience brought up a new issue, this time regarding the administration of the Alexa skill itself. How could an administrator of an element in Moodle, such as a calendar event, for example, be able to hear what the final user might experience through the Alexa devices, before making it publicly accessible? As an example, if a teacher could listen to what the students might hear regarding an event that is being newly added, the teacher is still able to edit the outcome until the audio experience achieves the expected level of quality and comprehension. However, in its current form, the only way for any person to hear what an event might sound like through our Alexa skill was to actually make the event public, without even knowing how it will really be spoken out by the [PERSON] device. These problems were a direct risk for the purposes of our work. If we were to test the likelihood of users enjoying the use of our Alexa skill, we had to aim for the best user experience we could offer to begin with. As our work was not a technical research on Moodle integration with Amazon Alexa, we made the conscious decision to edit the interaction flow with Moodle. Instead using the Moodle function core_calendar_get_calendar_events to fetch the user events, we decided to create a file within our application which would contain the events information hard-coded within, and replace the use of the Moodle function by reading and processing that file when needed. By hard-coding the information on a file, we removed the flexibility of updating event data through Moodle, or any external service for that matter. The only way to update any event data, meaning adding new events, deleting unnecessary ones, or modifying any of the existing ones, could only be achieved by editing the file manually and deploying the application again on our cloud hosting service (in our case AWS Lambda service). On the other hand, this file contained all the necessary information we required for our skill to perform optimally. The file would contain event data in JavaScript Object Notation (JSON) format, which will allow us to have custom values such as the course name, as we wanted to be said by Alexa, the date of the event, on a standard ISO-8601, and other values what allowed us to build the audio output of the Alexa skill on a more user-friendly fashion, which would help to our research for understanding user's experience with Alexa (see example of event JSON on Listing 3).