My last BrainBlog post on Salesforce Lightning provided a broad introduction to this powerful technology and also made some important recommendations for any organization that is currently leveraging Visualforce for their Salesforce-based web pages.
As that article explained, Lighting consists of several different elements – the most important of which is the Lightning Component Framework, and its associated Component Exchange on Salesforce AppExchange.
In this post, I’ll take a closer look at the Lightning Component Framework – its historical context, why it’s important, and the role it plays in content management on Salesforce.
A Brief History of Client-Side Components
The notion of building a user interface out of modular, Lego block-style components that could intelligently interact with each other actually predates the web entirely.
Long before the iPhone was a gleam in Steve Jobs’ eye, Apple Computer (as it was called then) developed OpenDoc in the 1980s, a client-side component framework that the brilliant minds in Cupertino thought would revolutionize application development.
Unfortunately, OpenDoc proved to be a few decades before its time, and the initiative barely got off the ground. One main stumbling block: there were no standards for interoperability for OpenDoc components. Apple wanted to build an ecosystem of app developers, but there were no ground rules for how to build components that would work together.
Cut to the late 1990s. With the rollout of HTML and JavaScript, enterprise portal vendors now had sufficient common ground to hammer out client-side components they dubbed portlets, named after the portal technology that had become all the rage in enterprises.
Portlets essentially occupied a (typically rectangular) portion of a portal web page, fetching content from servers independently of other portlets. Portlets were also able to interact with each other to some extent, thanks to new interoperability standards like Web Services for Remote Portlets (WSRP).
Portlets achieved a reasonable level of success within the world of corporate portals. However, once the digital era arrived with the associated rise of mobile technology coupled with social media, portals – and the corporate intranets they powered – found their day in the sun had largely passed.
Salesforce Reinvents the Client-Side Component
The 2010s, of course, are worlds away from the 1990s, and Salesforce is no simple enterprise portal vendor for that matter, either. The breadth and power of its platform and concomitant applications are undeniable, well beyond the capabilities we might have expected from our 1990s intranets – capabilities which are certainly still available from Salesforce-based applications nevertheless.
Lightning components are, in fact, modern updates of the portlet. They are client-side components that are able to interact with each other, following modern integration best practices as well as the rules that Salesforce has laid out as part of the Lightning Component Framework.
Because Salesforce has the luxury of being able to act as a “traffic cop” of sorts on its own platform, Lightning component developers can rest assured that their components will work with other Lightning components as well as the rest of the Salesforce environment.
Furthermore, this interoperability applies to both the application level, where workflows can coordinate application behavior, as well as on the all-important data level, where the rich information Salesforce manages for its customers and partners supports the entire Salesforce community at large.
Lightning Components and Content Management
As long as a component developer follows the rules, only the imagination of its creator limits what goes into a Lightning component. As Lightning matures, we can expect to see a wide variety of innovative components hit the market – and appear in the App Exchange as well.
It’s important to remember, however, that the user interface metaphor most useful and familiar for Salesforce users is the web page, and web pages consist of assemblages of various types of content: text, images, video, and the like, as well as interactive content like forms and more sophisticated interaction modalities.
In the Lightning context, therefore, appropriately responsive web pages are the organizing interface metaphor for assemblies of Lightning components, which will display content within the context of the page.
As a Salesforce Platinum Partner, Stantive understands this impact Lightning will have on content management on Salesforce. It continues to update its OrchestraCMS platform as Salesforce rolls out new Lightning capabilities, with an eye toward supporting modern, componentized content applications on Salesforce.
The Intellyx Take
To get an idea of the power of a fully Lightning-enabled OrchestraCMS, start with the notion of a traditional corporate portal – rectangular blocks of content, possibly served from different places.
Now, instead of blocks, free the components to be any shape, and in fact, able to change their shape and position as part of a fully responsive page.
Next, add interactivity, both among components as well as between components and other applications, on Salesforce and off. Remember, however, that such interactivity follows a consistent set of rules, enabling page developers to mix and match a wide variety of content-based and interactive components seamlessly.
Finally, realize the whole thing runs on Salesforce, leveraging all the capabilities of the platform, the data, as well as the new visual elements of the Lightning Design System – bringing users a powerful, modern, fully responsive content-centric experience.
Stantive will be presenting on the topic Content in Context Across Your Communities and Digital Channels at Dreamforce on October 6th at 10:00. Click here for more information.
Copyright © Intellyx LLC. Stantive is an Intellyx client. At the time of writing, none of the other organizations mentioned in this article are Intellyx clients. Intellyx retains full editorial control over the content of this paper. Image credit: skyseeker.
