 Hi everyone, my name is Lior, I'm a developer and a Moodle team in the University of Israel, Open University of Israel, and I'm here to talk about our new forum, but less than the forum or the approach, I'm going to talk about some of the, I'm going to point out some of the development issues I've developed during the work. So I'll start with some details. In the current year we have over 80, 890 courses with over 7,600 forums and as of now over 84,000 posts with around 49,000 students and 1200 faculty members. As you can see our forum is very used, it's actually our second most used component in the site. And it started as sound modification, we added to the original forum way back in Moodle 1.9 and it just took your life with its own over the years. And we just had to answer all the issues that were raised by the users and the staff. So here's our previous version of the forum that we built for Moodle 2.9 that we had. It shows some of our features, as you can see very, very compact display and collapsible content. And some actions are dynamic, by the way when I say dynamic here, I also mean interface and objects, we're working with the server. But the general appearance is closely similar to the original forum. You have all the, pretty similar, marvelous. So on our migration to Moodle 3 we used the opportunity and gathered all of the feedbacks and conclusion we collected throughout the years to create a new interface. Our two main goals were supporting Moodle devices and greater awareness to users with disabilities, which can be considered as another type of platform to support. And it's actually the most important one and most of my focus will be on accessibility issue. In short, we wanted the forum to be available everywhere. Each of these two goals is a large area by itself. To find proper solution we had to try new ideas. This include working with a York designer and learning how to develop for a screen reader. While it's relatively easy to add keyboard accessibility to existing sites, screen reader accessibility is a much, much larger investment. The dynamic also received a very large meaning for accessibility. And here was my first lesson in order to develop for a screen reader we have to work with a screen reader. There's no way around it when developing. After all, a screen reader walks through the pages data tree and you have an example for a web page and source code behind. And here's what's happened when user wants to post something on the forum. This is what actually happens. Every page load, it's a very, very slow process. While in a dynamic page the user remains at the same place after the action and can continue to navigate in the page. For a user with a screen reader, it's a much bigger improvement. So here's a sneak peek of the new forum. I'll talk later about what's in it. But before that, supporting our two goals required finding solutions that weren't technological. Our two most prominent are no more than two hierarchies in discussion replies. In long discussion, some of the times you're trying to understand who exactly you want to reply to or who did another user respond to. And in small screen, like mobile, it's even harder. So here we have only two levels with visual distinction that enable a much faster orientation. Another much more significant change is the text editor, the ATO. Loading and displaying ATO inside the forum page every time you want to write something isn't a very fast, simple process. And that just when ATO is a default editor, some other site will use another one. So we found a simple solution. Don't use the text editor. At least not in the quick mode at least. We found that in average discussion in our forums, most user write a simple text without special formats. Therefore the default is simple text. While pressing the advanced edit button, we load the standard editing form with the default text editor for your site. Now let's be more technical. A responsive design for mobile means buy-buy table display. Everything has to fit in the display as much as possible. This means every page should be compatible for at least three resolutions. And here we have the index page for a forum in our forum. And actually here you have almost the exact amount of information you have here just organized differently with buttons and also collapsible content. Now fitting a page for a screen reader requires selecting a structure that will help you to navigate faster and easier. Building in this structure for example, we look visually the same, but for a screen reader there is a difference that helps in navigating in the page and also jump to other section in it very fast. It also requires thinking some of the method that we're looking for a pretty standard approach for me at least. For instance using links for focus anchors and user actions instead of making an element to appear like another element, sometimes not always, sometimes just simpler to use the other element. In this example actually, some of the screen reader will say heading level three link or if you ever click on it it will say heading level three visited link but it's not the link at all. Here it will just say heading level three. Now let's stay in the interface. A dynamic interface requires not only design but also a fair amount of front-end coding. And this code also has to know how to talk to screen reader as well. For instance, this is the recommendation button that enables the instructor to recommend a certain post to the students. Now how can the screen reader know if the action happened and more importantly what if it failed? So I found a solution. Don't know if it's the best one. It works for me. The button has an aria label for the screen reader. And now I will demonstrate what happens if the action failed. You get a visual view and I'll do it again. And the screen reader read action failed in about a few seconds. It resets. Now also a responsive forum page raised the need to build new components. Between them a new type of button that can chain its behavior according to screen size. Here's our subscription button for the forum. On the desktop display the button acts as usual but on the compact display it turns into a menu to do the same thing. And this is the same button. The method of hiding element and replacing it with another one for any means may be easier but it does have the potential to make a user with screen reader or just one with keyboard lose its place because the former clicked element has disappeared and you can potentially lose your focus and start back from the beginning. So maybe I'll just show you the forum itself. Here you have a forum page with two discussions. It's collapsible as default. This one is open. User with capabilities can pin a discussion, lock it for replies, recommend it for other user or mark it for personal use. We added three types of flags so all users can make their own personal categories. The rest of the action are in the menu and somewhere is also dynamic as well. You can delete the permalink has its own dialogue and even send by email is also dynamic. You can actually send to several users the same post of discussion in a matter of seconds. You don't leave the page. Let's hope this works. Here's a screen grab of some of the action I talked about. I'll start a new discussion. There it is. Now let's add a reply. Change the default heading. You can notice the reply amount has changed. Now add another reply to the discussion. Let's flag it for personal use, red flag and also recommend it for students. Let's flag it for another color. Here's the send by email just to show you the dialogue. Notice this also has advanced added to the usual user forward page. The link to post, you can just copy the link for later use. Let's delete the whole discussion. We never left the page. Another feature, the form recognized formulas and photos and can show it in a responsive gallery. Very good for small screens. That's a live display. I want to talk about dynamic a bit. For every action there is an equal and opposite feedback. In a dynamic page there should be a proper response for every possible activity you can think of. For instance, the discussion the user is writing a very large reply and at the same time a teacher in his own computer has locked the discussion from a reply. What happens when you use a click send? What do we do? We need to give a proper feedback. So the user also won't lose all of the content he wrote for the last five minutes. So for every action it should be at least fair for successful actions, a failed action and some error handling procedures like the one I talked about. Otherwise you'll end up with a bunch of annoyed users. So the results supports many resolutions in a responsive design. We cannot use the mobile app unfortunately because we have too many third party plugins that we wrote. So this was our best solution. It supports all major browsers and also with compatibility to older version which means don't use the latest feature. If you see some new CSS feature and new HTML5 feature you have to check if it supports all the active mobile browsers and for example many people still use it to explore 11 and we have to support that. So we cannot use some of the cool features and use and support them. Also it hopefully completely has fit the accessibility standard for AA, screen reader, keyboard, contrast and all that. Wow, that was bad. That's it. You said something about not losing the responses written. I think auto editor, the auto editor has got another save. Is this also working on this kind of simplified editor? As of now, no, but it's a good point. We should do auto save to the text area. Thank you. Sorry, Juan. Thank you. So my question was are you thinking of looking at enabling your plug-ins for the mobile app with the new way that you can enhance the add-on? Enabling for the mobile app. I don't think so because we never develop anything for the mobile app and I don't think we will because we need to adapt everything to it. Hi there. I did some work on the middle room's advanced forum which I think faced some of the same problems and came up with some similar solutions. I think there are some other people that have done the same thing and I think it's a good sign when multiple people independently come up with similar solutions. I'm sorry, I can't hear you. Can you speak louder a bit? Okay. So I had worked on the middle room's forum which addressed many of the same issues and something I didn't get to do with that was to return some of those things to the core forum and I was wondering which elements from your work you felt were most able to be put back into the core forum so that everybody could benefit from them. Probably not all of it because it's fairly radical changes but is there any bits, small bits that could make a big difference? To the core. There are no core changes here. It was built to work on any model out of the box. Actually it was built for our version 3.1 and I've adapted it to 3.4 and that's where the screen shots came from my 3.4 on a booth theme. Actually it's not on the model plugin still on beta phase but it's on GitHub and if everyone wants it, I'm more than happy to give you the code to just use it on your own sites to play with it, do whatever you want with it. No core changes. It works and it relies only on what Moodle has to offer. Nothing else. Why are we all sitting separately developing our own forums? Can't we make these improvements in the Moodle core forum so everyone just gets them? That was kind of the previous question. Yeah, we just should do it. Dev Jam topic. Well, we should I think, yeah but we just have too many modifications of our own and we don't want to impose them on Moodle because we have our own demands and there will be conflicts if you want to, if you'll suggest some changes to the forum they won't actually go hand in hand with the current behavior the rest of the users in the world are used to. So if anyone wants to take some of the ideas and implement them in their own forums or even if one of these will be used in the core forum, that's not up for me to decide actually. So it's up to the Moodle HQ to decide if they want it. I don't want to impose anything on it. Does this answer questions? Well, I think this will be a good topic for... Yeah, but which features? Good topic for tomorrow, Dev Jam. When you were looking at accessibility requirements was one of the considerations for colorblind users. Yes. I'm just thinking because you had the flag icons which were the same icons with three different colors did you have to pick those colors particularly to make sure they contrast? It is, it is, yes. All the color plate is for, if you need miss one, you may have, it's for the colorblind. I have a last question. Have you noticed any improvements in Android or iOS screen readers? Because if I remember well in earlier versions they weren't very good. They weren't able to read properly the browser information. Have you tested? Have you noticed improvements in the screen readers that comes with Android and iOS? Improvements that... No, in the screen readers that, you know, the accessibility tools that comes with Android and iOS? You can activate accessibility tools there and they read what you see the browser information using these area levels. So my question was if you have noticed any improvement or if you are aware of that because I tested it in Android 4 and in iOS 8 a lot of time ago and they weren't very good reading the browser information. Even if the page was designed taking accessibility into account? Accessibility and Chrome. Well, the whole area of accessibility we have... I'm not sure I could answer your question. There are several screen reader engines. One of them is the Chrome and the Android and Apple has their own built-in. I haven't checked all of them. Yeah, maybe we can discuss later because it's just that I feel that they don't work as expected in mobile devices or tablets. I think these kind of tools work better in a computer, an adapter, in a real browser, but not in devices, small devices. That's my personal feeling, but it's something that I don't have proof to discuss. So thank you very much.