A “holy shit…what happened?” experience is never a fun thing, especially when you’ve been working hard to drive traffic to your blog or business site. And let’s face it, most of us aren’t developers by trade, so seeing things that are out of sorts can really ruin your day.
But, many problems with WordPress can be easily diagnosed and repaired without having a computer science degree or wearing a Three Wolf Shirt in a basement.

Warm Up

Before you get started, it’s important to have some information. It’s a good idea to jot this stuff down and save it somewhere now, before you need it.

A short list:

• Login for your webhost (often times the cPanel access)
• FTP login
• A basic understanding of the WordPress file structure
  • wp-config.php: in the root of your site. Contains the connection info for WP to get your content out of the database
  • theme and plugin folders: all of the unique items live in two main places, both of which are in the /wp-content/ folder. /plugins/ has…you guessed it, your plugins. /themes/ has all the various themes your site may have. Keep in mind that a theme or plugin doesn’t have to be active, just installed at some point.
• Your most recent backup. You ARE running frequent backups, AREN’T YOU???
• A cup of coffee

Common Errors

The dreaded “white screen of death”

So you’re going along, doin your web thing, and then one day your WP site is just…blank. A white screen. No error message, no text, no….nothin’.

Why This Happens

This is usually caused by the site needing more memory to process its various functions than the host is giving it. Often times, you’ve got a lower-end host ($5 a month! It’s a deal, right? Wrong.)

How To Fix

1. Log in via FTP and go to your wp-content folder.
2. Rename the entire ‘plugins’ folder to something else (for example, adding an X in front of it). This will force all the plugins to deactivate. Can you log in now? Good.
3. Go to the plugins section of your WP admin area and you should see a red message telling you that all plugins have been disabled.
4. Now go back in FTP and change the folder back to ‘plugins’.
5. Reactivate each plugin, one by one. When you get the white screen again, you’ve found the culprit.

How To Prevent It Going Forward

• Increase your memory allocation in your wp-config.php file.
  • define('WP_MEMORY_LIMIT', '64M'); (details here)
  • note: your webhost may have a pre-set limit that you can’t override.
• Keep your core WP install and plugins up to date, removing ones that aren’t needed.
• Review the plugins you’re using from time to time. If one is outdated and hasn’t been updated in a while (over a year is a good baseline) look for a possible replacement.

Possible malware infection or hack

Getting a strange PHP error? Seeing links in your post that you clearly didn’t put there? Or do your Google listings mention pharmaceutical ads instead of your post titles and excerpts?

Bad news: you’ve been hacked. In the past, sites that had high traffic or were polarizing on specific issues were targeted. Now? It’s largely automated, and they’re just trying to spam the hell out of whatever they can get.

Why This Happens

• Unsecure host (GoDaddy has been plagued with problems in the last year, but they aren’t the only ones)
• Outdated WordPress install

How To Fix

• Do a scan of your site. I personally recommend the Sucuri Security webscan.
• Pay someone to fix it.
  • This isn’t something you want to try and deal with on your own. Usually the hack can be in multiple places and include “backdoors” that allow them to get back in. A service like Sucuri (which I personally recommend to my clients) can not only fix the problem, but keep an eye on things and fix any future issues as well. It’s worth the money.

• Keep your WordPress install (both core and plugins) up to date. When a new version is released, hackers can often times review the different versions and look for exploits.
• Use strong passwords.
• Don’t use “free” themes you find on Google (and here’s why)
• Follow general best practices when it comes to WordPress security
• If it’s reoccurring, look for a better, more secure host.

You Hit Publish…but didn’t mean to

OK, so this isn’t so much an emergency in the true sense of the word, but can still cause a problem. Publishing unfinished content, when you’re not ready to, can ripple out into the various social networks and give people a skewed view of what you’re all about. And you may be asking, “What about my RSS / auto-post-to-every-social-network-ever functionality?”

How It Happens

• Well…you hit the publish button. Not a lot of detective work here.

How To Fix It

• Change the post status back to “draft”

How To Prevent It

• Write your posts outside of WordPress. I personally use Windows Live Writer, but here’s a comprehensive list of what’s available
• Delay posting of RSS via a function
• Don’t use an auto-posting function. Seriously, take the extra 30 seconds and post it yourself

My site looks….wrong

So you’ve published a post and….something seems wrong. That left sidebar is on the right, the right sidebar is below the post, and your footer is nowhere to be found. What’s going on?

How It Happens

• Often times, when copying a post over from a regular word processor (i.e. Microsoft Word) the program brings over with it a lot of extra markup. That’s not a problem if you’re using Word, but that stuff isn’t meant for the web. You can tell by looking at the HTML tab and seeing a lot of extra <div> and <span> items, among other things. Frankly, unless you purposely put it there, you shouldn’t see much else besides images and maybe a few <strong> tags for bolding. If it looks like an HTML page, you’re probably messed up.

How To Fix It

• Open the post or page in the HTML tab in WP and look for extra markup that’s in there and remove it

