Months following Dreamforce ‘15, we’re still hearing more than just murmurs about the launch of the new Salesforce Lightning UX. This is the first post in a series of four that will examine the different aspects of Lightning, and to a greater degree, their respective utilities. Given the breadth of what’s made available with Lightning’s features, it only makes sense to break the discussion up into the following parts:
- Part I: Introduction to the New UX
- Part II: Lightning App Builder
- Part III: Lightning Components and Lightning Design System
- Part IV:Lightning Limitations and Deployment Considerations
Undoubtedly, the majority of the excitement has revolved around the UI – its aesthetic value, efficiency, and so on, but is that all Lightning entails? Not by a long shot!
Salesforce1 Lightning has been around for as long as two or three years. If your organization is employing Salesforce1, you are likely already aware of Lightning Components and its up-til-now exclusive use for mobile. Salesforce has taken the modularity and other design attributes Salesforce1 Lightning has employed and extended them into desktop applications, making the inherent flexibility, power, and efficiency universally available across devices.
Please refer to my previous post “Why Salesforce Lightning Will Change CRM” for additional insights into what makes this transition so significant.
It’s worth referencing the history of Lightning to clarify what Lightning is today and what the most recent rollout consists of. It is comprised of three primary parts:
- Lightning App Builder
- Lightning Components
- Lightning Design System (LDS)
Each of these components is in one way or another impacted by the groundwork laid by innovation of Salesforce1 Lightning several years ago. This is absolutely most evident when you begin constructing apps and components, but it doesn’t take more than a glance at the UI to draw parallels between the mobile app and the new desktop interface.
In subsequent articles, we’ll look at each aspect of Lightning Experience in turn. Part II of this series will explore in greater detail the fundamentals and capabilities of App Builder, which represents the less technical, point-and-click side of Lightning development. This aspect of Lightning Experience is significant in that it adheres to the Salesforce ecosystem’s mantra ‘clicks-not-code’, for its numerous benefits.
Part III will look at Custom Components and the Lightning Design System, both of which require a bit of skill or internal development resources to fully take advantage of. While custom work inevitably results in increased management effort, we’ll discuss why the combination of LDS and Custom Components represent the zenith of Salesforce platform customization and flexibility to date.
Part IV of this series will explore the current limitations, caveats, and other points an organization should consider prior to transitioning from Salesforce Classic to Lightning Experience. Fortunately, even after activation, users will retain the ability to bounce back and forth between Lightning and Classic Salesforce. This ability, however, does not indicate that a Lightning Experience roll out should be approached recklessly. The final installment will discuss such considerations.