Ryan Fitzer

Hyphen, CamelCase, or Underscore

My choice of word combination patterns depends on the language. I initially tried to use a one-size-fits-all approach, but as my projects became more complex with multiple languages, it got really annoying when the pattern did not match the language. The old standby argument of “readability” quickly loses its validity when you’re dealing with code. For instance, PHP can contain javascript, html and css and uses underscores for functions. Depending on your text editor syntax hi-lighting, a javascript function (camelCase) could use the same coloring as a PHP function (underscore). Since you can’t depend on color alone, using each language’s pattern enables you to immediately know the difference.

There will always be edge cases (PHP uses CamelCase for classes), but I find that sticking with each language’s word combination patterns make for the least friction possible.

With that said, here are my current choices:

PHP
Variable: underscore
Function: underscore
Class: CamelCase

Javascript
Variable: camelCase
Function: camelCase
Constructor: CamelCase

CSS
Class: hyphen
ID: hyphen

HTML
Custom Attributes: hyphen

With html, the data- prefix is one defense, even though attributes like tabindex differ. Also, an underscore is technically meant to augment a letter or word, while a hyphen is used to separate words or syllables.

Regular Expression engines use the same characterizations.

For example, using the text:

some-word some_word

with the regex matching pattern:

\b\w+\b

the resulting array of matches is:

[0] => some
[1] => word
[2] => some_word

This may seem like I’m over-thinking things, but like I said, I want the least amount of friction when I work.

To Be, or Not to Be, an Anchor

In reading Chris Coyier’s response to a reader’s question on when to choose an anchor element over some other element when creating javascript-driven experiences, I realized that only recently did I form a concrete opinion on the matter. My response originally started as a comment on Coyier’s post, but quickly turned into a full post of its own.

Here’s the part of Chris’s response with which I identified most:

If the app is totally JavaScript dependent all behavior is attached via JavaScript, I guess it doesn’t really matter what element you use.

Until recently, I would have given the same answer. For the past year and a half I’ve been part of a large team working on the rewrite of a major ecommerce site that required full accessibility for blind, low-vision and cognitively disabled users. Being a javascript-heavy UI, it required a lot more effort in discerning the semantics of an HTML element.

I plan on writing a lot more about that experience, but right now I want to respond specifically to the question of when to use an anchor element.

The reader says that he generally used the a tag liberally to represent an element as clickable.

In brief, that’s the safest choice. But the natural inclination of a developer (ideally) is to dig as deep as possible and make the most informed choice. After all, their the ones who have to support it when things get wonky.

If you decide on something other than an anchor though, just make sure the element you choose is accessible to keyboards and screen readers. Easy. Done.

Of course, it can be a lot more complicated than that. Anchor elements are natively focusable and screen readers provide functionality for navigating a page by its anchors. This allows to users to quickly scan the page via their keyboard. Visual users often (and understandably) take for granted their ability to visually scan a page since it’s a natural response and not specific to viewing a webpage. But, substituting a different element can require a lot more effort in facilitating a equal experience to non-visual users.

Using tabindex with a value of 0 on a non-natively focusable element will allow for the element to be navigated via the tab key, and in the order of the natural document flow. But the catch is that a screen reader will not include the element in its anchor shortcut feature. This may not be necessary if the the element’s purpose would not make sense outside of its surrounding context, like a tooltip, for example.

More importantly though, the screen reader will not speak the element as a link. Visual users employ visual clues to interpret actionable elements in a page. Screen readers rely on semantics. While a visual user can instantly recognize a button by its design, a screen reader can do so only if a button element is used.

Also, it’s good to understand that title attributes are not necessarily spoken when a screen reader user is focused on an element that contains one. The popular screen reader JAWS provides this as an op-in preference. So using a span as an actionable element will need both a title attribute and screen-reader-only text (off-screen) to communicate to the user the purpose of the element.

Ultimately, an anchor element provides users an actionable element that’s accepted as a means to navigate information. Regardless of whether the navigation happens via a full page refresh, asynchronously, or with javascript turned off, the underlying meaning remains the same. Using it liberally is a good choice.

Update: 8.24.2011

Regarding ARIA, support is getting better, but it’s still pretty spotty. In fact, I’ve had to remove ARIA attributes at times because of screen reader conflicts. It can also change how the user’s screen reader interacts with a page (Form and Application modes). This can be disorienting to a user who has yet to master the full feature set of their screen reader. But after reading Dave’s comment below, I figured I should give the link role a try. I use the role when it’s useful, but the link value is one I’ve never considered.

I used the following markup for my quick test:

<span id="link" role="link" tabindex="0">Test Link</span>

Surprisingly, JAWS 12 with IE8 spoke the element as a link. I was also able to navigate to it using the u key shortcut (navigates unvisited links). The v key did not register it as a visited link even though it had been clicked. That makes sense since there’s no href. Good to know.

Update: 11.8.2011

