 So, good afternoon, I'd like to present to you ideas to, yeah, people should really, can I have your attention please? Okay, so basically what we want to present here is some discussion we had inside the Document Foundation in how to modernize and to bring to 2017 the LibreOffice Help. What we have in the user knowledge ecosystem is that we have the help system that is bundled in LibreOffice. We have user guides and books that are written and published by the community. We have a very extensive Wiki for a lot of information gathering. We have an Askbot, it's a question and answer website for the end user and we also use mailing list. And also the user is able to look into Google for information. Sometimes brown some videos in YouTube. There is also a partial open office forums and Wikis and also independent forums like Reddit and so on. Okay, so this is the universe of information that you can get for the LibreOffice technology. So what we have at the moment is the following. The LibreOffice Help is designed into XML and it was designed about circa 2005. And at that time we had issues with browsers. The browser's war was full. No compatibility, no browser manufacture was comfortable in adopting standards. So at that time Sun Microsystem adopted an internal only solution which is a specific XML to hold the contents and the navigation of the help system. The internal browser is write a web. That was easy because you just have one tool and you don't need to test with several other browsers. So then they developed a C++ wrapper to create an index and to connect the dialogues to the help pages. The issue is that now when you look at 2017 we have a complex way to edit and update, how to test and visualize the XML that is written for LibreOffice. There is no rich text editor available. So what we have is a help authority extension that you connect in your writer document and then you start writing your help page. The problem is you need quite a lot of skills in XML and specificity of the schema to understand what the help content is. So for end users and for people that wants to collaborate there is a quite steep entry barrier to start writing help files. It's also we consider it's an obsolete technology and for example we cannot insert in the help content we cannot insert multimedia. We can insert images but not videos. So this is a very old way to assist the user. Looks old and cumbersome to read because it's fully textual, it's terse in terms of information, no animation, no videos. So the idea is to move forward and to get a better LibreOffice help. So some requirements that we have in this challenge is first of all preserve the legacy content. We are not going to write again everything. So we have to use what we have and transform it into something better. We want to lower the barrier for the community participation. So make it easy for the newcomer to start contributing to the help content. It's much needed to give volunteers an objective to contribute some of the community is eager to contribute but they are not skilled for development and they want to add to be part of the team and by writing help pages, by giving to everybody their knowledge, it's a good way for that. We want an easy to update and easy to track software development. We want a dynamic, vivid and pleasant way to read and watch. Use modern technology for animations, videos, support the current process of translations because in LibreOffice we have at least 30 to 50 active language out of more than 100. An easy way to find information in online websites and to work online and offline because in some locations you don't have access to an internet. So basically the idea is to start phasing out the XHP technology and perhaps this is just a suggestion, start phasing in HTML5 which contains a lot of improvements from HTML and at that time, 10 years after the XHP design, HTML5 seems to cover most of the requirements. Also to assist the offline help is to develop a small JavaScript page server. You load a page that has JavaScript and the JavaScript will help you in the navigation. So why phasing out this XML? Well, the XML and ex-edit transformation has issues. It's not so standardized as we see for common HTML5. I spent a lot of time discovering that the transformation works in one browser, it doesn't work in the other. So there is a difference and we would like to avoid to have to be very specific to a given browser. And also it's not XSLT, it's not a technology that is so easy to get in the first glimpse. You need to study on that, understand what the transformation is doing. So it's a steep ramping for Neophytes and the community contributions and updates on new contents. XSLT is not by very few. It was important maybe 10 years ago, but today I don't think we are using that much this technology. So what I see in the W3C website is that this seems to be a technology that is slowly phasing out. So we have this browser difference in the implementation of these pair of technologies and I think that it's becoming obsolete too, replaced by a richer HTML. So this small JavaScript microserver will be used too. First, display the correct help page required by LibreOffice application so that when you click in the help button in your dialogue you need to go to the right help page. It uses most of the resources such as navigation, history, bookmarking, caching included in any major browser. Handle the indexing and searching text among pages so that we can find and look for a specific string or a specific keyword and get a list of pages. And perhaps supports the old XML and the new HTML simultaneously. Well, this is basically the idea that we have in terms of evolving the help content and the help technology. I have been spending a lot of time looking at what we have. There is good, the results so far tested were quite encouraging and perhaps we have a good way to not open the help contents to a broader audience of contributors. So that's my message for you about the help on LibreOffice. I can take questions. Quite fast. No questions? Yes? We have a timeline for this implementation. No timeline. Exactly. We are working on the availability of time of any of the contributors so far. The foundation is analyzing a possibility of opening a tender to quickly have it implemented. The complexity is low in that case, but it's an extensive work. Some issues have to be considered, especially to preserve and support the translations of the contents. Nothing more? Okay, thank you.