Drupal in a tablet world

A few years ago, computer tablets similar to Apple's iPad were props in science fiction films. Only a couple of years from now, tablets might be among the most popular consumer electronics ever.

It took less than three months to sell the first 3 million iPads. This has made the iPad the consumer electronics device with the fastest adoption rate of all time. Compare that with the 1 million iPhones sold in the first three months of its release, and the 350,000 DVD players sold in the first year of their mass production.

According to CNBC, the iPad will surpass gaming equipment and the cellular phone to become the fourth most popular consumer electronics category -- televisions, smart phones, and notebook computers are the top three. Large companies like Hewlett Packard have no choice but to design credible alternatives to the iPad. Samsung will soon begin to distribute their Galaxy Tab, which runs on Android OS, in Europe and the U.S. Once these big players enter the market fully, it's pretty clear that we're heading to a new lifestyle in which everyone and his dog owns a tablet. I already have mine.

This all begs the question: in a world of tablets and mobile handheld devices, what do we need to do so that Drupal will be a go-to platform? How can Drupal contribute so as to be a player in the ever-expanding ecosystem of tablets and mobile phones? What needs to change so that developers can build easily tablet and mobile phone optimized applications on top of Drupal? At the rate that tablets and mobile devices are being adopted, we don't have much time to get in motion. Drupal 7 takes enormous steps in the right direction, and I have a some ideas for Drupal 8. However, I'd like to get your take first ...

Comments

One of the primary concerns when developing a platform that will be used with mobile devices, like tablets, is ensuring that all user interface components can be operated through an input device agnostic method. We have already started to make this a reality in Drupal 7, by doing things like ensuring that the tabledrag interface (the ability to drag and reorder rows within tables) can be operated by users who do not have access to a standard "pointing device".

Another concern for content presented on mobile devices is that the content is understandable when viewed on variable sized displays, even if it does not look exactly the same on each display. Again Drupal 7 Core themes are easily understood when used with zoom and text resize features of browsers.

Clearly there are mobile user interface and theming issues that do not map directly to accessibility requirements. However, I believe that as we continue to make improvements to Drupal accessibility, both in D7 and D8, we will be positioning Drupal as an even better platform to be used with mobile devices.

That's great, but let's not forget that Android devices are now outselling iOS devices. The sales are spread out across lots of different devices and manufacturers rather than being a tightly controlled 3 or 4 products, but in terms of what's moving off the shelves Android is winning. And that's before we consider the inevitable Windows tablets and the webOS tablet that HP is working on.

"This all begs the question: in a world of tablets and mobile handheld devices, what do we need to do so that Drupal will be a go-to platform? How can Drupal contribute so as to be a player in the ever-expanding ecosystem of tables and mobile phones?"

Today, making a mobile theme isn't terribly difficult, and there are a number of case studies out there showing interesting Drupal sites that have piped their data straight to custom iOS applications with great success. Drupal doesn't offer those site builders a lot of help, though: there are copious workarounds and compromises involved.

In my opinion, a lot of the yeoman's work for enabling smooth multiple-platform deployment lies in the underlying bootstrap, page layout, and page building system. It's one of the reasons why the discussions around the 'Butler' context/request/response concept could play an important role in D8.

