Blueskying Drupal 8 Mobile Solutions

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
JohnAlbin's picture

Building mobile solutions encompasses a large problem space: native apps, HTML5 web apps, responsive design, device capability detection, mobile/desktop switching, front-end performance, etc.

I'm seeing lots of really interesting contrib modules and themes tackling mobile problems in Drupal 7.

Since Dries has already indicated that mobile will be an important aspect of Drupal 8, my question is:

what do you think Drupal 8 core (not contrib) should provide for mobile solutions out of the box?

Comments

Clean markup!

jpamental's picture

I think that given the variety of solutions (my current norm is HTML5/responsive theme), possibilities of HTML5 APIs and other ways of creating web apps or native ones, clean uncluttered markup (or even the ability to just output data more in the way Expression Engine does as far as I've heard it described) would seem to provide the greatest flexibility. I think that going further than that starts making assumptions about platform or delivery that likely shouldn't be made in core.

One thing discussed in the closing panel at Do It With Drupal last week was the notion of core outputting an array of data and then using a selected 'markup engine' to generate the output you want: JSON, HTML, etc. Maybe a bit ambitious, but that might be a way to get at the more ideal scenario of creating just the markup you want/need and no more.

Cheers-

Jason

Jason Pamental
[ @jpamental ]

I like ambition!

JohnAlbin's picture

One thing discussed in the closing panel at Do It With Drupal last week was the notion of core outputting an array of data and then using a selected 'markup engine' to generate the output you want: JSON, HTML, etc.

By the way, have you seen the core conversation I did on that subject at Drupalcon London? http://london2011.drupal.org/coreconversation/1300-1330-responsive-conte...

  - John (JohnAlbin)

watching the video shortly!

jpamental's picture

I think this was the same time I was giving my session on web typography - but I'm definitely going to check it out! Thanks for the prompt.

Jason

Jason Pamental
[ @jpamental ]

Responsive image solution

JohnAlbin's picture

I don't want to limit people's imagination, so I'll kick off the discussion with an obvious one. We need to have a responsive image solution in core. Drupal 7's image styles are awesome and there's surely some way we can leverage that to provide an image scaled for the device viewing it.

The funny thing is, I actually have no idea (yet) how to accomplish this. Jason Grigsby documents about 8 different ways to do this and none of them are ideal. http://www.cloudfour.com/responsive-imgs/

  - John (JohnAlbin)

Adaptive images

RainbowArray's picture

I particularly the adaptive-images.com approach, and I think it's particularly well-suited to how Drupal works, since image cache could easily generate the various sizes of images.

jpamental's picture

I've been looking at the stuff posted by the guys at the Filament Group and it seems like there are strong parallels with how image cache presets work anyway.

For example - in the responsive sites I've been doing I have 3 sizes of images - small, medium, large - set to pixel sizes I know are going to be a bit larger than I'd ever likely need for that size. When users place them in content they pick by size and I format with percentages of the area where they are placed. That percentage and allowed floats change with media queries.

If we take that same approach and use viewport width to replace the preset source of an image used anywhere in the site that goes through imagecache it would make a reasonable hook.

OK - so maybe not the most technical description, but enough for conversation to start, right? :)

Jason Pamental
[ @jpamental ]

Not sure whose problem this is...

eatings's picture

I've thought a lot about responsive images since your presentation in London, and I can't quite tell where this problem sits: is this is something that should be handled by a more robust Media module, a more presentation aware context system (WSCCI?), or something else? I guess not having an identifiable solution in the abstract doesn't help here.

Lean on ImageCache / image styles

rupl's picture

In @grigs' post yesterday, he pointed to Sencha.io SRC as the future-friendly option for responsive images as it stands today. Lucky for us, we already have a huge chunk of that infrastructure built into D7 core's image styles, better known as ImageCache in D6.

I've never used Sencha.io SRC (aka TinySRC), but I read the documentation and think we could write an add-on module that will provide the additional image style functionality found in TinySRC. It has some cool features that we could leverage, namely device detection on a per-request basis that allows for dynamic sizes such as "50% screen width" or "screen width minus X pixels."

I'm quite leery of setting device/feature detection results in a cookie, but I think some richer image styles options are worth investigating — even if they use per-request device/feature detection to achieve results. There are clearly performance issues with rendering dynamic image styles, but this seems like an option we could easily bolt on to improve our image handling overall.

I have been doing extensive testing with Scott Jehl's data-attribute-based responsive images JS combined with D7 image styles and really like the results. Having dynamic image sizing would make this combo even more powerful.

sounds like a sensible approach

jpamental's picture

I think that the more closely we can parallel how the media queries themselves work in tying into viewport width the better - and this sounds really promising. Let me know if I can help test/debug/develop!

Jason Pamental
[ @jpamental ]

+1 to leaning on existing

eojthebrave's picture

+1 to leaning on existing code. I haven't had much of a change to look into existing solutions yet but would like to. That said I know the existing image handling code inside and out and am happy to help implement a solution in core.

Responsive admin

crashtest_'s picture

I am really caught up in the idea that the admin interface should be responsive enough to allow easy use of the admin on mobile devices. That is one of the main things I would like to see accomplished in the responsive sprint that I proposed for DrupalCon. That, plus making Bartik responsive out of the box.

Other than that, yes, I think that the ability to output JSON, not just HTML, would be awesome. That would make creating native apps that feed off of Drupal data much easier to work with. That and being able to authenticate easily with Drupal from mobile devices.

