Why Resize?

Clinical Encounters has thus far been designed with one aspect ratio in mind (which is 16:9, for those curious). When building the canvas and all the supporting elements that define Clinical Encounters, we did so while under some assumption that our desktop application would always keep the same presentation and that mobile and VR presentations would have their own designs. WebGL has made us rethink that a bit.

When built for WebGL in its current form, Clinical Encounters can appear a bit small while embedded in some web pages. This, in turn, affects how large the text appears and makes it hard to read in some cases. So, a simple question was proposed: Can we zoom in? When this was asked, the initial answer was no, but now we have a system which lets us adjust the scale and resolution to some extent.

How It’s Done

The key component, literally, is the Canvas Scaler component which we use to conform the canvas to a certain resolution. Our default resolution was 1920×1080. By adjusting this resolution to 1280×720, for example, the canvas scaler reduces the size of the canvas which in turn makes every object in the canvas appear bigger. In conjunction with TextMesh Pro, which handles scaling text amazingly well, everything still remains as sharp as it appeared when not scaled up.

The issues with this are that not all elements of the Canvas were meant to be scaled up or down. Before scaling, all the elements had 1080 pixels wide to fit, but now they have to squeeze into 720 pixels. By using defined anchor points and layout groups this can be handled well. However, not everything was set up this way. So, after reconfiguring the setup of several different panels, tabs, elements, and the layout of the case viewer scene itself, we now have something that can better handle this kind of scaling.

Automating The Scaling

The last things to note here are that, with a different scale, we don’t want some things taking up more space than needed. Take the tab content and the tab buttons. With the other surrounding elements expanded, the tab content area would actually be smaller due to how things are set up. The tabs don’t need to be as tall as they are when directly expanded, so we opt to shrink their height and give the new space to the tab content. To do this, we have manually found a layout which looks and feels good, and we adjust the values of certain elements through a script to match this after scaling. Attaching this script to the Unity Editor makes it even easier to quickly select the scale we want.

The WebGL Front

When it came to distributing the WebGL version of Clinical Encounters we decided to host it on itch.io. We found that hosting on a separate site made the process of embedding the game in our own web pages easier, allowed us to organize the different case builds in one place, and decreased the time it took to build and test new versions. However, it also came with its own issues. We originally wanted to only make one build that would read the patient’s name we would add to the URL and then load the corresponding case. However, because we were hosting the game on a different site we had no control over the URL and that could not work.

Another trade-off with hosting is that itch.io creates an iframe for your game that you can just immediately embed into whatever webpage you want. However, there are only a few things about this iframe that you can customize. There were some ways we wanted the iframe to behave with screen sizes and expanding. We edited the default style sheet created by Unity during the build process and could get the same effect and added in a special class to handle the embedded iframe and got the effects that we wanted.

What To Take Away

This is an example of how a lack of preparation and planning resulted in a bit of extra work. We have known about our targets for other platforms, yet we built exclusively for the desktop application. By planning for these potential changes ahead of time, we would have saved ourselves some work. So, when you’re embarking on development, make sure to plan ahead and try to outline/define any constraints and requirements for your software. If you development methodology allows it, try and remain flexible, too.

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