The lazy method we got away with before:

function abtcore_shortcode_button( $atts, $content = null ) {
	extract( shortcode_atts( array(
		'color' => 'blue'
	), $atts ) );
	return '<p>' . $content . '</p>';
}

add_shortcode( 'button', 'abtcore_shortcode_button' );

The better way that is now required by WordPress 3.3:

function abtcore_shortcode_button( $atts, $content = null ) {
	extract( shortcode_atts( array(
		'color' => 'blue'
	), $atts ) );
	return '<p>' . $content . '</p>';
}
add_action('init', 'abtcore_register_my_shortcodes', 100);
function abtcore_register_my_shortcodes() {
	add_shortcode( 'button', 'abtcore_shortcode_button' );
}

Notice the add_action() call on the ‘init’ on line 7. This will properly register your shortcode function when WordPress initiates.

I hope this helps.

It’s no secret, I love beer. When I’m not talking about web design, I’m talking about beer and my homebrewing hobby. So naturally, this is where my “water cooler discussions” usually end up. What I’ve found from these conversations is that I have a lot of co-workers that love beer too. If you weren’t aware, we have 3 homebrewers, 1 ex-commercial-brewer, and about 25 or more avid beer fans in our office.

Fanboys aside, designing a beer and the process of brewing is similar to the planning and developing of a website. Both industries have a handful of key ingredients and important factors:

1. The concept or idea
2. The purpose and end-goals
3. The foundation
4. The experience
5. The consumers and keeping them coming back

When these factors come together in harmony, we’re left with a product that makes both the brewer (or web designer and client) and the consumer equally happy. And, on the other end, if these factors don’t jive, we’re left with a sad product that doesn’t sell.

Photo by e_walk on Flickr

The Concept or Idea

In order to craft a great beer, you first need a solid idea. What kind of beer are people drinking? How saturated is the market? What kind of beer do I want to make? These are just some of the questions any product design phase. They’re necessary because they help you focus on your concept. Going too broad too soon could result in failure. So, we focus on what will work for now. Once we build up a following, then we can begin to introduce all those other ideas or recipes floating around in our head.

So, I’ve done my research and I’ve found that most people in Raleigh seem to like pale ales. There’s already a few local breweries that make this style. But, there’s room for competition since the demand is so high. Now that we have a style chosen for our flagship, it’s time to plan and test the recipe. We find some friends, invite them over, and have them taste our latest batch of beer. We might even submit our idea to a panel of experts looking for feedback. In the homebrew world, this panel of experts are judges at a local competition. Regardless, every person along the way helps us formalize our concept–making it stronger.

Then, we need a catchy name. The name needs to say it all. And, most of the time, it needs to not have been used before. We’ll call our pale ale “Crabtree Pale Ale.” This name not only suggests the hoppy and dry finish we’re going for, but it means something to my local market too. I can already picture the label.

The Planning and End-Goals

Fully understanding the purpose of your concept can help you derive your end-goals. And, properly planning this execution is vital to success. This would be like understanding and formulating your recipe to suit a particular beer category. What flavor, aroma, and texture components are necessary to the style? What ingredients are used to achieve this complexity? And, most importantly, what can we do to keep this product on or under budget without sacrificing quality?

We’re making a pale ale, so we need a final beer that is relatively clean, moderately hoppy or bitter, and maybe a touch citrusy. The final product should also be pale and clear. There’s a few malts that we can choose from to create the flavors we want, as well as, a whole-host of American hops that will fit the profile.

It’s no coincidence that planning and end-goals are so closely related to the concept. What you’ll find is that there’s a lot of reliance on, or blending of, each of these steps. This is necessary to achieve the best product possible. This is also why it’s important to have all the moving parts under one roof.

The Foundation

Arguably, the most important ingredient in beer is water. In fact, beer is comprised mostly of water. Therefore, water quality naturally plays the biggest part. Many brewers treat their water to achieve the profile appropriate for the beer style. Whether we want hard or soft water, it is much like choosing the right code base, e.g., .Net or PHP. Each has it’s own advantages and disadvantages. Water can accentuate hop flavor or malt flavors. It can affect the efficiency of our mash (similar to making tea with grain). And, if you’re like me, this complicated chemistry gives you a headache, much like the programming languages and networking/hosting required for making a website.

