The Proposed WordPress Developer Code Of Honour

Over at WPShout Fred Meyer has published a proposed Code Of Honour for WordPress developers.

The article is address to developers of SME websites and is addressed to both developers and their clients. It addresses problems with SME website projects and puts forth a solution in the form of the code.

It’s a reasonably long read. And if you are either a business owner about to engage in a web project, or if you are web developer who builds out projects single-handedly – then it’s well worth reading.

Immediate Thoughts

After reading the code I had some immediate thoughts: the article and the post itself is timely. In fact, it’s overdue: many good developers have the experience of being pulled into an SME project to discover that the previous developer didn’t know his stuff. Consequently budget gets sucked into cleaning up unholy messes.

Web development professionals aren’t just in it for the money. We want our clients to be happy. We want the projects we work on to succeed. We want to create websites to return an investment. We don’t like seeing clients in pain because the previous team didn’t know what they were doing.

The code requests the developers use professional best practices. Best practices in technically building the project, and in client communication. It requests that developers be accountable to their clients.

The very existence of the code also creates a condition of accountability: accountability to a community that declares itself for the code.

I like this.

Unexpected Controversy

I’ve been in private discussions with people who are in the business of delivering web projects for SME’s. These people are both solo developers and agency owners. These people are good providers and all have records of delivering great projects and making their clients happy.

They largely agree in principle with the code itself. But to my surprise they had two objections to the article itself.

“The problem isn’t the developer. It’s the client”

According to this critique, projects don’t fail because of the developers own weaknesses. They fail because the of faults on the clients end.

There’s some truth to this. Some projects do indeed fail because the client makes unreasonable demands, micromanages the project and doesn’t trust the authority of the agency or the developer. Clients sometimes don’t understand the work that’s involved, and make unreasonable demands. Often clients fail to honour the process by which agencies and developers create good results.

I think that agencies can have good reasons for thinking these things. But I also think that ultimately it’s the responsibility of the agency or the developer to guide the client on these matters. Or to simply turn away clients that won’t work within the process of the agency.

Besides, in all fairness Fred links to content about how to avoid bad clients. And how to be a great client.

“The article is elitist. The author favours programmers over non-programmers”

Now as I mentioned above, the people I heard this critique from have histories of delivering great work. They’ve built many projects that make their clients money. I believe that these people are non-programmers themselves. And they seem to feel that the article shows a kind of hidden contempt for non-programmers the deliver WordPress projects.

But personally I think the critique is baseless.

Someone responsible for delivering an SME WordPress website can deliver without knowing how to program. They can simply hire a programmer.

But the reality is that the better someone knows how to program, and specifically how to program within the WordPress world, then they are in a better position to quickly solve the kind of problems that will come up within the project.

Non-programmers who build websites are spoilt silly by the WordPress world: there are extensions for pretty much everything. From creating real-estate listings, to assessing your content for search engine visibility. There are plugins that promise to make your website faster. Plugins exist for layout out page, for capturing leads, for social media…

There’s a huge amount that you can done without being able to program.

But ultimately if a provider doesn’t understand the underlying technologies then they are disadvantaged.

Understanding the underlying technology brings some significant advantages. Here are just a few.

A programmer can anticipate problems before they happen
A programmer can often solve these problems faster
Cost estimates for projects will be more accurate
When bugs rise from common extensions, programmers can find the cause
… and probably fix them

To clarify: non-programmers can be competent and even excellent at delivering satisfying projects. And sometimes programmers don’t have non-programming skills that great results require.

But personally I think that everyone who is in the business of delivering an SME web project should at least be learning the underlying technologies.

My Endorsement

Personally I endorse Fred’s Code Of Honour 100%. At this point I have zero reservations about it. If the code was “officially released” today in it’s current state then I would commit to it.

The “wild west” period of web contracting is coming to end. Even though cowboy agencies and developers still exist, their opportunities are fading.

Fred’s code is a an idea whose time has not only come: it may be overdue.

Speed Matters

Users of the web have ever-increasing expectations. These days users expect content to be delivered swiftly and smoothly, and with as few obstacles as possible. A slowdown measurable in microseconds can affect conversion rates and thus the profitibility of your website.

Google made speed an index ranking factor five years ago. Amazon discovered that a slowdown of 1 millisecond caused sales to drop immediately.

So if you want to keep visitors, improve your ranking and turn visitors into customers then you need your website to load fast and perform with excellence.

So how do you achieve this

Performance must be built in from the ground up

This is something that developers have know for a long time. If you have an existing site and you want it be faster, there are things that can be done. But if your foundations are poor then any improvements to speed and performance could be minimal. If you are starting a website from scratch then you are in a great position: you can make decisions right from the beginning that will assure great performance.

Start With Solid Hosting

“Pay peanuts, get monkeys” applies here. Hosting is a commodity, and the cheaper you go the less performance you can expect. Furthermore, if you buy at the bottom of the market to get started with then you can expect trouble when attempting to migrate your site to a better host.

The solution here is to get hosting advice from someone with experience in the world of hosting.

Hosting is a complex world with many different types of hosts across many different vendors, including shops that offer hosting specifically for WordPress sites.