How To Prevent It

• If you’re pasting from MS Word, use the built-in “clean” posting button.
• Do a quick check on the HTML tab before you publish, and peek at the “preview” tab as well.

In Closing

This isn’t meant to be a cure-all for what may happen. In the years of running my own WordPress development agency, I came across different problems and solutions often. When in doubt, hire a professional. If this is something that matters to your business, spending the money on a pro is well worth it.

Resources

Below are a few good places to start if you’re trying to figure out a specific problem. Just be mindful that the people that help on the forums are volunteers and are helping because they care. So be nice.

• WP.org forums
• WP StackExchange

One More Thing

While WordPress is very easy to use, it’s still software. It can have bugs, things can go wrong, or it can just plain stop working. Just like anything else you plug into a wall or log on to. There are now dedicated WordPress hosting companies such as page.ly, ZippyKid, WP Engine, and Synthesis (if you’re running the Genesis framework). While they may cost a few bucks more than your average shared host, they are built to handle WordPress and ONLY WordPress. They often handle all the upgrades, security, and backups for you, so it’s one less thing to worry about.

For this post we’ll be going over how to assign an app ID to your website, and touch upon getting PHP snippets for dynamic code. I’ll be posting another follow up to this, but for those looking to get their feet wet into some code this will be a good starting point.

This will be for the WordPress CMS. I’m updated to the most recent version 3.2.1. Warning: There are more steps after this that will be in my next post, so I wouldn’t implement this just yet. Just take the time to get a good understanding of it.

Assigning a Facebook App ID to your Site

First you’re going to need to get an app setup for your website. Go to the app section for Facebook Developers and click the button in the top right to create a new app. Enter the appropriate information (it says ‘failed’ in my image because I already set one up with the same name) and have it created.

From there, you’ll be able to enter in your display name, app name and other necessary information to get the ID assigned.

Be sure at the end that you go down the bottom and click the “website” section so you can enter your website URL.

Once you have all of this complete, you’ll be taken to a screen with all your finalized information.

When you’re working with various Open Graph code, the App AD/API Key is what you’re going to want to use when it’s being referenced. If there’s any reference to your fbadmins ID, you can find that by going to http://graph.facebook.com/*username*. Put your username on the end and it’ll pull up the raw information so you can grab your ID.

Getting a Little Dirty in WordPress

First, make sure that the site you’re trying to edit is your own domain on the .org platform- otherwise you won’t be able to get in and edit anything in your theme files.

If you’re a WordPress theme-editing virgin, here’s a quick walkthrough of the steps to get to your editor. It’s actually really painless.

Login to WordPress and on the left sidebar, click on the Theme editor. You can find it under the Appearance tab.

Once you’re in the editor, your individual style sheets will be on your right. Since we’ll be working in the Header.php file first, look for it in the right sidebar. This is where all of your header code sits.

Open this up and don’t get scared!

Javascript SDK Setup

I’ll run through this in more detail in my next post- it’s best to spend some time in here because of the capabilities that using the Javascript SDK opens up. Using this give you a ton of different capabilities with social plugins and canvas pages, so going in depth wouldn’t do it justice. If you want to use the xFBML social plugins, you’ll need this.

The Javascript SDK is in the Header.php file in the body tag. Here’s an excellent resource from the Facebook Developers page on getting it integrated into your site.

Remember, when appId      : ‘Your App ID’, is referenced in the Javascript SDK code, it’s asking for the code from the application that you just setup.

You’ll also want to make sure that this XML namespace goes up underneath your doctype tags on the top of your head.php file.

<html xmlns:fb=”http://ogp.me/ns/fb#”>

The Like Button

This is the snippet you’ll want to use for your like button once you get the Javascript SKD all setup. I put this in my post.php file so it’ll reflect across all my individual posts. If you don’t want to add code to your post.php page you can drop it in each individual post as you finish them, but you’ll lose the ability for users to connect directly with your site and lots of the functionality beyond the like button.

<fb:like href=”your URL here” send=”false” layout=”button_count” width=”450″ show_faces=”false”></fb:like>

If you want to show the faces of those who “Liked” your content, you can change show_face=”false” to “true“. You can also adjust the button width (width=”450″) and whether you want to include the send button or not. This is only for the main like button code, we will adjust it in the next post so it’s dynamic and pulls the individual post information.

Your code might vary depending on what type of theme you’re using, but I put this code in the container for my post and underneath my main image.

With this particular setup, the like button will ask the user to sign in so it connects directly with their profiles. When the dynamic snippets are added, the social plugin box that pops up will also have a comment area so they can add a comment to their “like” directly from your page.

 Open Graph Tags

As with the like button, the Open Graph tags that I referenced in my previous two posts have the ability to be changed so they use PHP snippets that dynamically pull in the individual titles and images. Without using this snippet it’ll just pull the the information from your main site when it’s in the header.php file.

