is a Salesforce Solution Architect with a depth of experience in the Computing industry from mainframe and client server to cloud and mobile. He has operated his own Integration Consultancy and has also had extensive involvement in Quality Assurance including Agile Testing. Russell currently lives in Australia and has 13 Salesforce certifications.
Lightning Component Interview
with Russell O’Brien
In recent times much has been published about Salesforce “Lightning” technology. It’s viewed by many as a pathway to the future. But what is Lightning and why is it so popular? To find out Focus on Force have interviewed Russell O’Brien who works as a Salesforce Solution Architect and is a strong advocate of Lightning.
Firstly, what’s your experience of Salesforce? How long have you been using it?
I first came across Salesforce in 2005/6 when I was setting up an integration consultancy. These were early days of course but the possibilities were obvious and I was interested, in particular, with the underlying platform and how it could integrate with applications hosted elsewhere. I did a lot of “tinkering” back then. My commercial development experience with Salesforce began around 2012. Since then it’s been a solid mix of Sales / Service cloud implementation plus custom stuff using Apex, Visualforce, Visual Flow and, more recently, Lightning.
Would you mind describing “Lightning” for me … in layman’s terms?
Without going into the history, I think it’s worth beginning by saying that “Lightning” isn’t a single technology and also that these “technologies” aren’t really related. This has caused plenty of confusion. Let me explain...
There are 3 core “offerings / products” Salesforce have that come under the “Lightning” banner. These are:
- Lightning Experience
- Lightning Connect
- Lightning Components
They are NOT technically related. A Salesforce purist may disagree, but for the purpose of understanding Lightning it will help to think of them as being separate.
Lightning Experience is Salesforce’s response to the need to update its User Interface and User experience on the desktop … to bring the Salesforce Interface up to current Internet / web standards and customer expectations. I’ll oversimplify here by saying that all the user needs to do is flick a switch and their experience of Salesforce changes from the one that’s been with us from day 1, to the icon-style experience you see on modern sites nowadays. Lightning Experience was unveiled by salesforce with much fanfare in late 2015.
So, Lightning Experience is just a change to the Salesforce user interface on the desktop?
Yes. You can switch between the traditional and new interface, but that’s what it is … bringing Salesforce into the modern world.
And Lightning Connect?
Lightning Connect is an Integration Technology.
It allows the use of external data, from other systems’ data stores, in the classic Salesforce way i.e. as objects and relationships between objects within Salesforce. The external data becomes available to Salesforce developers, as if it were resident within Salesforce itself. They can view the data and update it just like other Salesforce records, even though that data exists outside Salesforce.
For me Lightning Connect is a holy grail. Prior to it integration was achieved either by using ETL tools to load external data into Salesforce OR by building integration between Salesforce and external systems.
Lightning Connect doesn’t cover all the bases, so the two older ways still have their place, but it’s clearly a pathway to simpler solutions where data sharing across applications is necessary.
And Lightning Components ?
Ah yes. Lightning Components!
To put this in context it’s important to understand recent technology and user changes, in particular mobile. Mobile is all pervasive nowadays. There are thousands upon thousands of apps you can download to mobile devices and Salesforce is determined to be a part of the mobile world … hence their Salesforce1 mobile platform.
Non-Lightning Salesforce applications CAN make use of these frameworks. However the use of Apex, and in particular Visualforce pages, both of which are Salesforce propriety technologies, is server centric. They therefore bring into play potential connection and performance issues. These CAN be dealt with, but the solutions are sometimes complex and quite often development hungry.
What about HTML and CSS?
What’s available within Salesforce to help create Lightning Components?
There’s also a Lightning Design System that makes it easy to build applications from a UI perspective. It’s Salesforce’s answer to the likes of Twitter Bootstrap and contains a CSS Framework, Icons, Fonts etc.
That explains the technology, but what about rolling Lightning Components out? If you work for an organization that wants to get into Lightning Components, how would they do it?
The simple answer is really, more or less, the same as when trying to rollout a “building block” approach to development. The use of a “component” style approach isn’t new. Salesforce already have it in the form of Visualforce Components … for server-sided development.
The areas you should look to cover off include:
- 1Develop (or reuse existing) Lightning App training to educate developers and provide effective dev support.
- 3Create a specialised component register and search facility to facilitate use of existing components.
- 4Create a Lightning Component Test Methodology and enforce adherence to standards therein.
- 5Define and implement a BETA Test program to ensure optimal customer experience through effective user feedback.
- 6Define a process for establishing commercially viable custom components on the App Exchange.
- 7Assign “Champions” for the various technical and business genres. Champions act as touch points to assist with component utilisation.
- 8Maintain a simple, clear register of licensing / cost data for each utilised App Exchange component.
- 9Provide Mobile “Orientation” training for experienced Salesforce developers.
- 10Include an approach / best practices for component breakdown and assembly in the Development Methodology.
- 11Include UI standards in the Development Methodology. Engage specialist UX providers to advise on UX best practice.
- 12Document and socialise a Visualforce to Lightning Component Migration approach. This can be included in the development methodology.
So, there’s quite a lot to it and much of it is about sharing and reusing. How often have you re-invented the wheel because you didn’t know it already existed...
Are there any things NOT covered by Lightning Components … that Salesforce still need to do or complete?
Until recently I was troubled by the absence of Visual Flow in the mix. I use flows a lot for “in screen” dialogs … conversations or wizards you may know these as. They’re very useful and easy to develop and adapt. They truly transform the user experience.
As of March 2018 “Lightning Flow” has been included as part of the Lightning offering. It’s still undergoing development with things like Flow Stages and a Flow Debugger on the Roadmap. Salesforce are really stepping up here. We can expect to begin seeing Flow Components on the AppExchange in the near future.
How would you suggest going about learning Lightning Components?
There’s an online Salesforce course called “Creating Lightning Components” that’s a bit over an hour long. It provides an excellent introduction and covers everything from component markup and style, component nesting, binding with Apex and also the event handling model. It comes with an app building exercise so you get some useful hands-on as well. There’s also an excellent trailhead covering the “Lightning Design System”. I’d recommend completing that, as well as all of the other Lightning trailheads of course.