Quoted in “Fear of Accessibility”

My good friend Chris Jagers at Slideroom quoted me in his recent article Fear of Accessibility. It’s a great read.

The rest of the post is just as good.

Easy Syncing of GitHub Pages

I’ve started using GitHub more and more recently as I’m finding Git’s steep learning curve, as compared to SVN, outweighed by GitHub’s usefulness and flexibility. One of those factors is GitHub’s “Pages” feature. From the docs:

The GitHub Pages feature allows you to publish content to the web by simply pushing content to one of your GitHub hosted repositories.

For example, I’ve recently started a repo to begin adding the many miscellaneous tests, POCs and demos I create during the course of development. Instead of requiring someone to download the repo just to see the examples, I use GitHub Pages to host the rendered version (when applicable). The “Mimicking Links” page is the first one I’ve published.

GitHub makes this automatic when you create a branch of your master named gh-pages. Any time you push to gh-pages, the results are published. Easy enough, but I quickly realized that I needed a way to mirror all changes on master in gh-pages without constantly having to type:

git checkout gh-pages
git merge master
git push origin gh-pages
git checkout master

Some quick searching turned up Oli Studholme’s helpful post “GitHub Pages and deleting git’s master branch”. He outlines his own attempts (and suggestions from the comments) and what finally worked for him. Since he had more requirements (deleting the master branch), I wanted to post exactly what I’ve ended on.

First, create your local repo and add it to GitHub.

From the command line, navigate into the root of your repo and run following block of code as referenced in the “Project Pages” section of the GitHub Pages docs (make sure you have no changes waiting to be committed):

git symbolic-ref HEAD refs/heads/gh-pages
rm .git/index
git clean -fdx

Now that your working directory is clean, merge in the master branch and push gh-pages to GitHub:

git merge master
git push origin gh-pages

You can now visit the url http:username.github.com/yourRepo/ to view the results (the first push may take a little time to show your changes).

Now that your pages are in place, you’ll want to automate the merging[1] to gh-pages any changes you commit in master.

To do this, open the post-commit.sample file located in yourRepo/.git/hooks and replace its contents with the following, saving it as post-commit:

#!/bin/sh
# Mirror master in gh-pages
git checkout gh-pages
git merge master
git checkout master

This block will run after every commit you make to the master branch (you’ll see the output on the command line).

All that’s left to do is push both branches to GitHub any time you’ve made a commit:

git push --all

I’m still pretty new to Git/GitHub, so any suggestions or corrections are appreciated.


  1. Oli’s post suggests rebase, but I’m sticking with merge as I understand it better.  ↩

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.

My Alfred Custom Searches

I set up a page to share (and sync) some of the custom searches I use with Alfred. Hopefully they have a plan to create a network for contributing/browsing/filtering other users custom searches (do they?).

Command Line Aliases

I’ve been trying to hone my command line skills as it’s sometimes the only way to do complex operations (searching remote svn log files). One of the actions I find most repeated is finding my way into the various directories to perform these operations. My typing skills are less than stellar, so it kind sucks to type (even with tab completion):

cd /Applications/MAMP/htdocs

In looking for a better way to navigate to my repo, I created an alias. This means that instead of typing:

cd /Applications/MAMP/htdocs

I can simply type:

repo

That variable will be “expanded” into the string cd /Applications/MAMP/htdocs and executed by the shell.

Here’s how make this black magic a reality:

OSX (UNIX)
—–
Open Finder and click on your home folder.
Show the hidden files using the keystroke shift + command + . (or use a dashboard widget)
Open the hidden file named “.profile” (or create one with Textedit if it doesn’t exist)
Add the following text (I use MAMP as my server, which is located at /Applications/MAMP/):

alias repo='/Applications/MAMP/htdocs'

Save the file.
Open a new Terminal (/Applications/Utilities/Terminal.app)
Type:

repo

You should now be in the /htdocs directory (or whatever path you set for repo)

Windows
——–
Open Notepad and create a new text file.
Add the following text (I use WAMP as my server, which is located at C:\wamp):

cd C:\wamp\www

