Drupal Planet

Dries Buytaert: Optimizing your product strategy for the short- and long-term

5 godzin 21 minutes ago

Most products cycle through the infamous Innovation S-curve, which maps a product's value and growth over time.

Startups are eager to find product-market fit, the inflection point in which the product takes off and experiences hockey-stick growth (the transition from phase one to phase two).

Just as important, however, is the stagnation point, or the point later in the S-curve when a product experiences growth stagnation (the transition from phase two to phase three). Many startups don't think about their stagnation point, but I believe they should, because it determines how big the product can become.

Ten years ago, a couple years after Acquia's founding, large organizations were struggling with scaling Drupal. I was absolutely convinced that Drupal could scale, but I also recognized that too few people knew how to scale Drupal successfully.

Furthermore, there was a lot of skepticism around Open Source scalability and security. People questioned whether a community of volunteers could create software as secure and scalable as their proprietary counterparts.

These struggles and concerns were holding back Drupal. To solve both problems, we built and launched Acquia Cloud, a platform to build, host, and manage Drupal sites.

After we launched Acquia Cloud, Acquia grew from $1.4 million in bookings in 2009 to $8.7 million in bookings in 2010 (600% year-over-year growth), and to $22 million in bookings by 2011 (250% year-over-year growth). We had clearly found product-market fit!

Not only did it launch Acquia in rocket-ship growth, it also extended our stagnation point. We on-boarded many large organizations and showed that Drupal can scale very large. This helped unlock a lot of growth for both Drupal and Acquia. I can say with certainty that many large organization that now use Drupal would not have adopted Drupal without Acquia.

Helping to grow Drupal — or extending Drupal's stagnation point — was always part of Acquia's mission. From day one, we understood that for Acquia to grow, Drupal had to grow.

Launching Acquia Cloud was a great business decision for Acquia; it gave us product market fit, launched us in hockey-stick growth, but also extended our S-curve.

As I think about how Acquia has approached the Innovation S-curve, a few important lessons stand out. My recommendation is to focus on opportunities that accomplish two things:

  • Focus on business opportunities that serve a burning customer need that can launch or accelerate your organization.
  • Focus on business opportunities that remove long-term barriers to growth and push out the stagnation point.

OpenSense Labs: Conversational Commerce: From a Whisper to a Roar

9 godzin 32 minutes ago
Conversational Commerce: From a Whisper to a Roar Shankar Sun, 12/16/2018 - 23:07

We are continuing our march towards becoming an AI-first world where the mobile centricity is getting replaced with personalised user-centricity. This is an age where conversational commerce and artificial intelligence (AI) as a utility are altering the way we communicate with brands and with each other. One of the great examples is the LivePerson’s LiveEngage. As a leading conversational commerce platform, it allows the students of Barry University to interact over popular messaging services. They can ask anything ranging from the application processes to the courses available in a convenient manner like they do with their friends and family.


Conversational commerce is already making great inroads and is revolutionising the way consumers and brands interact with each other. It has the potential of being a curator of services and experiences that can intelligently fulfill the needs and engage consumers emotionally anytime and anywhere. Drupal Commerce, an open source e-commerce solution, can help in implementing conversational commerce. Before we look at Drupal Commerce’s capabilities for this implementation, let’s explore conversational commerce first.

Conversational Commerce: Explained  Source: Mücke, Sturm & Company GmbH

From the traditional point of sale systems (POS) to mobile commerce, we have seen it all. They have paved the way for conversational commerce which can dramatically metamorphose out shopping experience by leading a new era of individualised shopping.

Chris Messina coined the term Conversational Commerce looking at the dominant trend of consumer computing apps which came to life in 2015 with Uber’s integration into Facebook Messenger. He described it as a solution that can deliver “convenience, personalization, and decision support while people are on the go with only partial attention to spare”.

Conversational commerce is about delivering convenience, personalization, and decision support while people are on the go, with only partial attention to spare. - Chris Messina

Conversational Interfaces leverages the power of AI whilst using the technologies that consumers relish using like messaging, voice interface or other natural language interfaces thereby enabling people to interact with brands or services through bots.

