Posts tagged ‘Lightning Experience’

What is the Value Proposition of Lightning Experience?

If someone were to ask you what the Lightning Experience was all about, your first reaction might be, “It’s the new Salesforce UI.”

While that is technically correct as Lightning Experience is the brand name given to the user interface that replaces what we now refer to as Salesforce Classic, the implementation of this user interface is part of the larger vision of a unified Salesforce experience across all devices.

Lightning Experience takes the old way of doing things in Salesforce Classic – long, scrolling scrolling pages – and blows it up into tiny pieces. You to reassemble those pieces in the way that makes the most sense for your business users.

You can even create your own custom pieces, called components, and include those alongside components that Salesforce gives you out of the box, or components built by third parties that you download from the AppExchange. It is all completely seamless.

Focus on Getting Things Done

While the initial release of Lightning Experience focused on making salespeople more productive, the interface is rapidly evolving to improve on all areas of CRM.

The ability to seamlessly transition work between the desktop and mobile devices will enable every Salesforce user to find new ways to connect with customers and increase the effectiveness of business processes across the enterprise.

While the initial release of Lightning Experience wasn’t quite complete, it did include over 25 new features and a total redesign of many pages. Some of the notable improvements included:

  • Component-based record pages that focused on getting work done in the context of the Salesforce object record, rather than having to scroll to find pertinent related information
  • Completely redesigned reports and dashboards that enable visualizing customer data in new ways with flexible layouts and additional filtering options
  • An Opportunity Workspace designed to help salespeople get to Closed Won faster by focusing on actions instead of raw data
  • Kanban boards for visualizing Opportunities in their various deal stages and enabling salespeople to drag and drop multiple Opportunities to new stages rather than having to edit and save individual records
  • An enhanced Notes feature that enables users to create notes with rich text and attach them to multiple records at the same time

Unified Salesforce Experience

Following the mobile-first mindset adopted with the launch of the Salesforce1 platform, the same component framework that is used to power Salesforce1 is what underlies Lightning Experience.

The incorporation of design principles from the Salesforce Lightning Design System ensures that users get the same responsive experience whether they access Salesforce from desktop browsers, mobile devices, tablets, wearables, or anything else that comes along in the near future.

Developers and ISV partners can now build custom components and applications that plug right into Lightning Experience, rather than having to build custom pages and standalone applications.

Blurring the Lines Between Clicks and Code

Experienced Salesforce developers know that a key consideration when desiging Salesforce solutions is to find the right balance between using declarative, out-of-the-box functionality and the programmatic capabilities of the platform.

We lovingly refer to this dichotomy as “Clicks vs. Code” in the world of Salesforce development. With Lightning Experience and the introduction of the Lightning App Builder, the discussion shifts from clicks or code to clicks and code, as developers can now build custom components and expose them to the Lightning App Builder interface, allowing admins to drag and drop these reusable components onto a canvas and assemble new Lightning Pages.

While this sentiment may strike fear, uncertainty and doubt into the hearts of developers, anytime we can move from code to clicks or enable admins to maintain Salesforce customizations, it is a good thing.

Lightning Experience enables a closer relationship between admins and developers. Developers can focus on building reusable components, admins can focus on maintaining the user experience.

Overview: Applying Salesforce Lightning Design System (SLDS) to Lightning Components and Applications

If you want to recreate the look-and-feel of Lightning Experience or the Salesforce1 mobile application, you will need to apply the Salesforce Lightning Design System (SLDS) external style sheet to your Lightning Components and Applications.

There are a number of ways in which to apply SLDS styling, with some being automatic based on context, and others requiring a reference to the SLDS style sheet in markup.

Although not a technical deep dive, this overview will help you understand the different strategies for applying SLDS to your Components and Applications.

Implementing SLDS

Prior to the Winter ’17 release, the only ways to implement SLDS were to either download the design system as a ZIP file that contained the CSS style sheets and icon library and upload the ZIP as a Static Resource, or download an unmanaged package to your org.

In either case, the burden of keeping the SLDS resources up to date fell on developers and admins, who had to monitor for updates to SLDS and upload new versions to the Static Resource as they became available.

