From modernising instrument control software to improving user experience, 2026 has been a year of significant development at IS-Instruments. Much of that work will never be noticed by the people using our instruments, and that’s rather the point.
In a theatre production, the audience focuses on the actors and the performance. Behind the scenes, a team ensures that the lighting, scenery and props work exactly as intended. When everything runs smoothly, nobody gives them a second thought. But when something goes wrong, everyone notices.
For Dr Alex Poppe, Software Engineer at IS-Instruments, scientific software development can feel remarkably similar. Much of his work happens behind the scenes, maintaining and improving the software that enables our instruments to acquire, process and manage scientific data. When everything works, the software rarely attracts attention. When it doesn’t, it quickly becomes a priority.
During 2026, Alex has been undertaking a substantial software spring clean, modernising existing systems, improving development processes and laying the groundwork for the next generation of IS-Instruments software.
Modernising the foundations
Software is constantly evolving, and scientific instrument control software is no exception. As instruments evolve, new functionality is introduced to meet changing research requirements. Features are added, existing capabilities modified and code adapted to support different hardware configurations. Over time, even relatively straightforward applications can become increasingly complex.
IS-Instruments’ instrument control and data acquisition software has evolved over more than 15 years. The company has now completed its transition from LabVIEW to Python, providing a more flexible and maintainable foundation for development. The transition supports a modular, object-oriented approach, allowing software components to be reused across applications. This reduces duplication, simplifies maintenance and makes it easier to introduce new capabilities.
Alex has also updated package management tools, improving how software dependencies are organised and maintained. Although largely invisible to instrument users, these changes make it easier for Alex and fellow developer Charlie to write, maintain and update code. The result is a more consistent development environment and a stronger foundation for future instruments.
Making scientific software easier to use
Reliable functionality is only part of the challenge. Scientific software also needs to be intuitive. Alex has therefore been reviewing both the user interface (UI) and the broader user experience (UX) of IS-Instruments software.
The UI comprises the controls, menus and displays through which an operator interacts with an instrument. UX encompasses the complete experience, including how easily users can find functions, perform tasks and understand what the software is doing. Good interface design makes complex functionality feel straightforward. But developing intuitive software requires an understanding of how people actually use it.
As Alex points out, there’s an important distinction between developing software and operating an instrument within a scientific workflow. Developers understand how their software is constructed; scientists may approach it with very different priorities and expectations. User feedback is therefore essential. It helps identify where workflows could be simplified, functionality made easier to discover and unexpected behaviour addressed.
The surprisingly important role of user manuals
Alongside the software itself, Alex has been updating user manuals and technical documentation.
Documentation is easily overlooked, particularly when users expect modern software to be largely self-explanatory. Yet scientific instruments often have specialist functions and settings that aren’t immediately obvious. Recent experiences at IS-Instruments have illustrated this rather neatly. One colleague compiled an extensive list of questions and apparent limitations, only to discover that the manual already addressed almost all of them. Another, joining the team and learning to operate the instruments, expressed how useful they found the documentation!
The contrast highlights both the value and limitations of documentation. If users struggle to discover existing functionality, the interface may need clearer navigation, or guidance may need to be more accessible.
For Alex, such feedback provides valuable insight into how software is experienced beyond the development environment.
Managing scientific data and file compatibility
Another area of work concerns how scientific data is stored and exchanged.
For IS-Instruments’ High Étendue Spectrometer (HES), data acquired by the CCD detector is stored in a proprietary `.hes` file format. These files contain raw CCD image data alongside metadata also found in the company’s spectral file formats, `.spec` and `.pspec`. Alex has been investigating industry-standard alternatives, including SPC (`.spc`) and JCAMP-DX (`.jdx`), to understand how different formats might support future requirements.
One possibility is to store processed data alongside the original measurements, together with a record of the processing steps applied. This could make it easier to revisit and interpret results without losing track of how the data was generated.
However, introducing new formats or expanding existing ones presents challenges, particularly around backward compatibility. Researchers may need to revisit historical measurements, compare datasets collected years apart or continue using established analysis processes. Any changes must therefore preserve access to existing data without disrupting scientific workflows. Finding the right balance between additional functionality and long-term compatibility remains a key consideration in the software modernisation programme.
Rethinking the HES acquisition software
Looking ahead to 2027, Alex is planning a more fundamental redevelopment of the HES acquisition software.
The existing application has evolved incrementally over many years. As users requested new capabilities, the team added functionality to the original codebase. Although this approach enabled the software to adapt to changing requirements, it has also increased complexity and led to ‘code bloat’, making changes harder to implement and test. Rather than continuing to extend the existing application indefinitely, the intention is to redesign it around a clearer, more maintainable architecture.
One approach under consideration is Model–View–ViewModel (MVVM), a software design pattern that separates an application into three elements:
– Model: The underlying data and application logic.
– View: The interface presented to the user.
– ViewModel: The intermediary that exposes application data and functionality to the interface and manages its presentation state.
This separation lets developers modify the interface without changing the underlying instrument functionality. Similarly, improvements to data handling and acquisition processes can be developed and tested more independently. The result can be software that’s easier to maintain, extend and adapt as instruments evolve.
MVVM remains a proposed approach rather than a final decision. Alex and the team are open to alternatives if a more suitable architecture emerges before development begins. Whatever approach is selected, the objective is the same: a more modular, maintainable acquisition system that can support future developments.
Building instrument control software that supports the science
For scientific instrument users, the priority is the measurement. Researchers want to configure their instruments, collect reliable data and concentrate on interpreting the results. The software should support that process, not get in the way. Achieving that apparent simplicity requires considerable work behind the scenes, from maintaining code and updating documentation to improving data compatibility and planning new software architectures.
Much of Alex’s work will remain invisible to the people using IS-Instruments’ technology.
Just like the backstage crew in a successful theatre production, the achievement is enabling everything else to work as it should.
And when the software runs seamlessly, the scientists can focus on what matters most: the science.
