This week, I began work on my Google Summer of code 2014 project “Bootstrap and CiviCRM”. The project was proposed and selected to address the following goals:
1. Improve the user interface of CiviCRM
2. Provide a consistent and scalable UI framework for developers to extend/customize CiviCRM
3. Make CiviCRM compatible with mobile devices
Bootstrap was chosen as the framework of choice after much debate and discussion with the community. We also understand the enormous scope of the project and its long term implications in terms of changes to the codebase and existing extensions. We understand that GSoC coding period is too small to bring about changes to all components of CiviCRM. Instead, we have decided to focus on creating a solid process and documentation that can be taken forward by the community. In this context, after brainstorming with my mentors, we came up with a few possibilities on how to take this forward.
Some important questions we face are:
Which components do we take up during GSoC period?
There have been suggestions on taking up Donations while some have warned about this being too complex to begin with.
How do we integrate/replace the bootstrap CSS with existing Civi CSS?
Currently, Civi has a specific CSS structure eg. civicrm_entityname-label. Bootstrap however will have a different neutral structure without any references to Civi. If we change the bootstrap nomenclature, the whole objective is lost. We will no longer be able to customize it on the go. We came with the following alternatives:
1. Compile civicrm classes using sass/less includes/extends
2. Remove civicrm classes and replace for bootstrap - there is a time constraint
3. Put the appropriate bootstrap classes/id to the templates for each of the components we will be addressing (a lot of templates), leaving existing civicrm classes as is.
One possible way forward that occurred to us is - At first try, we do it by replacing all the classes that are affected. I am doing this by renaming civicrm.css as custom.css and adding bootstrap.css file. This way, whatever pages are bootstrapped pull their styles from bootstrap.css file and the rest from civicrm.css Whatever pages we successfully transition will be of bootstrap and rest will be in custom css file and can be taken up later. By the end of it, custom.css will become obsolete.
I am not sure what road blocks we will face. What do you think? Any feedback/suggestion/directions from the community on making a roadmap for this process will be extremely valuable.
Comments
Hi,
Why wouldn't you keep both the "semantic" civi classes, and add the bootstrap "layout" classes? They serve different goals and the semantic ones are used to target specific fields when you use javascript to do customisations. They are used as well in the core, eg for the edit in place that rely on crmf-xxx or crm-entity classes to be able to work its magic automatically
3 makes sense to me, but I might have been missing the reason you wanted to remove them in the first place
I agree that not all the civi classes can be removed, but any class that provides any change or position, decoration, or visibility will need to be overriden by new versions that modify the Bootstrap core styles. Rather than renaming civicrm.css, creating a civibootstrap.css that acts as an override to the core css file can be compiled from civicrm.less, with civicrm.less @including both the core civicrm.css and core bootstrap.css, then providing additions, overrides, and extensions in that file, or as additional @includes in that file.
The bigger challenge is in reordering the html generated by Civi. Using Bootstrap requires a combination of classes and specific semantic HTML. In order for there to be any use from implementing Bootstrap, all HTML will need to be refactored to the semantic structure that Bootstrap requires, which is not currently reflected in any of the existing Quickform rendering templates. This means that unless overrides for every bit of code that outputs HTML can be created to exist in parallel to the existing renderers, then little to none of the consistent and responsive functionality of Bootstrap can be leveraged. In QF, this mostly means changing the order and nesting of labels and inputs. Across the board, this mean the almost complete abandonment of tables-as-layout in place of the responsive div-based grid.
Getting on mobile devices is critical to being able to reach all the new non-profits coming online in the developing world. At NDI we'll be super interested to follow the project, and perhaps we can find ways to further the good work. We work with a lot of groups who are only on Android, so if we can be of use for testing let me know! cdoten @ ndi.org
Hi
Thank you for reaching out. We are definitely looking for extensive feedback on this project. I will get in touch with you once we have something substantial to test. We are just getting started right now.
Thanks!
I would say add the bootstrap classes to the elements and leave the civicrm ones in places. They describe civicrm code and maybe they get removed in the future.... But time will tell...
As to what component you can start with. I would say civi case as this gets a redesign in the short future. So rather that civicase gets a redesign to the civi standards of today (and we have to redesign it again to bootstrap). We can combine the energy spent on bootstrap and civicase. But this requires that the rest of civicrm moves to bootstrap as well. Otherwise civicase is still odd in the UI.
Hi, having relatively little knowledge of bootstrap it would be great to see some code showing the difference - not necessarily CiviCRM code - but possibly the html generated by a civicrm page with some explanation of what would need to change. I say that both with regards the classes & also the html structure concerns Jeremy raises.
I think one of the jobs of this bootstrap project is to educate the CiviCRM community
The import routines already seem to need work. That would seem to change less of the base code, yet touch many aspects of CiviCRM as a whole. Having not done much coding recently, I'm probably not thinking through every aspect, but it seems like this "out of the way corner" would be a great place to cut your teeth. It would also significantly decrease the entry barrier for other organizations looking to begin using CiviCRM. Killing two birds with one stone always looks more appealing.
I agree with you that the import would need some love, but the layout is a tiny issue in that case, and it's, obviously, screens that are never going to be seen by the end users, so I doubt that styling them more easily is bringing a lot of benefits of migrating to bootstrap.
Yes, that layout is a tiny issue that most won't see. Exactly the reason to start with that piece. Start with something small that doesn't break other things so that you can learn the effects .
I suggest to keep civicrm styles and add bootstrap css. This would keep both opportunities, civicrm with or without bootstrap.