I think mobile has become one

MrMaksimize's picture

I think mobile has become one of those terms that encompasses everything that isn't a traditional laptop / pc. And it is partially true. There is a wide range of mobile devices out there today, and somewhat a lack of standards.

This isn't much different for devices that could be considered outside of the normal 'pc / laptop' use case. TV's that could browse the web, refrigerators, pretty soon I'll be seeing some kind of chip with a little screen built into my hand so i can check my twitter account. None of these have a set of standards, and if Drupal tries to be everything to everybody, I don't see that going so well.

That being said, what I would really like Drupal 8 to have out of the box, is also something Dries mentioned. Web Services. I would like to see Drupal to become my central source for everything I develop. If I want to develop an application for the Pyoning 720BCAE Mark 9 (Not an actual model) refrigerator that came out on the market yesterday and can only read some obscure xml markup, and at the same time provide data to an Iphone App, and a Windows 7 app, I want Drupal to be the central source of data.

The only way we'll get there is through web services. The services module is an awesome start, and as I work with it more and more I discover new things and new potential use cases. As Drupal focuses more and more on web services, and taking the data it has rendering it into different formats, such development will be possible.

On top of that, I want Drupal to automatically generate documentation for all web services that are available on the system. This documentation should be machine-readable as well as human-readable. WADL is a good start, but I think we can improve. This documentation could be used by systems outside of Drupal to automatically generate code that will connect to the system.

Just ramblings :) But I think that's where we should be heading as a system, a platform and as a community. The real strength is in the apis :)

Working on it!

Crell's picture

http://groups.drupal.org/wscci

We need more hands to get it done, though, since we're basically reinventing Drupal. :-) Ping me in IRC or come by our next IRC meeting to see where you can help out.

For sure! Would love to help!

MrMaksimize's picture

For sure! Would love to help!

dOwen's picture

Responsive video: http://drupal.org/project/fitvids

It is trivial to use and scales very nicely in D7.

Responsive images: http://drupal.org/node/1289692

Although I still don't have it working, others do.

I'm just a themer and could

dotman's picture

I'm just a themer and could really use some help implementing fitvids with the Omega theme into my site. could anyone give me some direction?

thanks.

Drupal as back-end separate from Drupal as front end

jefflinwood's picture

I agree with MrMaksimize and CrashTest_ on the importance of web services and JSON. I'll take it a step further and say that Drupal 8 will have to be decoupled using its own Services API to really make mobile an excellent experience. Basically, the existing PHP front-end should be considered equivalent to a native app front end, or an HTML/JS front end using jQuery Mobile or Jo.

Take a look at Twitter - everything their front-end web client does comes from the same APIs they open up to developers.

Services 3.x is great, but I can't do a lot of things through Services (yet). There are some Drupal admin clients for iOS and Android, but nothing like http://ios.wordpress.org/

I think the future is bright for Drupal as a back-end for mobile applications, but I think there needs to be a better story. I enjoy working on native and HTML5 mobile apps, and anything I can do to help on that side, I'd be happy to.

Just my opinion, and offered because it's a blue sky open question!

Drupal as API

batsonjay's picture

Adding one more voice to your comment, I think this is the right approach, too - and I think it's what crell is trying to do with WSCCI.

A really good example of how this can (/should?) be done is to look at the screencast of the new interface for my.fcc.gov. This site is built as you're suggesting. It uses the contentapi module puts a layer on top of the services module to expose all Drupal content via APIs more tuned to content retrieval than the services module does. Drupal sends the browser nearly nothing except HTML structure (e.g. divs, ..) that contain javascript that makes a callback to Drupal to get, then render the content.

The my.fcc.gov site isn't the approach needed for everything. There's a good middle ground needed, because most pages (that have a main node body) need to have that body in text so that it can be indexed by search engine crawlers. And not everything wants to look like a dropped widget.

This (I think) is what the main fcc.gov site does; part of the page is "classic Drupal" and part is rendered by the JS widgets. But essentially, the back end & front end are (more extensively) separated.

The nice thing about this approach - when combined with the context stuff from WSCCI - is that you can get very mobile-oriented quickly. Though there are admittedly issues with putting too much JS on the phone, you can mix/match with JS & static content, especially with a responsive theme, and get to a very nice mobile result.

JS for content

RainbowArray's picture

I'd be very leery of any solution that required JS to display content. Annoying as it may be, there are around 5-10% of users out there without JS enabled, usually do IT restrictions. For those users to get no content would not be acceptable. This would also be a serious accessibility issue I would have to imagine. This is blue sky thinking, so I don't want to entirely stomp on this. Still, I think there are other directions to go besides requiring JS for content.

Responsive layout

RainbowArray's picture

What I'd most like to see is for Drupal to play really well with responsive web design techniques out of the box. Omega does a pretty good job with this, although they have only a few media query breakpoints set up for CSS files out of the box, and changing those is not for a newcomer. I'd really love to have the ability to create an arbitrary number of breakpoints with various device-widths and attach CSS files to each of those breakpoints.

There's certainly an argument for making the media queries within CSS files, rather than attaching separate CSS files, particularly since this would play better with CSS consolidation. But if that's the case, then really the only thing Drupal 8 can do is do media queries within the CSS files of the base themes, as a showcase of what can be done. That doesn't necessarily make it simple for others to step in and create their own responsive layouts.

Omega's mobile first approach

banghouse's picture

