Do Naked WordPress And Web Apps Mean The End For Mobile Themes?

Do Naked WordPress And Web Apps Mean The End For Mobile Themes?

The dominance of theme-driven delivery of WordPress content to readers has been virtually unchallenged over the last ten years.

But Atlantic Media’s Quartz has shown that web apps can not only match but surpass themes in providing a great end-user experience.

In this article, we’ll consider the advantages of delivering WordPress content via a web app, look at how to deliver your site using a web app with a proof-of-concept and ponder whether the days of the traditional WordPress theme are numbered.

iPhone in landscape with WordPress logo
Web apps offer plenty of advantages when delivering WordPress content to mobile users

In my first article for WPMU Dev, I wrote about syndicating by using WordPress as content hub and suggested that one end-point for content could be a web app. At the time, I was blissfully unaware of Quartz (qz.com), the “digitally native news outlet, born in 2012, for business people in the new global economy”. Most importantly in the Quartz blurb is their stated focus on “the devices closest at hand: tablets and mobile phones”.

So, What Makes Quartz Special?

Although hosted on WordPress.com’s VIP service, Quartz eschewed the traditional WordPress theme and, instead, developed a web app to provide the user interface. And not just any web app but a responsive web app.

WordPress functions purely as a naked content management system, providing the features (some via custom plugins) to create, manage and control the content and a JSON API to deliver the content to the web app. It is, then, completely quarantined from any end-user interaction, although it does serve content to search engine bots where clearly the visual design is not significant.

WordPress doesn’t even deliver the web app, that is handled by Quartz’s content delivery network, and a separate application is used to manage user accounts (for commenting), so WordPress itself has no interaction with the end user at all.

This WordPress without themes. This is naked WordPress.

The web app, built primarily on Backbone.js and jQuery, handles all the user interaction, providing the user interface and all its components and taking care of deciding what content has been requested and retrieving, formatting and displaying it. Effort has obviously been made to make the app as self-sufficient as possible: for example, all the icons are generated from embedded SVG rather than external files or even image files.

Despite this being a web app, to all intents and purposes it functions as a web site thanks to some really impressive url management. Visit any Quartz url and you’ll get that post displayed in the web app; and watch the location bar change as you scroll and new posts are automatically loaded when the bottom of the current post is reached.

And with 5 million unique visitors in August 2013, it’s clearly a set-up that not only scales but that readers enjoy.

Powered by WordPress.com  VIP but no themes involved here
Powered by WordPress.com VIP but no themes involved here

More on Quartz:

4 Advantages In Going Naked?

Obviously this approach was a conscious design choice and it is worth noting, again, that Automattic are fully onboard given that the content is served from a WordPress VIP account.

I like the separation of function, allowing each application to concentrate on a single function (WordPress to create, manage and deliver content, web app to handle user interactions). Here’s four reasons why:

1. Leaner, More Robust and Easier To Manage

Take a look at your plugins list now. How many plugins do you have? Chances are you’ve got quite a list covering everything from helpful functions for creating and managing content to front-end gizmos to enhance your theme.

In the web app scenario, where WordPress is that naked CMS, that list is restricted simply to those plugins required to manage the content. This makes WordPress leaner, far less prone to conflicts, less vulnerable and ultimately much easier to manage.

If you also think about most of the front-end gizmo plugins, they are mostly about embedding a client-side solution (usually jQuery-based) in your sites. With a web app, the solution is added directly to the user interface, no need to wrap it in a plugin, thus saving time and effort.

2. Multiple Channels, Interchangeable Components

As soon as you separate out the content creation from the content delivery, you give yourself the opportunity to swap or add components.

It’s easy to run multiple apps off the same content base but where it gets interesting, and potentially troubling for WordPress and other CMS developers, is the option to swap out the content management component. So long as the JSON API is maintained then your web app neither knows nor cares whether it is talking to WordPress, Drupal or any other application.

This is also one reason that I think that WordPress.org needs to pay more attention to the admin interface or it runs the risk of losing out to competitors if web apps become a popular approach.

3. Focussed Developers, Shorter Development Time

I’ve always been impressed by WordPress theme developers. The requirement to be proficient, at the very least, at both ends of that HTTP call strikes me as being both difficult to fulfill and daunting. And that’s without adding a design capability to the mix.

Perhaps that explains why there are so many bad themes out there?

The separation of function that comes with web apps removes this requirement. No longer does the developer of the user interface have to know anything about WordPress; they just have to know how to interact with the JSON API.

The web app toolkit is already mature with tools such as jQuery and Backbone.js not only having extensive communities but are earning their stripes in some major installations. This means that finding developers should be almost as easy as finding a WordPress developer.