I’ve put up a page of various attempts to mimic links. Not exhaustive, but should be helpful in drawing general conclusions. I’ll add to it as I get more examples and time.

Application Shopping

I tend to get stuck in my computing habits during the year. So each December vacation (since last year anyway) I’ve taken to trying out new applications. Here’s the list (so far) for this year:

• TotalFinder

  Adds tabbing, docking, folders-on-top, and more to OSX’s native Finder.app.

  So far I love it. The docking feature (named “Visor” and not to be confused with their other app of the same name) allows for a Finder window to animate in/out with a hotkey (⌥` by default), or whenever I switch to the Finder app. And with tabs, I don’t have to manage 50 different Finder windows any longer.

  It’s priced reasonably at $15 and has a 14 day trial period. I’m sure I will be buying it.

• Visor

  I’ve been learning Git lately (github.com/ryanfitzer) which involves a lot of Terminal.app usage. Like TotalFinder, Visor allows you to dock Terminal to your screen and animate it in/out with a hotkey (^` by default).

  Free and open sourced at github.com/darwin/visor.

• XRefresh

  Refresh your page Firefox whenever a file changes. So, I give a path to my working directory (I use MAMP so it’s “/Applcations/MAMP/htdocs”) and whenever a file changes, Firefox simply refreshes. No more toggling back and forth between Textmate and Firefox, constantly hitting ⌘r to refresh the changes just made. Working with 2 monitors makes this even easier since I can have Textmate running on one and Firefox on another. I never have to toggle over to see my changes.

  It is composed of an addon to Firebug and Ruby Cocoa (has a native OSX installer). Start the server via the command line with xrefresh-server, open a new Firefox window and watch with wonderment.

  You can also set it to soft-refresh any css updates to avoid page reloads.

  It’s awesome, free and open sourced at github.com/darwin/xrefresh.

• Tower

  Since my Terminal skills (mostly it’s my typing skills) are pretty rough I thought I’d also try a GUI for Git. I use Versions for SVN and Tower has so far proven to be the equivalent for Git.

  It’s currently free and in beta, but it will be priced once they have a solid release. I’m sure I’ll buy it.

• Alfred

  Billed as a “productivity application for Mac OS X, which aims to save you time in searching your local computer and the web”. And that’s exactly what it is. I’ve used Quicksilver for years, but the original developer ceased updates a log time ago and the community has kept it (mostly) alive (you find a good build at github.com/tiennou/blacktree-alchemy).

  I new I’d eventually have to find a replacement and Andy Clarke posted about Alfred this week.

  It’s free and currently in beta. An intersting note on how they plan to make money giving it away for free their FAQ page states [emphasis mine]:

  “We can provide the Alfred core for free thanks to users who support it by purchasing the Powerpack. We also include affiliate codes in Amazon links“

  It’s a great model and I’m interested to see it how it scales. I might buy the Powerpack, but I want to get familiar with the Alfred core first.

If anyone has any other recommendations I’d love to hear it.

Two Sides to the Story of Support

Side one, the Developer

To the question:

“Do the thanks and appreciation go anywhere near compensating the constant e-mail asking for support? What inspires your desire to give without return?”

Alex King responded, in part, with this paragraph:

“In talking with other plugin developers, it seems fairly universal that the reward for a successful plugin is a deluge of support email that includes the worst kind of sense of entitlement, rudeness and ignorance. The community as a whole seems to expect to be able to pay nothing, yet received expert and individual help and support for free.”

Every time I’ve thought of releasing a plugin for WordPress (or jQuery), I’ve had to think through this same issue. It hasn’t yet stopped me from releasing a plugin (I still have yet to release any, but they’re in the works), but it definitely stakes a claim in the “How” of the decision making process.

So far I have yet to find a bulletproof solution. The 3 best options I’ve observed are:

1. Directing all support to the WordPress forums via tagging.
2. Directing all support to Alex King’s WordPress Help Center.
3. Create a subscription-based support structure as exemplified by Justin Tadlock’s ThemeHybrid and Ingenesis Limited’s Shopp Plugin.

Even with one (or all) of these strategies in place, there are still going to be issues. Mostly, that you’re not able to fully recoup your efforts managing support work (via payment and/or hours that could have been devoted to coding). Plus, it’s not really that enjoyable, for either party.

Side two, The User

As a WordPress user, relying on free plugins that provide little or no support can get frustrating very quickly. I started using WordPress in 2005 and later joined the community in 2006. Not long after, I realized that relying on the free, forum-based support model was unsustainable. As a result, I quickly began contracting developers to write plugins I needed.

Most users would be surprised to find that the cost of contracting a plugin is minimal, especially when compared against time spent in the forums asking and waiting for help. The range for a plugin (one that doesn’t need to reinvent the wheel) is around $100-$400. I realize this price range could be prohibitive depending on your financial status, but I wasn’t making much then (first job out of grad school and a heap of student loans).

