Land Your Next Web Development Job: The Interview Process

During my career as a software developer and manager, I have been involved in many interviews. Whether the interviewer or interviewee, I have always paid special attention to the interview process.
In my current role, I spend a lot of time interviewing potential employees, so I’ve seen my fair share of good and bad interviews. Some candidates stand out from the crowd immediately, while others are just another face in a million. In this article, I’ll give you a few tips and a head start on your next interview. Whether your next interview is your first or twenty-first, hopefully these tips will help you along the way.
Interviews can be scary, especially when you attend your first few or haven’t attended any for a while. Preparation is the key to success and can take the stress out of the dreaded process. You can do a few things before even walking through the door. If you are prepared and your mind is ready, then the whole process should be a breeze. I like to break the interview process into three steps: preparation, interview and post-interview.

Preparation

This is the most important stage in the process and could determine whether you appeal to the recruiter. A CV won’t even make it past the review stage if it doesn’t meet certain criteria, but by preparing beforehand, you can maximize your chances of making it to the interview stage.

Update Your CV

Spend time creating a great CV. Some great templates are on Guardian Jobs. If you have never created a CV, try to mirror the layouts of some of the people who inspire you. I drew some inspiration from both Scott Hanselman and Paul Irish. For example, Paul’s CV contains testimonials from other popular developers in the community, and Scott’s CV contains highlights from his presentations, qualifications and open-source contributions. You might not have the same experience or work history as the people who inspire you, but you can always get new ideas from their CVs. Who are the leaders in your field?
I follow a few rules when creating a CV:

• Don’t lie.
  Never claim anything on your CV that you can’t do, because if an employer questions you and you don’t have the answers, you could lose the job and look like a fool in the process.
• Steer clear of buzzwords.
  I have noticed a trend of candidates adding a load of buzzwords to their CVs to help recruitment agents find them. Only add a skill if you have used it before and feel competent enough to answer questions about it. Also, steer clear of buzzwords such as “dynamic,” “synergy” and “creative.”
• Have your CV reviewed.
  Get your mother, sibling or friend to review your CV before submitting it. The extra pair of eyes might spot a few areas for improvement and help you finely hone the document into the perfect CV. Remember that your CV is the first point of contact before you walk in the door. You may be the greatest programmer in the world, but if your CV isn’t up to snuff, no one will want to interview you!
• Spellcheck.
  And then spellcheck again!

Put Your CV Online

If you haven’t done so, create a LinkedIn profile. It’s a great way to get your profile out there and to get potential employers looking at your CV. Simply upload a copy of the CV that you created earlier, and, with a little tweaking, LinkedIn will format it for you. I often use LinkedIn to see whether a candidate knows someone I know or have worked with in the past. Professional connections are a good indication of a person’s working background. You might have a friend who works at the company — a referral always helps.
Another great website for developers is StackOverflow’s Careers 2.0.

Much like LinkedIn, Careers 2.0 lets you post your CV, but it is more developer-focused, allowing you to link to your open-source projects and any technical books you may be reading. Once you have created your online profile, both LinkedIn and StackOverflow will let you export a PDF of your profile, which could serve as a CV. So, if you like the format and layout, simply download and use it for your next job application.

Get Some Code Out There

If you are a Web developer or designer, then an online presence is vital. If you have any side projects or even snippets of code, get them onto a social collaboration platform, such as GitHub. Seeing that a candidate builds things in their spare time or even contributes to open-source projects instantly piques my interest. It’s a great indicator that they are passionate about what they do. Include your highest-quality work in your online portfolio. Tinkering with projects in your spare time also helps you to learn and grow, and hopefully you will be able to bring that knowledge into the company.

A few great code-hosting services are GitHub, Bitbucket and CodePlex. Once you have uploaded your code, put it on your CV! It could help you to stand out from the crowd.
If working on an open-source project isn’t for you, then you could always contribute on StackOverflow. The community is great, and the more questions you answer, the higher your score, or “reputation.” While this doesn’t necessarily indicate that a candidate is qualified, it does show that they have an active interest in the community and are willing to learn.

Get a Blog Up and Running

If you have the time, writing a blog can be a rewarding experience. It will teach you the ins and outs of SEO, website deployment and social promotion. You could go down the route of writing your own blog engine (which would give you something to deploy on GitHub!), or you could use one of the awesome blog engines out there that are ready to roll. I quite like Tumblr, SquareSpace and even WordPress.

Again, don’t forget to add the blog’s URL to your CV! Blogging isn’t for everyone, and it takes time, so if you feel you might not be able to commit or update it regularly, get yourself onto Twitter and start following people who inspire you. As an employer, I always like to see what a candidate is interested in, talking about, etc.

Do Your Homework

Before going to the interview, learn as much about the company as you can. How long has it been operating? What products does it sell? What is its culture like? Think about the challenges it faces and how you can use your experiences and know-how to help it build great tools. Nothing is worse than interviewing someone who has no idea about our company or what we do. You don’t need to spend hours learning the history of the company, but a basic understanding of what it does and its ethos is important. If you haven’t done your research, then an automatic “No” is almost guaranteed!

Technical Test

If the job entails writing code, then certain companies will require you to complete a technical test. It could be a simple exercise that you complete at home, or it could be a test that you come into the office and complete then and there. If you are asked to complete the test at home, put as much effort into it as possible. I have received many tests from candidates that have a lot of JavaScript errors or that don’t compile. Make sure yours has no errors and that it works on platforms other than the one you develop on! If you get the chance, review the code briefly with someone you know. You might just find a few areas to improve on.

Another great idea is to deploy the test to a live server. You can sign up for a free starter plan on Site44, which enables you to create and deploy HTML websites from your Dropbox account for free. Both Amazon EC2 and Windows Azure let you set up free cloud websites in a matter of minutes and delete them when completed.
By deploying your application and showing a working version, you demonstrate an understanding of how to deploy software, which could give you an advantage over other candidates. In fact, I hire most developers who show me a live, deployed, working version of their code!

