Search is really just part of navigation. In many cases information found by running a search routine can also be found by just browsing through the pages. Which serves the visitor best? … is that also what serves the mission best?

Search needs words (also phrases) for searching. When visitors compose their own phrases, will those phrase be effective in searching the website? If not, then search terms should be offered as items in drop-down lists or some similar selection interface.

Next there is the question of what will be searched. A Google-like search can theoretically see every word in the public space of the website. Will this work OK? … will many irrelevant items be returned? … or should that type of “free word” search be used, but restricted to parts of the space with relevant content?

Another approach uses either “free word” input or “selected word” input to search only prepared fields in the database. This allows the web administrators to help or control the search results, but requires maintaining those fields of search phrases.

Many choices and variations are possible. Least expensive is installing one of the free search routines, one that can be limited to just the one website, as Google can. It has quick setup, little maintenance, is familiar to nearly everyone, but in a small website it can be quite imprecise and may often return empty lists.

I recommend a careful discussion with your website’s Information Designer.

Wanting to be as unbiased as possible, I have researched online several times and offer these two third-party views:
http://www.bivingsreport.com/2007/wordpress-vs-drupal/
http://www.quis.com/2009/06/01/drupal-vs-wordpress

Both articles try to be unbiased, and I think they succeed. Neither writes that WordPress and Drupal are on the same plane. They both assign WordPress to the simplest of websites and Drupal to the next echelon. This matches our considerable experience. WordPress provides an elegantly ease-to-use CMS. It is the appropriate choice for lightly featured blogs and very simple websites.

Here’s the experience of someone who “loves” WordPress (the language needs editing):
http://kevinjohngallagher.com/2012/01/wordpress-has-left-the-building/

The Drupal community is on a different track. Drupal is a machine for making interactive websites – newspapers, magazines, large corporate websites, online stores. In the spectrum of technology, Drupal picks up where WordPress leaves off, and takes us toward standard web applications. When the project no longer fits “standard things you do on a website,” it is a web application that requires a web application framework. GORGES will in that case recommend the appropriate framework, maybe Ruby on Rails, Yii, or .NET.

It should also be noted, that when a client is engaging GORGES to perform setup, to propose designs, to guide the process and provide training, the distinctions having to do with ease of setup, theme decisions, and ease of use become inconsequential. GORGES shoulders those.

The differences between WordPress and Drupal are finally differences in capability. What interactive features does your website need now and how likely are you to want significant visitor interaction in the future? Is the site to be a one-time undertaking, or is it likely to grow thought time? If these are not issues, WordPress might be just right.

In this article, we will discuss approaches to creating charts on the web. Currently, there are two general approaches to creating charts on the web: Image-based versus Scalable Vector Graphics (SVG)-based. There are also Flash-based solutions but we cannot recommend them because Flash is not available on iPhones and iPads and the future of Flash-based solution is uncertain.

Image charts
Here, the server generates a static image (e.g., a JPEG) of the chart from the data and the image gets displayed in the browser. There are a plethora of server-side charting implementations to choose from — a noteworthy one is Google Image Charts: http://code.google.com/apis/chart/image. Since the chart is simply an image, there are no cross-browser issues and the look of the chart is also consistent across browsers. The chart can easily be exported for usage in presentation slides since the chart is just an image file. However, the disadvantage of this approach is that users cannot interact with the chart; they cannot click into a pie chart slice or hover over line graph points to better understand the data being presented. While image-based charts provide a consistent and reliable view of the data, this approach does not give your end users necessary usability needed to make effective use of the information.

SVG charts
Here, the rendering of the chart is strictly on the client browser: There is no server-side rendering of the chart. Data are passed into a JavaScript SVG library which renders the chart as SVG markup (or VML markup if the user is on Internet Explorer 6/7/8). The browser produces a chart from the resulting markup that is mostly consistent across browsers. (We have run into an edge case issue where labels on pie charts get cut-off in Internet Explorer.) Exporting the chart into a file for use in presentation slides is a little trickier — since SVG charts are derived from JavaScript libraries and you cannot create files using JavaScript (at least not easily or consistently across browsers). One possible solution is to post the serialized SVG output back to the server-side and convert into the desired target format (e.g., JPEG, PDF, etc.). These relatively minor issues are offset by the huge gain in chart interactivity. SVG charting libraries allows developers to attach mouse click and hover events to the charts, such that a user can drill down into a pie slice of a chart or hover over line graph points for a more comprehensive view of the data. The SVG charting libraries tend to be relatively easy to use for developers comfortable with JavaScript, relative to the server-side charting tools.

