We may have reached the age of broadband with our desktops but with bandwidth throttling and pay-per-byte mobile plans we really need to consider every pixel and every bit of code we send to our users… If we expect them to frequent our sites that is.

One popular approach to building a responsive website is to take an already designed theme, then hide each element that doesn’t look good on a mobile until a minimalist theme remains. While that technique may leave you with a decent looking site it will wreak havoc on your users’ experience.

The ideal is to plan a minimum viable product — focus on your user’s needs, design for your content — and you’ll have the perfect mobile-friendly site. Just add a few media queries and you’re good to go.

But sometimes you NEED that awesomely cool heavy animation loading on your desktop theme, but want to spare your mobile users. Or you’d like to add some extra navigation, which just doesn’t work with the mobile experience.

What do you do then?

Introducing: php-mobile-detect

Let’s say you have a WordPress theme that you’re adapting to be Responsive…

Download the php-mobile-detect script and upload it to your theme folder.

Require it in your functions.php file.

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

Then when you have to urge to apply a “Display: none;” in your stylesheet for something that is particularly heavy.

    global $detect;
    if ($detect->isMobile() && !$detect->isTablet()) {
        // code for mobile only
    } elseif ($detect->isTablet()) {
        // tablet browsers
    } else {
        // everything else
    }

Voilà!

But User Agent Sniffing is BAD?!

Browser Detection is a double edged sword. Here’s a great summary why you shouldn’t do this. But this solution, while technically IS browser detection, is more in the spirit of capability detection. We’re not singling out all iPhones and building a special theme for them, we’re finding all mobile devices that aren’t tablets and hiding/showing elements consequently. This is more akin to the media queries we so dearly love and rely upon for our responsive site.

Disagree? Please share your thoughts!

Kudos @victorstanciu for a great job on the php-mobile-detect script!

While there are a lot of articles out there, these books really cover the core issues and flesh out the concepts. In fact, many of the best articles are just chapters from these books. I’ll be sharing some of the articles as well as tools in future posts so stay tuned!

Books

Responsive Web Design – Ethan Marcotte

This is where it all began. I feel like, as a Front-end Developer, discovering Responsive Web Design is one of those paradigm shift moments that, when it happens to you, you know your life will never be the same. However much it is adopted in the future, it’s principles will surely live on through one means or another.

Adaptive Web Design – Aaron Gustafson

Another seminal book and a strong case for progressive enhancement. While it seems to only deal with the periphery of the conversation I think, in truth, it really deals the core of the issue. Responsive Web Design is about making your site accessible to as many devices as possible. Progressive Enhancement reminds us that there are devices other than the newest and coolest… If you build your site upon a solid foundation that addresses older browsers, text-only browsers and audio site browsers, it will make a better experience for ALL browsers and ALL your visitors. Isn’t that whom you’re building your site for anyways? Your visitors?

Mobile First – Luke Wroblewski

“Design is the process of gradually applying constraints until an elegant solution remains”

This book is more about an overall approach to web development. We too often forget whom we are building our sites for — our users — and we tend to get to give in to the pressures to overload our sites with features… Because we can. This leads for bad Responsive Sites. One of the biggest criticisms of Responsive Web Design is that the mobile versions tend to load too much unnecessary junk. If you overload your site with features then are forced to hide those extraneous features your mobile devices will still download the extras. But if you think Mobile First — what this book advocates — you’ll be doing yourself, and your users a favor.

I’ll be sharing some of the articles as well as tools in future posts so stay tuned!

If you missed the performance or  would like to review the slides, feel free!

Use keyboard arrows to advance from slide to slide.

Note: Ironically, while it is viewable in Chrome and Firefox with all the fun JS bling, it is best viewed in Safari. When choosing a medium to build my presentation in I wanted to use impress.js because it provides a solid fallback, hence jiving with my preaching… Unfortunately, browsers aren’t quite up to all the 3d graphic rendering they claim to be. Even the bleeding edge ones… Except for Safari. (Although Chrome seems to be best for video… especially YouTube.)

Disclaimer: I am in the process of going through my live sites to implement the concepts I spoke about in my talk. I am not walking the walk 100% yet…

I will be posting notes for the slides over the weekend, and over the next few weeks I’ll be expanding on the ideas I shared in full blogposts. If you don’t want to miss any I’ll be tweeting them as they come out.

Please comment, share your ideas. If you think I’m talking $#!T call me out on it.

Cheers!

