Ben  McKernan
Sep 5, 2013
visibility 11031
star star star star star
(10 votes)

Adding extra information to the property overlay

Sometimes it can be quite hard for editors to know which property they should edit or even which property they are currently editing. Especially when they’ve just created a page and are presented with a column of empty blue squares that represent editable properties. For example:

The question of whether it’s possible to modify the overlays to display extra information has come up several times and I have given a few quick answers on the forums. But I figured a blog post might be more appreciated.

Display Name

The display name for each property is surprisingly already added to the DOM for all properties except content areas. Unfortunately due to some late design decisions it was hidden so that it wouldn't cause any visual problems. Such as hiding important information on the underlying website. This means that it is actually really simple to get the names of properties to be displayed, for example, on hover of an overlay. It's just a matter of loading some styles in edit mode:

/* Display the information node when hovering the overlay. */
.Sleek .epi-overlay-item.dijitHover .epi-overlay-item-info {
    color: #333;
    background-color: #B4C600;
    border: 3px solid #B4C600;
    border-radius: 2px 2px 0 0;
    display: block;
    font-size: 1.2em;
    top: -30px;
    right: -3px;
}
 
/* Hide the information node when editing. */
.Sleek .epi-overlay-item.dijitFocused .epi-overlay-item-info {
    display: none;
}

The first selector here says that we want to show the display name when a user hovers the overlay. The main part of this is the display tag which actually makes the display name appear. The others are there to make it look good. I would suggest tweaking these based on how you want it to appear.

The second selector is to make the display name disappear when the user is editing. So in this case when the overlay has focus. This is important for properties that are edited inline, since the display name could distract or potentially hide important information, but you can decide if it is necessary.

Thus we end up with the following:

Loading Custom CSS in Edit Mode

In order to load this custom CSS file in edit mode you need to add a module.config to your solution with the following:

<?xml version="1.0" encoding="utf-8"?>
<module>
  <clientResources>
    <add name="epi-cms.widgets.base" path="path-to-stylesheet.css" resourceType="Style" />
  </clientResources>
</module>
Sep 05, 2013

Comments

Sep 6, 2013 06:29 PM

Good. But please fix this in the product! And also give us some options to specify some information in content areas so the editors knows what to drop in them.

Arild Henrichsen
Arild Henrichsen Sep 6, 2013 11:58 PM

This is such a simple yet effective UX improvement. Totally agree with Johan this should come out of the box.

Eric
Eric Sep 7, 2013 11:02 AM

Awsome, hopefully i will get the module.config to work as well now when i know the namespace :)

Sep 10, 2013 09:08 AM

Works great!
Are these descriptions localized? (And if not, how can they be localized?)

Arild Henrichsen
Arild Henrichsen Oct 11, 2013 01:47 PM

@Anders: If by "descriptions" you mean the labels displayed next to each property (like "Name"), those are just the property names from your content type.
You can still use the old language files XML system to localize property names - see the /Resources/LanguageFiles/PropertyNames.xml in your EPiServer 7 site for an example.

Thomas Krantz
Thomas Krantz Oct 16, 2013 10:45 AM

I needed to make a small change in the css to make this work. Not sure if this changed in patch 4?
Instead of:
.Sleek .epi-overlay-item.dijitHover .epi-overlay-item-info

I needed:
.Sleek .epi-overlay-item-over .epi-overlay-item-info

/ Thomas

error Please login to comment.
Latest blogs
Add more scheduled job settings from the Optimizely CMS 12 admin UI -- with OptiScheduledJob.ExtraParameters

  Optimizely (EPiServer) CMS 12 ships a great scheduled-jobs framework, but it has one frustrating gap: a job has nowhere to store its own...

Binh Nguyen Thi | Jun 25, 2026

Automated Search & Navigation to Graph Migration with Claude Code

A Claude Code plugin that scans your S&N codebase, applies Graph SDK transformations, and validates the result. Install once, run one command. CMS ...

Connor Fortin | Jun 24, 2026

Migrating from Find to Graph: Lessons Learned from a Real CMS 13 Project

While migrating a search solution from Optimizely Search & Navigation (Find) to Optimizely Graph in CMS 13, I encountered several issues that were...

Binh Nguyen Thi | Jun 24, 2026

Optimizely: Upgrade Opti-ID and .NET 10 in CMS 12

Many Optimizely customers are planning their roadmap around a future migration to Optimizely CMS 13. As a result, upgrades such as Opti ID adoption...

Madhu | Jun 23, 2026 |

Understanding Optimizely Graph: Caching, Webhooks & Avoiding Stale Content (Optimizely SaaS CMS)

📌 Scope: This post covers Optimizely CMS (SaaS) only — using the official @optimizely/cms-sdk and @optimizely/cms-cli packages with Next.js 15. If...

Kiran Patil | Jun 23, 2026 |

Optimizely Content APIs: the Setup the Docs Don't Walk You Through

CMS 13 is pushing things firmly in the direction of Optimizely Graph, but plenty of teams are still running on older CMS versions, or have good...

Andre | Jun 22, 2026