I'm on my way back to San Francisco after an incredibly stimulating three weeks of collaborating (and co-habitating) with fellow "Civi's". There were lots of very long days (12 - 15 hours) of brainstorming , designing, hammering out code... intermingled with cooking and eating some lovely meals together, a few cool adventures in the natural beauty of New Zealand, and some excellent meetups with members of the community "down-under".
This was our fourth "international" team gathering. In planning for it we tried to build on the things that worked best in our prior meetups - and learn from things that didn't work as well. We decided to focus tightly on a few key goals / projects - and worked hard at staying on task. (This meant resisting the gravitational pulls of email, forums, team members not with us etc.) We set a schedule for moving through our projects and decided up front that it was ok to move on to the next task without completing 100% of the current one.
The plan was to make progress in these areas:
- Usability - solving some of the issues which folks have reported on the forums and in meetups
- Componentization - separating components (e.g. CiviContribute, CiviEvent, etc.) from the core codebase
- Automated Testing - automating both unit and user experience (browser-driven) testing
- Complex Permissioning - improving access control options for hierarchical organizations
- CiviEvent Enhancements - discounting and multi-participant registration
... and the cool thing is that we achieved quite a bit in each area.
One of the big wins in the usability arena was figuring out a way to seamlessly inject sets of fields into a form without reloading the page. Over the last 6+ months, the most consistently reported "tooth grinding annoyance" has been the page reloads that happen when you're filling in many Civi forms. The offline Event Registration form is probably the worst since it reloads TWICE - once when you pick the event and again when you pick the participant role. With the new ajax-based approach - the additional (or different) fields just appear in the form without affecting any entered values. See Kurund's recent blog post for more details.
The days we spent on test automation were also super rewarding. The extension to Simpletest developed by some of the core Drupal developers turned out to be pretty easy to install and we were cranking out some simple browser tests in the first afternoon. We wrote tests that logged in, clicked links, and even created a simple contact record - and could then test the database state to make sure it matched. We committed to using test-writing as a time to evaluate and re-factor the code being tested - and clean out redundant and unused methods in our business objects. Check out Michal's recent blog for more on this.
You can preview some of the things we worked on at the Hackathon by logging in to our newly re-configured 2.1 Development Sandbox. You can...
We'll continue to blog on specific features to try out on the sandbox in the coming weeks. Stay tuned.
- Try the improved Quick Search widget (left column block) which now takes you directly to viewing a contact if there's an exact match. (Personally I find this to be a nice "smoothing" of my typical work-flows...)
- Try the "ajaxified" offline Event Registration form - minus the annoying page reloads.
- Check out a sample textarea field with the admin-configurable WYSIWYG editor turned on (currently set to FCKEditor). Check out the Event Description field from Configure Event.