The document discusses the evolution of web development, highlighting the separation of user experience (UX) from server management, particularly in the context of Drupal and mobile applications. It outlines how headless Drupal facilitates this transition by delivering content as JSON objects, ultimately simplifying the development process by decoupling the UX from the traditional client-server model. The document emphasizes the growing importance of mobile apps and their influence on development practices and user engagement.

1. DRUPAL AND MOBILE
Separating 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.

2. 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 AdminTheme 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.

3. 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.

4. THEME
Thanks to Jen Lampton (jenlampton.com)
theme()
Theme Hooks
Theme 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.

5. DRUPAL 8THEME 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.

6. SERVER-SIDE RESPONSIVE DESIGN
• A Compromise of UX and
Content Management
• Does not Accommodate
Mobile Apps or IoT
• Convolutes the Work of
Designer, Coder, andThemer
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.

7. 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.

8. JSON OUTPUT FOR A UX
Backbone.JS - http://backbonejs.org
Addy Osmani
addyosmani.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.

9. WHY MOBILE?
• Closer to theTarget 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/

10. 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.

11. 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.

12. WHY NOTTRY?
• 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.

13. DRUPAL’S ROLE
• Content Modeling and ManagementTools
• Content Authoring and WorkflowTools
• 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.

14. –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.