Make the main forms more customisable

[xavier]

Hi,

We had a very interesting discussion yesterday with the civicrew and lots of civiconsultants. One of the problem that seemed to be shared by a lot of installs is that the default screens, for instance the contact edit, are packed with the core fields, but we use far from all of them.

For instance, I never use openid, never use the state/county field, never use the nickname, never use the suffix... That's likely that your own list of unused fields is different than mine, but I'd guess it quite long as well.

Having a more complex form than needed has several problems, it makes civi looks scarily complex, takes time during the training ("well, openid is...a nerdy thing you don't need") and makes the data entry clumsier, as you have to scroll up and down between the name, the email located 20 fields below, the employer far up, the phone down...

What I suggest to avoid that is to use profiles, but to improve the existing profiles.

1) it should be possible to replace the default edit/view screens of contacts and other components with a "default" profile, that will contain only the main and custom fields needed.

2) When used by I logged in user with civicrm access rights, the fields should be "smart". eg the current employer field should have the autocomplete/create new, the phone should have the drop down to let choose between phone/mobile/fax, the email and phone should have the +add to let you create several...

3) The profile manager should be way less painful to use. Instead of having to add field by field, set in the profile if it's an individual, a contribution or an event, and on the field page, offer the list of all the existing fields (including the custom ones), and let you check/uncheck the ones you want to see/hide.

4) By default, provides the default profiles with all the fields activated and one example of a simplified one.

5) at the bottom of the view/edit pages, add a link "customise this page" for the users having civicrm administrators rights.

6) being able to add profiles as new tables on the contact. For instance, the main tab contains the contact fields you need 80% of the tiem, but you have a demographic tab too, with the core fields+a bunch of custom fields.

What do you think ?

X+

[peterd]

Interesting option, and yes we may have a couple of contracts that would benefit from such options that we could therefore carve some funds out of (small scale NZ-type funds ;-) ).
Also please consider the discussion on this thread in terms of how to configure phone etc in a way that seems more logical. http://forum.civicrm.org/index.php/topic,4862.0.html

[Dave Greenberg]

Peter / Xavier - Kurund and I have begun discussions on the "project" of redesigning the main Contact Edit form and Contact Summary screen. We're looking to do this in the 2.3 cycle - possibly with some partnership from folks like you two. I've updated the "placeholder entry" in the 2.3 roadmap to include the general concept of field-level configurability. We'll be discussing and developing our thoughts on this over the coming weeks and will certainly be looking to discuss both the what and the how more.

http://wiki.civicrm.org/confluence/display/CRM/CiviCRM+v2.3

[peterd]

Good to know - thanks for this Dave

[davem]

I would like to add that in the UK civicrm meeting yesterday http://civicrm.org/node/494 this was a complaint of several people who had either experimented with or used Civi in earnest. It was also noted that in many other systems you start with something very bare-bones and add components while in Civi you start with everything and spend a lot of time removing components that are not required for this particular scenario. This would appear to be putting off potential converts to CiviCRM.
Perhaps some of the data collection that is now going on from live installs will inform the team what's a more essential core to be turned on by default....

[Donald Lobo]

one of our goals for 2.3 or a future release is to separate components into their own little downloads. So all the non-core compoments (civicase, civipledge, civiauction, civimail) will have their own little downloads and installs

we'll also have an all-in-one package for folks who want everything

however, a bit curious about this. Since disabling a component is basically a one screen thing. does it really matter?

lobo

[davem]

I think it's a perception thing. If people look at a demo and see everything they think "Hey this is a really complex bit of software" (correct) and then in some cases "it's probably too hard to learn for our volunteers" (incorrect). At the meeting last week we had the North West England ICT Champion who promotes software to voluntary sector orgs across a large area. He voiced a concern that for many of the orgs he deals with, the default interface is going to be very off-putting and although he was generally positive about it, felt that he needed to see some examples of worked up sites/demos where the interface is stripped-down enough to be not daunting to a 65 year old volunteer who is in the office one day a week, sorting out e.g. membership applications or logging phone calls.
I think there are two issues here:
one is about presentation and spreading the word/selling civi and this could be facilitated by a cleaner simpler default look where you can respond to "ah but can it do X?" with click click click done
the other is making things simpler for people who are doing the config so that some of the set up is simplified / improved as Xavier suggests.

[xavier]

What about adding a last step in the install with key customisations links:
- disabling modules
- setting the org information
- setting the map feature/the currency/the country
- adding groups/tags/custom fields
- (I will make a list of what I change next time)

BTW, one perception problem: by default, you have a maximalist approach for the modules, but not for the countries (only US is selected). I'd suggest by default to put them all, to avoid the US centric impression.

X+

[michaelmcandrew]

Hi there,

Great discussion - really support these ideas.

however, a bit curious about this. Since disabling a component is basically a one screen thing. does it really matter?

I think when people say this is too complex, they are often referring to the number of fields in the edit contact screen, as opposed to the number of modules installed (ability to turn off module functionality exists, after all)

Kurund and I have begun discussions on the "project" of redesigning the main Contact Edit form and Contact Summary screen. We're looking to do this in the 2.3 cycle - possibly with some partnership from folks like you two. I've updated the "placeholder entry" in the 2.3 roadmap to include the general concept of field-level configurability

Sounds great - just the kind of thing that we were talking about on the conference call.  I'm happy to join in here.  I think a good way to approach field-level configurability would be to allow admins to edit individual, household and organisation core fields as if they were custom fields that are reserved in some way.  An added benefit of more standardisation in the the way form field html is constructed would be easier styling of forms.