WEBVTT 00:00.000 --> 00:15.440 Hello, I am Matilda Sitch from Colabora and I will speak loud, I will try to speak loud, 00:15.440 --> 00:16.440 okay? 00:16.440 --> 00:21.000 I will speak about a cool UI command tracking and another reason. 00:21.000 --> 00:26.000 First, why do we need it? 00:26.000 --> 00:34.680 Well, at the UI, there is a question always that how should the UI elements be, how big 00:34.680 --> 00:40.520 there should be what kind of image, what kind of name, should be and where should we place 00:40.520 --> 00:49.840 this UI elements where we can have a lot of theories to do it, but we can also check what 00:49.840 --> 00:56.840 users do it, and figure out some problems maybe only if it's good, like if they 00:56.840 --> 01:07.240 undo most of these times, then maybe the UI element is not perfect and we can also check 01:07.240 --> 01:16.520 how much the users use them, there is a lot of other ways how we can use this kind of 01:16.520 --> 01:17.520 flux. 01:17.520 --> 01:25.960 For example, I made a screenshot from another application where we can see the paste button is 01:25.960 --> 01:33.320 much bigger than the copy and the cut, and I heard that there are some statistics about 01:33.320 --> 01:39.920 what the users do, and they see that the paste used much, much more than the copy and the 01:39.920 --> 01:46.640 cut, and so they just increase the button to be sure that the user can much easily use 01:46.640 --> 01:47.640 that. 01:47.640 --> 01:59.720 So, let's see what we got from it, this lags made from 12 days, so it's not a huge time 01:59.720 --> 02:08.120 in Taiwan yet, but you can see that the paste and the copy is nearly the same in our cases, 02:08.120 --> 02:18.480 but sure the cut is used 10 times less than the paste or the copy, maybe or users 02:18.480 --> 02:26.000 use it differently, however, there is another option that we only counted the you know 02:26.000 --> 02:36.360 paste and the you know copy command, and it can be a button, but it can also be generated 02:36.360 --> 02:46.680 by keyboard shortcuts, so maybe we could separate them and we could get different stats, 02:46.680 --> 02:53.520 maybe the other application they can't eat only the button clicks and that could result 02:53.520 --> 03:01.600 the difference, but all other stats could be useful, for example, it's good to see that 03:01.680 --> 03:10.320 we use most of the times for texting, but all of the moves movement is more in this case, 03:10.320 --> 03:18.680 and it's also good to see that removing text is much less than the input text, but we can 03:18.680 --> 03:29.400 see that 400,000 characters were inputed by users in these 12 days, and that we have 03:29.480 --> 03:38.520 other stats, for example, what was undoed, we can also see that the paste was undoed 03:38.520 --> 03:48.080 very many times, it can be a logical, I think if you paste somewhere and oh we have to paste 03:48.080 --> 03:53.840 it's one character, later than we undo it and go away and paste it again, maybe that's 03:53.920 --> 04:02.920 right, more, there is a strange problem here that we have an unknown command with undoed, 04:02.920 --> 04:11.840 but it's because there is a bit of problem, it was not able to connect R, undo with 04:11.840 --> 04:21.080 undo and do at command, or undo a command, we can improve it later, but I think this 04:21.080 --> 04:28.840 that's does not seem to be bad, but for example, the last, in the table, the table cell background 04:28.840 --> 04:40.520 color was used only 12, 21 times, but it was undoed five times, we could say that it's 04:40.520 --> 04:48.760 many of them was undoed, maybe it's not the best, but it seems not so bad at all, we have 04:48.760 --> 04:57.920 other statistics like typing speed, it's not important, it's just interesting, command transition, 04:57.920 --> 05:14.480 for example, it's logical that, then it was used mouse clicks only 25 times, but it was used 05:14.480 --> 05:21.920 a lot of text input or other navigation, it's logical if we click, then it will ruin all 05:21.920 --> 05:33.880 navigation, so we don't click many times if we are using navigation, but in other statistics 05:33.880 --> 05:45.280 are using, for example, we can see that many cases there was not even one user, I mean 05:45.280 --> 05:54.760 that is more than 20 times more times, documents was opened only by application, like converting 05:54.760 --> 06:03.840 it or something like that, and for example, we can see how many people was editing or 06:04.400 --> 06:15.320 just viewing, this information can help us figure out how to set up servers for them, and 06:15.320 --> 06:22.120 many other cases, but we can use it for, and about how to implement it at first it was 06:22.120 --> 06:29.240 seems, it's very easy, we just find a function where other commands go, I find the function 06:29.320 --> 06:35.840 in the server, and we just look these commands and then make some statistics, it's very 06:35.840 --> 06:44.320 easy, but in the reality it's much more complex, for example, I mentioned that paste, 06:44.320 --> 06:54.200 baton or keyboard, if we want to separate them, then it's not enough to check in the server, 06:54.280 --> 07:01.480 we have to somehow find it from the UI as so, which it can be find in the client, but in 07:01.480 --> 07:08.920 the client side code, it's not in one place, so if we want to check them there, we should 07:08.920 --> 07:18.280 make codes everywhere or on the source code, so I decided to keep it in the server side, 07:18.280 --> 07:27.320 but we still can fix this by making separate commands for the batons, and separate 07:27.320 --> 07:36.760 you know, command for the keyboard, and then it can be done, another question was, what 07:36.760 --> 07:44.640 do we want to log, what kind of statistics we are, because this is very subjective things, 07:44.720 --> 07:51.120 like for example, the client visible area, this is a command we get, but it's not directly made 07:51.120 --> 07:59.520 by the user, so we thought that it's not needed, but we can, if we want such statistics like 07:59.520 --> 08:07.200 how many times the user done something that the visible area changed, then we have to log it, 08:07.280 --> 08:15.840 so I rather made a configurable point to the code where we can list what kind of code 08:15.840 --> 08:23.360 commands we want to log and what do we, we don't want to log, and another complexity that 08:24.160 --> 08:30.720 what should we do with the parameter, so if it, because in some case, we need this parameter, 08:30.720 --> 08:38.400 for example, in the k command, it can be a space or an arrow, and sure we need this information 08:38.400 --> 08:47.200 what it is, but if we are typing text, we must not log the text that the user typed, 08:47.840 --> 08:58.720 because we have to make it anonymous, and another complexity is that how to 08:59.280 --> 09:10.560 count the andro, I mean, now I do, it's like that there is a vector in the core that contains 09:10.560 --> 09:18.560 either an ando state, when we change the document then it will add an ando state that we can 09:18.560 --> 09:28.000 use for ando, and if before the command, and after the command, I check this vector and it 09:28.160 --> 09:37.280 changed and I, I will log that the ando state has changed, it gets one more and or one less, 09:37.280 --> 09:48.160 element, it has other problems, but I rather skip them, now and the match thing is again 09:48.800 --> 09:56.400 complexity, because we don't want to log one handy times that someone write it one letter, 09:56.480 --> 10:06.800 the other one to have only one line that there was 100 letter typed in, and this is even not 10:06.800 --> 10:13.680 so easy, because at first we talked with one to murder everything, but in then that was things 10:13.680 --> 10:19.360 that we want, we don't want to merge, for example, the key commands, if we merge everything, 10:19.360 --> 10:32.880 then we will not see which is navigation or we ended up to save, log this information like up or 10:32.880 --> 10:44.320 write or page up, not like a 9 navigation, another complexity was that we have to convert some of 10:44.320 --> 10:53.120 the commands, because like if the user made a most click, it video sees most than and the mouse 10:53.120 --> 10:59.760 up, but we don't want this information, it would be enough to log only just a mouse click, 11:01.360 --> 11:09.920 in other cases, for example, the key command can be a space or an enter, but this is more like a 11:09.920 --> 11:17.840 text, so we should log it as a text input, but other cases if the key was an arrow key, then it should 11:17.840 --> 11:27.520 be not a text input, so in the run time we have to convert even these commands, and we also have to 11:27.520 --> 11:36.800 care about if the control the shift key was pushed to, and even more complexity is that 11:36.880 --> 11:48.240 multi user and multi document, where we have to separately keep track on every user, what 11:48.240 --> 11:59.680 commands was they last last commands was used for merging, and we have to keep what commands 12:00.000 --> 12:09.600 are undoable, if you use an undo, we can choose what was undoed, in the multi document, 12:09.600 --> 12:17.920 please, we had some problems with the logging system, I tried to try the more things, because I think 12:17.920 --> 12:29.600 I don't have much time, so, and there are more problems about the merge, we can lose the order, 12:30.320 --> 12:42.080 if you want to log at run time and log at merge at run time, then we have a logical problem 12:42.080 --> 12:49.920 with the order, because we cannot log the command until we figure out that the user 12:49.920 --> 12:57.760 started to do something else, I mean if the user run start to type and he doing it for a long time, 12:57.760 --> 13:08.800 okay, then if you have one type along and the user to just join in and do something and 13:08.800 --> 13:16.160 quit, then the user to be logged, but the user one will still not log, because he still try typing and 13:16.160 --> 13:22.640 it don't see, then he will stop, but once user run stop typing and do something else, 13:22.640 --> 13:29.600 it will be loaded after the second user, but with an earlier time stem, it's the 13:29.680 --> 13:47.040 order, but we can fix it, but we can fix this order at a later time, in this case in the 13:47.040 --> 13:55.440 script that makes the statistics, there was other complications like there are, there are no user 13:55.520 --> 14:02.320 in the sessions in the combat application of something like that, and sure we had to make a 14:02.320 --> 14:12.960 script to make statistics about it, and this is just an example of the lock five, but we are 14:12.960 --> 14:22.960 now logged in, and I think I should finish now.