This lays a nice foundation for part 4 of my post, where we’ll actually get into the PHP portion. I wanted to keep this fairly simple so you can get an idea of the pre-dynamic process. I’m also working on social plugin implementation so I’ll also be working some kind of Timeline tie in to follow up to this.

If you’re planning on jumping ahead and getting everything working yourself, make sure to check your code against the debugging tool. It’ll let you know if you have stray code or if your tags aren’t working properly.

If you’re curious to learn more about the meta tags and their uses,  check out my Facebook Open Graph part 1 or part 2.

Being resourceful is critical to getting the job done. As web designers and graphic designers we are constantly looking at the latest tools and tips on how to push our craft and better our workflow.

This list is some of the tools and resources that I have been incorporating into my processes, whether it is something that is inspirational by way of geeky interviews that talk shop about hard/software used like The Setup or a website like Designers MX and Stereomood that fuel my creativity by stimulating my ears with fresh music. Dive in and please feel free to let me know what tools or resources help you and how by posting a comment!

Lorempixum

Lorem ipsum dolor sit amet. What? If you are a graphic artist or web designer and have to use dummy text or filler (or meat and filler) on a daily basis- you know. Lorempixum is that but with images and photos; a genius idea that allows you to specify what type of subject and size you want your filler image to be and it will generate an image for you to use. They even have a bunch of preset settings to choose from.

Little Big Details

User interface, the space where interaction between humans and machines occur, is everywhere. The Internet makes us, as users, appreciate the beautiful- intuitive- simplicity of a great interface, or leaves us feeling deeply annoyed and lost. I am always inspired by creative design in this area and Little Big Details is a Tumblr that shows off amazing examples to learn from and be inspired by. Definitely worth a follow.

The Web Font Combinator

The Web Font Combinator is a cool name for a site that lets you preview web font combinations and sizes instantly. Simple, helpful and to the point (or should I say pixel). Currently this tool only uses fonts supplied by the Google Font Directory, as well as a handful of common system fonts.

The Setup

Get your geek on at The Setup and read cool interviews with industry creatives and vanguards from all walks of life. They talk shop and get asked all the right questions from ‘setup’ of hard/software to inspiration. I love this: “Despite appearances, the site is not actually sponsored by Apple – people just seem to like using their tools. We’re a fan, too.”

Designers MX

Music is on almost 70% of my day when I am pushing pixels on the computer. It drives me when I need that boost and it puts me in that zone where I seem to loose track of time and look up at the clock and see that I have just spent the last 2 hours in Photoshop and forgot to blink. Designers love to make mixes of music. Designers MX asks creative leaders what music fuels their creativity. I love this concept and it is a great way to discover new music/ideas!

Stereomood

Piggybacking on Designers MX, here is another way to get inspired by music. The genius idea behind Stereomood is that you can pick a playlist to listen to based on your mood or emotion. Feeling happy, they have that. Feeling sexy… yep, that too.

What Web tools or online resources inspire you or make you more productive ‘on the reg’? I would love to hear!

Content and Menu Text

It should be a given that text on a website needs to be actual text, not text that has been written onto a graphic and then placed on the website. Actual text is not only good for SEO, but it also allows text readers to read the content out loud to the user. Many tools allow text to be translated into braille, such as the free examples listed below by Disabled-World.com:

• BRLTTY: A background process (daemon) which provides access to the Linux/Unix console (when in text mode) for a blind person using a refreshable braille display.
• EdBrowse: Makes a complete audio desktop, including web access with JavaScript support.
• Emacspeak: A speech interface that allows visually impaired users to interact independently and efficiently with the computer.
• Spoken Web: Users of IE can take advantage of this helpful text to speech tool.
• VoiceOver for Mac users: An accessibility interface that offers you magnification options, keyboard control and spoken English descriptions of what’s happening on screen.

Having actual text for all website and menu navigation items also allows a user to increase the font size, making text easier to read. Image text may become distorted and harder to read.

Example of website content where the font size has been increased.

Example of website content where the font size has been increased.

Contrast Ratio

Contrast between website colors and text is another element of website design that can make it difficult for those with visual impairments to view and navigate a website. AccessColor by AccessKeys, is a free tool that tests the contrast of websites. As they explain, “AccessColor tests the color contrast and color brightness between the foreground and background of all elements in the DOM to make sure that the contrast is high enough for people with visual impairments.” As mentioned above, AccessColor cannot evaluate the contrast for text that has been placed on a graphic: “AccessColor examines only the difference between foreground and background colors for text elements. This tool is intended for websites where most of the text is not written on background images or with flash.” Paying attention to contrast is important, as there are specific visual impairments that struggle with them, as Kelli Shaver states in 5 Ways to Ensure Your Site Is Accessible to the Visually Impaired on Mashable.com:

“Eye diseases like Retinitis Pigmentosa, Glaucoma, Retinopathy and cataracts (some of the most common eye disorders out there) all lead to a significant decrease in contrast sensitivity — that is, the eye’s ability to differentiate between similar shades and levels of brightness.”

