 Hi all, I'm Carlos, I'm representing Moopist Team on Educational Solutions and I'm going to provide a super quick update on the work done this spring and leave most of the time to Sabi, UX designer for Moopis and Julia, content designer for VX, who are going to introduce us to the prototyping process for the in-web project. Over to you, Julia and Sabi. Thank you Carlos. Hi everyone, I'm Sabina and I'm going to be talking about the process Julia and I follow for the default type completion settings project. As Carlos says, this is a project fostered by day anyway and the proposal was to reuse the default completion setting space that we have at the course level for the site level completion default and here you have the links to the two tracker issues that we have for the project. Next slide please, Adrienne. So for the project we follow a content design focus approach and Julia and I worked together from the very beginning of the process. The first step we follow was analyzing the page that the MUA went to reuse and these included the pages as a whole and its functionality. Next slide please, Adrienne. And also analyzing the activity completion settings for each of the activities at course level and comparing these settings to the ones of each individual activity. So during the analysis we found some inconsistencies between activity and course level settings and these were the some settings were only at the activity level like for example in the right screen so that you can see that the required grade setting have more options like whole forum or rating that are not visible in the course level and also the completion settings at activity level were using some progressive disclosure while the one in the default course level were using non-progressive disclosure. So as you can see on the left screen shot even though we have system do not indicate activity completion we are still displaying all the settings that are disabled because obviously we choose an option that don't track the completion. Next slide please. So the decision that we made was making both experience consistent so that the new site level settings that the MUA wanted will be congruent with the activity and course level settings as well. So the next step that we followed in the process was creating flow diagrams of all completion settings for each of model core activities and resources as you can see here in this instance and I'm going to pass on to Julia to continue the presentation. Hi next slide Adrian please. So after working on the flow diagrams for all activities and resources we started grouping them together based on common completion requirements. For example there's many resources that only have the view requirement while other activities had submission or posting requirements some support grades some don't etc. These grouping of the activities allowed us to get a deeper understanding of the logic of the requirements. Next slide please. And it also allowed us to detect pain points and things that we could improve. For example like Sabina said people are seeing many settings at the same time. Some of these settings are not relevant to them according to the option they just selected so it can be a bit confusing and overwhelming. We also saw that the labels for all setting names and the options start with the same words like require require require and student mask student mask and that makes information not easily scannable. We also noticed that we were allowing people to select options that might be redundant for example require a grade and require a passing grade and even some contradictory settings. And finally we also noticed that an essential part of the information is hidden here behind the help pop art or tooltip which is that when you select these requirements all of them must be complete in order for the activity to be marked as done. So next slide please. Then we had an aviation session focusing on three of the groups that we had identified. The goal of the session was to simplify the way in which people can define completion requirements and to address the pain points and with it that by using progressive disclosure so people can take one decision at a time only and are not overwhelmed with things that are not relevant to them. Using simpler and more action oriented language for example instead of saying show activity as complete when conditions are met for people to select conditions we just have like add conditions. And then we also decided to show information that's essential which is that all requirements have to be completed. And finally there was also a bulk editing feature for completion requirements. At course level we looked at that and we realized it was difficult to use not very useful and it added more clicks to the experience so the team decided both not to add this to the new site level settings and also to remove it from the course level settings and we brought that up with CMUA and they agreed. So now I'm going to pass it back to Sabina so she can do demo. Thanks Julia. So I'm going to see my screen. Okay great. Can everyone see my screen? Yes. Great. So we've added a new section in the site administration in the course tab called the fault settings in which we added a new page to be for the admin to define the default for each activity at site level. I'm going to just go through one of the activities one of the most useful ones because we don't have much time but you have the link to the prototype in this slide so you can play around if you want. So as you can see we have this page with some information in here and all the activities listed here and when we for example go to forum we see that if we select non completion tracking we won't show any settings. We can select the manual completion here and we can select the automated completion which is the most complicated one with more settings and as you can see here we are using the progressive disclosure only displaying the relevant settings when the user make a selection and this will happen as well with the child settings that we have under some main settings as you can see in posting forums and once each of the settings is selected we will display then the input fields or any other components that will be necessary to complete the settings as here the number of discussions or thoughts or replies that this student needs to do and also like Julia mentioned we change slightly the way in which we display the received grade and passing grade so we don't display few button down settings and it's a little bit easy to use. We have as well the whole forum or grading grade settings that we only had at activity level we make consistent with size and course level and here we basically can change the grade passing grade and so on and once the admin is done with the settings we will have the state button in the sticky filter and we will see a confirmation that all the settings have been changed and have been updated. Yes this is it from me the project is a little bit wider and you will be able to see also in the prototype what we've done for the course level because the settings are slightly different in course level so you can play around with the prototype if you want. Yeah that's it from me.