For some sites (like one of the media clients we're working with), mobile isn't an alternate view of the same site but an entirely separate production pipeline, with a shared pool of content. Distinguishing between sites that need "mobile-enabled" and "tablet-enabled" versions of their sites... and those that need a more robust system for multi-target publishing, is a big question mark. Today, Drupal focuses on a single integrated everything.

There are lots of questions -- tablet penetration is still a tiny fraction of traditional browsers, but there's a lot of very interesting development going on. It's fun to watch Drupal's evolution into those new spaces...

I am about to launch two mobile sites on Drupal for "well know" companies that will get high traffic and need to run on large range of mobile platforms, including the ipad.

Using both the Wurfl module, for device detection and Mobile Tools for theme switching, we manage to get basic setups that allow for theme switching based on device types/category. And this is already a huge step when you want to go mobile. So I would say Drupal has already some support.

If I looked at the process of creating the mobile site I could clearly distinguish the "backend" part and the "theming part" of it. And it is in that last part that we always find most difficulties:

First of all from a design point of view: how to provide your content on this huge range of low to high end devices?

Use 1 degradable theme using media queries, progressive enhancement techniques, or just some luck...

or go for multiple themes for each device category...

And secondly, testing takes up much more time than you should expect. But these browser compatibility issues we also experience on a day to day basis on desktop (think ie6 support), and are not specific Drupal related. Experience, and knowledge of the different devices can help enourmously...

An upside is that in mobile we can use a lot of CSS3 and some html5 that will work on iphone, android, BB6, Palm Pre, Samsung Bada, Symbian^3... ( a fast growing list).

However, caching for mobile is what I experience in D6 as being not straightforward. If the concept of switching your theme, or making design choices in the template based on device characteristics, persists, then there is the need for caching based on device group (and not just url)... Quick fixes are possible by creating your own cache file (I recently added an example in the Wurfl module), or hacking your preferred caching module to "alter" the CID based on device group.

I am not sure yet if D7 has this "_alter_cache_id" in core, but this would be my personal suggestion on enhancing Drupal for better mobile performance. If it is already in D7, then we have here the perfect use case for it :)

Of course I am only talking about the "website part" of mobile and the effort of making "designed for mobile" websites. This in contrast to do a best effort to make desktop sites run on ipads or using the services module to feed native apps.

Great to see some thinking on this for Drupal. Remember that it is not only idevices, android is making big inroads into the market, there are still many older devices that are web enabled and we may need to start thinking about TV's and other household items.

One of the big issues we need to address is data and how expensive it can be. We have all heard stories of people getting charged massive amounts for blowing their mobile data usage quota.

Drupal loads a lot of unnecessary files for mobile devices. Sure there are mobile themes and modules to switch between themes when a mobile device is detected. These usually rely on the user_agent string from the browser and a list of known devices. Both may be wrong or out of date.

It's not only the number themes files and CSS and js, it's also the amount of data transmitted overall. It means pictures, lines of code, texts. Mobile communication network is not as capable as computer's one. A idea for a tool : a module that would measure the amount data total in each page, and that would print on every page - or integrated with devel, themer or mobile tools. That way with a module like Panels one could create lighter page in terms of theme weight, content loaded by focusing on main content and navigation, complexity and calculation time.
And make Mollom recognize iPhones (I'm not a spammer :).

I'd like to see Services module mature and move into core. Thats how we give a robust backend to all these native apps. For web based apps, we are already in good shape IMO. I can't think of anything in our core code that relies on a large screen to work. Perhaps some admin pages do but it is reasonable to expect folks to admin using larger screen. Contrib can provide small screen admin experiences. It isn't hard.

The plan at this point is to have the Butler project take over much of what Services does, and I've been talking to Larry a lot about what Services does and how it works. I agree this is a very important step to having Drupal work for mobile devices, as Services has largely become the de-facto standard for this communication. The new version is a big step forward but like all other popular contrib projects, we could use a ton of help in keeping the momentum going.

i agree with moshe and want to add that imho, the "experience" is already covered for web apps and via assorted custom themes to handle output - i'd much rather see the focus of drupal center around A) relentless focus on ease of use and simplicity (for new users mostly) , B) speed and performance improvements, and C) some kind of step toward nitwit-proof data portability so that users who don't get services or API's can click a button that spits out data to push into a mobile app platform (i'm thinking of some of the many simple app builders that assume a user is piping in content or runs a CMS of some kind)

...oh, and maybe built in support for FB *and* diaspora (could drupal run diaspora native and become a one-click hub/install for users who want to run a hosted instance? that would be cool...and tie in to drupal profiles/activities etc)

In addition to what has been described earlier to things jump out at me. First, we need to optimize what gets sent to the browser. There is room for improvement there. Instead of dealing with PC processors and lots of RAM we are talking about a platform where the ARM chips dominate and there are less resources. The front end should be snappier and we have room for improvement there.

Second, we should have a mobile theme in core. Dealing with building a mobile site into core will give us a case where we have to think and work through APIs, how we deal with different clients, etc.

Becoming a great mobile platform is going to cause some of us to rethink some of our assumptions.

