DRUPAL AND MOBILESeparating the CMS from the UX

The UI is no longer a coat of paint, and the monolithic client/server web application is going away. Today, most web pages include as many as 50 sites, and web services create more traffic between servers than between the clients and the server apps. Mobile applications will carry these changes even farther. The UX is being separated from the server, and that is a good thing.

WHY DRUPAL?

• Packages LAMP and MVC

• Delivers Formatted Content

• Conceived as a Message Board During the Early Days of REST & Mobile

• Themes Have Always Been an Issue, even the Admin Theme i86 CPU, Ethernet, Internet

VM/Hypervisor

OS/File System

Web Server RDBMS

PHP Application

Drupal, like many LAMP CMS, has been a powerful and convenient tool for implementing traditional, monolithic web applications. Drupal combines the flexibility of a framework with the reliability of a commercial product, and all-in-one solution.

The problem it solves, however, has bifurcated.

THE OTHER HALF

• jQuery, AngularJS, Backbone.js

• PhoneGAP, WSDL, Azure/AWS APIs

The worldwide web has always been a client/server model. The client side has its architecture, too. However, it was originally a very lightweight architecture, stateless with two-dimensional heterogeneity.

Today, the client has far more power than the entire client/server system did when HTTP was conceived. Today, one datacenter is bigger than the Internet was in 1980. Today’s web page often consists of content from more than a dozen web servers.

The model has adapted, and now it changes again.

THEMEThanks to Jen Lampton (jenlampton.com)

theme()

Theme HooksTheme Hook Suggestions

Theme Registry

hook_theme()

Templates

Template Preprocess

Preprocess Functions

Process Functions

Theme Functions

drupal_render()

Variables

hook_page_alter()

hook_theme_registry_alter()render()

render_element

Theme Override

As the core of the UI, theming has been complicated. So much, that it created a new role in development, the themer.

Anything as involved as Drupal will have inherent complexity, and the organic nature of Drupal development has created a system that is difficult to characterize and model. Therefore, it is harder to learn and use.

DRUPAL 8 THEME INTEGRATION

• Classic is Deprecated

• Twig/Symfony Templating Engine & PHP Framework

• Headless Drupal

Drupal 8 addresses this issue from the perspective of the Drupal developer by creating yet another abstraction layer. Twig provides a means to reduce the volume of CSS (‘div hell’) but does not address the underlying problem — the ever-increasing depth and complexity of the client. For a Drupal developer, the mobile client is farther from the server than any other. This is due to the nature of the device — size, orientation, and the gestures used to interact (the UX) — and, more importantly, the context behind the user’s intent. Mobile may have the user anywhere doing anything (e.g., driving a car), which creates entirely new use cases and greater development complexity.

Rather than add more complexity to address every use case, Drupal 8 formalizes an approach taken by several Drupal 7 modules that output content as JSON objects instead of HTML/CSS formatted content. Referred to as ‘headless Drupal’, this makes Drupal a web services provider. The UX problem is solved by removing it. More about this later.

SERVER-SIDE RESPONSIVE DESIGN

• A Compromise of UX and Content Management

• Does not Accommodate Mobile Apps or IoT

• Convolutes the Work of Designer, Coder, and Themer

These server-side tools such as Twig try to manage the continuity of the content amidst the frenetic fashion of the User Experience (UX). They succeed only through the frustrated efforts of the Coder, Themer, and Designer.

The developer is forced to deal with a myriad of derivatives — the Baskin Robbins of content. The designer is forced to deal with the developer. And the ‘themer’ is created to deal as an intermediary between the developer and the designer. Who wants to be a themer?

Responsive design works because many talented and hard working people make this awkward arrangement work. It has some advantages, too, such as potentially optimizing network I/O. However, it still makes the web experience a monolithic design and implementation effort.

HEADLESS DRUPAL

• https://groups.drupal.org/headless-drupal

• JS - https://www.drupal.org/project/js

• Restful - https://www.drupal.org/node/1860564

• RestWS - https://www.drupal.org/project/restws

One way to deal with a problem is to delegate it away. By taking the client UX out of Drupal, it can move to where others may find opportunity in taking over that development role.