Making sure the contrast is pleasant enough to read is an easy step to implement in the web design accessibility process.

Taking Colorblindness Into Consideration

Those who are colorblind may have trouble with contrast as discussed in the previous section, but elements of a website, such as call to action buttons or brightly colored menus, may also present problems for those with colorblindness. The Color Blindness Simulator offered free of charge by Entre.com allows designers to upload a graphic to see how it may be seen by those who have colorblindness. This is not only crucial for webpage elements, but may also be relevant in logo design- especially since most logos have text incorporated into them.

Broken Links

Broken links are something that makes a website inaccessible for any user, regardless of impairment. There are several free broken link checkers online, but a few free tools are:

●     W3C Link Checker

●     Broken Link Checker Tool

●     Online Broken Link Checker

Broken links not only make some pages of a website inaccessible from other pages, they are also bad for SEO purposes, especially if they exist in the menu navigation. In order to combat broken links, be sure to check for broken links regularly and also have a 404 redirect in place to send users to a 404 page in case they click on a bad link.

Mobile Browser Version

Mobile versions of websites make it easy for those with smart phones to navigate pages, but they can also help those with visual impairments. Because mobile websites are often a ‘watered-down’ version of a website, viewing them on a computer’s normal browser may make them much easier to navigate. As Henry Swan stated in his presentation at WWW 2008 in Beijing, those who want to view a website on their smartphone and those with disabilities may run into the same problems, such as excessive images, javascript, and keyboard only navigational websites. Swan reports that working on mobile and accessible versions at the same time can help reduce costs and development time, in effect “killing two birds with one stone”.

Developing accessible websites doesn’t have to be time consuming, especially contrast ratio, actual text, and mobile website versions are things that should be implemented across all websites by default. Building websites with the visually impaired in mind can increase traffic and repeat visits, as the site will be easier to use overall.

I don’t know if that 8-line statistic is true. I’m not even sure I remember it right. But, like most statistics, it doesn’t matter if it’s true when it illustrates my point: there’s more to programming than producing lines of code.

Let’s look at an average programmer’s eight hour day. If it only takes a few minutes to physically write 8 lines of code, where is the rest of that time going? Some of it goes into planning, but even the most pensive programmer spends a small fraction of their total time thinking in silence. Let’s give planning 30 minutes. How about research? Nothing can be built without first understanding how the new jQuery library or Cloud service we’re interfacing with works, but reading more than 10% of the day away looks suspicious. I’ll knock off an hour (tops) for research. Code re-use doesn’t count either. It’s an important part of programming, but those aren’t new lines, they’ve already been counted by someone else.

After planning, researching, testing, cutting-and-pasting, and Facebook stalking, we’re left with 5 hours in the day that are completely unaccounted for. Where does all that time go?

One place: Debugging.

Debugging is the sometimes time-consuming, and always tedious, process of fixing errors in software. I’m going to explain the concept of debugging to non-programmers because I think there might be some parellels between the steps of debugging code and launching a successful marketing campaign on the web. I come from a C++ background.

A lot of people don’t know this, but the original C++ compiler (the program that turns code into other programs) actually plays that “you’re a loser” trumpet sound from the Price is Right every time you compile code. That’s because in C++, 99% of compiled code either doesn’t compile at all or fails straight away. The web is not so unforgiving. Because of that, I learned a lot about the process of debugging that helps me every day. I’m going to go over the general steps I take when things don’t work.

Step 1: Blame everyone else

When anything breaks, the first thing any responsible programmer does is blame everyone else. The user, other programmers, the server, squirrels, the moon; it’s everyone else’s fault, but the code is not broken. I’m joking, but it’s kind of true.

• Make sure the server was updated with the most current stable code. That’s an easy mistake to make and it means it’s not your code. .
• Clear your cache. Clear everyone’s cache. In fact, I think I’m just going to turn my cache off completely after writing this–at least until I can remember what it’s purpose is beyond driving me insane when it doesn’t refresh. .
• Upgrade your software libraries. Update the server, rename files, delete plugins–basically do all of the quick changes you can to fix the problem, and simultaneously hope that none of them work because if they do, you’ll never know what caused the actual bug in the first place. That thought gives programmers goosebumps.

No matter what order you do the above, you’re probably about to move on to the next step.

Step 2: Find exactly where the problem is

There is a very slow evolution that has been happening in software over the last decade or two. Programming has become less about writing code and more about designing systems built on frameworks representing code modules that interact according to the design. This is a good thing. It gives people who are not programmers the ability to design sophisticated software. It also creates better, less-buggy code. It’s the future. It also means that this step in the debugging process is becoming more foreign to developers.

The first real step to debugging software is finding exactly where the point of failure lies. That may sound simple, but there are a lot of layers to a program working together under the user interface. Fixing a big enough piece of software isn’t like fixing a car that isn’t working, it’s more like fixing a freeway that isn’t working. Any number of layers could be at fault and this step is about narrowing it down to the most likely suspects. Here’s a hint, they should have line numbers.