Use a well-engineered theme

Assuming that you are using WordPress then you need a theme that is built well.

Of the thousands of themes on the various marketplaces – many look great. The demos available through envato’s marketplaces or through the many theme shops will show themes that look great. But just because a theme looks great doesn’t mean that all is well under the hood.

Many themes come loaded with redundant, inefficient database calls, a zillion options which will go unused and poorly performing, poorly tested code. Showrooms are designed to make products look great. But only qualified programmers can tell what’s going on beneath the surface.

To get a performant theme you have three options:

Have a qualified programmer build your theme from scratch, choose a theme from a good theme shop, or have a qualified programmer choose your theme for you.

Themes to avoid

There are some very popular, very well-marketed themes that are just going to slow down your content delivery. Not everyone is going to like hearing this. But some very popular themes simply shouldn’t be used by people who are ambitious about their project.

Avoid any theme built with many options. One such popular theme is Avada. Its only one example. Such themes are built for all all possible scenarios, and finely tuned for nothing.

Optional: use a Content Distribution Network

Using a good CDN can really speed things up. But to get this advantage you need to have the foundations sorted first. The advantages of a CDN will be minimal if you haven’t got great hosting and a well-engineered theme. Paul Irish, a chief developer at Google has said “CDN’s are the gluten-free of the web” when talking a lack of solid foundations.

Cloudflare is a CDN offers a free level of service that includes some protection from DDOS attacks. It’s a great start. Amazon’s Cloudfront is a popular service that can store items of your content across it’s global network. There are many other such services.

Asset Management: minify images

This can be critical.

The file size of an image can be relatively independent of it’s visual quality. That is, you can have two versions of the same image on a screen. They can both look the same to the eye. But they can have very different filesizes. Your website should be using the version with a lower filesize.

A lower file size will result in faster delivery.

Before uploading images to your site: reduce the file size.

Photoshop has a filter for saving images for the web. So does Gimp. If you don’t have either of these programs then you can use an online service for reducing your image file sizes.

Use as few images as possible per page

You probably worked that out from reading the last point.

Images are important for web pages. Images should reinforce the message of the page. They can illustrating a point or draw the user to another related message. But the more images you have, the slower the page will be. Even if highly-compressed images are being delivered from CDN’s: more images makes for heavier pages.

Conclusion

Fine-tuning the speed and performance of website is something that developers are always working on. Every page should be built with speed as a consideration. Great developers have an arsenal of strategies and tactics to keep website performance as fast as possible. There are many things that site operators can do as well. But speed must be built in from the very foundations.

Wherein I compare those things called “frontend frameworks” and hopefully bring Bourbon to the attention of more developers.

Following is a light, comparative review of some frontend frameworks. I give a glimpse into the existing landscape.

Context: Bootstraps Dominance

Presently and for at least two years or so, the most popular “front-end framework” has been bootstrap. It’s everywhere. It’s an industry standard. Job postings all over the web ask for applicants to have “experience using bootstrap”, as if seasoned frontend developers don’t have skills that are transferable to any frontend framework.

Bootstrap has little appreciable competition for mindshare in the webdev world even though there are other frontend frameworks in existence. Zurbs’ Foundation is notable. It’s been around for a long time. It’s mature and people know about it. It’s thought of as “the alternative to bootstrap”.

Pros and (mostly) cons of Foundation

My opinion is conventional: that Bootstrap is easier to simply load and use, and that Foundation takes a little longer to learn. Where I’d stray from conventional opinion is that I don’t think that all bootstrap sites have to look the same. It depends how you use the framework.

I’ve enjoyed using Foundation in the past. But going back to it, I simply can’t tolerate it’s installation processes. There are three options and all of them are… a bit icky. In theory you can just download the library and pull Foundation components into your project. But it’s not easy to figure out. It’s undocumented. And the installation paths that are documented are done so lightly. You can beat through the thorny path if you are a seasoned Ruby developer. But there’s no sane reason for way you should have to be a seasoned Ruby developer if you just want to install some frontend components.

Foundation promises to make development faster. But the complicated magic dance required to actually get started using it annuls that promised benefit.

Newcomers based on Googles Material Design

Google Material Design is a pattern language for design. The purpose of which is to encourage UI designers to create beautiful interfaces by using taking improved metaphors for web design into the realm of responsive design.

Google supports its Material Design language with its Web Starter Kit.

I have yet to experiment with Web Starter Kit. But I’m looking forward to it. Another project is Material CSS. It’s a student project out of Carnegie Mellon University. There is also LumX, a toolkit that includes and is geared forAngular.js. I haven’t tried these either, but may well do so in the future. Obviously a huge amount of work has gone into them and they look… delicious.

Bourbon

Bourbon.io provides sets of mixins for sass. That’s all. It’s really that simple.

Like Foundation, you have to the gem installed. Unlike Foundation, the installation of the Bourbon gem doesn’t require the same tightrope-walk and chicken-sacrificing. Combined with it’s sub-projects neat, bitters and refills, it provides most every component that either Foundation or Bootstrap do. And some that they don’t.

