When building WordPress sites, I’ve often been in need of adding a call to action with a striking appearance into the site. Working by myself, that’s really no problem – but when it needs to be added into client-created posts and Pages, it can get to be a hassle — and cause long-term problems.

It’s not really effective or efficient to teach all the intricacies of HTML to every client. If you’ve created a cool CTA format which requires specific HTML you also want to make sure that this is as easy as possible for your client to enter into their post.

The easiest way to do this, in my experience, is by adding a simple shortcode, accessible using the quicktags bar in the WordPress HTML editor. (Since I care about HTML quality, I prefer to either disable the Visual editor or at least strongly discourage it’s use.)

The WordPress API makes it shockingly easy to set all this up.

First, we’ll define our Call to action shortcode:

1

add_shortcode('cta','my_cta');

Short and sweet – the first argument is your shortcode itself — with ‘cta’ defined, you’ll used [cta] as your shortcode. Next, we’ll define the function which will handle the shortcode.

2
3
4
5
6
7
8
9
10
11

function my_cta($atts, $content='') {
	extract(shortcode_atts(array(
				'class'=>'my-cta'
			), $atts));
	$output = '';
	if ( $content != '' ) {
		$output = "<div class='cta $class'><p>$content</p></div>";
	}
	return $output;
}

The arguments accepted by the ‘my_cta’ function are the attributes of the shortcode, as assigned in the extracted array and the content enclosed by the shortcode. This particular function is designed to accept one shortcode parameter; and not to output anything if there’s no enclosed body. The usage of the shortcode is like this:

[cta class="buy-now"]Buy my awesome widgets today![/cta]

The output would be:

<div class='cta buy-now'><p>Buy my awesome widgets today!</p></div>

Want to add another parameter to the shortcode? It’s easy — just add another value into the array of parameters.

Finally, we want to add the quicktag — so here it is:

15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

add_action('admin_footer','add_quicktags');
 
function add_quicktags() { ?>
<script type="text/javascript" charset="utf-8">
/* Adding Quicktag buttons (WP ver. 3.3+)
* - Button HTML ID (required)
* - Button display, value="" attribute (required)
* - Opening Tag (required)
* - Closing Tag (required)
* - Access key, accesskey="" attribute for the button (optional)
* - Title, title="" attribute (optional)
*/
QTags.addButton( 'aq_cta', 'CTA', '[cta class=""]', '[/cta]', '', 'CTA' );
</script>
<?php }

Only two pieces to this code, as well: an action added to the footer of your admin pages, and a function which inserts a new quicktag. Need to add multiple quicktags? Just add each one on a new line – there’s no need to add additional actions or additional scripts.

And here’s the whole thing — you can just drop the entire block of code into your theme’s functions.php file and everything here will be available immediately.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

add_shortcode('cta','my_cta');
 
function my_cta($atts, $content='') {
	extract(shortcode_atts(array(
				'class'=>'my-cta'
			), $atts));
	$output = '';
	if ( $content != '' ) {
		$output = "<div class='$class'><p>$content</p></div>";
	}
	return $output;
}
 
// Add buttons to html editor
add_action('admin_footer','add_quicktags');
 
function add_quicktags() {  ?>
<script type="text/javascript" charset="utf-8">
/* Adding Quicktag buttons (WP ver. 3.3+)
* - Button HTML ID (required)
* - Button display, value="" attribute (required)
* - Opening Tag (required)
* - Closing Tag (required)
* - Access key, accesskey="" attribute for the button (optional)
* - Title, title="" attribute (optional)
*/
QTags.addButton( 'aq_cta', 'CTA', '[cta class=""]', '[/cta]', '', 'CTA' );
</script>
<?php
}

The whole thing is only 30 lines of code – including 9 lines of comments.

One of the main reasons for using a content management system (CMS) is that it can provide great advantages for future growth. Having the easy ability to extend your software to create new types of documents (as with WordPress’ custom post types), or to simply add new pages and new features without needing to scrap everything you currently have is a huge advantage.

However, much of that advantage can be lost through poor planning.

If you have any thoughts — at all — that you might want to add additional content to your web site in the future, it’s really not a bad idea to start planning right away when you’re building your web site. A little forethought now can save a lot of trouble down the road.

It’s not necessarily the case that your problem will be absolutely and insurmountably limiting — in fact, that’s extremely unlikely. It is very likely that it will be an inconvenience which will cost you time and money.

For example, let’s think about the most basic key element of your web site: the navigation. If you’re making changes to your web site which included adding, re-naming, or removing documents, you’re going to be making changes to the main navigation. With that in mind, does it make more sense to take the CMS navigation and style it to do what you need, or to remove it and replace it with a static menu that looks like you want it to?

