 Okay, so we'll come to our presentation. It's some kind of a workshop mostly about the UX and development interaction. So, it was a bit of a surprise for Haiko and Jan that they are actually sharing this presentation for me. So, we were sitting yesterday in the pub and I told Haiko, well, do you know that we have a presentation tomorrow and he remembered, okay, yes, we were talking about that. So, we have quickly created a survey like from the people that were joining our conversation there and there are some ideas like what should the talk contain. So, somebody was telling like, talk about color, like pictures and how you bike-shed about things in your design team. Somebody said, okay, well, I will avoid this show. Like it's too much in the morning and like too many people will be just having monologues there. And another one was how can I get involved, which was more positive, like approach to that. Then even somebody got further, like I'm interested in something and I want to do it and like how can I actually get involved. So, there were like nicer screenshots, stuff like that. So, like many opinions about things, many things to get together. So, we of course like analyzed that and created this talk based on that. So, let's get a bit more serious. So, I think it would be good to just tell a few words about like what has happened since the last year. Because like we had already the design team last year, but that like many things has changed in the meantime. So, like for me, the biggest thing that has changed is that Document Foundation now has HIKO as an employee. And so, like we can be like much more serious about the design in general, because like now we have a dedicated person for that. If there are things that need doing, we have somebody who has the experience, who has the time for that. So, like for me, it was one of the biggest achievement in the last year. HIKO was a long-term contribution, contributor to LibreOffice already. So, like he already knew all the processes, like how to do things. And what was very positive for me that he actually started running the design meetings that we have every Friday. And to which you are most welcome to come and join and be there. Another notable improvement that was since the last year was how we were handling the Google Summer of Code. Because in the past years, it was just the developers mentoring the Google Summer of Code. But like sometimes it was like based on the ideas from the design team. Sometimes it was just like from the developers how they thought that things should be done so that they work nicely or that they are done in some way. But this time, like there was some really actual like actual work between these two groups. So there were projects where really there was a mentor from the UX team and there was a mentor from the development team. And they just had to work somehow like very closely together so that the result is right. Then of course, there were lots of improvements and proposals and things that have been done. So if you want to see the details, of course, scan the release notes, which actually answers one of the proposal from the first slide, who wanted to see the screenshots before and after. Like release notes is the place where you can see that. You will see that like in the view or in the design of LibreOffice like lots of things changed. Other than that, the work of the design team, there were things that hasn't changed. So still, it is very important in general for the design team to see like what will be the end result. So as I like to say, like when the work is not in git, it hasn't happened. So it is so that like when you design something and you just do it for the fun of doing it, that's nice, that's fine, that's okay. But you are not doing it like completely. You still have to have in mind like how you will get it into LibreOffice in the end. So like, of course, one way of doing that is like actually if it is for example, update of some dialogue or improvement of some texting or better icons or anything, then if you can do it yourself and just get it to git or get somebody to help you, getting it to git, that's ideal. Of course, if you cannot do it, then you have to have a plan like how actually achieve that it will get into git. So again, some of code is very good for that, but like if you have a friend who has a developer and he's willing to work with you on your idea and actually apply it and get it to git for you, awesome as well. So just want to repeat, like it's very important to have a plan like how to actually get it into git in the end. And of course, like what we would like to do in the future, we would like increase this amount of people that are actually contributing to the design team, but also applying the ideas of either of the design team or of of course, like if the developer has an idea, like how to improve something, the best is to consult it with the design team. We are happy to help some way as much as we can and then get it implemented. I think one point that we forgot yesterday to add is the contribution by Yanni, the easy hacks. We increased our effort in easy hacks and added a couple of easy hacks from the design point of view, very simple things that can be done without any coding experience and also try to flag tickets in the backtrack as easy hacks, which is quite important and that's why Yanni is here. And I have two things. I'll start with the easy hacks, as you said. When you have made a new wonderful dialogue, you have made the UI file in Glade and talk with the UX team, then the next thing is you need to get it implemented and that's where you put it in Boxzilla. You mark it as an easy hack, typically topic UI. Then I will see it next morning and I will do the rest of it. I won't implement it, but I'll make sure it's a proper easy hack because a lot of, especially these dialogue things can be very easy to make. If you have just changed the layout, you need it added in Git and that's it, attach the UI to the Boxzilla and I'm sure some of our new contributors in development would be glad for an easy hack that type. Another thing is, I see regularly patches in Garrett that contains UI and all of these patches, as soon as there's a UI file involved or a change of workflow, then it automatically goes to the UX team for evaluation. So it's not to sort of say your work is bad, it is more that we want a consistent UI and therefore every change in the UI is passed by the UI UX team. I have a microphone. I have a microphone. Yes, and so like this way we are getting to like, what is the current workflow? So from the design point of view, like the two most important things are like, how do we communicate? So like in case there are ideas, in case like there are some concrete things to evaluate as he unset like for example, the patch to check or talk about, then of course like we have the IRC, it's the LibreOffice design on IRC3 node. We have a hangout every Friday at 2 p.m. of the European time. So it changes like when there's a shift from the daylight saving time to not daylight saving time. We have a mailing list, design and global LibreOffice. We have a blog where we communicate like what was achieved, but also like this blog communicates when there is for example a survey, when we want to get like ideas from people, like what should we do better or like when there is a proposal to get some feedback on that so that we can collect it and get some results from that. Then some people in the team are using Google Docs just because it's somehow convenient for them. And of course like some, the results that just need to be preserved in some like more structured way are on the wiki. But what we have forgot to get here is actually the Garrett itself because lots of communication is happening in Garrett as well because like when it is implemented, it just needs to be approved. And lots of people from the design team are actually in Garrett like approving the patches or posting patches as well. Let me like mention Jay and Adolfo who are very active in that. And also in the bugzilla. So in bugzilla if you can remind like what is the workflow in the bugzilla for the UX advice? First I wanted to add that we of course to also report in or discuss things in the etherpad. It is collected in all the other etherpads and from time to time we do some discussion not in the GDoc but in the pad. And some really short polls with the community are run on G-plus because it's very easy to ask the large liberal office community which has I think 6,000 members. Just ask the question do you know how to do this or that and you get a quick response with some 100 people. It supports the decision if you get a number of people to yeah it's just another argument. About the workflow in the bug tracker. Yeah the workflow in bugzilla depends on two things. If you have an idea that you want done then you can add a bugzilla report, mark it as enhancement or if it's a problem not as an enhancement but as a real bug. That will go through the normal workflow the UX people will look at it give their opinion and at some point it will be passed on to the developers. That is the more seldom case. We really recommend you come to IRC you use our mailing channels to discuss your ideas before you make a bug out of it. It's a lot easier for everybody. So on the other hand like it's not forbidden like a batch is appreciated all the time. So like if the first contribution is a batch without previous discussion that's perfectly fine as well. But like of course it's better to be more involved and yeah. The next step is you have actually made a new dialogue. I use that as an example. You have changed something in the UI. Then you put it the easiest way for you is actually to put it in bugzilla use the keyword easy hack use the keyword topic UI. Then it lands on my desk next morning. And what I will actually do is I look at it and see do we have any comments from the UX team? If not pass it to them otherwise pass it to the development. And typically you will see these easy hacks are very very interesting for developers because they are pretty easy to implement and the new contributor can see something. If he makes a change to one of the C++ classes which I find very intriguing but it has no effect. He can't show his friends I made this. And the effect of I made this is what gets a lot of contributors to come in. So your easy hacks in that respect is very very welcome. And so now we are coming to the question or a bit of a discussion if we can have it here. So what could we do better? What is your feeling or your experience with interacting with us as the design team? What can we do better together? And stuff like that. Just from the development side I think what might be helpful for the likes of me is short kind of direction statements from the UI team. Not like a huge big document but just a general thing such as for example Tula bars aren't really the future for Leera Office. Sidebar is where most activity should take place in the future, issues like that. So we have sidebar issues, we have tool bars, we have menus. There seems to be a lot of activity mostly in moving things to the sidebar. Is that kind of where we should focus most things on? So did I understand correctly you are asking about what is the direction? Yeah I don't mean like where is the direction of Leera Office but just like what as a developer we should look at for user interface stuff. So will new things go into the sidebar? Is that a direction that we're going in? Like there seems to be additional things being added to the sidebar. I mean that seems like reasonable direction but is that the case? That's a very hard question I would say. That's a very hard question. Just because like we in the design team just cannot decide ourselves yet. So basically we are experimenting with many things. You can see that for example J has done a lot in the direction of having sidebar as the main thing. So you could have seen it already in press that like when you are editing some text or so and want to apply the attributes on that that it's in the sidebar. And like the main toolbar is there like mostly for the operations with the document but not for the attributes. On the other hand like there was just a Google summer of code that like allows you to like get UI files directly like instead of the toolbars or even instead of the like the entire toolbar and menu area which is kind of orthogonal to this. So we are still in the face of a bit of experimenting. I do not have any strict view on that but like if Heiko has some more strict view on that then... In short it's a question that goes a little bit beyond the workshop here that we can do better. It's a question about where are we going or heading with the sidebar, right? We drafted a guideline and the guideline says toolbar is for access to frequently used functions. You open a file from the toolbar, you save the file. One click, save, and it's gone. If you modify properties it is nothing which has to be located in the toolbar so features go to the sidebar. And I would say it's also something which needs to be frequently used. For my taste it has not been followed so frequently a part of the use thing. It is a container for properties that are changed in the document more or less frequently. So if I hear some concerns from your side that the sidebar gets a little bit flooded, maybe yes. I would really appreciate if we get some more configuration into the program. Things that we do with the new toolbars, the extended toolbar, Muffin, Robin, or however you want to call it, you can switch easily between two or more toolbars that it's workflow oriented. Or user oriented. If a user wants a simpler toolbar, he loads, if he wants to switch to something an expert feature, it could be done quite easily. And if you get something similar for the sidebar it expands the possibilities in a way that makes everybody happy. So configurability is one goal in the future. Just from my side, we are, as Candy says, discussing those issues. But unfortunately, no good answer yet. Thank you very much. So something about more in the general, would you like us to reach more to you or you are happy with how we are interacting with development or any change necessary? Did we offend you some way? That's good. Did we make you happy in some way? I mean, we made you happy. So tell us about that. Yeah, thank you. Maybe one suggestion. You talked about workflow and people talking about UI stuff and I think there will be a lot of work talking back to them. We want this like that and we have some design rules. We would like to have that stuff in the sidebar, that stuff in the toolbars. How about writing that down on the VQ or something? Maybe it's already done. So you don't have to explain it to everyone every time again. Just some basic design rules. And don't call it rules. It sounds limiting and suppressing. Design suggestions or something like that. Best designs for a LibreOffice. Or what we want to do. Yes, so actually we have some kind of document. That's one of the things on which we have been working in the last year. But again, as you say, we do not want to do that strictly. So it is more in the direction of we have found a problem that people are not decided like how to do things. So it is described in this, how is it called? Guidelines. Guidelines, guidelines, guidelines. Guidelines is not bad. Optimal I think would be some pages which you read as a newcomer and you are so motivated and have not seen anything pressing you but you are directed in the direction you want to have. And so one example of the application of the guidelines actually was the rework of the menus. Because we discussed that before Jay did the actual changes. So one of the visible or very visible things in the guidelines was that we have set a limit of how many things can be in the menu so that you do not get menus that are over the entire screen. And so in the menus, it was set as like 20 items as the maximum. And then of course we tried based on the information that we had. So mostly the results from the old research, so based on the use, it was organized into the submenus. And having that in the guidelines, they're easy for us. Because then when there was confusion, somebody told us, you have moved my favorite feature to a submenu. Then the answer was, sorry, but we had it in the guidelines. It was a decision that we just need to do it some way to fit the 20 items. So bad luck. Your feature is not that used as the other features in there. It was the out-of-time sign, it's a pity, but my reply to get it together with the development team, there's a discussion ongoing to improve the Get Involved page, some landing page where people read information about the project, how to do things, there is effort planned to improve the situation. And what I take from your argument is that we need it for the design team as well, a Get Involved page. It could be really great to do it in a similar way that it, for instance, has the same branding, same look and feel. Yeah. Did you know what's the argument? Yes. That's how it links to the developers. Great. Great suggestion. So thank you so much. So if you have anything else, please do reach us. The presentation contains the details about how to contact us. We will be very happy to hear from you. Thank you so much.