Headless Drupal is an awkward metaphor for a web services application. A better metaphor would be Faceless Drupal. Even that is misleading. From the admin perspective, everything is still there, and the intelligence of Drupal — content and user management — is even more prominent. Missing is the developer’s headache of having to anticipate the UX. Call it headache-less Drupal. There are many efforts in this area:• JS is a High performance JavaScript callback handler• Restful, found on GitHub, github.com/gizra/restful• RestWS, Restful Web Services, uses the Entity API to provide resources representations for all entity types.

I have talked to many developers, who quietly admit that the theme and UI are the biggest pains. Reducing client I/O to JSON objects would make many Drupal development efforts idilic.

JSON OUTPUT FOR A UXBackbone.JS - http://backbonejs.org

Addy Osmaniaddyosmani.com

Backbone.js is a good example for a client-side UX. Actually, it does not reduce the complexity of the problem and still requires the web server to deliver the entire client. However, it creates a clean division of content/user management and UX management. Issues between the Designer and the Developer come down to JSON object structures and state maintenance. The trade-off for using Backbone is a larger initial payload.

Mobile applications address that trade-off.

WHY MOBILE?

• Closer to the Target Audience

• Fashion - Branding and the User Experience

• Fast Moving yet Sticky

• Better Security

• More ways to maintain State

Mobile goes beyond Backbone.js by dumping a HUGE payload on the client in the form of an app. In this case, the user expects it, as it is a one-time dump, known as an app store download. This opens new horizons of UX with native development environments, compiled run-time code, device-specific tools & libraries, and huge development ecosystems. Development objectives such as maintaining state, network connectivity, and security are better managed.

Mobile is where the users are, and mobile is hot. Mobile apps can provide a more intimate branding experience, and it can be fast and sticky at the same time. For the Developer, apps are an easier way to maintain state and provide security.

Business-wise, there are many mobile developers and most are design-focused. They are looking for the best ways to bring content to their customers. See http://blog.contractiq.com/top-50-custom-mobile-application-development-companies-a-curated-list-from-quora/

EXAMPLE

• NSJSONSerialization class

• E.g., http://github.com/CMDT/DrupalCMS

• Drupal 8 iOS & Android SDK — http://drupalsdk.com

• Kyle Browning’s Drupal iOS SDK for Drupal 7 — https://github.com/kylebrowning/drupal-ios-sdk

http://crackberry.com/android

Until recently, Drupal and mobile apps were custom work, requiring REST code for both the clients and the server. This made the abstraction layer between the content and the UX a custom design effort, which added time and cost to the development and led to ‘creative differences’ between the Drupal and the mobile developers.

Apple recently added JSON handling to iOS, eliminating the need for various 3rd party libraries or customer interfaces. The Drupal community is active in using this, too. There are iOS and Android SDKs for Drupal 7 and 8.

WHY NOT MOBILE?

• Another Development Environment

• Another Development Environment

• Another Development Environment

Drupal packaged the web experience for developers to provide a stable and relatively secure framework. As long as the UX was secondary to the content, this worked. Once the UX takes precedence, Drupal’s limitations become a developer’s dilemma. From the perspective of a monolithic development, this is a huge step function.

WHY NOT TRY?

• Another Development Partner

• Another Development Partner

• Another Development Partner

However, there are huge developer communities for mobile, far more than for Drupal. Mobile is a great opportunity for Drupal developers to partner with mobile. Mobile developers tend to be focused on the UI and the UX and need the back end expertise to differentiate their products. In other words, they need you.

DRUPAL’S ROLE

• Content Modeling and Management Tools

• Content Authoring and Workflow Tools

• Users, Roles, and Permissions

• Admin and ‘Classic User’ UIs

With Mobile, Drupal is now more powerful. As long as content needs to be managed, Drupal will provide the tools. Also, users much be managed and so must the site. The current model still provides the classic PC browser UI, too.

–David Richo

“Things change, so get used to it.”

In three years, Drupal sites will be talking to more non-browser clients than traditional browser clients. Mobile has changed the market, and Drupal will change with it.