Realistically, you can probably have it both ways — in my experience, a skilled web developer can take CMS output and make it look however you want. But I’ve certainly encountered many circumstances where that simply wasn’t what was done — which made later changes significantly harder than they needed to be.

This is just intended to be a quick post, so I’m not going to go into extensive details on all the possible ways that you can fail to plan for future changes on a web site — but I do want to make a few quick points:

• Unless you’re planning on your business failing, you should always assume that your web site will grow and change.
• Your web site will never be finished. It is a living document.
• You should always be prepared to simplify. Change is not always additive. Removing the right things can be a huge benefit.
• While building a new web site, it’s not at all unreasonable to ask your developer how much work it would be to change “x”, where “x” is something you may want to do next year. But it’s probably better to find out even sooner.

However much planning you do, not every change will be quick and easy. However, even though a complete redesign will always be a lot of work, adding a new page shouldn’t be.

I’m a firm believer that the first step to creating effective accessible web sites is to understand the nature of disability. Learning all the technological elements which can affect that accessibility is also necessary, but if you don’t understand why you’re employing the technology, you’re far more likely to make simple but costly mistakes.

My latest article, 10 Common Developer Mistakes, published at Ecommerce Developer, covers examples of some of those still-common mistakes which are fundamentally the result of a failure to understand how other people perceive and interact with your product.

What makes a web site inaccessible is your fault: your web site is not inaccessible because your visitor has a disability, it’s inaccessible because you have placed barriers on the site. These barriers are caused by a failure to understand how other people perceive or interact differently from yourself.

A self-focused perception of the world can be very damaging to accessibility or to usability. It’s not that you can’t build a great and even successful web site while primarily thinking of yourself as the user; but your site’s ability to cope with the needs and expectations of other users is greatly reduced if you aren’t able to understand how other people will interact with your web site.

Yes, that does say HTML 4 in the title. This is not an article about HTML 5, or, indeed, about anything which is at all new. But it’s not just new technology which needs discussion in the web development sphere!

It’s sometimes hard to remember that HTML 5 is still not in common use — and that writing about HTML 5 is something which almost exclusively targets forward-thinking and experienced web developers. HTML 4 is still in widespread use across the web. If you’re looking at volume, HTML 4.01 and XHTML 1.0 cover most of the web site editing by webmasters, internet entrepreneurs, content management systems, or on personal sites.

But, more importantly, the internet continues to be littered with tutorials on how to abuse HTML.

If you look for HTML tutorials, you will primarily find fair and reasonable articles on standards-based usage. This is good. You will not, however, exclusively find tutorials which exhibit best practices in front-end development. This is, in part, the fault of an un-revised web: the well-reasoned article you wrote in 1998 may still be present, exhibiting years of inbound links and an honest but obsolete point of view. To the undiscerning reader, the authority of your article may be more apparent than it’s obsolescence.

I have mixed feelings about the idea of deprecating web content. There’s a part of me which is hesitant to edit the past by deleting and redirecting from older articles. After all, this isn’t done in print materials — if a volume is edited and re-released, the prior version is still available. In fact, the prior versions won’t even have any reference of any kind to let you know that they’ve been updated! The web has the power to avoid that problem entirely: in theory, you can delete, revise, or redirect away from any obsolete article on the web, making it impossible for any new explorer to come across out-dated material.

In practice, however, that doesn’t always happen. The best publications focus (as they should) on producing quality new content, and let their archives stand. While this means that they retain an honest history of their publishing, it also means that authoritative publications may still be promoting outdated ideas.

Today, for example, I ran across a web site which had a professional-looking design (albeit rather generic) and offered a prominent section of HTML tutorials. The first article in the set of tutorials was discussing how to use the font element to change the size, color, and font used in your text.

It even used Comic Sans as the example for an alternate font to use. Seriously.

For obvious reasons, I’m not actually linking to this site — the whole point of my article is to try and avoid the promotion of outdated material, after all.

Now, to me, it’s fairly apparent that this article is sitting here pretty much as advertising fodder. The site isn’t one which has anything like a prominent position in results for HTML tutorial, or is a place somebody would be expected to land when looking for an HTML tutorial. But it’s there, and somebody has undoubtedly made use of it.

Is the article above a representative example?

In point of fact, a lot of web publications have behaved moderately responsibly about promoting better practices in web development. However, the actual results you’ll find in a search are all over the map — and examples like what I cited above are definitely present. In an example search for “html tutorial change font color”, among the 9 relevant results in the the top 10 included:

• 3 sites which mentioned that the font element had been deprecated;
• 5 sites which suggested the use of stylesheets instead;
• 3 sites which linked to a tutorial page on Cascading Style Sheets;
• 3 sites which linked to a tutorial page on adjusting fonts with Cascading Style Sheets;
• 0 sites which had removed the information on changing font size with the font element;
• 4 sites which did none of these things, and recommended use of the font element whole-heartedly;