And it also means that the WordPress developer can concentrate just on WordPress and providing the functions and features to facilitate the content creation and publishing processes and ensuring that the JSON API delivers the content required by the web app.

In a greenfield project, these two development streams can run side-by-side potentially reducing the time required to complete the project.

4. App-like Experience Without App-Like Headaches

The biggest single reason for developing a web app could be your desire to target the mobile platforms without the overheads and headaches of developing multiple native applications.

Whilst it does depend on the functionality you want to deliver, modern web apps can get pretty close to a native app experience, with the massive advantage, of course, of a single application being compatible across all platforms.

Quartz are not alone in the publishing world, in particular, in deciding that web apps offer the most cost-effective path to delivering content to mobile platforms. Both the Financial Times and Melbourne’s The Age have ditched native apps in favour of their web-based cousins.

Indeed, if web apps really take off then we could see a rapid demise in the development of native apps.

3 Scenarios Where Going Naked Makes Sense

1. You Want To Focus On Mobile Users

A web app allows you to design purely for the smaller screen. Even if you decide that, like Quartz, that the app has to be responsive and work on smartphones and tablets, taking desktops out of the equation greatly simplifies the design process.

A whole raft of tools and frameworks exist for the development of web apps which should also help provide that native app feel.

2. You Want To Power Several Products From The Same Content

Repurposing content is the holy grail of many publishers and web apps brings this a step closer by allowing for the rearranging of how content is formatted, its level of granularity and how it is collated. For instance, we could use a web app to deliver a “Best of 2013” for the WPMU Dev, using already published content but collated into topic areas and delivered with more of a book feel.

3. You Want To Manage Your Content In A Single Repository

If you run multiple sites, then you have multiple admin interfaces, multiple content repositories and, more than likely, multiple plugin repositories with the same or similar list of plugins.

By using web apps instead of sites, it would be possible to consolidate on a single WordPress instance, with a single content repository and single, likely much shorter, list of plugins.

Get Your Kit Off: A DIY Web App Proof-Of-Concept

The proof, as they say, is in the eating, so let’s walk through a web app prototype which should, in theory, work with any WordPress site. Keep in mind that I’m not presenting this as a fully-fledged solution, merely something that might pique your interest either to develop something yourself or to get a better developer than me to create something for you.

Something to pique your interest in web apps
Something to pique your interest in web apps

You can download the web app and run it straight from your file system. It’s hooked up to a test site at the moment but if you want to use it with your own site, then you just need to set up the JSON API on your WordPress site and update the endpoint variable in the javascript.

I’ve taken my inspiration from Quartz but rather than trying to create an app that works across all platforms, I’ve cheated a little by concentrating on creating a smartphone application as, to be blunt, it’s a lot easier.

The app is a single-page app but provides four “views”:

  1. Home – a list of the most recent posts
  2. Category – a list of the most recent posts for a category
  3. Post – the display of a single post
  4. Page – the display of a single page

There’s also a categories menu and a pseudo-slideout sidebar menu.

