I’ve always found the WordPress admin bar a bit annoying. It can definitely be handy for editing pages while browsing (clicking the edit button on the admin bar is easier than trying to find it in the admin area). Whilst it has its uses however, I tend to turn it off by going to Users / Profile / then un-ticking the ‘Show Toolbar’ check box.

I’ve seen tricks for moving the Toolbar to the bottom of the page, which is better because the toolbar is less obtrusive… but it still annoys me because it gets in the way of experiencing the site. The other problem of moving the toolbar around is that you have to keep track of how WordPress develops it; for example recently WordPress added another pane for the user (screenshot below).

One of the techniques I was using to push the toolbar down the bottom broke because of this new addition (well, it didn’t break, but you couldn’t see the new user bar because it was pushed below the bottom of the screen, being unaccounted for in the CSS).

In this tutorial we’ll leave the toolbar where it is, so if WordPress adds or removes anything in future we won’t have any problems. But we’ll subtly hide it by default, fading it in when users hover at the top of the page. Better still we’ll use CSS transitions to further control how it fades in.

The best thing is that we’re only modifying 6 properties…

body.admin-bar {
    margin-top: -28px;
}

#wpadminbar {
    opacity:0;
    transition: opacity 0.3s 3s;
}

#wpadminbar:hover {
    opacity:1;
    transition: opacity 0.3s 0s;
}

If you’re already up and running with Responsive Design (RWD), what’s the next step?

At first, I was pretty happy with the way RWD solved the problem layout on different sized devices. However, with the accelerated growth of mobile devices + high-resolution screens we’ve got another problem on our hands – serving whopping high-resolution images by default to all devices. Now if we’re serving the images via CSS, this isn’t a problem; we use our default stylesheet to serve standard resolution images to mobile devices, and then we might decide to swap the image out for a larger version on bigger screens or higher resolution devices, using Media Queries.

The problem really arrives when we’re looking to serve images within our markup. For example, WordPress serves images dynamically, depending on which page you’re visiting. Because we can’t use CSS Media Queries to control what our WordPress database serves us, we need to think carefully how we manage our content. Thinking of high-resolution devices down the line (iPad 3?, and then what next, Apple? Retina Desktops?).
We need to start the ball rolling so that all of a sudden our sites don’t look awful when a visitor hits them on a high-resolution screen.

I admit, I started advising clients that any images they upload via a CMS need to be twice as large as they actually appear, so that in future when the image is exposed to high-resolution device and scaled to 100%, it still looks crisp. Now say we’re dealing with a large image at its default size (maybe 800px wide). This means I have to tell the client they need to upload a 1600px version, for when someone lands on their site with an iPad 3 (or whatever the Android equivalent is, Ice cream Sundae Sandwich with a 99 Flake?). All of a sudden any advantage we’re gaining with Media Queries has been blasted away by these data-hungry high-resolution images.

So enough complaining, what’s the solution? Well, in short, there’s not a solution yet. It’s still a work in progress; in fact a new discussion was kicked off the other day here. Reading Mathew Marquis’ post, it really is depressing to think that it’s probably going to be a while before this gets any traction. Further more, I don’t know how the proposed solutions would integrate into a Content Management System like WordPress. However, do not fear, Matt Wilcox has come up with a great solution for the time being, which he calls Adaptive Images.

Bad news?
Under ‘limitations’ Matt points out that the solution relies on Javascript and cookies. But honestly? No big deal, it’s better than doing nothing about our sticky situation. You can read more here.

Good news?
It’s easy to use and it’s a completely non-destructive solution. Ever want to change your approach to handling large images? Just remove the script and delete the cache file. That’s it.

It’s been a good few months before I’ve posted anything, mainly because I have a new job and client work is taking up all my evenings. I still have to edit out my ums and ars quite a bit before I can publish a video unfortunately so I can’t quickly publish as I’d like.

I thought I’d write some really short posts for now instead, seen as I’m learning of tonne of new stuff.

Here is a way to finely target IE to your heart’s content in WordPress (but you could easily adapt for plain HTML).

<!--[if IE 7 ]><html <?php language_attributes(); ?> class="no-js ie ie7 ltie8 ltie9"><![endif]-->
<!--[if IE 8 ]><html <?php language_attributes(); ?> class="no-js ie gtie7 ie8 ltie9"><![endif]-->
<!--[if IE 9 ]><html <?php language_attributes(); ?> class="no-js ie gtie7 gtie8 ie9"><![endif]-->
<!--[if (gt IE 9)|!(IE)]><!--><html <?php language_attributes(); ?> class="no-js gtie7 gtie8 gtie9 modern-browser"> <!--<![endif]-->

This method adds a loads of classes that you can use to target IE after you’ve targeted normal browsers.

Example

In the example below I know that when I move the nav around it messes up in Internet Explorer 7. This is probably a bug that I would rather not waste time fixing, choosing to dedicate my time to working on advanced CSS3 for modern browsers.

Normally I would write two sets of rules (one for normal browsers, and one to neutralise IE7), but with our extensive targeting classes I can simply target browsers outside and above IE7 using the gtie7 (greater than IE7) rule.

.gtie7 #nav {
    right: 440px;
    top: 26px;
}

It’s important to note that these classes are more for targeting buggy behaviour. If you’re looking to change layout for less capable browsers then consider using feature detection with Modernizr.

Finding the Build Script Hard Work?

The scope of the HTML5 Boilerplate by Paul Irish and the team is pretty big. In fact, they seem self-aware of this, sending a questionnaire to their users, trying to figure out which parts of the project people use or don’t use. Here are the results.