Interestingly, not one of the results was exclusively a discussion of changing font color using CSS. None of them. In fact, only one of these articles even included information on changing colors with CSS on the page, and the example provided in that article only pertained to changing the colors of of the anchor element. This very fact should make it evident that people searching for HTML information are still very likely to come across bad information.

It’s not 1998 anymore, but 1998′s HTML tutorials are still haunting us.

It’s clear from examining the search results that the larger players in the tutorial realm (Tizag.com and W3schools.com, for example) have done some due diligence in updating their articles, which is good. However, they could do better.

The Conclusion

So, I get back to my original point. It’s still important to talk about older technology: it’s still relevant to write or promote articles which offer tutorials on simple tasks, like changing font color using CSS or properly forming an unordered list. The reason it’s relevant is because the internet knowledge base is polluted — those who are in control of outdated material should take responsibility for updating their information, ideally, but we don’t all have that power. The best we can do is continue to promote best practices in all areas.

If you think about it, a significant part of web site updating is done by non-experts: the person tasked with maintaining the web site in a small business may not be at all knowledgeable. The beginning blogger may not know anything about HTML. Their learning will still come through basic searches, starting from a task-oriented question which is probably not technology specific. Those are people we need to reach if we seriously want to improve the quality of HTML on the internet.

Even though many elements of HTML 5 have only limited application at this time due to lacking browser support, there’s little reason not to make use of them. The design of the markup language is intended to minimize dependence on user agents, failing invisibly if the browser doesn’t offer that feature, which helps encourage early use of new elements.

Of course, the lack of support does have some consequences. We can’t just go out writing HTML 5 without having significant awareness of this lack of native support — we have to compensate.

Nonetheless, being able to incorporate great new elements like figure, progress, meter, nav to improve semantics or browser capabilities including content prefetching to provide a faster, more seamless experience for users is actually pretty exciting.

HTML5 Datetime input in Opera 10.53

But new input types…cold shivers.

Sadly, they’re also one of the less useful elements at the moment. Until support is available in browsers, they’ll simply fall back to a text field, unless supplemented by scripting to customize their behavior. But hey — easy upgrade, right?

From an accessibility perspective, this is fabulous news. Or rather, potentially fabulous news. These new input types — including date formats, time formats, numbers, ranges, and colors — are intended to provide user-friendly and accessibility-enabled interfaces for inputting these kinds of custom data. Ultimately, they’ll provide replacements (or fallbacks) to the innumerable JavaScripted widgets used to create date input or color selectors. Users, instead of encountering a different style of calendar every time they need to enter a date, could have a consistent user experience. Having the behavior built directly into the browser, and tied from there directly into any accessibility software in use offers a hugely more dependable experience for users of assistive technology.

Now, this all depends on several factors: vendor implementations need to meet user agent accessibility guidelines; interfaces between browsers need to be consistent; and, of course, the attribute values need to be implemented by enough browsers to make their use truly valuable!

Today, support is pretty limited. You can take a look at Roger Johansson’s HTML 5 input type test page and see whether your current browser supports any of them. If you’re using recent versions of Opera or Safari, the answer will be yes — otherwise, you won’t be seeing very much of interest for a while.

But you can implement these input types today.

All of these different input types fallback to a simple text input. If you’re using the HTML 5 doctype, there’s nothing stopping you from applying HTML 5 input types right now. Any browser that doesn’t support them will simply provide a field to enter plain text — so if you’re currently collecting email addresses in a text input (which seems pretty likely,) then you have no excuse not to change now. You may not see the benefits right away, but why wait? You’re not going to see any downsides, either.

Creating forms has long been a thorn in many a developer’s side. Dealing with how to best layout and collect date information, for example, is always a pain. Do you leave it as a simple text field, and have to deal with who-know-what kind of data received from the user? Do you use multiple select boxes, and force the user to walk through three or more fields just to enter the date? Do you use a JavaScript-based tool to provide a calendar, which may not have great accessibility, may behave strangely in some browsers, and may take a lot of development time to massage into providing the functionality you’re looking for?

Even when browser support for HTML 5 input types is fully available, it’s entirely possible that you’ll want to take the route to custom develop interfaces for various fields. However, unlike the past, you’ll only be needing to do this because something particularly unique is required for the project; for lower-budget projects, you can save a lot of labor and provide a solid interface just by using native features.

In June of 2010, Twitter will be permanently disabling basic authentication in favor of the OAuth protocol for authentication. For WordPress plugins which make use of the Twitter API, this is a change which will have significant repercussions.

The specific repercussion will be that every implementation of a plugin will need to be registered with Twitter as a separate application.