The quality and balance of your code and HTML is much like water in brewing. Bad code can really ruin a website, and chlorine can ruin a beer. Gross.

The Experience

The overall experience, or taste of the beer, is crafted in part by the water quality, as well as, the ingredients and techniques used during the brewing process. In web design, this crafting is done by our User Experience (UX) Designers. They’re major players throughout the entire life-cycle of the project. Everything that is done passes through their UX filter. Their chief concern is always how the end-user will experience and use the website. For beer, if a flavor component is off, the consumer will reject it because it doesn’t taste right or it is too hard to drink.

This “experience layer” in brewing has many moving parts. There’s the malt, the hops, the pH balance of the water, and the temperature control (at each step). And, if the style requests, a spice or adjunct may be in the mix.

Malt brings sweetness and potential alcohol. Hops brings bitterness or balance (it also preserves the beer). Chemicals in the water accentuate each of these flavors as well as improve the efficiency of the process. But, temperature control can easily become the biggest player in the result of the final product. I can add the right amount of hops, but if I mash too cool, then I won’t have enough residual sweetness to balance the beer. I’ll be left with a harsh, thin, liquid. Been there before.

This is much like adding lots of eye-candy, frills, and information to your site, only to find that you didn’t pay attention to what the users (not you) are looking for from your website. If the frills don’t help the experience, then don’t add them. And, like-wise, if all the moving parts parts (designers, developers, marketing, and UX) don’t come together in perfect harmony, something might break.

The experience is a double-edged sword. It’s all about balancing the frills and ingredients to achieve the perfect experience.

The Consumer and Keeping Them Coming Back

You may have noticed that I left one key ingredient out of my beer analogy so far. That is yeast. Yeast is our consumer. And, so is the actual consumer. But, to be fair, yeast is the first organism consuming our beer.

During the entire process, you’re attempting to make a sugary water extract, called wort, that will be like a Candy Land for these tiny single-celled creatures. Unfortunately, though, it’s not as simple as that. If you mash the malt too high, you’ll be left with an un-fermentable extract. Essentially, you’ve made a beer with too much sweetness. Or, a website with too many frills and not enough digestible substance. This could be too much content or, conversely, too much JavaScript fanciness hiding the lack of precision. We want those yeast cells to consume and multiply. We want them to have families that consume the beer too.

Another potential problem is not adding the right amount of yeast. This would be comparable to hitting the market without proper marketing. What happens? The fermentation happens too slow resulting in off-flavors. And, possibly, you end up with a stuck fermentation. In the product world, this is slow growing and painful return on investment. Or worse, no growth at all.

There’s lots of ways to keep the fermentation going, or entice the consumer. We could control the temperature, making sure it’s appropriate for growth. We could use the appropriate yeast and pitch the perfect amount of it. This is similar to choosing the right target audience and controlling the amount of marketing. During the products life, how much marketing are you investing into your product?

Or, if the style allows, stick the beer in the corner and allow it to open ferment at what ever temperature it gets in the room during the day. This would be like viral marketing–letting the consumer run with it! But, then again, it all comes back to the initial concept: what style or what am I selling? And, how do you market the product appropriately?

Final Product

Once the yeast has done it’s thing, you’ve got a tasty beverage waiting for you in the icebox. So, sit back, relax, and enjoy the product you’ve created. And, if you venture beyond the hobby, maybe it’ll make you lots of money one day. Cheers!

By the way, what’s your favorite beer?

However, when I was writing a function the other day, I came across a minor stumbling block in jQuery. I was trying to create universal “continue” buttons throughout some user-interface tabs and I realized I needed a specific method that isn’t part of the jQuery library; some way to determine the current index of the element I was on.

Having been to jQuery Docs several times, I didn’t recall ever seeing what I needed, but I was hoping I’d be lucky. Unfortunately, after a visit to the documentation, I found that I was right. There was no such method. Of course, the eq() method does exist, but that’s the direct opposite of what I was looking for—to move to a specific index position of the matched elements. Moreover, in using the eq() method you’d need to know which index you’d like to select!

The eq() selection concept is much like the built-in “select” parameter that you can pass through the UI Tabs method I was hoping to use. For instance:

	$tabs.tabs(‘select’, 1);

