Hi,
The code sprint in London has finished yesterday. It's always a pleasure to see old civi friends and meet new ones. Thanks to Michael and Katy to have organized it. Time for a quick update of what I've been working on with the most obscure title I could find. My focus has been on usuability to make civicrm easier and faster to use.
To make our crm more user friendly, we need to make the pages more "application like", where you can add, edit remove and reorder from the same page without having to switch and go to more pages with forms to fill and save. And load. And wait. And save, and load and wait more...
For instance -and that will be a make it happen that we launch next week to improve- creating a survey today means you have to go to visit a different page to create the survey, the profile, for each field you add in the profile, for each custom field you need to create. And things like re-ordering and fixing the help fields in the profile involve visiting half a dozen pages too. Our goal is to make (most of) these steps disapear and do all that directly from the survey page.
Ajax API
The feature that makes all that possible is the API v3, where you can create, update or get a list of pretty much anything stored in civicrm in a single line of javascript, without having to change page.
This mostly exists but will need some improvements (custom fields and profile fields need some love for instance).
In place Editing
a jquery plugin is cooking that allows to edit any text (right now regular strings but could be extended to deal with dropdown lists or textarea) and save it without having to leave the page and go to a form by adding a single javascript line " $(".crm-editable").crmEditable()".
So say that you have the phone of a contact on the list of participants, you can click on it, change it and save without having to leave the list.
To make it work is simply a matter of adding two classes (to say it's editable and what's the name of the field in the api) on the text, and two classes and one id on the "parent entity" (eg. the contact) to say it's the object the field belong to, its type (contact, activity, event...) and its id. The plugin then knows how to call the ajax api in the background and update the field on the server.
I'll post a longer article about it when it's in a sharable state.
Loading an html fragment
They are plenty of pages where we request the server to give extra bits of more html and add it to the page. For instance contact summaries overlays or "popup" to add a contact or when you click on the custom fields blocs.
Being able to add extra parts on a page only when the user needs them means that pages are easier to generate, smaller and faster to load. To go back to the survey example we have at least 4 different parts that we will load only when the user needs it (to add new fields for instance) and that's something we do quite often on custom developements too.
We are introducing a new "magic url" civicrm/inline/{entity}/{name} that can pick up the right template and process it without having to write a single php line. For instance visiting "civicrm/inline/profile/summary" that will automatically take the template into templates/CRM/Profile/Page/inline/summary.tpl
It is expected that these bits of page use {crmAPI} to fetch and create the needed html. This will look as well in the custom template folders, so it will be easier to customise civi and add more custom features too.
I'm going to document it when we are happy with the syntax and how it works
Mustache and client templating
Beside being able to load extra page fragments easily, I have experimented with an even faster and easier to implement solution: instead of having to create an extra smarty template that generates the needed html, we use the ajax api to get the data (in json) and use mustache to create the layout directly on the client side in the page.
For instance you can get the list of all the fields in a profile and display them with a nice layout so you can edit the labels and fields or reorder, without having to write a single line of code nor smarty template: you fetch the list using the existing ajax api and create the list of fields to display directly in the browser.
All that put together fits nicely and makes a very exciting framework that will allow huge usability improvements without having to code a lot. All that is still under construction, if you have any suggestion to improve, now is the right time.
If you think you can contribute financially to improve the surveys/petition and profile management at large, please leave a comment or come back next week we are looking for help to make it happen.
X+
