Advertise here with BSA

There are a whole slew of developers writing amazing and practical code and there are thousands of public code repositories on sites like GitHub. Meanwhile, the rest of us are content with just cutting and pasting the code of these industry geniuses.

For the majority, it seems that true coding has become a lost art. Almost every project, it seems, now uses some sort of library/framework or contains a heap of plugins.

It’s rare to see any front-end coding project truly start from scratch anymore.

In this article, I thought I would give some somewhat off-the-wall tips on improving your skill as a front-end coder.

These tips will likely not be used when coding paid client projects where time and budget are factors. These are tips that we can put into practice in our own personal projects or in our spare time to try to improve our coding abilities and problem-solving skills.

While I do think the tips below can contribute to a developer becoming a stronger coder, they may not always be practical.

1. Write Your Own Framework

As mentioned, there’s almost no such thing as a from-scratch project anymore. Everything starts with some kind of code base or boilerplate. Even industry leaders with cream-of-the-crop engineers like Google have leveraged open source JavaScript frameworks such as jQuery.

On the back-end, you’ll probably be using something like WordPress or another CMS. On the front-end, you’ll likely be including your favorite JavaScript web development library/framework and a CSS reset.

Forget those bloated things. Write your own code base instead and adapt them to your own needs. Yes, something like this will probably take you many hours, and potentially weeks or months.

You’ll likely end up scrapping the whole thing and never using it on a real project. But you’ll have no choice but to learn how to do it, even if that means doing it badly.

It’s a daunting task, but something that will reap great benefits. You’ll understand the language’s syntax better, the concepts will become clearer, and your problem-solving skills will improve.

Even if it’s something small like your own tiny JavaScript library (e.g. a JavaScript animation framework) that has a half-dozen modules, it will be well worth the effort.

It might even be a good idea to keep this type of thing as an indefinite project that’s continually on going. You can keep going back to it, improving it, learning new lessons and adding new features. It probably still won’t be as good as the popular, open source ones out there, but you’ll probably learn more than you ever would otherwise.

2. Don’t Use Developer Tools

If you’re like me and you run into a scripting problem or a selector specificity issue in CSS, the first thing you might turn to is some developer-related tool like Firebug, Web Developer extension, Google Chrome’s Developer Tools and the like. For instance, Firebug provides invaluable features for tracking down and fixing almost any front-end coding issue.

However, remember that tools like Firebug are fairly young. Developers in the late 90s and early 2000s didn’t use these types of robust tools.

Although those rudimentary development techniques might be considered "slow" by today’s standards, the developers that used such archaic debugging methods understood their craft as well as anyone.

If you can debug a CSS or JavaScript problem without using any special tools, then that shows you have a solid understanding of CSS and some of the deeper parts of JavaScript.

This topic, specifically in relation to debugging tools, was covered by Jens O. Meiert and I wholeheartedly agree with his theory.

Sure, you won’t solve any problem as quickly as you would with Firebug or your favorite developer tools, but there’s a good chance you’ll learn more and avoid making the same mistake again in the future.

3. Don’t Use a Browser

Creating websites without testing them in their environment? Did I mention that these were crazy coding tips?

Well, customarily, if you’re developing a CSS layout or some kind of JavaScript functionality, it’s pretty common to switch back and forth between editor and browser, checking your stuff as you go.

Instead, try this exercise some time: Code an entire web page layout or JavaScript widget without checking it in the browser until you’ve completed the whole thing. This will cause you to stay focused the entire time, ensuring that every line is coded properly. And you’ll be forced to visualize the outcome of your code.

From my experience, being able to visualize the results of the code you write is an important part of understanding it. Ignoring, to some degree, the actual output forces you to think through your code line by line, and this will help you understand every bit of it more fully.

4. Don’t Use a Code Generator

This tip is especially important for learning the ins and outs of CSS3. There are dozens of CSS3 gradient generators, button makers, and other tools that can help you write CSS faster. Those are useful, especially when you’re facing a deadline.

A CSS3 gradient generator can be useful, but can also hamper learning of underlying style sheet concepts.

But if you take the time to type every line of CSS3 manually, you’ll be forced to learn all the different parts of the various syntaxes.

Take for example the simple box-shadow property (example below):

.shadow {
  box-shadow: 4px 4px 8px rgba(0, 0, 0, .2);
}

If you’re using a code generator to spit out that code, then you’ll take much longer to get used to what each of those values represent.

On the other hand, typing it manually likely means you’ll have to check a reference or even the CSS3 W3C specification draft. All of this will lead to a better understanding of how the code works.

5. Type Book Code Examples By Hand

Pretty much every computer programming book written nowadays will include a code archive that’s available for download or on an accompanying CD. This is great. But how much can you learn from copying and pasting so much code?

So forget about the code archive. If you have the time to do an in-depth study of the material in a book, complement such study by typing all the examples by hand, then test them to ensure they’re working properly.

This will have a number of positive effects on your coding abilities. It’s inevitable (especially if the concepts are new to you) that you’ll type a lot of things incorrectly, leading to error messages. This will force you to have to pore over the code examples in the book while comparing them to your own until you find any problems.

You’ll be debugging code almost immediately after learning it, and I’m sure we can all agree that many of the most important coding lessons are learned when debugging. You might also find errors in the code printed in the book, so this presents further opportunities for getting a stronger understanding of the concepts involved.

Even more crazy: You might want to do the same thing with code examples you find online in tutorials and articles. Don’t copy and paste them, but instead, type them manually. Again, you’ll see many of the same benefits mentioned above.

6. Use a Vanilla Text Editor

What I mean by "vanilla" is a text editor that has no helpers or auto-complete functionality. Or else you could just turn off any auto-complete functionality your editor has, and pretend you’re using something like the Windows-based classic Notepad.

I used to code classic ASP-based websites in the early 2000s, and for a number of years I wrote all my code (front-end and back-end) in Windows Notepad. Although there were times when this seriously slowed me down, I learned to write a lot of it from memory, and I was able to debug pretty much anything without any special tools.

If you get zero help from your editor when writing code, you’ll be forced to memorize much more than you would otherwise.

7. Re-Invent the Wheel

Whatever project you’ll be working on next will likely require something that’s been written a million times before. It could be a lightbox, a content or image slider, a photo gallery script or a tab switcher.

Almost every developer will tell you you’d be crazy to write one of these yourself. But think about it: Do you know how to write (for example) a lightbox function in JavaScript? If you don’t, then how would you ever learn?

The concepts you’ll pick up from these activities will have tremendous long-term value.

It’s ridiculous to never re-invent the wheel. If you spend your entire developer career cutting and pasting other people’s code, then you’ll only make minimal progress at best.

Of course, if you do write your own lightbox script, it will probably be one of the worst lightbox scripts ever. But who cares? You’ll learn a ton of stuff along the way, and you could always go back to it later and see if you can’t make any improvements and optimizations that you might have picked up elsewhere.

Conclusion

As I mentioned early on in the article, these aren’t going to be the kinds of tips you’ll want to use regularly or on important projects. But if you have some time to spare, use some of this advice — even if you’re just applying it in a small way.

In my opinion, these crazy suggestions will help you develop your own coding style and you’ll have a better understanding of the underlying concepts of the code you’re working with.

Related Content

• 10 Ways to Be a More Productive Web Developer
• Tips on How to Code Web Designs Better
• 5 Good Habits That Will Make You a Better Coder
• Related categories: Web Development and Web Design

About the Author

Louis Lazaris is a freelance web developer based in Toronto, Canada. He blogs about front-end code on Impressive Webs and is a co-author of HTML5 and CSS3 for the Real World, published by SitePoint. You can follow Louis on Twitter or contact him through his website.

Advertise here with BSA

Web analytics is a powerful tool made accessible to all of us through awesome free software such as Google Analytics. These tools are designed to satisfy the general needs of every kind of website out there.

That’s why website analytics tools, in general, are very good at offering a fundamental overview of traffic data of a site, but not so good when it comes to answering specific questions.

To get specific questions answered, sometimes you have to work around limitations of your current software.

As a proof of concept, I’ll present three examples/ideas for gathering more information in conjunction with Google Analytics.

The purpose of this article is to present some starting points for your further exploration.

Example 1: Where Do Users Come From?

Google Analytics (and other web analytics tools) does a great job of telling you the last web page the user clicked on that got him/her to your website. This last web page is often called the referrer or referral path.

Knowing where the user was before visiting your site is helpful because you can use this data to analyze and understand how people are getting to your site.

The problem, though, is that not all visitors become customers/users on their first visit to your website. In most circumstances, the majority of customers visit a website a few times before deciding to buy something or become a regular visitor.

Taking action based only on the last referral path, as reported by tools like Google Analytics, might leave many opportunities on the table and might not give you enough actionable information.

Hacking Google Analytics to give you all the referrers of each visitor proves to be pretty difficult, and the reports you get still won’t answer all of your questions.

Here is how you could do it better:

1. Each time a visitor gets to your website, Google Analytics will look at his referral and note it down in a specific cookie called __utmz.
2. A JavaScript hack can help you copy that referral information on another cookie that is managed by your website, and not by Google Analytics.
3. Each time a visitor gets back to the website, Google Analytics will rewrite its own cookies. The JavaScript hack will update (not rewrite) your website cookie by adding the new referral next to the old one.
4. When a visitor becomes a customer, upload the content of the new cookie to your database, next to your customer details.

Below is a sample of such a script. Feel free to experiment and fine-tune it.

function createCookie(name, value, days) {
  if(days) {
    var date = new Date();
    date.setTime(date.getTime() + (days * 24 * 60 * 60 * 1000));
    var expires = "; expires=" + date.toGMTString();
  }
  else {
    var expires = "";
  }
  document.cookie = name + "=" + value+expires + ";domain=" + window.location.hostname + "; path=/";
}

