Omniboard 1.0

Over the past couple of weeks I’ve been chipping away at bugs, feature requests,1 and other miscellanea for what is officially (as much as that means anything) Omniboard V1.0.

What’s Omniboard?

Omniboard is a small ruby library that does one thing: it turns your normal OmniFocus library into a Kanban-style board of projects, each sorted according to the criteria you provide. It does this by reading the database files produced by OmniFocus, which means that you do not need a Pro account (or even to have OmniFocus running) in order to run Omniboard. That’s kinda cool - you can find out more about this on the project page.

What do I need to run Omniboard?

Right now, a little bit of stuff! Due to its dependencies, Omniboard needs you to have OS X’s developer tools installed, which a lot of people don’t have. I’m hoping that will change in the near future.

In addition, Omniboard can only currently read old-style (i.e. pre-2.6) databases. If you’ve upgraded your database to Omni Group’s fancy new encrypted databases, you might have to wait for a bit while I get that sorted.

OK, what’s new?

So many things! Let’s make a list of them, shall we?

Groups are objects now

Omniboard will helpfully arrange your projects into groups based on criteria that you select. In the pre-1.0 days, these groups were identified by a simple string, which is perfectly fine for some applications. But what if you want to group things by their container, and have these containers sort themselves by order? Or if you group by due date, and are sick of the string sort algorithm slotting “10 days left” between “1 day left” and “2 days left”?

So a group’s identifier can now be anything - they can remain strings if you want, or you can use any object you like to group things. As before, you specify a project’s group with a block inside the column configuration:

1
2
3
Omniboard::Column.new "Sample column" do
  group_by{ |project| project.container }
end

Note that a project must be given a non-nil group, for reasons. If your group_by block ever returns nil, Omniboard will give you errors. So you’d actually write the above example as follows:

1
2
3
Omniboard::Column.new "Sample column" do
  group_by{ |project| project.container || "" }
end

By default, Omniboard will give your groups names by running to_s on the group objects. If you want to provide your own naming scheme, simply use the group_name block:

1
2
3
4
5
6
Omniboard::Column.new "Due soon" do
  group_by{ |p| p.due.to_date - Date.today }
  sort_groups{ |i| i }

  group_name{ |i| "Due in " + (i == 1 ? "1 day" : "#{i} days") }
end

You can custom-colour your groups

By default, groups are given a range of colours throughout the spectrum to make them stand out. But if you always want one group to be bright red or blue or green or something, you can do that now!

1
2
3
Omniboard::Column.config do
  colour_group(50){ |i| i == 0 }
end

The colour_group method takes two arguments: first, a numerical value which represents the hue you want the group to be, and a block which is evaluated by passing the group’s identifier and receiving true or false. So in this example, if the identifier is equal to 0, the group’s colour is set to 50.

Note that Omniboard is not yet smart enough to auto-colour around these custom colours: you may find that you have two similar colours popping up on your board.

You can provide a link to refresh your board

If you set the global config option refresh_link, you’ll find a little “refresh” button in the title bar of your board. Hitting that button will call the URL - useful if you have a local sinatra setup and can call a link to trigger a refresh of the board.2

You can automatically hide dimmed projects

Some people don’t want to see their “dimmed” projects (normally projects that have been deferred, or which have no tasks left). By setting hide_dimmed on a column to true, these will automatically be hidden from view. If you have hide_dimmed set, you probably want to set filter_button as well - this gives you a button to hide/show dimmed projects.

Column totals are back

Once again, you can see at a glance how many projects exist in each column. Any column with the display_project_counts property set will show a project count. Depending on what you set this to, you’ll see a different total:

1
2
3
4
5
Omniboard::Column.new "Sample column" do
  display_project_counts :all     # Will give a count of all projects in the column
  display_project_counts :active  # Will only count "active", i.e. non-dimmed, projects
  display_project_counts :marked  # Will only count marked projects
end

In addition, you can have your project counts go red if you end up with more than a certain number. Set project_limit inside column config to get this.

What next?

I’m going to leave Omniboard be for a bit now. It’s not perfect, but it’s pretty damn good, and the foundations need a bit of work. In the next few months I hope to eke out some spare time and work on rubyfocus, the interface between ruby and OmniFocus. In particular, I want to wean the library off of nokogiri, which is an excellent library but makes installation a bit of a pain sometimes, and also build in support for Omni Group’s new encrypted database system.

Have any comments, questions, or requests? Drop them in the comments, or - better still - open an issue on Github.


  1. If I file them, they’re still feature requests, right? 

  2. If you know your way around Sinatra, this shouldn’t be too hard to implement. If not - well, that’s a post for another day.