Choosing a solution
When choosing a charting solution, it is necessary to consider the following requirements:

• Does the chart have to be interactive? If the answer is a resounding yes, then SVG approaches are the only options.
• How important is exporting chart into other file format? If very important, then it may be worthwhile to look at image-based solutions or possibly dual solutions of both SVG and static images.
• Are we dealing with tens of thousands of data points? If yes, then it may be neccessary to sacrifice the interactivity of SVG charts for performance of static image charts.

SVG solutions
Below is a brief descriptive of three SVG libraries. This is by no means a comprehensive list.

• gRaphael: http://g.raphaeljs.com
• Only completely free solution of the three.
• Not as mature the others and poorly documented.
• Programming somewhat easy.
• Fewer eye candy.
• Bottom-line: Check back in 6 months; the library is improving rapidly.
• Google Chart Tools: http://code.google.com/apis/chart
• Does not cost money but source code is not available and hard dependency on Google’s server.
• Mature and well-documented.
• Programming not as easy but powerful.
• Better eye candy — see Geographic chart.
• Bottom-line: Good solution but the charts and data security are heavily dependant on Google’s server.
• Highcharts: http://www.highcharts.com
• Costs money (couple of hundreds) but open source.
• Mature; Good documentation.
• Programming is easy.
• Best eye candy — charts will “pop” to your users.
• Bottom-line: Best overall general-purpose charting solution.

Usually developers work directly on their workstations or laptops, and a development environment has both web and database services running similar to a production server. Ideally a development environment should have the same versions of services as the production server, for example PHP 5.2 or Ruby 1.9.  On more than one occasion I have been bitten by writing MySQL 4.3 or 5 code, but the production server has an older version of MySQL without sub-query support so the queries had to be rewritten.

Usually these development services are customized for development, for example the database does not have to be hardware-optimized and the web service can have debugging tools enabled.  I prefer to turn on all warning messages, so any identified problems that are not severe enough to halt page serving will be shown either in a log file or onscreen.

Just as important with having a staging server is to have clean and well-structured publishing scripts.  If you are relying on a manual process to upload files using FTP, then it is possible to skip an updated file by mistake.  Publishing scripts come in all sorts of flavors and approaches – we have both “pull” methods that use server-side scripts, and “push” scripts that execute on the developer’s computer and automatically upload files to the server.  The push scripts are built on Capistrano, which although it is based on ruby we sometimes use at Gorges for non-ruby websites.

We routinely protect our staging servers from prying eyes and search engines by using HTAuth username and passwords.  Once a website is scanned by a Google, Bing, or other web crawler then it is out of your control.

Having a staging server doesn’t mean much unless it is actually used to test new features and look for bugs.  Quality assurance is important, and I have yet to meet a developer that produces bug-free code or see a unit testing system that covers 100% of a web application feature set.

Not covered in this post is the issue of database migrations between developer environment and a staging server, and also from a staging server to a production machine.  These can be tricky, but as with all challenges the proper planning will guide you to the best solution.

After the application or update goes live to the production server most staging servers are continued as “sand boxes” to support additional updates and testing.

Finding straightforward explanation of how to immediately dive in proved to be a bit painful – most of the tutorials I found seemed to be aimed towards clients or casual Facebook users rather than developers. I thought I would compile the information I found useful in quickly making custom tabs for Facebook pages.

First of all, even though they still use the term tab, what we are talking about are the links in the left column that fall under Wall.  A standard first  custom tab to add is a Welcome tab.

I originally tried using an existing app (Static HTML frame tabs) which worked fine, but had two major disadvantages.  One was that you could not assign a custom icon, and the second that it could only be used to create one link.  This could be handy for a quick and easy custom welcome page, but most likely a client is going to want more than one custom tab.

I won’t cover signing up as a developer, but basically it involves creating a Facebook account and being assigned as an admin to an existing business page, or creating your own.  You will also need to be confirmed via a text to your mobile phone or by entering a credit card.

After you’ve done this, you can head on over to http://developers.facebook.com, and hit the Apps link, and then the + Create New App button:

Create a name for the app:

This will create an app with an app ID (which you will need later).

For now, you can just upload a 16×16 icon that you would like to appear to the left of the link on your page.

Now, click the On Facebook link in the left column.