Save the file as “repo.bat” in C:\WINDOWS\system32.
Open a Command Prompt at Start->All Programs->Accessories->Command Prompt (or using the Start Menu shortcut r and CMD)
Type:

repo

You should now be in the \www directory (or whatever path you set for repo)

OSX (UNIX) reference

Windows reference

This is What I Like to Read

Great detail into dealing with a rush of new traffic to Pinboard after Yahoo! announced the Delicious “sunset” (ugh, corporate-speak never gets any easier to swallow).

Server administration scares me.

via marco.org

Toggle Class – The jQuery Way vs. The Native Way

I work with a team of developers located in the US, Canada and Bangalore. On behalf of the North American team, I send daily status emails detailing what each dev worked on, as well as their svn commit log, so the offshore devs and project leadership can stay synced.

For the past 2 or 3 weeks I’ve been including little quick tips on CSS and javascript. The team I’m on is composed of people with a variable level of skills and this is an attempt to affect those levels.

I thought I’d start posting some of these to archive ones I would have found helpful when I first started programming.

We use jQuery in our project and the majority of the devs (including myself) learned javascript via jQuery. Below is what it takes to toggle a class using jQuery vs. native javascript. As you can see, we’ve had it easy.

The jQuery Way

$( '.some-class' ).toggleClass( 'newClass' );

The Native Way (I’m sure there are better ways):

var i = 0,
    elements = document.getElementsByClassName('some-class'),
    len = elements.length,
    classToggle = function( element, tclass ) {

        var classes = elements[i].className,
            pattern = new RegExp( tclass );
            hasClass = pattern.test( classes );

        classes = hasClass ? classes.replace( pattern, '' ) : classes + ' ' + tclass;
        elements[i].className = classes.trim();
    };

for ( ; i < len; i++ ) {
    classToggle( elements[i], 'newClass' );
}

The native example could be wrapped up a bit tighter to make it easily reusable. One of the reasons the jQuery example is so concise is that it relies on it's own methods for making collections and performing loops. The $ and toggleClass functions have quite a bit of code backing them up. If I were to add in all of the source code jQuery uses to preform these tasks, things would look a lot different.

But that's not the point. The thing that has enabled me to use jQuery as just one of the tools in my toolbox, instead of the only tool, is understanding the underlying functionality.

A couple of good references: the jQuery source (of course) and the MDC.

Interesting Links

Programmer Competency Matrix

I was surprised to find that I placed in level 3 for most of the “Programming” rows (as I understand my skills anyway :). Art school has definitely made for some strange bedfellows.

It was motivating to see where I placed in all of the topics, as my approach to learning programming has been to aquire as much understanding as possible about the the things I don’t know. Finding that I was at level 2, but knowing the existence of the concepts in level 3 validates that this approach is moving me in the right direction.

I likened this philosophy to Elizabeth the other day as analogous to how one understands their city. We live in LA, a big, sprawling metropolis, and while I’ve never been to Monrovia or Cerritos (far out there), I understand that both are cities in Los Angeles County. Not the best example, sure, but one that illustrates the differences in approach. I actively seek out and retain this type of understanding in the belief that it may be useful at some point. Others my see it as the inevitable result of living in the same place a long time.

A better example would be to relate it to one’s chosen carrer. Using this angle, it becomes quickly evident that the ones who take an active approach are usually more successful (the definition of the success is based on the specific domain, of course). Conversely, those taking a passive approach tend to exert more effort in defending how what they do know is more tried and true, and hence more reliable. More dangerously, as a superior, they tend to actively block their peers and subordinates. Anyone who has worked in a university or college setting will loudly attest.

Deep Linking with Javascript

Open sourced javascript implementation for linking to paragraphs, and even sentences, in webpages. Uses a matching pattern based on the first letters of the first 3 words in the first and last sentence of the paragraph. That was a mouthful. For example, the key for this paragraph would be [OsjFet].

A fun way to practice your Dvorak skills

I still intend to pick up proper typing. And when that time comes, it will definitely be on a Dvorak keyboard.

I started the typing tests last year and unfortunately, lasted only a week. It takes the same discipline as QWERTY (no surprise there), but I find the layout much easier to memorize. Now, if Apple could get on the ball with creating a beautifully designed split keyboard, I could get rid of this clunker. It’s hideous, poorly constructed and loud (key paddings wear out quickly), but it’s still the most comfortable I’ve found.

