Building Site Navigation with Markdown and Nokogiri

Who knew that Markdown — in my opinion the best text-to-HTML syntax available — could be used for something other than blog posts (or Github readme files)? Turns out that Markdown can be used as a powerful way to make web app navigation really simple to edit, even by non-developers. The task I set out to do was to turn something like this:

* Home
* About
    * About Us
    * API
    * Terms of Use
* Browse
* Etc.

into a nice dropdown menu. Making this markdown text available to a view is a fairly simple task. In Ruby on Rails, if you have a Page model that can hold Markdown text, you simply have to fetch it in the controller and call .to_html.html_safe on it. Also, with the help of some ternary operator elegance, you should make sure that if the page doesn’t exist, the code doesn’t blow up.

c_nav = Page.find_by_slug 'client-nav'
@client_nav = c_nav.nil? ? '' : c_nav.to_html.html_safe

So now, with the addition of a simple line in the view where we dump the contents of @client_nav onto the page, we’ve accomplished displaying a terrible looking unordered list when we could have just hard coded a nice looking menu in Haml. Here comes the fun part.

The obvious first choice for this task was to use jQuery to dynamically add CSS styles to the unordered list to turn it into a nice navigation menu. With the use of jQuery’s addClass method this is fairly simple, and it worked when I implemented it with just a couple lines of code. Unfortunately it resulted in annoying flickering as the page loaded because the unordered list is displayed un-styled for a split second (unacceptable). This could probably be fixed, but why bother doing something on the browser when it can be handled perfectly well on the server? After a couple of painful hours attempting to add classes to the generated HTML using Ruby string manipulation techniques and having little success, I discovered that this problem had already been solved by the creators of the Nokogiri gem.

To begin turning the raw HTML into styled goodness, I first stripped out the opening and closing ul tags manually. I enclosed the code to do this in a beginrescueend block because the test suite I’m using (Rspec) didn’t like me using negative numbers for indexes in a string for some reason.

begin
   @client_nav[0..3] = ""
   @client_nav[-5..-1] = ""
rescue
end

Then I let Nokogiri work it’s magic.

@client_nav = Nokogiri::HTML::DocumentFragment.parse(@client_nav)
@client_nav.css("li:root").each do |anchor|
   anchor['class'] = 'nav_item'
end
@client_nav.css("li:has(ul)").each do |anchor|
   anchor['class'] = "nav_item more"
end
@client_nav.css("ul:first-child").each do |anchor|
   anchor['class'] = "dropdown"
end
@client_nav = @client_nav.to_html.html_safe

Because the HTML I was passing to Nokogiri is just a fragment of an unordered list, I used the DocumentFragment.parse method to prepare the HTML for Nokogiri to dynamically add CSS. Then, using basic CSS selectors (as well as one really useful one — has() — taken from jQuery), I added the proper classes to the list elements. It worked like a charm.

I’ll leave the CSS magic up to you — suffice it to say that with the proper stylesheets, this can look really great and is infinitely configurable. Why bother with bulky client-side code when Nokogiri provides a just as (perhaps even more) elegant solution?

Advertisements

Tag Clouds in Ruby on Rails

Tag Cloud
My finished tag cloud.

One of the first projects I got to work on at Art.sy was a tag cloud that provides a quick visual representation of the types of artworks that are in the site’s database. These can be quite visually striking if done correctly, but can be ugly if done poorly. Some of this is a result of design considerations (the underlines on the second tag cloud aren’t helping) which is definitely not my area of expertise, but the algorithm behind a tag cloud is just as important if it is going to be successful.

Just like any good Ruby on Rails/jQuery developer, I first scoured the internet to see if someone had already solved this problem adequately. What I found wasn’t too promising — many of the plugins were using math that would output text in just a couple of preset font sizes, and wouldn’t fully capture the relative frequency of a given tag. I determined that I would have to build it myself, and because at the time I was much more comfortable with Ruby than I was with JavaScript, I decided that I’d build the logic into the backend rather than build a jQuery plugin. I did get help on the algorithm, however. The best one I found was the following (which I’ve translated into Ruby):

weight = (tag.count-minOccurs).to_f/(maxOccurs-minOccurs)
size = minFontSize + ((maxFontSize-minFontSize)*weight).round

For the code above, minFontSize and maxFontSize are constants that you decide beforehand that dictate the font sizes for the least occurring and the most occurring tag. For my purposes, a min font size of 5px and a max font size of 100px worked nicely. minOccurs and maxOccurs need to be determined algorithmically before running the above code (this is quite easy for my setup, and we’ll see). The way this code works is slightly cryptic, but basically it first determines a ratio of how much the tag differs from the lowest tag relative to the entire span of tag counts, and then uses that ratio multiplied by the span of font sizes to determine how much greater the font size should be for a given tag above the minimum font size.

The rest of the code isn’t too difficult, but took a while for me to configure correctly. To start, it’s a little unclear where exactly this code should go. I initially created a tag_cloud method in the Tag model, which I then called in the controller to pass to the tag cloud view, but that doesn’t really make sense because the logic here has to do with font sizes and other visual considerations and thus shouldn’t be in the model. I ended up putting all of the logic in its own method in the tags controller.

def tag_cloud
   tags = Tag.asc(:name)
   if tags.length > 0
      tags_by_count = Tag.desc(:count)
      maxOccurs = tags_by_count.first.count
      minOccurs = tags_by_count.last.count

      # Get relative size for each of the tags and store it in a hash
      minFontSize = 5
      maxFontSize = 100
      @tag_cloud_hash = Hash.new(0)
      tags.each do |tag| 
         weight = (tag.count-minOccurs).to_f/(maxOccurs-minOccurs)
         size = minFontSize + ((maxFontSize-minFontSize)*weight).round
         @tag_cloud_hash[tag] = size if size > 7
      end
   end
end

All I’m doing here is storing the tag objects and their calculated sizes in a hash to send to the view. I’m excluding tags from the hash with calculated sizes less than 7 for purely aesthetic reasons (there were a ton of tags, and having all of them in the tag cloud didn’t look great).

The view code, written in Haml, is even more straightforward.

#tag_cloud
%h1
   Most Frequently Used Tags
- if @tag_cloud_hash != nil
   - @tag_cloud_hash.each_pair do |tag,size|
      .cloud_element= content_tag(:a, tag.name.downcase, { :href => "#{tags_path}?tag=#{tag.slug}", :title => "#{tag.count} artworks", :style => "font-size:#{size}px;" })

Actually, the part of this project that took the most time were the stylesheets, mostly because I find CSS in general to be really counter-intuitive. It’s always unclear to me what styles are being inherited when I’m working with large stylesheets. Luckily, I’m writing the styles in SASS which helps a lot. Here’s what I came up with:

#tag_cloud
   display: block
   width: 600px
   margin-left: auto
   margin-right: auto
   h1
      text-align: center
   .cloud_element
      display: inline
      a
         text-decoration: none
         line-height: 110%
         vertical-align: middle

Put all of this together and you get a pretty nice looking tag cloud. There are of course tons of possible improvements, and it still looks nothing like my example of a well done tag cloud, but this is a good start and is a big step up from a lot of the tag clouds I’ve come across online (including the one on this site). If I ever come back to this project to improve it, I’d probably redo it in jQuery rather than keeping the logic on the backend. While writing the code in Ruby was (I think) much more elegant than a potential JavaScript solution, moving to frontend code would open up the doors to tons of fancy effects. And fancy effects are cool.