Part of the Boilerplate is a tool called the Build Script; a script that runs in Terminal that essentially speeds up your website through compressing your code and images, forcing visitor’s browsers to cache everything, and probably some other wizardry that I can’t fathom.

Eh?

Unsurprisingly over 70% of users don’t use the Build Script. Whilst the BS seems great, it’s one weakness is that it requires a bit of time-investment to download Terminal stuff and figure out what’s going on. Sure, the HTML5 team have videos, but as soon as you start watching them it’s immediately clear that Paul and the team are already perfectly comfortable with Terminal and assume we are too. When Paul started typing gibberish like ‘Ant Build’ into the Terminal I imagined many of the designers out there simply switching off. From the outsider point of view it’s more developer territory. Don’t get me wrong, I think the Build Script is great, but there’s an easier way…

The Good News

If you’re in the habit of building websites on WordPress, there is an amazing tool that will pretty much do the same thing as the Build Script, but with a nice user interface and no Terminal work :-). I’m talking about a free plugin called W3 Total Cache, which I’ve seen recommended in many places but not bothered to check out until now. I’m so pleased with it that I’m going to side-park the Build Script from now on (unless I’m working on a non-WordPress website of course).

Video Notes

Don’t forget to empty your cache in the ‘performance’ tab of W3 Total Cache every time you upload a piece of code that W3 Total Cache will compress e.g. if you have CSS compression enabled and you upload a new version of your stylesheet you’ll need to empty the cache before you see the changes to your website.

Here is the link about why you should use the enqueue method to load jQuery and not hardcoding.

Please use the below code for running jQuery from the functions file. Ignore my suggestion in the video, it actually broke the jQuery in my Dashboard afterwards:

function my_init_method() {
	if(!is_admin()) {
		wp_deregister_script('jquery');
		/* =Jay. This code taken from Digging Into WordPress by Chris Coyier + modified so that jQuery is in the footer, with reference to: http://codex.wordpress.org/Function_Reference/wp_enqueue_script */
		wp_register_script('jquery', ("http://ajax.googleapis.com/ajax/libs/ jquery/1.6.1/jquery.min.js"), false, '1.6.1', true);
		wp_enqueue_script('jquery');
	}
}

add_action('init', 'my_init_method');

Chromebooks, here is an approach that is the complete opposite. We don’t have to force local data on to the web because all our data lives on the web.

Personally I have been long advocating web apps and where possible I will work on the web instead of using a native app e.g. Why use Twitter App when you can just go to www.twitter.com and get the same experience? They have built in keyboard shortcuts and I can get notifications via a Chrome extension like Twitter Notifier. If I get a new computer I don’t have to worry about downloading a native app and setting up my preferences again, the web app is exactly as I left it.

There are many advantages in working exclusively on the web, the key ones being:

• I can work from anywhere, on any computer
• I never have to worry about setting up my computer and preferences again
• I never have to worry about backup
• I get a consistent experience across different OS’

For the every day worker I am pretty sure they would have no problem switching to Chrome OS – the only habit they would need to change is using Google Docs rather than MS Office. However, for the web developer / designer it’s much more difficult to use Chrome OS. Here are the problems we face…

1. We can’t develop locally when working on a Content Management System like WordPress. No MAMP
2. Whilst we could use Firebug or Web Inspector there are no really good substitutes for a program like CSSEdit or a text editor like TextMate or Sublime Text
3. How do we transfer our changes to a web server? No FTP?

I would love to make the switch to working 100% in web apps; I believe that in 10 years from now it’s inevitable that everything will be a web app, but at there moment there are too many things preventing me from pulling the trigger. I suspect the three above issues would be major show-stoppers preventing 99% web designers from even considering Chrome OS. Some people would start arguing about the Adobe suite, but personally I design more in the browser, and Aviary looks like a reasonable substitute for me.

What about you? Can you suggest any work-arounds for these issues? And what would you miss if you had to switch to Chrome OS?

In this tutorial we’ll go through…

1. Briefly why you should be using MAMP
2. Changing the preferences in MAMP
3. Backing up our website files
4. Using Symbolic Link to copy the actual WordPress database to Dropbox

The link to the Symbolic Linker that I mention in the video is here… Symbolic linker.

Filezilla is a free FTP program available on Mac and Windows, you can download it here.

Here are the filter configurations I talk about in the video:

In part 2 of the HTML5 Build Script + WordPress tutorial we’ll go through the changes we need to make to the build script so that it works nicely with WordPress. It’s actually not too taxing, but there are a few gotcha’s.

If you want to jump straight to the code there’s a link below to my blank WordPress theme, based on Starkers by Elliot Jay Stocks, but with added HTML5 Boilerscript stuff + a working Build Script.

HTML5 Boilerplate WordPress Theme with Build Script

N.B. I’ve made a few tweaks here and there, for example I’ve included Ryan Fait’s Sticky Footer, Andy Clarke’s 320 and up principle for CSS3 Media queries, etc. Feel free to strip these out – just use Cmd + F to look for a comment prefix of =Jay

The idea of the HTML5 Boilerplate is to provide a starting point for future-proof web design. From putting javascript at the bottom of the page to using Modernizr, this is a collection of best practices from some notable people in the web industry and we really need to be aware of these basic fundamentals.

However, basic Boilerplate aside my next two videos will specifically focus on the ‘Build Script’, a feature fully realised in version 1.0 of HTML5 Boilerplate. The idea of the Build Script is to always serve your code compressed, and always get visitors to cache unchanged code. Achieving this will significantly increase the load speed of your website and in future you’ll be forever turning your nose up at other people’s YSlow score.

In this video we’ll go through…

1. Downloading and using the HTML5 Boilerplate Build Script
2. Using Terminal to run the script