A loading skeleton solves that by showing a placeholder version of the content before the real data loads. Instead of staring at an empty space, the user sees the shape of the card, chart, or widget that is about to appear.

In this post, I will show a straightforward way to build a shimmer loading skeleton in Ignition Perspective using a lightweight skeleton view, a loading Boolean, and a custom style class in the project stylesheet. No JavaScript or custom module is needed.

What We are Building

• Create a normal embedded view for the real content.
• Create a second embedded view that is structurally identical but uses placeholder components instead of real data.
• Apply the shimmer-style class to those placeholder components.
• Toggle between the real view and the skeleton view using a loading Boolean.

This works well for KPI cards, summary widgets, charts, tables, and other dashboard elements.

Step 1: Create a Skeleton Version of the View

Start with your normal view. For example, suppose you already have a card view called MetricCard. Create a second version of it called MetricCardSkeleton.

The skeleton version should keep the same overall layout as the real one: the same containers, spacing, padding, alignment, and approximate component sizes.

The goal is not to redesign the card. The goal is to make a lightweight placeholder that occupies roughly the same space as the real content.

For example, if the real card includes a title, a large OEE number, and a small subtitle, the skeleton version should include placeholders in the same locations.

Step 2: Use Static Placeholder Text for Sizing

For text-based placeholders, I used normal Label components and applied a custom style class to them.

The label text itself is just there to help with spacing and sizing. It does not need to be meaningful, and it should not be bound to live data.

For example, if the actual OEE typically shows 47.7%, the skeleton label might simply show 88.8%. That gives the label a realistic width and height while keeping the skeleton lightweight.

The same idea applies to titles. You might use a short static label value just to preserve the shape of the final layout.

Step 3: Add a Loading Boolean

This is the part that makes the whole pattern actually usable.

You need some Boolean value that tells Perspective whether the real content is ready yet. A simple example would be view.custom.isLoading.

Set that Boolean however it makes sense for your view. Common options include setting it true until a query returns, until required params are present, until a custom property is populated, or until a dataset or object has usable data.

For a simple setup, isLoading should be true while the data is not ready and false once the data is ready.

Then bind visibility like this:

• Real view visible when !view.custom.isLoading
• Skeleton view visible when view.custom.isLoading

This makes the skeleton show first, then disappear once the real content is ready.

Step 4: Add a CSS Shimmer Style Class in Perspective

In Perspective, style classes can be created in the project stylesheet. I used a single general-purpose class for shimmer text placeholders.

:root{
  --sk-base:   #FFFFFF1A;
  --sk-radius: 8px;
  --sk-clear:  #FFFFFF00;
}

@keyframes shimmer {
  from { background-position: 200% 0; }
  to   { background-position: -200% 0; }
}

.psc-skeletonTextShimmer {
  background:
    linear-gradient(
      90deg,
      var(--sk-clear) 0%,
      var(--sk-clear) 35%,
      var(--sk-base) 50%,
      var(--sk-clear) 65%,
      var(--sk-clear) 100%
    ),
    var(--sk-base);
  background-size: 200% 100%;
  background-repeat: no-repeat;
  border-radius: var(--sk-radius);
  min-height: 14px;
  animation: shimmer 1.4s ease-in-out infinite both;
  color: #FFFFFF00;
  user-select: none;
}

:root{
  --sk-base:   #FFFFFF1A;
  --sk-radius: 8px;
  --sk-clear:  #FFFFFF00;
}

@keyframes shimmer {
  from { background-position: 200% 0; }
  to   { background-position: -200% 0; }
}

.psc-skeletonTextShimmer {
  background:
    linear-gradient(
      90deg,
      var(--sk-clear) 0%,
      var(--sk-clear) 35%,
      var(--sk-base) 50%,
      var(--sk-clear) 65%,
      var(--sk-clear) 100%
    ),
    var(--sk-base);
  background-size: 200% 100%;
  background-repeat: no-repeat;
  border-radius: var(--sk-radius);
  min-height: 14px;
  animation: shimmer 1.4s ease-in-out infinite both;
  color: #FFFFFF00;
  user-select: none;
}

