Monthly Archives: January 2010

Designing a Course Details Page

Have been looking at improving some of the previous ideas I’ve had for our course details pages. They are a crucial part of our site, so I wanted to have a good think about the way they should work. An essential part of design is clarity about the different priorities of the information you have to convey. If everything you have to say is of equal importance then that could be reflected in the visual representation. However, this rarely happens, and there is usually a definite hierarchy from the most important information down. An often tricky set of decisions when organising a home page, the structure of a course information page should be a little more obvious. This set of priorities then informs the semantic structure of the page.

To help me arrive at a sensible page structure, I had a ponder about what someone might want from a course detail page. This page should collect as much relevant info about the course and secondly, supplemental info that might help someone make a decision. Marketing have provided the broad headings that most of the information comes under, and these are pretty common across other University’s course pages.(give examples) So, a user would click through to the course page about English, and see a summary that helps them to decide if they are on the right page. If so, then the other headings are designed to give them more detailed info that would help them to decide, whilst hopefully making them interested about the possibility of studying that course.

Ideally, once someone has read enough of the exciting words about the course, then they would want to act upon what they’ve just read. To enable that the sidebar has a set of links with a variety of designs, to attract attention and emphasise that there are things the user can do. There’s a link to apply online, to book and open day, to contact the university. Hopefully with more similar tailored tools to follow. Currently styled with a predominantly blue theme I envisage there being versions based on the faculty color themes.

Further down the page there boxes with related info. Based on the presumption that all the previous info didn’t quite match what they were looking for, these are provided as jumping off points. There are links to related courses, Links to different parts of the site to Fees, Accommodation and a Parent focused site.

It’s best to keep this info all together as much as possible, rather than spread it across multiple pages and the attendant difficulty of managing links and urls. A consequence of that is that the page would potentially be very long. I don’t mind long pages myself, but it’s a good choice for the user to give them the option about which sections are relevant to them. Putting them in an accordion interface puts that control back in the hands of the user.

As per “Paul Boag’s article”: I think it’s really important that we try to create pages with very clear ideas of why they exist and what we would like them to achieve. If we can manage that then that clarity will benefit the people who use the site.

I tried a more rigid representation of this hierarchy, with the ‘Information’, ‘Links’, And ‘Tools’ block following one another in a single column. As you can see, it’s probably not a good idea to enforce such a rigid hierarchy.

Annoted design idea

I looked placing the tools on the left,but felt that they then became too prominent, since the info block is designed to be read first. It’s common practice to have in-page navigation on the left, and ordinarily I can see that it’s a convenient place to put things to make it easy to move around. However, since these pages are designed to be an end result of a search, it would be counter productive to then give links to take a user away the same visual priority as the main information

Annotated Design Idea

In the end I’ve settled on a right aligned tools block, with the idea that it’s easily placed for jumping off, but doesn’t demand too much attention. The task priority on this page would then be

  • Read
  • Act
  • Continue Searching

Annotated Design

My little bundler of Joy

Bit of Background

One of the new bits of technology coming into Rails 3.0 is the all singing and dancing Gem Bundler . If you’ve ever found yourself in config.gem hell, or have pushed a perfectly fine project from development to production and it’s all gone kaput due to gem problems, than this is the medicine that you need. Here’s the blurb

Bundler is a tool that manages gem dependencies for your ruby application. It takes a gem manifest file and is able to fetch, download, and install the gems and all child dependencies specified in this manifest. It can manage any update to the gem manifest file and update the bundled gems accordingly. It also lets you run any ruby code in context of the bundled gem environment.

We’re not running Rail 3.0 yet, but thats no reason not to start using bundler.

Let’s install it, I’ve settled on version 0.7.1 as I was having odd problems with any of the newer versions.

sudo gem install bundler -v 0.7.1

Next step is to create a file called Gemfile in your applications root directory, and then subsequently fill it with what gems you need, and also in that environments you need them. Here’s the one I’m using.

Sample Gemfile

Now add these lines to your .gitignore file, this will make deploys easier and faster


Now it’s time to start a bundling. From inside your application run

gem bundle

That will now do all it’s magical stuff for you, creating the bin executables and the necessary files and folder in the vendor/bundler_gems folder.

Will it work yet? Not quite 🙁

To get it working with rails 2.3.4 I had to do the following things.

1. Create a file called config/preinitializer.rb with this code in

require "#{File.dirname(__FILE__)}/../vendor/bundler_gems/environment"

2. Add the following line to all environment files, ie, config/environments/*.rb

Bundler.require_env RAILS_ENV

Now when I start my app using script/server, or nginx and passenger it all works as it should. I even removed all my local gems just to check. (stupid idea as not all my rails projects are bundled yet :-))

Deploying the medicine

I’ve unashamedly knicked the deploy stuff from numerous people, I love you all, even though I can’t remember your names.

Capistrano Deploy Script

Watch out for….

It might sound obvious but some gems can’t be handled in this way. Have a good think about that prior to using bundler, one for us was passenger. I had a hell of a time trying to workout how to use it with bundler, than I got some sane advice to just install passenger as a module of nginx, problem gone. The unicorn is stalking me at the moment though, so we may have a passenger who wants to get off shortly.

We were using REE in production, in my experience REE and bundler didn’t get on, so I had to remove all REE and install the ruby that comes down the pipe with aptitude, then rebuild nginx with passenger module after doing that, it all worked ok then.

I now deploy from the application like so

./bin/cap staging/production deploy

That way I know what version of capistrano I’m using per app

Don’t delete all your local gems until all your projects are bundled, and even then be careful.

If you have rake tasks that are being run by cronjobs, make sure that the rake you are accessing is present.
RAILS_ENV=production rake some:jobname will not work from a cron job now, as rake is not available like that any more. You’ll need to edit it to point at the rake in your project bin.

RAILS_ENV=production /path/to/project/bin/rake some:jobname

Or add the bin folder in your project path to your $PATH, that might be a better solution.

Happy bundling everyone.

Our Current Technology

ubuntu 8.04, rails 2.3.4, ruby 1.8.6, nginx 0.7.64 (with passenger 2.2.8 installed as a module)

People who’ve helped immeasurably

#carlhuda on freenode