This means that the development of WP to Twitter will need to move in a slightly different direction. After pondering a bit, I’m left with four plausible choices:

1. Let the plugin die
2. Implement OAuth for the plugin
3. Build a pass-through web service to act as an application interface with Twitter
4. Associate with a 3rd party web service in the same capacity

These all have downsides, obviously — but I want to lay out my thoughts on each possibility and I’m asking for comments from the users of my plugin on their preference.

Death of WP to Twitter

Although it’s not really my favorite option, I have to acknowledge that it’s plausible. It’s certainly the easy answer — maintaining an even moderately popular WordPress plugin is a lot of free labor. I already spend more time on maintaining than I really should, from a financial perspective, and this may push it over the edge.

Implement OAuth

This would be a fair amount of work for me, although not insurmountable. The real downside to it would be how much work it would be for users — every one of you would have to register one application with Twitter for every site where you installed the plugin. With one site, this may not be a big deal — but I know it could be a real pain for people with more than that.

It’s not without some potential advantages, of course – when you’re registering your own application, you could customize the application name, the home URL for the application, etc.

Build a pass-through service

One way around the Oauth mess is for me to build a separate service which would handle actually connecting to Twitter. WP to Twitter would authenticate with that service, and pass the post off to Twitter. Again, this would be a lot of work — but, more significantly, it would involve some definite expenses.

I’ve been happy to maintain this plugin for not-much-better than free, but when it comes to incurring expenses, I start to feel a bit unexcited. It’s not like WP to Twitter is a commercially viable business, and I have expectations of profit from it — but I’d prefer not to find myself going into the hole because of it. I’d probably need to see an increase in donations to make this feasible.

Use a 3rd Party Service

Obviously, if I can build a service to connect with Twitter, so can somebody else. This is almost certainly the easiest solution which keeps the plugin usable — but it does mean creating a dependency on a 3rd party to keep the plugin functioning. Depending on Twitter is just natural; obviously, if Twitter goes away, the point of the plugin is lost. Depending on somebody else is something I’m less certain of, on the whole. There’s a reason, after all, that the plugin allows for use of URLs without an external shortener.

Give me your thoughts

This is very important to me — I want to know what direction you’d like to see WP to Twitter go. Please let me know! Do you know another solution? Do tell!

And if there are no responses…well, that has a pretty obvious meaning as well.

A couple of weeks ago, I launched a WordPress Calendar plugin. Now, there are a *lot* of Calendar plugins available out there, so I’ll freely admit that my primary reason for doing this was to meet my own needs — and given the “profit margin” on writing WordPress plugins, that’s generally the best plan when writing one.

Interestingly, the most frequent complaints I’ve heard since launching it were in an area which I had considered to be the least important area of the plugin — what it looks like.

I only did minimal work in setting up the appearance for this plugin; checking whether it basically worked in the default WordPress themes and little else. My assumption was that if anybody needed the plugin, they’d just have to be prepared to customize it to meet their needs. There was no reasonable way I could set it up to mesh with all possible themes, after all!

But apparently, in order to have the plugin be generally accepted, people need it to have “a look.” Most advanced users will probably change it; but I clearly hadn’t considered the more beginner users, without sufficient CSS knowledge to readily customize the output.

What’s really interesting to me about this situation, however, is not whether the plugin is accepted, popular, or heavily designed; that’s just an example. I was intrigued to observe in my own development process an approach which almost entirely ignored what the product looked like. From start to finish, I was really thinking about whether the plugin produced well-structured HTML and whether the various functions involved in producing information worked well.

I just never thought about design. And why would I? If I can’t predict what context the plugin will be used in, why should I design it at all, beyond making the basic functionality clear?

It’s an interesting question; from my perspective, as a fairly advanced WordPress developer, I honestly prefer plugins I use to have absolutely minimal styles, and for me to be able to disable those styles at will so that I can replace them. However, WordPress has a very broad user base. Most of those millions of users probably expect that they can install a plugin and immediately make use of it — and any changing of colors or reskinning to better match their design is purely optional. For those users, I really should be providing something which can be immediately useful.

It actually does come down to usability: advanced users can do what they want with the calendar design regardless of how extensively I’ve set up styles. Beginning users, however, may not be able to fix anything that I’ve left unresolved, or not fully tested. In order to provide the best usability, I need to consider those users, as well.

Having determined that it does make sense to actually design the plugin’s output, but also knowing that there’s no reasonable way I can design it to match all themes, I do have to make a firm decision about what the basic color scheme for the plugin will be. Originally, I’d used a basic, Kubrick-derived color set. Now? Well, the sensible thing seems to be to consider branding; set it up using my own website’s color scheme. It may be subtle, but it will convey my identity, even without my name or URL. That seems worthwhile.

Guess I better get to work!