By taking that extra time to make sure your technical test is outstanding, you give yourself a clear advantage over other candidates.

The Interview

If you’ve made it this far, congratulate yourself. Your hard work and preparation have secured an interview, and the employer thinks you might be the right candidate. It’s time to nail the interview and finish the whole process in style.

Questions

Before going into the office for the interview, write down a few of your own questions about the position. This is your chance to learn as much about the role as possible. Having learned a little more about the company, you might even find that it’s not the place for you!
Ask about the working environment, the development stack you will be working on, and anything else related to the job. Interviewers love to answer questions, and it shows you have taken the time to think about the position. Going into an interview without any of your own questions is a bad thing! Remember that you are also interviewing the employer in this stage!

Don’ts

There are a few definite no-no’s in the interview process. Follow these simple rules to avoid any awkward moments:

• Don’t ask about the salary.
  Bringing this up during the interview is not the best timing. Other members of the staff will often sit in on the interview, and your potential salary might not be intended for their ears. If you do need to ask at this point, do it privately with the hiring manager.
• Don’t ask how you did.
  This is important because the people in the room will be discussing you after the interview. Other candidates might be interviewing before or after you, and the team will need a chance to compare you to them.
• Don’t badmouth your former employer.
  No matter how mistreated you feel or how bad the job was, keep your thoughts about your former employer to yourself. Be as diplomatic as possible, because disparaging other people won’t win you points with the interviewer. Your attitude towards and description of your former employer is a good indication of the kind of employee you will be. If asked about your last position and why you left, explain the situation but save the ranting — you would only make yourself look bad!
• Don’t lie.
  If you don’t know the answer to a question, just say so! The interviewer will respect you for answering honestly and will understand that you don’t know the answer to every question.

Last-Minute Details

Whether you are applying for the job directly or through an agency, check a few last things before going to the office for the interview:

• What is the dress code?
• What will the format of the interview be?
• How long will the interview last?
• When and where will the interview be held?
• Who will be present in the interview?

Find out the address and time of the interview, and arrive at least 15 minutes early. This will give you a chance to relax and to avoid the stress of rushing about. By arriving early, you will also observe the staff coming and going through the reception area. Those 15 minutes could give you a good feel for the company.
Finding out these simple things before going for the interview takes some of the stress out of the situation. Preparation is the key to success!

Relax

The interview process is as much about you finding out whether the job and company are right for you. Feeling nervous is natural, but try to relax and enjoy the process. If you are relaxed, you will interview that much better and will come across as more confident. You’ve done all the hard work to get through the door — now, just keep up the good work.

Post-Interview

The interview is over, and you are eagerly awaiting the result. Depending on the company, it could take a few days to a week to get back to you. Rest easy, knowing that you have done all the hard work and given it your best shot.
If you wind up not being chosen, don’t be disheartened. The timing might not have been right, or you might need to brush up on a few areas. There could be any number of reasons why you weren’t offered the position, many being outside of your control. Interviewers will often give you feedback on the process and your performance; if you would like more detail, don’t be afraid to ask. Whenever I have been turned down for a position, I have asked the interviewer for areas to improve upon. It is an opportunity to learn and grow. Practice makes perfect, and the more you interview, the better you will become at the process. Once a few interviews are under your belt, it starts to become a piece of cake.
If you do get the job, well done! You’ve nailed your first interview and are on your way to starting the new job. You should be extremely proud of your achievement.

Remember

Interviewing is difficult! No matter how hard you try, you will not always be successful, and sometimes it just doesn’t work out. By following the steps in this article, hopefully you will become more effective at the process and seem a more attractive candidate. Finally, remember that the interview process is as much about you learning about the employer as it is about them learning about you!

Custom php.ini settings for PHP FCGI

If you want to enable custom php.ini settings for PHP FCGI on your server then follow the below steps :

1. Create a .htaccess file under the directory : /home/username/public_html

cd /home/username/public_html

vi .htaccess

Add the below two lines at the top :

AddHandler php5-fastcgi .php

Action php5-fastcgi /cgi-bin/php.fcgi

save and quit.

2. Go to the cgi-bin directory : /home/username/public_html/cgi-bin

cd /home/username/public-html/cgi-bin

and then copy the default php.ini here

cp /usr/local/lib/php.ini /home/username/public_html/cgi-bin/

3. Create php.fcgi file to load custom php.ini

Please note that you should still be in /home/username/public_html/cgi-bin location.

vi php.fcgi

and then add the below code :

#!/bin/sh

export PHP_FCGI_CHILDREN=1

export PHP_FCGI_MAX_REQUESTS=0

exec /usr/local/cpanel/cgi-sys/php5

save and quit.

Now make the file php.cgi executable:

chmod + x php.fcgi

4. Change ownership of files to correct user:

chown username.username * -R

And if it still does not work for you then follow the below steps as well :

5. Add paths to php.conf file

vi /usr/local/apache/conf/php.conf

and add the below lines :

Action php5-fastcgi /cgi-bin/php.fcgi

AddType application/x-httpd-php .php

save and quit.

and after adding the above two lines the php.conf file should look like this :

root@server[/usr/local/apache/conf] # cat php.conf

# Fastcgi configuration for PHP5

LoadModule fcgid_module modules/mod_fcgid.so

MaxRequestsPerProcess 500

AddHandler fcgid-script .php5 .php4 .php .php3 .php2 .phtml

Action php5-fastcgi /cgi-bin/php.fcgi

AddType application/x-httpd-php .php

FCGIWrapper /usr/local/cpanel/cgi-sys/php5 .php5

FCGIWrapper /usr/local/cpanel/cgi-sys/php5 .php4

FCGIWrapper /usr/local/cpanel/cgi-sys/php5 .php

FCGIWrapper /usr/local/cpanel/cgi-sys/php5 .php3

FCGIWrapper /usr/local/cpanel/cgi-sys/php5 .php2

FCGIWrapper /usr/local/cpanel/cgi-sys/php5 .phtml

# End of autogenerated PHP configuration.

6. Distill and rebuild Apache, then restart Apache

