CiviCRM Community Forums (archive)

While a dump of the code (even client specific code) would be helpful for this student and mentors to start looking at, understanding your approach would also really valuable. 

Would you be willing to talk to the student about your experience with Bootstrap and CiviCRM?

As I've said before, my personal interest in seeing this project happen is to reduce the CiviCRM specific knowledge needed to manage the look and feel of the CiviCRM UI elements and forms regardless of which CMS CiviCRM is paired with.

I've done a number of sessions at Drupal camps trying to get Drupal developers and themers to stop hating on CiviCRM just because it's different.  I've had to deal with themers who hate working with CiviCRM because the Smarty templates look so different that the PHPTemplates from Drupal 6 and 7.  These same themers will tell you they love Twig even though they can't tell the difference between Twig and Smarty markup.  While this "four feet good, two feet bad" mentality is maddening, I chalk it up to there being too much of difference between what the themer knows vs. what they are being asked do.  The result is often a quote from implementing a donation form that requires adding Ubercart or Commerce that costs less than simply customizing the CiviCRM form.

I think this is one of the reasons why the CiviCRM Webform Integration module is so popular.  Despite the complexity that module adds, it make CiviCRM forms look like something a Drupal themer is familiar with.

IMHO, giving designers/developers/themers something familiar to build on should reduce the cost of integrating CiviCRM with any CMS and make it a more attractive option for shops that don't specialize in CiviCRM... but I could be wrong. 

Hi All:

I am Chad and a Joomla contributor and I also run our GSoC program for Joomla.

I saw that you had been accepted for GSoC and you are doing a bootstrap project. Congrats! I thought I would take some time to make some recommendations based on the fact our project has both done this, and we've figured out what worked well and what did not work well for this. Now keep in mind our project is a bit different. Joomla has a need to be very theme-able but I think that is less the case with CiviCRM.

Lessons Learned:
Front End Devs don't like non-semantic CSS / Markup
We discovered that front end devs don't really care for Bootstrap markup. Now we did BS2, I suspect you'll use 3 so your markup will automatically be much better. But overall I think the conclusion from the markup snobs (said lovingly!) is that they would prefer a unified set of semantic classes that are extended by bootstrap / another UI framework via LESS or SCSS.

Don't glue too tightly
Joomla developed a very tightly coupled implementation with our Joomla User Interface Libraries. We discovered that doing this made them hard to change and also made it hard for us to update from Bootstrap 2 to V3. So watch out for this.

Make it possible for people to NOT use bootstrap
One of the biggest complaints we've seen is that some people plain don't want bootstrap. For whatever reason. So I would encourage you to think about ways to ensure things still function and work without having bootstrap be included. It should be optional. This is where things like only extended core markup classes comes into play. Also when you're talking about things integration like CiviCRM and Joomla, make the javascript includes optional or configurable. If there's an integration and i already have jQuery, I won't need CiviCRM to include it again.

Think Long Term
I would encourage you to think beyond bootstrap and making CiviCRM pretty, think about the next thing that comes along, worry about solid markup, good design, usability and UX first. Let Bootstrap be the secret sauce you put on later.

Resources:
Mega huge discussion on bootstrap & joomla: https://groups.google.com/forum/#!topic/joomla-dev-cms/7ommekXwB-w%5B51-75-false%5D
Really tightly coupled HTML library to BS2 components (aka: how not to do it): https://github.com/joomla/joomla-cms/blob/staging/libraries/cms/html/bootstrap.php
Make sure you can scale with tons of elements: https://groups.google.com/forum/#!topic/joomla-dev-cms/HrXO83ksK20
Why you shouldn't tightly couple to Bootstrap: https://groups.google.com/forum/#!searchin/joomla-dev-cms/bootstrap/joomla-dev-cms/rNhVt65OEWA/Y8OLiz3vZm8J
Problems with updating from V2 to V3: https://groups.google.com/forum/#!searchin/joomla-dev-cms/bootstrap/joomla-dev-cms/7ommekXwB-w/VDcqQ_-8nw8J

Final thoughts:
I don't want to come across as bashing bootstrap. i actually love it! I have built tons of Joomla sites with it and it's fast and efficient. But since I care about GSoC stuff and I saw you were going to be going down this road, I thought I would share some of our experiences as a large project who adopted it and found where the bodies can be buried. I wish your project the best of luck and the most success!

Best wishes
Chad

Hi

I have started work on the GSoC project and wanted feedback/suggestions before I zero in on the components and implementation of the project. Major questions that come to me are:

1. Optional vs Standardized Bootstrap: Will Bootstrap be an additional theme that the user can turn on/off will it be the DEFAULT user interface of CiviCRM going forward? IF Bootstrap is made the default UI, development will have to continue as Bootstrap evolves. Personally, I feel the current UI undermines the potentiality of CiviCRM. It is largely inconsistent and buggy. Even assuming Civi UI wont be updated to future versions of Bootstrap, isnt Bootstrap a semantically and aesthetically better UI to stay with?

2. CSS Structure: Civi currently has a core taxonomy with civicrm.css file and additional CMS specific files as required. Going forward, how do we reconcile the present structure with that of bootstrap? My proposal is to discard civicrm.css and develop from scratch the following structure - bootstrap.css + civicrm.css + wp/joomla/drupal.css

bootstrap.css will be the core file that the user can customize as required. Bootstrap website already offers a host of variables including colors, typography etc. for customization (http://getbootstrap.com/customize/) This opens up infinite possibilities for Civi customization also. For ANY color scheme of a website on ANY CMS, the user just has to key in the colors and we have a matching "civi theme" that blends right in.

civicrm.css will be a canges in bootstrap code for CiviCRM. This file is included so as to not disturb the core bootstrap.css

wp/joomla/drupal.css will have CMS specific changes

However, some questions still stand in this approach:
   1. This will lead to huge changes in the code base wrt. template files and the CSS tags
   2. I am not sure if the project time period will be enough to take up this humungous    task. Should the scope of the project be limited to user facing pages?

3. To get up to speed, it has been suggested that I take up a specific component/page in the first week of GSoC period and come up with a process to bootstrap it. I wanted to begin with the most visible part of CiviCRM and chose Donation page. Any other suggestions/ challenges that I might face?

4. LESS vs SASS?

Any inputs on these issues will be greatly appreciated. Thanks!

A Profile form might be the easiest to start with, as it is the simplest. The donation and event pages have a lot of calculation and a number of optional parts that aren't found in the Profile form.

The biggest obstacle I've been seeing is dealing with Quickform, as some alternative will need to be used in order to get clean HTML to style. I've been dealing with this currently by using the Profile API to provide the form metadata and completely rewrite the forms from that point up, decoupling them from the rest of the logic.

I'm hoping some of the additions that are being worked on to the Profile API will help make that process easier for you.

I can tell you now that none of the HTML necessary for making Bootstrap work in HTML forms is in the Smarty templates, because almost none of the form elements themselves exist in the templates. Writing new renderers will probably get the job done, but ultimately rendering classes need to be as easily extended or overridable as a template.

1. Which page do I start with? I began with the Contribution Page but it seems to have many includes and is complex. Is there a different component that is relatively straightforward and can help me get up to speed? 

Might be easier to isolate a part of most of the publ, ic facing forms and start with the profile only ,eg:
http://drupal.sandbox.civicrm.org/civicrm/profile/create?gid=1&reset=1

2. Which CRM do I develop with? I have been working with Joomla! as I am more familiar and I was thinking since I am modifying core files, it does not make a difference. Does Drupal/WP offer any advantage?

I don't think it does either way, but most of the dev seems to test first on drupal as the default CMS

3. One of the options discussed about CSS structure was retaining both classes. W have semantic classes that already exist and add layout level classes as another layer. In this case, we would be trimming down the existing civicrm file to bare minimum and adding layouts through bootstrap. Any ideas?

Assuming you aren't going to manage to change all civicrm generated pages, we will still need the complete civicrm.css for these.

It might make sense to keep the existing css and create a new one for the bootstraped pages and when you load the page, you decide which one to include.

Check out how the js is handled, there is already a test if the page is public or nor and based on that load all our libraries or just the ones used in the front office.

You might do something similar

4. There was another comment on my blog post and it made some valuable suggestions - Using less to include bootstrap & civicrm css files to generate a common file and another about the table centric layout of CiviCRM. I too have observed CiviCRM is based on layout tables. But these tables are in Joomla specific parts of the code. Is this true for other CMSes too? In that case, I will have to completely abandon tables and switch to a div based approach. This may be huge. Your suggestions?

Not sure I follow why you are saying these tables are in Joomla only, but have limited knowledge as what's going on with J!

Most of the "simple" forms are div based, I would focus on them first.

To work, you will need to change the way the html is generated by quickform. I don't know if you have scheduled to work on it, but it would be good you see how to create a custom output (or whatever the solution on quickform) to have full control on the generated html and put the div and stuff bootstrap needs.

Past week's Activity:

- Read documentation of Quickform 2
- Understand about custom renderers and callbacks

This week's agenda:

- Write prototype custom Quickform 2 renderer for bootstrap

The current renderers of quickform2 do not have native support for certain types of elemtents like button groups,  text box groups etc.  This has to be addressed by creating separate standalone classes that consisting of multiple elements.