I’ve been using bourbon for at longer then I recall and I’m surprised it’s not more popular. It’s dead easy to pull it into an existing project or start your own project around it. My initial attraction was that earlier versions of Bootstrap didn’t have integration with sass, so the only way to use bootstrap was to clutter up the DOM with nonsemantic markup. Bourbon Neat let me use a grid system without cluttering the DOM.

Bourbon itself provides a range of conveniences documented here. It’s sibling libraries, dependent on Bourbon provide a grid system, typography and a collection of compents like headers, footers, navigation bars and tab systems.

Bootstrap also has a sass version, but I’ve found it more difficult to install then Bourbon. With Bootstraps Sass library, you have to pull in the deps with bower. And to tidy your project up before deployment, you’d probably have to handcode a Grunt task to move your files to the right place.

You don’t have to do that work with Bourbon.

In conclusion, Bourbon is easier to install then Foundation but you aren’t compelled to build your whole app around it. It has pretty much all the tooling of either Foundation or Bootstrap, but it’s much easier to get started with and you probably won’t really lose anything.

I’ve created a new page outlining a conditional offer for consulting for community groups for reduced fees. If you are an under-resourced individual or a group in need of web development then get in touch.

The Context

Building a responsive site with wordpress.

The Problem

I have a loop that spits out posts. the site must be responsive. I must use markup to designate columns. However, simply taking the loop content and wrapping it in a div isn’t good enough. I need to intersperse the output of a loop with columnar markup. Say I want two columns, and I must divide the posts between two columns. I’ll have to “inject” markup into my loop output to create my ideal section of code. I could do this with js. But that’d kinda suck. I mean, I wouldn’t hold it against a dev to take the js approach. But I grimace at the thought.

A Hypothetical Solution

Lets get the loop content and put it into an array. Then we’ll split the original array into two “blocks”. We will then print these blocks, wrapping markup around them. That markup will be then targeted by CSS to create columns when the viewport width hits a target breakpoint.

Getting The Loop As An Array

Thanks to the magic powers of google I discovered get_posts. The first sentence of the doc tells us that we are on the right track: “The most appropriate use for get_posts is to create an array of posts…”. That’s great! From that point I can manipulate the array and do what I want. Here is where we can start.

 $args= array( 'post_type' => 'my_cpt' ) ;
 $posts_array = get_posts($args) ;

An Awesome Discovery

It turns out that putting the post output into an array gives us a lot of control over how we choose to publish the posts that we got. Most of the time a mixure of template tags and markup will do what we want. But with get_posts we can replace the usual approach with… anything we want.

If we know some basic PHP then we have a lot more control. Specifically, it helps to know how to do really basic object and array manipulation.

The logic I wanted to impliment was this:

For each post: for two particular custom fields: wrap the custom field in my markup.

And this is how I did it:

foreach ($posts_array as $o ) {
 // get the meta array for the current post
 $meta = get_post_meta( $o->ID ) ;

// get the quote
 echo "<blockquote><p>" . $meta['_cmb_testimonial_text']['0'] . "</p></blockquote>" ;
 // get the attribution
 echo "<p class='attribution'>" . $meta['_cmb_attribution']['0'] . "</p>" ;
 }

Viola! Post content! Now to generate my columnar markup!

Lets take the array, split it into two other arrays, and wrap the two output arrays in markup…

/*
 * how many posts do we put in the first column
 */
 $els = count($posts_array) ;
 $half = round(($els / 2 ));

$arrOne = array_slice($posts_array, 0, $half ) ;
 $arrTwo = array_slice($posts_array, $half) ;

/**
 * output first half of our testimonials
 */
?>
 <div id="stb-testimonials" class="group">
 <div class="testimonial-col col1">
 <?php
 foreach ($arrOne as $o ) {
 // get the meta array for the current post
 $meta = get_post_meta( $o->ID ) ;
 // get the quote
 echo "<blockquote><p>" . $meta['_cmb_testimonial_text']['0'] . "</p></blockquote>" ;
 // get the attribution
 echo "<p class='attribution'>" . $meta['_cmb_attribution']['0'] . "</p>" ;
 }
 ?>
 </div> <!-- ENDS testimonial-col col1 -->
 <?php
 /**
 * output second half of our testimonials
 */
 ?>
 <div class="testimonial-col col2">
 <?php
 foreach ($arrTwo as $o ) {
 // get the meta array for the current post
 $meta = get_post_meta( $o->ID ) ;
 // get the quote
 echo "<blockquote><p>" . $meta['_cmb_testimonial_text']['0'] . "</p></blockquote>" ;
 // get the attribution
 echo "<p class='attribution'>" . $meta['_cmb_attribution']['0'] . "</p>" ;
 }
 ?>
 </div> <!-- ENDS testimonial-col col2 -->
 </div>
<?php

Done.

The complete chunk of code is here. It’s part of a bundle of files that constitutes a plugin for publishing testimonials, and is in use on the Stalking The Boogeyman website. (I’m helping to maintain this beautiful site, which was built by Chris Van Patten for DRT Advertising). If anyone actually wants the full plugin, just ask me and I’ll put it on github.

Navigation

Category: coding