To be sure, the forums are a great resource, staffed and frequented by a lot of excellent and helpful people. I owe them for a good bit of help and have contributed back over the years

Choosing a great developer is key. Their reputation and hourly rate isn’t necessarily indicative of your potential cost. Great developers work quickly and have a vault of stored solutions they’ve developed over the years that will directly benefit your project’s budget. An inexperienced developer charging half the hourly rate may take 4x as long to complete the job. Not to mention that the code quality may have you needing frequent fixes and upgrades as WordPress evolves.

A few points in support of my opinion:

• They’re normally willing to give you a flat rate. This avoids any surprise overages.
• They’ll usually provide free support, especially if they feel it was their mistake or that they could have written the code to be more forgiving of certain edge cases.
• They tend quote lower if your idea presents good challenge. Developers love to be challenged.
• They usually will not charge for time spent learning something needed to code your solution.

Regarding choosing a great developer, start by contacting the most prominent names in the plugin community. I’ve never had to go further than contacting 3 people for a given project. The best ones are always busy, but if your schedule is flexible you’ll have more luck.

Small disclaimer, I am currently using Alex King’s WordPress Help Center for 2 large pieces of client work.

Phone Screens Using Skype

In the limited amount of phone screens I’ve done this sounds like it would have helped.

The biggest problem with doing technical interviews over the phone is that when you ask hard questions, the subject of the interview has to think about their answer, and may even need to write things down to get their answer together. When you’re talking on the phone, nothing is conveyed. There’s an awkward silence punctuated by the interviewer letting the interviewee know that it’s OK that they’re not talking while they think about it. People get more nervous, and I think it hurts the quality of their answers.

Interviewing over Skype

Using jQuery’s queue(), dequeue() and delay() Methods

These methods were very confusing to me so I decided to do some demystification and see what the hell was going on. jQuery’s documentation sets them up as methods related to the effects api. By default this is true, but I found this little misleading.

queue() / dequeue(), in short, allows you to create a queue of functions to be executed on the matched element(s) and then execute them in order.

delay() allows you to create a delay between functions in the queue.

None of the functions are run until the dequeue() method is run. This could be a click event, for instance.

Take for instance the following code:

$(document).ready(function() {

	// cache the body element
	var body = $('body');

	/*
	  Create a "bodyQueue" queue for the body element and add a function into it.
	  After this funnction runs it will delay the "bodyQueue" queue by 5 seconds.
          None of the functions are run until an event triggers the dequeue() method.
          This event is defined at the end using a click on the body.
	*/
	body.queue('bodyQueue', function(){ 
	    console.log('1st function. Next one is delayed by 5 seconds');
	    $(this).dequeue('bodyQueue');
	}).delay(5000, 'bodyQueue');

	// Add another
	body.queue('bodyQueue', function(){ 
	    console.log('2nd function (delayed 5 seconds)');
	    $(this).dequeue('bodyQueue');
	});

	// Add another
	body.queue('bodyQueue', function(){ 
	    console.log('3rd function');
	    $(this).dequeue('bodyQueue');			
	});

	// Add another
	body.queue('bodyQueue', function(){ 
	    console.log('4th function');
	    $(this).dequeue('bodyQueue');
	});

	/*
	  Add another and delay the "bodyQueue" queue by 5 seconds.
	*/
	body.queue('bodyQueue', function(){ 
	    console.log('5th function. Next one is delayed by 5 seconds');
	    $(this).dequeue('bodyQueue');
	}).delay(5000, 'bodyQueue');

	// Add the last one
	body.queue('bodyQueue', function(){ 
	    console.log('6th function (delayed 5 seconds)');
	});

	// Show the queued functions when the page loads
	var queue = body.queue('bodyQueue');                               
	console.log('There are ' + queue.length + ' functions left in the "bodyQueue" queue:');
	console.log(body.queue('bodyQueue'));

	// Add an event to fire the "bodyQueue" queue
	body.click(function(){

	    // Run everything in the "bodyQueue" queue
	    body.dequeue('bodyQueue');

	});

});

What I’ve defined here is a queue with the name bodyQueue, attached it to the body element and added a series of functions. When the body element registers a click event, the callback runs body.dequeue('bodyQueue'), firing the queued functions in bodyQueue.

View the demo. Make sure you run it in Firefox with the Firebug console open to view the feedback.

Resources:

jQuery for Designers | API: queue & dequeue

jQuery in Action 2nd edition: Queuing functions for execution

List of Computer Term Etymologies from A-Z

C++

C++ creator Bjarne Stroustrup called his new language “C with Classes” and then “new C”. Because of which the original C began to be called “old C” which was considered insulting to the C community. At this time Rick Mascitti suggested the name C++ as a successor to C. In C the ‘++’ operator increments the value of the variable it is appended to, thus C++ would increment the value of C.

A lot of interesting back-stories.