If you’re a programmer, I’m not going to rehash available debugging tools here. The tools specific to your language and platform are probably a part of your IDE. If you’re not using them, do the opposite of that. However, for all you non-programmers, I’m going to give you two little magic words you can use to find out exactly where a program is failing: “alert” and “echo”.

alert('hello'); //for javascript
echo 'hello'; //for PHP

If your website has stopped working, open up your favorite FTP program and start dropping those bad boys into your developers’ code like you’re Ebeneezer Scrooge throwing money out the window after waking up from a fevered Christmas halucination. Also, check out Firebug. It has some great JavaScript debugging tools you can use without touching your website files.

Some people might frown on the idea of a non-developer changing code by adding debug statements all over the place like the ones I listed above, but I say go nuts. You paid for those files, didn’t you? If your developer complains about it, then he needs to figure out a more robust backup system!

Step 3: Fix the problem

This step is the reward for all your hard work in Step 2. If you can fix the bug, fix it and move to Step 4, but what if it really isn’t your problem? It’s not your code, you can’t fix it. Better pass it off to the person who can.

Can you imagine if every episode of CSI ended right after the scientists figured out who the killer was, but then didn’t go arrest them? They just clocked out and went home? I don’t mean CSI: Miami either. That show should end right after the main credits. I mean CSI: Las Vegas. It wouldn’t be as good of a show without closure.

The point is, don’t ballpark a bug and then hand it off to someone else with an email that sounds like, “It’s the server guys doing something crazy again.” Maybe they are, but personally, I think I’m batting a solid .230 when it comes to suspecting that bugs are not my doing–even after tracking them down! That’s not a bad batting average, but it’s also not great. It makes me put in yet another run-through the code to make absolutely sure I can’t fix a problem instead of just punting it into another department.

Tracking down bugs in a complicated system is like that spaghetti scene in Lady and the Tramp. You start at one end, your server guy starts the other and eventually, you’re making out at one spicy meatball of a bug. Fix it or make sure it gets fixed, and get ready to make some more broken code because you’re not done.

Step 4: Track your users

Buggy software sucks, and bug reports suck more. The last thing anyone wants to do when their program crashes is replay the last ten minutes of their life to the same jerk programmer they blame for the crash in the first place! Most people have to be more productive than 8 lines of code a day and reliving software failures seems like a huge waste of time to them. Well, they’re kind of right.

Software is always going to crash, so plan for it. During the prototype phase, track user actions and variables like an obsessive parent attempting to create the most comprehensive baby book ever made for their newborn infant. Then, as your baby software grows up, ease off the monitoring and give it the ability to track itself. Tie user actions to a timestamp and log everything.

Log the URLs, log the server variables and session data, make sure that no data moves without you knowing who it was and where it was going. I try to build this kind of logging into the bottlenecks of code as I go, along with creating a generic logging function to call from anywhere, even if it’s simply a URL I query from inside distributed code. Sadly, since that logging code will eventually be deleted from the finished product, it doesn’t count toward my 8 lines of code a day.

Step 5: Make debugging part of your UI

When you’re dealing with software meant for a large amount of users across several disciplines and with varying degrees of technical expertise, more information is better. Dump it all out in a crash, who cares if it doesn’t make sense? People are smart. Even someone who’s never touched a computer before knows how to play “which one of these things is not like the other” when given enough information. They will call attention to something that doesn’t look right and one time in a hundred, they’ll get it right. That one time might buy you another line of code!

Try adding a hidden panel in the footer of your application that contains your debug information and state variables, or better yet, build it in as an easter egg. I’m always surprised when I see a debug mode in a program or plugin. I don’t think I should be surprised. It should be more common.

Step 6: Do not leave your threads hanging!

This is my most important piece of advice, and I wouldn’t even consider it advice. It’s more of a mandatory life choice for being able to sleep at night. For the love of God, if you asked a question about your bug in an online forum and then you figured out the answer on your own, go post the answer in the question thread that you started. If you don’t, subtract a line from yourself because you just cost the rest of us about a hundred of them.

If anyone is wondering, I counted the lines of code I wrote today. Keep in mind that I’m knocking an hour off of my day for the time it took me to write this post. That means my final figure came in a little below the average of 8.

It was -14*

*research code doesn’t count and consolidation is a killer…it was actually a really productive day!

Edit: Since the two lines of code that I wrote in this article both had bugs in them, my new total was -16. Thanks Joost, for the heads up. Fancy quotes cost developers more productivity every year than Minecraft.

Never build anything from scratch.

When I think of the perfect software programmer, I think of Paul Sr. from American Chopper:

Burly muscles? Check.
Awesome mustache? Check.
A mastery of outsourcing? Double check.

