Reaching a Stable Point

Over the past few weeks, new additions and big changes to Clinical Encounters has been winding down. We’ve been getting closer and closer to our vision for it, so the focus has shifted from adding new functionality to polishing existing features and eliminating bugs. There has also been a good effort to tidy up the project by removing old, deprecated scripts, scenes, and prefabs while also organizing the project structure and code better.

Project Upgrading

Part of this organization and clean up involved updating the project from unity 2017.3 to 2018.1. In general, it’s not usually wise to upgrade a project in the middle of a development cycle. This has the chance to introduce new bugs from project refactorings that will cost time and effort to resolve just to get back to where you were before the upgrade. Some key reasons to upgrade a project would be if the current version has a game-breaking bug that is fixed in later versions or perhaps some new features are added that would greatly improve development moving forward.

In our case, since we have a bit more of a breather in development, we went ahead with the upgrade to match the same Unity level as our other in-house projects. Since the project organization involved removing a bunch of unused assets and scripts, there were fewer things to throw errors from the upgrade. Before committing to the upgrade, we also made a project back up and tested what the upgrade would be like, and there were only a handful of small changes that would need to be made. Because of that, deciding to upgrade was an easy decision.

Swapping Text For TextMesh Pro

This time was also good for upgrading the Unity Text asset with the more newly supported TextMesh Pro asset that I mentioned in a prior blog. Since it was a substantial effort to swap every text instance in both the code and across the project, a process was created to streamline the substitution and speed things up. Now Clinical Encounters really is looking sharp!

Creating A Demo

By showing the core functionalities of the full software, we can offer the most out of our demo.

Since our project is in a stable place, it seemed like a great time to produce a demo version. We had two ideas for a demo version: one of just the case viewer application and another of a limited version of the full software. While the case viewer would be a simpler demo, we opted to go for the full software because of what it can show our users.

Our primary audience at the moment are attendees of conferences. We want a demo that is quick and easy while still showing what the project is about and what it can do. By showing the core functionalities of the full software, we can offer the most out of our demo. Effectively, we want users to be able to view cases and experiment with creating their own. We had to make some modifications for this demo mode, which are as follows:

• The demo works entirely offline, just in case an internet connection is unavailable.
• We skip the login screen and log in users as a guest. The benefit of this is the demo then automatically has some of the restrictions we want guests to have, which works out perfectly.
• Users can still create and save cases, however, we limit the extra case info to make the case saving process more streamlined.
• Features such as case importing/exporting, creating case copies, and deleting cases are disabled

By doing this, we remove some of the features which could distract the user from that core experience we want to show them.

You can read more about the Clinical Encounters platform at its website.