We are open sourcing our UI library

We build software for the operating room, so our product comes with a user interface: the screens the surgical team looks at and the buttons they press. User interfaces are harder to test than the rest of the code, because in the end somebody has to look at them. We needed a UI library built for agent-first development: one with minimal dependencies, that makes user interfaces that look awesome, and that is as fast and reliable as a medical product needs to be.

What our UI library helps with

Our app has two halves. One works on the camera input and analyses it. The other is what the surgical team sees and touches: the video on the screen, and the buttons, menus and text around it. Our UI library is the toolkit for that second half. It has those parts ready-made, draws them on the screen, and reacts when someone presses buttons.

We looked for a UI library that could do all of that on a small, bare Linux computer like the one in the operating room, without a web browser underneath, and found none. So we built Navisurg bibui.

How we test UI

Some code is easy to check. If a piece of code works out a dose from a patient's weight, a test can check that the dose is right. What the user sees is harder. Text can be cut off at the edge, or a button can cover the video, and every dose is still right. Usually the only way to find out is to open the app and look, and if one of us had to do that for every change, we would hold up everything we build.

So every bibui app has a built-in line that an agent can use to work the real app directly. It presses buttons and fills in fields, and it gets back a list of everything on the screen and where it is. It doesn't have to search a screenshot for the right button. It asks the app, and the app answers. It can ask for a picture too, and that's what it brings to us.

The app handles the agent's presses exactly as it handles a person's, and can't tell the two apart. So a problem the agent finds is one a user could run into too.

None of this needs a monitor, so we can run many agents at once, each trying a different idea for the same feature. On every change, all of our tests of the app run again from start to finish. A change only reaches one of us once it has passed them all, and then we decide.1 For a team of three, that changes how fast we can build.

Fewer dependencies to check

Almost every app is built on other people's code, and that code is built on more code again. For most software that's fine. For a medical device, each of those pieces has to be identified, assessed for what could go wrong, and followed for as long as the device is in use. The standard for medical device software has a name for them: software of unknown provenance.2

Each of those pieces is also a way in for an attacker, through a flaw in it or through someone tampering with it on its way to us. A device on a hospital network has to be kept safe from both, and every piece is one more to watch for security fixes.

The fewer of those pieces there are, the less work it is, the less there is to go wrong, and the fewer ways in there are for an attacker. On Linux, bibui uses no packages from anyone else. Apart from the operating system, it only needs a few standard pieces that are already on the machine.3

Approved building blocks

bibui comes with a set of building blocks: buttons, switches, menus, dialogs, text fields, tabs and more. We designed and reviewed every one of them ourselves, and bibui checks on every change that they still look the way we approved.4

That gives our agents safe ground to build on. When an agent builds a new screen, it puts it together from these approved blocks instead of designing a new button each time. You can see them all in bibui's gallery, each on a page of its own.5

The surgical team has our screens in front of them for a whole operation, so they should be clear, calm and good to look at. Every colour, size, corner and font comes from a theme, so a bibui app can look however you want it to. Ours uses the orange and dark of our brand, but any colours work, dark or light.

How fast it is

We've worked on bibui for half a year, and everything we build for the desktop now runs on it, including the operating-room app and the studio where we study the fluorescence recordings from our clinical work.

It's small and quick. A bibui app is one file of about 6 MB. It's on screen about a hundredth of a second after it starts, using about 33 MB of memory. A screen with 600 buttons on it is redrawn in under 5 milliseconds, well inside the 17 milliseconds a screen gets at 60 pictures a second.3

Why we're open sourcing it

Our business is the surgical product, not UI libraries. bibui is a tool we needed along the way, and nothing in it is specific to surgery.

We also build on a lot of open source. Most of the tools we use every day were written by people who gave them away, and this is a way to give something back.

And open source makes bibui better. The more people use it, the more problems get found, and anyone can send in a fix or a new building block. That makes it safer for us too.

bibui is free and open source under the Apache 2.0 licence. You'll find it at github.com/Navisurg/bibui, with documentation at navisurgvision.com/bibui. This release is version 1.0.

If you build with agents and want them to see what they've made, try it. Tell us what you think.