EC Styling Guidance

[David Arbour]

When you update Employee Center to version 31.0.3, some changes are applied to the My Items widget that totally break any styling that was applied prior to the update. This occurs because the new version is updated with new classes, so any custom CSS that was added to target the old class names is no longer valid. We always attempt to apply styling in a way that prevents us from customizing widgets, so we put CSS on the theme, CSS includes, pages, etc. Since we are not updating the actual widget, updates from the store get applied rather than skipped, and our first indication that something changed was an unstyled My Items widget showing on a client's EC portal.

So, my question is, what is the guidance from ServiceNow for how we should be applying CSS styling to EC portals? Should we actually be customizing every widget with CSS so that attention is given to skips during an update? Or should we continue doing what we’re doing in trying to avoid widget customizations? This one update may have been a fluke, so we would really love to understand what ServiceNow recommends here.

[Rohan Rasane]

Hi David,

Thank you for bringing this issue to our attention regarding the styling challenges encountered after updating the Employee Center to version 31.0.3. We appreciate your diligence in seeking guidance.

In situations like these, we recommend adopting a strategy that aligns with ServiceNow's best practices for applying CSS styling to Employee Center (EC) portals. Here are some considerations:

1. Apply CSS styling which is consistent across the widgets at the theme level and avoid styling at widget level even though in your case you have used pages level or widget level
2. Im hoping that the testing of the new application version is first happening on the non-production instance, otherwise it might end up being a bad experience for the end users.
3. If at all requirements make you stick with your current approach then you do have two options
   1.  Clone the current widget and then compare the latest changes in your test instance and then copy the latest code that you want from our widget
   2. Keep using the same widget, but and make edits to the CSS files that you would need to update to fix the experience issues.

For the my items widget, we did some user experience improvements based on the feedback that we got. Usually these types of changes are less frequent.

[David Arbour]

Rohan, thank you for the quick response. Please see my comments below:

1. We always apply CSS consistently, at the theme level when we can. There are, as I'm sure you know, instances where CSS is applied with an !important property at the widget level. In this case, we must override the CSS with CSS that is more specific, which means we're likely putting it on the widget instance. We hate having to do this, but sometimes we're left with no other choice. Whether we apply the CSS at the theme level or down to the instance level (we never apply on the widget level because we are not customizing the widgets), if the class we're targeting in our CSS is removed or changed, the styling is going to break.
2. Testing is absolutely occurring first, which is ultimately how we found this issue. Unfortunately, some clients are unable to maintain their EC implementations without the help of a partner. So, if we've gone live with a client and are no longer supporting them, when they update EC to the latest version and the styling breaks, what are they expected to do? We've always built our CSS with the assumption that classes are not going to change in future releases. If widgets do change drastically, we would expect a new version of the widget, along with the deprecation of the original widget. This is how the old catalog item widget was handled.
3. I understand what you are saying about updating the CSS files to fix the experience, but sometimes this isn't possible, as outlined in the point above. Not every client that we work with has the resources available to apply fixes such as this without the help of a partner. Aside from this, are you saying we should clone and customize every widget we style to ensure this doesn't happen in the future? That would be a lot of extra work because we are applying custom designs with CSS styling to many EC portals.

We apply CSS to our clients' EC portals so that we can provide them the best user experience for their users' needs. This has become a critical part of our business as nearly every client chooses to go with a custom design after working with our UX design team. Ultimately, we would expect our CSS styling to continue to work with the classes it is targeting even after the client has applied an update. If the expectation is that we should tell to our clients that the styling we are applying may or may not break with a future upgrade, I don't think that's going to go over very well at all. Can we not get some assurance that the classes we are targeting in out-of-the-box widgets are not going to change or be removed in future upgrades?

[Rohan Rasane]

Hey David,

Can you please share the variable(s) that you guys were relying on. We will take a look and see if we can retain it or not.

Our product does UI refreshes based on the trends and customer feedback and we try to be consistent across the portal. I will definitely share this feedback with our User experience team.

[David Arbour]

Rohan,

We're not relying on variables here. Not everything is clearly mapped to a variable (which is a completely separate issue). For those classes and elements that we cannot affect with a variable update, we have to apply CSS directly to the class or element from the theme level.

If you look at the images below, you'll see that while some elements contain additional classes after the EC update, others are completely missing classes. Not only are the elements missing classes, but the entire structure of the HTML is different after the EC update.

summary-view is an example of a class that we commonly targeted in the widget before the EC update. After the EC update, summary-view is missing completely. So any CSS we setup for the summary-view class would be completely useless after the EC update.

One last point... I already emailed AJ Siegel (from your User Experience team) about this, and he told me that my best bet for getting this sorted out would be to post the question here in the Employee Center forum.

My Items widget before EC update

My Items widget after EC update