SMART style properties are not widely implemented

[isaacvetter]

I think that the smart_style_url feature of SMART is a great idea. Dynamically unifying the look & feel of an app and its host is where the industry should be heading. Afaik, only my EHR has implemented this feature so far and most apps are focused on more fundamental and important integration features.

The SMART spec communicates styling information by including an additional launch parameter of smart_style_url, which points to a json object of styling directives where changes to the url indicate a change in the style.

Overall, the existing method for delivery style information makes sense; however, the actual values need additional implementations and feedback.

I've labeled the actual styling property values as experimental in pull request #132. I think that this is the right thing to do, until we get feedback from additional implementations.

Currently, the spec includes these keys:

• color_background, color_error, color_highlight, color_modal_backdrop, color_success, color_text,
• dim_border_radius, dim_font_size, dim_spacing_size,
• font_family_body, font_family_heading

[nschwertner]

BPC v2 (http://apps.smarthealthit.org/app/49) would be a good candidate for testing the style property functionality. We were discussing this with @vasofilipov and he thinks he can modify the app to pick up the color cues from the style param. Then perhaps we can test it with your EHR to see what we can learn

[kpshek]

I agree that there are SMART app developers who will want to spend the time/effort to make their SMART app match the look & feel of the application they are contained within.

We tried implementing this within our Cerner implementation -- both in our EHR and our patient portal. Both applications provide good use cases to vet out the current SMART styling definition.

Our EHR is a native Windows application that offers limited styling capabilities today.

Our patient portal is a pure web application that has very robust styling capabilities as our clients/customers style their patient portal instance using a couple hundred attributes to match the look & feel of their organization.

The problem we ran into is that the current SMART styling attributes are not well defined, being either ambiguous and/or not sufficient. That's not to say I think we would need hundreds of attributes to meet a baseline, but the current attributes don't pass muster. For instance, while the various color_* attributes seem to provide a basic set of attributes, when we tried to use them in an actual SMART app, what about the colors in the various states of an element (selected, dithered, hover, deactivated, etc)? For color_highlight, is this the button text color, button outline color, etc?

In order to define a set of attributes that would allow for SMART apps to match the style of their host application/container, I think we need to get at least two vendors (more is better) to take a minimum set of attributes from their current styling capabilities and see if we can find agreement on a combined set. In conjunction, we'd want a few SMART apps to honor these attributes. In doing this, I think we'd see if it's possible to define a set of common, standard styling attributes.

In the meantime, I agree with @isaacvetter on moving this portion of SMART under some sort of 'experimental' section.

At Cerner, we tried to come up with a proposal for a minimal set of attributes as a counter to the current set SMART defines today. There was difficulty in coming up with this set of attributes. Instead, we wonder if it would be better to simply define a standard endpoint for which the styling information can be obtained (eg, the current smart_style_url value) and leave the document vendor specific for now.

[vasofilipov]

I can add here that the current development build of BPC v2 (http://apps.smarthealthit.org/app/49) implements the current smart_style specs and uses background/highlight colors + font to stylize the application and it does produce a working theme out of these styles. If for some reason the generated theme is undesirable the build-in themes can be used too.

[isaacvetter]

Hey @vasofilipov ,

What feedback do you have on the current experimental style attributes? What would've made your work easier? What are we currently missing?

Isaac

[vasofilipov]

Hey @isaacvetter,
The current set of attributes provided are just about enough to restyle the main interface parts of BPC v2 when using the build-in themes as a base to build on. The biggest issue we're facing is testing this functionality with a server that has the smart_style_url parameter and the URL to actually be available and working without CORS issues and such.