Attention talented designers and CSS gurus! Check out the newly launched www.teamviget.com to meet our design team and learn why we LOVE working at Viget Labs. Then, apply to one of our current openings and tell us why YOU want to be a part of that energy, too.

Ben – geared up for the onslaught of the Rails community

We had a great time at RailsConf this year. Ben’s presentation went well and got a great response from the crowd that attended. I had a chance to chat with some people (both from our local group and elsewhere) about the content of the presentation, and the responses were pretty consistent.

For the developers who had faced the same issue of building a dynamic site with a large amount of static content, the solution met their needs. I ran into a lot of people who had just been creating a single controller (e.g. GeneralController) to handle all the static content for their sites. This approach works for a while, but as the static content grows – which was the case when we built the ACVA site – things quickly become cumbersome.

I also talked with others who were misled by the title and wondered “why would you use Rails to build a static site?” The answer to that is… “you don’t.” If you’re building a truly static site, Apache, Lighttpd, or Tux are your friends and will serve up static files faster than Rails can. In fact, Ben’s solution relies on a front-end web server to serve up the cached pages generated from the static site framework.

So for those that missed out, here’s what the framework allows you to do (implemented as a plugin-app):

• Upload or create content files – In typical CMS CRUD fashion you can add content directly to the ‘pages’ table through a web front-end either using a textarea or a standard file upload control. From there, the content is then immediately available in your application.
• Generate site maps – Because the page content is stored in the database and the Page model uses acts_as_tree, we’re able to traverse from the root and generate a site map for display. This design decision, along with providing modification timestamps, also helps when you need to generate the XML for use with Google Webmaster Tools and other search engines that use this site map standard.
• Provide customized page-specific variables – Again, because of acts_as_tree in the Page model, we can provide a hierarchical inheritance model for page-specific variables. Setting a variable at the parent level makes it available to all the children with the ability for each child to override the parent’s default setting.
• Search for terms in your “static” content – The framework plays well with your current search solution. If you’re using Ferret, Solr, or Hyper Estraier you can search both your existing CRUDified content and your new static content.

If you want to test it out, you can download the plugin and view the slides from the Viget site. In the near future, we’ll be pulling the code into a public SVN repository – stay tuned.

Our clients spend an awful lot of time obsessing over the homepages of their sites. And there is some merit to that; typically, the homepage is one of the most visited pages of a Web site. But in the age of search, any page of your Web site can act as a homepage.

What to do? Put the same amount of thought into secondary pages. As you carefully craft copy and calls to action on the homepage, ensure that each page of your site is designed to convert your visitors by influencing them to take actions you deem important.

Need more convincing? Well, if you have any analytics on your site, it will likely show an interesting long tail trend. The number of people who visit your secondary pages probably exceeds the total visits of your homepage. The impact is even greater if you are building a knowledge-based site like Squidoo or Wikipedia.

The Web has changed. People no longer come in solely the front door of your site - some visitors get dropped straight into your living room, and you need to be prepared to serve them equally.