Enter the Tab Name (This is the name of the link as it will appear on your page) and the Tab Url.

The Tab Url is a link to a file hosted somewhere else that will be placed in the iframe (more on constructing this later)

After saving, click View App Profile Page in the left column

Now you can click Add to My Page , and then select the page (for which you are already an admin) that you wish to add it to.

Now, if you navigate to the page you’ve added it to, you will see it as a tab in the left column:

Hit the Edit button below the tabs to rearrange the tabs, but note that Wall and Info will always come first.

To make this new tab the default landing page of your site, click Edit Info at the top of your page.

Now click Manage Permissions and then choose the Default Landing Tab from the dropdown.  Note that fans and admins of the page will always be directed to the wall – this default landing page only applies to anonymous users or non-fans.

Finally, a note on creating your content for the iframe. I initially ran into some problems with scrollbars appearing both vertically and horizontally in the frame – the solution was to include two Facebook scripts and apply a little bit of css, all of which you can see in the basic template below. You’ll need to modify the height, add your content, and also include your app id in the bottom script.

<!DOCTYPE html><html>

<head>

<title></title>

<script type=”text/javascript”>window.fbAsyncInit = function() {FB.Canvas.setSize();}function sizeChangeCallback() {FB.Canvas.setSize();}</script>

</head>

<body style=”width:520px;overflow:hidden;”>

<!– Modify height if necessary –>

<div style=”width:520px;height:1000px;overflow:hidden;”>

<!–Your Content Here –>

</div>

<div id=”fb-root”></div>

<script src=”http://connect.facebook.net/en_US/all.js”></script>

<script>

FB.init({

// CHANGE THIS TO YOUR APP ID

appId : ’123456789′,

status : true,

cookie : true,

xfbml : true

});

</script>

</body>

</html>

That’s all you need to do.

Most people simply do something along the lines of this:

$('body').append('<h1>Hello, World</h1>');

jQuery injects the HTML string into the DOM, and all is well.

But sometimes you need to inject more structured content, or even entire forms – what I typically do is something along the lines of this:

jQuery('body').append(
  $('<div/>').append(
    $('<div/>').text('Hi there'),
    $('<p/>').text('How do you do?')
  )
);

With all the parentheses, angle brackets and repetitive calls to append(), this doesn’t exactly look nice.

Recognizing the repetitive construction of elements, followed by calls to append, what if we had a set of tiny functions that would do both in one simple operation? I decided to give it a shot, and here’s what it looks like:

jQuery('body').append(
  $div(
    $h2('Do you love it?'),
    $form(
      $div('Sign here:', $text()),
      $div($label($checkbox('yes'), 'I love it!')),
      $ul(
        $li($radio('1'), 'Option One'),
        $li($radio('2'), 'Option Two'),
        $li($radio('3'), 'Option Three')
      ),
      $submit('I submit!')
    )
  )
);

The functions prefixed with the $-sign create the elements, and pass down any arguments to the append() method.

The input element methods, such as $radio and $submit are a bit different – they create input elements, set the type-attribute, and if you pass them an argument, they apply that as the value-attribute on the element. (input elements can’t have child-elements, so this doesn’t get in the way of anything.)

You can see a working example and source code here.

Because JavaScript is a highly dynamic language, I didn’t need to write each of these $-functions by hand – with just 13 lines of JavaScript, applying a simple meta-programming technique, all of the functions are automatically generated.

Finally, it’s worth noting that something like $('<div/>') actually results in a string of HTML being parsed and then inserted into the browser. My handy little DOM-helpers avoid the parser – they access the DOM and create HTML elements directly, which means they execute around 10 times faster compared to the first example.

Update

One of my GORGES colleagues pointed out the fact that I had no convenient way to apply attributes to the created elements – if you don’t like the repetitive calls to attr(), try this updated version, which provides a simplified way to apply attributes quickly. This takes a bit more code, but I suspect he’s now porting this to CoffeeScript

Web developers typically write unit tests on server side code and rarely on client side code, which is where JavaScript resides. This approach is reasonable given that the majority of the application logic of web applications run on the server side. However, as the web become increasingly more dynamic, so does the number of lines of JavaScript code needed to support a rich user experience. The need for unit testing in JavaScript should be apparent, yet JavaScript unit testing have been largely ignore.

One reason why developers don’t write JavaScript unit tests is that JavaScript testing is front end testing. Front end tests are hard to write and we are better off leaving it to manual testers. Keep in mind, however, that application logic tend grow exponentially in complexity. So unless the project has the resources to hire manual testers at an exponential rate, it is far more cost effective to devote the time to write tests.