/usr/local/cpanel/bin/apache_conf_distiller –update

/scripts/rebuildhttpdconf

/etc/init.d/httpd restart

Semantic CSS With Intelligent Selectors

“Form ever follows function. This is the law.” So said the architect and “father of skyscrapers” Louis Sullivan. For architects not wishing to crush hundreds of innocent people under the weight of a colossal building, this rule of thumb is pretty good. In design, you should always lead with function, and allow form to emerge as a result. If you were to lead with form, making your skyscraper look pretty would be easier, but at the cost of producing something pretty dangerous.
So much for architects. What about front-end architects — or “not real architects,” as we are sometimes known? Do we abide by this law or do we flout it?
With the advent of object-oriented CSS (OOCSS), it has become increasingly fashionable to “decouple presentation semantics from document semantics.” By leveraging the undesignated meanings of classes, it is possible to manage one’s document and the appearance of one’s document as curiously separate concerns.

In this article, we will explore an alternative approach to styling Web documents, one that marries document semantics to visual design wherever possible. With the use of “intelligent” selectors, we’ll cover how to query the extant, functional nature of semantic HTML in such a way as to reward well-formed markup. If you code it right, you’ll get the design you were hoping for.
If you are like me and have trouble doing or thinking about more than one thing at a time, I hope that employing some of these ideas will make your workflow simpler and more transferable between projects. In addition, the final section will cover a more reactive strategy: We’ll make a CSS bookmarklet that contains intelligent attribute selectors to test for bad HTML and report errors using pseudo-content.

Intelligent Selectors

With the invention of style sheets came the possibility of physically separating document code from the code used to make the document presentable. This didn’t help us to write better, more standards-aware HTML any more than the advent of the remote control resulted in better television programming. It just made things more convenient. By being able to style multiple elements with a single selector (p for paragraphs, for instance), consistency and maintenance became significantly less daunting prospects.

The p selector is an example of an intelligent selector in its simplest form. The p selector is intelligent because it has innate knowledge of semantic classification. Without intervention by the author, it already knows how to identify paragraphs and when to style them as such — simple yet effective, especially when you think of all of the automatically generated paragraphs produced by WYSIWYG editors.
So, if that’s an intelligent selector, what’s an unintelligent one? Any selector that requires the author to intervene and alter the document simply to elicit a stylistic nuance is an unintelligent selector. The class is a classic unintelligent selector because it is not naturally occurring as part of semantic convention. You can name and organize classes sensibly, but only with deliberation; they aren’t smart enough to take care of themselves, and browsers aren’t smart enough to take care of them for you.
Unintelligent selectors are time-intensive because they require styling hooks to be duplicated case by case. If we didn’t have p tags, we’d have to use unintelligent selectors to manufacture paragraphs, perhaps using .paragraph in each case. One of the downsides of this is that the CSS isn’t portable — that is, you can’t apply it to an HTML document without first going through the document and adding the classes everywhere they are required.

Unintelligent selectors at times seem necessary, or at least easier, and few of us are willing to rely entirely on intelligent selectors. However, some unintelligent selectors can become “plain stupid” selectors by creating a mismatch between document structure and presentation. I’ll be talking about the alarming frequency with which the unintelligent .button selector quickly becomes plain stupid.

Vive la Différence

Intelligent selectors are not confined just to the basic elements offered to us in HTML’s specification. To build complex intelligent selectors, you can defer to combinations of context and functional attribution to differentiate basic elements. Some elements, such as <a>, have a multitude of functional differences to consider and exploit. Other elements, such as <p>, rarely differ in explicit function but assume slightly different roles according to context.

header p {
   /* styles for prologic paragraphs */
}

footer p {
   /* styles for epilogic paragraphs */
}

Simple descendent selectors like these are extremely powerful because they enable us to visually disclose different types of the same element without having to physically alter the underlying document. This is the whole reason why style sheets were invented: to facilitate physical separation without breaking the conceptual reciprocity that should exist between document and design.

Inevitably, some adherents of OOCSS treat the descendent selector with some suspicion, with the more zealous insisting on markup such as the example below, found in BEM’s “Definitions” documentation.

<ul class="menu">
  <li class="menu__item">…</li>
  <li class="menu__item">…</li>
</ul>

I won’t cover contextual selectors any further because, unless you have a predilection for the kind of overprescription outlined above, I’m sure you already use them every day. Instead, we’ll concentrate on differentiation by function, as described in attributes and by attribute selectors.

Hyperlink Attributes

Even those who advocate for conceptual separation between CSS and HTML are happy to concede that some attributes — most attributes besides classes and custom data attributes, in fact — have an important bearing on the internal functioning of the document. Without href, your link won’t link to anything. Without type, the browser won’t know what sort of input to render. Without title, your abbr could be referring to either the British National Party or Banco Nacional de Panama.
Some of these attributes may improve the semantic detail of your document, while others are needed to ensure the correct rendering and functioning of their subject elements. If they’re not there, they should be, and if they are there, why not make use of them? You can’t write CSS without writing HTML.

The rel Attribute

The rel attribute emerged as a standard for link relations, a method of describing some specific purpose of a link. Not all links, you see, are functionally alike. Thanks to WordPress’ championing, rel="prev" and rel="next" are two of the most widely adopted values, helping to describe the relationship between individual pages of paginated blog content. Semantically, an a tag with a rel attribute is still an a tag, but we are able to be more specific. Unlike with classes, this specificity is semantically consequential.
The rel attribute should be used where appropriate because it is vindicated by HTML’s functional specification and can therefore be adopted by various user agents to enhance the experience of users and the accuracy of search engines. How, then, do you go about styling such links? With simple attribute selectors, of course:

[rel="prev"] {
  /* styling for "previous links" */
}

[rel="next"] {
  /* styling for "next" links */
}

Attribute selectors like these are supported by all but the most archaic, clockwork browsers, so that’s no reason not to use them anywhere the attributes exist. In terms of specificity, they have the same weight as classes. No woe there either, then. However, I recall it being suggested that we should decouple document and presentation semantics. I don’t want to lose the rel attributes (Google has implemented them, for one thing), so I’d better put an attribute that means nothing on there as well and style the element via that.

  <a href="/previous-article-snippet/" rel="prev" class="prev">previous page</a>

The first thing to note here is that the only part of the element above that does not contribute to the document’s semantics is the class. The class, in other words, is the only thing in the document that has nothing functionally to do with it. In practice, this means that the class is the only thing that breaks with the very law of separation that it was employed to honor: It has a physical presence in the document without contributing to the document’s structure.
OK, so much for abstraction, but what about maintenance? Accepting that we’ve used the class as our styling hook, let’s now examine what happens when some editing or refactoring has led us to remove some attributes. Suppose we’ve used some pseudo-content to place a left-pointing arrow before the [rel="prev"] link’s text:

.prev:before {
  content: '\2190'; /* encoding for a left-pointing arrow ("←") */
}

Removing the class will remove the pseudo-content, which in turn will remove the arrow (obviously). But without the arrow, nothing remains to elucidate the link’s extant prev relationship. By the same token, removing the rel attribute will leave the arrow intact: The class will continue to manage presentation, all the time disguising the nonexistence of a stated relationship in the document. Only by applying the style directly, via the semantic attribute that elicits it, can you keep your code and yourself honest and accurate. Only if it’s really there, as a function of the document, should you see it.

Attribute Substrings

I can imagine what you’re thinking: “That’s cute, but how many instances are there really for semantic styling hooks like these on hyperlinks? I’m going to have to rely on classes at some point.” I dispute that. Consider this incomplete list of functionally disimilar hyperlinks, all using the a element as their base:

• links to external resources,
• links to secure pages,
• links to author pages,
• links to help pages,
• links to previous pages (see example above),
• links to next pages (see example above again),
• links to PDF resources,
• links to documents,
• links to ZIP folders,
• links to executables,
• links to internal page fragments,
• links that are really buttons (more on these later),
• links that are really buttons and are toggle-able,
• links that open mail clients,
• links that cue up telephone numbers on smartphones,
• links to the source view of pages,
• links that open new tabs and windows,
• links to JavaScript and JSON files,
• links to RSS feeds and XML files.

That’s a lot of functional diversity, all of which is understood by user agents of all sorts. Now consider that in order for all of these specific link types to function differently, they must have mutually differential attribution. That is, in order to function differently, they must be written differently; and if they’re written differently, they can be styled differently.
In preparing this article, I created a proof of concept, named Auticons. Auticons is an icon font and CSS set that styles links automatically. All of the selectors in the CSS file are attribute selectors that invoke styles on well-formed hyperlinks, without the intervention of classes.

In many cases, Auticons queries a subset of the href value in order to determine the function of the hyperlink. Styling elements according to the way their attribute values begin or end or according to what substring they contain throughout the value is possible. Below are some common examples.

The Secure Protocol

Every well-formed (i.e. absolute) URL begins with a URI scheme followed by a colon. The most common on the Web is http:, but mailto: (for SMTP) and tel: (which refers to telephone numbers) are also prevalent. If we know how the href value of the hyperlink is expected to begin, we can exploit this semantic convention as a styling hook. In the following example for secure pages, we use the ^= comparator, which means “begins with.”

a[href^="https:"] {
   /* style properties exclusive to secure pages */
}

In Auticons, links to secure pages become adorned with a padlock icon according to a specific semantic pattern, identifiable within the href attribute. The advantages of this are as follows:

• Links to secure pages — and only secure pages — are able to resemble links to secure pages by way of the padlock icon.
• Links to secure pages that cease to be true links to secure pages will lose the https protocol and, with it, the resemblance.
• New secure pages will adopt the padlock icon and resemble links to secure pages automatically.

This selector becomes truly intelligent when applied to dynamic content. Because secure links exist as secure links even in the abstract, the attribute selector can anticipate their invocation: As soon as an editor publishes some content that contains a secure link, the link resembles a secure one to the user. No knowledge of class names or complex HTML editing is required, so even simple Markdown will create the style:

[Link to secure page](https://payment.example.com/)

Note that using the [href^="https:"] prefix is not infallible because not all HTTPS pages are truly secure. Nonetheless, it is only as fallible as the browser itself. Major browsers all render a padlock icon natively in the address bar when displaying HTTPS pages.

File Types

As promised, you can also style hyperlinks according to how their href value ends. In practice, this means you can use CSS to indicate what type of file the link refers to. Auticons supports .txt, .pdf, .doc, .exe and many others. Here is the .zip example, which determines what the href ends with, using $=:

[href$=".zip"]:before, 
[href$=".gz"]:before {
   content: '\E004'; /* unicode for the zip folder icon */
}

Combinations

You know how you can get all object-oriented and use a selection of multiple classes on elements to build up styles? Well, you can do that automatically with attribute selectors, too. Let’s compare:

/* The CSS for the class approach */

.new-window-icon:after {
   content: '[new window icon]';
}

.twitter-icon:before {
  content: '[twitter icon]';
}

/* The CSS for the attribute selector approach */

[target="_blank"]:after {
   content: '[new window icon]';
}

[href*="twitter.com/"]:before {
  content: '[twitter icon]';
}

(Note the *= comparator, which means “contains.” If the value string contains the substring twitter.com/, then the style will be honored.)

<!-- The HTML for the class approach -->

<a href="http://twitter.com/heydonworks" target="_blank" class="new-window-icon twitter-icon">@heydonworks</a>

<!-- The HTML for the attribute selector approach -->

<a href="http://twitter.com/heydonworks" target="_blank">@heydonworks</a>

Any content editor charged with adding a link to a Twitter page now needs to know only two things: the URL (they probably know the Twitter account already) and how to open links in new tabs (obtainable from a quick Google search).

Inheritance

Some unfinished business: What if we have a link that does not match any of our special attribute selectors? What if a hyperlink is just a plain old hyperlink? The selector is an easy one to remember, and performance fanatics will be pleased to hear that it couldn’t be any terser without existing at all.

Flippancy aside, let me assure you that inheritance within the cascade works with attribute selectors just as it does with classes. First, style your basic a — perhaps with a text-decoration: underline rule to keep things accessible; then, progressively enhance further down the style sheet, using the attribute selectors at your disposal. Browsers such as Internet Explorer (IE) 7 do not support pseudo-content at all. Thanks to inheritance, at least the links will still look like links.

a {
  color: blue;
  text-decoration: underline;
}

a[rel="external"]:after {
   content: '[icon for external links]';
}

Actual Buttons Are Actual

In the following section, we’ll detail the construction of our CSS bookmarklet for reporting code errors. Before doing this, let’s look at how plain stupid selectors can creep into our workflow in the first place.
Adherents of OOCSS are keen on classes because they can be reused, as components. Hence, .button is preferable to #button. I can think of one better component selector for button styles, though. Its name is easy to remember, too.

The <button> element represents a button.
– W3C Wiki

Topcoat is an OOCSS BEM-based UI framework from Adobe. The CSS for Topcoat’s various button styles is more than 450 lines if you include the comment blocks. Each of these comment blocks suggests applying your button style in a manner similar to this introductory example:

   <a class="topcoat-button">Button</a>

This example is not a button. No, sir. If it were a button, it would be marked up using <button>. In fact, in every single browser known to man, if it were marked up as a button and no author CSS was supplied, you could count on it looking like a button by default. It’s not, though; it’s marked up using <a>, which makes it a hyperlink — a hyperlink, in fact, that lacks an href, meaning it isn’t even a hyperlink. Technically, it’s just a placeholder for a hyperlink that you haven’t finished writing yet.

A dog in a shark costume does not a shark make. (Image: reader of the pack)
The examples in Topcoat’s CSS are only examples, but the premise that the class defines the element and not the HTML is deceptive. No amount of class name modification via “meaningful hyphenation” can make up for this invitation to turn your unintelligent selector into a plain stupid one and to just code stuff wrong.
Update: Since writing this article, Topcoat.io has replaced these examples with <button> examples. This is great! However, I still have my reservations about the way the examples expound the use of the .is-disabled class while omitting the proper disabled attribute. To hear both sides, find my conversation with the Topcoat representative in the comments. For further examples of OOCSS-facilitated web standards mishaps, look no further than semantic-ui.com. The “standard button” in their examples is a <div> containing an empty <i>.

See No Evil, Hear No Evil

“If it looks like a duck, swims like a duck, and quacks like a duck, then it probably is a duck.”

A link that resembles a button and triggers button-like JavaScript events is, to many, a button. However, this only means that it has passed the first two stages of the “duck test.” For all users to be able to apply inductive reasoning and discern the button as such, it must also quack like one. Because it remains a link, it will be announced by screen readers as “link,” meaning that your allegorical skyscraper is not wheelchair-accessible. Avoiding this kind of unnecessary confusion for assistive technology users is not a pursuit of semantic perfection but a responsibility we should undertake for real benefit.
Nonetheless, some will insist on using a as the basis of their buttons. Hyperlinks are (slightly) easier to restyle consistently, after all. If a is the element of choice, then there is only one way to make it a close-to-true button in the accessibility layer. You guessed it: You must apply another meaningful attribute in the form of a WAI ARIA role. To ensure that a hyperlink element looks like a button for good reason, apply only the following attribute selector.

[role="button"] {
   /* semantic CSS for modified elements that are announced as “button” in assistive technologies */
}

Quality Assurance With Attribute Selectors

“CSS gives so much power to the class attribute, that authors could conceivably design their own “document language” based on elements with almost no associated presentation (such as DIV and SPAN in HTML) and assigning style information through the “class” attribute. Authors should avoid this practice since the structural elements of a document language often have recognized and accepted meanings.”
– “Selectors,” CSS Level 2, W3C

The reason we have two elements — a and button — is to semantically demarcate two entirely different types of functional interaction. While the hyperlink denotes a means to go somewhere, the button is intended as the instigator of an event or action. One is about traversal, the other about transformation. One facilitates disengagement, the other engagement.
To make sure we don’t do anything too daft and get our links and buttons muddled up, we will now build a CSS bookmarklet that uses intelligent attribute selectors to test the validity and quality of the two respective elements.
Inspired partly by Eric Meyer’s post and taking a few cues from DiagnostiCSS, this style sheet will combine attribute selectors and the :not selector (or negation pseudo-class) to highlight problems in the HTML. Unlike these other two implementations, it will write an error to the screen using pseudo-content. Each error will be written in Comic Sans against a pink background.
By connecting function directly to form, we see that ugly markup results in ugly CSS. Consider this the revenge of an abused document, exacted on its designer. To try it out, drag revenge.css to your bookmarks, and click the bookmark to trigger it on any page that you fancy. Note: It won’t currently work for pages that are served over https.

REVENGE.CSS
Drag to your bookmarks bar.

Rule 1

“If it’s a hyperlink, it should have an href attribute.”

a:not([href]):after {
   content: 'Do you mean for this to be a link or a button, because it does not link to anything!';
   display: block !important;
   background: pink !important;
   padding: 0.5em !important;
   font-family: 'comic sans ms', cursive !important;
   color: #000 !important;
   font-size: 16px !important;
}

Notes: In this example, we are testing not the attribute’s value, but whether the attribute exists in the first place — that is, whether [href] matches any element with an href attribute. This test is only appropriate on hyperlinks, hence the a prefix. The rule reads like, “For every a element that is not also an [href] element, append some pseudo-content with an error notice.”

Rule 2

“If it’s a hyperlink and has an href attribute, it should have a valid value.”

a[href=""]:after, a[href$="#"]:after, a[href^="javascript"]:after {
   content: 'Do you mean for this link to be a button, because it does not go anywhere!';
   /*... ugly styles ...*/
}

Notes: If the href is empty, ends in a # or is using JavaScript, it’s probably being used as a button without the correct button element. Note that I am using “starts with javascript.” Standard practice for voiding hrefs is to use javascript:void(0), but we can’t depend on that always being written in the same way (with or without a space after the colon, for example).

Rule 3

“If it uses a button class, it should be a button — at least in the accessibility layer.”

.button:not(button):not([role="button"]):not([type="button"]):not([type="submit"]):not([type="reset"]):after,
.btn:not(button):not([role="button"]):not([type="button"]):not([type="submit"]):not([type="reset"]):after, 
a[class*="button"]:not([role="button"]):after {
   content: 'If you are going to make it look like a button, make it a button, damn it!';
   /*... ugly styles ...*/
}

Notes: In this example, we’re demonstrating how you can chain negation when testing for attributes. Each selector reads like this: “If the element has a class that says it’s a button but it’s not a button element and it doesn’t have the correct role to make it a button in the accessibility layer and it’s not an input being used as a button, then… well, you’re lying.” I’ve had to use [class*="button"] to catch the many Topcoat class variations (62 in total!) that fail to enforce actual buttons on hyperlinks. I’ve noticed that some authors use button-container and the like on parent elements, which is why the a qualifier is included to avoid false positives. You may recognize the .btn class from Twitter Bootstrap, which (if you’ve read the component’s documentation carefully) you’ll know is also unsure about whether links or buttons are buttons.

Rule 4

“If it is an a element with role="button", then it should link to somewhere when JavaScript is off.”

a[role="button"]:not([href*="/"]):not([href*="."]):not([href*="?"]):after {
   content: 'Either use a link fallback, or just use a button element.';
   /*... ugly styles ...*/
}

Notes: We can be fairly sure that hrefs that do not include one of /, . (usually to precede a file extension) or ? (to start a query string) are probably bogus. Getting links to act as buttons and return: false when JavaScript is on is fine — fine, that is, if they have a page to go to when JavaScript is off. In fact, it’s the only legitimate reason I can think of not to use <button> instead.

Rule 5

“You can’t disable a hyperlink.”

a.button[class*="disabled"]:after, 
a.btn.disabled:after,
a[class*="button"][class*="disabled"]:after {
   content: 'You cannot disable a hyperlink. Use a button element with disabled="disabled".';
   /*... ugly styles ...*/
}

Notes: Even ancient user agents understand the disabled attribute, so use it with an appropriate element in a compliant way. You can concatenate attribute selectors just as you can concatenate classes: In the last of the three selectors, we’re saying, “If it’s a link that contains the substring button and the substring disabled, then print an error message.” Twitter Bootstrap uses the second form, .btn.disabled, in its style sheet, but not with the a prefix. We’ll only consider it an error if used on hyperlinks.

Rule 6

“Buttons in forms should have explicit types.”

form button:not([type]):after {
 content: 'Is this a submit button, a reset button or what? Use type="submit", type="reset" or type="button"';
}

Notes: We need to determine whether buttons within forms have explicit types, because some browsers will treat any button in this context without a specified type as type="submit". We want to be absolutely sure that the form won’t submit if our button has a different purpose.

Rule 7

“Both hyperlinks and buttons should have some sort of content or an ARIA label.”

a:empty:not([aria-label]):not([aria-labelledby]):after, 
button:empty:not([aria-label]):not([aria-labelledby]):after, 
button:not([aria-label]):not([aria-labelledby]) img:only-child:not([alt]):after, 
a:not([aria-label]):not([aria-labelledby]) img:only-child:not([alt]):after {
   content: 'All buttons and links should have text content, an image with alt text or an ARIA label';
   /*... ugly styles ...*/
}

Notes: Buttons and links that don’t include any kind of direction for their usage — in either textual or graphical form — are pretty bogus. These final two selectors are perhaps the most complex I’ve ever written. For the hyperlink version, the selector reads something like this: “If it is a hyperlink that does not have either an aria-label attribute or an aria-labelledby attribute and it contains only an image as content but this image does not have an alt attribute, then write the ugly error message.” Also, note the use of the :empty selector. Arguably, no element that is not self-closing should ever be left empty.
Ten points to the first person using revenge.css who can tell me where I’ve broken my own rule in this very article. Trust me, the error is definitely there.

Conclusion

The reason I use the kinds of selectors and patterns described above is not to try something different or to have something new to write about. Attribute selectors aren’t, by themselves, anything new anyway. IE 6 is the only browser that doesn’t support them. The reason I use them is because I simply do not have the time or mental capacity to “do” HTML and CSS in parallel. My brain just isn’t good enough for that. The reason I style my page headers with [role="banner"] and not .page-header is because that’s the only way I’ll know — upon seeing the intended visual effect — that I’ve put the navigable landmark in place. How else does one keep track? You can’t just leave it to testing, because then it’s usually too late.
There’s no such thing as semantic CSS. There’s only semantic HTML and its visible form. In this article I have tried to demonstrate that, by coupling the function and form of Web pages directly, you can create mechanisms for reward and punishment. On the one hand, you can set up selectors that invoke visual motifs only when the suitable markup is used. On the other hand, you can query the markup for bad patterns and erode the visual design as a commitment to the underlying ugly truth.
It’s true that not all the styling hooks in your arsenal will likely ever be uniformly semantic or intelligent. Classes are often desirable as polyfills for much needed elements or attributes that have yet to be standardized. That’s how .footer became <footer> and type="text" (with a bunch of JavaScript) became type="url". Other times, they are helpful for doing non-semantic layout scaffolding with grid frameworks and the like.
However, if you are committed to giving CSS its own completely separate logic, then you are bound to create unnecessary arguments between form and function. In this eventuality, only constant vigilance can protect against inaccessibility and invalidity. To make matters worse, trying to manufacture pseudo-semantics purely with classes makes it easy to fall into one of those interminable discussions over what makes a semantic class name. You’ll start spending less time using the remote to control the TV and more time just sitting there, contemplating the remote control held in your hand.
Life is too short.

Key Ingredients To Make Your App Go Viral

A viral app is the highest achievement on iTunes and Google Play. It’s an app that customers eagerly share across the Internet, through social networks, email, chat and word of mouth. It’s like rocket fuel, and it is the best case scenario for an app developer because word of mouth is far more powerful than any paid advertising. Ad clutter is everywhere, and people just ignore it.
No one trusts ads, and they cost too much for developers anyway. But humans have shared stories since we’ve been using rocks as tools. We’re naturally built for viral sharing.

But getting your app to spread faster than celebrity gossip takes a lot more than bolting on some Twitter and Facebook buttons. It requires strategizing a world of social interaction inside your app.

What Is Viral?

Virality is about interacting with people and enticing them to participate. Virality isn’t a marketing strategy that can be executed once you launch. It has to be thought through and built into your app from the beginning.
To succeed, your app must pass these four tests:

1. It must have something valuable to share.
2. It must make it easy for users to share and for friends to join.
3. It must reward users for sharing and offer them incentives to come back.
4. The more people use the app, the more value must be created for them.

First and foremost, your app has to have a gem — something valuable to share. That something could be a photo, a great wine, a turn-based game, an article, a playlist or a five-mile run. It’s your customer’s little pride and joy, and it has to be shareable.
When users share their little gem, they’ll get a warm fuzzy feeling that keeps them checking into the app over and over. The more they check into the app, the more praise and delight they will get from it. And when the app’s audience grows, the value just keeps going up.
To figure out whether your app has any gems, ask yourself these few questions:

• Does my app offer something valuable to share?
• Is it worth being shared?
• How will users be rewarded when they share?
• Why will users want to share?
• Why would they want their friends to share?
• How will my app motivate users to keep sharing over the long term?

Old-School Viral Models

The typical viral flow starts when the user creates something and then shares it, leading friends to discover the gem and download the app so that they can get in on the action:

The typical viral flow strategy of apps.
With this approach, the most obvious way to offer social interaction in your app is to add buttons so that users can share their creations (or actions) on Twitter, Facebook, email and SMS. For example, the Faces app enables users to design silly faces of friends that can be shared on Facebook, Twitter and email.

Social interaction in the Faces app has a typical viral flow, because it only lets users share images.
Unfortunately, this approach misses a lot of opportunities, because only some of the users will share, and only a small percentage of their friends will actually see what they’ve shared, let alone click on the link and download the app themselves.
To go truly viral, you need to engage your audience. Every time they use your app should build on the previous experience, so that they get more value out of your app. And as the audience grows, that value should just go up.
Think of Facebook, Twitter and Pinterest. No one sees the true value of these apps the first time they use them. But the more you put into Twitter, the more you get out of it.

Five Principles Of A Viral Strategy

You don’t have to dig too deep into viral principles before you come across something called the viral coefficient. In The Lean Startup, Eric Ries defines it as “how many new customers will use the product as a consequence of each new customer who signs up.” He claims that a viral coefficient greater than 1 will lead to exponential growth, and a viral coefficient less than 1 will lead to hardly any growth at all. I won’t get into the details, but the math looks like this:

viral coefficient = (average number of users invited by each active user who invites someone) × (proportion of invited users who actually join or become active) × (proportion of active users who invite others)

One important element missing from this formula is the time it takes for a customer to try the app and share it with their friends. The key is to get your users to invite their friends in the shortest amount of time possible. How do you do that?
The quick and dirty method is to just tap into their address book and spam their friends. But then you’d be abusing your customers rather than caring for them, and it will backfire in the end. Instead, try the five principles outlined below. (Most of the examples shown are iOS apps, but the principles apply to all platforms.)

Principle 1: Make It Effortless

The best apps appear so effortless that the design fades into the background, making the task at hand surprisingly easy. This is “flow,” and it has nothing to do with processes or charts. It’s about being completely absorbed in doing something you love and not being distracted by confusing or burdensome steps. The user loses a sense of time and self and becomes completely immersed. It’s why you can’t stop playing Minecraft and why your friend just spent three hours on Pinterest.
To create flow in your app, you’ll need to remove all obstacles and doubts that users might have about using your app and sharing it with friends. Let’s go through a few examples of how your app can do that.
Offer one-click sign-in via Facebook or Twitter, rather than with a dedicated user name and password. This not only gets users registered quickly, but lets you tap into important data to grow the network.

500px offers one-click sign-in via Facebook or Twitter.

Rockmelt offers one-click sign-in via Facebook, Twitter or Google.

Snapguide offers one-click sign-in via Facebook or Twitter.
Display profile pictures of friends during authentication to increase their audience as well as yours.

Foursquare displays profile pictures of the user’s friends during authentication.

Vine displays profile pictures of the user’s friends during authentication.
Motivate users on the first screen to get started by clearly showing how they can grow their network and start sharing.

The first screen of Foursquare offers a clear path for users to get started.

The first screen of Hipvite (now defunct) encourages users to get started.

The first screen of Toast encourages users to get started.
Prioritize what is on the screen, and show top actions right in view. Users need to know what they can do.

SoundCloud puts the top action right in front of you.

Wrappit has top actions right in view.

Snapguide has top actions right on hand.
Enable users to easily post to multiple social platforms with just one tap. Always make sharing part of the creation process, and let users post to multiple websites at once. One big advantage of the Android framework over iOS is that it allows apps to share anything with virtually any other app (as long as that other app can receive the “share” intent). This opens up all sorts of interesting viral potential.

Krop Circle lets users post to Instagram, Twitter and Facebook all at once.

Glmps lets users post to several websites with just one tap.

Rexly lets users post to Twitter or Facebook or send by email, all in one action.

Principle 2: Reward Often

If you want to encourage a certain behavior, reward it. This basic psychological tactic has been used on us since we were toddlers, and it will motivate your customers to share your app with friends. Give them a gift for each friend they get to use your app.
Best of all, when someone gives a gift, the recipient naturally has the urge to give one in return.
Inviting friends and connecting with others should be a part of their daily usage. Daniel Tenner, founder of Swombat, suggests that the number of users who each of your active users invites will determine your success. Therefore, inviting friends should be a core process in your app, rather than an afterthought. Experiment with ways to encourage customers to invite friends at different points in the app.

POP’s prototyping app rewards users for signing up early and telling friends.
Reward the friend, too. Rewarding customers for their referrals can make them feel guilty that they are making money off of their friends. The best way around that problem is to also reward the friends who receive their invitations. Voila! Now your customers feel like they’re doing their friends a favor. Everyone wins.
Rewards could be:

• extra storage,
• free themes,
• a character,
• a free upgrade,
• discounts,
• sample sizes.

To create a sense of urgency in the invitation, offer a limited-time promotion. This can get people out of their holding pattern by giving them an incentive to take action before the offer expires. It costs you nothing and could be just the push your customers need to convince their friends to download the app.
Sneak in secret rewards and surprise people, then watch as the app goes viral. Clear unlocks hidden themes when you follow some of the app’s developers on Twitter or if you complete a task at 2:00 am (I discovered that one the hard way). These hidden gifts create a storm on Twitter each time a new one is found, giving the app all sorts of wonderful free publicity.

Clear rewards users with free themes based on other apps installed on their device and based on when they use them.

Each time a new theme is discovered, a Twitter storm happens, making the Clear app more viral.
Some apps even pay people to use them. Not that you’ll need to go to such length, but apps like Shopkick, GymPact and Viggle let users earn real cash and rewards by using them.
With Shopkick, users earn rewards, or “kicks,” simply by walking into participating stores and checking in via the app. They can earn more kicks by scanning items and purchasing them. As a reward, users get a first look at new items in the store, and they can use their kicks to unlock gift cards and products.

Users earn points on Shopkick by going into certain stores. (Image: Hongkiat)
GymPact entices users — non-exercisers, in fact — to go to the gym, work out and earn cash. Users start by making a pact with their friends, promising to work out at the gym a certain number of days, and they set the stakes of how much they’ll pay if they skip a day. Those who go to the gym claim cash from those who don’t!

GymPact rewards people for going to the gym. (Image: Hongkiat)
Viggle is for TV junkies. It practically pays users just to watch the tube. Users earn points by checking into any TV show on the air. Users just tap the “Check-in” button, and their device listens to the TV, earning them points. More points are earned by answering trivia questions. The more points accumulated, the bigger the prizes, which vary from Starbucks gift cards to MacBook Airs.

Viggle rewards users for watching TV.

Principle 3: Give Users Control

Because virality and privacy are polar opposites, transparency is a must. Be up front about what your app is sharing, and give users full control over whether to share. If users don’t trust the app or suddenly see content appear on social networks that they don’t want to be shared, they’ll stop using your app or, worse, leave negative reviews on iTunes.
Be transparent about what is being shared. The social fitness app Teemo tells users what will be shared before they even log into the app. Sonar (iTunes link) reminds users that it won’t post to their accounts unless explicitly told to.

This nice little message in Teemo gives users confidence in the app.

Sonar reminds users of what will be shared.
Always allow users to control what is shared. This can easily be done by including a settings screen with toggles for controlling the sharing options, like in Pinterest’s app.

The settings screen in Pinterest lets users turn off publishing to their Facebook timeline.

Principle 4: Keep Pulling Them Back In

The more people use your app, the longer you’ll stick around. The longer you stick around, the more that customers and onlookers will say good things about you, spreading word of mouth and increasing your profits. So, think about people downloading your app as a springboard to achieving more, rather than as the finish line.
Send users useful notifications that motivate them to return. Don’t wait for them to start using your app. Keep sending them useful messages, as well as showing them tips to encourage them to use your app. This should be a part of your core features.
Also, keep sending friendly reminders and rewards to invite more friends, but be careful not to send out notifications that are worthless and annoying. That’s called spamming. Give users control over what notifications they receive and how they receive them, as We Heart Pics does.

The settings screen in We Heart Pics lets users turn off any notifications.
Create challenges in which users can partake. When Diamond Dash introduced weekly tournaments, users went ballistic. When a player beats a friend’s score, the victory is posted to the winner’s Facebook timeline. When they reach a new level, win a medal or unlock a feature, Diamond Dash announces it to their entire Facebook network. This dynamic has created a friendly competition, pulling users back to the game a stunning 18.5 million times in just one month.
Let users create exclusive groups and invite others to participate, as in the case of a team of supporters in a weight loss or training app.
Promote users with exceptional content or activities. Target power users who have the most connections — these are the mavens who will create the best content. Reward them with freebies and promote them to be managers so that they can set up special groups, create high-end invitations and keep the conversations going. And set them as an example by suggesting that others follow them.

Viddy suggests following the most popular users, helping those users grow their audience.
Let users promote each other. This will help you discover trendsetters. These people might not have the largest following, but they are using your app in new and exciting ways.

Principle 5: Be Useful to a Lone Person

Your app should be of benefit to users, even without the social aspect. This isn’t a requirement, but it does make your chances of going viral much higher. It gives people a chance to kick the tires first. Most people won’t invite others to join the app unless they already know it’s good. To find that out, they have to road test it a few times first.
Your app must have something meaningful for the user to do right away, without inviting friends. When your user base increases, the value of the app’s main function increases as well.

Conclusion

You can’t make your app viral as an afterthought, like pixie dust that magically gives you a ton of users. It has to be designed into the app’s core functionality and features.
You can do these things to improve your app’s chances of going viral:

• Offer something meaningful to share.
• Be transparent about what your app is sharing and whom it is contacting.
• Connecting with friends and inviting new users should be at the core of your app.
• Reward both your users and their invited friends for signing up.
• Keep pulling users back with meaningful notifications, competitions, rewards and promotions.
• Be useful even to the lone user. This is the start of your viral circle.

Unlike the Snuggie Blanket, there is no one-size-fits-all viral strategy; some apps simply won’t benefit from viral tactics. While adding viral features to your app might increase its virality, to really make your app spread, you’ll need to start with a clever idea and a good design. Combined with a fantastic viral strategy, these will surely make your app go Gangnam style.