Half-Elf on Tech

Thoughts From a Professional Lesbian

Tag: mobile

  • How Mobile is AMP?

    How Mobile is AMP?

    There are pros and cons of using AMP, the biggest being Alex Kras’ discovery that Google is kinda stealing your mobile traffic with AMP. But since WPBeginner lays out the pros and cons really well, I’m going to skip over that and discuss something else.

    Responsive Themes

    The concept of a ‘mobile only’ theme is one I generally deride. After all, if you’re on a website in 2017, it should have been written with the concept of mobile first. Most people design a site for their computer/browser of choice, and then add in resizes for mobile. Contrasting this is the idea that you build out your website for mobile browsers first, and then go back in and add in the larger views. That is Mobile First.

    It’s an ideal, I agree, and while I love it (and Carrie Dils who made the beautiful Utility Pro Theme as a mobile first them), it can’t always be achieved. Some websites are written to be ‘apps’ and they’re intended to be used as a browser app.

    In general, I support the use of a responsive theme, be it mobile first or not. This kind of theme will react based on browser size, or operating system type. But a mobile ‘only’ theme? I dislike them a great deal. They create headaches with caching (ask anyone who’s had their cache catch the mobile page for everyone!) and they can be difficult to jump back from, if someone is perhaps on a tablet that can handle the ‘full’ site. They also double your work.

    AMP

    AMP is a project by Google. The concept is a super light, ultra-fast mobile page for your sites. AMP is fast, it’s simple, and it’s a stripped down version of your normal site. How it works is that When Google searches your site and adds it to their big giant database, they can can see “Aha, this site has AMP! I will use it for mobile!” And then, when someone surfs to your site via a Google search, Google would notice “This user is on mobile! I will show it AMP displays!”

    The downside you might have noticed is that the AMP pages only get called when you’re doing a Google search. That means if you go to a website on your phone, you get the mobile responsive site anyway. Which is what Paul (and I) think you should be doing. And right away, you might think “Hey, I should make all my mobile visitors go to AMP!” and you may come up with code like this:

    function amp_redirect() {
	if ( wp_is_mobile() ) {
		$url = trim(  $_SERVER['REQUEST_URI'], '/' );
		if ( substr( $url, -3) != 'amp' ) {
			$url = $_SERVER['REQUEST_URI'] . '/?amp';
			wp_redirect( $url );
			exit;
		}
	}
}

    That looks great, doesn’t it? It’s smart enough to check if the URL ends in ‘amp’ and, if so, not redirect. Plus it uses ?amp which means if the page doesn’t have an AMP URL, it won’t fail an ugly 404 death.

    There is, however, a big problem with AMP. You end up having two sites. Paul Bakaus talks about the pitfalls of a separate mobile site, and how you should keep a responsive theme for your site, and not use AMP for Mobile. This is not a good thing in the long run.

    A RESTful Alternative

    So let’s think about this differently and not in the simple “Mobile vs Non-Mobile” way. Let’s ask ourselves the real questions. “What is this site doing?” and “How will people be using this site?” Because the crux of the matter is really how is the data from the site being consumed!

    Recently, with the advent of the REST API, WordPress has as new way for people to eat your data. Much like I’ve talked about before, using the REST API to power an Alexa app or a plugin, the REST API can be used to power mobile apps! Yes, people are running iOS apps with the REST API. This lets you display the content however you want, even audio only, and yet power it fully with WordPress.

    In a way, you’re still making two sites, the app and the theme, but… You’re not making a generic theme that fits all users. You’re making a real application that fits the specific use case.

    What’s The Answer?

    Let’s break this down.

    1) Your theme should be responsive for mobile. Period.
    2) AMP is great for Google searches.
    3) The REST API can, and should power your apps.

    That’s it. Three steps to amplifying your site.

    Oh, and please don’t use that code I showed you. It’s sad.

  • AMP It Up

    AMP It Up

    We’ve all heard about how Google wants to make mobile pages faster. The Accelerated Mobile Pages (AMP) Project is there to deliver and process a pared down version of a webpage, prioritizing speed. Since speed is important to your SEO, and I’m on a bit of an SEO kick, you bet it was next on my to-do list.

    I admit, Joost talked about this at his WordCamp US talk this year, and among my notes was this:

    Add AMP – not set it and forget it

    This is so, so true.

    The AMP Plugin

    First its like all things WordPress, you install the plugin AMP by Automattic and activate it. That does the easy work. Of course then you have to customize the hell out of it to make it look right. Still, out of the box the plugin adds a /amp/ so if you go to https://halfelf.org/2016/amp-it-up/amp/ then you’ll see my AMPlified pages. If you’re using Multisite, you may need to re-save your permalinks for the URL to work.

    There are some big warnings about this though.

    1) No analytics tracking
    2) You don’t get to design your AMP page
    3) It doesn’t work on the front page or pages or cpts

    Don’t worry! We can fix all that!

    Analytics

    If you’re using Monster Insights for Analytics, supposedly they added in some code to make tracking work, but I was unable to find it in the code or documentation. More than likely it’s in their Pro version. I don’t use that plugin simply because I found it easier to use a 28 line mu-plugin for my network and I don’t need to see my stats all the time. I used the AMP WP recommended method and put it in the same mu-plugin as I have my regular analytics.

    Design

    This is a little messy. Design is a very complicated word. If you just want to change the colors, you can do this via Appearance > AMP. Whaaaat!? That’s right, it lets you change the header color and font color right there. Super simple. If, though, you want to make your CSS tweaks directly to change that light blue header to navy, perhaps, you can follow the AMP WP directions for CSS additions and have this:

    add_action( 'amp_post_template_css', 'halfelf_amp_css' );