With the objective of delivering a top-of-the-line customer experience, it helps in replicating the one-on-one, in-store salesperson experience with the consumers. Whether you are buying clothes, ordering food from a hotel, or making a financial transaction, conversational commerce is here to revolutionise the business model.

Why is Conversational Commerce Important?

Comscore states that 85% of the smartphone time is being spent on social media, messenger and other media applications. Moreover, by 2021, the number of users using digital voice assistants is projected to reach 1.8 Billion.

Massive adoption of messaging applications along with the rise of conversational, AI-powered technology can streamline the process of making one-on-one conversations at scale. And as people distance themselves from clicks and taps and inch towards conversational UI, more adoption of conversational commerce can be witnessed in the coming years as it promises a slew of benefits which are stated below:

  • Driving customer satisfaction: Offering voice assistants can enhance brands’ Net Promoter Scores (NPS®) thereby driving customer satisfaction.

 

  • Generating more business: Enterprises will be able to generate more business and positive word-of-mouth

 

 

  • Increasing consumer spending: Consumers show the willingness to increase their spending with a brand when they receive a good voice assistant experience.

 

  • Focussing on priority consumer segments: Enterprises that emphasise on the segmentation of priority consumers like targeting users who prefer voice assistants for purchases will bring in great value.

How does Conversational Commerce Work?

There are different ways to look at conversational commerce in action. One of the types of experiences can be a proactive model. In this, the customer buys something for the very first time from a shop and receive an automated message with greetings and thanking them for shopping at that store. Another working model can be a reactive approach. In this, a customer buys a defective product from a shop and seek assistance. In response, the shop guides them through a solution.

Source: Chatbots Magazine

Furthermore, there can be one-to-one and one-to-many working models. If a shop sends a message and personalised offer to a customer who has applauded their service on Twitter, this comes under the one-to-one approach. Suppose a restaurant chain has opened a new store. They can send a custom message to a targeted audience segment who live nearby. This comes under the one-to-many approach.

Also, a digital voice assistant like Amazon Alexa and Google Home can assist the consumer in finding stores, hotels, events and much more. It can also recommend products, access customer care service, book a cab, or even control smart home devices.

Conversational Commerce with Drupal

Decoupled Drupal Days 2018 had a session which showed how to integrate bots in Drupal Commerce. When it comes to bot’s business logic, Drupal Commerce turned out to be a great solution in addition to its robust capabilities in storing content and product details. Moreover, Drupal, being an API-first CMS, offers a plethora of APIs out-of-the-box and the Commerce Cart API module makes it easy to interact with carts in Drupal Commerce.


It showed how decoupled Drupal Commerce, bot frameworks and Natural Language Understanding (NLU) can be leveraged for providing a boundless shopping experience to the e-commerce websites which are built on Drupal using Drupal services layer.

Decoupled Drupal Commerce, bot frameworks and Natural Language Understanding can be leveraged for providing a boundless shopping experience

The session focussed on Drupal 8 core services and the creation of custom REST APIs. It also laid emphasis on utilising decoupled Drupal Commerce APIs and using Node.js and Bot framework for building a chatbot.

In addition to this, it also talked about the bot frameworks and other cognitive services that can be used to develop bots for different use cases. Several bot frameworks were considered like Facebook Messenger (wit.ai), Google Dialogflow, IBM Watson, Microsoft Bot Framework and open source conversational AI like Rasa. Ultimately, it all started with a framework called Open Source Bot Builder SDK for Node.js which is used for building bots. The application was hosted on Heroku and the Microsoft Bot Framework was used to integrate with Facebook.

In the demonstration, some of the common e-commerce functionalities like search, exploring products and many more were exposed as REST APIs. The main idea was that the bots will enable search and explore the products by incorporating Drupal Commerce APIs. On the basis of message-based interaction, bots can also enable simple Add To Cart and Review Cart functionality among others and can offer relevant actions while looking for a product.

Conclusion

Conversational Commerce represents an astronomical opportunity for the brands and the retailers alike. It can enable them to interact with their consumers in a new and innovative way. Enterprises must extract the power of this interaction opportunity for building relationships of value with consumers across the lifecycle.

Conversational Commerce, along with Drupal Commerce, can help the organisations to offer a completely new and more instinctive way for consumers to engage with them.

We have been steadfast in our goals of powering digital innovation for the enterprises with our expertise in Drupal development.

