There’s a change occurring within our Salesforce ecosystem. The Salesforce Lightning Experience is here, maturing, and release by release is bringing Salesforce customers pages worth of new features. With such a great amount of positive change going on within the native and out-of-the-box areas of Salesforce, it can be easy to overlook the other areas that are subsequently affected. One of these areas is the AppExchange and the slew of existing Apps that are already available as well as those under active development.
New and existing partners alike need to know how, when, and where Lightning is being applied and what is expected of their apps. If Lightning is not yet part of your AppExchange app delivery approach yet, it’s crucial to begin understanding the requirements and planning on how to provide a “Lightning Ready” certified app.
Per Salesforce earlier this year, all new apps, both free and check-out based must be Lightning Ready while all others created by new partners entering into an agreement on or after 3/1/2017 also must be Lightning Ready. For those with existing apps, it’s suggested by the AppExchange team that you begin making them Lightning Ready “as soon as possible” to “avoid being the app that prevents your customers from enabling Lighting.”
What makes an app “Lightning Ready?” Read on!
Your Customers’ UIs: Salesforce Classic and Lightning Experience
New Salesforce customers have it pretty good as they might not know of any other Salesforce UI aside from the one in their new org(s); the Lightning Experience. However, existing customers are in a state of flux as some have migrated from Classic and are taking advantage of many of the Lightning only features while others are still evaluating and making the important decisions around how to get there.
There are plenty of great resources available that define Salesforce Classic and the innovations introduced via the new Lightning Experience. If you’re new to the platform as a Salesforce customer or perhaps a Salesforce App Innovation Partner (previously known as ISV partners) looking to get insight into what your customers are doing in Salesforce, check out this Salesforce Trailhead Module, Lightning Experience Basics, to get up to speed.
Seeing this? Your Lightning-enabled future awaits.
Salesforce Classic isn’t going anywhere (anytime soon) and will continue to be supported. Think of all the custom development work that has been done, leveraging Classic and built around the traditional/native stylings of Visualforce. This should not be taken as a recommendation to disregard your customers’ use of Lightning and in-fact, the remainder of this post will be much the opposite.
Take a look at the last few sets of Salesforce Release Notes and see if you notice a trend. It doesn’t take Einstein AI technologies to notice that all of the exciting new features that are being released are Lightning centric. Any mentions of those coming to Classic? Nope.
The “Lightning First” Mindset
Now’s the time to adopt a “Lightning First” mindset. By this, we mean that if you’re doing any Salesforce platform development, your solution approaches should start with the Lightning Experience and fallback to Classic when and only as needed. As developers, we’re over the hump in asking “Is Lightning ready yet?” Last year, CRM Science created our own internal “Lightning Incubator” to answer that question. Our criteria was to look at what common design elements, patterns, and use cases we routinely used when developing in Classic and determined whether or not the same or better results were achievable if the development were done natively in Lightning? We’ve been “Lightning First” since.
What this Means for App Developers
Whether you are building a new app or working to adapt an existing app, it’s certainly recommended to do so with Lightning in mind. So much so that Salesforce has created an AppExchange listing badge and search filter to allow “Lightning Ready” apps to be distinguished against those that aren’t. Below are some tips for develops to consider, but all should review our “Get the “Lightning Ready” App Certification” blog post.
Building a New App?
“Lightning First” definitely applies to you. You have the opportunity to start with native Lightning Apps or develop using the tried and true Visualforce, modernized with the Salesforce Lightning Design System (SLDS). SLDS allows you to leverage all of the great new UI components and elements introduced in Lightning, complete with their styling.
Below’s an example application of a common element found in our work, the simple page alert. Move over apex:pageMessage, there’s a new alert in town.
A few examples of the common SLDS design elements.
Adapting an Existing App?
Review the “Lightning Ready” requirements below and consider your existing app. How many “pieces” of the app work independently of each other; meaning, if you were to start transitioning your existing work to be Lightning styled, would anything be out of place or look unusual? Would 90% of the user experience be in Classic and 10% in Lightning? Attempt to identify the “portions” of the app that can be transitioned alone or need to be done together. You don’t have to convert your app all at once, but you do want to maintain consistency of either all Classic or all Lightning for your various user flows.
In most cases, adapting existing Visualforce code to work as-is, with an updated styling via the Salesforce Lightning Design System (SLDS), requires much less effort than anticipated.
Plan the development of your new features around your conversion; again, you want to attempt to provide the users of your app a consistent look and feel. You may be tempted to develop a new feature in Lightning (and you should), but might need to expedite the conversion of the other UI elements where this new feature will be found so it doesn’t stick out or potentially degrade the end-user experience.
Check out our follow-up post, “Get the “Lightning Ready” App Certification!”