über easy user-agent swapping in Chrome

A little know setting in Chrome lets you easily spoof websites into thinking your desktop browser is an Android device or even an iPhone 4. This functionality has been around for about a year, but it seems very few web developers I’ve talked to actually know about it. It’s also not well documented in the Chrome developer docs, and it’s just mentioned in passing. So, this is me giving a shout-out to this very cool, useful and time saving functionality.

I love it because in seconds you can pseudo-emulate a mobile device view on the Chrome desktop browser. Sometimes I need to tweak something on a web mobile app and I don’t want to go through the hassle of viewing it on my device until I’m fully ready to test it on an external web server. With the user-agent tool you can set the size exactly for testing and viewing.

This is especially useful for when you are building responsive apps that use CSS3 media queries or frameworks like Twitter Bootstrap. In comparison, without this tool you have to manually resize the browser, which is time consuming, inaccurate and usually annoying.

Here’s how this works:

Step 1. In Chrome use Control + Shift + I to open the developer tools window. Then in the lower right hand corner click on the wheel icon.

Step 2. In the Overrides tab you can select User Agent or manually adjust the device screen resolution and font scale. Cool! There is even a checkbox option to emulate touch events using your mouse.  Note that there will still be mouse events, however you can also test code that listens for touch events.

Step 3. Use the User Agent pulldown list to choose from various presets.

Step 4. Easily swap between landscape and portrait modes.

Step 5. Make sure the correct user agent was sent via HTTP request header in the Network tab of the developer tools. You may need to reload the page.

Step 6. Have fun and try it out yourself!

Going mobile with blogging

I’ve had several comments that my blog is not mobile web enabled and that I need to “put my money where my mouth is” and “practice what I preach”. Little did they know that I have in fact been investigating the various mobile web options and doing my homework. In fact, just in the last week I started experimenting on my live blog, which I will add is a scary thing to do and there have been some problems. So if you come back to the website and it looks like something has changed, it’s very possible it’s related to my ongoing modernizing efforts. And, puh-lease let me know if you see something is broken.

The approach(es). I’ve started with the approach of having two different themed websites: one theme for desktop and one theme for mobile web. Why? Because I’ve gotten quite a bit of feedback that some people like the utilitarian look and feel of the desktop theme. On that note, if you don’t like it now is the time to say something. I’m also looking at responsive (fluid) designs that use CSS3 media queries to hide and unhide content depending on the device and browser you are using. I’ll be tackling responsive designs next, and perhaps much sooner than expected if approach numero uno crashes and burns in a flaming, twisted mess.

Challenges. I can say one of my primary challenges is handling legacy content, for example short codes and existing plugins such as the ones that affect page load performance like Total Cache. If you are just starting out fresh then your life is significantly easier as you are starting with a clean slate. But I have almost 100 blog posts that need care and feeding and I don’t really want to be manually changing page content, if I don’t have to, so that the new website theme or plugin can have its’ way.

Fallback plan. At the moment I’m being very careful with taking a full backup of the website and the database, as well as copying specific files before playing with any plugins or theme changes. In the best case scenario I’d like to create a completely separate copy of the website to play with, however there is a good chance this isn’t going to happen unless I simply can’t get a theme or plug-in to work. Usually theme or plug-in changes are relatively painless, with the emphasis on ‘relatively’. Besides, I always recommend clients create a test copy of their website that’s not visible to the public. But, they are usually big(ger) organizations and have more resources. I may still do this if time permits, but my theory is if I really mess something up I can restore the site or database.

Maximum WordPress Spam Prevention: Part 2

Anyone who has a public facing blog knows about being bombarded by spam. Recently I got so annoyed I started locking down blog comments after thirty days. After a month or so I realized this was counter productive. Readers could no longer participate, ask questions, etc. so I started searching for a better way to handle my anti-spam measures.

After doing a bunch of research I landed on Askimet. Note, I am not being sponsored by Askimet, I truly did this research on my own. I can say so far the results have been awesome. I’ve been able to turn all blog comments back on, and it’s very rare for a spam comment to sneak through. 99.9999% of the time when that happens it seems that Askimet has already killed the spam by the time I get around to viewing the WordPress spam queue.

Since turning Askimet on I haven’t had to personally deal with 462 spam comments. Yay! In the screenshot below, the 228 spam comments number represents a partial snapshot of the spam that I had to manually delete prior to Askimet.