Omega's mobile first approach in core themes or maybe even a minimalist iteration of Omega itself would be just fine by me. Feel free to tell me the pros/cons of such a suggestion.

I think Omega is amazing, but...

jpamental's picture

I think that honestly the choice to be responsive or not is in the theming layer, so while it would be great to have Omega (or something darn close) in core would be great (especially with source order control in addition to layout) - ultimately I think that core should be focused on delivering content devoid of markup assumptions. That's where I first had the notion of core just spitting out an array, and then selecting the 'markup engine' to render it as nice clean semantically-correct HTML or whatever other format is needed. Then you can select the theme to do anything further with it (or maybe the 'markup engine' isn't necessary and it's all in the theme?)

It seems this would give the results that both 'small core' fans and hard-core front-end developers and designers are looking for: fine-grained control over output without sacrificing the flexibility inherent in Drupal for the content creation and structure configuration.

Jason

(not sure how well that covered pros and cons, but oh well!)

Jason Pamental
[ @jpamental ]

Meh, there's nothing exclusive to Omega

rupl's picture

Meh, there's nothing exclusive to Omega that requires it be included. It's not "Omega's" mobile-first approach anyway. Mobile-first is a years-old concept that Jake rightfully promotes, and his marketing of Omega has been very successful in the last few months. I am glad someone is bringing the power to the people. But in reality Omega is merely one of thousands of mobile-first implementations on the web. It's not unique, just like AdaptiveTheme is not unique, just like my various mobile-first custom themes are not unique, etc.

The reality is that Drupal 7's theme layer was not engineered to handle the kind of flexibility we're discussing. Per JohnAlbin's OP it would be more fun to talk about pie-in-the-sky-style ripping the guts out of Drupal and rebuilding them correctly. Taking any existing theme that was built around "desktop Drupal" and putting it in core would make things worse in the long run IMO.

Didn't intend to imply Omega

banghouse's picture

Didn't intend to imply Omega invented this approach or imply exclusivity. I was just saying the approach implemented by Omega is working for me and I think it makes sense in some form for the future. Whether that means Omega or no Omega idk.

Omega

RobLoach's picture

Similar to how some of the ideas behind Zen were pushed into Drupal 6/7 core, I would love to see more of Omega's concepts be pushed upstream into Drupal 8 core. Configurable regions, contextual theme settings, toggle-able templates/styles, etc.

It's true that Omega didn't invent mobile-first, but Omega was the first Drupal theme to employ it, and employ it well.

I think it's a great idea,

MrMaksimize's picture

I think it's a great idea, but from a usability standpoint, I think that would even further confuse casual / first-time users. I would love to see an omega-based admin theme though...

Just my $.02

Some thoughts

Crell's picture

1) Thinner markup. This helps everyone.

2) Responsive by default. This helps everyone except print designers who think they know the web.

3) Eliminate all hover-events. Those do not exist on touchscreen devices. They're also not very accessible. They also suck in general as a UI model. I blame Apple and Mac OS Classic menus for this abomination.

4) Think through where swipe-events would make sense in the UI.

5) More people need to work on http://groups.drupal.org/wscci so that we can be services-enabled by default. :-)

6) Less reliance on Render arrays. Really, using them for anything but HTML output is a pipe dream, IMO.

7) Refactor all, all logic in Drupal to be commands fired by a UI of some kind, rather than something coupled to the UI. If you cannot rip out every single form in Drupal and do absolutely all configuration via Drush, then you have a critical bug. (Because if you can do it via Drush, you can do it via web services.) Hold very very firm to this concept. The Drupal UI should be an architectural after-thought to the underlying code. It should be developed almost independently from it.

8) Figure out a way to automate pushing tiny images into data-uris, especially those in CSS. It's a PITA to do manually, but the reduced HTTP traffic can help devices on WAN networks. (Content images, it's not worth it IMO.)

I had more to say in Drupal Watchdog #2, if that ever comes out... ;-)

The Context API (part of WSCCI) should be able to support device detection through WURFL or similar, but I am reluctant to put that in core. It's probably a contrib solution.

I'd love to see jQuery Mobile

moshe weitzman's picture

I'd love to see jQuery Mobile in core. I know that responsive is awesome, and works well for a lot of sites. At the same time, JQM works better for other sites. This is one place I think we really should choose 'both'. I saw a demo of the http://drupal.org/project/mobile_jquery theme and its companion module and it gave a very nice admin experience on D7. Not saying that /admin should be a focus for JQM, but I'd like to see us ship with one install profile (see snowman project) that features JQM.

The problem with jQuery

LewisNyman's picture

The problem with jQuery Mobile, good though it is, is that it is an absolute monster to download. When building mobile sites I try and keep the total page weight below 40kb. jQuery mobile js + it's CSS + jQuery itself totals around 62kb! We haven't even loaded any content or our own styling yet.

Let's also bear in mind that some older mobile browsers struggle just to parse complex JS files like jQuery... you end up with a very mobile unfriendly solution.

Hesitant to put jQuery Mobile in core

rupl's picture

Properly executed, responsive works for all sites, instead of JS-performant (supporting JS is not enough, it must run fast to be usable). jQuery Mobile may have a few more man-hours behind, but that doesn't mean responsive techniques won't catch up. jQM brands itself as "Touch-Optimized Web Framework for Smartphones & Tablets" — do we want to set the gate that high? I'd like to continue using Drupal to serve all types of devices, not just first-world. Here is the jQuery Mobile supported browser list. Notice how quickly the list shortens as you move on from A-grade browsers.

