Easy core forms tweaks

[nicolas]

Probably the single most request from my customers is to tweak the core screens / forms.

Like: Can we get rid of the data of birth field on the contact screen? Can I have the address block way up top when creating a new contact? Can I have the job title listed on the relationships tab? Can I add the phone number on the left-side quick create? Etc, etc.

So, can there be an easy way to tweak these core screens/forms/lists/etc? At minimum an XML description of the screen that we can override, ideally a graphical form builder that would allow us to rearrange the screen/form graphically with drag/drop, or anything else.

See around 1:00 - 2:30 of the following: https://www.youtube.com/watch?v=gb791SrJBJY. It would be waaaay coool to rearrange the CiviCRM screens like that!

I do not know if there is anything like that in Symfony or if we'll have to find it some place else (building it might be a bit too ambitious).

[andrewhunt]

This could also be handy for a responsive approach to mobile interfaces.  If fields were units with easy-to-customize attributes, you could say that birth date is a field that's displayed by default, hidden when you're in "quick mode" (or whatever the mobile-oriented interface might be called), and nested in the demographics section.  Nicolas could alter the config and then say he wants it hidden by default for an association.  I could make it visible in "quick mode" for a youth organization.

[joanne]

I agree this would be very very useful. 

As a user who has just upgraded from 4.2 to 4.4 I now find the block in the prime location on my contact summary screen (top left) contains only one field (nickname) that we use regularly. The rest are used for only 5% of our contacts. 

I would love to be able to drag and drop the blocks to suit our use.

[nicolas]

FYR - another graphical form builder: http://www.wufoo.com/form-builder/

I only know of this service because a customer of mine has been using it in the past to do event registrations, and is now trying to replicate the same with CiviCRM for their event registration pages. We are having to field a lot of questions ...

[clarkac]

Something like that would be terrific and a huge plus in making Civi better for end users! I would try to get funds for a MIH for that. 

[Coleman Watts]

CiviCRM clearly needs a form builder, and profiles is not it. Neither is Webform, although it does fill quite a few gaps at the moment (for those using Drupal).
The core team has kicked around ideas about this for over a year now but so far it hasn't gotten any funding or made it to the top of the list.
Here are some ideas/specs we came up with:
http://wiki.civicrm.org/confluence/pages/viewpage.action?pageId=73924905

[jcasharpe]

You know the best way to do all of this would be to rewrite all of the display logic so that it makes use of the API exclusively.
This gives you a twofold win:

• Ability to customise the screens via standard hooks
• Scalability of the api

It will definitely show up many limitations in the current API but this is exactly the purpose of this exercise; the API should enable a developer to reimplement all the core display functionality.

[Coleman Watts]

Well, yes, and... talk is cheap. "rewrite all of the display logic" is not exactly something I'm going to go and do this weekend.

[jcasharpe]

Indeed, but this is the Saloon, so I was putting the idea out there!

Its more about thinking about the direction of the display logic and creating a proper MVC style separation.

For instance there are a lot of inconsistencies in the implementation of the Label generation code vs Export in terms of how they scale and how they handle things like merging by address / household. If these were implemented in terms of the api then you start to get an efficient api exposed to the users (which the current api really isn't in some areas).

Basically my thinking here is that civicrm needs to start to eat its own medicine in terms of using the api itself; afterall if you currently want to change a core screen you're either going to have to hack core (or at least some rather convoluted hooks) or implement your own display screen in terms of the API. I've gone down exactly that route of implementing my own display screen over the API for two reasons; the permissions system in Civicrm is very convoluted to tightly restrict users to a very small subset of the data and smarty templates just don't quite integrate into the theme that the rest of my site is using without extra css to style the smarty generated parts of the html.

[Eileen]

And actually - one of the proposed paths is to re-write current pages using Angular JS & API.

Agree that the saloon is about discussing great ideas without being constrained by where the funding is - as hopefully the discussion will be beneficial in framing future work.

[Chris Burgess]

A gist I wrote a year ago on Contribute forms, was a draft of a blog post that didn't eventuate then.