A quick Ignition-specific note: if your Perspective style class is named skeletonTextShimmer, the selector in the stylesheet needs the .psc- prefix: .psc-skeletonTextShimmer.

For a deeper dive into this code, see the section How the CSS Works.

Step 5: Apply the Style Class to Placeholder Labels

In the skeleton view, apply the style class to the labels you want to shimmer.

props.style.classes = skeletonTextShimmer

You can keep normal label styling for things like:

• font size
• font weight
• margin
• padding
• alignment

The text itself becomes transparent due to CSS, but the label retains its size and layout behavior. That is what makes this pattern so convenient: you are still working with ordinary Perspective components, just styled to look like placeholders.

Tip: If the shimmer does not appear right away in the Designer, try closing and reopening the view.

Step 6: Show the Skeleton While the Real View Loads

A simple and maintainable way to do this is to use two embedded views in a parent container: one embedded view for MetricCard and one embedded view for MetricCardSkeleton. Then bind each view’s visible property to your loading Boolean.

Skeleton embedded view:
visible = view.custom.isLoading

Real embedded view:
visible = !view.custom.isLoading

Skeleton embedded view:
visible = view.custom.isLoading

Real embedded view:
visible = !view.custom.isLoading

That gives you a very readable setup: when loading is true, show the skeleton; when loading is false, show the real widget. This is often easier to maintain than trying to make one view serve both purposes.

Why This Works Well

This pattern gives the user immediate visual structure instead of a blank area.

It also reduces layout shift because the skeleton uses the same approximate spacing as the real content.

Just as importantly, it stays simple. You are not adding much scripting or frontend complexity. You are duplicating the layout, replacing live content with static placeholders, toggling visibility with a Boolean, and using one reusable CSS class.

A Few Practical Tips

Keep the skeleton lightweight: Do not bind the placeholder labels to live data. Their job is just to hold space and show the shimmer effect.

Match the real layout closely: The closer the skeleton matches the final card, the smoother the transition feels.

Use realistic placeholder lengths: For percentages, use something like 88.8%. For short titles, use placeholder text of similar length. That helps preserve spacing.

Hide overflow if needed: If a placeholder label could get awkwardly sized, setting overflow-related text styling can help keep the skeleton clean.

How the CSS Works

If you mainly want the implementation, you can stop after applying the class and wiring up the loading Boolean. If you are curious about how the shimmer works, here is the breakdown.

Root Variables

:root{
  --sk-base:   #FFFFFF1A;
  --sk-radius: 8px;
  --sk-clear:  #FFFFFF00;
}

:root{
  --sk-base:   #FFFFFF1A;
  --sk-radius: 8px;
  --sk-clear:  #FFFFFF00;
}

These are reusable values for the skeleton effect.

• --sk-base is the main placeholder color
• --sk-radius keeps the skeleton corners rounded
• --sk-clear is a fully transparent color used inside the shimmer gradient

Using CSS variables makes it easier to tweak the look later without rewriting the whole class.

Keyframe Animation

@keyframes shimmer {
  from { background-position: 200% 0; }
  to   { background-position: -200% 0; }
}

@keyframes shimmer {
  from { background-position: 200% 0; }
  to   { background-position: -200% 0; }
}

This animation moves the background image from right to left.

The shimmer effect is not a separate moving object. It is just the background gradient sliding across the component over time.

The Background Layers

background:
  linear-gradient(
    90deg,
    var(--sk-clear) 0%,
    var(--sk-clear) 35%,
    var(--sk-base) 50%,
    var(--sk-clear) 65%,
    var(--sk-clear) 100%
  ),
  var(--sk-base);

