Hello, we can start. Hello, hello.
Fantastic. Well, thank you so much for coming.
Look at all of you wonderful people.
Actually, let me put my glasses on so I can see you.
Ah, you look even better, close up. That's good.
So I'm going to talk a little bit about office documents.
One of the deep joys of the world of the moment is the so much excitement about digital sovereignty
and moving office sweets into a sovereign infrastructure.
And that's great. But then people think, well, office is easy.
Let me write my own. There's all this money out there for this.
Let me try and do that. The browser can do it for free for me.
So it's easy. There's almost an office suite in a web browser.
So let's just use that. And that would be great.
And so I'm just going to walk you through a few of the unanticipated, well, the ostrich is unanticipated.
And it unanticipated difficulties that you might experience when you try this.
So obviously, very easy things. People know about proportional text and monospace text.
And that's all great. Unicode solves everything until you hit the web dings and the wing dings.
And all that sort of thing. But it's easy to solve these problems.
You know, we need metric compatible fonts because the size of the glyphs is really important
because that determines the layout of your document.
But either way, it's easy to fix because we can embed these things.
And actually PDF does this. So PDF subsets all your fonts and sticks little bits of the menu PDF.
And so this is all very simple. Of course, the world is actually a little bit more complicated.
There are people there that are right to left. And that's obviously not very difficult.
You know, in a fine transform, we'll flip your screen.
You could just get some glasses that go the other way around.
Except it's not nearly as easy as that because there's mixed left to right and right to left text.
And the whole thing becomes rapidly quite problematic.
And then, of course, there's laying things out. So layout seems very simple.
I mean, you know, when you write a document by hand, it's all just fine, isn't it?
That's no problem at all.
But the problem is there's all sorts of complexities with text that you don't realize.
And as you start to lay it out, you discover,
well, it's a bit of a nightmare, isn't it?
This is a very simple layout problem.
So, you know, we've got, okay, so on the right hand side is a great example of auto-hyphenation,
not working in Google Docs.
And what hyphenation turns out to be difficult.
And that's great.
But unlike, or a little bit like writing your own programming language,
I don't know, lots of people write their own programming language.
It's very trendy to write your own programming languages.
You know, yeah, look at that. You know, excellent.
Some of us do.
I think there's a tourism of writing new programming languages, which is this.
By the time the debugger works, the language is obsolete, right?
And this is a fairly true of everything.
I mean, if you try and debug Java embedded in C embedded in C++,
you know, it's still, I just setting a breakpoint is, is anyway.
So, yeah, I mean, like, it seems really easy, doesn't it?
But actually, to do this right, you need, like, dictionary-based stemming, you know,
it's quite clever.
And that's before you get into smart justification,
where there's combination of, you know,
kerning and squeezing characters and shrinking spaces, and, you know,
an anti-phenation to try and make the text look as beautiful as possible
without huge jagged holes in it.
And let's know, NMF, who is sitting at the back here,
and waving at me.
No, yeah, is a hero of creating Hun spell and doing awesome things for this.
But forget even that difficulty,
because this is the rocket science, just a simple stuff.
You know, we're laying stuff out on the page,
and we're putting things in, and it's all going super well.
You know, we're playing Tetris, and it's just packing beautifully.
You know, we're going to hit the high score.
And then we think, well, we can get a bit more in the bottom,
or we get that in, and it brings with it a footnote.
Right?
But the footnote then changes the page size,
and now we have to shrink the page size.
Go back and see if we can fit it all in again.
And maybe we can, but that's actually changed the number of pages
in the document, and there's a page number field,
and that then forces the reflow, and now we can't fit it in,
or there's an image in it that's anchored to us anyway.
It all gets quite fun, quite fun.
And that's before we get to actually complicated text.
So I don't know, you know, who likes Ruby, you know?
And of course, Ruby is a programming language, I believe.
But it's also this wonderful way of somantically annotating Tokyo.
This is Tokyo, I believe.
I'm not very good at reading, but this is the English one there,
and I can read that one, right?
And actually there's whole bit of differences there,
and the great news is, and then of course vertical text.
So, you know, we use two web pages that you scroll downwards,
you know, that you keep going down and more and more text comes,
but some people scroll sideways, because their text goes,
goes like this, right?
And which is all fun, right?
It just adds to the rich variety of life,
and the good news is that if you use an HTML div,
and you actually do all of the extra coding and UI stuff
to make this work, then you can actually do this in the browser,
and that's great.
And the browser will lay it out for you, and that's beautiful.
The problem is that if you want to actually get whizzy,
we're getting, you can't leave the browser to its own devices.
You have to switch to using the canvas,
and then you have all this great control of where glyphs are,
and none of this is there for you.
So, that's great.
You rapidly hit this wall.
And then, of course, you want to print,
and that's easy, because as we all know,
browsers can print.
And that's great, isn't it?
Anyone who's printed a Google Maps or whatever,
and a notice, why is it crammed in the corner?
We'll know a little bit about paper sizes,
and the complete lack of API there in the browser.
You can't even work out what page size your printer has
from JavaScript.
You just have no idea.
So, it's a great thing we use the canvas to render,
because that's not going to print at all, really.
And we can then handle all that complex text,
and then generate PDFs and render it twice to make your print.
So, it, yes.
And of course, the browser is very frightened of,
yes, fingerprinting your devices,
so it loves to turn off things that
can tell you about your system.
So, anyway, we've done a bit of text, and that's all good,
but let's think about spreadsheets.
So, spreadsheets are, you know,
the source of never-ending fun, and a personal passion of mine.
And you see, if I can read this, what does it say?
Yeah.
So, we have more than two to the 32 possible cells
in a single sheet in a spreadsheet,
which is quite a lot.
Now, of course, almost no sheets actually have that much data,
because it will probably kill your machine,
unless you have a very efficient way of storing the data.
And so, we're doing pretty well.
We used to have this quite mad way of storing cells,
because it's a very sparse data structure,
which was essentially a row number,
and then a pointer to what was in the cell.
So, we just have these great swathlets of numbers,
which would typically go 1, 2, 3, 4, 5,
with a whole lot of pointers next to them.
Well, sometimes they wouldn't go 7.
They would go 8, you know, and it's exciting.
And it turns out that there's a thing called interpolation search.
I don't know if you've ever heard of it.
It's probably not a very popular computer science search form,
but it has a computational complexity of log log,
the number of things, which is the kind of complex to you want in life.
If you can get a log log in, that's really good.
We switched away from that, because of obvious problems with this method,
particularly pointer chasing is a nightmare,
and modern CPUs hate pointer chasing.
I mean, just caches, yeah, it just doesn't work basically.
And this is partly why Java is quite as slow as it is,
because everything's a pointer, you know?
But there you go.
So, we then did a whole lot of work to inline,
for example, great chunks of double, so you can use SSE,
accelerated arithmetic and so on on things.
It's just pretty cool.
And so we have now a much more compact and better structure,
and it's brilliant.
And you can thread it, and you can do SIMD, and it's great.
Or, you could use JavaScript.
And the implementation's here, you sparse arrays.
You know, it's just basically a hash table on the array index,
often down a row or a column.
And that's great, obviously.
And in theory, constant time look up, but in reality,
another massive pointer chasing disaster areas.
And you may think that this is not relevant,
but the component that first gave us the,
your zips are not 64 bits safe.
And we have streams inside these zips files that decompress
to more than four gigabytes of data, as we pass it was calc.
And this just does happen quite a lot.
And so talking of computation orders,
we have a fixed cost XML parser,
that will pass any size file in constant time.
And we want to heckle me?
Well, it's sort of true.
Basically, we thread it.
So there's a fixed cost of starting up the thread
and getting the parsing and the unzipping in one.
And as long as you consume and set up your structure,
slower than the parsic and pars,
you effectively get your parsing for free,
which is kind of nice when you have gigabytes of data.
Of course, in the JavaScript,
well, this is difficult to do to put it mildly,
because the threading model is not really as helpful,
as it could be.
So either way, we've made a beautiful,
entirely new office suite,
and we've solved the number of these problems
and made them beautiful.
And we're making beautiful looking documents.
They really look great,
but the problem is that there are trillions
of existing documents out there.
And the file formats are of mixed quality.
Let's say, some of them are nicer than others.
And yes, some of them have been wiped on before you get them.
And the problem with that is that you end up with things like this.
So in LibroFish and Calabro,
we have this wonderful tool that will render with Microsoft Office
and render with CalabroFish compared to you.
And where it's read, it was different.
And that's not good.
And you can see, basically,
maybe it looks like you've just got double vision or something,
and you have another drink, and it will look great.
But we can't afford that for all of our users.
You know, it's difficult.
So you need to fix it, and so it wants the problem.
While you look into it,
and you discover that actually the fix here is it's a compatibility level.
There are lots and lots of different ways
to render the same trillion documents, right?
And some of them are the old way,
and some of the new way.
And the number of ways is something like this.
Well, actually there's more than that.
It goes further back in time.
And in the infinite healthfulness of the standardization process,
you get a number that says,
do it, well, actually it doesn't say do it 13,
because there's some superstition in the Microsoft Office team,
amazingly.
But yeah, so you get a number,
and then not a whole lot of hints on how to do it differently.
So you think you're implementing one thing,
and actually you get to implement really a lot.
And that's because everybody is trying to improve their layout
and make it better and nicer and more beautiful,
but it's difficult to describe exactly what that means.
So layout is fundamentally not standardized.
It's not there in the specs.
You're not going to find any of it.
But actually it makes a really big difference.
Well, it can make a really big difference.
If you really care about the number of pages,
and it's got to be exactly right.
You know, if your MI6 or something,
you know, James Bond has to kill the guy on page seven.
You know, it's nice if that's not your contact,
due to some re-raping problem earlier in the document.
So then the other thing is little graphics.
So I mean, we have loads of nice little graphics in documents.
And you'll be pleased to know that the native vector format
for Microsoft Office is this wonderful thing called,
well, EMF, WMF, Metaphiles, EMF plus.
And what you see in these variants is that the rendering API
has changed in Windows over time.
And so all we have, ultimately, is an API dump
of the low-level Windows rendering API.
It's pretty much at the level of individual methods being called.
And so the great thing about that is if you have some random
component that's written by some crazy in your early object,
you can just copy what it's drawing on the screen,
and then someone else can do that again without that software.
Right? So it's a typical metaphor.
And the great thing is that WMF is the original Windows 16 API.
You know, it's just quite amazing.
Exclusive all renderings, you know, one bit masks everywhere.
No anti-aliasing, et cetera.
Obviously that didn't survive, well, it survived a very long time.
And then they wanted to extend it,
luckily it had a comment feature in it.
So inside your 16 bit, you know, or your terrible rendering of the past,
you can have a comment. And inside the comment,
is the EMF file.
Right? So that's great.
So there's then a duplicate rendering of a different API level.
And then, you know, EMF plus, which has a whole, whole, whole, whole.
It's just quite amazing.
And early objects inside these have a preview,
so you can rapidly render them.
So you can see stuff, but actually just common objects.
This, this, this thing here on the right.
These two things, this chart.
My chart doesn't render.
Why doesn't my chart render? You suck at charting.
Well, I just not a chart.
That's a massive legacy stream of vector graphic rendering,
madness that is being rendered properly,
and actually you just see a nice chart.
And the user doesn't have any understanding.
You have a life blissfully unconcerned about the horror that lies beneath,
that we have handled for them over so many years,
with so many people. So yes, thank you.
And of course, it's been extended over time this metaphyl.
So we have this, these nice little, little things like this,
you know, past through arbitrary data to the printer driver.
You know, so this is also used for printer drivers,
the back end, and so you can get post script inside your EMF,
anyway, just to give you sort of a flavor of the scale of the problem
that people love.
I talked about, I keep this being much loved.
It's not just the Windows metaphyl that's, you know,
the legacy of the 16 bit error.
You may wonder why when you look at the spreadsheet,
the document, the main document module,
is actually 10 files instead of 1.
It's the kind of thing that you think, well, that's a bit odd, isn't it?
And the answer is, the OS2, the brand new 32 bit operating system of,
well, you know, 30 years ago,
actually had a 16 bit token limit on the number of tokens,
it could pass in its C++ compiler.
So it was necessary at that time to split the modules,
each into less than that many tokens,
and 30 years later, it's still like that.
I mean, actually that's quite good for revision controls,
so you can see what happened.
Now, you may think that these are extreme examples,
but we could go on all day,
luckily I'm not going to, I don't have the time,
but let me tell you about smartart.
This is absolutely beautiful feature,
where you can generate from these bullets,
schema-driven, amazing graphical loveliness,
and, you know, this is great.
There's an even an XML spec for it,
with, you know, hundreds of abbreviated terms in it, you know?
And there's a constraint solver,
and a sheet layout language that goes on and on like this,
for hundreds upon hundreds of lines
to describe each shape.
And you have to write a rendering engine
that will follow these constraints,
understand them reverse engineer what they do,
and then draw that,
which looks very smiley and friendly, doesn't it?
It's just underneath it's all dry bones and horror, you know?
So there you go.
As they say often, you know,
people have this wonderful view of everything being nice and clean
and well done and an open and so on,
and actually they have absolutely no ideas
quite a famous saying, isn't it?
One of the things that I fear
is a plague of new duplicate lame office sweets.
So simplified that they don't really do much,
and assume a huge amount of money before they hit
the obvious roadblocks.
And with that money,
we can actually just improve the state of the art so much, you know?
So there you go.
Jeng is a win ski who is sort of an old, old,
and yes, well interesting, interesting chap.
Mozilla Hacker, one of the earlier Mozilla Hacker,
he talked about this CADT development model,
and this is a genome bug that he suffered.
And he was complaining that his bug,
as always, was closed with, I'm sorry,
and this entire subsystem, please try again, you know?
And yes, he, of course, ran, you know,
hardly seems worth even having a bug system.
If the pace of from scratch rewrites,
outstrips the pace of bug fixing,
now this is particularly problematic in a stack of software,
the people at the bottom of the stack need to be even more responsible
and people at the top, you know?
I just encourage that, and we'll see in a minute,
why that might be useful.
But when this cute naivety of everything is easy,
and we can rewrite everything,
and these other guys are idiots,
meets the quest for personal glory.
You know, I want to be the next Linus Torvals.
I'm going to call it Meeks Office, or whatever.
You know, it's just a bit lunatic.
And so this huge bent to try to reinvent the wheel,
and software is really hard.
So I think the, the take home thing is that there are just
so many axes, here are a few of them,
to getting just office software right.
And, you know, yeah, it's very easy to think of one of these.
So I tend to say this to a lot of people,
and they say, yeah, but collaboration, you know?
Collaboration is the killer feature, and it is.
I mean, collaboration made us use wikis,
and learn new markup languages with asterisk in them.
You know?
I'm going back to word five days.
It made us throw out wizi wik.
So, so all we need to do is first rewrite it all in language of choice.
Or, and then we'll rewrite everything to be,
operational, transform, CRDT, insert,
test, trendy technology.
And it's not just idiots saying you should rewrite it completely.
You know, there are major tech luminaries out there
saying that we should, we should really be doing this.
And 2009, thanks to the register for preserving that.
But let me just give you an example of a little rewrite.
This is a very simple one.
It has no file format impact.
It's a very simple refactor.
Ha ha.
Except we have quite a lot of user interface.
At 1,260, Glade style XML UI dialogs.
Quail on, spent multiple person years,
and was helped by many other people.
And if there is a 10x developer out there,
it's probably Quail on.
So, yes, a very simple thing, just rewriting the UI.
So, but instead, we should rewrite the whole core engine of our office sweep.
To use the amazingly popular Google Wave operational transforms model.
Yeah.
And the great news about this is you get undue for free.
And here was I thinking, so just to give you a sort of background,
there's a mathematical elegance to this.
You have operations and inverse operations,
and you can move things over each other.
And it's just wonderful with these transforms.
And everything looks very nice to a computer scientist.
It all sounds great.
And if you've only ever written small programs from scratch,
it sounds beautiful.
I totally agree.
Where we just start from scratch, maybe that would be a good idea, maybe.
But actually, undue is already quite easy.
You've got copy and paste, right?
You just copy it and stash it all somewhere and then shove it back.
You don't really even need to understand it, just put it back like it was, right?
So, yeah.
So, here's a great example of this spreadsheet.
You know, one guy does a sort of the cells,
the other guy enters 42.
And so, they get them in different orders.
And we have to work out which order is the right one.
But this guy is going to be the wrong one.
So, now we're going to swap this round.
We've already sorted, you know, 100,000 cells or something like that.
And now we need to work out where to put the 42 so that we change the right cell.
Yeah.
Otherwise, these models are going to get out of sync.
And life is not going to be a happy place, okay?
And that seems reasonably easy, right?
We just track where all the rows went and then we can, you know, find,
but there's a whole lot of complexity that you might not be thinking about here.
So, for example, you can actually, you can actually use random numbers in,
informially.
So, you know, you need to synchronize your random number generators
and make sure that they are in the same state.
But, you know, we can probably fit that in somewhere.
But you can also make random dependency chains.
So, cells can be dependent on or depend on things around them, right?
Or, you know, so it's not very clear who does what.
And of course, we need to calculate everything to the end.
So, we have the real numbers having changed something.
Otherwise, the source is going to be wrong.
And you're out of sync.
And, you know, what about those external data sources that we were downloading data from
somewhere in between?
Maybe that.
But, you know, what about that beautiful feature of not calculating everything all at once,
every time you type something, so that, you know, it's efficient and stuff.
You know, like, say the background calculations running.
So, all of these problems can be solved.
Nothing I've said is, in solve, solve, obviously.
But we're just talking about moving a editing a number,
which incidentally doesn't have to be in the range of cells that's being edited.
It could be anywhere in the sheet.
You can't tell.
So, you have to do all that work for this one pair of this one transform, right?
So, hooray, after we've done that, we've done this and that's brilliant.
But the problem is, this is only two operations.
As you increase the number of operations that you need to transform over each other,
the CPU complexity goes up, but that's nothing to the programmer complexity.
The programming complexity of sorting these goes with the square of the number of operations.
Okay?
We talked about log log search complexity.
How about squared programmer time complexity?
Yeah?
So, I mean, this is a great way.
Operational transformations are great.
And there's lots of hand waving about, but some of the operations are quite similar,
and, you know, we can bucket them and so on.
And obviously, Google Docs sort of works,
but this ends up, meaning you don't have many features.
Or you have a vast engineering team, or both.
So, CRDTs are then the latest fashion in this,
and, you know, they're absolutely ideal for very simple flat text.
But our real documents are not just complex in their file,
you know, they're standards and layout and memory representation,
but they're also complex on disk.
So, you know, we have these zipped file systems with embedded XML trees and millions of nodes in them, right?
And we mutate them really quite a lot.
And there's just a ton of invariants, you know,
if this is that, that there also has to be that.
There are implicit, there's no documentation for those.
And so, of course, probably something like this can be done.
There are people that have JSON trees that exist in CRDTs,
and often they use a separate table of GUIDs, you know,
these huge random numbers, to associate linkage and pointers and manage these,
and it's all very clever, and they try and hide that from you inside.
And that's all brilliant, until you try and save it in a file format.
Because the far form, I doesn't have any of that.
It doesn't have a massive table of GUIDs,
associating attributes with other attributes to try and make this work, right?
Yeah, and storing all of the state anyway, this never mind that.
There's a whole live conflicting constraint.
So, it's quite common that we get conflicts in constraints.
So, we get files that say, hey, your minimum cell height,
it's got to be at least this big, right?
But actually, the page size is only this big.
So, what do you do if you can't fit the minimum table cell height onto the page?
And it's not obvious, right?
Like there's a lot of ways you could do it.
And we try and we try and get this right,
but the world of office is full of invalid states,
and transitioning between one and another.
And so, you know, if you have your million monkeys typing your office productivity suite,
it's not going to produce anything valid anytime soon.
If that's going to produce a lot of very invalid things.
So, there you go.
So, here's another little UX win.
So, another thing, just changing the widget toolkit,
to use a native widget toolkit instead of the internal one.
Again, touching a whole native UI staff, again,
cray-lawn with help.
More multiple person years.
Again, no standards, problems, no complicated,
some staff, simple refactors, and just reusing things.
And we just got there in time to get native G2K3 dialogues
by the time G2K4 was released and totally broke our threading model.
So, there you are, you know, what can you do?
In order to save a few, you know, days of work
and improve windows, bindings or something,
they just broke it really badly.
Good news is it's the foundation for JavaScript dialogues,
which you're doing good.
So, anyhow, two better strands.
Better ways of doing this.
So, collaborative online, of course, uses online collaboration.
And that exploits people's misunderstanding of how fast the internet is.
So, do you know that you can get from Frankfurt to London,
quicker than your Bluetooth keyboard,
can get from your Bluetooth keyboard to the PC next to it.
Right?
Now, that's a pretty interesting result, isn't it?
And, you know, Frankfurt Milan is getting faster than your 60-hurt's frame time.
Right?
So, the internet is an unbelievable wonder of performance.
It's just extraordinary.
And, yeah, this is, I think, a look, no, this is a linear plot,
but you see the, you see the thing on our typing speed and our blinking speed.
You know, a human, a human eye blink.
That's a very fast human eye blink.
People say it's, you know, 200 milliseconds, please.
See, say by bringing everyone into one model,
we can do really well on having done that,
for the people who use their laptop and want on a train.
We can make their life much better.
We hackers understand a dipping, right?
We have dipping tools, and that's great.
We don't want to put ODF in get.
We just want to show people the differences, right?
What changed on one side and the other,
and make it really easy for the whole world to get changed tracking right?
Because it's really not currently easy.
So, another thing that we've been investing in
is improving user experience,
because actually the user experience is what the user's experience.
I know, I know, it took me weeks to work this out.
And so, we, we have lots of really, really cool data,
and actually the Zendis has done some great work
to actually build the analytics here to help us work out.
You know, which commands are used in what order?
Who undoes what?
What are they unhappy with?
What are the most popular things that are going on there?
How can we make it easier?
How can we make the contextual toolbar near where your mouse is?
So, you don't need that power assisted mouse anymore.
You know, to track all the way across your full case screen
up to the toolbar and back again, right?
It's just convenient.
And the tools in there are the tools that people use.
By frequency in order, close to where you are.
I'm context tooltabs so that you can, you know, find things that you want quickly
and get to the tools that you want.
Lots of new tabs to make things a prettier
and more easier to use, more functional.
And well, it goes on and on.
Look at all of these great things.
All of these features that we had already.
We didn't actually have to do much to write these.
We did a bit of JavaScript, a bit of cleanup,
a bit of clarification, some CSS and all of that.
Good stuff.
A responsive toolbar so that they fit nicely on your screen.
And, you know, I'm a big user of bullets
as it turns out, our other people.
So, when the paragraph thing collapses, it just collapses
to a single bullet button, which is basically the button you want.
You know, it's just nice to see it and use it and go,
oh, it did what I expected.
That's really cool.
I'm better search results in the sidebar.
Hiding latency and showing you, allowing you to navigate that
and see your document tree and so on.
So, all of that has been shipping nicely.
But we got some new things coming soon.
So, there's a two-page view coming up.
So, side by side, and I think you'll always
nice book binding things.
A nice new inter-op feature here.
Marcus Mohard doing fantastic work and Balash Varga.
Looks particularly ugly in the screen shop,
but it's getting better and a nice inter-op feature
that people have been missing.
Multi-sheet views.
So, my competition have cheated.
They totally cheated.
So, they replicate the model on each of their machines.
So, the first thing that they do is download the whole document
every user and then they try and calculate a new on each machine.
We do it once, essentially, which is nice.
But these guys had a really easy feature to implement,
which is this temporary views.
I want to view of this sheet, other people don't see.
And that's kind of easy when you duplicate the model everywhere.
Like everyone has the model anyway.
Like, what's the problem?
For us, it's more tricky because we have a single model at the center.
And so, yeah, so we did a whole lot of work here.
And now, you know, it's very easy to then filter
and not affect other people's views and see different views of that data.
And we hope to return the favor by having multiple views,
you know, and easily to use it in the sheet tab and switch between.
So, that's fun. And why is that hard?
Well, it seems a super easy thing to do as everything seems.
Until you realize the calculation engine can use the visibility state
to calculate different numbers.
So, you have to, you know, do some fun stuff.
We're improving mobile tool bars and all sorts of things.
Follow me presentation.
This is great. So, NLNet, NGI, zero, have funded this thing.
And it's really cool.
So, apart from having beavers and lots of beavers.
Actually, I'm going to need help giving them out later.
This then allows you to project your slides to other people effectively.
Much as we're doing now.
And why would you want to do that?
Because, of course, what you can do is you can render that
on your high resolution screen and then you can take screenshots of that.
And you can compress that into H264.
And you can stream that to everyone else.
You can then decompress it again.
And you can do that at 60 frames a second as your webGL transform,
you know, happens.
And it might, someone might even keep up if they're lucky.
Up all, you can just send some JavaScript to them to run the presentation
and the assets they need.
And then they can run this presentation, see it all beautifully,
beautifully happening on each of these people's screens.
And they have actual content instead of pixel.
So if they're visually impaired, they can go at their own speed.
They can go back.
They can read that bit on the Braille display better.
They can get, it be included more.
And if the presenter speaks too quickly, as can happen.
Then they can, you know, keep up.
You know, they can go back and check again and make sure they understood that.
So, yeah, some nice stuff.
And pretty as settings you I, just built in.
And one of the things we're really focusing on is interoperability.
We've talked to you about some of the problems.
We've, you know, we solve huge numbers of them.
But we want to get the numbers down to zeroes everywhere.
So we've been using a tool.
The game was helpful funded by Zendes.
And just exposes the very worst bug documents out of our very worst bugs
that are causing problems around tripping.
And so there's a great team there of people just chasing that down to zero.
And once we get it to zero, it stays there.
You know, like this is, this is what we want to see.
Lots of, lots of, lots of zeros.
So we have all this beautiful new user experience in collaboration line.
And we've been doing some great work to bring that to the desktop.
But actually, that's something we've done for years.
So on Chrome OS, you've always had something that runs on your Android phone.
And if you plug it into a big screen and put a keyboard in, suddenly it's a full
full office suite running on that device.
Same thing on iPhone for Mac if you compile it right.
And so, you know, native code brings a whole load of advantages.
Um, offline support is one of them.
Obviously, as you travel the same UI, but better, you know,
high performance layer latency editing there, obviously, you know, in a slow train.
But better than that, you have platform API.
So the browser is a wonderful tool.
And it provides an amazing infrastructure everywhere.
Quite amazing in some ways.
Um, two amazing and JavaScript, let's say, but anyway,
um, but it also really is a bit security paranoid.
So getting access to your clipboard is really difficult.
You can't get rich content through it nicely, and that sucks.
If you want to see whether you've got multiple screens or what the
resolutions are, get a projector and project on it.
None of that works.
Um, if you want proper printing APIs, we talk about that.
What about image formats?
You know, there's a whole lot of things there.
And we tried initially to do this, and we're still doing that work on
WebAssembly.
So Stefan Bergman, somewhere is a hero of, uh,
I'm making this work, but the problem with that is that it's quite disappointing.
It's not really share those webAssembly that big webAssembly
blog between multiple tabs, which makes a real problem.
There's a couple of bugs there in the browsers that, uh,
Yeah, a problem for us.
So anyway, native code makes sense.
And so we're just bringing the same UI to the desktop with a
little bit of wrapper around it to make it look, you know, nice and
pretty, uh, and all of the features you know and love, uh,
the look, uh, integration with your Mac goodness and so on,
or badness, it's proprietary.
You shouldn't use it.
It's just free desktop.
Um, and this is really complimentary to the classic product that we're all aware of.
Um, so we continue into work on classic, and there's a huge tech overlap
there, obviously in this giant community backing that code base.
And the new collaborative is then really complimentary, and that really slim
down thing.
No Java.
No database.
No mail merge, master documents.
We're taking lots of stuff out of that.
Um, to make it cleaner and smaller and, you know,
easier to handle and wrestle.
We're doing a lot of collaboration.
I'll skip that now.
I think, um, for, uh, we have a talk later in the collaborative room.
If you want to come and see how we're doing, um,
collaboration and better, a hackfest at the bed for the hotel.
So just walk upstairs and visit us Monday Tuesday.
If you're interested, but a lot of beavers
tooling away are doing doing good things.
But if you can't make that because it's a bit late as notice,
we'd love to see you in Hamburg, come and join the community,
meet people, do team building, uh, give lots of input.
Now, there's a whole lot of really cool people who have have done great stuff.
And it would be remiss of me to stand here as one person.
And not mention their names.
Loads of people on, uh, can have a line.
Loads of great translators, uh, doing, doing great work.
And, and, and, and look at the complex text goodness in the middle of
there to, uh, to get some of these people written right.
Now, we also have a mascot.
And, um, uh, toast and don't, can I grab you to come and grab the,
the thing there because we'll need this surely.
There's a whole case of them over here.
So, so one of the things that I have as a problem,
and maybe you, you do too.
So, I work quite hard.
You know, I love programming.
Don't get enough chance to do enough of it, you know.
And so, so there's a great temptation to ignore the real world
and, and to go away and, uh, program.
And, and say, we have a mascot that is the sort of, uh,
uh, epitome of hard work, you know.
It's always out there doing, doing hard things.
And, and John Hall is modeling on here at the, at the front.
Thank you, John. You know, excellent. Just like that.
And, and we have a lot more here and say, where people will, um,
people will get these if they ask questions or come and grab me
afterwards. And, and this is actually a character from a comic about open source.
So, if you, if you go, it's called the Open Road to Freedom.
And it's a comic about communities, an open source, and companies,
and it might even be funny if you read it.
So, uh, yes, have a look at that.
So, here's my conclusions. My conclusions are, what are they?
Ah, office is a little bit harder than you think.
It looks easy.
Ah, lives of people are suckered by the ease of writing their own office suite
and the glory and the fame of creating something new.
But, actually, it's a bit of a nightmare. So, just be a little bit careful,
uh, you know, before you jump in and come and talk to me and maybe you will learn something.
Ah, the browser really does get you part way there.
Um, but it would be really helpful if you could just join us and we build upwards.
Instead of doing the Jamie Zowinsky, CADT, you know,
attention deficit teen version of point eight being succeeded by completely rewritten point eight.
And then another totally rewritten point eight.
And when we could have been a, you know, uh, well, I can't multiply very well.
Uh, 2.4. Um, so yes, look at this. This is, we should have a gun that kind of, you know,
sprays people with, with hardworking beavers, but anyway.
Anyway, I think I've said thank you, but, but the people I'd really like to highlight here are,
uh, the volunteer is a fantastic, um, but we have loads of staff,
some of them here, Torsten is, is, is, is, is, is one.
Uh, we have lots of partners and customers that help fund it and actually we can't do anything without.
There's a special insurance for this, it turns out.
Um, and we, you really rock. So thank you for everyone that's contributed, you're absolutely amazing.
Get involved, see me. We are hiring. We are trying to grow quite rapidly.
Uh, there's obviously a big opportunity here and we want to make free software and documents better.
So please come and join us. Thank you for your patience. You've been very good.
Thank you.
Now an upside of talking too quickly is that we have time for questions.
Um, and I'm trying to get us back on, on schedule. So hopefully we, uh,
we have a bit of, uh, bit of time. So if you have some questions of the form, you know,
can I have a beaver? Um, we've got another hundred of them in the hotel that will come tomorrow.
So just come and grab me somewhere around the Libra office next cloud, uh,
uh, but in the meantime, if you have a question or a comments or a hickling or, uh,
I love CRDTs, they're easy or anything like that, you know?
John, what question do you have? What second? I can give you a microphone.
First of all, I love my beaver. Okay.
Second of all, uh, my pleasure.
You mentioned spreadsheets and spreadsheets has always been a problem.
How is your, how are you at importing Excel spreadsheets?
Fantastic.
So Excel support is, I think, outstanding that you're not going to find anything else outside of Excel that does it as well as we do.
Um, the performance is great. We're threading stuff. It works really well.
And of course, because we're running out on the server, we can have quite a big server.
So you can load really a big spreadsheet on your phone,
and you're not downloading all of this stuff. You're just getting a view into that.
So, you know, it's, it's, it's pretty good. I think the ergonomics and the UI,
we're continually improving, but that's, you know, that's what I'd be.
Good question. Yeah, I can.
On one, you skipped quickly over the collaboration thingy.
Can you give short impression of what the state of the artists of this protocol?
The communication protocol?
Two slides back.
You said there's a presentation later, but for people who cannot make it,
there's quite a lot of slides on them.
This guy, shoot.
Yeah.
Just for you, Hiker.
You know, the, the collaboration.
It's a slide. You skip very quickly over collaboration between applications.
I still can't hear what you're saying, which is one of the things.
We're a fine Hiker.
Collaboration. Oh, yeah, sure.
I mean, we do collaboration, but we do it by bringing everyone into the same document model.
So, with collaborative line, you can collaborate.
All these document formats, and that works nicely, but there's a single model.
So, you don't have this model synchronization problem.
Right? The issue with this is that you have two models,
and you have to somehow make sure they're consistent and kept in stay.
And that's really not easy.
Like, like, caching is one thing, but model synchron distributed model replication is a tricky problem to get right.
And people do it in databases, for example, and also, so, you know, places,
but it's, it's not easy with extremely complicated data structure.
Stuff.
Good question.
Anyone else?
Yeah.
You're starting desktop editors based on, like, the existing collaboration line stuff, right?
Correct.
Yes.
Are there plans to do integration with something like, let's say, next cloud?
So, if I think a bunch of documents to my computer, I can just, like, double click a ODT file.
It opens and is collaborative.
Because currently, we have the problem of, if I want to collaborate, I need to open it in the browser,
but if I double click a dog eggs, then it locks it for everyone else, and it's just a mess.
That's a brilliant question.
Yes.
Of course.
And the answer is that, come to first of all, I'll talk in the collaboration dev room later.
So, we'll be talking about that, and Stefan's been doing some great work, if I can.
Ah, Stefan Bergman over here.
If you wave, Stefan.
Don't.
So, if you're particularly interested, talk to Stefan.
And the beautiful thing is there, because you have the same UI, you can switch, then,
transparently in your tab, and ideally, keep your cursor position or whatever, and suddenly, you're
collaborating with other people on a remote server.
Oh, until your connection doesn't work, and then you can bring it back to your machine
and edit there.
So, we can take a load of CPU load off the server when we need to.
If you're just one person in the document, which turns out to be 90% of the time in collaborative
systems, actually, is just one person collaborating with themselves.
Which is a little bit sad.
But actually, if you consider what you do, typically, you finish your document, and then you ask
for review, rather than mashing it up horribly without thinking and, you know, collaborating the same
time.
So, yes, perfect.
We're, of course, engaged in that.
And there's some fun stuff there, detecting this file you've opened locally, is actually being
synced by a, you know, a sync client, and now I need to go and talk, you know, there's a lot of plumbing,
but not a lot of complexity in doing that.
So, yeah, we're looking forward to getting that working.
Oh, so, no, no much of a technical more on the marketing side.
So, currently, obviously, the world is going from like desktop office suits to online ones.
Like this gives you an opportunity because, like, then people stop expecting pixel perfect rendering.
And, over the, I guess, you have, like, two main competitors, the Microsoft and the Google,
the Google suits are apart from digital sovereignty.
What other killer features would you recommend as a, like, what little bit of office does.
Our collaborative story.
So, killer features in caliber office that aren't there in the other online office
sweets.
Yeah, I mean, we have some just amazing cutting-edge features that you can use in
you can have a online writer, for example, that aren't there in Microsoft's writer.
Good work, Benoit.
This guy's a hero.
He's one of the customers.
Yeah.
Awesome.
Million plus seats in France, French education, that man.
What a hero.
So, yes.
So, in Microsoft Office online, you can't insert a chart in a word document.
I'll just say that again.
You can't insert a chart in a word document.
Now, you're not going to believe me because that seems totally lunatic, right?
The leading office suite provider has suddenly decided we don't need charts in word processing
sweets.
Now, as you probably can copy it from Excel, but you're probably going to get a bit map image
with false color around it.
So, when you size it, you get like blue red green, you know?
I mean, just startlingly bad.
And the thing itself is riddled with adverts for using the desktop version
instead.
So, you know, it's constantly saying, are you sure you want to do this?
This seems a bit difficult.
Please continue to use Windows.
And store your data in one cloud while you're there, right?
So, yeah.
I mean, I think from a feature function perspective web versus web,
we kick Microsoft's backside already quite hard in many ways.
And Google, you know, on a par or, you know,
we win and lose.
Interrupt.
We kick Google's backside.
We're just much better interrupt than they are.
So, yeah, I think there's everything to play for in that market.
And we don't need to be ashamed.
We should say you should use this.
It's really good.
Thank you.
Oh, different.
So, wait.
And thank you to you.
Yeah.
So, my previous job and very clear talk,
would you mind going back to the number of bags along the time?
Oh, yeah, this one.
This is a very specific kind of bug.
It's an interoperability bug.
Of a specific targeted interoperability type.
Yeah.
So, is there any reason why ODD is still?
Oh, yes, just bad prioritization by me.
So, I was particularly annoyed with the presentation fidelity.
And so, I was like, right, got to fix and press.
So, we did that first.
And now we're doing these.
But there's nothing wrong with ODT.
This is just, this is just exporting it back to DocX.
Because there's quite a large difference.
If you get a very complicated ODT, then sometimes when you import that in Microsoft,
it will complain about the document structure in some way.
Okay.
Oh, it seems bad.
Usually you get the document.
It just likes to complain.
So, you know, if we can stop the complaints, they scare users, you know.
But all your contents there and we can reload it.
But yeah.
So, and just to give you a perspective, you know, we have like a test corpus of
quarter of a million, third of a million of the worst documents we can find in the world.
Right?
And so, this is some fraction of a percent of the real usage.
And, you know, this is the sort of numbers we're seeing for actual problems doing that
roundship from Microsoft.
So, yeah.
So, we're making real progress.
I'm hopefully next falls down.
This number will be zero.
And then it will stay zero because we have automation.
And, you know, as soon as it goes up, we'll stop it happening.
So, thank you so much.
You've been super good audience.
So, bless you.
And come and see me.
Grab a beaver.
Thank you so much.
Thank you very much.
And I hope you didn't scare away all the developers, the potential ones.
And yeah.
Thanks again.