What the custom chopper guys do best is outsource the development and maintenance of technology–not to India, but to other companies who specialize in that technology. The engine, the wheels, the chroming process, everything on their bikes are purchased from vendors and assembled in a way that maximizes their combined value to the customer. Nowhere along the assembly line does the process come to a halt because Mikey has decided to reinvent the wheel.

In the world of programming, however, there’s one of those guys in every shop. I’m going to give a few reasons why the American Chopper way of programming is better than the other “reinventing the wheel” type.

It’s Cheaper

The most expensive development resource is time. Every man-hour that goes into developing software is one that you pay for, and every day that your business is waiting on custom code, is another day that sales are going elsewhere. Many programmers, myself included, underestimate the scope of tasks. When writing code from scratch, there are hundreds of details that only bubble up to the surface once the project is half-way up s-creek.

I take every estimate I hear from a programmer and double it. If you’re trying to compare the cost of a product created from scratch vs. one bought off the shelf, triple it.

Think about it like this, you wouldn’t pay a programmer to write a word processor for you or an Internet browser. Why pay one to write your lead management software or a CMS? It already exists, and if you can’t find it, hire a developer to look harder.

It’s Better

I’ve talked to countless clients who’ve wasted tens of thousands of dollars on elaborate custom systems that they could have basically gotten for free. If only their developer had followed rule number one: never build anything from scratch. The kicker is, the free version is usually better!

RSS feeds, API access, built-in security, user administration, exporting, importing, custom alerts, and dozens of other features they hadn’t even thought of yet already existed on available frameworks and software packages. Better yet, they’d been designed for users with similar needs.

Whether it’s an expensive tool set or some freebie plugin, it’s always good to have more features than you’ll use, and it’s always bad to spend more and get less. I’ve seen Paul Sr. kick a door off its hinges for less than that.

Check.

It Works

Ready-made software comes with a pedigree of beta testing. That doesn’t mean your finished product is going to win Best in Show, but it does mean that your finished product won’t leave everyone in the company scratching their heads and wondering what the hell to call the thing.

Ready-made tool sets have forums and communities of similar users who’ve faced similar problems. No solution made from scratch can boast that. Even some of the smaller commonly-used open source projects have hundreds of active beta testers–and yes I realize that sounds like calling Reno the biggest little city in the world, but it makes sense if you’ve used something like FullCalendar. A product built from scratch has only one group of beta testers: your customers.

Software built on pre-existing solutions is going to do something right out of the box, and in a business where user interface is the difference between sales and abandonment, the sooner it works, the sooner it can be refined.

It’s For Sale

In addition to the testing and maintenance, there is one big added benefit to using pre-built systems: new customers!

Look at the most popular plugins for sale in open source web applications like WordPress, Joomla, or Magento. These plugins started out as a developer’s attempt to add something they needed to an open source system instead of developing that system from scratch. Interestingly enough, those systems themselves (WordPress, Joomla, and Magento) were built on existing software packages in a similar fashion (b2, Mambo, and osCommerce). And the tool I used to look that up, Wikipedia, was itself built on a pre-existing application called Nupedia.

With its user-friendly Dashboard, and fully customizable features, WordPress is one of the greatest tools a website owner could ask for. When planning for user friendly features, a wise colleague of mine once said “Think of your Mom, is this something she would be able to use?” and I know firsthand that when using WordPress, the answer is yes. WordPress was created for anyone and everyone to use.

After completing WordPress’ Famous 5 Minute Installation there are many tips and tricks to available to set up and personalize your site. These tips are available to anyone, regardless of their level of experience.

1.Themes

Changing the entire look and feel of your website has never been easier than with WordPress’ Theme repository. You can browse over a thousand free themes until you find the one that suits your personality and needs. Once finding the new design of your website, you can make it live in literally two steps. All WordPress themes are fully customizable to better incorporate your personal logo or change colors to something that fits you better.

As for the skeptics, while you may think that the WordPress themes are not up your alley, or are too limited in style options, I highly suggest browsing through a few of their themes; You may be surprised by the versatility and variety that WordPress themes have to offer. If the free themes don’t catch your eye there are additional low-priced themes offered as well. Of course you always have the option to design and develop a custom theme, but this may require a higher level of experience.

2.Plugins

I believe the plugins offered are really what set WordPress apart from the competition. It doesn’t matter if you are setting up your site for the first time, or have already had it for years, you will never stop browsing/adding plugins. These plugins are created to make your life easier; and that’s exactly what they do. If you’re looking to setup a gallery, a contact form, Google analytics, or even a way to generate content, it can all be done with a pre-made plugin. Just hit activate, and watch how much a single plugin can improve your website.

3.Widgets

Almost all WordPress themes come with specified areas for you to add widgets. These widgets allow for you to choose what users should see on your site. Usually you will find these areas on the sidebar, footers, and headers. A very common use of the widgets in the sidebar is to display a large amount of your blog posts, categories, or other pages. Widgets can also be useful to add a search or custom text on your site.

4. Social Networking