I think a jQM in core conversation will go very similar to the Modernizr-in-D8 discussion a while back. Basically, we don't yet have a compelling reason to marry ourselves to a single solution, and core would be better served by providing a pluggable architecture that allows people to easily use any framework they want to implement. I realize we already include jQuery proper in core, so it seems like an easy extension. I just don't see a reason to force it upon all Drupal use cases.

Totally agree

crashtest_'s picture

I have looked at the pros and cons of JQM in the past and I don't see a compelling reason to include that in core. I think that making core lighter, and more responsive serves much of the same purpose at less weight. JQM may be impressive in newer smartphones but on my old G1 it drags, and isn't so quick on my Cliq.

I believe the direction we should take is cleaner and lighter and responsive to as many devices as possible, not tailored to mobile, but open to mobile.

I just don't see a reason to

moshe weitzman's picture

I just don't see a reason to force it upon all Drupal use cases.

I agree. Perhaps you are reacting to the idea of Seven being done with jQM. OK, perhaps Seven isn't a good choice. Still, core needs to be a shining example in my mind and a profile or theme that shows of jQM is core worthy, IMO. jQM development is very very fast, and thats factor for many projects.

Just my opinion

rupl's picture

Not reacting to anything in particular (I wasn't aware of jQM Seven). I'm just trying to consider the diverse set of developers that may want to use Drupal, and don't think that all of them will need jQM. If anything made me more cautious of core inclusion, it was the Modernizr discussion. I started out very gung-ho and quickly realized that my needs are not the needs of everyone. Don't get me wrong, I like jQuery Mobile. I've used it and think it's a fantastic tool. I just don't think it's a universal enough need for core.

However, I strongly agree that we need several rock-solid mobile implementations that are easily available for people to use or fork, be they profiles or themes. Not only would it improve Drupal's product-ness, but also reduces error and provides guidance as more people jump on the bandwagon.

Proudly Found Elsewhere

RobLoach's picture

If there are issues that we have with jQuery Mobile, or any other outside solution we consider, then we should work with those teams to make the system work for us. Not Invented Here is a huge problem in Drupal core, and we should work with third party open source communities and adopt something that works not just Drupal core, but other systems around us. Building a home grown solution is a viable option, but it would be better to adapt an open source system and push things upstream.

One good example of this, is how we got parts of Symfony2 in Drupal core, instead of (once again) inventing our own HTTP request handler.

Agreed

rupl's picture

I actually talked to Moshe about this at BADCamp, and after hearing him frame it in the context of "Standard" vs "Minimal" install profiles I am definitely seeing a home for it. I was just concerned that the library would be unconditionally enabled for every single user (like jQuery proper), which I felt was a little too much to assume.

I never wished to re-write jQuery Mobile. Yikes! However, I still think that a proper responsive interface scales to more devices, and must be part of our strategy.

Context on the Device, not the Server

rupl's picture

Most of these technologies rely on the front-end having device context. While this can be stored on both server and client-side, I am strongly in favor of keeping these settings within the client. It's more robust to directly detect features on each device rather than make guesses on the server. It leads to more reliable UIs, and in many cases lighter page weight. Additionally, setting device context on via cookies on the server makes it harder to use other components of the web stack, especially pieces like Varnish that are so important to higher traffic websites.

Not mutually exclusive

batsonjay's picture

Aren't there really are two "context" points?

  • There's the "context" that defines what information Drupal has when it receives a request that did NOT come from the client, which it must use to decide how to handle / process this request. (Larry Garfield can probably cite a better example here than I can). One example, though, is that we can't assume the client isn't trying to send context to spoof Drupal into providing something it shouldn't be able to do. E.g. you can't let the context / cookie on a client control legal right to access content; the server may need to enforce restrictions - this is part of context.
  • There's the context the client wants to use in order to get the correct content/service from Drupal. E.g. a cookie specifying my preferred language.

Both need to exist.

Pardon the confusion

rupl's picture

Pardon the confusion. Yes, my post needs clarification :)

I am referring to front-end context, which is yet a third point in the stack. The WSCCI type of context will obviously be session-driven, to provide the architecture necessary to allow secure form submissions and so forth. Absolutely. Regarding language cookies, I'm not sure, but at the moment my gut says it falls into the category I'm about to describe.

I'm referring to the mechanism by which we supply public-facing markup and so forth. In other discussions, the idea has been mentioned that once we discover what type of device is connecting to Drupal, we cache that data server-side to provide front-end context, which allows for different markup or content based on this cached information. I am only opposed to a server-side mechanism for caching visible parts of Drupal's output — that is, something you don't have to "view source" to experience.

I think we could just as easily cache this context client-side and rely on direct feature detection as the device requests content and CSS/JS. Plus, it provides the benefit of being more nimble when client-side context changes. Examples would be screen size via orientation changes, loss of or changes in bandwidth availability, or client-side adjustments to phone API, such as (dis)allowing Geolocation API in browser.

While we will clearly need to manage sessions for the same reason we've always done it, I would rather not bake in the dependence on server-side caching of front-end context, be it UA sniffing or feature detection. It will surely provide the incorrect experience at times, which we can all agree would be bad. It also can't scale as easily as client-side mechanisms, since all possible combinations would have to be known, with one chosen on each page load. It also blocks the use of reverse proxy caching, which is important for enterprise Drupal.

