This document proposes to use Twitter Bootstrap as a base framework for RapidSMS core and contrib templates.

Twitter Bootstrap provides a lot of useful base functionality (layouts, grids, responsive, buttons, icons, etc.). Adopting it in RapidSMS core will provide a better foundation for building apps without needing to write a lot of custom CSS. We can spend more time writing apps and less time writing HTML/CSS. This will also help set a common theme across apps.

• Update all core/contrib templates to use base bootstrap css classes
• Move all core templates under templates/rapidsms to preserve namespace
• Create a base template that uses RapidSMS colors and look and feel
• Remove RAPIDSMS_TABS and use an inclusion template (e.g. "rapidsms/_nav_bar.html") to allow per-project customization of navigation items. Supply default _nav_bar.html template in rapidsms-project-template.
• Remove djtables, since it's not actively maintained anymore. Replace with normal HTML markup.
• Provide compiled CSS by default.

• Should djtables be replaced with another library?
  • @daaray: I'd suggest looking at django-tables2 [1] as a replacement for djtables. It is actively maintained, and is more flexible in terms of extending and customizing the table and associated templates.
• Twitter Bootstrap uses LESS to simplify CSS management. Should we use LESS in RapidSMS to allow easier extension of styles?
  • Cory: [Also bundle CSS if LESS is used]. Makes it easier for many developers who never need to touch CSS, and you can always have a build target that verifies the output is what you'd get from LESS if you're concerned about the two getting out of sync.
• Is now an appropriate time to add a "skinnable" feature to the rapidsms contrib UIs, such that a different 'layout' template can be specified in settings.py?
  • Nic: you should be able to overload the base template no problem using Django's standard template hierarchy.
• Do we want Bootstrap bundled within core or should that be a project-level aspect (such as in the rapidsms-project-template)? That is, leave the decision of if and how to use bootstrap to the project owner. Is there a downside to depending on bootstrap? Will it make it harder to incorporate RapidSMS into an existing project?
  • Cory: I don't have a strong opinion on these, although my gut would be that we should just put the dependency in rather than trying to manage it in a more flexible way. We've attempted to do this in some of our projects and inevitably someone introduces functionality that depends on bootstrap and then all the complex decoupling ends up being for nothing. Also, if someone wants to incorporate rapidsms into an existing project, they'd likely want to re-roll most of the UI anyway to integrate with the existing site (this is a guess as it's not something I've ever done).