Best practice for Mobile development in WordPress

[ambiguousfrog]

I’ve been thinking about this a lot, recently I’ve been using the Bones Boilerplate which contains several breakpoints in the form of media queries which normally involves overuse of display:none;

I’m reading more and more about optimisation in the form of reducing HTTP requests by limiting images, html and js and minifying both css and js files to reduce download times on 3G.

So then I was thinking about a mobile detection plugin to serve up a different template for mobile users to desktop but I guess this could also be achieved by JS.

Basically I’m just wondering what is the best practise that takes into consideration load times as well as optimal user experience. What have you found to be the best approach?

[Paulie_D]

Different template or different content?

[nixnerd]

…which normally involves overuse of display:none;

Sooooo much of this! ++

FYI though dude, you may be branded a heretic by some for feeling this way. The way I see it… everything is true until it’s not. It might be time to radically think RWD and create compelling sites that maximize the capabilities of whatever device they’re on. I kind of feel like over-reliance on media queries has led us back down the path of glorified pamphlets.

I’ve been thinking about the same thing lately and was just talking to @traq about it, AKA “Thunderscore.” We decided that the best method would probably be to query the device for it’s window size and then request the proper markup/stylesheet via AJAX. The only question either of us had was about performance and how quickly this can be done. Now, I’m going to assume people have figured out a way to do it pretty damn quick because some of the benchmarks on dynamically serving up mobile-specific markup/styles are crazy.

Different template or different content?

Paulie, I think he means both. This approach to RWD involves many things… including but not limited to tailoring content to the device. This might involve the inclusion/exclusion of photos, etc. Also… there’s some content on a site that flat-out does not even apply to mobile users. So… 5EO gurus love this approach.

I read an article with benchmarks a while ago that recommended using photos as background images to a div, then putting that div in a parent div and setting the parent to display:none. Apparently almost all browsers know not to request the photo in this scenario. But… seems like your markup suffers and becomes less semantic. Not to mention… the intellectual overhead associated with these COMPLEX styling rules seems to go WAY beyond managing two simple site versions. Just my opinion.

@traq, what say you sir? How should this gentleman proceed?

[__]

The “in WordPress” part limits your options (and also my ability to give any useful insight). So… no answer. Sorry.

The Thing What Joe Is Talkin’bout:

I haven’t actually done conditional loading of templates/ content/ etc.; but I don’t see why the idea wouldn’t work. It’s similar to the process (which I think Chris Coyier has written about) of using js to query screen size/ capabilities/ whatever and setting a cookie with the info, which the browser would then send along with subsequent requests, allowing the server to selectively serve images and other resources.

The idea would work best with a wholly js app (ajax + templating framework —I’m thinking of trying this with polymer, once I get familiar enough with it). The platform capabilities could be queried asap, and would then dictate what content + templates are used.

Anyway… if this concept goes anywhere, you can be sure I’ll share it. But it would be very, very difficult to integrate with WP, if it could be done at all.

[nixnerd]

Damn it… Sorry. I read the title and then immediately forgot we were talking about WP. Yeah dude… I just really don’t see this working with WP either for a multitude of reasons.

[Alen]

@Paulie_D dude can you elevate my privileges to super awesome so I don’t have to tag you in these :)

[Paulie_D]

@Alen

I’m just a Mod not an Admin so I can’t change anyone’s status.

Some general rules though.

Don’t type ESS EE OOH…..use 5EO.

Those three letters are a big red flag that will pretty much guarantee a auto-reaction.

Don’t post multiple links…3 is usually OK but 4 sometimes pushes the button.

[Alen]

@ambiguousfrog

Don’t rely on plugins. Build it custom and I don’t see any reasons why you wouldn’t have full control. Not everything is a “theme”. I discourage my clients from using any plugins, there’s only few I like to use. I leverage Theme Options Framework and Advanced Custom Fields with my builds and you can get pretty custom with those two. Other plugins are mostly for SEO, Caching, User Management, etc. I don’t use any plugin that uses PHP process to do the heavy lifting that can be done on my local environment before I push everything live.

I often hear response time is horrible with WordPress, well no shit. There’s about million plugins (Image optimization, minification, concatenation, etc… all running).

Don’t allow WordPress to do the work. It’s slow.

Having said all of this, if you’re building more general “theme” then make sure to follow theme building conventions.

[Senff]

Whether it’s WordPress or Drupal or whatever platform shouldn’t matter too much, as this issue is front-end related. Sure, things get slower when you load 100 WordPress plugins — but that would also be the case if it were a static site and you’d load 100 jQuery plugins. It all comes down to “not using too much X”, with X being additional whatever.

Everything in moderation and you’ll be fine.

So then I was thinking about a mobile detection plugin to serve up a different template for mobile users to desktop but I guess this could also be achieved by JS.

Doing this, you’re basically bypassing the responsive methodology and move towards adaptive; serving different markup based on screen size. If Bones uses display:none too much, you may want to check out another theme (personally, I’m a bigger fan of Underscores), or even make your own custom theme, so you can minimize the use of display everywhere, and also set all the breakpoints yourself.

(I never liked the use of “proven” breakpoints in the first place; I’ve always thought it depends on the individual design and where things “break”, which is definitely not always 640 or 960 or whatever).

Basically what I mean to say…don’t try to fix a problem with the theme with a solution in a plugin. Fix the problem on theme-level; either by changing the code in the theme, or picking a different theme altogether.

[__]

(I never liked the use of “proven” breakpoints in the first place; I’ve always thought it depends on the individual design and where things “break”, which is definitely not always 640 or 960 or whatever).

+1

[serenade76]

strongly buid theme is the best solution.

[Alen]

Some conceptual ideas/approaches you should think about, not everything is about building themes.

http://youtu.be/dfweWyVScaI

[Author]

Posts