[TSTIL] The easee Diff Viewer

First published on
[ This is a part of "The Software That I Love", a series of posts about Software that I created or had a small part in ]

2019 - The easee Diff Viewer

Medical Devices need an IFU document. The "Instructions For Use". It's called the User Manual in the normal world. The consumerisation and digitalization of healthcare blurs the contrast between the Medical Device world and the normal world. When is the last time you looked at the user manual for an app on your phone? Do most apps even have one? Probably not. The User Interface should be be self-explanatory. Why would it be different for a healthcare app?

Having an IFU is kind of a ridiculous requirement if no one will ever look at it. As far as I know, even the regulators won't take more than a cursory glance for low-risk healthcare solutions.

With easee we decided that the UI is the IFU, and for purely regulatory reasons we needed to create a PDF document out of it to show to the regulators. But how? Doing this by hand would be error prone and a lot of work, as we have a new version every couple of weeks. Ideally we would automate the PDF generation for every release. Now this stupid regulatory requirement had turned into an interesting engineering challenge! I had the feeling that one of the puzzle pieces was hiding in the wizard engine, and also that this PDF generation would only be the beginning of something beautiful.

The wizard engine can render pages based on just page parameters. If we made a "debug" renderer, we could show individual pages if we knew the parameters. Using selenium we could then create a screenshot of the page. But how do we capture all the pages in the eye exam?

Well, the wizard engine can also capture all the page inputs and outputs in SessionStorage. We can store this "execution tree" scenario in a json file. So how this works is: you manually execute an eye exam, and at the last step press "store this scenario". Now we have captured all the page inputs. We store this json file next to the source code, and using a small debugging tool can jump to any step in the exam to debug things.

In CI we can load these captured scenarios, and one by one render the pages in it and capture screenshots. If we create a small HTML page with all these screenshots in it, we should be good! We now have a simple IFU document of just screenshots. But we also would like some accompanying text. In Vue you have "single file components" that specify template, script and style tags. We added some other tags like "documentation". This is parsed in CI and added to the html page, and now we had auto generated screenshots per release! IFU done!

Then I realized that we would also like to make really really sure that we don't unintentionally change anything in the UI of the eye exam. It would be neat if we can compare pages from before and after, and before a release check for "visual regression" problems.

The diff viewer could do this too! During CI we were already storing the component descriptions and screenshots to AWS S3. We needed an app to quickly compare all screens in two versions of the software. Due to the combination of screens x screen sizes x page parameters, we had close to 5000 different screenshots. How to do this efficiently? I learned about image diffing and perception hashes. In the CI run I added a perception hash to the metadata files in S3.

I created a quick & dirty Vue app to load two different versions of the exams and show the differences in screenshots. If there was a diff in the perception hash, it sends two images to a lambda function that shows the differences highlighted.

As CTO you have to say that it was a "team effort", and that's true for almost all of the things that we do. I don't code much anymore. But while the team was working on the important roadmap stuff I got inspired. I built the entire CI screenshots scripts and the diff viewer in about two weeks by myself. I'm not really proud of that, I shouldn't be taking the fun projects for myself. Later on Rik and Mason started adding some features, and they took part of the ownership. Thanks for working on my hacky code guys.

The easee diff viewer is a pretty cool multi-functional tool that compares thousands of images within seconds. It's awesome. We use it to verify that things looks good on multiple browsers and that we don't unintentionally change anything. I think it could be a separate SaaS product by itself. If only we had infinite time to launch new products.



next: 2019 - easee RemoteControl

previous: 2018 - The easee Wizard Engine



Comments

Post a Comment

Popular posts from this blog

"Security Is Our Top Priority" is BS

First published on
A couple of years ago I was asked to give a conference talk about software security. Well, actually I wasn't really asked, my company bought a sponsorship package with a speaker slot and I replied to the internal email asking for volunteers  🤣  Anyway, while preparing my talk, I realized a couple of important points about security that have not left my mind since: Security is limitless . You can always spend more effort to make things more secure. The same goes for quality, safety, employee happiness, etc. The needs of security are opposed to the needs of a convenient user experience . Improving one typically hurts the other. Now some organizations say "Security is our #1 priority". Really? You want to make something that has no limits your number one priority? I mean security is a good thing, but this seems a bit too simple? In fact, hollow marketing claims like that can make me a bit angry. In this post I'll help you understand what to make of statements like that
Read more

AI programming tools should be added to the Joel Test

First published on
Here's a wake-up call to all CTOs: AI programming tools are getting freaking amazing and if you don't allow your teams to use them somehow, it will bite you in the ass in a couple of years. You will be slower and you will lose your best people. The infamous Joel Test is a list from the year 2000 of 12 things all great software companies do. Since then most companies have implemented Git and CI/CD, checking of three items, so we have some space left in the 2024 update ;) I believe "Do you allow your developers to use AI assisted development environments?" is a necessary addition. I get that you don't want your source code to end up on some OpenAI / Microsoft / Github server somewhere, sure, but find a way to use your own models or learn to live with it. Note that this is often not the same as "#9 - Do you use the best tools money can buy?" as blocking AI tools is about data security, not money. So why do I think developers need AI programming tools? I&#
Read more

The unreasonable effectiveness of i3, or: ten years of a boring desktop environment

First published on
Image
My wife uses Windows and over the years I've helped her move things to new systems. Win8, 10 and now 11. With every upgrade the UI changes. Now I can't right click the bottom right corner anymore to open Task Manager. The UI feels "fresh" and up-to-date I guess, but does it really matter? My desktop has looked like this since 2008. I love the picture of the gearbox, it's a testament to the hidden precision engineering that goes on inside the built world all the time. I don't see much of the gearbox though, because most of the time my screens look like this: The environment around my background picture has changed a little more, but has been stable for the last 10 years. My experience is very different to my wife's constantly changing system. In 2009 I moved from Windows to Ubuntu, then to Debian using Gnome. Then finally to i3 in 2013 after a brief affair with XMonad in 2012. So by now in early 2024, I've had the same minimal UI for more than 10 years,
Read more