Contact us at hello@opensenselabs.com to implement conversational commerce in your business.

blog banner blog image Conversational Commerce Drupal 8 Drupal Commerce Blog Type Articles Is it a good read ? On

OpenSense Labs: Creating a Custom REST Resource for GET Method in Drupal 8

19 godzin 6 minutes ago
Creating a Custom REST Resource for GET Method in Drupal 8 Anmol Sun, 12/16/2018 - 16:44

As the world gets more connected, web technologies too, need to get connected. RESTful web services can be used as an application program interface to connect various service.

This can be made possible by using HTTP requests to GET, PUT, POST and DELETE data. It is based on representational state transfer (REST) technology, an architectural style, and approach to communications often used in web services development. 

With decoupled development getting the ground, it has become important for the developers to understand teh REST technology better. Drupal provides its developers an in-house build method to use this REST technology. RESTful Web Services module, which is now a part of Drupal core, provides REST services to its developers. 

It allows users to read or update data on the site. 

Different verbs or request methods that are used for the approach are:

GET, HEAD, POST, PUT, DELETE, TRACE, OPTIONS, CONNECT and PATCH

The GET method allows the user to access various entities like Node, User, Taxonomy, Comments and even watchdog database log entries. GET method is a SAFE method as there is no database manipulation operation, it is a read-only request.

Unlike GET, in the POST method, database manipulation takes place. The user can update the database and create a node if need be. 

Creating REST Resource Plugins

REST resource plugins are important to expose additional resources over REST. In the steps below we will create a basic example for understanding the fundamental functionality of developing REST resource endpoint which takes a content type as argument and returns title and node ids of all nodes of that particular content-type.

  • Create the staging code for REST resource with the following Drupal console command:
drupal generate:plugin:rest:resource

You can also generate the staging code manually by creating a plugin file under src in the custom module > Plugin > Rest > Resource > {ResourceClassName}.php

Next, define the namespace, dependencies, and the plugin class as given in the example below.

  • Next, you need to create the @RestResource annotation. It helps you indicate the dependencies, and status of the class. Another important point to consider is that the URL mapping is case-sensitive.

    We must also be careful with the  @RestResource  annotation's urli_paths  which take link relation types as keys, and partial URIs as values. If you don't specify any, Drupal will automatically generate URI paths (and hence URLs) based on the plugin ID. 

    If your plugin ID is rest_example, you'll end up with/rest_example/{id}  for GET|PATCH|DELETE and /rest_example for POST . But, often, you'll want to specify your own paths: a canonical URI path (for example /todo/{todo_id}). For example:

* uri_paths = { * "canonical" = "/rest_example/{id}", * }

Here’s how to get the complete REST resource GET request

