Drupalcon 2015 Moves to Headless Drupal

There were a couple sessions at Drupalcon 2015 about headless Drupal and the move from web pages to web applications.

The first session in this ilk that I attended was Decoupled Drupal: When, Why, and How.  This was the introduction to setting up Services in Drupal especially in Drupal 8.  The presenters showed, although there is not a standard “Drupal” way to build headless Drupal, they showed that using the RestfullWS module you can build a complete interface to Drupal using another front end.  They are proposing that we standardize on a “Drupal” way to do this.  One of the presenters went to the Angular conference last week where they were building amazing front ends or web apps, but they did not consider the back end.  One of Drupal’s strengths is the administration of a CMS, things like reseting your password are tried and true, if you use Drupal int he backend these are done for you with little effort.

A similar presentation was Angular with Drupal 8, in this session it was presented the idea I presented before.  We need to start thinking about building web apps, applications that run in a browser or on a device that gets content as needed from the back end, rather than this one system that builds the pages and presents HTML pages.  Angular pages are a single web page that will get new content and present it to the user as requested.  The present an interface that is much closer to the user, giving a better experience.  It also means that you may not need as much from Drupal.  Currently if you want to include a map in Drupal you install a module that interfaces with Google Maps to present a map.  With Angular all you need to do is present the geo location (address) from Drupal and Angular can go to Google to get the map information.  Drupal can be less dependent on modules, Angular gains by not having to invent an admin interface to your back end components.  They presented a new concept API first design, when you create a Drupal site you first create a clean API that can be used by mobile apps, and other front end systems.  Then if you need to you can develop a web interface as well.  Angular is not the only front end tool in use.  It is currently the hot new tool but there are other frameworks are good as well.

I think it would be wise for us to consider this in future development.  We are already using Drupal’s services module to drive our app, so we are started in the correct direction.


DrupalCon 2015, the battle for the body field

At DrupalCon 2015 the first session I attended, was one close to my heart.  You can watch the session here.

The problem is trying to figure out how to give your content creators the functionality in a website to create the content they want to create and have a good website.

Normally the first solution is to use the “body” field, and turning on a WYSIWYG editor and let the content creator edit what they want.  The problem is that the WYSIWYG editors are not the best to use, and HTML is not the easiest thing to create the desired output.  So the content editors are frustrated trying to create what they want, and the output may look ugly and the HTML is pretty ugly as well.  Many times you loose consistency and will loose any responsive or mobile designs.  There is an example in the presentation where New York Times, Snow Fall article, which was great and compelling but cost $250,000 to produce.  So the presenter wanted to figure out how to do this with the Drupal tools we have on a consistent basis.  The developers figure it they can just structure the content with all the little bits and pieces we can assemble the desired output together.  If we can just get all the bits and limit the HTML tags that can be entered or use markdown we can solve this problem, but there are some things missing that allow for the content creators creativity.

To solve this the first step is to define a vocabulary about the content.  This will include the atomic elements of the structure (like a Call Out field) and must also have some usage characteristics, like that it will randomly be aligned within the article, it may contain a attribution and how it is to be formatted.  Also that we want to vary the formatting a bit on a per article basis.

Now you can find a way to define the components you want and create a way to indicate the location of this element in the article.  Then you can transform the content you save to the content you want to display.

I think this is a good definition of the problem we are trying to resolve.

Another option was mentioned Paragraphs which was covered later in the day.  Better Tools for Content Creators

Paragraphs can be used to allow you to intersperse your content with other content.  This is similar to the discussion above but it works best when your content is small blocks of content rather than long narrative text.  This is similar to what Marquee does, in Marquee each paragraph is separate, you can insert things between paragraphs like images, callouts etc.  If your content is small self contained blobs of content this technique works well.  I think this would work well for landing pages.