In some cases with early adopters of Lightning, there were multiple versions of SLDS floating around as Static Resources within a Salesforce org, further complicating the maintenance requirements.

With the Winter ’17 release, SLDS is included in all Salesforce orgs and will be updated on a schedule that is more aligned with the three-time per year Salesforce release schedule.

Lightning Experience and Salesforce1

As of Winter ’17, any Lightning Components that are exposed in Lightning Experience or Salesforce1 will automatically have SLDS included in the app.css external style sheet that gets generated at the time the Lightning Component Framework bootstraps.

When you work in Lightning Experience or Salesforce1, the user interface is composed by a special top-level application that we refer to as the one.app container. If you look at the address bar of your browser when you are using Lightning Experience, you will notice the URL looks something like this:

https://my-custom-domain.lightning.force.com/one/one.app#...

Just like we can create our own custom .app applications and expose them by URL, one.app is a Lightning Application that contains all of the markup, styling and events needed to run the Lightning Experience and Salesforce1 user interfaces.

There are a number of options for exposing your custom Lightning Components through the one.app container, each of which automatically applies SLDS, and we will touch on them here.

Lightning Pages

Lightning Pages are created using the Lightning App Builder, which is a drag-and-drop interface that allows you to declaratively create new user interfaces from any standard, custom, or third-party Lightning Components that implement a special interface.

Lightning Pages enable developers and admins to create new App Pages, Home Pages, and Record Pages by simply by assembling reusable components on a canvas and assigning component attribute values where required.

When you implement the appropriate interface and expose your custom Lightning Components as Lightning Pages, they will automatically have SLDS available to them.

Lightning Component Tabs

If you simply want to expose your Lightning Component as a custom tab in Lightning Experience, you can create a new Lightning Component Tab and add it to Apps in the App Launcher. By implementing the interface to expose your Lightning Component in a tab, the component will have SLDS available to it when it is rendered in the one.app container.

Lightning Quick Actions

With the Winter ’17 release, Salesforce introduced the concept of exposing Lightning Components as Quick Actions. Now you have the option to expose your Lightning Component in a much more granular fashion than exposing it on a Lightning Page or in a Lightning Component Tab, and any Lightning Component that implements the appropriate interface can be exposed as a Quick Action.

Again, since the component is being rendered in the one.app container, SLDS will be available to your component automatically.

Communities

If you implement the necessary interface for exposing a Lightning Component to the Community Builder, the component will be given access to SLDS CSS classes when exposed in a Community Page.

Lightning Out and Lightning Components for Visualforce

Whether using Lightning Out to expose Lightning Components to an external website or a Visualforce page, SLDS CSS classes will automatically be included in the app.css stylesheet so you won’t have to worry about manually loading the SLDS stylesheet or other assets.

force:slds

To apply the look and feel of Lightning Experience and Salesforce1 in custom Lightning Applications (.app resources) that are not rendered in the one.app container, you can extend force:slds in the application definition to implement the SLDS style sheets and design tokens from Lightning Design System.

For example:

<aura:application extends="force:slds">

    <c:MyCustomComponent />

</aura:application>

Note: force:slds can only be extended by Lightning Applications. If you attempt to extend force:slds in the definition of a Lightning Component, the compiler will throw an error.

Static Resource

In some cases you may have a requirement to use a specific version of the Lightning Design System. If you do not want to take advantage of automatic upgrades to SLDS provided by the one.app container or by extending force:slds, you can upload the CSS stylesheets for SLDS as Static Resources and create a dependency on them in your components by using ltng:require.

If you do choose to use a Static Resource to apply SLDS, or if you have components that were developed prior to Winter ’17, keep in mind that you will be responsible for maintaining the stylesheets in your Salesforce org.

Unmanaged package

In earlier releases of SLDS, the design system was available as an unmanaged package that could be downloaded directly into your Salesforce org. This is no longer an option as the unmanaged package has been deprecated.

To find more detailed technical articles related to styling Lightning Components and Applications, check out the curated library of Lightning content here: