The Desktop user interface has been developed in HTML and JavaScript. Essentially, it works by downloading from a shared site on Amazon and runs in your users' browser, connecting to and using an API in ClickHome Web Services that's installed on your servers. There are some important technical details you need to know such as connecting via HTTPS protocols and supported browsers, so we've quickly covered them for you in this article along with a graphic to help you visualise how our Desktop user interface works.

 

The ClickHome Desktop interface gives us the best of both worlds. A modern HTML interface that runs on browsers using the blink layout engine (or are compatible with it – see below), and all user interface logic is implemented in HTML and JavaScript running in the user's browser. It is built using the Angular client side framework developed by Google with Single Page Application architecture in mind so that it can behave similar to a desktop application. The backend that this Single Page Application connects to is an API that is implemented in the ClickHome Web Services module.


An important security control is our move to require HTTPS protocol for all users on the Desktop interface. In 2016 Google announced plans to mark web pages as Not Secure if they are not using HTTPS. This also applies to the backend, so the ClickHome Web Services will need to be installed on a web server with an SSL certificate for HTTPS access.

 

The API implemented in ClickHome Web Services exposes all business logic. This means that we can rapidly implement the user interface based on this API and deliver regular updates and respond quickly to user feedback and suggestions. To facilitate this, we are hosting the user interface so that there is no need for your IT team to schedule downtime and install the software for users to access the latest versions. This might seem strange at first with potential problems, but we’ve covered a lot of this in our planning as shown below, and our team are happy to discuss any other concerns you may have. The key points to this are:

  • The user interface is built from HTML, CSS and JavaScript (compiled down from TypeScript).
  • We host this content on Amazon behind a Cloudfront content delivery network which has edge locations in Sydney, Melbourne and Perth.
  • We keep all versions of the user interface online so if there is any issue, we can roll users back to a previous version at any time.
  • All your data is still stored in your existing local/on prem/personal cloud ClickHome database.
  • Users get the new version when they refresh the page or log out and log back in.
  • All links such as direct links to contracts, saved searches etc. automatically redirect to the version that the user is logged in with.
  • By default, the version of the user interface will be based on the version of ClickHome installed on your server.
  • As a last resort, your IT team can request that your site be locked to a specific version of the user interface.
  • If you stay on older versions of ClickHome on the Server, then when we release new versions of the user interface that only work with newer versions, your users will stay on the last version of the user interface for that server version.
  • We will deploy and test new versions of the user interface before making it available to end users.
  • Most importantly, the user interface is downloaded by your users into your browser and runs on your computers. The security impact of this is that it is effectively your data transmitted between your users’ computers and your servers, and not through our servers or networks.

The below graphic illustrates how our new user interface works and can be enlarged by clicking on the image.


Supported Browsers

ClickHome is not a mass-market software and to make the most of our development budget we must be selective in our technical investments. This includes which browsers we support. As noted earlier, Silverlight now works only on Internet Explorer, and our new interface will support many more browsers. For us, a good compromise is to target the Blink Layout Engine  and the Chrome V8 Javascript Engine. This translates to the ability to test on one browser, such as Google Chrome, and ensure we are compatible with these popular browsers (and many others):

  • Chrome
  • Chromium
  • Opera
  • Vivaldi
  • Microsoft Edge

Other browsers should work as we use many tools developed to support other browsers, and compared to Microsoft's approach with Internet Explorer, the developers of these browsers are very focused on compatibility with agreed standards.