This will select the first tab in the set. So, if I had a continue button at the bottom of each tab panel how would I know how to select the very next tab? I could, of course, make a special case for every instance of a panel’s continue button, but that poses a problem with extensibility. What if we added more tabs? Plus, it’s just ugly code. The fault here is that you’d have to know what each tab is named and how they relate to one another—creating a problem if the tabs were ever re-organized.

Instead I’d need something a little more universal. I’d need a single function that would encompass all of the continue buttons and switch to the next tab based on its current index. But, as I discovered in the documentation, you can’t locate the current index with a simple method like eq().

With all of my struggles aside, the good news is that the round-about way of getting the current index position is really not all that difficult. After a few minutes of thought and some idea bouncing (off of the smarter programmers here in the office) we came to the conclusion that I could simply count how many elements there are before the tab I’m on using the prevAll() and length methods built-in to jQuery. Thus, if there were 2 previous elements, I must be at the third item. The selection looks something like:

	var $tabs = $(‘#tabs-area ul.ui-tabs-nav’).tabs({ fx: { opacity: ‘toggle’ } });

	$(‘#tabs-area a.tab-link’).click(function () {
    		currentIndex = $(this).parent().prevAll().length;
    		alert(currentIndex);
    		return false;
	});

Here I’m selecting the anchor elements with classes of “tab-link” which is what I called each “continue” button. When they’re clicked, I store the number of “ui-tabs-panels” before the current tab. Please note, that the parent() method is being used to traverse backwards to these “ui-tabs-panels.” You’re path may vary depending on your HTML markup.

Using “currentIndex” I can check if it is larger than the length of the tabs array (meaning I’m not on the last tab yet) to prevent any possible tab selection errors by trying to move past the last tab. Then I can use currentIndex to select the next tab. This would make our little function look like this now:

	var $tabs = $(‘#tabs-area ul.ui-tabs-nav’).tabs({ fx: { opacity: ‘toggle’ } });

	$(‘#tabs-area a.tab-link’).click(function () {
    		currentIndex = $(this).parent().prevAll().length;
    		if (currentIndex < $tabs.tabs(‘length’)) {
       			$tabs.tabs(‘select’, currentIndex);
    		}
    		return false;
	});

I also must mention that in this function I’m selecting currentIndex in the statement $tabs.tabs(‘select’, currentIndex);. This may be confusing since the way the array indices and the “select” parameter work are based on a zero beginning index. But, when length is calculated it starts with 1. So, there’s a bit of an “off-by-one-bug.” I can, of course, trim the length by 1 and adjust the if statement to be <=, but that would be equally confusing. Either way, rest assured that the currentIndex in the “select” statement will select the very next tab.

In closing, it is quite easy to determine the current index position of an element in jQuery without using any built-in methods. All you need to do is count:

	currentIndex = $(this).parent().prevAll().length;

This assignment is very easy to build upon (or adjust the index by subtracting 1—if you’re picky).

I realize some of my ideas may go beyond the so-called “scope” of the original intentions of CSS and HTML/XHTML. But my hope, like all “standardistas,” is to get a focused set of standards for all browsers to comply with (does such a Utopia exist?) and for these standards to give more power to semantic markup and provide more advantages to CSS.

I’ll begin with HTML first, since semantic markup is the most important:

1. Custom Elements

I’ve read some of the working draft for HTML 5 and I must say that I’m impressed with some of the ideas that have been added. It’s going to give more meaning to HTML code, which is precisely what web developers need! However, I did cringe at the proposed “header” and “footer” elements. I understand their purpose, but aren’t the words header and footer presentational? For instance, what if at first I designed the footer to be at the bottom of the document. In the markup, perhaps it is. But later (for some odd reason) the client decides he/she wants that info to be moved to the top? Would this still be considered the “footer?” I’m sure there are several sides to the argument, but I’ve also read accounts where people like Andy Clarke have proposed the same. Footers should be “siteinfo” and headers should be “branding” or “masthead.” In contrast, Dan Cederholm and Andy Budd still use “header” and “footer” on their personal sites. But regardless of who uses what, I still feel these names are presentational and HTML is for content not for its appearance or layout.