Social media outlets are an ever-growing influence to society’s daily life; there isn’t an easier or more effective way to spread the word of your blog or website than by adding social buttons to your site. Just activate a plugin for your favorite individual social network site, or add one single plugin that will add options for multiple social sites.

5.Write the Content

After investing time and effort into perfecting the look and feel of your website, you are now ready to begin writing!

After following these 5 steps, you’ll learn just how easy it is to make updates and maintain your site.

Become a fan of BlueGlass on Facebook, Follow us on Twitter, or Subscribe to our RSS feed.

Since joining BlueGlass, I’ve come into contact with a lot of talented developers and sophisticated products at different stages in their development life cycle. To explore the tech side of our business a little more, I’m going to talk about our approach to the development life cycle. It’s not an approach that we invented, but it’s an important one. That approach is called Iterative Design.

A common belief is that software development happens like something out of the movie ‘Weird Science’. Someone gets a great idea, puts together a big list of requirements (no matter how outrageous), and then after a lot of noise and chaos, the perfect piece of software bursts out of a big mess wearing a halter top and ready for action. Unfortunately, that kind of assembly-line development doesn’t always work. It lacks checks and balances during the “big mess” part, and suffers greatly from the missing feedback that ultimately gives software value to a user.

Working on the Internet, we’ve all heard about great web ideas that were poorly executed or just never came to be. The advice I sometimes hear to get projects going is “Just Do It,” but how? I think the concepts of iterative software design that we use at BlueGlass might help some people get their own web ideas off the ground by starting small and concentrating on the most important part of any project: providing value to the user.

Iterative design is a process of software development that maximizes the benefits of prototyping, design, testing, and creativity. These are all very powerful things and they need to be arranged properly–like drunks at a wedding.

Put them too close together and its a big headache. Too far apart, and one of them might disappear because they don’t get enough attention.

The first phase of any product usually starts with a conversation that goes, “Wouldn’t it be cool if something did this…?”

At BlueGlass (and back at 3DogMedia), we design our biggest products for our most demanding client: ourselves. When we can’t find the right tool for the job, it probably doesn’t exist. And if that piece of software doesn’t exist, it should. Identifying that need powers the rest of this development cycle.

When we comes up with an idea, we let our brainstorming run wild. It’s not important to limit the features or the scope of a project here. We want to see the forest, not the trees, and we want to get a good mental picture of that forest because in the next phase, we’ll be chopping most of it down.

Once we’ve got an idea, the first step is creating a usable, working prototype. This is a big deviation from assembly-line software design and also the most important step.

In every idea, no matter how big, there is one part that can be put into use immediately. Sometimes the prototype is an experiment in the flow of “link juice,” or a content aggregation service. For example, if you consider Facebook the original big picture idea, Twitter would be the prototype phase: a method of broadcasting messages to groups of friends. Even that reduced version of the big picture clearly has value–even if it took me three years to figure out what that was.

With a usable, working prototype, everyone gets a good idea of where the software is heading and major misunderstandings can be rectified at a time when it’s cheapest to make big changes. This prototyping phase also has the invaluable effect of focusing developers on the most important tasks. Spending resources on anything that is not directly serving the original need of the user is a waste of time. The most valuable features of a product should get the most attention and by distilling those into a prototype, we make sure of that.

With a prototype that works in-house, testing begins immediately.

Too often, software design is run like the movie ‘The English Patient‘. It’s really heavy at the end and hard to pay attention to during the rest.

That pushes bugs and usability issues onto the end users–who are paying for it! Having a usable prototype early on creates a built-in testing team: us.

One thing I like to keep in mind when it comes to the testing phase is: a users’ instincts are always right. Anyone who thinks users need to learn how to use new software will find twenty unread manuals in their closet who beg to disagree. An interface should be intuitive. If a user testing a prototype clicks on a button and stares at the monitor as if expecting a result, something should have occurred. It’s up to us to find out what and make it happen during the next phase.

It might seem counter intuitive that a prototype is constructed before any design is done, but consider this, any small misunderstanding in the “idea” phase will be turned into a massive flaw in design. Design flaws are not always easy to correct. Sometimes it means having designed an infrastructure for a feature no one needs. But sometimes a mistake here means a costly redesign later.

During the design phase, we produce a set of milestones for usable prototype products that are tested upon their completion and refined in a continual process of design, prototype, test.

After some initial shyness, I’ve found that test users are as free with their suggestions as Charlie Sheen in front of a crappy webcam. This feedback helps create an interface that is both intuitive and uncluttered. However, while all user suggestions offer value, it’s important to avoid “feature creep,” the gradual

increase of the scope of a project that ultimately results in the delay of a product people can use. By keeping the basic priciple of iterative design in mind: provide maximum additional value with each iteration, we avoid becoming the next ‘Duke Nukem Forever’ (a game that has not come out in a long time even though everyone really wants it to).

Through the repetition of the above cycle: prototype, test, design, we gradually create a stable initial product. The ideal cycle of iterative design looks like a continual release of usable prototypes with a steadily increasing user base that seamlessly grows beyond us. Eventually, we move into the most exciting step of them all…