I’ve been doing some research for my upcoming talk at WPNYC where I’ll be discussing Responsive/Adaptive Web Design. While preparing to talk about why it’s important to be inclusive with your design I checked the daily browser distribution from statcounter and noticed a very interesting pattern…

Do you see the funny blue/green fish at the top of the chart?

The blue is Internet Explorer, the green is Chrome. The blue humps are weekdays, the green and blue meet / cross over at the weekend. Basically, what (IMHO) this means is that most of the IE users use Chrome at home, when they are predominantly at home — over the weekend — they use their preferred (or kid’s preferred) browser, while at work they are forced to use what their IT team provides…

So if you’re wondering why IE is still such a strong force, ask your IT department at work.

Just some food for thought…

Whereas…

Adaptive Web Design is built on the principals of  Progressive Enhancement.

Whhahaatt?

Graceful Degradation is when you build your site for modern browsers, then find solutions to make the experience passable for people using Internet Explorer or Mobile Browsers.

Progressive Enhancement starts with a solid base, designing as for the lowest common denominator, then adding enhancements for a better experience for the more fortunate visitors.

This is a somewhat of a watered down analysis. But essentially, it’s a difference of approaches. Who is your audience? are you targeting, mostly, people who use modern browsers and you just want to make sure it just works OK elsewhere? There’s nothing wrong with Progressive Enhancement… when it’s intentional. Personally, I’m a fan of inclusive thinking.

That was what I was looking for when I decided to build my next site using bootstrap… and it did save time, initially. I decided to use the LessCSS version, I LOVE mixins, and within a couple hours I had 95% of the site styled and laid out. The Bootstrap framework is truly powerful.

Bootstrap does for UI what jQuery does for UX… Potentially.

Until you hit a bump in the road.

The CSS includes for Bootstrap are similar to jQuery in the sense that it doesn’t give you anything you couldn’t do yourself, but it gives you a LOT that you couldn’t do simply yourself. As the jQuery tagline goes: “Write Less Do More“.

Inevitably, when styling a site I come across cross-browser inconsistencies. Usually it’s a simple matter of tweaking to fix the bug. The problem with Bootstrap is that it adds so much extra CSS into the mix that finding that conflict becomes practically impossible. CSS was designed to be more forgiving than Javascript. If there is a conflict, it cascades. CSS was designed to work that way, on purpose.

But in order to work with a CSS framework the way you’d work with jQuery you’d have to know – cold – every module in the framework in order to be able to properly troubleshoot the conflicts. When something breaks in jQuery you know immediately; however with CSS, if the inconsistency is not in the browser you’re developing in you’ll only find it later and then good luck finding it.

Example: I was styling a typical list of blogpost excerpts for a category archive page – article tags surrounding a title + excerpt, etc. On the right of each article I had floating a “more” button (position: absolute; top: 1em; right: 1em; with a position relative on the article tag).

The “more” button would float perfectly in webkit browsers and in IE (even IE7) but for some reason it is ignoring the position relative on the article element in Mozilla so they all piled up on top of each other at the top of the page.

I had a a different issue with an absolute positioned input tag with IE7 that just disappeared completely from the DOM.

Normally I’d be able to find the conflict easily. Normally I KNOW every inch of CSS that I code. But with Bootstrap I wasted hours hunting down the conflict, which was buried in a completely unrelated module… Due to this volatility I had to drop Bootstrap for the project.

Back in the days of “webmasters” when WYSIWYG editors began to appear, the people making a living from coding sites were concerned that these editors would take their jobs. But the editors spat out spaghetti code, unformatted and crude. Which worked fine in the browser you were designing your site for. But once there was a cross-browser inconsistency, you needed a pro to sacrifice a day to fix it. Sadly, Bootstrap isn’t much different.

I plan to continue to use Bootstrap, but not as a full design framework, as it was designed to be; rather, as a library that I can take pieces from. The reset and mixins are a shoe-in to use. It’s not that it’s too buggy to use; more, that the nature of CSS makes frameworks difficult to implement as a full robust solution.

TLDR: Bootstrap is like WYSIWYG editors in the sense that it makes your life easier, until you have to troubleshoot a bug… Then it’s a nightmare.

Have YOU used Bootstrap? What are your thoughts?

function activatePlaceholders() {
    var detect = navigator.userAgent.toLowerCase();
    if (detect.search("msie") > 0 ) {
        $('input[type=text],input[type=email]').each(function(ind,elem) {
            if ($(elem).attr('placeholder') != ""){
                $(elem).val($(elem).attr("placeholder"));
                $(elem).click(function() {
                    if ($(this).val() == $(this).attr("placeholder")) {
                        $(this).val("");
                    }
                });
                $(elem).blur(function() {
                    if ($(this).val() == "") {
                        $(this).val($(this).attr("placeholder"));
                    }
                });
            }
        });
    }
}

