 So, hello. As you already said, the talk today is about EFL focus. First of all, a little introduction to people who don't know what EFL is. So, EFL is just a graphical framework that you can use to build up UI applications. It works on many display protocols, it works on many operating systems, and basically it looks like that. So, this is a little example of an invitation you could get at your desktop, which just invites you to a random meeting, which is today here in Brussels. You have two buttons below that, one of them is the Attent button and one of them is the Dismiss button. What you can see here is that the Attent button has a blue rectangle around it, which indicates that this button has focus. So, and what focus in EFL actually is, is it is a property which is unique on the UI, which means the whole window always has only one widget which has focus. The focus widget in the UI is also used to inject keyboard events. So, an example of before, if you would press the Enter key, then the Attent button would get at first the keystroke for the Enter keystroke. Who can get focus in EFL application? We have divided basically the whole set of widgets into two types of widgets. There are focusable widgets and unfocusable widgets. To the focusable widgets we have buttons, the entry and the time picker, and the unfocusable actually is something like a labels or image. The reason they are unfocusable or focusable is, for example, a label does not have any defined feature or defined function on them. They are just rendered on screen and they are not specially used. There is no feature on them when you press a key. However, a button, for example, gets a click event if you press Enter. An entry hopefully changes its content if you press some keys. And the calendar, for example, wants to change the month when you press the plus or minus key. In our example from before, this means that there are the different widgets of the text field above and the text field below. So, the title and the description of the meeting is actually not focusable. However, the buttons below are focusable. You could use them with a keystroke. While you see this like this, focus can also be moved in an application. And logically, focus moves always there where you click with the mouse button if there is the interaction with the widget. However, you can also move focus while using the arrow keys on your keyboard. And you may also know focus movement, for example, from your browser. If you have a website which is rendered like Facebook or something and you press tap, then you will see that a little dotted line will go around the links you have on your Facebook site. EFL, however, extends this model a little bit to the relations of up, down, right and left. And the difference from those four and those two are that next and previous is actually more logical based, which means the focus movement for next and previous is calculated based on how your UI is built up or how your HTML site in Facebook, for example, is built up. The relations up, down, right and left are actually coordination based, which means they depend on the position where they are on the screen. And calculating them is a little bit more complex than just the logical based ones, because you have the whole set of widgets on your screen which are part of your application, which can be quite big. And it's more effort to calculate than just walking a tree like for the next and previous. So in our example, this means that our attempt button now has focus and if we press, for example, the right key, then the blue rectangle will move to dismiss over there. And in this example, there's no instance for up, down or left. So the task in EFL that we are trying to solve with graph is actually we try to find the best candidate for each focusable widget on the UI. And the first approach for solving this could be actually we just take the set of vertices and say this is just our focusable widget. And then we search the smallest distance between the widgets. This small idea is good for forming the problem. However, there are a few problems. And the problem number one is actually defining the distance function. And the problem with that is that the physical distance on the screen is not always what the user expects to happen. So the simple distance function of a distance was not enough to respect what the user would expect. So we've broken this up into a little tuple which has in the first place a class and in the second place a distance. And what we try to do here is we try to minimize the class and then we try to find for the smallest class, we find the smallest distance. And the class in our EFL is between one and three and the distance, yeah, just whatever the distance on the screen is. And the classes can be divided into something like that. So what you see here is actually our reference widget and our candidate. And what showed up when we've been talking to users is that if the white widget here is in the shadow of the blue widget, which means directly on the left side and not above the reference widget and not below the reference widget, then the user expects this widget to be, in this case, the left widget. And a class one candidate, a class two candidate, however, would be within those two angles and would be not in class one, obviously. And a class three candidate would just be on the left side of the reference widget. So all in all this look, if we take an example like that and we say this is our reference widget, then we would say that this here is actually our closest widget for the reference of this widget because those are not in the same class. And even this model looks a bit obscure and strange. This was actually what met the perception of the user, the closest, so we kept this. And also this here was just an example for the left relation. You obviously can just convert it to the other relations by turning it by 90 degrees into each direction. So the second problem is that actually widgets can intersect on the screen. And the reason for that is when we look at our example again and extend it a little bit, now we have their list in our pop-up with the list of attendees to our meeting. And after on the right side of each name you will have a button now that you can click to email for example this guy whose name is there. To the user this looks like that, however internally it looks like this because the list of users that is attended in this UI, appended to this UI is that big and it just hides beyond the scroller and it's just not random debuff but it's still there. So what you see here is that this button, those two buttons are colliding with each other. So calculating or distance or relation there does not really work out well and the solution for this was basically that we split it up the graph, the one big graph into multiple smaller graphs where we say we have one graph per layer and a few widgets to define new layers. And when a widget is defining a new layer then we just register the new layer in the graph above or below and calculate the relations in the one graph and in the other graph. We call the graph which is the actual graph of the window main graph and the graph in the scroller we just call a sub graph and there can be multiple sub graphs in one window. With this solution we have actually solved the problem of intersecting widgets, however we have introduced a new problem and that is we need to interact between the layers and we need to do that in a way that a user expects things to happen like that to meet his what he expects and we also need to form it in a way that a user still can explore a UI and finds every single element and UI navigation is not super complex and therefore a problem is that doing those interactions heavily depends on the type of widget that you have and the mode which can be basically broken down that are implemented in EFL are three different and there's the sub graph isolation the sub graph movement and the sub graph jumping and sub graph isolation is basically what you can refer to as the pop-up case. So if you imagine you have a UI where you are doing some work for example you are creating a presentation in Microsoft PowerPoint then you want to save it and it pops up some question asking you and you need to answer yes or no then you probably don't want the user to escape with this intention back to the window if there's still a pop-up on your screen so what happens is that we have a little sub graph down here which has three registered buttons and behind some content where you could have worked in and now it is not possible to escape the focus here just by moving around you rather have to do some explicit operation like pressing escape or so. The next mode we had was the sub graph movement and back to the example that I've brought in before is when we now press let's let's say we are in the state of we are having focus on dismiss and we are pressing up then we probably want to move focus onto the last element under scroller which logically means we move this the content of the scroller over here up as wide as we can so the lowest button is here and the focus would move from that is miss button one up the reason we do this on the one or the other widget is we want to encounter the user to explore the whole UI so he doesn't just get jumped into a part of the UI where he does not know why he is there and then it's randomly moved around however other situations like a property on like a property UI you probably want to move focus into something which is scrollable however where you have selected your option before and this then we call sub graph jumping this would be for example if you click dismiss here sorry if you have to focus on this miss here and you move up you would have to focus at button here and then the user however needs to explore the whole scroller on his own so this is how EFL forms this graph we have the layers in the scroller and in the main window and in a more complex UI it happens quite fast that we have a lot of widgets so we have also a lot of graphs where we interact with each other and a little introduction to what was there before before this was implemented so as you know a UI is basically built up as a tree and before it was a graph for the up down right left relations we did nothing else than just walking up the parent chain of the tree and then looking into the sub children and just looking for widgets which might be there and then calculate the distance however the problem was those results could barely be caged because there was basically no place for them to be caged and there was no clear structure where they could have been so the advantages of the new solution that we started to use a graph is actually that we have a defined data structure where we can get information from what also turned out is that we have fewer redirections in terms of pointer redirections in C which made the new solution actually faster than electricity which is quite nice and we have found a wonderful way to cage results because our graphs we can we can check if our graphs are moved or not and when they are moved we can check if either the whole set of vertices is moved or just a subset of vertices of one graph is moved and if the whole graph is moved then we don't need to recalculate the relations because the relative relations within the widgets of one graph did not really change and if we go back to this example then you can see that scrolling around here the scroller does not invalidate any single relation that we have calculated before which makes the whole thing very fewer recalculations than compared to electricity however the case which is not covered is when for example a few widgets here in the middle would just disappear then we still need to recalculate the relations because we don't have the assertion that the other relations are stable um what is also perfect about the solution is we don't have any kai day tree or any speeding up in from speeding up technology implemented yet in the focus graph calculation itself right now we really just calculate every single tuple that we have and we are already faster than what we had before so we still have a giant potential of getting faster however there is one problem compared to before and that is we register the set of focusable widgets when the ui is starting up and that is actually slower than what we had before because before there was basically no relations because we were not forming any graphs so this somehow makes the startup time and the first frame time of the application a little bit slower but overall in the application itself when it's there and we just do benchmarks like scrolling around in a scroller so we have a lot of movement um this does not slow down the ui anymore so with what I already have said now is that we don't really have any optimizations in the graph calculation itself implemented so if you have any questions or comments like if there are any experience on if someone already implemented something like that then I'm very happy to hear that and that's most basically the talk thanks so much so one for me so this is now very specific to the ui component yes um have you seen so other folks have used graphs for other kinds of dialogue control uh do you see any kind of similarities between like visual layout of components and for instance temporal layout of components so that you kind of find also distances in like other ways of where people interact with complex navigation networks you looked at things like that as well not really yet because to be honest doing those patches in EFL the most work of that moved into adjusting every single widget and finding every single bug which was a lot of work and it was only a year that was worked on it for a single person so wasn't much work into optimization um that's definitely something that a ui designer might do however you probably want to have the question was if ui designer isn't the one in charge who is defining what is on the left side of reference widget and there might be wishes and there is a possibility to implement special cases however you want a base system which gives you the best result in a in a general purpose application because for example someone developing a EFL application in its free time probably doesn't want to go through every single widget in its ui and saying okay that is the left button that is the right button that is the top relation and that is the down relation and therefore we have come up with with this function so we have a good general purpose result