<?php namespace Drupal\rest_example\Plugin\rest\resource; use Drupal\rest\ModifiedResourceResponse; use Drupal\rest\Plugin\ResourceBase; use Drupal\rest\ResourceResponse; use Symfony\Component\HttpKernel\Exception\AccessDeniedHttpException; /**  * Provides a resource to get view modes by entity and bundle.  *  * @RestResource(  *   id = "rest_example",  *   label = @Translation("Rest example"),  *   uri_paths = {  *     "canonical" = "/rest/api/get/node/{type}"  *   }  * )  */ class RestExample extends ResourceBase {   /**    * Responds to GET requests.    *    * @return \Drupal\rest\ResourceResponse    *   The HTTP response object.    *    * @throws \Symfony\Component\HttpKernel\Exception\HttpException    *   Throws exception expected.    */   public function get($type = NULL) {     // You must to implement the logic of your REST Resource here.     // Use current user after pass authentication to validate access.     if (!(\Drupal::currentUser)->hasPermission('access content')) {        throw new AccessDeniedHttpException();      }     if($type) {       $nids = \Drupal::entityQuery('node')->condition('type',$type)->execute();       if($nids){         $nodes =  \Drupal\node\Entity\Node::loadMultiple($nids);         foreach ($nodes as $key => $value) {           $data[] = ['id' => $value->id(),'title' => $value->getTitle()];         }       }     }     $response = new ResourceResponse($data);     // In order to generate fresh result every time (without clearing      // the cache), you need to invalidate the cache.     $response->addCacheableDependency($data);     return $response;   } }

Output 

[   {     "id": "67",     "title": "Consectetuer Sits"   },   {     "id": "69",     "title": "Eum Paulatim"   },   {     "id": "70",     "title": "Tation"   } ]
Configuring the REST Resources

In the config file, we define which HTTP method, serialization format, and an authentication mechanism is supported by the plugin. 

This config file is necessary to use the REST resource plugin. There are two ways to configure the REST resource @RestResource plugin:

  1. REST UI Module
     
    • The REST UI module is not part of the core. So you have to download it and install it like any other module in your Drupal site.

       

    • Once installed, go to  /admin/config/services/rest and enable your REST Resource.

       

    • Select your desired settings. To have hal_json format, you can enable Drupal Core’s HAL module.
  2. Manually
    • Go to the config directory and create a config file with name as rest.resource.{resource id}.yml.
    • Add the following content.
langcode: en status: true dependencies: module: - rest_example - serialization - user id: rest_example plugin_id: rest_example granularity: resource configuration: methods: - GET formats: - json authentication: - cookie
  • Save this file as rest.resource.plugin_id.yml (rest.resource.rest_example.yml in this case) in your config directory and run config sync.

Defining your resource config:

Status: true/false ( enable or disable) Id: unique id Plugin_id: unique id configuration=>methods: Name all request method you want to use in this plugin configuration=>formats: Define all supported serialized format configuration=>authentication: Name all supported authentication method. By default, the REST module supports json and xml

Key Point: Each REST resource must be annotated with  @RestResource  annotation so they can be discovered by RESTful Web Services module.

Custom REST API is useful in sending data to third-party applications and for headless architecture. As of today, there is hardly any project or application that doesn't have a REST API. Connect with us at hello@opensenselabs.com to help you create

blog banner blog image Blog Type Tech Is it a good read ? On

Red Route: A framework for progressively decoupled Drupal: Introducing the SPALP module

1 dzień 20 godzin ago

This article was originally posted on the Capgemini Engineering blog

A lot of people have been jumping on the headless CMS bandwagon over the past few years, but I’ve never been entirely convinced. Maybe it’s partly because I don’t want to give up on the sunk costs of what I’ve learned about Drupal theming, and partly because I'm proud to be a boring developer, but I haven’t been fully sold on the benefits of decoupling.

On our current project, we’ve continued to take an approach that Dries Buytaert has described as "progressively decoupled Drupal". Drupal handles routing, navigation, access control, and page rendering, while rich interactive functionality is provided by a JavaScript application sitting on top of the Drupal page. In the past, we’d taken a similar approach, with AngularJS applications on top of Drupal 6 or 7, getting their configuration from Drupal.settings, and for this project we decided to use React on top of Drupal 8.

There are a lot of advantages to this approach, in my view. There are several discrete interactive applications on the site, but the bulk of the site is static content, so it definitely makes sense for that content to be rendered by the server rather than constructed in the browser. This brings a lot of value in terms of accessibility, search engine optimisation, and performance.

A decoupled system is almost inevitably more complex, with more potential points of failure.

The application can be developed independently of the CMS, so specialist JavaScript developers can work without needing to worry about having a local Drupal build process.

If at some later date, the client decides to move away from Drupal, or at the point where we upgrade to Drupal 9, the applications aren’t so tightly coupled, so the effort of moving them should be smaller.

Having made the decision to use this architecture, we wanted a consistent framework for managing application configuration, to make sure we wouldn't need to keep reinventing the wheel for every application, and to keep things easy for the content team to manage.

The client’s content team want to be able to control all of the text within the application (across multiple languages), and be able to preview changes before putting them live.

There didn’t seem to be an established approach for this, so we’ve built a module for it.

As we've previously mentioned, the team at Capgemini are strongly committed to supporting the open source communities whose work we depend on, and we try to contribute back whenever we can, whether that’s patches to fix bugs and add new features, or creating new modules to fill gaps where nothing appropriate already exists. For instance, a recent client requirement to promote their native applications led us to build the App Banners module.

Aiming to make our modules open source wherever possible helps us to think in systems, considering the specific requirements of this client as an example of a range of other potential use cases. This helps to future-proof our code, because it’s more likely that evolving requirements can be met by a configuration change, rather than needing a code change.

So, guided by these principles, I'm very pleased to announce the Single Page Application Landing Page module for Drupal 8, or to use the terrible acronym that it has unfortunately but inevitably acquired, SPALP.

On its own, the module doesn’t do much other than provide an App Landing Page content type. Each application needs its own module to declare a dependency on SPALP, define a library, and include its configuration as JSON (with associated schema). When a module which does that is installed, SPALP takes care of creating a landing page node for it, and importing the initial configuration onto the node. When that node is viewed, SPALP adds the library, and a link to an endpoint serving the JSON configuration.

Deciding how to store the app configuration and make all the text editable was one of the main questions, and we ended up answering it in a slightly "un-Drupally" way.

On our old Drupal 6 projects, the text was stored in a separate 'Messages' node type. This was a bit unwieldy, and it was always quite tricky to figure out what was the right node to edit.

For our Drupal 7 projects, we used the translation interface, even on a monolingual site, where we translated from English to British English. It seemed like a great idea to the development team, but the content editors always found it unintuitive, struggling to find the right string to edit, especially for common strings like button labels. It also didn't allow the content team to preview changes to the app text.

We wanted to maintain everything related to the application in one place, in order to keep things simpler for developers and content editors. This, along with the need to manage revisions of the app configuration, led us down the route of using a single node to manage each application.

This approach makes it easy to integrate the applications with any of the good stuff that Drupal provides, whether that’s managing meta tags, translation, revisions, or something else that we haven't thought of.

The SPALP module also provides event dispatchers to allow configuration to be altered. For instance, we set different API endpoints in test environments.

Another nice feature is that in the node edit form, the JSON object is converted into a usable set of form fields using the JSON forms library. This generic approach means that we don’t need to spend time copying boilerplate Form API code to build configuration forms when we build a new application - instead the developers working on the JavaScript code write their configuration as JSON in a way that makes sense for their application, and generate a schema from that. When new configuration items need to be added, we only need to update the JSON and the schema.

Each application only needs a very simple Drupal module to define its library, so we’re able to build the React code independently, and bring it into Drupal as a Composer dependency.

The repository includes a small example module to show how to implement these patterns, and hopefully other teams will be able to use it on other projects.

As with any project, it’s not complete. So far we’ve only built one application following this approach, and it seems to be working pretty well. Among the items in the issue queue is better integration with configuration management system, so that we can make it clear if a setting has been overridden for the current environment.

I hope that this module will be useful for other teams - if you're building JavaScript applications that work with Drupal, please try it out, and if you use it on your project, I'd love to hear about it. Also, if you spot any problems, or have any ideas for improvements, please get in touch via the issue queue.

Tags:  Capgemini development Drupal Javascript open source All tags

OpenSense Labs: SCORM and E-Learning. Can Drupal Fit In?

2 dni 15 godzin ago
SCORM and E-Learning. Can Drupal Fit In? Vasundhra Fri, 12/14/2018 - 17:32

Referred to as the de facto standard of e-learning, Shareable Content Object Reference Model aka SCORM was sponsored by US Department of Defense to bring uniformity in the standards of procuring both training content and Learning Management Systems. 

Long gone but not forgotten are those days when learning was only limited to books and classrooms. With the development of technology, virtual learning has transformed into an approachable and convenient method.

Can Drupal, which is a widely popular CMS for education websites, conform to SCORM standards? How does it ensure that it remains SCORM compliant? 


In Details - What is SCORM?

SCORM is a set of standard guidelines and specifications for the programmers on how to create LMS and training content to be shared across systems. 

The agenda to bring SCORM was to create standard units of training and educational material to be shared and reused across systems. 
                           


Shareable Content Object refers to creating units of online training material that can be shared and reused across systems and contexts.

Reference Model refers to the existing standards in the education industry while informing developers on how to properly use them together.

Working with the authoring tools to design and produce the content, e-learning professionals, training managers, and instructional designers are the ones who typically use SCORM packages.

Content (used in courses and LMS) is exported to a SCORM package (.zip folder) to deliver the learners a seamless and smooth upload of the content.

The Evolution of SCORM

Since SCORM wasn’t built as a standard from the ground up and was primarily a reference to the existing ones, the goal was to create an interoperable system that will work well with other systems. 

Till date, there are three released versions of SCORM, each built on top of the previous one solving the problem of its predecessor.

SCORM 1.0 was merely a draft outline of the framework. It did not include any fully implementable specifications but rather contained a preview of work which was yet to come. 

SCORM 1.0 included the core elements that would become the foundation of SCORM.  

In other words, this version specified how the content should be packaged. How content should communicate to systems and how the content should be described.

  • SCORM 1.1

SCORM 1.1 was the first implementable version of SCORM. It marked the end of the trial implementation phase and the beginning of the application phase for ADL. 

  • SCORM 1.2

SCORM 1.2 solved the many problems that came along version 1.1. It provided with robust and implementable specifications, this version presented its end users with drastic cost savings. 

It was and still remains one of the most widely used version.

  • SCORM 2004 (1st - 4th edition)

The 2004 1st edition allowed content vendors to create navigation rules between SCOs. The 2nd edition covered the various shortcomings of the 1st. It brought with it Advanced Distributed Learning which focused on developing and assessing the distributed learning prototypes, enabling more effective, efficient, & affordable learner-centric solutions.

The 3rd edition removed any ambiguity, improving the sequencing specifications for greater interoperability.

The final and 4th edition was focused on disambiguation and addition of new sequencing specifications. These specifications widened the options available to the content authors which made the creation of sequenced content even more simple.
 


Why Should You Use SCORM?

Now that we have an idea about SCORM and its attempt of reducing chaos in the entire industry, let’s know what benefits it brings along. 

Here are some of the reasons that can contribute to a huge factor in terms of using SCORM.

  • It is a pro-consumer initiative. The online courses are eligible to be used on any compliant LMS vendor. You can alternatively upload the courses to LMS as long as you have a zip folder.
  • All the high-quality LMSs and the authoring tools are SCORM compliant so that they can build and be part of a great ecosystem of interoperability and reliability.
  • The introduction and evolution in SCORM have brought about a great reduction in overall cost of delivering training. The reason is that it has no additional cost for integrating any type of content. 
  • SCORM helps in standardizing eLearning specifications. SCORM provides a set of technical specifications that gives the developers a standard blueprint to work with.
How does SCORM Work?

Other than guiding the programmers, SCORM administers two main things, i.e packaging content and exchanging data at runtime to ensure workability. 

  • Packaging content or content aggregation model (CAM) defines how a piece of content should be presented in a physical sense. It is required by the LMS to export and import a launch content without the use of any human interventions
  • Runtime communication or data exchange helps in defining how the content is supposed to work with the LMS while it is actually being played. This is the part which describes the delivery and tracking of the content. Eventually, these are the things that include “request the learner’s name” or “tell the LMS that the learner scored 95% in a test”. 
“SCORM recommends contents to be delivered in a self-contained directory or a ZIP file.”
Working of SCORM Packages

SCORM recommends contents to be delivered in a self-contained directory or a ZIP file. These files contain content, defined by the SCORM standards and is called Package Interface File (PIF) or in other words SCORM packages. 

It contains all the files that are needed to be delivered in the content packages via SCORM runtime environment. 

Course manifest files are considered as the heart of the SCORM content packaging system. The manifest is considered as the XML file that describes the content. 

Some of the pieces involved in the packaging are:

  • Resources 

Resources are the list of parts that bundle up to be a single course. There are two types of resources that contribute to the course.

The first is the collection of one or more files that make up a logical unit presented to the users. The other is SCO or Sharable Content Object which is the unit of instructions that are composed of one or more files, to communicate with LMS. It mostly contains the instructional or static part of a content that is presented to the users via course. 

Resources should contain a complete list of all the files that are required for proper functionality of the resources. 

This is done to port the list to a new environment and function it the similar way. 

 

  • Organizations

Organizations are considered as the logical grouping of the parts of resources into a hierarchical arrangement. This is what is delivered to a particular learner when the item has been selected. 

  • Metadata 

Metadata are used to describe elements of a content package in its manifest file. They are important because they facilitate the discovery of learning resources across content package or in a repository. 

When a learning resource is intended to be reusable, it is a best practice to describe it with metadata. 

For describing learning content, Learning Object Metadata contains many predefined fields.   
  • Sequencing

Sequencing is responsible for determining what happens next when a learner exits an SCO. With navigational control, it orchestrates the flow and status of the course as a whole. 

However, it doesn’t affect how SCOs operate and navigate internally, that is defined by the content developer.

Drupal With SCORM 

Drupal is best at managing the digital content, but the task of planning, implementing, and assessing a specific learning process can be best done by an LMS.

How can Drupal become a platform for an organization that delivers effective training, manage learners, individual progress and record results?

Since Drupal is not an LMS, its distributions and modules help it become more effective. When it comes to SCORM compliance, Drupal has Opigno LMS as its core distribution.  

Opigno LMS is a Drupal distribution that integrates H5P technology (an open-source content collaboration framework based on javascript), which enable you to create rich interactive training content. It allows you to maintain the training paths that are organized in courses and lessons. 

This distribution includes the latest version of Opigno core that offers you effective and innovative online training tools.

Opigno LMS is fully compliant with SCORM (1.2 and 2004 v3) which offers a powerful editor for content management, in particular, to create course material. These courses can eventually be grouped into classes to provide easy and manageable training paths. It should also be noted that this distribution is the quickest way to present a functional e-learning platform out of the box, with the users, courses, certificates, etc. 

Based on this distribution, Opigno SCORM implements the SCORM feature in Opigno which allows you to load and play SCORM packages within Opigno training and is also responsible to handle and manage training paths that are organized in courses and lessons. 

Opigno LMS comprises an app store that also enables you to install latest features easily, without asking you to upgrade the current install. 

According to the requirements and expectations of the learners, Opigno LMS can be summarized by the following specification:

  1. Scalable to manage the hardships of a dynamic and modifying environment
  2. Safe and easy to update
  3. Support further development of customized functionalities with proper integration with the core solution in a modular way
  4. Open to letting each client be free and independent
  5. And most importantly, easy integration with other enterprise systems 

H5P javascript framework makes it easy to create, share and reuse HTML5 content and applications, allowing users to built richer content. With the use of H5P, the authors can edit and construct videos, presentation games, advertisement etc. To create an e-learning platform, the integration of HP5 framework and SCORM is essential.  


H5P SCORM/xAPI module allows to upload and view SCROM and xAPI packages. It uses two HP5 libraries namely (HP5 libraries are used to create and share rich content and applications)

  1. H5P SCORM/xAPI library to view SCORM package.
  2. H5PEditor SCORM library to upload and validate SCORM package.

You can create a new content type by uploading it in the preceding step of a process using the H5P editor.

In the nutshell

Different people adopt SCORM for different reasons. You and your team are the only ones that can decide whether sticking to SCORM is worthwhile or not. 

Depending upon the nature of your requirement and the course of action, it can be decided which platform is best for you. At OpenSense labs, we have been giving adequate solutions to our customers. Contact us on hello@opensenselabs.com to make the right decision on the correct choice of a platform. 

blog banner blog image Drupal Drupal 8 SCORM LMS Learning Management System Shareable Content Object Reference Model SCORM 1.0 SCORM 1.1 SCORM 1.2 SCORM 2004 E-learning Content Aggregation Model Organization Sequencing Resource Opigno LMS Blog Type Articles Is it a good read ? On

Capgemini Engineering: A framework for progressively decoupled Drupal

3 dni 3 godziny ago

A lot of people have been jumping on the headless CMS bandwagon over the past few years, but I’ve never been entirely convinced. Maybe it’s partly because I don’t want to give up on the sunk costs of what I’ve learned about Drupal theming, and partly because I’m proud to be a boring developer, but I haven’t been fully sold on the benefits of decoupling.

On our current project, we’ve continued to take an approach that Dries Buytaert has described as “progressively decoupled Drupal”. Drupal handles routing, navigation, access control, and page rendering, while rich interactive functionality is provided by a JavaScript application sitting on top of the Drupal page. In the past, we’d taken a similar approach, with AngularJS applications on top of Drupal 6 or 7, getting their configuration from Drupal.settings, and for this project we decided to use React on top of Drupal 8.

There are a lot of advantages to this approach, in my view. There are several discrete interactive applications on the site, but the bulk of the site is static content, so it definitely makes sense for that content to be rendered by the server rather than constructed in the browser. This brings a lot of value in terms of accessibility, search engine optimisation, and performance.

A decoupled system is almost inevitably more complex, with more potential points of failure.

The application can be developed independently of the CMS, so specialist JavaScript developers can work without needing to worry about having a local Drupal build process.

If at some later date, the client decides to move away from Drupal, or at the point where we upgrade to Drupal 9, the applications aren’t so tightly coupled, so the effort of moving them should be smaller.

Having made the decision to use this architecture, we wanted a consistent framework for managing application configuration, to make sure we wouldn’t need to keep reinventing the wheel for every application, and to keep things easy for the content team to manage.

The client’s content team want to be able to control all of the text within the application (across multiple languages), and be able to preview changes before putting them live.

There didn’t seem to be an established approach for this, so we’ve built a module for it.

As we’ve previously mentioned, the team at Capgemini are strongly committed to supporting the open source communities whose work we depend on, and we try to contribute back whenever we can, whether that’s patches to fix bugs and add new features, or creating new modules to fill gaps where nothing appropriate already exists. For instance, a recent client requirement to promote their native applications led us to build the App Banners module.

Aiming to make our modules open source wherever possible helps us to think in systems, considering the specific requirements of this client as an example of a range of other potential use cases. This helps to future-proof our code, because it’s more likely that evolving requirements can be met by a configuration change, rather than needing a code change.

So, guided by these principles, I’m very pleased to announce the Single Page Application Landing Page module for Drupal 8, or to use the terrible acronym that it has unfortunately but inevitably acquired, SPALP.

On its own, the module doesn’t do much other than provide an App Landing Page content type. Each application needs its own module to declare a dependency on SPALP, define a library, and include its configuration as JSON (with associated schema). When a module which does that is installed, SPALP takes care of creating a landing page node for it, and importing the initial configuration onto the node. When that node is viewed, SPALP adds the library, and a link to an endpoint serving the JSON configuration.

Deciding how to store the app configuration and make all the text editable was one of the main questions, and we ended up answering it in a slightly “un-Drupally” way.

On our old Drupal 6 projects, the text was stored in a separate ‘Messages’ node type. This was a bit unwieldy, and it was always quite tricky to figure out what was the right node to edit.

For our Drupal 7 projects, we used the translation interface, even on a monolingual site, where we translated from English to British English. It seemed like a great idea to the development team, but the content editors always found it unintuitive, struggling to find the right string to edit, especially for common strings like button labels. It also didn’t allow the content team to preview changes to the app text.

We wanted to maintain everything related to the application in one place, in order to keep things simpler for developers and content editors. This, along with the need to manage revisions of the app configuration, led us down the route of using a single node to manage each application.

This approach makes it easy to integrate the applications with any of the good stuff that Drupal provides, whether that’s managing meta tags, translation, revisions, or something else that we haven’t thought of.

The SPALP module also provides event dispatchers to allow configuration to be altered. For instance, we set different API endpoints in test environments.

Another nice feature is that in the node edit form, the JSON object is converted into a usable set of form fields using the JSON forms library. This generic approach means that we don’t need to spend time copying boilerplate Form API code to build configuration forms when we build a new application - instead the developers working on the JavaScript code write their configuration as JSON in a way that makes sense for their application, and generate a schema from that. When new configuration items need to be added, we only need to update the JSON and the schema.

Each application only needs a very simple Drupal module to define its library, so we’re able to build the React code independently, and bring it into Drupal as a Composer dependency.

The repository includes a small example module to show how to implement these patterns, and hopefully other teams will be able to use it on other projects.

As with any project, it’s not complete. So far we’ve only built one application following this approach, and it seems to be working pretty well. Among the items in the issue queue is better integration with configuration management system, so that we can make it clear if a setting has been overridden for the current environment.

I hope that this module will be useful for other teams - if you’re building JavaScript applications that work with Drupal, please try it out, and if you use it on your project, I’d love to hear about it. Also, if you spot any problems, or have any ideas for improvements, please get in touch via the issue queue.

A framework for progressively decoupled Drupal was originally published by Capgemini at Capgemini Engineering on December 14, 2018.