GreenHouse by ICS Helps Software Engineers Turn UX into Reality

Building a new device challenges the skills of a software engineering team to the extreme. Although code reuse has been the motto of software development for years, in reality very little code is re-used (aside from personal “tricks”). In fact, most code isn’t written to facilitate reuse because of pressures from deadlines and hidden dependencies. And, in the cases where the code is incorporated, it often threatens the success of the project by forcing the use of old concepts and discarded approaches that may not be appropriate in a new device. This is something developers know all too well. 

If you ask a developer to itemize what makes his or her job difficult, three common themes will emerge:

1. Translating the vision of the UX team into the reality of the software and hardware environment

2. Gaining consensus within the engineering team on an architecture that makes sense  today and will work through future generations

3. Testing the software when the hardware is late or has limited availability

At Integrated Computer Solutions (ICS), we develop more than 50 high-impact devices annually. We know that projects can succeed only if these types of concerns are effectively addressed. For that reason, our own team of engineers devised GreenHouse by ICS, a rapid development solution for embedded touch devices built using Qt.

GreenHouse solves these problems and smooths the way for faster product development. Here’s how. 

Translating the UX Vision into Reality

Around ICS, we recall a story that illustrates reality colliding with the UX. Around a dozen years ago, we worked on a project for a major appliance manufacturer that had created the UX portion in house. Their vision: while the appliance was operating, an animation would appear on the touchscreen to indicate to users that the wash cycle was active. The designer who created this was understandably proud of his innovative UX, which worked perfectly in “flash” on a quad core Intel processor packed with lots of memory. 

Unfortunately, that wasn’t the platform the actual machine was being built on.

Sadly, we had to inform the designer, who had expended great effort and time on the nifty animation, that the processor they had chosen lacked a GPU capable of making that level of animation possible. Needless to say, people did not leave the meeting with smiles on their faces.

To ensure this type of problem would never again arise, we took a UX-centric approach with GreenHouse by putting the UX designer in charge of the UX from the beginning of the project. 

Designers can create using their preferred tools (e.g. Figma, Qt Design Studio, etc.) and then, through “bridge” software supplied by GreenHouse, import it into the development environments that engineers are using. Almost immediately, the design is concretely implemented — if available, even on the target hardware — and the UX engineer can confirm that the design is capable of meeting the reality of the device's display and processor.

Architecture for Today and Tomorrow

Some developers love to work on the architecture of a software application, tweaking and re-writing until it is perfect. Others believe in the “good enough” principle and want to get on with the tasks of developing the actual software. The battle between these positions (and perhaps other subtle variations) makes it difficult for a typical manager to make the best decision.

GreenHouse eliminates this battle by delivering a four-layer architecture, driven by a sophisticated state machine, that has proven itself repeatedly in all the devices that ICS delivers. Furthermore, it isolates changes because the layers are loosely coupled. This makes it relatively simple to address even last-minute changes — you know, the ones that always seem to be “must haves” but arrive just before the team wraps the project up. For the same reason, it’s future proof. By expanding the state machine or modifying selected states, v2, v3 and future versions can be delivered. 

GreenHouse also provides a number of large-grain components, such as Wi-Fi and bluetooth, settings, that can be immediately dropped into your application with minor tailoring. 

Hardware is Unavailable. What Can We Do?

One of the very frustrating aspects of developing software for a new device is that often the hardware is late, or because of cost and size, only available in limited quantities (and perhaps in limited locations). When this happens, it can be a disaster for the productivity of the software team. 

Often, key members can’t do anything more on the project and are “loaned” out to other projects never to return. If they do return, they’ll take days and weeks to return to the point of productivity where they left the project.

Believe me, it happens all the time. 

GreenHouse was specifically designed to address this issue by building a device simulator into the application. When the application needs data from the device, the developer can provide it through the simulator workbench. This data also can be saved and “replayed” later to test for regressions. 

The simulator console doesn’t even have to be on the device itself. Through a built in RPC mechanism, the simulator console can be on your desktop while the application is running on the target hardware. This makes testing and debugging much more straightforward on devices that only have a touchscreen and might not have the facility to enter data to trigger states or explore the state of the machine.

Even after the hardware becomes available, the simulator console is still very useful in triggering error conditions that might be difficult — even impossible without doing damage to the machine — and seeing how the software responds. In other words, GreenHouse’s simulation console is one of its most powerful features and well worth exploring.

The Last Word

The concept of GreenHouse originated in the challenges we continuously saw each year as we developed devices for our clients. We frequently had to be the messenger of bad news when the UX outran the capability of the hardware. And our engineering culture of getting things done now didn’t allow us the luxury of debating which architecture was best. So we developed an architecture that works well in 99% of applications. 

GreenHouse solves the issue of code reuse by generating all of the boilerplate interface code and ensuring all dependencies are properly oriented. This means implementations are truly reusable.

Regarding hardware, prior to the development of GreenHouse, if we couldn’t get the hardware, our engineers couldn’t work. And, if they don’t work, we don’t get paid. There goes the business plan. With GreenHouse, the simulator provides an elegant solution that benefits our customers and allows our team to move ahead even when hardware availability is an issue. Developed by engineers, GreenHouse makes it easy to overcome the typical obstacles involved when developing elegant touch devices.

For more on GreenHouse, read GreenHouse is a Smarter Way to Build Embedded Touch Devices.