background:
  linear-gradient(
    90deg,
    var(--sk-clear) 0%,
    var(--sk-clear) 35%,
    var(--sk-base) 50%,
    var(--sk-clear) 65%,
    var(--sk-clear) 100%
  ),
  var(--sk-base);

There are two background layers here:

1. A linear gradient (…) that creates the moving shimmer band
2. A solid var(--sk-base) layer underneath it

The gradient is mostly transparent, with a slightly visible band in the middle. As it moves, that band creates the shimmer effect.

Background Size and Repeat

background-size: 200% 100%;
background-repeat: no-repeat;

background-size: 200% 100%;
background-repeat: no-repeat;

background-size makes the animated gradient wider than the component itself, which gives the shimmer room to move across the element instead of appearing static.

background-repeat: no-repeat keeps the gradient from tiling in ways that look messy or unnatural.

border-radius keeps the skeleton shape visually aligned with the rest of the UI.

min-height helps prevent small labels from collapsing too much.

The animation line applies the shimmer keyframes and controls the speed, easing, and repetition.

Transparent Text and Text Selection

color: #FFFFFF00;
user-select: none;

color: #FFFFFF00;
user-select: none;

color hides the label text without removing the label itself.

That is important because the label is still doing layout work for us. It keeps its width, height, margins, padding, and font-based sizing, but the user sees only the animated background.

user-select: none prevents users from accidentally highlighting invisible text while the skeleton is visible.

Final Thoughts

This is a small UX improvement, but it makes a Perspective project feel much more polished.

Instead of showing a blank region while data loads, you can show a placeholder that matches the real layout and communicates that the screen is actively loading.

The main pieces are simple: a real view, a skeleton view, static placeholder components, a loading Boolean, and one shimmer style class. Once you set up the pattern, it becomes easy to reuse across the rest of the project.

The post Step-by-Step Guide: Building a CSS Skeleton in Ignition Perspective appeared first on DMC, Inc..

#1: Classic, Flat Controls

Modern user interfaces tend to use flat or semi-flat UI graphics. Flat design became popular around 2012.  By this time, users were more comfortable with digital mediums than similar users a decade earlier.  Flat design was a break from the common trend to simulate the appearance of the physical world.  Instead, flat design aimed for a simplistic, minimalist, and clean approach for user interface design.  Over time though, the disadvantages of flat design became more apparent. Studies showed that increased exposure to flat, yet clickable elements slowly reduced a user’s ability to determine what was clickable and what was not.

This lead to the slightly improved “semi-flat” design (also referred to as ‘semi flat,’ ‘almost flat,’ or ‘flat 2.0’). The Semi-flat design style is mostly flat, but makes use of subtle shadows, highlights, and layers to create some depth in the UI.  Both the flat and semi-flat designs have a clean and simple look. If you combine one of them with a tasteful color palette, you will be on your way to designing a professional and modern UI.

Example of a flat UI (from free Flat UI Kit by Riki Tanone)

#2: Layout – Simpler is Better

It’s very common in LabVIEW to try to shove as many controls on a single front panel as possible, but try to keep user interaction in mind. This is a critical component of UX design.

Some questions to ask when deciding layout:

• What is the most common interaction the user will have with the UI?
• What are the most important pieces of information I am displaying on the UI?
• What is the typical order of operation when interacting with the UI?

If you set up your user interface to intuitively guide the user through the motions of using your program, they will thank you for it. Also keep in mind that less is more when it comes to UI design, as you may have noticed from the flat and flat 2.0 design styles. Instead of making one cluttered interface, consider breaking controls and indicators into different groups to display on a tab control. Allow the user to focus only on the important information for any given view.

Remember, it doesn’t matter how pretty your UI is if the user can’t figure out how to use it!

#3: Color Palettes

Colors are very important to the overall look of a UI. Just as with layout, less is more when it comes to colors.

A good practice is to only choose a couple of colors for the entire UI. Consider using shades of grey and one or two theme colors. Or, you can use complementary colors to highlight selections or important things.

