Should you use Fusion?

Advantages

As a developer deciding which theming approach to use on a new Drupal project, Fusion has a number of strengths to consider:

  • Modular, reusable styling – Fusion Accelerator enforces a modular and more maintainable approach to CSS, which can then be applied across different types of site content
  • Fast site building – rapid prototype a client site without custom theming and get to the meaty parts of the project faster
  • Greater autonomy for themers and developers – Fusion styles can be built and applied later without needing to target specific block or View IDs that have to be built first, so there’s less overhead between team members
  • Common patterns are already coded – no need to reinvent the wheel for types of menus, field floating, table styles, etc. are available already in Fusion, and even more design patterns shared through the community
  • Support community – active support community for getting focused help
  • Quickly make on the fly changes – changed your mind about how many blocks go in the header? Make changes quickly through the UI
  • Less hassle for client maintenance – when the client wants a second menu in the sidebar or another view styled just like that one on the home page, you (or the client) can re-apply a style months later without pulling up code
  • Easily create custom layouts/grids – Fusion makes grids easy, with all the math taken care of behind the scenes in template.php so you can define any custom columns, widths, and gutters easily in a couple dozen lines of CSS
  • Out of the box browser/standards compliance – we handle these issues so you can focus on the styling
  • Drupal-savvy foundation – support for popular modules and common Drupal-sense applied liberally
  • Consistent, reusable code across projects – adopting a consistent approach means that managing multiple projects and developers
  • Commercially supported – with an established company behind Fusion, commercial support is available when needed from a team of professionals

Projects that are ideal for Fusion have requirements that fit with these advantages.

Permalink

Disadvantages

While we’re a bit biased in our love for Fusion, we recognize that there are some downsides to this approach, and Fusion is not ideal for every project. Here are some things to watch out for:

  • Verbose markup – not as much as some other themes and this generalized code is what powers much of its flexibility, but Fusion is by no means a lean markup solution – if you can’t stand divs unnecessary for your particular theme, Fusion isn’t for you try out the Fusion Starter Lite theme
  • Requires a grid-friendly design or some flexibility – this is more about grids in general than Fusion, but you might want to read up on the pros and cons of going with a grid system
  • Layout configuration stored in the database – Skinr configuration can be imported/exported (like Views), but you’ll be setting up a lot of your site’s layout and look and feel with values stored in the database which can add steps to deployment in a dev/live site environment. There has been some work done on Ctools/Features integration though.
  • Adds to complexity of Drupal’s UI – the blocks admin doesn’t get a lot of love as it is, and Fusion (through Skinr) adds a lot more options to that interface, which can be overwhelming
  • Requires adoption of a new approach – as with any new system, you’ll need to spend some time getting used to The Fusion Way
Permalink

Known limitations

There are some limitations with Fusion, or subtheming in Drupal in general. Most of these are things actively being worked on.

  • No sub-subtheming – patch for D6 is in Drupal 6.20
  • Not fully layout-integrated with Panels – you can use Panels’ layouts and Fusion’s block designs in Panels, but not Fusion’s layout/positioning options
  • Can’t apply styles to block displays through Views’ interface – the style selection options will show up, but in order to avoid doubling of styles (at the block and view level), they won’t actually apply. Workaround: apply the style to the block/pane instead of the view (more details)
  • No page-level (planned feature added in Skinr 2.x!) or per-node styles (in discussion)
  • Can’t have different sidebar widths/positions per section
  • No live previews of styles, just image screenshots added in Skinr 2.x
  • Can’t easily reuse styles across themes or from a module added in Skinr 2.x
Permalink