There have been some questionable interpretations of the Beatles’ song ‘Helter Skelter’, but I think it’s pretty obvious that the lads from Liverpool were singing about iterative software design. Once you get to the bottom, you go back to the top.

With a working version of a product, it’s time to pick a new part of the forest to hack into. By this point, we know more about our users, we know more about the strengths of our software, and maybe most importantly, we know what to improve in our development cycle.

So what are the unexpected consequences of iterative design? With the above methods, user feedback often turns a simple prototype into something much more interesting and valuable than the idea that spawned it. Just look at all the Google properties that came from the 20% time initiative. Look at Facebook. Look at how MySpace is dealing with Facebook.

If you really want a good example of the benefits of iterative design, there is only one product you need to investigate. Largely considered a success, this product has undergone 6,000 years of improvements and user feedback. It has been through so many cycles of design, prototype, and test, that the modern day iteration we are familiar with is completely unrecognizable from the prototype from which it spawned. That product is beer. Happy St. Patrick’s Day!

The easiest and most objective way to evaluate your site is to do it within 15 seconds or less. You don’t have to stand upside down with socks on your hands while squinting through one eye to critique your site, here are some simple techniques to aid you in your own critique.

Load up your website, close your eyes and wait for the page to load (I hope it doesn’t take too long…) Open your eyes and pick one word that stands out to you, either in your mind or a word you see on the page that jumps out and grabs your immediate attention.

Was it happy, serious, exciting or did it give you a blah feeling and make you want to hit the back button in your browser?

Did it explain what your site was about in an instant or did you have to search around for clues?

Clear your browser cache and reload your page. See how long load time is for the new un-primed user. It can be easy to forget what load time you are have with when you have been working with cached assets.

Slow page rendering today is typically caused by server delays or overly fancy page widgets, not by big images, however, users still hate slow sites. For today’s wireline users delay in load times is not an issue, though images can still cause delays on mobile devices.

Screen shot your page and import into Photoshop and convert the image to black and white. Seeing a page without the distractions of color allows designers to easily focus on the spacing between elements and type on the page. White space is very important to better help the user ‘digest’ and take in various elements (calls to action) without feeling slammed or overwhelmed.

Try now and squint your eyes and view the page. The page will become blurry, note how your eyes travel along the elements and see how your brain is trying to reason the information as it seeks out areas of contrast.

Your page should have some good contrast within the various sections and your eyes will want to naturally go to these areas. Contrasting elements is a good thing, however, white text on black background is a bad way to create contrast since it causes eyes to strain harder than necessary. Therefore keep the content readable if you want visitors to stay on the site.

Load up your page and scan it for a maximum of 3 seconds. Now write down 3 things that you can remember. This will force you to take in only the most relevant information, and this information should be the same as the call’s to action or main points you want the user to take away.

Our brains are able to hold only so much in short term memory, most people will not be patient to continue reading- thats when the browser back button gets hit or the user will click to learn more if the information or hook is appealing. Make these three elements or ‘things’ count- this is where the user experience begins.

In most cultures a diagonal scan from top left to bottom right is the direction the eye is trained to read information. However new studies in eye tracking have found that, “…users often read Web pages in an F-shaped pattern: two horizontal stripes followed by a vertical stripe”.

Load up your page and start from the top left and scan across and then down along the left side of the page to the bottom, make sure that the information is presented in this order and remains clear and logical or if your purpose is something different and unorthodox or experimental it still will be useful to know what the standards of a typical user viewing your page is.

People that read every word on your page are few and far between, however some will. They will read the third word much less often than the first two in every line so use headers, subheads, bolding and bullet points when necessary.

Type in your website URL and use these tips to evaluate your page in less than 15 seconds- after all the average user is giving your page that much time or less before they decide whether it is worth their time to proceed or retreat. Learning to read and objectively critique your website is a necessary skill to hone.

When you are able to successfully read and evaluate your site you begin to see through the eyes of the user and enrich their experience.

Recently WordPress has introduced the PuSHPress plugin, which adds the PuSH hub to your blog.  So what does that mean for you? Simply by installing this plugin you’re opening up your blog to get indexed almost instantaneously by Google Search, and picked up by other services, such as Google Reader, Netvibes, FriendFeed, and many others. New sites are starting to use this protocol every day. So every time you publish a new blog post it can be picked up in real time by all these websites. Best of all, there is nothing to configure. Just simply install the plugin and it works.

So, if you have a WordPress blog, or a developer who builds these sites, adding the PuSHPress plugin seems to be a must nowadays. Perhaps it will become a permanent part of WordPress in later version. In the future, this protocol may be used by countless applications that we cannot yet imagine. If you run a custom built blog, check out the Google’s code page on how to add the PuSH protocol to your website.

Don’t forget to follow 10e20 on Twitter and subscribe to our RSS feed.