When in doubt, just look at other professional applications or websites to get a sense of what color palettes the experts use. Adobe Color CC is a free web-based tool that is fantastic for helping designers choose color schemes:

You can even click ‘Explore’ up at the top of the page to get ideas from palettes other designers have created.

#4: Animation

Have you ever seen animation in LabVIEW? If you’re like most developers, the answer is probably no.  Animation plays an essential role in modern applications.  It acts as the bridge to tie together the layout and feel of your application.  Effective animation can help keep your layouts simpler by moving panels on or out of the viewing area.  It also helps direct your user’s attention to areas of the application that need their input.  In this way, you can utilize animation to improve your application’s intuitiveness and provide a better user experience overall. 

As you probably know, LabVIEW does not have animation built into any controls.  The good news is that there is an easy way to add movement and animation to your user interface that won’t cost you too much time. 

The main display and the menu bar that we added animation to are shown below.

This example uses a tab control for the animation, although you could use any control. When the user presses the settings button on the main display, the custom menu bar (tab control) slides onto the screen from the left, enabling the user to select from the displayed options. When the user presses the menu button again, the menu slides off.

This .vi works by adjusting the “Position” property of the tab control within a while loop (in that it can executes repeatedly as long as a certain boolean condition is met). Using an exponentially decaying shift in position, we are able to give the animation a realistic and smooth feel. If you choose an appropriate delay time between loop iterations, then it actually appears that the tab control is sliding onto your main viewing area.

Below are a set of pictures taken over a time period of about a second that show the animation movement of the control. Of course, downloading and checking out the demo file above is probably the best way to explore more about it.

National Instruments also has a few examples that you can find online. Using Property Nodes to Create Orbiting Boolean Indicators is an excellent example to check out from the NI Developer Community that can help you understand the idea of moving controls and get started making your own custom animations.

#5: Modify Classic or Silver Controls

So, how do you make those flat or semi-flat controls I mentioned?  The standard modern, silver, and classic controls in LabVIEW are not going to provide you with what you need, unless you customize them.

If you right-click on a control, you can select Advanced -> Customize to give these controls a nice/custom look. You can choose to hide many graphics you don’t like as well.

I have found that the silver and classic controls are the easiest to quickly modify to give you more attractive controls. In the example below, I hid the shading on the silver button control. It looks better already!

Customize it even more if you’re not satisfied! You can change the icon, the shape, even replace elements of the button with your favorite pictures from the internet. I personally use Flaticon to get some great custom icons for my application buttons.

I’ve also recently designed a new graph control that I prefer over the existing LabVIEW ones. This was all done just by customizing the already-provided default controls in LabVIEW. Sure, it does take time to make them look nice, but now if I ever need a visually-appealing graph, I have a much better starting point than the default controls.

#6: Custom Control Palettes

If you don’t want to design your own controls, just check out UI control palettes that other LabVIEW developers have made. Some are free while others cost a little extra, but in the long run, the benefits outweigh the cost if you’ll be designing a lot of nice user interfaces.

Here are my favorites:

• DMC LabVIEW GUI Suite
• JKI Flat UI Controls Kit
• Scarlet UI Controls Kit by RAFA Solutions
• Flat User Interface Controls Suite by Ovak Technologies

The Bottom Line

As LabVIEW developers, we have become accustomed to the primitive modern, silver, and classic control palettes, but unfortunately (or fortunately), our end users are not. They expect the same quality they get from their free Apple/Android apps. Furthermore, your UI is the window through which the user experiences your application. It doesn’t matter how good your code is if the user has a hard time figuring out which buttons to press, or is overwhelmed by all the colors and information on a single screen. This is the importance of UI design and UX design.

By following these six tips, you will be better equipped to satisfy your end user’s desire for a user-friendly and aesthetic user interface.

Learn more about DMC’s LabVIEW programming expertise and Contact us to find user experience and interface solutions today!

The post 6 Tips for LabVIEW UI and UX Design appeared first on DMC, Inc..