Another reason for not writing JavaScript unit tests is the belief that client side programming logic should be minimized and pushed into the server side wherever possible. The rationale is that JavaScript unit testing is not needed if the code base is small. In other words, not writing JavaScript means not having to write unit tests. However, as mentioned, JavaScript is needed to support a rich web experience. Not writing JavaScript is not an option if a modern web experience is desired.

There are many free and open source testing frameworks available for JavaScript. Three such frameworks are: Selenium, JS Test Driver, and QUnit.

SELENIUM, http://seleniumhq.com

Selenium is not a JavaScript testing framework. Rather, it is an end-to-end testing framework for web applications. So Selenium implicitly tests the JavaScript portions of a web application. Selenium works as follows:

1. Write your Selenium scripts. The scripts can be written in many languages including PHP, Ruby, C#, and Java. If you don’t know how to program, you can use Selenium IDE which is a Firefox plugin that records your mouse clicks and typing web browsing behavior to create test scripts
2. Your unit test runner (e.g., JUnit) sends the scripts to the Selenium server
3. The Selenium server launches browsers and runs the tests. The Selenium server can be configured to launch different browsers on different computer platforms (e.g., PC, Mac, Linux).

Note that Selenium runs your tests using real browsers so you get comprehensive tests of your web application against various browsers. The downside is that the comprehensiveness also leads to complexity of setting up the Selenium server and stand-by machines waiting for Selenium tests. Selenium is best suitable for large web projects with the resources needed to configure various servers.

JS TEST DRIVER, http://code.google.com/p/js-test-driver/

JS Test Driver can be thought of as Selenium-lite but specifically designed for unit testing your JavaScript code (as opposed to end-to-end integration testing as is the case with Selenium). The test runner for JS Test Driver runs your unit tests in the same manner as Selenium. JS Test Driver launches your browsers and executes your tests inside the browser. JS Test Driver can also be integrated into the Eclipse or IntelliJ IDE as a plugin which provides a one click interface to running your JavaScript tests.

QUnit, http://docs.jquery.com/Qunit

QUnit is the simplest of the three framework. You write your tests in JavaScript and embed it in an HTML page with qunit.js and qunit.css include. To run your tests, you simply refresh the page in your browser. There is almost no learning curve for developers familiar with any of the xUnit framework. Because of its simplicity, there is no out-of-the-box support for running your tests on multiples browsers simultaneously, unlike Selenium and JS Test Driver.

Which framework?

These three frameworks all serve different testing needs and are by no means mutually exclusive. If you are only interested in end-to-end integration test, then Selenium is a good choice if you have the resources to set up your testing environment. If you see the value of unit testing JavaScript in your web application, then QUnit is the easiest way to start but look into JS Test Driver as your testing need evolves.

There are several steps in planning.

• Needs Assessment
• Platform Analysis
• Information Analysis
• Wireframing
• Prototyping
• Work and Phase Planning
• Budget Planning

All of these save money and improve the quality of the product. As consultants we also know that involvement and review with the client is a critical part of each planning step.

One of my favorite steps is wireframing because this is where the idea first takes graphic form. There are many small apps for making wireframes.

The wireframing tools that we have used within our office, here are some we like:

Eclipse with a Wireframe Sketcher plug-in ($75 or $37.50 for students). We have a GORGES license, and there is a downloadable standalone version available (http://wireframesketcher.com). You can probably try before buying.

Omnigraffle Pro (Mac-only application). We have an office license, but since it is Mac-only only a few developers use it here.

Pencil (free Firefox Browser plug-in, http://pencil.evolus.vn). Feature-limited and sometimes awkward, but the price is right.

Balsamiq – online version; useful for working remotely. We used this a few years back when it was in free beta stage. http://www.balsamiq.com.

Microsoft Visio – my least-favorite tool because of cost and clunkiness, but perhaps the leading prototyping tool thanks to Microsoft’s influence.  http://office.microsoft.com/en-us/visio/.

JS has been around since the late 1990s. Like a house with several owners with different tastes, it’s been added on to over the years. It’s really easy to write ugly JS, chock full of bugs, that no other developer will ever want to or be able to read. You can accidentally open memory leaks that crash the browser. You can accidentally put a variable in the global namespace and cause the rest of the program to come to a crashing halt, or behave mysteriously.

At the same time, the core of JS is a beautiful language that, if you stick to the “good parts,” can support the richest of rich client apps with grace and aplomb. That is where CoffeeScript comes in.

CoffeeScript (CS) is a language that compiles into JavaScript. It makes it easier and less tedious to do good things with JS, and harder to do bad things. Because CS only turns into JS when the i’s are dotted and the t’s are crossed, it is harder to write buggy JS.

Line Noise Reduction

Programming languages based on C or Java, such as JS and PHP, are filled with parentheses and semicolons to tell the computer where each block of code starts and ends. Keywords such as “var” and “function” tell the computer which are variables and which are functions. The programmer’s eye gets used to them, and may even come to rely on them to interpret code on the screen.

Oftentimes before I write a paper I begin with an outline. Top level items are on the left, and each layer of sub-item gets one level of indentation. My word processor responds when I press the TAB key, and has an indent button. There is no facility to write an outline like the following, nor is there a word processing facility for doing so outside of a code editor:

I. The Industrial Revolution {
    A. Origins {
        i. deforestation in 17th century England
        ii. proximity of coal and iron deposits
        iii. accumulation of capital from overseas trade
    }
}

Therefore if you want to make code more human readable, replace the braces with indentation, and let the compiler put them back in for you to make the computer happy. CS does this, calling it “syntactic white-space”:

class App
  ...
  initUI: ->
    if $('#controls').size() is 0
      $('#title').append render('searchControls')
      JKT.earth.addControls() if (JKT.earth)
    ...

becomes:

App = (function() {
  function App() {
    ...
  }
  App.prototype.initUI = function() {
    if ($('#controls').size() === 0) {
      $('#title').append(render('searchControls'));
      if (JKT.earth) {
        JKT.earth.addControls();
      }
    }
  }
  return App;
});

I personally find the CS more meaningful, and the compiled code to be cleaner than the code I would have written to do the same thing (although it’s not fashionable to admit that your code isn’t always the cleanest and most awesome code anyone has ever written).

Notice that the -> stands for “function”, and function name colon: means “add this function to the object prototype.” Please read the CS documentation a few times before you try CS – this is just the beginning of the stuff you can do.

The bottom line is that “line noise reduction” removes as much computer-oriented meaning as possible from the code, while leaving the human-oriented meaning. The principle is that while programmers write code for computers to run, unless it’s one-time only throwaway code, they’re also writing code for other programmers (including themselves when they come back to it three months later to add a new feature). The less time it takes a programmer to figure out what is going on, the higher the business value.

Meaningful Code is Cleaner Code

The code snippet above isn’t necessarily fair, because it doesn’t show JS “before I started writing CS.” I see that it has benefited from the other thing I most like about CS: to make it easier to debug, you have to break it down into smaller parts. Smaller parts that do one thing only are cleaner parts.

That’s right. In the old regime, I might have a JS file with several hundred lines. When a error pops up, Firebug will tell me what line it’s on, and I can jump to it in the code editor and fix it. Maybe right there I will add some more code, and pretty soon I’ll have a large JS file that is hard to edit without Firebug, with lots of interconnected parts and mixed behaviors.

Since CS makes working with the JS object model so easy, I find myself using it. I would take that 500 line JS file and break it into a half dozen or more constituent parts. I have development mode set to deliver these to the browser individually, so if an error crops up, it’s easier for me to find it in the CS. Production mode combines and minifies the JS into one file for speed of delivery to the user.

If you’re coming from Ruby or Python, you’ll recognize the philosophy of human oriented code. You’ll also recognize that CS is 2/3 Python and 1/3 Ruby. Therefore CS will be easier for you if you know one of those; likewise if you hate Ruby, stay away from CS. (And if you don’t know JS yet, don’t try CS…)

Gotchas

I must admit that CS came with some pounding of my head on the table, especially when I started. Here’s where I got stuck, and what I did to get unstuck:

1. I started by opening a JS file and “saving as” a coffee file. DON’T DO THAT! Create a new coffee file, copy the JS from the JS file, and paste it into the coffee file. The paste action will get the indentation right.
2. Your code may look indented to you, but it may not be so for coffee. You may have SPACES mixed in with your TABS.

When you make changes to coffee but nothing seems to happen in the browser:

1. First check that you are running the compiler. I have a shell script that starts coffee’s compile-on-edit mode. Sometimes I forget to run it. By the third alert statement, I check for that.
2. Second, check the compiler output. You may have a syntax error in CS. It won’t compile at all if there’s a problem with the CS. If you see “cannot use a pure statement in an expression”, it usually means there’s a rogue space in your tab indentation. Redo the indentation and try again.
3. Third, if the CS compiled but weird things are happening such as it says a function doesn’t exist when you know it does, check the compiled JS. Sometimes there is an indentation issue that doesn’t break the compiler, but causes it to misinterpret where classes end and begin.

In a perfect world

CS is new. Therefore it is not integrated into most IDEs yet. Since Rails 3.1 uses CoffeeScript, it shouldn’t be long before you see CS support in Aptana. There is an IntelliJ plugin for RubyMine and PHPStorm. I use the TextMate bundle. My colleague Jim uses Eclipse and edits it with plain text, as he finds it still easier to read than JS.

Getting started

I recommend going to the CS website (http://jashkenas.github.com/coffee-script/). Read it a few times before you do anything. Bookmark it. Then install node, npm, and coffee.

When I started on CS, I had a few thousand lines of JS already written. Most of it was for a prototype, and I dreaded having to whip it into production grade and add the rest of the features to it. I started learning CS by porting some of the easier JS files. When I was comfortable, I took on the hairy part. It emerged as a piece of code I’m proud of and like to work with.

In a nutshell, CoffeeScript makes it fun for me to write clean JavaScript, and delivers business value by helping me to write maintainable JavaScript faster that it otherwise would. If you’re not using it yet, it’s time to start.

References/Additional Resources

1. The CoffeeScript web page: http://jashkenas.github.com/coffee-script/
2. My presentation to the Ithaca Web Group: http://www.slideshare.net/davidfurber/real-lifecoffeescript
3. Tongue in cheek presentation of why you’ll hate CS: http://www.slideshare.net/tim.lossen.de/coffeescript-7-reasons-you-are-gonna-hate-it
4. The PeepCode screencast, “Meet CoffeeScript”
5. The PragProg book (written by yours truly), “CoffeeScript: Accelerated JavaScript Development”
6. The CoffeeScript Cookbook wiki (new, but promising)

I will be focusing on the Ruby implementation in this posting, but note that there are also implementations for PHP, .NET, Java, and several other languages. As you might expect with Ruby, HAML is installed as a gem, and once installed, all .erb files can be renamed .HAML to be run through the HAML compiler.

When using HAML, tags are marked with the % symbol. For example:

%strong hello

This would be compiled to:

<strong>hello<strong>

Although you could write:

%div hello

to create a div, it is not necessary as HAML makes the common div tag the default. It also borrows the period symbol from CSS to denote class, so the following:

.content Hi

would be compiled to:

<div class='content'></div>

Classes can also be chained, so the following:

.content.notice Bye

would be compiled to:

<div class='content notice'>Bye</div>

HAML is whitespace active, so we can nest divs as follows:

#parent
  #child
    #grandchild
      #brother-twin I am the evil twin
      #sister-twin I am the good twin

to create:

<div id="parent">
  <div id="child">
    <div id="grandchild">
      <div id="brother-twin">I am the evil twin</div>
      <div id="sister-twin"> I am the good twin</div>
    </div>
  </div>
</div>

Comments are also more legible in HAML:

/ here is a comment

would generate the bulkier:

<!-- here is a comment -->

HAML includes filters which are denoted by a colon, and some examples are

:plain
:javascript
:markdown

You can also create your own. Usage is simple:

#content
  :markdown
    Some *emphasis*

would compile to:

<div id="content">
  <p>Some <em>emphasis</em></p>
</div>

Including Ruby (or other) code is either silent with the dash symbol, or inline with the equals symbol.

#content
  .title
    %h1=@title

would create:

<div id="content">
  <div class="title">
    <h1>My Page</h1>
  </div>
</div>

One of my favorites is the Object Reference, which uses square brackets with an object. Basically, given an object, it will work as div_for and content_for in Ruby, generating a id and class name based on the id and class of the given object. This is very handy for use with javascript and jquery and really polishes the markup.

%div[monster]
  %ul.eyeballs
    -monster.eyeballs.each do |eyeball|
      %li[eyeball]
        =eyeball.color

would create:
<div id="monster_4">
  <ul>
    <li id="eyeball_1">Green</li>
    <li id="eyeball_2">Blue</li>
    <li id="eyeball_3">Grey</li>
  </ul>
</div>