function readCookie(name) {
  var nameEQ = name + "=";
  var ca = document.cookie.split(';');
  for(var i = 0; i < ca.length; i++) {
    var c = ca[i];
    while (c.charAt(0) == ' ') c = c.substring(1,c.length);
    if (c.indexOf(nameEQ) == 0) {
      return c.substring(nameEQ.length,c.length);
    }
  }
  return null;
}

function googleCookieReferrer() {
  var feed=readCookie("__utmz");
  // If the utmcsr is not found, cancel
  if(feed.indexOf("utmcsr")==-1) {
    return null;
  }
  if(feed != null) {
    // New version cookie
    if(feed.indexOf("%7C") != -1) {
      feed = feed.split("%7C");
      feed = feed[0].split("%3D");
    }
    else {
      // Old version cookie
      feed = feed.split("|");
      feed = feed[0].split("=");
    }

    if(feed[1] != "") {
      return feed[1];
    }
    else {
      return "";
    }
  }
  // Read the Google cookie, and extract the utmcsr parameter from utmz
  var referrer=googleCookieReferrer();
  // If the Google cookie was successfully read, and utmcsr found
  if(referrer != null && referrer != "") {
    // Read our cookie if it exists
    if(readCookie("__rfrr")) {
      // Cookie data
      var feed = readCookie("__rfrr");
      // Temp cookie string
      var feed_temp = feed;
      // This will hold the last referrer in our cookie
      var check = "";
      // Split the data in our cookie
      feed = feed.split("|");

      // If it's the first element, it's a string
      if(feed[feed.length-1] == null) {
        check = feed;
      } else {
      // If multiple elements, it's an array, so get last array item
        check = feed[feed.length-1];
      }

    // If last element != referrer: write cookie and add new referrer
    if(check != referrer) {
      createCookie("__rfrr",feed_temp+"|"+referrer,365);
    }
    // If no cookie found: create and populate
    else {
      createCookie("__rfrr",referrer,365);
    }
  }
}

Once the script is in place, you’ll be able to answer the following questions:

• Who are the referrers that drive the most sales (no matter if it’s the first click, the last click, or somewhere in the middle)?
• Who are the best first-click referrers that bring converted visitors to the website?
• Which referrers do the best job of getting visitors back to the website and convincing them to buy?

Example 2: How Much Do Customers Spend?

The number one question I get from my clients who use Google Analytics ecommerce tracking is: Why are there more/less money or orders shown by Google Analytics than in reality?

The answer: Google Analytics is not an accounting application, and it will almost never show exact figures of your sales. Charge backs, tracking code issues and ecommerce implementation not covering all payment methods are just a few reasons why the information provided by Google Analytics will not be precise.

Here is how you could do it better:

1. In the admin area of the website, create a special page for reporting sales (if you don’t already have one). Report from your own database figures; include data such as daily sales, orders or average amount paid per order.
2. Having in place the above JavaScript hack (example 1), add the referrers reports for your orders.
3. Add some Google Analytics API queries and display behavior data of converted users compared to website average: time spent on site, number of pages, countries or anything else that’s important to your business (i.e., key performance indicators — otherwise known as KPIs).

You’ve just created a professional dashboard for your business that will give you a clear and reliable view on what’s happening.

Example 3: How Successful Is Website Personalization?

Personalizing the experience of your website visitors can bring positive results. For example, according to a Fast Company article, Yahoo!’s personalization algorithm was a key contributing factor to a 270% increase in clicks on the site’s home page compared to 2009.

Here are just a couple of examples on what you could do to personalize experiences for your visitors:

• Display personalized messages and call-to-actions to your visitors, based on their referral path. You can start with specific messages for users that come from advertising campaigns by offering them exactly what they’re looking for based on the ad campaign they clicked on.
• Change your home page content based on previous behavior (make it an opt-in or opt-out action for your visitors when they sign up, to respect their privacy). Some more advanced coding might be needed, but it would be worth it.
• Invite engaged users to your website to subscribe to your newsletter (my company built an online app for this, called PadiAct) or RSS feed, based on their behavior.

Each website has many keywords that drive visitors from search engines on pages that aren’t immediately relevant for those keywords.

With the next add-on to the previous hack, you can display a nice bottom overlay to your visitors that would contain just the information they are looking for. Now that’s good targeting!

// Add this to extend the code in Example 1
function googleCookieKeyword() {
  var feed = readCookie("__utmz");
  // If the utmcsr is not found, cancel
  if(feed.indexOf("utmctr") == -1) {
    return null;
  }

  if(feed!=null) {
    // New version cookie
    if(feed.indexOf("%7C") != -1) {
      feed = feed.split("%7C");
      feed = feed[3].split("%3D");
    }
    else {
      // Old version cookie
      feed = feed.split("|");
      feed = feed[3].split("=");
    }

    if(feed[1] != "") {
      return feed[1];
    }
    else {
      return "";
    }
  }
  else {
    return "";
  }
}

// Read the Google cookie and extract the utmcsr parameter from utmz
var referrer = googleCookieKeyword();

if (referrer == "YOUR_DESIRED_KEYWORD") {
  // Add your code for displaying the content you desire here
}

Conclusion

Actionable web analytics is not something that should be left to generic tools and data-gathering methods. You’d be happy to know that it’s also not something exclusively affordable only to large companies with big budgets.

As long as we can do some basic coding — and as long as we are devoted to meeting the goals of our website — nothing can stop us from hacking our way to great solutions and innovative workarounds.

I hope this article has inspired you to look into how you can gather richer and more refined data from your own analytics software.

Related Content

• Search Analysis with Google Analytics
• Designing By Numbers: Data Analysis for Web Designers
• Using Charts and Graphs for Content
• Related categories: Web Development and Tools

About the Author

Claudiu Murariu is a web analyst and co-founder of PadiCode, a company building conversion optimization tools. Claudiu can be found on Twitter (as @padicode) and on his conversion optimization blog.

Advertise here with BSA

One of the biggest hurdles when developing a website in Drupal is the initial setup and configuration. Out of the box, Drupal isn’t exactly "end-user friendly".

If you’re like me, and you need to set up sites with a non-developer end-user in mind, there is a lot of face lifting that needs to be done before Drupal is presentable in a simple, easy-to-learn way.

Below, you’ll find some recommended Drupal modules that will extend the core installation in order to make content management easier for site owners as well as, you, the developer who builds sites using Drupal.

Background

I tend to use Acquia Drupal (a free packaged installation of Drupal) on all of my sites. It comes with a lot of handy modules right out of the box that Drupal core doesn’t provide you. It’s a good starting point.

I noticed patterns in most of the sites I set up, so I created an installation profile to streamline the configuration process. (It’s more of an advanced topic, but ask me about it in the comments if you’re interested.)

The modules covered here are must-haves for any standard setup and configuration of a site built in Drupal 6.

While Drupal 7 has rapidly become the center of attention in the Drupal community, I think it’s important to pay homage to Drupal 6. After all, it’s given us three years of solid, reliable site-deployment power. It also has more modules than Drupal 7, making it the only viable option for some sites.

We’ll cover Drupal 7 modules in another post.

I have divided the modules in these categories:

• Content management
• Content editing
• Multimedia content
• Site administration
• Tools for developers

Content Management

We can enhance the way site owners create, present and manage their content through the modules below.

CCK (Content Construction Kit)

CCK is a must-have module for any custom content configuration. This module has become a part of Drupal 7 core (it’s that important).

CCK allows you to add content types as well as additional fields to existing content types. If your site has the need for a blog, or a staff list, or an events area, CCK can help you create a whole new type of content.

I’ve found that making the distinction with separate content types has worked a lot better than using other methods, like taxonomy.

A few additional modules I use in conjunction with CCK that make things even easier are:

• Email
• Phone Number
• Location

Multiblock

One of the huge criticisms of blocks in Drupal is that, with larger sites, you often get to a point where there are just too many blocks that they become unwieldy to manage. Your block list becomes cluttered and it starts to make things really confusing.

To make matters worse, blocks are only able to have one instance. This works fine when you want a block to appear in the same region on multiple pages, but it falls apart when you want to add the same block in multiple regions.

Multiblock solves this issue by creating more than one instance of a block and allowing you to add it to multiple regions. This helps us cut down on repetitive blocks. This also makes training end-users a lot easier.

Trigger

Trigger is a Drupal core module, so it’s included by default. It tends to be a module that many Drupal developers overlook, but it’s powerful and deserves props.

Trigger allows you to fire off certain actions based on events that take place on your site.

Trigger comes with a standard set of actions, but you can also create your own actions as well. For example, if you want a user to be redirected to a specific page upon registering for an account on your site, you can create a trigger.

Trigger: it’s what’s for dinner.

Views

I don’t care what anyone says, the Views module is the most powerful module available for development in Drupal.

You will likely need it for every site you will build and deploy. The Views module allows you to organize, order, specify and manipulate content on your site using specifications you control.

Views can generate anything from simple news lists to complex sidebars that only show up on specific pages. Views can be displayed in page, block, feed or attachment format by default, but other modules have extended these capabilities.

A couple of modules I always use in addition to basic views are:

• Views Slideshow – a rotating slideshow with views.
• Views Attach – for attaching a view to other content.

Pathauto

This module makes URL-generation automatic instead of having to designate a URL for every piece of content you add.

System URLs — the ones that look like http://drupalsite.com/?q=node/123 — are bad for SEO and site navigation.

With Pathauto, you can set an automated URL for each content type you have. For example, you can set the URL structure for all news items on your site to be news/[article-title], which is much better for SEO and is more user-friendly.

Pathologic

Has anyone ever dealt with relative URLs linking to pages within your own website? It can be cumbersome, especially when web pages are moved around or deleted.

Pathologic creates a filter that corrects URL paths that would normally have the tendency to blow up and break. The configuration is a little more challenging than your average Drupal module, but the documentation is great and it’s worth it so you can avoid broken-link headaches.

Content Editing

Graphical user interfaces (GUIs) for writing text content is a great way to make site management easier.

Wysiwyg

Wysiwyg is the module that allows you to use rich-text editors within text areas on your site. It’s compatible with a lot of different rich-text editors and is easy to install and use.

A Module for Rich-Text-Editing

If the site you are building is going to be used by a non-technical site owner, you almost always have to include a WYSIWYG/rich-text editor in your initial setup so that they don’t have to be burdened with having to learn HTML or some other markup language when they want to create or edit site content. (The exception here would be if the client wants to write in HTML.)

I tend to use CKEditor or TinyMCE, but there are many out there that you may want use instead (YUI Rich Text Editor, Htmlarea, widgEditor, the list is seemingly endless).

For a step-by-step setup guide on setting up a rich-text editor, read: Installing a text editor in Drupal 6.

Multimedia Content

Aside from text content, the site owner might want to embed streaming video and audio in their content pages or provide PDF and Excel spreadsheet for their readers to download. The following modules will help in this regard.

Embedded Media Field

When possible, embedded media is the way to go, because you’re not hosting anything on the server and taking up space.

YouTube, Vimeo, Viddler and other third-party web services allow you to host and serve multimedia content under their server infrastructure. Those videos can then be embedded into your Drupal content pages.

You’ll need to download supporting modules for easily embedding multimedia content from these web services.

If you really need to host your own audio and video, check these modules out:

• Video – Upload videos via CCK (video player included).
• Audio Field – Create a simple CCK field for audio.

IMCE

IMCE gives you control of the uploaded files on your server as well as the ability to upload new ones.

It works great for images as well as file uploads (PDFs, text files and so on). It’s not so great for video and audio, though.

To get IMCE to work with your text editor, you need to download IMCE Wysiwyg Bridge, a module that connects IMCE to your WYSIWYG/rich-text editor.

Site Administration

By default, it’s really hard to navigate through Drupal’s admin interface. Check out the following modules to enhance Drupal’s navigation menu interface.

Administration Menu

This module comes standard with Acquia Drupal (mentioned earlier) and gives you a nice, horizontal admin navigation bar at the top of web pages for navigating around the admin interface easier.

As a site administrator, it can be difficult to use the default menu system to configure things and manage content quickly. This module solves that by giving you a persistent navigation menu.

Content Access

Content Access is a must-have for sites with any kind of customized permissions. This module will allow you to restrict access of content as you choose.

Content Access is great for limiting access to content types by user roles. You can also allow access to individual pieces of content and individual users as well. When content is restricted, it becomes invisible to users who don’t have permission to see it. It also becomes invisible in site searches. I use this module a lot when creating internal wikis or help documentation for clients.

Backup and Migrate

Backup and Migrate is used to create regular backups of your site files and database. The backups can be manually triggered or automated at set intervals (say, once a night or once a week).

The backups can be emailed or saved to a directory on the server. Make sure your site has routine backups in case something goes awry. If things do go south, and you have Backup and Migrate installed, all you need to do is restore. Easy and stress-free! Protect your client’s web assets by setting this up to do automatic backups.

Tools for Developers

The following modules are for web developers working with Drupal and can be used during the site build process to speed things up. If the end-user doesn’t need these developer-oriented modules, deactivate or delete them before the project hand-off.

Features

With this module, you can create your own features and bundle them into modules to use on other projects.

I use Features when I find myself creating the same thing over and over again in Drupal, like an event list, for example.

The Features module makes it easy to create functionality and export it so it can be used later. This can save lots of development time and resources.

IE CSS Optimizer

Your website audience may include Internet Explorer users (feel sorry for them) who probably have no idea what a Drupal themer goes through trying to make Drupal look good on IE.

By default, IE does not load more than 31 linked style sheets. This may not mean anything to you, but it could mean the difference between a theme working or not. Install this module so you don’t break out in a spastic fit while trying to debug IE.

Drupal 7 does not have this issue anymore. This module only applies to Drupal 6.

Devel

Devel provides great resources for Drupal development, theming and testing. Devel can generate dummy content for all content types, which saves time and energy when theming and testing.

This module also allows you to hop over to different users so that you can see the site from their role/permissions perspective.

It does a lot more and I recommend you visit its demo page. Seriously.

Conclusion and Summary

Bear in mind that there are around 6,000 modules that are compatible with Drupal 6, and not every module was able to make it on this list. There are a lot of other modules that make life easier when developing in Drupal.

Feel free to suggest your own favorite Drupal modules in the comments.

Drupal 6 Module Summary

Related Content

• Getting Started with Drupal: A Comprehensive Hands-On Guide
• 22 Excellent Tips for New Drupal Developers
• 10 Drupal Modules You May Not Know About
• Related categories: Web Development and Website Management

About the Author

Katie Methe is one of the sharpest Drupal Chicks on the East Coast. Her experience with Drupal ranges from small websites to complex and advanced databases. Catch up with Katie at Drupalcon 2011 or join the Gravity Switch mailing list to stay up to date!

Advertise here with BSA

Until recently, managing a website required, at the very least, familiarity with HTML. Updating a web page required the ability to work with FTP. Even minor tweaks to the site’s design required the client to know CSS (or to have someone on staff with the know-how).

This was just an accepted part of owning a website. The nature of the Internet created a demand to keep websites constantly updated and interactive by skilled developers, designers and/or IT staff.

Things have changed.

Today, we have plenty of fantastic content management systems (CMSs) that make creating, editing and managing site content easy even for individuals who have the bare minimum computing skills.

Sure, a little bit of guidance at the start is probably going to be required. Clients need to become familiar with how their CMS works and how to use the system’s admin interface.

However, the days of teaching site owners HTML, FTP, CSS, and the other things that are required to edit source code and manage website files are behind us now.

What this all ultimately means is that we can more easily deliver web-based products that are complex, yet easy to interface with.

Instead of providing extensive staff training at hand-off, for example, web designers like the Paper Leaf team build sites using WordPress and give their clients a 30-minute training session on the publishing platform (and a user-friendly guide to WordPress administration basics when face-to-face meetings aren’t doable).

Empowering Your Client

When we restrict our clients — placing limitations on what they can and can’t do with their website — we start to build a list of rules and regulations that their new site comes with.

As a web designer, I hate telling clients that they can’t do something with their website such as changing the font size of paragraphs, re-writing their About page or changing the color of their site’s hyperlinks.

Telling a client that they can’t add a sidebar on a product description page or alter featured content on the site’s home page without the help of a professional is no longer acceptable. We can — and should — build sites that allow them to make basic changes without our assistance.

In the case of WordPress, for example, many themes allow users to specify which pages should and shouldn’t have sidebars, and there are WordPress plugins such as WP Featured Content Slider that you can easily install to deal with featured content on the home page.

What follows are just some of the things you can do to empower your client.

Set Up User Roles

When delivering a website built using a CMS, don’t encumber the site owner with rules such telling them which parts of the system they can and can’t use.

Instead, take advantage of your ability to use and create custom user roles with varying system privileges.

For instance, WordPress comes with user roles that have different capabilities. The Administrator role can do anything, the Editor role allows the user to publish and manage posts but won’t allow her to modify the site’s theme settings and so on.

WordPress table showing user roles vs. capabilities.

And if the default user roles aren’t enough, a great content management system will offer you the ability to create custom user roles out of the box or through a plugin (by default, you can create your own user roles in Drupal and WordPress has the User Role Editor plugin).

Set up accounts that only have access to the tools that can generate or edit the front-end of the site, and give your clients the freedom to experiment with everything they have access to.

Provide GUIs for Basic Site Administration Tasks

Another important thing we need to do is to provide user interfaces for common site-management tasks (even if the publishing platform doesn’t provide them).

Here is a brief list containing some common site administration tasks you should consider providing a user-friendly GUI for:

• Adding links to site navigation menus
• Formatting a web page’s content (through a rich-text editor)
• Choosing which content should be featured on the home page
• Creating new users
• Adding and resizing images on a content page

Providing GUIs is simple if you use a CMS because if it doesn’t come built into the system, you may be able to find an extension/plugin for it or use the CMS’s API to build one.

To determine what GUIs are needed, you can follow these steps:

1. Create a list of site administration tasks an empowered site owner might want to do.
2. For each task, determine if the CMS provides a GUI for the task by default.
3. If the CMS doesn’t provide it by default, research plugins/extensions/modules that you can use.
4. If there is no existing plugin, use the CMS’s API to create a GUI.

Create Sites with Changeability in Mind

Websites are meant to be alive — they are constantly changed, updated, redesigned, and so on. In other words, what you deliver to the client today might not be exactly the same product a year from now. Change is inevitable.

Having this concept in mind throughout the website-production process will ensure that you make the appropriate design decisions.

When we design with change in mind, our clients can expand and even rebuild their website with significantly less work. When a designer plans for the future around the content, they can reuse the most important part of the site even as technology and their needs change.

Planning for the Website’s Future

As web designers, it’s our responsibility to make sure that our clients’ websites will stay functional while continuing to deliver a rich experience long after a project is finished.

The best way to achieve this is to plan ahead as much as we can.

In the initial stages of a new project, make sure you sit down with the client and hash out a plan for growth. Any project for a brand new or freshly redesigned website should involve stakeholders that are familiar with the current state of the company, product or service, along with where they want it to be several years down the road.

If a company knows they want to expand into a new line of service in two years, it should be a part of the consideration of a website that’s being developed today.

Getting these plans out in the open will help the web designer predict what kinds of content additions, changes and expansions to expect down the road. This way, when the client decides to expand their site, they can do so with a minimal number of surprises or additional work.

I’m not suggesting that we have the power to build a website that can predict the future. However, we should be able to make websites that are as flexible and accepting to whatever lies ahead.

Related Content

• Agile Web Development That Works
• The Three Golden Rules of Site Redesigns
• 10 Excellent Tools for Responsive Web Design
• Related categories: Web Development and Web Design

About the Author

Jason Gross is a freelance web designer focused on creating clean and user friendly websites. Jason currently lives in Indiana and can be found on Twitter as @JasonAGross or on the web at his personal blog and portfolio.

Advertise here with BSA

One of the neatest things I’ve had the pleasure of experiencing by combining my love for software development and professional blogging is to see how closely tied they are in art, form and function. The marriage couldn’t be more copasetic, and I’ve discovered that they complement each other and I can learn more about each respectively and dependently.

Taking it one step further, I’ve had the pleasure to be a part of a startup that leverages one of the top blogging platforms out there, WordPress, and I’ve spent ample time in the weeds developing both WordPress themes and plugins for the system.

Naturally, I’ve learned a lot and, just like how an auto mechanic knows a car better than the average driver, I’ve been blessed with an insider look into how the blogging system itself talks to the end-user.

Here’s what I’ve discovered: You can become a seriously better blogger if you code even a little bit. Below are a few ways development is similar to blogging.

An Affinity to Order

When you first start out, developing software is like swimming in a pool of ideas that somehow coalesce into something workable, pliable and functional.

As you mature, you find that you’re able to quickly increase your pace of development by systemizing your processes, taking advantage of existing structures, syntax, systems and frameworks to speed things up. That is, you produce order out of chaos.

The more order you bring to a system, the more manageable it will become.

As a blogger, your goal is create order in what you write so that your readers can reasonably understand what you’re saying. It harkens me back to my elementary school years where my teacher required me to create all those outlines before I actually started to write anything. You remember, don’t you?

Practically, this means that your blog posts need to be orderly, written in a pattern, rhythm and cadence that’s acceptable to the audience and the context you’re covering. The more you can lock into the acceptable pattern and order, the better and quicker your writing becomes.

Balance and Tension

Coding requires poise, nerves of steel, and a bit of luck to get it off the ground. Do it once and you’re hooked. It’s like a drug that satisfies but never completely satiates.

As you build more and more complexity into your system, the balance begins to wear and the tension begins to grow. Of course, all of this is to produce an excellent product that the end-user will enjoy, so you continue to muddle through the code to completion!

And like any good blogger, your content needs to strike the right balance and tension as it presents the information to the reader. Go out too light, and the reader finds it boring and not deep enough. They might even find you a tad bit boring as well.

Create too much irresolvable tension, and you won’t capture anyone long-term.

In literary terms, this is called the narrative, the overarching movement of the story, a beginning, middle, and end.

Code does that aplenty, and if you spent a little time walking through some code, then you’d come away with a fresh perspective that few bloggers have: an appreciation for the art and science of software narrative.

In time, this develops into even more mature thinking as you build out your blog posts. For example, you might even start thinking about blog series and putting more than one or two blog posts together. You might even string them out for over 50 posts at some point!

Just Ship It!

At the end of the day, the most important thing that any software developer needs to do is ship the darn thing. That is, they need to finalize the last semi-colon, make sure it works, and then give it to the public for use.

The never-ending battle within the soul of the developer is that he knows that his work is not completely finished nor is it absolutely the best thing since sliced bread — but they ship and launch anyways.

And bloggers can learn a thing or two here: I encounter tons of people that have the potential to become amazing bloggers if only they’d ship more. In other words, they need to let go of the fear of making a mistake and the pointless drive to perfection, and just simply publish their posts, even if they’re imperfect.

Many writers simply feel like they can’t publish anything that isn’t completely perfect. This is insanity in a box. A post will never be perfect.

On the other hand, a developer knows that the moment she ships it, she’s already fixing it.

You will become a better blogger if you learn to publish despite the voices in your head telling you that it’s not perfect, that it’s not quite there yet, and that it’s not your opus.

Then, you’ll find the next time to be easier, and then the next even easier, and heck, you might even wake up one day as a professional blogger.

Related Content

• How to Write an Amazing Article
• Components of High-Quality Blog Posts
• Creating a User Interface That Speaks Your Users’ Language
• Related categories: Web Development and Project Management

About the Author

John Saddington is a software developer at 8BIT and a professional blogger who loves sharing his blogging tips, tricks, tools, and practical teaching covering SEO, WordPress and making money through your blog. You can follow him on Twitter @TentBlogger.

Advertise here with BSA

Agile web development is not a specific process, action, or a daylong exercise. Agile is a mindset, an attitude with which a project is undertaken.

It means streamlining the project, taking away time-sucks, performing frequent sanity checks, and making sure that you’re not spending excessive time on things that don’t add value to the project.

It’s about spending quality time on actions that add value to the website and make it better, and taking away time and energy from parts of the process that cause headaches.

Your team will reach the same goals and milestones, but in half the time or less.

In this article, I’ll show you how the agile project management method can be applied to developing websites.

Traditional Web Development Process

Typical web development process circa 2000-2007.

Around the turn of the century, a bunch of us web geeks were working hard on figuring out how to design websites effectively. We started with the tools and processes used in print, video and radio, and modified them for the internet.

We embraced paper prototypes, wireframes, user personas and use-case planning, as well as information architecture planning with site maps and flow charts.

When Jesse James Garrett and Steve Krug came out with their usability/user-centered-design books, we heaved a sigh of relief, not because what they were saying was new, but because they articulated the subject in a way that even the most technology-phobic print designer could understand.

The Turning Point

We got an RFP recently from a college that is redesigning their website and wanted to hire us for design and planning. It’s a great school and it sounded like a great project, the likes of which we’ve done dozens of times before.

But when we sat down to write the proposal, we found ourselves scratching our heads about how to approach it.

After a while, we realized why. The RFP was looking for a web developer from 2005.

Wireframes, site maps, use-case scenarios and focus groups — the traditional web development process — have served us well for almost 10 years, and we developed effective websites using them, but in a high-paced industry like ours, speed and efficiency are very important.

Now we see that they were tools of the Wild West. They still have their places in the new world, but they’ve been reduced to a niche player, and are only used on the trickiest of web projects.

What’s Changed?

There have been three major changes in the past 5 years that have fundamentally altered how we design websites.

First, everyone uses the Internet. I mean everyone. Ten years when we met with marketing directors or CEOs, most of them had secretaries who printed out their email to be replied to. Now, every CEO has a Blackberry or iPhone.

Secondly, we have gained a better understanding of how people use sites. Five years ago, we had best guesses to start from, now we have best practices. For example, every user who goes to a college website knows to look for the link that says "Admissions", and likewise every college knows to have a link called "Admissions". It’s hard to imagine, but these were big questions 10 years ago that merited days of discussion and testing.

Third, and possibly most importantly, are the vast strides in content management systems (CMS) technologies over the past 5 years. Any reasonably talented usability consultant (a profession that also didn’t exist 10 years ago) can work with a developer to customize any number of inexpensive or freely available, open-sourced CMSs, so that even my grandparents can edit a website.

Now we’re at a point where the work that used to take up 80% of a web development project is unnecessary.

It’s time to put aside the processes that supported that work, and graduate to the next level.

Agile Web Development Process

Modern (agile) web development process.

In the process shown above, editors are interacting with content and navigation on day one. Navigation is fluid, and we’re getting in front of users faster and making 100 minor corrections to our course, instead of waiting a few weeks and making major adjustments.

Flexible Processes for a Flexible Web

Get your team off of email and hold the phone. Stop the endless back-and-forth, internal meetings, and rehashing of the same issues each week.

Get everyone in the office and lock them in (figuratively). Bring the decision makers, the content entry folks, and your IT specialists, and you have a recipe for success.

While every part of an agile web development process runs more smoothly with rapid iterations, it’s the reduction of time spent on overhead — scheduling, recapping, hunting someone down for feedback, mood swings, staff reorganizations, training, etc. — that really gives you your biggest time-savings. Instead of your key stakeholders having to attend 4 meetings over 5 months, they need to attend 3 hours of meetings over 3 days.

With agile development, your team will be immersed in building the website within a couple of weeks of starting the project, and you’ll be getting real-time feedback from real website users within a month.

Your internal team will be empowered to make these changes and will be trained in asking the key questions, which are:

• Does this change help us reach our goals?
• Do these images and words support our brand?
• Is this solution better than what’s there now?
• What’s the worst that could happen if we tried this for a week?
• Once the week is done, how should we decide if we leave it or change it back?

Now is a very exciting time for technology, and this new method of web development is a tool that gets right to the heart of the matter, and avoids wasting time on the noise and minutia that slows us down.

A Case Study of Agile Web Development

We worked with Technical Career Institutes in Manhattan to re-launch their 100-page college website in 1 month.

They wanted a slick, modern, engaging design to reflect their brand. They want it to be easy to edit, and easy for them to maintain.

Within 2.5 months of signing a contract with us, their inquiries had increased by 100% — a wonderful outcome of the re-design. (We’re continuing to work with them to understand where they lose people in the application process, and will continue to improve these numbers.)

In three days, despite not having a clear brand statement, we took all the photos, designed the new website look, got sign-off (and excitement) from over a dozen key stakeholders, programmed the themes and tested them on all priority browsers, finalized navigation and created about half the pages on the website.

What follows is a breakdown of our 1-month timeline.

Week 1: Setup

Initial server setup by our team. We chose Drupal because it’s powerful and can be configured and customized to be very easy for end-users to use. Using the Acquia Drupal install, security updates become easy. (We have a standard module list that, if you ask about in the comments, I’ll discuss in another article.)

Week 2: Onsite Training

Over the course of this week, we worked with TCI to understand their brand, create the visual design of the website, take hundreds of photos, define the navigation, and train 15 TCI staff members on content management. This allowed them to completely rewrite 15 pages and migrate 25 more from the old site to the new site, set up multiple web forms and calendar integration, and connect all the hooks to their existing admissions systems.

Weeks 3-4: Cleanup and Go Live

We spent the last two weeks tidying up and preparing to go into production. TCI continued to add and tweak content while we refined the design and the code, cropped pictures for them, and helped them with navigation problems. We made the site more search-engine-friendly and generally kept things moving forward to deployment.

Post-Launch

Both our team and their team have made dozens of tweaks to the website after the site was launched. We continue to monitor website traffic to optimize the website for search engine traffic.

Conclusion

Using agile project management reduces traditional website development processes significantly. What could have taken 4-8 months under a traditional process, we reduced to 1 month. Cutting down the build process to its bare essentials reduces bottlenecks and project overhead, making it as efficient and results-driven as possible.

Related Content

• 4 Steps to Building a Portfolio Website Using Drupal
• Why Making Web Apps with Rails Is Awesome
• Ideas for Expanding Your Web Design Business
• Related categories: Web Development and Project Management

About the Author

Jason Mark is an educator, business owner, and author. His Massachusetts-based firm, Gravity Switch, continues to be the leader in web, iPhone and iPad development in New England, and Jason keeps their carbon footprint down by bicycling to work year round. Follow him on Twitter @jasonnmark.

Advertise here with BSA

Previously, I wrote about 5 web files that will improve your website and discussed files that, while small in size, pack a solid punch and make our work that little bit better. In this article, we’ll look at five more web files that can improve and your website.

Quick Overview

Here are the files we will cover:

• P3P.xml – for user privacy
• Geo.kml (and Geo.rdf) – for geolocation
• Humans.txt – for attribution
• vCard.vcf – digital business card
• PICS.rdf – declares a website to be safe (or not safe) for young web users

P3P.xml

Issues related to user privacy on the web are of paramount concern both to those who store information (site owners) and to those who submit the information (site users).

The Platform for Privacy Preferences Project (P3P) encourages website owners to declare all details relating to their privacy measures in a standardized XML document (or via meta tags), so that browsers can pick up the information, display warnings and details, and empower users to take whatever action they feel necessary.

On the surface, this system sounds wonderful: it gives users control over their data, it helps site owners keep them informed, and the browsers let users choose sites to trust.

Platform for Privacy Preferences or Pretty Poor Privacy? The truth is out there!

Unfortunately, creating the file can be quite complex, with all of the variables involved (it’s like filing a tax return).

Worse, Internet Explorer is the only major browser that does much with the file. It grants greater control over cookie-blocking in IE6+, while letting you display an on-screen privacy policy.

In addition, the issuer of the file is responsible for complying with its own guidelines, and there is no enforcement.

The reality is that, with all of the critics and compatibility issues, no alternative has gained as broad of a support as P3P.

Website owners need to deal with these increasingly prevalent privacy issues, and because P3P offers a workable solution right now, adopting it for the sake of IE, privacy search engines, and other user-focused tools is justifiable.

Creating a P3P.xml File

Once you’ve created the file, it requires little maintenance.

There are two ways to go about creating a P3P.xml file.

One way is you could follow the W3C Platform for Privacy Preferences 1.0 (P3P1.0) specification and build the file by hand using your favorite text editor.

Alternatively, a few useful apps will do the work for you.

P3P.xml tools:

• IBM P3P Policy Editor (freeware)
• JRC Policy Workbench (open source)
• P3PEdit (web-based, $39)

Other useful resources:

• P3P policy validator
• Internet Explorer and P3P
• P3P privacy verification
• Search for privacy-friendly websites

Once you’ve created the file, name it P3P.xml, put it in either the site’s root directory or a directory named w3c.

Next, you’ll need to add a reference in the <head> of your HTML document. Below is a sample reference:

 <head>
 <link rel="P3Pv1" type=" text/xml" href="/w3c/p3p.xml" />
 </head>

Geo.kml and Geo.rdf    

Geotagging has taken the web by storm.  Disclosing your geographic location to site visitors can build trust, especially in e-commerce websites.

Using Google Earth or Maps, we can guide visitors to our office.

The benefits of geotagging are quite evident. You let users see where your offices are (great if you need to arrange meetings with clients at your headquarters). Also, showing that there are real people behind the website makes you seem less like an anonymous corporation. Not to mention, mapping services will be able to index you in their listings.

There are several possible approaches to geotagging your site, including using microformats. We’ll look at how to build two different solutions: one for Google Earth (Geo.kml) and a helpful RDF fallback (Geo.rdf) for other tools.

Creating a Geo.kml file

You can create this file using any text editor. You could name the file after the website or place that you’re mapping. For example, if we made a file for Six Revisions, it could be named SixRevisions.kml.

Put your Geo.kml file in the root directory of your website.

Below is a basic example of what the code should include:

  <?xml version="1.0" encoding="UTF-8"?>
  <kml xmlns="http://www.opengis.net/kml/2.2" xmlns:gx="http://www.google.com/kml/ext/2.2" xmlns:kml="http://www.opengis.net/kml/2.2" xmlns:atom="http://www.w3.org/2005/Atom">
  <Document>
  <name>Brighton</name>
  <description>The place that I call home!</description>
  <Style id="pin"><IconStyle><Icon><href>http://maps.google.com/mapfiles/kml/pushpin/ylw-pushpin.png</href></Icon></IconStyle></Style>
  <Placemark>
    <LookAt>
      <longitude>-0.13642</longitude>
      <latitude>50.819522</latitude>
      <altitude>0</altitude>
      <tilt>0</tilt>
      <range>5500</range>
    </LookAt>
    <styleUrl>#pin</styleUrl>
    <Point><coordinates>-0.13642,50.819522,0</coordinates></Point>
  </Placemark>
  </Document>
  </kml>

Every KML file begins with a document type declaration (DTD), which states that this is an XML file that follows the KML specification.

Inside the KML element, there should be a <Document> tag (just as an HTML document has a <body> tag), and in it, you put the details of your address.

Briefly, here are explanations for tags to include:

• <name> and <description> lets users know what is being shown
• <style> offers an image to pinpoint the location on the globe
• <Placemark> pinpoints the object
• <Point> contains <coordinates> to the latitude and longitude of your location

  <LookAt> data about the coordinates, such as altitude and tilt

• <range> tells how far to zoom in

Most of these are easy to declare. The only thing to find are the coordinates.

Finding your coordinates is rather easy. If you visit maps.google.com and type in the place or address, half the job is done.

Of the many methods of extracting these details, my favorite requires the least amount of work. Simply using the script below into the address bar after you’ve found your location will yield the information.

javascript:void(prompt('',gApplication.getMap().getCenter()));

To reference it in HTML, add the following inside your <head> tag:

 <link rel="alternate" type="application/vnd.google-earth.kml+xml" href="SixRevisions.kml" />

Of course, you can do more with your KML file than what is described here. If you’d like to explore further, Google has a KML Reference documention.

Creating a Geo.rdf File

Of course, not everyone uses Google Earth, and many other web services exist (such as search engines) that gather geodata. So, we should also produce an RDF file that works some geo magic on the semantic web.

Geodata has a lot of uses, and it’s very easy to create.

If you have the coordinates, the file is actually a lot more straightforward to create than the Google Earth KML file, because we’re not worried about visual representation; we simply want to get the coordinates out there for other services to make use of them (whether social networks or search engines).

To build the file, create a new document named Geo.rdf, and in it, just use the code below, replacing details such as your website (rdf:about), the place or website name (dc:title), and your coordinates (geo:lat and geo:long tags).

 <rdf:RDF xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:foaf="http://xmlns.com/foaf/0.1/" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
 <rdf:Description rdf:about="http://www.mysite.com">
 <dc:title>Brighton</dc:title>
 <foaf:topic rdf:parseType="Resource">
 <geo:lat>50.819522</geo:lat>
 <geo:long>-0.13642</geo:long>
 </foaf:topic>
 </rdf:Description>
 </rdf:RDF>

Once you’ve created the file, add the link reference to your website:

 <link rel="alternate" type="application/rdf+xml" title="Geo" href="Geo.rdf" />

Humans.txt

The proper way to attribute work has been up for debate since the Internet went mainstream. As professionals, we want to act in our clients’ best interests, but as creatives, we want people to know who is behind the wonderful work we put together (which could lead to new clients).

Websites are built by people, so why not credit them?

humans.txt is a standard format not unlike a robots.txt, but with the intention of providing information about the people behind a particular website.

Creating a Humans.txt File

The great thing about Humans.txt is its simplicity. While there is no formal standard for what (or who) to include, there are some best practices to ensure that the file is as human-readable (and possibly machine-readable, for web spiders) as possible.

To begin, create a humans.txt file and put it in your website’s root directory. In that file, you will be enclosing three primary categories in comments. You could add and remove categories as you see fit

The first category, TEAM, can include directives such as title, position, website, Twitter profile and location. The purpose is to provide information about the individuals responsible for creating the site.

The second category, THANKS, attributes the project’s contributors by name (or URL).

The final category, SITE, provides information about the standards, components and software used in the website’s production, along with a timestamp for the last update and language details.

Below I’ve adapted a humans.txt template, illustrating this format:

/* TEAM */
Title:      YourName.
Position:   Job Role
Site:       http://yoursite.com
Twitter:    @YourSite
Location:   City, Country.
/* THANKS */
Name: TheirName
/* SITE */
Updated:     YYYY/MM/DD
Language:    English (US)
Standards:   HTML5, CSS3, JavaScript
Components:  jQuery, etc.
Software:    Adobe Photoshop, Notepad++

Once you’ve filled in as much detail as you’d like (remember that this file is primarily for humans, so keep it simple), you just need to link to the <head> (as always).

<link type="text/plain" rel="author" href="humans.txt" />

It’s a great way to credit the entire team unobtrusively.

vCard.vcf

Next on the list is a personal favorite of mine. In this era of communication, enabling clients and visitors to get (and stay) in touch is essential. Our contact pages are often fragmented by social network icons, email forms and lists of instant messaging and VoIP accounts. Visitors and clients just want to get in touch with us, so make the process as easy as possible.

With a few lines of code, we can produce a useful importable contact reference.

vCard is a standardized format for digital business cards. One file lists all of the applications, services and social networks that people can use to connect with you. It functions as an index of meta data about you or your business, and people can import all of the data into their favorite address book or email client. Microsoft Outlook and other clients support vCards, as do the Windows and Mac address books.

vCard has its own microformat that semantically marks up any related information on our pages. You could offer just the microformat version, but for compatibility and ease of access, vCard (or even both formats) is preferred.

Creating a vCard.vcf File

The first thing to do is create the vCard.vcf file (which is case-insensitive). Inside are a few things every vCard must have, according to the specifications:

• BEGIN:VCARD and END:VCARD (case-sensitive) to map the start and end of the line (the same way that we open and close the <html> tag in HTML documents)
• VERSION: with a value of 3.0 (the latest edition)
• N: (Lastname;Firstname) and FN: (Full Name) directives

Here is an example:

BEGIN:VCARD
VERSION:3.0
N:LastName;FirstName
FN:FirstName SecondNames LastName
END:VCARD

You can add a bunch of other useful directives to declare things about yourself; if supported, these details can be used by other apps and services.

The general syntax for vCard files is the directive in uppercase, followed by a colon character, except where a variable is required (like TYPE=HOME or EMAIL), in which case the colon becomes a semi-colon. TYPE= becomes the variable identifier, multiple variables are comma-separated (like TYPE=HOME, WORK), and new lines for values are identified by more semi-colons.

Below are some examples of the various directives:

 NICKNAME:Name
 X-GENDER:Male
 BDAY:YYYY-MM-DDT
 ORG:Company
 TITLE:Web Designer
 URL;TYPE=WORK:http://www.yoursite.com/
 EMAIL;INTERNET:Hello@yoursite.com
 EMAIL;TYPE=PREF,INTERNET:Support@yoursite.com
 X-MSN;TYPE=HOME:You@hotmail.com
 X-SKYPE;TYPE=WORK:MySkypeID
 X-GOOGLE-TALK;TYPE=WORK:MyGoogleID

The variable TYPE=PREF indicates a preferred contact type (if the destination program recognizes it).

For more details about directives and extensions, please check the links below. You can add all sorts of awesome things into vCards, like images, links and even sometimes audio!

• Basic directives
• Known extensions

There are many more directives than are mentioned here. Another reason vCards are great is that they are extensible, supporting proprietary extensions. vCard extensions are prefixed with X- (the way we use vendor prefixes like -moz- in CSS). The only downside is that, as with CSS, support isn’t a given, so you’ll have to figure out the best semantic route.

Once you have your vCard.vcf ready, reference it in your HTML documents like so:

 <link rel="alternate" type="text/directory" title"vCard" href="vCard.vcf" />

PICS.rdf

Not everything on the web is child-friendly, and this last file helps with that issue. Many software providers (even Windows with IE6+) provide specialized tools to filter out objectionable content for young audiences (i.e. generic content filtering). While some providers use human-based filtering, PICS (Platform for Internet Content Selection) helps any automated product gauge whether your content is age-appropriate. And it’s well supported.

The content advisor in Internet Explorer is just one system that integrates PICS tags.

Getting your content blocked automatically reduces your ability to reach users, and while some newer tools rely on human screening (because of a distrust of self-regulation), we can at least certify our content to aid with such decisions. It’s pretty much like how the music and film industries work, and there are several ratings systems, too.

Creating a PICS.rdf file

Because there are several ratings systems, each with its own methodology, I’ve adapted one of the most popular formats (ICRA’s RDF method) to accept other types of labeling. Even though the ICRA has ceased developing its PICS labeling system, the system is still widely used by content filters, so it still has an important role to play, until something better comes along.

Start by creating a PICS.rdf file, and use the following code in it:

<?xml version="1.0" encoding="iso-8859-1"?>
 <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:dcterms="http://purl.org/dc/terms/" xmlns:label="http://www.w3.org/2004/12/q/contentlabel#" xmlns:icra="http://www.icra.org/rdfs/vocabularyv03#" xmlns:rsac="http://www.icra.org/rdfs/vocabularyv01#"  xmlns:ss="http://www.safesurf.com/ssplan/" xmlns:sfk="http://www.weburbia.com/safe/ratings/ ">
 <rdf:Description rdf:about="">
 <dc:creator rdf:resource="http://www.icra.org" />
 <dc:creator rdf:resource="http://www.safesurf.com" />
 <dc:creator rdf:resource="http://www.weburbia.com/safe" />
 <dcterms:issued>2011-04-15</dcterms:issued>
 <label:authorityFor>http://www.icra.org/rdfs/vocabularyv03#</label:authorityFor>
 </rdf:Description>
 <label:Ruleset>
 <label:hasHostRestrictions><label:Hosts><label:hostRestriction>www.yoursite.com</label:hostRestriction></label:Hosts></label:hasHostRestrictions>
 <label:hasDefaultLabel rdf:resource="#label_1" />
 </label:Ruleset>
 <label:ContentLabel rdf:ID="label_1">
 <rdfs:comment>ICRA Ratings</rdfs:comment>

 </label:ContentLabel>
 <label:ContentLabel rdf:ID="label_2">
 <rdfs:comment>RSACi Ratings</rdfs:comment>

 </label:ContentLabel>
 <label:ContentLabel rdf:ID="label_3">
 <rdfs:comment>SafeSurf Ratings</rdfs:comment>

 </label:ContentLabel>
 <label:ContentLabel rdf:ID="label_4">
 <rdfs:comment>WebUrbia Ratings</rdfs:comment>

 </label:ContentLabel>
 </rdf:RDF>

Below each rdfs:comment element, you’ll notice some empty spaces. Your job is to fill them in according to the specifications of the various groups. Guides exist to help you determine what code to put in each category (mentioned below).

In each section, create a tag that begins with the letters of the system you’re using there, and then (separated by a colon) define the relevant rating by its unique abbreviation. Once you have the tag, simply enter the appropriate digit, 0 or 1, inside it.

ICRA, RSAC, SafeSurf and Safe for Kids represent the four most popular PICS systems.

For example, if you used ICRA, your tags would be <icra:x></icra:x>, with the x‘s being replaced by the rating, and the 1 or 0 value going between the tags.

For RSAC, it would be <rsac:x>, for SafeSurf it would be <ss:x>, and for Weburbia’s "Safe for Kids" system it would be <sfk:x>.

To determine exactly what sections you’ll need, visit these websites:

• ICRA
• RSAC
• SafeSurf
• WebUrbia

To see how this code might look, I’ve pre-built some example labels. ICRA labels have a two-letter code (for example, NZ declares that there is no nudity on the website). For RSAC, it’s a letter followed by a number (indicating severity).

For SafeSurf, it’s a slightly longer value (SS~~, followed by two zeros and the number or letter). The easiest of all (with only one declaration) is Weburbia’s "Safe for Kids" scheme, with an S to represent the safety level, and a value of a 0, 1 or 2 to match the PICS scheme.

Below are some basic examples of PICS labels from the four providers:

 <label:ContentLabel rdf:ID="label_1">
 <rdfs:comment>ICRA Ratings</rdfs:comment>
 <icra:nz>1</icra:nz>
 <icra:sz>1</icra:sz>
 <icra:vz>1</icra:vz>
 <icra:lz>1</icra:lz>
 <icra:oz>1</icra:oz>
 <icra:cz>1</icra:cz>
 <icra:xz>1</icra:xz>
 </label:ContentLabel>
 <label:ContentLabel rdf:ID="label_2">
 <rdfs:comment>RSACi Ratings</rdfs:comment>
 <rsac:L>0</rsac:L>
 <rsac:N>0</rsac:N>
 <rsac:S>0</rsac:S>
 <rsac:V>0</rsac:V>
 </label:ContentLabel>
 <label:ContentLabel rdf:ID="label_3">
 <rdfs:comment>SafeSurf Ratings</rdfs:comment>
 <ss:ss000>1</ss:ss000>
 <ss:ss001>1</ss:ss001>
 <ss:ss002>1</ss:ss002>
 <ss:ss003>1</ss:ss003>
 <ss:ss004>1</ss:ss004>
 <ss:ss005>1</ss:ss005>
 <ss:ss006>1</ss:ss006>
 <ss:ss007>1</ss:ss007>
 <ss:ss008>1</ss:ss008>
 <ss:ss009>1</ss:ss009>
 <ss:ss00A>1</ss:ss00A>
 </label:ContentLabel>
 <label:ContentLabel rdf:ID="label_4">
 <rdfs:comment>WebUrbia Ratings</rdfs:comment>
 <SFK:S>0</SFK:S>
 </label:ContentLabel>

Once you’ve created the PICS label and determined your content’s suitability for younger audiences (basically by filling out the RDF file like a questionnaire), all that’s left to do is save the file, put it in the root directory of your website, and declare it in the <head> via a link tag:

 <link rel="meta" href="PICS.rdf" type="application/rdf+xml" title="PICS labels" />

Related Content

• A Comprehensive Guide Inside Your <head>
• 5 Common SEO Mistakes with Web Page Titles
• Fine-Tuning WordPress for SEO
• Related categories: Web Development and Resources

About the Author

Alexander Dawson is a freelance web designer, author and recreational software developer specializing in web standards, accessibility and UX design. As well as running a business called HiTechy and writing, he spends time on Twitter, SitePoint’s forums and other places, helping those in need.

Advertise here with BSA

In the past few months, there has been a lot of talk around modern web browsers (Firefox 4, Chrome, IE9, etc.). The software application we use to navigate to our favorite websites is seeing tremendous attention, increased competition amongst its vendors, and advancements in its features.

Designers are understandably excited about these so-called modern browsers because they support HTML5 and CSS3 and have enhanced performance that can render complex graphics animation and processing-intensive scripting. At the same time, we’re seeing a big push to move users off older versions of browsers like IE6. All great stuff.

While Internet Explorer still holds a majority of the market, Firefox and Chrome, for instance, have been gaining a lot of ground. For web designers, this means we can take advantage of the new features today.

While this is all exciting for the design and development community, I can’t help but wonder how much it all really matters.

Does it really matter to the average user and to the typical client that the animated hover states of buttons or dropdown menus are now using CSS instead of JavaScript (or Flash) because of CSS3 transitions? Would they even know the difference between a Flash object versus something that’s made using JavaScript, CSS3, and HTML5?

In the eyes of the site user and the site owner, the real value of a website will remain the same. It’s still all about the content. Users visit websites in order to gain information, socialize with other users, or to complete a specific task. As long as they can accomplish their goal, they will be happy. That’s all that matters.

Focus on What Matters to Users

While it’s now an accepted reality that any given website can look differently depending on what browser you use, it’s not acceptable that a website requires its users to use a modern, future-standards-compliant web browser. A web designer should never have to include a disclaimer with their website saying that it’s a better site when experienced in Chrome or Firefox or Safari or IE9.

The information a website displays or the task it allows its users to complete must be accessible in all platforms and in as many scenarios as possible.

Never make browser choice a hindrance to access and the user experience.

Along the same lines, a website’s interactive features (such as its navigation menu) must remain functional across all platforms and interfaces. All of the cool new features in the world won’t save you from a web design with poor functionality. A website with poor UI design is just as broken as a site that doesn’t work well in IE5.5.

The Modern Browser

There’s no arguing that modern browsers boasting wide support for the newest features in HTML5, JavaScript, and CSS3 put more power in the hands of designers and developers. They allow us to craft better and high-performing user interfaces and innovative designs.

The ability to design a website just for one environment is the utopian scenario; it’ll make things so much easier. Unfortunately, this is hardly ever a realistic scenario for most of us.

The truth of the matter is that we’ll always be required to design and debug for the weakest browser. Sometimes this means putting an ideal solution to a problem on hold in favor of one that’s supported by all browsers. Other times we choose to force weaker browsers into compliance with hacks, script, and overrides. Both courses of action are taken in order to achieve the same goal: to make sure that the core content and functionality of the website remains the same for everyone, regardless of the browser they choose to use.

This may make it seem like users on old systems are holding us back and preventing the web from evolving. This unavoidable situation certainly doesn’t help move things along. However, it doesn’t leave us at a complete loss for taking advantage of what modern browsers have to offer.

What Users Don’t Know Can’t Hurt Them

While we shouldn’t punish users for having an old, outdated browser, we can certainly reward those who choose to use a more feature-rich browser. How can designers use modern methods to build a beautiful site that boasts rich interaction on modern browsers, without neglecting those who still use outdated browsers?

Let’s talk about this through a pragmatic example. The CSS3 border-radius property provides a great example of a way to achieve what was once a painstaking task with a simple line of CSS.

But older versions of Internet Explorer don’t support this feature. That good news is that they simply don’t render rounded corners — they ignore the rule — and fall back to right-angled corners. It’s harmless and doesn’t affect the user experience of people who use browsers that don’t have support for this new CSS property.

If used consistently throughout the site, IE users will never notice their corners are any different; and they probably don’t care either way.

This kind of design methodology can be used for many situations. The core concept is that the new techniques and site features aren’t barriers to those that choose to use older browsers.

The Reality

In reality, web designers will always need to take into consideration how their site renders on the weakest browser. And right now, the weakest browser also happens to be a pretty popular one. While Firefox, Safari, Opera, IE9 and Chrome are gaining momentum, it really doesn’t matter if the number of IE7-IE8 users are still significant enough to merit our concern. Even though better browsers have surpassed IE6 in market share, we can’t ignore the weakest possible scenario until its usage significantly drops off.

Even if IE9 provides designers with a huge improvement over what’s available in IE8 and below, we still need to wait for the older versions to be phased out. The complete adoption of CSS3 and HTML5 is not something that’s going to happen over the course of a single year.

The Good News

Web designers are in a unique professional position in that we have the ability to drive our own future forward at a faster pace by holding web browsers accountable and by promoting the use of better browsers.

The continual improvement of web browsers is wonderful, but it will never hold the true key to our success. What will always drive the achievements of a web designer is their ability to use their skills and experience to present a message and a great experience to the user.

Much like different brands of TVs vary in size, quality, resolution, and features, web browsers, too, have differences between them. However, what really matters and what deserves our attention is what’s playing on the channels, not the box that presents them.

Do you test your designs to ensure that the core functionality of your sites remains the same across all browsers? Are you taking advantage of what CSS3 and HTML5 have to offer yet?

Related Content

• 10 Web Browsers You Probably Haven’t Heard Of
• Why IE9 is a Web Designer’s Nightmare
• The History of Web Browsers
• Related categories: Web Development and Web Standards

About the Author

Jason Gross is a freelance web designer focused on creating clean and user friendly websites. Jason currently lives in Indiana and can be found on Twitter as @JasonAGross or on the web at his personal blog and portfolio.

Advertise here with BSA

If you’re building a website for a client or yourself that requires a number of images to be presented in a gallery format — for example, if you’re a web designer, photographer, sculptor, painter or graphic designer — Drupal has some out-of-the-box solutions to help you organize and present your information.

Professionals who work on a visual medium often need help presenting (and possibly monetizing) their work, and an online gallery is a great way to do this. Perhaps you could also make the images available as physical products or digital downloads in an online store as an added option.

This guide will show you how to develop a portfolio/image gallery website using the popular content management system, Drupal.

Prerequisites

For this guide, you will need basic working knowledge of Drupal and a clean installation of the Acquia Drupal distribution ready to go.

The following guide might be helpful to read for new Drupal users:

• Getting Started with Drupal: A Comprehensive Hands-On Guide

Here are the Drupal modules we’ll be using:

• Acquia Drupal distribution
• Content Construction Kit
• Views
• Simplenews
• Optional: Ubercart (for e-commerce)

Below, you’ll be instructed to navigate to certain sections of Drupal. You will have to replace http://example.com with your domain name where you have Drupal set up.

Let’s get started!

Step 1: Gather the Information to Display

Use Drupal’s module manager to enable the following modules:

• Image (enables you to use images)
• Image Gallery (pre-built gallery functionality)
• Image Attach (functionality to add images to pages and other types of posts)
• Image Import (to batch upload a number of image files)
• Lightbox 2 (if desired)
• CCK Content (to edit the "Image" content type)
• CCK Number (to add new number fields to the "Image" content type)
• CCK Text (to add new text fields to the "Image" content type)

The typical project to display in a gallery-style website would have specific fields that display only on a per-project basis. These could include things like the image itself, the image’s title, the creation date, the medium and a description of the image.

Go through the body of work and identify the types of information that are important to display for each item in the gallery. You may be able to skip this step if all you need is the title and a description of the gallery item.

If you need more, then use CCK to add new fields to the "Image" content type by navigating to:

Admin menu > Content management > Content types > Edit Image > Manage fields

Direct URL:

http://example.com/admin/content/node-type/image/fields

This will enable you to collect more information about each image (again, specific to the type of gallery being displayed).

Note that the name of each gallery may be specified in advance by going to:

Admin menu > Content management > Image galleries > List

Direct URL:

http://example.com/admin/content/image/list

If no gallery has been prepared yet, you can create one by going to:

Admin menu > Content management > Image galleries > Add Gallery

Direct URL:

http://example.com/admin/content/image/add      

Step 2: Import the Images

You may upload images one at a time using the "Add image" functionality:

Admin > Content management > Create content > Image

Direct URL:

http://example.com/node/add/image

The default version lets you add a title and description. Because we enabled the Image Attach module, you can therefore attach an image to this node.

The following describes how to upload an image from your hard drive, and assign it to its gallery (if it’s destined to have one).

If you have a number of photos to upload at the same time, you could first put them all in one folder on your desktop or hard drive to make them easier to organize and access.

Next, go to the Image Import settings:

Admin > Site configuration > Images > Image import

Direct URL:

http://example.com/admin/settings/image/image_import

Follow the instructions to create a "temporary" folder somewhere in your web server. You may need to use FTP to create the folder (especially if you are using shared hosting).

Here is the equivalent tmp/image file on the hard drive:

FTP all of the images that you want to make available to your Drupal website, putting them in this temporary directory.

Note that you can automatically create new image galleries by creating sub-directories. For example, with the path tmp/image/gallery1/foo.jpg, the image foo.jpg would be part of gallery1.

Next, take those images from the temp folder and import them to your Drupal website:

Admin > Content Management > Image Import

Direct URL:

http://example.com/admin/content/image_import

You can use the Select button at the very top of the list to auto-select all of the images.

At this point, specify a new "Title" and "Body."

After the images have been imported, you’ll receive a confirmation.

You can always refer to the content overview section by going to:

Admin > Content management > Content > List

Direct URL:

http://example.com/admin/content/node/overview

Review which of the most recent items have been moved over, and make sure that any new images are assigned to the correct gallery. For example, I am assigning this particular image to the "Regular Gallery," which is in the dropdown list right under the title of the image.

Step 3: Fill Out the Informational Pages

Now is your chance to start creating pages about your portfolio website. Typically, you’ll start with pages such as:

• Home
• Biography
• Contact
• Privacy policy
• Terms and conditions

You can create new pages using the "Page Management" tool:

Admin > Content management > Create content > Page

Direct URL:

http://example.com/node/add/page

You can also specify whether or not the page should appear in the "Primary Links" menu, which is usually found across the top of every page.

Step 4: Using Lightbox

Lightbox 2 is a very nice way to present photos on a website. It allows you to upload images to the Image Gallery; and then, when a user clicks through the images, the images come up as a modal window with an arrow on either side of the image.

It’s worth briefly reviewing the available options for Lightbox. For the gallery we’re working on, we won’t change the default settings much.

To configure Lightbox, go to:

Admin > Site configuration > Light box > General

Direct URL:

http://example.com/admin/settings/lightbox2/general

My only change to the default settings is the following:

 Admin > Site configuration > Lightbox > Automatic image handling

Direct URL:

http://example.com/admin/settings/lightbox2/automatic

Set the Automatic handler for image nodes option to be Lightbox grouped. This means that the images will be grouped together but appear one at a time, with "Next" and "Previous" arrows and a dark shadow behind them.

Putting It All Together

If you’re using the Image Gallery’s default functionality, then all of your galleries will appear at:

http://example.com/image

Finally, the uploaded images themselves will appear in Lightbox format if you click on one of the thumbnails in a gallery.

Bonus: Using Ubercart to Handle Payments

I use Ubercart to handle user payments. This software is free and open source, and it allows you to sell products on your website. The products could be digital, such as high-resolution JPEGs (like screensavers) or PDF reports that are unlocked upon payment. Or they could be physical, such as signed prints, t-shirts, mugs, calendars or signed photos, which require shipment to the buyer.

Perhaps the site owner wants to sell subscriptions to the website, in which case the product would be a "membership package" that directs the purchaser to a "paid members" section for a fixed amount of time.

You can create a product by going to:

Admin > Content management > Create content > Product

Direct URL:

http://example.com/node/add/product

If you use Ubercart, you’ll need a payment gateway such as PayPal or Authorize.net to accept payments. If you choose to accept payments directly on your website, you’ll also need to purchase an SSL certificate to make data transmission from user to your web server (and back) more secure.

Examples

Would you like to see some examples of this deployment in action? Check out the following examples:

Missing Link

Images of logos, products and events for a bicycle co-op.

Wagner Society of Northern California

Images of members of an organization devoted to the famous composer.

Related Content

• 20 Drupal Modules to Boost Your Website’s Functionality
• CMS Showcase: 31 Remarkable Drupal Powered Websites
• 22 Excellent Tips for New Drupal Developers
• Related categories: Web Development and WordPress

About the Author

Monica S. Flores is a web developer through 10K Webdesign, which focuses on websites for progressive organizations and membership groups. She founded a member community for success-oriented women ASuccessfulWoman and one of the first green business directories by and for women GreenBusinessWomen. Contact her through Twitter.

Advertise here with BSA

I’m fairly new to the Ruby on Rails web application framework. I just started learning it about eight months ago when I started developing my web app.

I’ll share a story with you about my experience with Rails, and maybe you’ll be intrigued enough to try it out for yourself.

About My Web App

CompVersions is a web application that allows designers to upload multiple versions of their designs so that their clients can easily give them a thumbs up or a thumbs down as well as provide comments as necessary.

Here are some images of the app:

The idea for the app comes from my previous experiences working with multiple designers. I have, at various points in the past, worked on projects where I was either project lead or project manager and I had to coordinate designs and feedback from multiple designers and stakeholders.

Getting and forwarding emails with PDF files as attachments and notes specifying the line and page number in the PDF was not cutting it anymore.

I tried the popular project management app, Basecamp (also built on top of Rails, by the way), but it wasn’t designed for this problem, so it didn’t work the way I needed it to.

I decided to build my own solution.

A friend of mine (Hector) is on a similar journey (building a web app/site while still learning about the framework), but he is in "Microsoft Land" — .Net, IIS servers, MSDN — the whole nine yards.

I was explaining to him why I love Ruby on Rails (RoR for short), and how it completely abstracts the pain of doing things like database queries (although, if you want to work with them, you surely can).

I was trying to find a real-world example of what I meant, but all I found were the regular "build a blog in 15 minutes" tutorials and articles that take you through the entire app development process.

I didn’t want that, so I started looking through my code and realized that I have the perfect use case to highlight how wonderful it is to use Rails.

He appreciated the example, and understood what I meant by way of a practical, real-world example that’s actually in use.

I figured I would share to you that example I showed Hector.

Rails Business Logic

Rails is known for allowing the developer to focus more on the business logic of the application, rather than the technical, behind-the-scenes stuff.

What does that even mean? Here is an example: I was hooking up the email functionality for CompVersions so that once a designer registers, they get an email from the app.

I used a Rails gem (similar to what a plugin is for WordPress or a prewritten class in PHP) called Devise that makes it relatively easy to get up and running with an authentication solution. It handles users logging in and out: Registering, forgotten passwords, resetting passwords, and so forth. Locking and unlocking an account — say if your application requires high security where you only allow a certain number of login attempts — was baked right in, no need to code it. It had a bunch of other awesome features that solve everyday web app development problems.

That’s right, you get all that functionality from one Rails gem. All done to industry standard design patterns, e.g., when a user forgets their password, a unique link is sent where they can reset their password.

So the first question I was faced with was, How do I format the email? Not, How do I programmatically tackle something like this? or Can I write code to send out emails?

Do I say "Hi John!"? But what if there is no first name, how do I fallback to their username (sexyjohn79) and then subsequently their email (sexyjohn79@email.com)?

That’s business logic.

Writing the Business Logic

The registration form for CompVersions has input fields for first name, last name, username and email address. A user can log in with either their username or email address. But I haven’t decided whether or not I’m going to let first and last names be required form fields. Most likely, I will, but I wanted to implement it to gracefully handle the situations when a user doesn’t provide one or the other.

Rails uses what’s called an MVC structure. Model, View, Controller. Rails encourages you to put all of your business logic in the Model portion of your app.

In my User model (which is where Rails handles all the business logic related to the users of the app), I created a method called pretty_name that handles the business logic.

This is how my pretty_name method looks:

def pretty_name
  f_name || username || email
end

The first line is the definition of the method. The method is what I will invoke to print out the designer’s name in the email.

The method translated in plain English: "If the value f_name exists, return that value, if not, try username, and if that doesn’t exist, then try email". The syntax will be familiar to many of you: || means OR.

The assumption here is that a username must exist because the user will be getting this message through email. Ruby executes left-to-right.

That’s it. That’s the business logic.

Applying the Business Logic to the View

In my template for the actual email — the View in MVC — this is what the first few lines look like:

<p>Hi <%= @resource.pretty_name %>!</p>
<p>Thank you for registering with CompVersions.</p>

The template prints ‘Hi ‘ and then it invokes the pretty_name method on the object called @resource. @resource is an object that is used to refer to the current user account and then returns the best value.

So if the person’s first name is John and it’s available (i.e., the value is not nil), the email will say ‘Hi John’.

If there is no first name, it will use the username (e.g., ‘Hi sexyjohn79′).

If there is no username, it will say something like ‘Hi sexyjohn79@email.com’, falling back to the user’s email address.

The Result

Here is an example of how the email looks.

Some Parting Thoughts

So is Rails really a walk in the park for non-developers?

I don’t want you to misinterpret what I’ve said. I’m not implying that getting from nothing to a full SaaS web app with no Ruby and/or Rails knowledge is effortless. It’s not that easy.

But as a general rule when using Rails, the things you will be struggling with (once you get the basics down) are related to how the app will function (business logic) rather than the minutia, set up, coding syntax, and the writing of common web app methods and functions. The focus will be on the logic of the app rather than missing semi-colons, setting up a code project, and errant SQL queries.

Like all web development frameworks, Rails has its quirks. Rails has a set of conventions that make sense and force you to develop a certain way, which makes it especially tricky for those immutably set in their processes.

I hope this helps encourage you to try Rails and to consider it for your next web app project. There are many awesome tutorials out there. For starters, I would recommend Rails for Zombies.

Related Content

• Getting Started with Ruby on Rails: Installation
• Four Ways Ruby on Rails Can Help You
• How to Create a Blog from Scratch Using Ruby on Rails
• Related categories: Web Development and Web Applications

About the Author

Marc Gayle lives in Jamaica and is bootstrapping CompVersions with blood, sweat and care. He’s a proud advisor to Kingston Beta, an organization set up to help nurture local tech entrepreneurship. He blogs at marcgayle.com. Follow him on Twitter @marcgayle.