Haml Tips and Tricks

I use Haml for my templates, and I mostly love using it and find it very intuitive. However, there are a few things that seem to trip me up on a regular basis, and I constantly find myself googling for the same Stack Overflow posts … so now I’m doing something I should have done ages ago and just posting them here for easy reference. Hopefully they might even help somebody else.

Don’t escape my HTML

By default, Haml escapes HTML, because in most cases this helps protect from XSS – but sometimes it’s my HTML and I know it’s safe, so I don’t want it escaped – or maybe I really just wanna let the bad guys hack me. For this, use an exclamation mark (!).

!= "I like my html UNESCAPED!!"

Thank you Haml Docs.

Whitespace removal

Ever want to do a link followed by a comma? You know, like that? Only if you do that in Haml:

You
%a know
, like that?

It comes out with a space: You know , like that? But you can fix it with the greater than operator, >, which removes all whitespace surrounding the tag.

Thank you, Haml Docs and Heikki on Stack Overflow

You
%a>
 know
, like that?

Inline, Indented Javascript

This is almost always a bad idea, but if you find yourself forced to do it, use the javascript filter.

:javascript
  function myFunction() { 
    // do some stuff
  }

Thank you Haml Docs and bcoughlan on Stack Overflow.

The Haml docs contain a lot of other useful stuff, but these are at least two things that I am tired of looking up!

Let your users direct the tech

I was trying to explain to my co-founder Liz last night the changes that I’d been making to Cake, the system that we use to process enquiries from our website, when she frowned and said, “that sounds really complicated.”

It stopped me in my tracks – technology is supposed to be enabling our company to move faster! She went on, “Trello is so simple in comparison!” She’s right on that – Trello IS simple but it only covers one part of of the process, while Cake is trying to do all the things. But it was time to stop ignoring that niggling feeling that I was losing my direction on what I was building, and revisit the system with the person who actually uses it every day.

So co-founder-2 (Phil) and I sat down today, hooked his laptop up to a large TV screen and started putting orders through on the staging site, all the way from the customer placing them, through to the supplier accepting them, and the customer confirming and paying. I played the part of the customer, and Phil took on the two hats of the supplier and himself, doing his daily job of processing orders for You Chews. It was a bit confusing – would have been better with Liz to act as supplier!

Things started off slowly. I’m using a Kanban system to pull changes through to production, and I’m releasing changes sometimes several times a day. For Phil, that means that the system and processes he uses are changing every day – and even when it seems to me like it’s for the better, sometimes it’s just a PITA. It’s not until you see somebody else using the system that you built that you start to see whether or not it will actually work!

The first order was a bit of a struggle. It became obvious fairly quickly that Cake needs to update the order status automatically, that having that as an extra step makes it significantly more confusing.

With the second order, we discovered some bugs in the steps to email the supplier – luckily they were just config issues, so I fixed them, and we were off again.

The third and fourth orders started to go more smoothly. Phil was following the steps he had noted down for himself, knew that there would be upcoming changes to automate the status updates, and asked loads of questions. He consistently deleted one part of the email that would go to suppliers, so it was really clear that it wasn’t needed. Towards the end of the meeting, he was even getting excited – “This is great! This is great!” – he even said at one point. We discovered a ton of places where small changes like wording could make the process smoother, and I walked away with a much clearer vision of what I need to create to make the system useful for him. Phil even left saying that he’d enjoyed the meeting – we spent about two hours in that room, so believe me that is quite an acheivement!

It reinforced a few things for me. Firstly, and most obviously, test the system with real users. They can be customers or staff – and don’t just do a quick test, let them use it a few times, see if you can provide help and direction and if that makes a difference, and watch what they do. The more they use the system, the more useful feedback they’ll be able to provide you.

Secondly, if you’re working in a fast-paced environment, constantly pushing through changes, it’s a good thing to stop and review the bigger picture every so often. It doesn’t need to be a big, formal process – I spent five minutes sketching a diagram of what I was trying to do, and fifteen minutes talking it through, and was far more confident that I was heading in the right direction.

Lastly: if you are going to do user testing, expect to walk away with a longer to-do list!