Language Constructs

I had a very difficult time in my English classes. In fact, there was a period where I simply refused to attempt any writing assignments due to the stress I caused myself. This was the primary reason for many failed classes in high school. Thankfully, I managed to graduate and go on to do much better in college.

It was during 2005 I began programming and a surprising result has been a better appreciation in how the English language is defined and used. Like human languages, programming languages can be broken down into similar constructs of nouns, adjectives, verbs, etc. It’s not something I’ve looked into (someday I will), but I find that common devices in modern programming languages can be compared to simplified examples in human languages.

So yesterday, Elizabeth and I were discussing using the phrase “that that” in a sentence and how awkward it sounds in conversation, even though it’s grammatically valid. When writing, I normally try to substitute “which” for the latter “that” (I’m usually not deft enough to do the same in conversation). The unintended side effect though, is the substitution can end up making the sentence read a little too formal and out of character. Most people I know, including myself, rarely use the phrase “that which” in conversation. Not that I judge a good writer by how well their writing mimics conversation, but formalities can interrupt and/or ruin otherwise good prose.

Interested in how this phase functions in a sentence, I looked up the definition of “that”. I learned the first instance of “that” serves as a pronoun, while the second as a conjunction.

Take for instance this conversation:

Speaker One:

Why are you are always disrespectful towards me?

Speaker Two:

I’m not. You’re just not smart enough to know when I’m right.

Speaker One:

See? It is that, that I’m talking about.

The first that, the noun, is referring to Speaker Two’s answer of I’m not. You’re just not smart enough to know when I’m right..

The second that, the conjunction, acts as the clause connector, connecting It is that with I’m talking about.

To help me remember how these constructs work I like to try and relate them to something in the world of programing. It usually helps regardless of if I can find any similarities.

Here what the conversation would look like as a hypothetical javascript program:

/*
================================
= Define our variables upfront =
================================
*/

var pronoun = null;

var conjunction = "that";

var speak = function( message ) {

	alert( message );

};
	
/* speakers */
var Ryan = {

	role: "Speaker One",

	speak: speak

};

var Chris = {

	role: "Speaker Two",

	speak: speak

};

/*
==========================
= Begin the conversation =
==========================
*/

/* Ryan defines and speaks his question */

Ryan.question = "Why are you are always disrespectful towards me?";

Ryan.speak( Ryan.question );


/* Chris defines and speaks his answer */

Chris.answer = "I'm not. You're just not smart enough to know when I'm right.";

Chris.speak( Chris.answer );


/* Redefine the pronoun to refer to Chris's answer */

pronoun = Chris.answer; 


/* Now Ryan defines and speaks his response */

Ryan.response = "It's" + pronoun + conjunction + "I'm talking about.";

Ryan.speak( Ryan.response );

To take this comparison even farther, you could find parallels for nouns, adjectives and verbs in the above program.

Nouns

Each speaker is “typed” as an Object. Not as in “typed on a keyboard”, but as in the speaker’s value is of the Object type. In English, each speaker would be typed as a noun.

Adjectives

A word that describes or modifies a noun is considered an adjective. Similarly, the properties and methods (referred to as members) of an Object can describe and modify that Object. Our speakers each have a role property to describe the part they play in the conversation.

Verbs

A verb describes an action or occurrence and in the beginning of the above program, the function named speak does just that. Instead of running speak on as a standalone (via speak()), I decided to create a speak member in each speaker and use the standalone speak function as its value. This effectively creates a method (used as Ryan.speak()). Now, each speaker can have its own voice.

The speak function takes one argument, message, which is the value passed into the parenthesis used to execute the function. The function simply calls alert, which creates a little browser notification dialog.

While I didn’t set out to write a introductory to programming, It’s nice to finally write down the way I think about these things. At least I can point to it when my friends want some sort basic understanding of programming, which is never, of course.


Copyright © Ryan Fitzer 2011. All rights reserved.

RSS Feed. This blog is proudly powered by Wordpress and uses a modified version of Modern Clix, a theme by Rodrigo Galindez.