By offloading front-end context to the client, we'd be receiving the correct content every time, saving bandwidth and improving the speed of page loads at multiple points in the stack.

light and open

jpamental's picture

I think that the best comments are those focused on light-weight output from core, leaving the decisions about presentation (responsive or not, mobile-specific JQM or JQTouch) for the theming layer. Core output of content should be (IMO) just that: core to the content itself, without making assumptions about how the content will be presented.

That said - I do firmly believe that a responsive design approach is right/appropriate more often than not - but I don't think that should (or even needs to) extend further up the source tree than the theme.

Jason

Jason Pamental
[ @jpamental ]

one more...

jpamental's picture

I do want to add that Moshe's comment about making the admin experience better is pretty important - though here again I think that a good responsive theme lets the final decision about presentation get made on the client device based on its capabilities rather than pushing out a device-specific response. Designing for capabilities being far better/more reliable than designing for specific device(s).

Jason Pamental
[ @jpamental ]

mowgli's picture

I am just brainstorming ideas here ...

Why not build some sort of device detection in D8's core?!

Currently, mobile solutions are being served by various mobile modules: Mobile Tools, WURFL, Mobile Plugin, Mobile Services, jQuery Mobile, Simple Mobile Redirect, MobileKey, etc ...

At the heart of all these modules is a device detection mechanism.

With device detection built in D8's core, some sort of API function call can be made available to themers who can then manipulate it to set their CSS media queries or preprocess/process or load conditional stylesheets, or whatever ... This device detection in core should be configurable and be turned off at will.

Talking about conditional stylesheets, why do we have to download a separate module for loading conditional stylesheets? (Some base themes have it built in, but I don't think it belongs in themes). Loading conditional stylesheets should also be built-in (don't know exactly where, maybe in the theming subsystem), and themers should only just invoke it in the .info file or even call it dynamically and conditionally in template.php ... again I'm just brainstorming.

I completely agree with the comments that the Responsive video module ( http://drupal.org/project/fitvids ) and Responsive images module ( http://drupal.org/node/1289692 ) should be optimized and integrated in D8 core.

And while there is an HTML5 initiative for D8, why not explore HTML5 Video to see if it can natively support or made to support responsive video ...

And while I am in a brainstorming binge, why not explore a theme function that can detect screen size (in combination with device detection) and then allow the themers to have fine-grained control on theming any region, element, just about anything in theme ... Something like SASS, Mixin and media queries combined but with more mobile programming power ... ok, I better stop before it gets out of hand :)

If there is an overall message I want to convey is that these mobile features should be confined to the theme layer level as much as possible. Just make it easier for the themers to theme in a responsive web design principles.

I leave it to the Drupal gods to figure out the feasibility of all of this :)

Now vs the Future

rupl's picture

We need to think long and hard before conceding to device detection on the server-side. It seems like an easy way to wrangle Drupal, but it is also the old way of thinking. I unfortunately cannot expound at the moment (clients, sheesh), but server-side detection is not the most robust, future-friendly approach. Server-side simply cannot scale with the untold number of devices that will continue to start consuming the web.

I believe we will reap more rewards by moving away from nosey servers and relying on the intelligence of each device. We need to build one web!

How would we maintain this

LewisNyman's picture

How would we maintain this list of devices in Drupal core? Would we have to release an update to Drupal every time a new device came out?

I'm hoping we can bring device agnostic feature detection to the server side instead. It is possible to do this with Modernizr.

Context on the Device

rupl's picture

Caching device context on the server doesn't scale quite as well as caching it on the device itself.

Storing cookies and serving different markup based on any server-side mechanism — be it UA sniffing or feature detection — causes weird caching problems. What happens if a desktop user views page and causes it to cache, then a mobile user hits the cached page?

Sometimes context changes per page load. People view a few pages on their tablet, then rotate it arbitrarily. Maybe a landing page or dashboard looked better in landscape, then a single article looked better portrait.

Check Crell's link out ( http://groups.drupal.org/wscci ) we'll have the ability to request any piece of Drupal content without the baggage of the page wrapper. Need these three blocks for mobile? Great. Need two extra for desktop? You got it. My point is, other Drupal initiatives are working toward a greater goal and the front-end must evolve to keep up with the back-end stack.

These are the primary reasons causing me to believe that we should not store device context on the server in core. If contrib modules want that, great. But to be a first-class mobile platform, I don't think it should be a core behavior baked into Drupal. Making contrib do it would be cake, as it already exists.

Modernizr is the way to

Must be possible to preview during content creation

batsonjay's picture

Whatever mechanism gets settled on, Drupal really needs to be able to let content creators preview the resulting page as it would appear on devices.

I'm presuming this is a hairy problem. It would seem to involve a couple of things:

  • Node edit needs to know about the various forms a page might be delivered in, and provide the appropriate preview
  • If those pages use different, alternate layouts, those (of course) need to be reflected
  • Providing useful options to take if the editor thinks the layout sucks

It's a bigger question than just this group, but is it worth having a discussion somewhere that says the content editor experience should be separate from the "overall admin" experience? E.g. a different interface altogether?

Content editor experience

JohnAlbin's picture

The “content editor experience” is something that the Workbench project is working on in D7 contrib. The flexible workflow in that project is excellent, even though they are just starting work on improving the UX.

I'm intrigued by the idea of a “different interface altogether”. Certainly there are two different sets of admin screens: those used during the initial build out (and that should be rarely used later) and those used to create and administer content.