Github offers a fun feature called gists. It’s not a full git repository, just a way to host a single file or a few lines of code. In addition they offer a script to embed your gist into your site. The only problem is that if you toggle in between the “Visual” and HTML tabs on the WordPress wysiwyg it will probably strip out your script. So, back to the drawing board, right? No.

Add the following code to your theme’s functions.php file and you’re good to go.

I did find a plugin that offers this functionality; however, when I downloaded it and opened it up it had WAY too many lines of code. I appreciate extra functionality and maybe a plugin is the way to go for you if that’s what you need.

But if you just need the shortcode… The above solution is lean and mean.

Download and try it yourself

A short while ago I stumbled upon an interesting Hacker News conversation…

Intrigued by the challenge, I decided to implement the theory as a WordPress plugin for all to use. So here’s the gory details…

The Flow

1. User visits Login page
2. Login page Generates unique hash, saves hash to the database
3. Login page Creates QR code of a link that GET posts hash to the Plugin’s admin page
4. Via long polling Login page waits for a username to be inserted into the row in the database that has the page’s active hash
5. User scans QR code with mobile device and which is sent to Plugin’s admin page on mobile with along with the active hash posted via GET
6. In WordPress, the User must be logged in to reach Plugin admin page by definition
7. The Plugin admin page records the username to active hash in the database (the GET posted hash)
8. The Login page sees a change in active hash’s row of the database and reloads the page with a GET post of the active hash
9. Using the WordPress action init the page  receives the hash, finds row of active hash in the database and pulls the username, it then removes the hash from database so it can’t be reused
10. The page then logs in the User using the username pulled and redirects the User to the WordPress Dashboard

Notes

Alone, this isn’t a solution to never having to remember your passwords again. Your mobile browser has to have the logged-in cookies for it to work completely without password.

Why is it still useful? Well, everyone goes everywhere with their cellphones now, but with today’s mobility it means that you’re likely to find yourself with an urgent idea to post to your blog, and not wanting to type it out with your thumbs on your mobile. So, borrow Aunt Sally’s computer – that by all chance has thousands of suspicious apps, key loggers and, by the way, is running Vista – and to log in just scan away!

Ideally, it would work great with an app built to complement it that would scan the qr code, save your passwords, and log you in automatically if the local cookie had expired… Perhaps that app is in the works… Comment below if you’d like it and I may be swayed to create such a monster. Perhaps tiqr might want to gang up…

Is it secure? I’ve put several checks in place to make sure it is.

1. Username/password are never passed back and forth, only the unique hash.
2. Hash is removed from the database once it’s used, old hashes that haven’t been used can’t be unless the database is hacked, but then you have bigger issues.
3. All database queries of the hash have been escaped to prevent XSS attacks.
4. nonce added to ajax call.
5. nonce and confirmation added to on mobile end to prevent CSRF attack.

I’m pretty sure that covers security. Anything else needed?

Suggestions? Comments? You know where that goes…

Special thanks to…

• 5 tips for using AJAX in WordPress
• PHP jQuery AJAX Javascript Long Polling - although the long polling solution I worked out with WordPress’ AJAX isn’t perfect yet.
• And of course @PeterLegierski for the original post on HN.

View the GitHub repository

Download and try it yourself

Add the following snippet to your LocalSettings.php OR includes/OutputPage.php file and it will insert the META tag ROBOTS NOINDEX, NOFOLLOW into the header.

As you know, the ROBOTS NOINDEX, NOFOLLOW tag will tell search engines not to index your site.

## Adds global NOINDEX,NOFOLLOW  meta to site headers
$wgExtensionFunctions[] = 'globalNoIndex';
function globalNoIndex(){
   global $wgOut;
   $wgOut->addMeta ( 'ROBOTS' , 'NOINDEX,NOFOLLOW') ;
}

Why would you want that? Any number of reasons: you’re still developing it, it’s a private wiki for just you or a small group of people or maybe you want to block search engines to just to spite them.

The above snippet can be modified and used to insert any meta tag into the header of your mediawiki site.

I placed the code after defining the theme in my LocalSettings.php page and it worked beautifully. Not sure where specifically it should go. Please comment below if you know of a “best placement” for the code.