It was born out of experiential learning... A modularly expandable remote monitoring platform

As most development engineers, we also grew up in a cognitive learning system. We acquired and processed information from subject matter experts and thematic textbooks. As practicing engineers, we prefer experiential learning gathered from errors, consequences, and performances, which, coupled with expert information processing, enables us to achieve a broader understanding.

In this writing, I would like to share my personal experiences with those colleagues interested in handling the challenges of user expectations and operational needs associated with the development of a modularly expandable remote monitoring platform, MonitoringBook 2.0, as well as supporting them.

The story began just over 15 years ago when my university peer, Zsolt Mozgó, and I started developing GSM communicators for remote monitoring. At that time, we had no graphical remote monitoring software capable of displaying the signals generated by our devices. To support this, we developed an IP-based receiver station server connected via a serial port to a client computer running Mimas, and later Alarmsys. These "thick-client" remote monitoring software had many valuable features but were not prepared from an operational standpoint to handle the real-time reception of millions of event messages, as well as the simultaneous connection of hundreds of users.

These "thick-client" programs were developed to support communication technologies (dial-up phone line, UHF radio) where the daily signal count did not exceed ten event signals per device. However, IP-based remote monitoring receiver station servers are capable of receiving hundreds of thousands of signals per second. Therefore, it is essential that remote monitoring station software is prepared for different signal counts and server applications.

The term "thick client" (in computer slang) comes from the emergence of networks, where instead of running isolated applications on individual computers, they started to take advantage of the benefits offered by networks. Thus, data was stored on a central computer on a database server, and programs running on individual computers, while still operating independently, turned to the server for data. This was the client-server architecture, also known as two-tier architecture. A layer is thick if it performs many and complicated operations. The software installed on the computer performs most of the operations, hence the name "thick client." (Source: studicore.hu)

Internet Protocol (IP)-based signaling technology required more computational capacity, a more complex operational structure, and extensive IT capabilities from remote monitoring station operators. Recognizing this, we immediately began developing a modern infrastructure capable of serving operational needs stably and securely in the long term. Thus, the first thick-client remote monitoring software written in Java, Mercurio Commander, was born.

The business and operational opportunities inherent in IP technology mobilized the imagination of many remote monitoring service providers, leading to a massive technological transfer. Due to this transition, more and more service providers replaced their old systems with our developed solution. However, the significant increase in the number of remote monitoring servers and the fulfillment of associated unique customer needs posed increasingly significant challenges for us.

Initially, the thick-client software seemed like a good idea because it was built on Java and seemed scalable in the long run. However, Java required a specific environment to run the remote monitoring software, and regular updates became a continuous task for station operators. Nevertheless, no one enjoyed dealing with this task. Updates were not only needed in the runtime environment but also in the IP-based receiver unit servers and their thick-client software. In such cases, we had to update each running server (primary + hot standby) individually: migrating the old database to the new system, updating the Java runtime environment, and installing the new version of the graphical display software. To minimize risk, we only updated one remote monitoring service station per day. This type of system support required a considerable amount of time and resources on the one hand and slowed down the release of new versions on the other, hindering the faster development of a remote monitoring service provider's system. Once we realized that this type of operation was hindering the mission of MOHAnet, we made the decision to create a new remote monitoring infrastructure.

At the start of the business, our mission was to change the way people think about and use remote monitoring services globally. To this day, this principle guides all our decisions.

The new infrastructure adopted a "thin-client" technology based on cloud services. This approach solved many known operational and developmental difficulties we and our partners had suffered from before. Thanks to the new solution, users can access the remote monitoring software on any computer through a web browser supported by a program written in JavaScript. Preprocessed data is requested from a cloud server, so the client's only task is to display it. This is why the industry refers to graphical software running in a web browser as thin clients. It might sound simple, but in reality, this development came with numerous professional challenges and compromises. Nevertheless, it promised flexible scalability and more stable operation for rapid growth.

Cloud services were still a relatively new technology in the market, so we had to learn as we progressed. Subsequently, we rewrote the IP-based receiver station server software (backend) and its associated graphical user interface (frontend), which we now defined as a platform since it included our completely independent remote monitoring software (Observer, Datamatic) as well. Due to consolidation, supporting our products became significantly simpler.

Our goal was to create a modularly expandable remote monitoring platform capable of serving multiple applications from a single system. More than three years ago, we succeeded in implementing everything we envisioned. However, some of our customers were not enthusiastic about using the new platform, so they continued to use our previous software. We addressed numerous functional customer requirements and operational problems with the new platform, but unfortunately, we didn't pay enough attention to ensuring that the new graphical interface provided a better user experience than what our customers were accustomed to with our previous programs. We followed every technological trend, yet it didn't help improve the user experience. According to our customers' feedback, MonitoringBook 1.0 offered much more than any of our previous programs, but unfortunately, the user experience was worse.

In our previous software, individual records and reports were located in the upper toolbar of the main screen as toolbar icons, making them accessible to users at all times. However, in the new version, due to following trends, we applied minimal design to the graphical interface, where the upper menu bar was no longer meaningful to maintain simplicity. Instead, we introduced a new menu system, the hamburger button used in mobile phones (three horizontal lines below each other in the upper-left corner of the screen), which, when pressed, revealed a "drawer" sliding in from the side. However, the drawer obscured everything, requiring users to open it more frequently, and if something was located deeper inside, scrolling was also necessary. It was disheartening to relive the experience that what we had meticulously planned and developed over many years did not garner unanimous success among our customers.

Those who work with software on a daily basis need to simplify their work, not complicate it. That's why we decided to replace our newly developed frontend interface, written over several years, with a version that aligns with our partners' visions. At the beginning of last year (at the start of the pandemic), we allocated time to rethink the graphical presentation of MonitoringBook and to create a much more user-friendly remote monitoring platform by completely redesigning the existing interfaces. We have excellent developers, but improving and enhancing user experiences requires a separate skill set and expertise. That's why we hired a professional UI/UX designer (user interface/user experience) who sat with the National Remote Monitoring dispatchers and observed their work. With each intervention, they always asked the same question: "What would you do differently to perform this task more simply and comfortably?" Surprisingly, it was the dispatchers who provided valuable insights. Following this, I personally visited some of our partners in exchange for their valuable feedback and assured them that the redesign of the graphical interface had begun based on their indicated needs. Fortunately, we received a lot of ideas from them, which helped us design the graphical user interface of MonitoringBook 2.0.

Thanks to the modular structure of the new MonitoringBook 2.0, it can be easily and flexibly expanded with new features and value-added services. Upon login, users can decide which module of the remote monitoring application (alarm monitoring, vehicle tracking, patrol inspection, weight tracking, disinfection, etc.) they would like to use. Upon entering a specific module, users will only encounter functionalities and services that are exclusively related to the chosen application module, as our earliest remote monitoring software users have already become accustomed to. In the header, we brought back the display of individual command icons (toolbar), which differ from module to module. Switching between modules is, of course, easily manageable on-the-fly. Thanks to the modular structure, the clutter and display of irrelevant functionalities, which were previously caused by the drawer system, have been eliminated. Looking to the future, the development of a new application module can now be measured not in years, but in just a few months, whether it's about indoor positioning or video remote monitoring, as this infrastructure is now extremely easy and quick to scale. The release of the new MonitoringBook 2.0 platform will be done module by module, with the first module being available to all existing and prospective partners simultaneously with the SecuriForum exhibition.