But getting back to your first question about previewing the resulting page…

When we built out the new Palantir.net website, we used a responsive design implemented mostly through Panels layouts (or CTools Page Manager layouts, if you will). Since the actual front-end layouts' CSS is being included during the preview, a desktop browser could be resized in order to simulate varying sized devices. That worked when node types always had the same layout.

Certainly, we'll need to start thinking about how to deal with content types that can have per-node configurable layouts. Phase 4: Layouts of the web services initiative will probably need that.

  - John (JohnAlbin)

We should look at getting a

calte's picture

We should look at getting a tool like http://responsive.is integrated for content editing preview. Lots has happened on this point since last October :)

Screen size is only one device feature

rupl's picture

That's a great high-level preview (and it's very neat to use), but unfortunately that tool only considers screen size when rendering output. Nothing has changed since October.

It is impossible to emulate the spectrum of device capabilities within a particular browser. For instance, if someone wants to enable different JavaScript for touch devices, that tool will not allow proper emulation in a desktop browser. Consider the unique CSS3 capabilities of the browser you're using. Previewing in Chrome will differ from the preview in IE. These are just a few easy examples.

Again, I think multi-screen preview would be a great start, but I want to caution people from assuming that squishing your window is a solid solution to mobile testing. You simply cannot use a browser to emulate device experiences reliably.

Absolutely, depending on the

calte's picture

Absolutely, depending on the implementation of the media queries using a tool like this will at least get us as close as possible to device emulation.

I didn't intend to suggest that this would emulate the device experience.

We could (potentially) move

calte's picture

We could (potentially) move one-step closer to device emulation by using modernizr for local device detection and then offering node-preview a false positive.

/edit fixed typo

Do we need to be able to 'preview'

jpamental's picture

I agree with @rupl - we'll never be able to do this accurately, and I honestly think we're trying to devise a solution for a problem that's not really there. I think in many if not most cases, there won't be much in the content someone is editing to make it really necessary to preview. The theme should be sorting out size and scale for most content. I think just making the admin interface itself responsive is a big step forward. Trying to solve 'preview' for every device capability just seems like we're over-reaching.

Jason Pamental
[ @jpamental ]

Preview issue

yoroy's picture

The not-mobile specific issue towards real content previes in core: http://drupal.org/node/1510544

That's legitimate; this might

calte's picture

That's legitimate; this might be contrib territory. Thanks for thinking about it.

of course I should add...

jpamental's picture

...that Modernizr now lets you detect if 'touch' is present in the browser, so you can do things like control the type of interaction presented (I only show navigation with no drop-downs for touch devices and will sometimes show an additional 'quick links' type of menu differently for touch than for desktop browsers). I could see that being a valuable thing to work into our admin interaction design.

Jason Pamental
[ @jpamental ]

The Drupal Way

mowgli's picture

I am back in brainstorming mode :) .

Let me rephrase the problem space in concrete terms. Let me give a concrete example encountered when theming for mobility.

Responsive web design is great in that it allows for the scaling and rearranging of the UI elements according to the media, and for that, there are css media queries, html5, css3, sass, fitvids, modernizr, jqm, etc... to help scale, rearrange and theme.
As nice as responsive web design is with the above nice technologies, it still can NOT allow a themer to ADD or REMOVE a Drupal's region, a Drupal's block or any Drupal-specific element from the final output.

Suppose a themer wants to ADD a Drupal's BLOCK when the site is on a wide desktop screen (e.g. a nice decorative image in a block, in a region), but wants to REMOVE that block when the site is in a smartphone. Unless I miss something, I don't think Modernizr, JQM, css media queries, html5, css3, sass, fitvids can do that. And I don't think we can rely on the "intelligence" of the devices to do that either. These technologies lack the Drupal "programming" power; they are still Javascript and CSS based for presentation. They can NOT handle Drupal-specific problem spaces. Note the emphasis is on Drupal-specific.

That's why, in my earlier comment, I allude to programmable and themable MOBILE API to do it the Drupal way. These mobile features should preferably lie in the theming layer. With such a mobile API, the themer can do things like check for screen size and then display or hide a specific Drupal block.

For example, "Show block on specific pages" --> "Pages on which this PHP code returns TRUE (experts only)" --> Use a mobile API function to check the screen size is greater than or equal to 960px and return TRUE.

Responsive web design the Drupal way!

Client-driven interfaces

batsonjay's picture

At some level, it seems like what you want Drupal to deliver to any browser (desktop, mobile) is HTML structure (DIVs) that contains code that's executed in the browser to actually build the page - i.e. have JS fetch the contents of any DIV via a web service content query (e.g. via the contentapi). JS (or equivalent) can say "I'm on a device less than Xpx wide, so I'm not going to fetch the content in the block I would otherwise fetch. And the theme can take care of the structural layout of regions based on the device.

In essence, push as much "construction" as you can to the client, and let the code on the client decide what it wants to display, where, and even get that content after the "page" has been loaded by the client.

I think I have to respectfully disagree...

jpamental's picture