I really like most of the other elements like “menu,” “section,” “dialog,” “aside,” “datagrid,” etc. They really give more meaning to the markup in place of the generic div’s with id’s. This will definitely give more power to CSS and more meaning to the document at the same time. Specifically it allows you to separate your styles with semantic element names and giving them unique rules with really low specificity instead of making them arbitrary div’s. Simply put, this will give you more control with id’s when they’re needed.

But what I’m proposing is that instead of giving set element names that will always be debated on their semantic merit, why not give that power over to the developer? If a developer could declare his/her own elements in the head of the document, he/she could have more control. I envision it working something like this:

		<head>
			<elements type="elements/text">
				section : div;
				dialog : div;
				menu : ul;
				masthead : div;
				newelementname : baseelementbehavior;
			</elements>
		</head>

				

In this element named “elements” the code would be handled by the browser. It would read each line, separated by a semi-colon, and take note of the custom elements being declared and determine their base behavior off of the base element listed after the colon. For instance, the first custom item “section” would behave like a “div.” This would give ultimate control to the developer to make his/her document follow its purpose semantically. This will also open up the possibilities for more microformats! A developer could utilize this to create <tel> elements, <adr> elements, <product> elements, and more, replacing the annoying <div class=”product”> and more nested, loosely based “classitis.”

2. Definition List Item

I can’t recall where I saw the <di> element once, but I’ve been unable to relocate it through my web searches.XHTML 2′s working draft describes a definition list item, but I wonder why this element is still not supported well, if at all. And I didn’t see any proposed plans for it in the HTML 5 working drafts. I feel that this would be a good addition because it provides one more “hook” for styling and more meaning as well. The definition item would separate definition terms and their descriptions from others. If I was creating a list of definitions, each term and its description or descriptions should be separated logically from its siblings. Thus the <di> element would encase and separate each item.

3. CSS Snap Declaration

My third proposal is for a CSS 3 style declaration called “snap.” This can replace the need to use javascript to snap elements to non-parental elements. This “snapping” has been done via javascript on many old versions of dropdown menus. Now with CSS and better standards, the snap is no longer needed for menus. But the need for snap in other presentational ways is still warranted. What if I wanted to “snap” one element in the lower portion of the document to another element that was completely unrelated? I could simply add it to the style rule:

		#snapping-element {
			display: block;
			width: 300px;
			snap: #host-element;
			left: 0; top: 10px;
			…
		}
				

In this example, the element with the id “snapping-element” will be snapped to the element with the id of “host-element.” Host-element, however, probably should be positioned relative; and the snapping-element’s position will be based off host-element’s relative state. Much like how absolute works, except that absolute is limited to basing itself off of ancestral elements.

4. Column Hovers

Placing a hover on a table row is a cinch. But what if I wanted to create a triangulation effect for the rows and columns with a different hover state color? I can’t! I’ve seen others mention it in posts, but I haven’t seen any plans to integrate this into CSS. Why not? This would provide another layer of accessibility/legibility to users with a simple col:hover rule. Of course the colgroup elements must all be declared in order for this to work.

5. Javascript-type Psuedo-classes

My last proposal to CSS 3 is probably the most CSS-scope-defying of them all. What if there were more pseudo-classes available other than just visited, hover, active, focus, etc? Why not onclick? I realize focus is currently a bit of a Mozilla proprietary state, but it’s a really good one! If javascript already handles onmouseover (hover) and onblur and onfocus (focus), why not onclick?! Man would this be powerful! All javascript toggling could be handled in CSS! But this event catching is a bit more daring for CSS’s scope of just styling. But why not, eh?

Conclusion

Perhaps some of this has been mentioned before me. I’m not sure. If not, then I’m glad to be able to provide some recommendations. If so, I apologize for assuming credit, that’s not my intention. I do however feel that these would provide a lot more meaning to HTML 5 and more power and control for the visual and presentational experience to CSS 3.

Any comments, suggestions, critiques are happily welcomed. Just some food for thought.

Specificity Wars by Andy Clarke

I’m not writing this to take away from the brilliant explanations of Andy Clarke, Patrick Griffiths, Eric Meyer, or Molly E. Holzschlag, but to merely supplement their posts with, perhaps, another angle. Many people feel the need to re-explain this topic in layman’s terms rather than enduring W3C’s overly technical explanation about specificity.

What is specificity?