The web app works out which of these views is required, calls the JSON API to retrieve the appropriate content, formats this content as HTML and then replaces any existing content in the content placeholder (‘#page-content’) with the new content.

The two most important functions in a web app are routing and templating. Routing handles user requests, essentially any time the user clicks or taps on a link, whilst templating takes JSON-formatted data and converts it to HTML.

Not being familiar with Backbone.js, I’ve used two simpler alternatives in Satnav.js for routing and the popular Handlebars.js for templating.

Routing With Satnav.js

Generally, a click or tap on a hyperlink will cause the browser to navigate away from the existing page to the new page or file. In our one-page web app, we don’t want that to happen, we want to catch that request, stay on the current page and perform the appropriate function, most likely a request for content and the display of that content.

This is what Satnav.js does for us and as you can see from the following javascript, it’s pretty straightforward to set-up:

{code}

Satnav({
html5: false,
force: true,
poll: 25,
}).navigate({
path: ‘main-menu’,
directions: function() {
$(‘#main-menu’).toggle();
}
}).navigate({
path: ‘home’,
directions: function(params) {
load_home_page();
}
}).navigate({
path: ‘post/{post_id}’,
directions: function(params) {
load_post(params);
}
}).navigate({
path: ‘page/{page_id}’,
directions: function(params) {
load_page(params);
}
}).navigate({
path: ‘category/{cat_id}’,
directions: function(params) {
load_category(params);
}
})
.otherwise(‘home’)
.go();

{/code}

The html5 attribute determines whether navigation is pushState based or hash based. What this means is whether the urls are presented as ‘post/1’ or as ‘#post/1’. Whilst the former (pushState) is prettier, and indeeed is what Quartz uses, its implementation is patchy across browsers and can cause some security concerns on others. So, I’ve stuck to hash navigation.

The guts of Satnav.js are the navigate functions. Each one captures a particular path (request) and defines the direction (function) that needs to be executed. Variables, such as post_id, are specified in the path by using {}, e.g. /post/{post_id} which are passed to the directions in the params variable.

Notice, also, that even though we are using hash navigation, the # is not specified in the path.

Templating With Handlebars

The web app only receives content in the JSON format and therefore it needs to be formatted before being displayed to the user, just as in a normal WordPress request where content is formatted using the appropriate theme’s template.

Handlebars provides a simple templating language for formatting JSON data. Each template is included in the HTML page as a script and a unique id; the template is compiled; and the HTML output generated by passing the appropriate data to the compiled template.

Here’s an example template that formats a post:

{code}

<script id=”single-post-template” type=”text/x-handlebars-template”>
<article id=”single-post”>
<header>
<h3>{{post.title}}</h3>
<h2>{{getExcerpt}}</h3>
<p id=”meta”>By {{getAuthor}} | {{post.date}}</p>
</header>

<img src=”{{getFeaturedImage}}”>

{{getContent}}

</article>
</script>

{/code}

Values from the passed JSON data can be placed directly into the template by including the qualified path in double parentheses {{}}. Handlebars also allows for custom javascript functions, called helpers, to be called to return content and I’ve used these in a number of places. For more information, have a look at the Handlebars documentation.

The template is compiled by calling, not surprisingly, the compile function:

{code}

var tpl_single_post = Handlebars.compile( $(‘#single-post-template’).html() );

{/code}

And the HTML is generated by calling the compiled template with the JSON data. Here’s an example, including the call to the JSON API to get the data for a post and then generate the HTML

{code}

function get_post( id ){

// #page-content is the placeholder for all our content
$(‘#page-content’).hide();

// set up the method and add the id variable
var method = ‘get_post&id=’ + id;

// generate the JSON API url
var url = endpoint + ‘?json=’ + method + ‘&callback=?’;

// call the JSON API

$.get( url , function( data ) {

// call is asynchronous so need to put post-retrieval actions here

// replace the page content with the post
$(‘#page-content’).html(
tpl_single_post( data.post )
).show();

}, “json” );

}

{/code}

That’s a fairly brief walk-though: I just want to give you enough of an explanation so you can poke around the code and get inspired. lt’s probably also worth reading the documentation for Handlebars and Satnav.

Setting Up JSON On WordPress

For all this work, of course, your WordPress site needs the JSON API installed. There’s a few options here, including Jetpack, but I’ve opted for the JSON API plugin as it’s stable, proven, well-written and I’ve used it before.

As an interesting aside, this plugin was developed for the Museum of Modern Art where a Ruby-based website pulled content from a WordPress back-end. A very similar concept to what we are looking at here.

Go to Dashboard > Plugins and search for JSON API. The plugin you want is the one written by dphiffer. Install and activate the plugin.

Running the Proof-Of-Concept

Download the webapp and unzip it. If you want to run it against your own website, and you’ve enabled the JSON API, then open up index.html in your favorite editor and look for:

{code}

var endpoint = “http://162.243.67.226/master/”

{/code}

Change the url to your own WordPress instance; one running locally should be fine.

Now, simply open the index.html in a browser, preferably on a smartphone (or use an emulator). On entry you should get the home view which will simply list the most recent posts. Click on a post title to view the post; click on Categories and then on a single category to view a category archive.

You’ll notice that as the content changes the url in the browser’s location bar does too, yet the page never refreshes.

If you are going to play around with the web app (and I hope you do) and if you are using your own site then you might find it useful to know that you can call the JSON API in your browser to view the returned data.  Adding dev=1 to the query string will format it and make it far more readable.

For example, to show a specific post use: http://[site_url]/?json=get_post&id=[post_id]&dev=1

And I think it’s worth reiterating that this is a proof-of-concept not a suggested solution. This was quick and easy to knock up and shows the power and ease of the web app approach.

So, That’s The End Of Themes Then?

Whilst I think that web apps have enormous potential, they aren’t about to take over from the traditional theme, mainly because at the moment you’ve got to build it yourself. There’s a reason that most of us are theme consumers rather than theme developers.

What will be interesting to see is if commercial offerings start appearing, perhaps even ironically as a WordPress theme that can be configured by the site admin and then either be exported or delivered to the device on the initial request.

What is clear is that many more publishers are likely to follow the lead of Quartz, FT and The Age and look to web apps to deliver that wow experience for non-desktop users.

What do you think about web apps replacing themes? Have you created a web app that uses WordPress as naked CMS? Let us know in the comments.