Wednesday, 9 November 2016

Salesforce Lightning

Understanding Important Visual Design Considerations

Visualforce pages look the same whether they are running in Salesforce Classic or Lightning Experience, unless you rework them to adapt to the appropriate user interface context. Built-in Visualforce components that display user interface elements aren’t easily restyled to match the Lightning Experience look-and-feel.

Specifically, the HTML that’s rendered by the built-in Visualforce components doesn’t change when the page displays in Lightning Experience, and the Salesforce Classic stylesheets those components use is, by default, loaded by the page. The effect is that pages that use <apex:inputField>, <apex:outputField>, the <apex:pageBlock> components, and other coarse- and fine-grained components that match the Salesforce Classic visual design, still match that visual design. You get a little slice of Salesforce Classic in the middle of your Lightning Experience.

It’s our general recommendation that—for now, for existing pages—you don’t try to adapt them to match the visual design of Lightning Experience. There are two reasons for this. First, Lightning Experience is still evolving, and matching its styling yourself means you’re chasing a moving target. That’s work.

Second, it’s even more work if you don’t have the tools to do it. In the current release, the tools are mostly not there. We have a number of ideas here and, Safe Harbor, we’re already hard at work at bringing them to you in a future release. So if you can wait, that’s our recommendation.

Nevertheless, in some cases you’ll want some pages to match more closely with Lightning Experience visuals. For new pages, or if you’re willing to do some work, there are some great tools for creating pages that fit in perfectly with Lightning Experience.

Adding a Custom Stylesheet

You can add your own custom stylesheets to any Visualforce page using static resources and the <apex:stylesheet> tag. For example, to add a stylesheet that’s been uploaded as a static resource named “AppStylesheet”, add the following to your page.

<apex:stylesheet value="{!$Resource.AppStylesheet}"/>

You can then refer to any of the styles contained in the stylesheet, and reference them in Visualforce tag styleClass attributes, as we did with the asideText style previously.
This is the recommended method for adding CSS style definitions to Visualforce pages, because it shares the stylesheet between pages, and minimizes the markup you need to add to each page.

Styling Strategies and Recommendations

In the current release there’s only one supported method for creating Visualforce pages that match the Lightning Experience visual design, and that’s to create new pages using the Lightning Design System. Before we get to specifics, let’s think at a higher level and consider the different strategies for applying Lightning Experience styling to your pages. In particular, let’s talk about your existing pages.

There are two ways to affect the styling of existing pages to make them look more like Lightning Experience.

Change the markup to apply new styling—make changes in your pages.
Change the styling rules for existing markup—make changes in your stylesheets.
These aren’t either / or. You can use them individually or in combination.

The Lightning Design System is a fantastic all-new toolkit for styling your pages, and we’ll talk about it in detail shortly. Correctly using the Lightning Design System means using the Lightning Design System stylesheets with all-new markup for your Visualforce pages. Again, this is the only supported method for matching the Lightning Experience visual design.

However, it is possible to add the Lightning Design System stylesheets, and revise your pages to use them. How much work this is depends on how closely you want to match Lightning Experience as well as the specific markup and components in your code. While it’s possible to achieve decent results this way, it’s not an approach we recommend. The Lightning Design System was designed to be applied to specific markup, and that’s simply not what Visualforce emits. There’s an “impedance mismatch” that, while not fatal, is definitely a serious rock in your shoe when you take this path.

Finally, there’s the other approach: adding new rules and styles to your existing (or a new) stylesheet to make your existing markup look more like Lightning Experience. If your page is already mostly styled with your own stylesheets, this approach might work well for you. If instead you’re mostly using the built-in Visualforce components and the Salesforce Classic styling, it requires you to override the styles from the Salesforce Classic stylesheet.

While this is technically possible, we want to discourage you from taking this approach. It introduces dependencies into your markup and styles that you don’t want to have. These dependencies are on the structure, IDs, and classes of the HTML rendered by the built-in Visualforce components. We want to be really clear here: the HTML rendered by the built-in Visualforce components is an internal implementation detail, subject to change without notice. If you have dependencies on it in your own stylesheets, your styling will eventually break


Knowing Which Features to Avoid in Lightning Experience

Lightning Experience Header and Navigation Menu Can’t Be Suppressed

Visualforce pages always display with the standard Lightning Experience user interface when they run in Lightning Experience. There’s no way to suppress or alter the Lightning Experience header or sidebar. In particular, the showHeader and showSidebar attributes of <apex:page> have no effect on Visualforce pages when displayed in Lightning Experience.

This behavior is intentional. Apps that display in Lightning Experience are Lightning Experience apps. If you need to provide a completely custom interface for your app, you’ll need to run it in Salesforce Classic.


sforce.one Isn’t Salesforce1-Only

The sforce.one JavaScript utility object is available to Visualforce pages in both Salesforce1 and Lightning Experience. If you’ve been using the presence of the sforce.one object as a way to tell if your page is running in a mobile or desktop context, you need to update your code.


No comments:

Post a Comment