To be brief, it’s the applied calculation of the priorities of CSS selectors and how they cascade through a stylesheet. Simply put, selectors with a higher specificity will overrule other selectors in the cascading order.

How it works

There are two ways to determine specificity — the “right” way and the “quick and dirty” way. According to W3C, the specificity is officially calculated using four numbers concatenated, like: a, b, c, d . The “quick and dirty” technique is to assign values to each type of selector and add the values up. For example, general elements have a value of 1, classes have a value of 10, ID’s have a value of 100, and inline styles have a value of 1000. However, this value-based “quick addition” technique is a bit misleading because it presumes that 10 of any value will override the next highest selector. Following that logic if you have 10 ID’s in a style declaration those will override an inline style, because 10 ID’s are worth 100 x 10 which equals 1000 — inline styles being worth 1000. This statement is far from true. However, it can still be used as an easy way to get an idea of the specificity of a particular selector in a declaration; but it should never be fully relied upon.

The W3C states that Concatenating the four numbers a-b-c-d (in a number system with a large base) gives the specificity. This is the correct method to rely on. The reason is because it separates the values into 4 categories: a, b, c, & d. The variable a is reserved for the number of inline styles and has the highest priority. While b is for the number of ID’s, c is for the number of other attributes (including class, but not ID’s) and pseudo-classes, and d is the number of elements. This is the correct order of specificity and pseudo-elements are to be ignored.

Let’s focus on b and c since these are the subjects of confusion. ID selectors (b) are the most valuable asset to CSS, so they are given the second highest priority, next to inline styles (a). ID selectors are written with a # in front of the name given to the ID. So, #content is referencing <div id="content"> which has a value of 100 using the “quick and dirty” method. These selectors, like all selectors, can be used in combination with any other selectors. For instance, #main-area #content would add up to 200.

Class selectors and other attribute selectors are assigned the variable c. These are each given a value of 10 using the “quick and dirty” method. Class selectors are denoted with a dot (.) before the name of the class, like .box. Attribute selectors are declared with the attribute name inside a set of brackets — a[rel="friend"]. It is not necessary to include the value of the attribute. Additionally, the = can be replaced with ~=, *=, ^=, or $= depending on how you’re equating the value. A better concept of these equations can be found on 456 Berea St’s CSS 3 selectors explained post.

Note: Attribute selectors of CSS 2.1 are supported by most modern browsers, and when I say modern browsers I do not mean Internet Explorer 6.

Initially what confused me about attribute selectors and their specificity was whether or not using class= or id= in the attribute selector made it behave like the # (ID) or . (class) of its CSS 2 predecessors. After doing some testing and reading, I found that the attribute selector has the exact same specificity as the class selector (.), regardless of whether it says id= within its little brackets. It will always have a value of 10. Thus, div[id="content"] is less specific than div#content.

Here’s an easy way to visualize all of this (in a poorly misunderstood table element):

If you haven’t seen any specificity charts before I hope my interpretation helped explain it further. Be sure to check out the other explanations too, because Andy Clarke has an awesome example using siths from Star Wars. Maybe I’ll make a diagram of my own someday.

Apple understands usability better than most companies. If you review Apple’s product catalog you will find one thread of consistency – simplicity. Take a look at Apple’s iPod, their core colors are black and white, no obtrusive buttons or screws. One would wonder how it was even manufactured, seems as though the iPod was born that way. You are left with a colorful lcd screen and compass-style navigation wheel which you can control with one hand. Apple’s method to their madness is not to charge for what you don’t have but give you what you paid for – a simple way to navigate and listen to your music collection.

“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” — Antoine de Saint-Exupery

The main challenge between designer and client when the topic of usability comes up is education. There is a lot to consider when the melding of minds between design and client occurs – project requirements, likes and dislikes, site goals, conversions, call to actions, etc. All this must be accomplished while still maintaining the integrity of good design and ease of use. This is the real challenge, it’s not like trying to fit a square peg into a round hole, but it’s pretty darn close. Here is how designers are separated from the pack. Give them what they want while still keeping people coming back.

Eric Burke, stuffthathappens.com, created a satiric image that I feel really illustrates this concept of “less is more” approach.

Consider the model that Apple and Google have taken. Create simple products so you don’t overwhelm your target audience. Or do as most sites do, add options and features that no one looks at so the only percentage that goes up is your bounce rate.