I think that in keeping with the notion of 'one web' it's better to output the content in a nice clean semantic manner (either as HTML or some other structured output) and then (if HTML) my own preference is a responsive approach that lets the design control how the 'page' reacts to different viewport sizes and device capabilities. That way we don't get in the habit of making assumptions about what a 'mobile user' wants or a 'desktop user' needs. It's already so robust in this sense that it seems dangerous to move into a page of containers that requires JS to get content (or in the case of the my.fcc.gov site - it seems an entirely different way of serving the page). If we're designing from the content out in a meaningful way (and adding in responsive images - that we still need the JS for) a responsive theme will address the broadest needs. If we want to use jQTouch or jQM or some other framework to do a dedicated mobile solution, great - but use the Boston Globe site as and example: all the content is still accessible on any device, but interaction with it and format is entirely appropriate on the device with which you're browsing.

I know there will always be cases for other approaches, but for core it seems that we should be taking the most slimmed down and normalized approach that will serve the broadest spectrum of needs, and then build out to handle edge cases from there. If we could simply get clean, slim markup that would let us do all the fancy we want building up from there.

OK - that was probably 2.5 cents.

Cheers guys - and thanks John for kicking off such a great discussion!

Jason

Jason Pamental
[ @jpamental ]

You're actually agreeing

rupl's picture

Jay is spot on. This will happen in the future and it's actually the next step of abstraction past the model you have described!

Responsive as we know it is basically contextual CSS/JS. Drupal will provide contextual content as well. Here's an excellent presentation from DIWD last week that spells it out better than I can: http://globalmoxie.com/jhc/prez/mobile-context-myth.pdf

Basically this presentation says:

  1. Make an API (WSCCI)
  2. Leave front-end context on devices

actually...

jpamental's picture

Josh was talking about the 'one web' idea of just what I described! (I was fortunate enough to be there giving a couple of presentations) The thing I'm getting at (and Josh too) is that we need to not make assumptions about what a user (mobile or stationary) will want - just deliver the content in a way that will display appropriately. Letting the device do it's thing for presentation, but not limiting or altering the content delivered based on choices we make (as designers/developers). Technologies like HTML5 local storage and web sql let everything be more 'app like', and of course we can go further with things like JQM or jQT, still coming back to the same content, cleanly output. (I guess what I'm getting it is that the device is determining how things display, not what is delivered to the device itself other than size-appropriate media assets)

This would be way more fun as a bar discussion - but that may be the 2hrs sleep talking ;)

Cheers-

Jason

(actually the basis for the web types talks I gave at DC London and DIWD originated in a bar at 2am with a bunch of core devs at DC Chicago. I sense a trend)

Jason Pamental
[ @jpamental ]

Spot on

RainbowArray's picture

I completely agree with this. Making decisions of what HTML you will output based on server-side detection just isn't the best way to go. The moment you think, "Nobody will need this bit of content on a mobile device, since they will be out and about!" is the moment somebody says "I would like to look at this site on my couch with my nice speedy wi-fi... hey, wait, why can't I view the content I wanted to see?"

the best bit from Josh's talk...

jpamental's picture

was about '40% of people admit to using their smartphone while on the toilet.... meaning that 60% of us are liars' :)

Never know where you'll need full-site content on a small(er) screen!

Jason Pamental
[ @jpamental ]

Heh

RainbowArray's picture

I thought of using that example, too... ;)

It goes beyond serving

LewisNyman's picture

It goes beyond serving completely different content a on a mobile device. For the record I am against that approach.

Server side capability detection is our path towards responsive images, which is serving different content depending on device capability. Screen size is just one capability here, resolution is another important variable that would be excellent to automate in Image Styles. iOS developers currently have to make two sets of images for 3gs and 4.

Different input methods require different interactions and instructions, a great example are the instructions in the Google URL shortener.

Another obvious mark up change would be tables. Being able to switch to a different theming function based on screen size is a real solution. Hacking away at tds in CSS is not.

Let's not forget CSS and JS assets. We shouldn't be loading any assets that are not needed on a device.

Trying to avoid dumping onto the clientside

macjules's picture

I do agree with the 'one web' notion and for my penny's worth it would be just great to keep away from the, "OMG lets just do it all with JQuery/JQM!" Quite how one would do this level of progressive enhancement in images will be the challenge. My initial ideas were that this would be some system combining ScientiaMobile API and ImageStyles - could there be a server-side mobile device detection using the WURFL Database API which then selects the most appropriate optimisation level in Imagestyle to serve up the image and/or content?

my $0.2

jerryitt's picture

I have being using the omega theme for well over a year now and has a lot of the features being discussed here.

I currently use it along with omega tools, delta and context which allow me to display a block in any region on any screen size (e.g. wide, narrow, mobile etc) It also allows me to disable groups of and individual regions and zones in any layout (mobile for example).

http://drupal.org/project/omega

Remember theme settings?

mowgli's picture

Remember there was a time when theme settings did NOT exist in Drupal ? In the Drupal 5 days, there was no theme settings; themers had to go through ad hoc programming hoops to customize their themes.

Then some people came along with a "theme settings MODULE" for Drupal 5, promoted it to the core team, and then that module evolved into a UNIFIED theme settings API as we know it today in Drupal 6 - 7. Themers now have a common Drupal way of creating their own theme settings.

I would like to see the same thing happen to THE "Drupal Mobile API". Some modules exist for some themes to do things like checking screen size and display/hide blocks, but these are just simplistic examples.

I would like to see a COMPREHENSIVE list of mobile features ABSTRACTED out into a mobile API, which can then be used by ANY themes.

Indeed, what we need api

LewisNyman's picture

Indeed, what we need api available to themes and modules to allow them to make decisions based on device capabilities.

This was initially discussed in the original thread for responsive images. Off the back of that I started a sandbox for a Device Context API module. My lack of coding abilities has really slowed this down, if anyone wants to jump on board to help me out that would be golden.