Perhaps we will face the same choice for tablet/mobile than several years back when the community choose JQuery as javascript framework. Jquery is multi-browser, and we should definitly choose a multi-mobileOS road (not specific to iOS, Android ...)

I see 2 roads:
1- Web: we could facilitate the dev work with a framework like http://jquerymobile.com (will bring us a more "agnostic" experience iOS, Android ...), or http://xuijs.com/
2- Native Application: which will bring more integrated user experience, with a good integration with Drupal services as backend. I'm not specialiste, but perhpas we could develop a drupal native application layer ? Or use http://www.phonegap.com

A lot has already been said about mobile web sites. But the real challenge I think is about native apps.

When I got my iPad I was surprised to see nearly no web sites that talk about integrating Drupal with a native apps. While the first version of a native iOS app with phonegap and JQTouch is not that difficult the real problem for me was using the services module from Drupal. Even with some programming experience I could not get it to work. This needs to be MUCH easier! Maybe a Drupal services plugin for jQuery anyone?

I am happy to see that in the meanwhile Drupad has been released, a native iOS app + Drupal module that takes an interesting generic approach, at least for admin work. I did not try it yet, but it looks promising, especially a potential iPad version. It is 3,99 EUR though.

1. Robust support for all the HTML5 goodies that hold so much promise for mobile services, especially the location API and the local data storage. I want to be able to make it all Just Work from Drupal without having to code any Javascript. I know a lot of work is being done in the jQuery community to make this happen.

Google gave us a taste of offline functionality in Google Docs. Wouldn't it be awesome to write Drupal functionality that continued to work when disconnected, then sync on reconnect? Wouldn't it be great to define a set of content that would be background-downloaded into a device for fast/offline usage?

The New York Times just started experimenting with some touch gesture Javascript. How do I make a list of nodes in Drupal that can be sequenced through horizontal page-flipping gestures? We come from a world where it's all about the link tag, and that's just not the case any more.

2. Apps. I'm a bit of a pessimist. Most of the apps I'm seeing don't really do much that can't already be done on the Web, except for reading when the connection dies and maybe a little performance boost. Given the opportunity, users will spent most of their time in the connected world.

For the cases where native client-side implementation makes sense (set the bar high), we need client-side frameworks that support high-level interaction with Drupal through a documented Services-based API ... and we need examples. One API should serve all platforms, but development-framework support on the client side is going to be a train wreck. I said I'm a pessimist.

Making Drupal "tablet-ready" is mainly a matter of good themes with big buttons.

Personally, I would like a module that gathers usability statistics from users who agree to participate. This could also have a server-side component that detects misclicks (e.g. user hits "back" immediately after page load, thus reloading a non-cached element). This could be used for feedback to themers and webmasters.

In order to take advantage of the new possibilities we should also have a vigilant eye on SMIL and the comfort features tablet manufacturers integrate in their browsers but right now I do not see any development that would call for any additional functions in the Drupal code.

All of these tie into a new level of consulting for Drupal, and it's something (as Kyle mentioned above) we've been putting a lot of work into for the last six months. Drupal has always been strong as a platform for SIP, XMPP, and pub/sub (remember that? :). Now, we're looking to extend the platform from a community standpoint so Drupal can be the "middle" — the message and identity hub — for a whole new breed of applications.

There's a lot to do here. Moshe and Jeff's comments are especially relevant regarding theme and services (as always).

One thing that everyone should realise about tablets is that they make web accessible to even more people than it ever was. My grandmother can not use keyboard, but our demo application was easy to use for her after 30 seconds showing. So my advice is to think always the minimum set of basic features very well first and then add features to more advanced users, who will know their way in UIs anyway.

Hmm, after trying to submit this page, I found out couple of big mistakes, especially if I would have been working on a tablet:

1) I didn't originally put "http://" to the web address, so I was given error message _after_ submitting (should have either not be needed at all or at least given as tip for the field) and the error message displayed on the top of the page - and had to go all the way down again in order to make the correction

2) Then I got captcha which I understand is often needed, but is also good example of how things are more awkward often with tablets; in this case the field is quite small, sometimes on-screen keyboard may prevent from spotting the captcha at all.

These kind of basic ui elements need to be planned well for different sets of devices and offered e.g. as well thought out set of customisable themes for developers. We can help. 8)