Over the past couple of days, I have been working on an initial concept/prototype for a new, interesting website. As I normally like to do whenever I am tackling a new project, I started by opening up a notebook and making a few really simple layout sketches for how I initially thought the page should be laid out (at this stage, I am just working the layout for a single type of page, with others following later). After discussing these initial concepts with members of the team I am working with, I very logically moved on to the creating more fully realized wireframes. For me, this meant printing of some grids and using a pen to draw and label content boxes.

The process, however, started me thinking about wireframes, their importance and the role(s) that they play in the design and development process. More specifically, it got me thinking about how wireframing— even in the rudimentary pencil on a paper grid method that I use—may be even more important and useful than it may initially appear, or than we like to give it credit for.

Any form of design—but especially web design (or anything else that actually requires a tangible user interface)—is about more than just what the product looks like. It also needs to consider its audience, its purpose and its media. On the web and in application development, this means questions of usability and user experience, interaction and information architecture, all of which are at least as important—and likely more so—than the what something looks like.

Yet, in the same way that “design” has a tendency to be understood merely as the creation of a unique (and often disconnected) visual aesthetic, so to can wireframing have a tendency to be relegated solely to the realm of layout, when it is, in fact a tool with a much broader scope.

It’s All About Structure

Often, many good designers will approach the question of layout from the perspective of arranging the elements on a page in such a way as to create something that is aesthetically pleasing to look at. Conversely, others will approach the layout as a matter of arranging elements in a logical, predictable and consistent fashion, which leads to improved usability and a better user experience.

Great designers do both, and I wouldn’t be at all surprise to learn that 9 times out of 10, this is generally reflected in their wireframing.

Earlier this year Nick Haas authored an excellent post on why wireframing is important and should not be glossed over in an effort to jump straight into the “real” design (and I use that term somewhat ironically) that determines a site’s appearance. In this article, Haas rightly points out that wireframing:

forces everyone to look objectively at a web site’s ease of use, conversion paths, naming of links, navigation placement and feature placement. Wireframes can point out flaws in your site architecture or how a specific feature may work.

From this perspective, wireframing is as much about the underlying structure of a site as it is about the visual dressing that we drape over that structure. It’s about planning the skeleton or framework on which the site will ultimately be built. And, while this skeleton will be reflected in a visual manner, with a number of sketched or grey boxes arranged in a particular fashion, that does not mean that the wireframes themselves are at all limited to the visual aspect of the site.

When done properly, those boxes tell us more than what kind of grid to use or how many CSS floats will be required. Through their positioning and interaction (and, ideally, accompanying notes), they bring a site’s underlying structure to the forefront. If that structure is solid and logical, then it will be easily be able to accept the aesthetic trappings that will eventually formulate its final apperance.

On the other side of the coin, if there are issues or flaws in that structure, those problems can be readily addressed (and hopefully fixed) at this early stage of the process. This certainly beats having nearly completed the entire design only to discover some fundamental structural flaw that forces you to tear everything apart, fix the problem and then try to put it all back together again.

Wireframing can help you catch these issues early, saving time and precious budget dollars.

Wireframing With HTML

There has been a lot of discussion at different points about the merits of designing in the browser, as opposed to creating flat mockups in an application like Photoshop. There are strong opinions on both sides of the fence. My own view is somewhat less concrete, in that I feel that approaching any new web design project is really a matter of context, and the tools and techniques that I chose to employ will depend on what I am looking to accomplish.

That being said, however, while I may not always start in the browser (or even get to it early), I do feel that it is vitaly important to always be designing with the browser in mind. In other words, to consciously design within the constraints and limitations of HTML and CSS. With new and emerging technologies, these constraints are certainly shrinking, but there remain certain things that we still can’t do (or things that we shouldn’t do).

Moreover, it is important to always keep in mind that when we are designing for the web in the traditional sense (apps, I believe, may be somewhat different in this regard), what we are actually doing is creating the visual skin that will be placed over our standard HTML.

We’ve already touched on how wireframing is very much a matter of creating the initial skeleton or structure for a site. In practice, the HTML that we craft becomes the tangible result of that structure. It the context of the document, it brings semantics and meaning to the content, while simultaneously providing the key hooks that will be required to wrap that same content in the visual layout that we have created.

For this reason, I believe that wireframing and HTML are (or at least should be) fundamentally connected, to the point where I am increasingly finding myself actually writing out simple HTML structures at the same time that I am creating my wireframes. In my experience this has a number of key benefits:

1. It helps remind me that wireframing is about more than just the visual aesthetic of the site.
2. It helps keep my mind “in the browser” so to speak.
3. It helps me think of structure in a broader context. By constantly working out how the layout would need to be represented in HTML, I am better able to consider the placement of my wireframed boxes and make important decisions about the relationships between those boxes, both visually and structurally.

For me, these are all key components to my design and development process—components which help strengthen the quality of my work and ensure that the structure and layout are more than just a cool visual treatment. As such, I plan to continue to pair my traditional, rough pencil and paper wireframing with equally rough HTML structures, especially as I dive deeper and deeper into world of responsive design.

Of course, while the concept of wireframing generally serves the same basic purpose from designer to designer (or team to team), the techniques that are used in the process can be very different. As already noted, I like to work more traditionally with pencil and paper. Some designs will use simple grey boxes in Photoshop or Fireworks, while others will actually use applications and other tools that are specifically geared towards wireframing. Regardless of the technique that is used, I believe that the important relationship between these wireframes and HTML still exists and needs to be considered.

The only “exception” would be for those designers who wireframe by creating basic, lightly styled HTML documents right out of the gate. Of course, in these cases the exception is not that HTML should not be considered, but rather that it is no longer a matter of considering the relationship between two seemingly autonomous elements. Instead, the HTML is the wireframe, which only serves to further underscore the point that I’ve been driving at through the entire article: that a thorough consideration of HTML should be an integral part of any wireframing process.

How that manifests itself is up to you.

For those readers who may not be all that familiar with wireframing, feel free to check out Grace Smith’s “Get Wireframing: The All-In-One Guide” for a full complement of resource materials. There are all kinds of wicked resources to help get you started, or to help you dig deeper into the concept.

article photo my sonali sridhar

Exclusive Content

To thank you for subscribing to my feed, I am including exclusive, feed-only content for you at the bottom of each post!

Current Freebie Code - 7ev165dd

Semantics, semantics, semantics—sometimes it feels like it has become just another clichéd buzzword that we like to throw around the web these days. Obviously it’s more than that though. Semantics has everything to do with meaning. More specifically, in the context of web design/development and the deployment of markup, it has to do with meaning in a very particular context.

I’ve always tended to think of semantics in web design as being primarily a means of accurately describing content. In fact, that’s how I have described HTML to a number of the people who have asked me questions as they were getting started using the language. The tags in which we wrap our content essentially describe what the content is, and as the sort of person who obsesses over grammar, structure and the meaning instilled by language, this is a huge part of the reason that I preach the necessity of using the correct tags in your HTML.

Using the wrong tag is basically telling us that the content is something that it’s not.

This understanding of semantics is, well, primarily semantic. In other words, it concerns itself with meaning for meaning’s sake. Yeah, trust the guy with the English degree to make that argument.

There are others on the web, however, who (being far more intelligent than I) look beyond the semantics of semantics and theorize the concept of what they call the Semantic Web. All the way back in 2001, Tim Berners-Lee, James Hendler and Ora Lassila authored an article published in Scientific America about this very topic. Simply entitled “The Semantic Web,” the article envisions meaning (semantics) as becoming the common bond the would bring information from different and even unrelated sources together in a way that could be readily processed by software, due simply to the common shape of meaning. In the article, the authors write:

The Semantic Web will bring structure to the meaningful content of Web pages, creating an environment where software agents roaming from page to page can readily carry out sophisticated tasks for users.

It is a fascinating idea, and though we will probably get there one day, I don’t think we’re there yet. There are probably thousands of semantic “content pockets” all over the web, but the glaring inconsistencies between sites and other data models are probably still polluting the waters too much for any truly extensive semantic tasks to be readily performed by the envisioned “agents”

That being said, however, it is still a good practice to work at creating the most semantically accurate code that we can today. It is important simply for the sake of meaning, but also to train ourselves for the day when semantic coding will be more than just a best practice that we as web designers and developers like to talk about amongst ourselves. The chances are very good that one day, semantics will become a true requirement.

But What about Forms?

Yes, this article is about forms. We’re getting there.

If you follow me at all on Twitter, you may have seen that I am currently working on an application called Survd, which will allow users to create and manage surveys (on other data collection forms) right from their own websites. As such, I’ve been spending a lot of time working with forms lately, and it occurred to me that, up to now, I had not been creating forms that were quite as semantic as they could have been.

Why, you ask?

Simply because I had previously been unaware of a somewhat obscure little attribute of the <label> tag, called “for”. In a nutshell, this little attribute actually allows us to specifically declare the input field that a particular label actually describes. For example, I could define a label and input in HTML like this:

<label>Name</label> <input type="text" name="name" id="yourname" />

As human beings looking at this, code we can obviously deduce that the label is intended to describe the input field. However, from a purely technical standpoint, the label and the input are not related to each other in any way other than their relative proximity. An extremely intelligent program might be able to correlate the name value of the input with the contents of the label, but what if we had something like this?

<label>What do they call you?</label> <input type="text" name="name" id="yourname" />

Now there is no textual relationship at all. The elements may rest right beside each other in the document, but is it really safe for any program parsing the document to assume that this proximity automatically implies relationship? Probably not. There are too many possible exceptions.

That’s where the for attribute comes in really handy. Now, we can take our same block of code, but add the attribute in:

<label for="yourname" >What do they call you?</label> <input type="text" name="name" id="yourname" />

Instantly, this establishes the desired relationship! The label now explicitly defines the connection between the input and its label through the common value held by the id attribute of the input. Using this attribute also brings the added usability benefit of allowing the user to click on the label to bring focus to the related input element. It’s a small touch, but in many ways, isn’t that what a lot of usability is all about—those small touches that help to make a site or web app super user friendly?

Conclusion

I’m sure that there are plenty of people out there who already knew about the for attribute. Until, recently, I wasn’t one of them. It’s one of those oddly obscure attributes that you don’t read a lot about and which doesn’t do anything overly visible of flashy to draw attention to itself. As such, in my continuing journey of self-education, it was unfortunately something that got lost or glossed over.

I’m glad to have it well in mind now, though, and I hope that those of my readers who were in the same boat as me will also benefit from the knowledge. I’ve already gone back and checked through my comment form on the blog (attributes were already there, thanks to rock-solid coding from WordPress), and will be improving the semantics of all my forms of the future by explicitly linking my labels and inputs.

What about you? Are you so familiar with the for attribute that it’s like second nature to you now? Or, did you come into this article like me, having somehow missed it?

Exclusive Content

To thank you for subscribing to my feed, I am including exclusive, feed-only content for you at the bottom of each post!

Current Freebie Code - 7ev165dd

Recently, one of my awesome Twitter followers was asking me a few questions about getting started with WordPress. From what I could understand, this individual worked for an agency or firm where he created website designs in Photoshop, and then sent the PSD on to another team member in order to have it coded up. Now, he was working on setting up a personal site and, while he could rock off a custom site design, he openly admitted that he knew nothing about coding and asked me for a little help getting started.

After a bit of discussion, I suggested that the best place to begin would be to start learning the basics of HTML, and then CSS. After all, any great theme (WordPress or otherwise), ultimately begins with good, well-formed HTML and CSS.

Still, this interaction got me thinking (as I am prone to do) about the roles of both HTML and CSS within the larger context of a website. Through my contemplation, I began to consciously formulate the thought that, while these two technologies are clearly an important part of web design, they are only ever single pieces of the puzzle. In other words, there’s a lot more to a website than just its markup and style.

This isn’t some sudden realization that is going to dramatically change the way that I approach web design. I wouldn’t even say that it’s really anything all that new to me. It’s more like putting a structure to something that’s always been in my mind, but which I have simply never articulated. So, in this article, I would like to undertake that articulation, and offer my own understanding of what defines the a website. I think it might be valuable.

A Page vs. A Site

One of the most important distinctions, and probably the best place to start, is by differentiating the concepts of the web page as opposed to an actual website. A web page is what’s loaded in the browser, and is generally a combination of text, images, video and other content. HTML gives the page its structure, while CSS provides (or should provide) the visual appearance.

On the other hand, a website at its most fundamental level can be understood as comprising a network of individual pages, which are all linked in some (usually) logical and predictable manner. Back when I first started this web design thing, most sites were comprised of a number of unique and separate HTML documents, all located in the same folder, or within a hierarchy of folders, and each containing links to many (and sometimes all) of the other pages that made up the site.

Today, of course, things have become a bit more ambiguous, with the introduction of content management systems and dynamic content fed to us through technologies like jQuery or AJAX. When using a system like WordPress or Concrete5, we’re not focusing on creating static pages (though they may be generated behind the scenes for caching purposes). Instead, we build theme and template files, which have designated content areas that are populated with data extracted from a mySQL database.

From a maintenance perspective, this kind of thing is certainly a godsend, since we don’t have to manually go through hundreds, or even thousands of individual pages to make a single change to the design. Fundamentally, though, it doesn’t really change the way a website is structured.

Whether we are looking at a site comprised of static HTML documents or one that is fully CMS-driven, we still have “pages” that exist at unique URLs. The content found at these URLs may vary significantly on some sites, like Facebook – where the home page features different “news” everyday, for every different users – but the basic concept of structure still exists. Our profiles have the same URLs, as do our Fan Pages. The content simply varies based on what our “friends” are doing.

This distinction, though not perfect (as we shall see below), is an excellent starting point, as it emphasizes the importance of the unity of a site.

Unity

But what about single page websites? There are thousands and thousands of such pages out there, featuring all of the important content within a single HTML document, elegantly styled with CSS. Do these sites contradict everything that I have been suggesting so far? Or, am I somehow suggesting that single page websites are not, in fact, websites at all?

I would say no on both counts.

I will admit that this idea did make me stop and ponder these very same questions. After some contemplation, however, I reasoned that there is nothing that necessarily requires a website to have more than a single page. In looking at both the fact that most sites do have multiple pages, and the obvious success of single page sites, I would actually suggest that a website comprises the entire collection of unique URLs that exist for a given location on the internet (which could be an complete domain, a particular subdomain or even an individual folder).

To take this back to the original premise on which we began this discussion, we can think of a website as a singular unit, which ultimately equals more than the sum of its parts. It’s kind of like looking at a MacBook (or any other kind of technology). Taken on their own, its individual parts really aren’t worth all that much. Taken together, however, these parts create the powerful machine, and a popular tool among many of you designers out there.

A website is much the same. CSS without HTML is entirely meaningless, while HTML without CSS is extremely plain and unattractive. JavaScript and its various frameworks can’t accomplish all that much outside of the DOM. When it comes to content management systems like WordPress, the mySQL database is useless without the PHP (or other sever side language) to extract the information, and the PHP itself needs to generate HTML (usually through a template) in order to display that information in the browser. And, of course, this entire network of technologies means absolutely nothing to the user without content.

So, when a website is working properly, all of these different elements come together in (what should be) a beautiful symphony of interaction and interrelationships that from the backbone of the interface that you design to connect your users with your content. At the same time, that content – represented by either a single page or a network of pages – also works together to round it all off and complete the entire, unified package that is the website.

Clearly, then, a site is much more than just its HTML and CSS.

Purpose

There is, however, one more piece to this website puzzle. Even after all the technologies have been accounted for, and we’ve grasped the important role of great content, there still remains one important concept to consider. That concept is purpose.

Every website should have a purpose. It may be to inform potential customers about your business (probably one of the most common types of websites). It may be to function as an informational resource. It may be to connect people with other people. It may be to showcase yourself, or even simply to entertain. Whatever the purpose is, it is ultimately the core of the site, the nucleus around which everything else that we have looked at so far is ultimately wrapped.

However, while HTML and CSS do not a website make, when it comes to this question of purpose it is entirely possible to build a beautiful, functioning website full of content, but which ultimately has no real purpose. Unfortunately, this well crafted but purposeless website is more than likely destined fail and fizzle even faster than a poorly designed site with a clear and identifiable purpose.

Implications on Design

As I mentioned earlier, I don’t think that there is anything all that revolutionary or earth shattering to what I am saying here. Most competent web professionals will probably read all of this and find that they already knew it. But the point isn’t whether you know it; the point is whether or not you think about it.

Sometimes, it seems as though our design processes can fragment what is ultimately intended to be a unified product. The typical process that I seem to see from the design community goes something like this:

1. Simple wire framing on paper (maybe)
2. Design in Photoshop
3. Code up the design in HTML and CSS
4. Develop a theme from the HTML and CSS
5. Install the CMS
6. Import content
7. Find another client and repeat

At each stage, we tend to be focused on one or two parts of the larger project, and I have to wonder how much time we spend thinking about the other parts. For instance, if you’re working in Photoshop, are you already looking down the line, towards coding the HTML and CSS? Are you considering the specific capabilities of your CMS? Have you even decided on a CMS yet (assuming that you don’t always use the same one – which I don’t)? How do the answers to these questions ultimately inform the design decisions that you are making from inside Photoshop?

Asking yourself these questions can certainly make your job easier (or your developer’s job, if you only do the Photoshop layout), but they can also serve an even more important role, by bringing all the pieces of the puzzle together, and forcing you to consider the website more as a single entity rather than a collection of separate pieces.

I think that’s where this discussion becomes truly important. The more you consider the website as a whole at each individual stage, the better equipped you will be to make choices that will ultimately help the site succeed by achieving its ultimate purpose. It’s all about unity.

What do you think? Do you consider the website in its entirety through every stage of your process? Do you have anything that you’d like to add or argue against? Be heard! Leave a comment.

Exclusive Content

To thank you for subscribing to my feed, I am including exclusive, feed-only content for you at the bottom of each post!

Current Freebie Code - 7ev165dd

Earlier this week, I posted an article by Amber Weinberg, entitled “Should Designers Know How to Code? Thoughts From a Developer.” In that article, Amber writes about her own experiences as a front-end developer and comes to the basic conclusion that, while not all designers actually need to code their designs, they should understand the basics of what is and is not possible (or at least desirable) when it comes to web design.

Language and Metaphor: An Alternate View on Coding for the Web

She also notes that coding “is another language.” As a designer with a background in literature, this just added fuel to something that I had already been thinking about: namely the idea of how coding languages like HTML, CSS or JavaScript are related to human languages like English.

I’m no master coder, but I’ve been working on websites for well over 10 years now, and in my experience there are essentially four types of languages at work on the internet (both font-end and back-end). These include mark-up, style sheets, programming and database queries. Each type of language has a different general purpose, which is actually reflected in its general syntax and structure. In this article, which will be the first in a two part series, I want to look at these four types of coding languages, and consider their purposes through various metaphorical comparisons to human (written/spoken) language.

Some Thoughts on Language

First, though, I would like to consider the more general purpose of all languages, which is to communicate. For the purpose of this article, I have a series of ideas that I want to present to you, my readers. To do so, I carefully select strings of words and punctuation with which to form sentences. These sentences then form paragraphs. As you read, you recognize the words, then the combination of words, the sentences and so on. As you recognize, you interpret and as you interpret, you derive meaning.

If the language is used properly (and I hope that it is), the message that I want to convey is delivered from me to you.

This is the fundamental purpose of all language, and the various coding languages that we are going to look at are really no different. Each exists to communicate some message from one entity to another. The differences emerge in the form of what those entities are, and the message that is being communicated.

Mark Up – Descriptive Language

Let’s start with the granddaddy of all web language types: mark-up. The most common form of mark-up has to be HTML, in its various forms and derivatives. That’s where I started with coding for the web, and I’d say it’s a pretty safe bet to say that it’s where almost every other web developer started too. Other forms of mark up include XML, or the hybridized XHTML, which is essentially just HTML that conforms to the more rigid syntactical rules of XML.

HTML is probably the most well known form of mark-up

Regardless of what specification we’re talking about, though, the purpose of all markup – in it’s purest form – is simply to describe content. A document is marked up with various tags, which should do nothing more than indicate the purpose of each part of the document. Consider this simple example.


<h2>Introducing <i>The Second Dive</i></h2>

<p><i>The Second Dive</i> is a completely fictional novel that I have made up to write this simple paragraph about. There may actually be a novel titled <i>The Second Dive</i>, but I have never heard of it, so I am just going to write this out for a few more words. Now it is finished</p>


What we have here is just some really basic HTML (without the proper document tags, of course). First, we define a second level heading with the <h2> tags (opening and closing). Everything that falls between these tags is considered a second level heading. Next, we define a single paragraph using the <p> tags. Again, everything between those tags is considered to be a single paragraph.

You will also notice that I’ve used the <i> tag, which indicates that its contents should be italic. I’ve done this because it is proper to set the title of any novel, film, play or other “long” work in italics. I’ve also done it because it gives me a great excuse to talk about description versus formatting.

Remember, mark-up is a descriptive language, and each tag is like a different description. We could also use the <cite> or <em> tag to make something appear in italics, but those tags have different meanings than the <i> tag. The <em> tag is basically saying that there should be emphasis placed on its content. Conversely, the <cite> tag defines its content as the citation for a quote.

Neither of these apply to our title. We don’t want the title to be emphasized, and it’s not quite a citation either. As such, the <i> tag likely provides the best description for the title of our fictional book. Since mark-up is all about describing our content, then, the <i> tag is clearly the best choice!

Styles – Sensory Language

If mark-up is basic descriptive language, style sheet languages like CSS (Cascading Style Sheets) are the sensory language that gives life to that description. As such, it is an add-on type of language, that expands the description of a given element.

I like to think of it like this. Mark up is like a noun, which literally states what something is. For instance, I can point to an object and state that it is a car. In doing so, I have described what it is, and (if you’ll allow me to extend the metaphor) “marked it up”.

CSS adds on to the structure created by HTML mark-up

Styles, however, are more like adjectives, which add extra values or properties to the noun. Now, if I point to the same object and state that it is a large, red car, the basic understanding of what the object is doesn’t change – it is still a car. However, we also have additional descriptive information that tells us that it is large and red.

We can think of styles in much the same way. They hook into HTML and add in various bits of information (predominantly for visual rendering) that exist independently of the mark-up itself. For example, this following rule would add extra information to the second level heading from the our HTML sample:


h2{
  color: red;
  font-size: 1.3em;
  font-weight: bold;
}


In a nutshell, this styling indicates that all <h2> tags are also to be coloured red, rendered at 1.3 times the basic font size and to be bolded. To translate into relative English, whenever a browser sees and <h2> tag, it understands and renders the content as a large, red and bolded second-level heading. The style adds to the mark-up to make it richer.

A One Sided Relationship

It also helps to understand the relationship between mark-up language and styling language as being entirely one sided. Styles cannot function without mark-up, but the reverse is not exactly true. Let’s look at another literary example. Currently, I am reading the novel The Awakened Mage by Karen Miller. Allow me to quote the opening passage.

With one callused hand shading his eyes, Asher stood on the Tower’s sandstone steps and watched the touring carriage with its royal cargo and Master Magician Durm bowl down the driveway, sweep around the bend in the road and disappear from sight. Then he heaved a rib-creaking sigh, turned on his heel and marched back inside.

Now, let’s look at the same passage with all of the adjectives (or adjective-like phrases) removed.

With one hand shading his eyes, Asher stood on the Tower’s steps and watched the carriage with its cargo and Master Magician Durm bowl down the driveway, sweep around the bend in the road and disappear from sight. Then he heaved a sigh, turned on his heel and marched back inside.

It’s not much different, and still completely readable and understandable. It’s just missing some of the finer details that help contribute extra meaning to the passage. Now, let’s look at it with the nouns (and pronouns) removed.

With one callused shading his, stood on the and watched the touring with its royal and bowl down the, sweep around the in the and disappear from. Then heaved a rib-creaking, turned on his and marched back inside.

Without the nouns, the paragraph becomes completely non-nonsensical and looses all meaning, and the adjectives have absolutely nothing to work on. The same concept applies to HTML and CSS. While HTML can exist without CSS and still make sense, CSS without HTML is like throwing a bunch of adjectives onto a page without a single noun to give them context.

Which, of course, serves to emphasize the importance of the mark-up over the styling in design. Good, clean and well-structured HTML should always proceed the creation of equally good, clean and well-structured CSS.

Scripting – Directive Language

With that little aside out of the way, let’s get back to the matter at hand and look at the next type of language: scripting, which could also be called programming. This one probably has the largest series of specific languages that fall beneath it, including JavaScript, PHP, Perl, ActionScript and so forth. Each of these languages are unique in their own right, have varying syntax, functions, methods and core functionality.

JavaScript is a popular form of scripting

However, like all programming languages, they share the common bond of being procedural, or as the title to this section suggests, directive. The purpose of any script is to provide a series of directions which, when followed, will yield a desired result.

This differs dramatically from mark-up and styling languages, which describe what something is and what it is like. Directive or procedural language is more like the instructions that came with your last IKEA purchase (though hopefully vastly more helpful). For example, here is the code for a simple JavaScript function.


function doSomething(myValue){
  newValue = myValue+5;
  newValue *= 2
  newValue /= 3
  alert(newValue)
}


If you don’t understand JavaScript, this function is basically a series of instructions, that go something like this:

• accept a value
• add 5 to that value
• multiply the resulting value by 2
• divide the resulting value by 3
• display the resulting value through an alert box

That’s it – just a simple set of procedures acting upon a given value. And that’s really the basic premise of all the programming or scripting that I have ever done. It’s just a matter of writing a series of steps that explain to the computer how to accept, transform and return various bits of information.

Obviously, I’m simplifying a little bit, but probably not as much as some people might think. If you can write a basic set of directions about how to get from your house to your favorite pizza joint, you’ve already written a basic non-computer-based program. To move to programming on the computer – and specifically on the front or back-end of a website – is just a matter of learning how write appropriate commands in the right language!

Query – Request Language

Last of all, we have query languages, or what I am calling request languages. Chances are that many of you will never even need to work with this kind of thing, but I think that it’s at least important to know that exists. Basically, a query language, like SQL, is a way for a program or application to communicate with a database, appending, extracting or modifying information within specific tables.

The popular phpMyAdmin system uses SQL to manage databases

I like to think of it kind of like a grocery list. Let’s suppose you want milk, bread, peanut butter and some eggs from the grocery store. You write this all down on a list, give the list to your significant other and send them off to the store. Your significant other (being so kind), enters the store, checks the list, retrieves the appropriate items and finally returns to you with everything you asked for.

That’s pretty much exactly what a query language does, except that instead of a store, it’s a database, and instead of groceries, it’s retrieving data. Here is an example of an SQL command for extracting data from a standard WordPress database


SELECT `post_author` , `post_content`
FROM `wp_posts`
LIMIT 0 , 30


Basically, this list is saying that we want the information from the post_author and post_content fields in the wp_posts table. It also imposes a limit to only retrieve the information from the first 30 records. Just like a grocery list.

Admittedly, though, the grocery list metaphor is not perfect, since query languages like SQL can do so much more than just retrieve data. They can also add, remove, move and update data across multiple tables. Still, the basic concept is the same. The query has a single directive (select, add, drop etc), a listing of various bits of data and optional conditions to dictate and/or restrict what data is to be handled.

In one basic sense, a query can be similar to a script in that it dictates a command, and can actually contain some basic functions to manipulate the data. However, they key difference lies in the fact that a query only ever has a single command (though that command can be extremely complex), whereas a script or program generally contains multiple commands, which form the bulk of the procedure.

Conclusion

So there you have part 1 of this series. I hope to have accomplished something here for both coders and non-coders alike. For designers who don’t know how to code their own designers, I hope that this article has shed some light on the different types of coding languages that exist on the internet, and perhaps provided you a context through which to understand their various and different functionality within a website.

For coders, I hope to have provided a similar context, and allowed you to look at what you do from a different, language-based perspective. At the very least, I hope that I may have provided you with some helpful metaphors to help explain what you do to family in friends!

Of course, as I’ve already mentioned, this is only part 1 of a two part series. The second article will follow early next week, and will draw further parallels between scripting languages and the written language, including the roles of logic, syntax and grammar, and why they are all important.

In the meantime, though, I’d love to hear your thoughts on this one. Which types of coding are you the most familiar and/or comfortable with? Is there another type of language that I missed (I hope not), or a different metaphor that you think better explains one of the four types outlined above?

Exclusive Content

To thank you for subscribing to my feed, I am including exclusive, feed-only content for you at the bottom of each post!

Current Freebie Code - 7ev165dd