The Add Modernizr to core discussion is still open and a lot of work has been going on in the issue queue the Modernizr module to whip it into shape.

Caching Caching Caching

Cellar Door's picture

I'll throw my hat in and say it's great to see not only mobility but responsive design becoming a more formal push in Drupal. We need to be able to adapt to future technologies now in order to make D8 relevant when it launches. Responsive is the only way to do this.

On the backend side I think the ability to handle the images/videos as discussed would be great. This has to make it into core in order for mobile to thrive on the system.

The device based context is difficult because at render the site is unaware of the device, unless there was a render for various standard sizes that was cached and ready for the devices to pick through based on the media query. I'm just spitballing here but more optimization of the experience in terms of speed is going to be critical. In the field users will want to be able to access and create content quickly.

Mainly I see a re-write to caching of css and js based off the various pre-configured device sizes and better caching of media the main 2 setbacks in core for theming mobile (read responsive) on Drupal currently. Many of the other niceties can be handled in the theming and through contrib modules. We don't want to bloat core's mobile too much but provide the basics needed to build mobile optimized sites.

RESS: Responsive Design and Server Side components

lloydk's picture

Here are some links to articles and slideshows about RESS (Responsive Design + Server Side components) that may be useful to this discussion:

RESS: Responsive Design + Server Side Components
Adaptation: Why responsive design actually begins on the server
Pragmatic responsive design

A couple of thoughts...

Graeme Blackwood's picture

I guess designing adapatively is essentially about accessibility.

If we gradually disable the features of a desktop browser, e.g. JS, CSS, images, you would eventually be left with pure markup. If a user is blind and using a screen reader, they don't need images, so why send them from the server? Likewise if a device doesn't support a certain feature, there is no need to send a page containing it. How far back do we roll? Is it really mobile first, or actually content first?

Certain feature detection happening at a server level makes a lot of sense to me.

On responsive design, the more I try and work the same output to fit different devices, the more I feel it just doesn't cut it in many situations. The basic content at a Drupal level will always be the same, and in the same way you have translations or imagecached thumbnails stored on the server being sent out in different user or page contexts, this approach is logical for device contexts.

Even at a most basic level you have issues with media queries not being supported – server side feature detection makes it possible to serve a different theme or sub-theme, which in turn can be responsive within certain parameters.

The way I see it is:

  • Primary top level / base theme – Server level
  • Feature / resolution informed contextual sub themes, adjusting markup as needed – Server level
  • Responsiveness to adjust the presentation minimally to different screen sizes and basic features – Client level

At each stage, this keeps things as lightweight as possible.

Luke W and server-side support

Crell's picture

Interesting and timely article on the subject: http://www.lukew.com/ff/entry.asp?1436

Great Article

dOwen's picture

Thanks

Spot on

batsonjay's picture

eom

exactly it

jpamental's picture

Great write-up, and pretty much in line with what I've been doing for sites at Schoolyard (without the server-side optimization, because I'm not quite that clever yet). Ethan mentions the mobile-first approach midway through the book but Luke explains it much more thoroughly.

Cheers-

Jason

Jason Pamental
[ @jpamental ]

...

markabur's picture

That lukew article makes me wonder about using view modes for different mobile contexts. E.g. the "max-width-480" view mode for a block is where you'd specify the low-res image preset, maybe switch to a more abbreviated teaser format, etc..

What about hardware features? Is there anything core could provide to support location-awareness?

Why do it with Views?

macjules's picture

Surely this could be handled faster and better using a Context extension for the WURFL module along the lines of "if screen = x then deliver y blocks".

As I said earlier, something like an update on the WURFL system, as a mobile identifier, plus clever use of Imagestyles and Context would appear to be the way to do this while remaining within Drupal's framework.

A lot of people seem to

LewisNyman's picture

A lot of people seem to forget that WURFL is not free for commercial use. Putting something like WURFL into Drupal core requires every company using Drupal to obtain a license from scientia.

It's also not really a

Graeme Blackwood's picture

It's also not really a future-friendly approach – the field of play is only going to get more diverse and querying for every device imaginable isn't really sustainable imho. More generic feature detection makes better sense to me.

Well worth a read on responsive images

Graeme Blackwood's picture

Jeremy Keith's post last Wednesday is pretty up to the minute on thinking: http://adactio.com/journal/4997/

very worth it - perhaps we need...

jpamental's picture

Perhaps we need a DNS-like service that an Apache module could query to find out device parameters based on user agent. Ultimately it's the device not the browser string that's important though - and truly it's the actual capabilities of that device that is most important. We don't have to care that it's an Android or iOS device - we just want to know if it can supply location information, or screen resolution, or whatever. Seems like Media Queries allow us to react passively within our markup, but to be proactive in what we serve for an image we need more, and for best performance in what actually gets out to the browser it should be some sort of server-level technology. But I'm guessing that Apache (or IIS or Tomcat or...) is the more appropriate place to make a determination and supply the right information accordingly.

Just some Monday thoughts.

Jason

Jason Pamental
[ @jpamental ]

Yep, I think Modernizr can

Graeme Blackwood's picture

Yep, I think Modernizr can handle the detection effectively and then feed back to the server for conditional content loading though? Seems like the most acceptable solution we have so far.

This is also worth noting: https://github.com/Modernizr/Modernizr/wiki/Undetectables

Theme development

Group organizers

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: