Why a Desktop App?
- More real estate.
- Higher security (reducing the risk of extension exploits).
- Naturally suitable for more serious, administrative functionality.
- Possibly higher development time
- We might need access to the user’s browser cookies, to scrape data out of Voiceflow
This was always known to us yet, in earlier HCI iterations, we were first considering designing a browser extension. The reason was that we thought we would need to reverse engineer Voiceflow’s API. And we did that. But as mentioned in a previous article, eventually that wasn’t necessary. So we defaulted back to a desktop app, which could arguably be more difficult to develop.
How Did You Build The Frontend?
The core framework we use is Electron. It essentially is a browser instance running a locally hosted website trying to look like a native app.
- Use any web UI framework and therefore benefit from many open source projects
- Provide installers for nearly any platform (Win, MacOS, Linux)
- Looks like a native app
- Non-native performance (not important in our case)
Our first UI iteration was an implementation of our Figma prototypes, built using pure HTML and CSS since we were familiar with these technologies. It was very simple but gave us a decent foundation to build off of.
For a particular UI framework, we chose
React. It allows us to design our website in a component-driven way, similar to an Object Oriented Model. This way, we could reuse a lot of the previous code we had and be more flexible in implementing changes without having to rewrite core parts of the codebase.
Our app has state shared across all pages. Usually, this is a hassle to properly deal with in
react and ensure all data dependencies are updated. This is why we chose
mobx to design our data model.
mobx allows us to declare which objects are system state, and it handles the responsibility of properly updating anything that might depend on that state.