I think that any developer that creates customer-facing software dreams that their users rave about and show affection for the product. But being users of software ourselves we know it's not easy to like any application that much. There are usually so many other applications vying for our love, and they tend to be so bland and similar, it's easier to just treat them with equal disinterest.

Still, why some applications win your heart?

I would argue that this has all to do with the way such application let some of the hearts and souls that created the application leak through some inoffensive outlets.

The idea is that it is hard for users to attach themselves to something that has no sign of human behavior. Let me try to clarify this point with an example. Let's say Albert is your co-worker. He gets his job done but not always the same way every day. Sometimes he's not in the mood for water cooler chat, worried about the world financial crisis, sometimes he's thrilled that his team qualified for the playoffs, sometimes he's supportive when you are facing some personal problem. I mean, he's not a machine.

Take one of the biggest examples of them all: Google. Do you think the Google Doodles or the famous hidden treats are there just the works of mischievous coders? No. They are carefully placed messages that serve as a constant reminder that the folks at Google are real people and they like to connect with you, the user. What other email site would dare to have user message like "Hooray, no spam here!" ?

Why am I talking about this?

I've joined a new company a couple of months ago and I was pleasantly surprised to learn that we make use of those little outlets to connect to our users on a personal level as well. For example we change the site logo on special occasions and send plush toys to customers when we release a new version (plush toys, as a "weapon" of Marketing, deserves its own post. I'll leave that for another day.)

You may think this just sounds silly, but you should see the emails we get from customers when they notice these little things. They are thrilled to find them. Sometimes it makes someone's day. It happened again last Friday (Haloween — a major occasion in the U.S.)

It's very rewarding and I'm very proud to work with people that think about their users that much.

One of the reasons I've been mucking with NHaml is the upcoming meeting of the Chicago ALT.NET group.

The plan is to talk about NHaml and Spark (and maybe Brail), comparing equivalent implementations of a simple website written in ASPX, NHaml and Spark. The meeting is on November 12^th, see registration link below for details.

The Different Views of ASP.NET MVC

6:00 pm
Pizza and networking time

6:30 pm
The default ASPX view engine in ASP.NET MVC is fine and comfortable but as with just about anything in ASP.NET MVC, you can replace it with alternative engines — and there are a few of those available.

We will be giving an overview of some of the alternative view engines, showing how to install and use them, what brought them about, and why would you use them.

• Adam Tybor will be presenting Spark,
• Mike Hall will show NHaml,
• and TBD (not defined, wanna talk?) will talk about Brail.

7:45 pm
You may want to stick around after the presentation portion of the meeting and take part in our monthly open discussion. The topic is never arranged in advance but it's common that it reflects the content of the presentation.

I started playing with NHaml lately for sheer curiosity. It comes with MVCContrib and that's what I've been using to explore it.

I'm not completely on board yet that you'll want to write all your views, for all kinds of application scenarios using NHaml. I know someone will probably jump out and say that their entire site was built with NHaml and it's wonderful. I'm sure it can be done, I'm just still wondering if it's more trouble than necessary. On the other hand, if you are starting a new application from scratch (i.e. you are not inheriting any existing template or that sort of thing,) then NHaml can guide you through a different way of thinking about your views and simplify them a lot.

I might have already said this before, but I'm generally in favor of working as close to the platform as possible and viable. That's why I'm not a big fan of things like Script#, RJS, and Volta. NHaml is almost in the same category but it does bring some nice things to the table and that's why I'm not ready to dismiss it just yet. Just take a look at what our HTML looked like circa 1998 and what it is now with richer CSS and JavaScript.

As much as I can, I try to separate my (X)HTML from my CSS and my JavaScript. Sometimes it gets to the point that I wonder why I am using HTML to begin with — it's all data and structure. I wonder how long until we have a WikiText or MarkDown view engines.

NHaml fits well for these kinds of well-separated HTML views. It does away (kind of) with the HTML tags and focus on the structure and meaning of each piece of information. Because it defines structure in a way that works well with CSS, it also works great with jQuery for our JavaScripts. It's unobtrusive JavaScript heaven!

I think the key to learning NHaml is forgetting about HTML and its tags (or at least don't focus on them). Forget that the page ultimately rendered will be in HTML. For a moment just visualize the areas of the page as meaningful pieces of data: sidebar, lists, headings, article title, article body, author name, navigation tabs, etc, not divs, tables, spans, fieldsets, etc.

Less Noise More Content

The most obvious impression you get when looking at a NHaml template for the first time is how skinny it is compared to any tag-based template. Your eyes are used to look for angle brackets to help you understand the structure of the document, but in NHaml the indentation serves that purpose.

Take a look at a common template to create a grid of products in ASPX.

<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 
   "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
	<head>
		<title><%= ViewData["pagetitle"] %></title>
	</head>
	<body>
		<h1>All Products</h1>
		<table class="grid" id="products">
			<tr>
				<th>ID</th>
				<th>Name</th>
			</tr>
			<% foreach(var prod in (IEnumerable<Product>)ViewData["products"])  { %>
				<tr>
					<td><%= prod.ID %></td>
					<td><%=  prod.Name %></td>
				</tr>
			<% }  %>
		</table>
		<input type="button" value="Say Hi" onclick="alert('Hi');" />
	</body>
</html>

Now take compare that to the NHaml version.

!!! XML
!!!
%html
  %head
    %title= ViewData["pagetitle"] 
    %body
      %h1 All Products
        %table.grid#products
          %tr
            %th ID
            %th Name
          - foreach(var prod in (IEnumerable<Product>)ViewData["products"])
          %tr
            %td= prod.ID
            %td= prod.Name
        %input{ type="button", value="Say Hi", onclick="alert('Hi');"}/

Never Forget a Closing Tag Again

Having meaningful indentation brings the common advantage of needing to explicitly mark the end of a block, making that automatic. In other words, the closing tags are added at the right places for you. That's something I value a lot.

Identifiers and Selectors, Css-Friendly

By now, after looking at the above NHaml sample a few times, you probably noticed that the class and id attributes are set using a dot and a # sign, respectively.

%table.grid#products