function halfelf_amp_css( $amp_template ) { 
	?>
	.amp-wp-header {
		background-color: #013659;
	}
    <?php
}

    I strongly recommend making few changes. Oh, color of course, but don’t go and make a 1 meg CSS file. The point of AMP is to load faster, after all!

    There’s a whole second level of design that I’ll get into later. It needs its own post.

    AMP your CPTS

    Right now you can only do it via code. The AMP WP directions for CPTs state they may come up with a better way, but for now you do this:

    add_action( 'amp_init', 'my_amp_add_this_cpt' );
function my_amp_add_chars_cpt() {
    add_post_type_support( 'post_type_this', AMP_QUERY_VAR );
}

    It’s pretty direct, and I added this in the bottom of my existing CPT code.

  • Mobile Ad Detection

    Mobile Ad Detection

    I screwed up not that long ago.

    I got an email from Google Adsense telling me that one of my sites was in violation because it was showing two ads on the same mobile screen, which is not allowed. Until I started using some of Googles whole page on mobile ads (an experiment), this was never an issue. Now it was. Now I had to fix it.

    Thankfully I knew the simpliest answer would be to detect if a page was mobile and not display the ads. Among other things, I know that I hate too many ads on mobile. So all I wanted was to use the Google page level ads – one ad for the mobile page, easily dismissible. Therefore it would be best if I hide all but two other ads. One isn’t really an ad as much as an affiliate box, and one Google responsive ad.

    For my mobile detector, I went with MobileDetect, which is a lightweight PHP class. I picked it because I was already using PHP to determine what ads showed based on shortcodes so it was a logical choice.

    Now the way my simple code works is you can use a WordPress shortcode like [showads name="google-responsive"] and that calls a file, passing a parameter for name into the file to generate the ad via a mess of switches and sanitation. Really you can go to http://example.com/myads.php?name=leaderboard and it would show you the ad.

    The bare bones of the code looks like this:

    <?php

require_once 'Mobile_Detect.php';
$detect = new Mobile_Detect;

$thisad = trim(strip_tags($_GET["name"]));
$mobileads = array('google-responsive', 'affiliate-ad');

// If it's mobile AND it's not in the array, bail.
if ( $detect->isMobile() && !in_array($thisad, $mobileads) ) {
	return;
}

echo '<div class="jf-adboxes '.$thisad.'">';

switch ($thisad) {
	case "half banner":
		echo "the ad";
		break;
	case "line-buttons":
		echo "the ad";
		break;
	default:
		echo "Why are you here?";
}

echo '</div>';

    The secret sauce is that check for two things:

    1. Is the ad not one I’ve authorized for mobile?
    2. Is this mobile?

    Only if both are false will the script continue to run. It’s simple but I like to have things stop as soon as possible to make loading faster. There’s no css trickery to hide things via mobile size detection. It’s as simple, and as close to a binary check as I can make it.