Usability - Contact Edit and Summary Screens

Prefix your entries with your (first name) to facilitate further discussion.

This focus area includes overhaul of Contact Edit form and Contact summary screen to make them less location-centric and more customizable We will consider providing a mechanism for field-level configurability for the edit form and summary screen (include / exclude core fields, set order and grouping...).

Kurund and several other folks on the team are currently working on prototypes for the contact edit and summary forms. The advisory group team should coordinate with them as soon as possible - review the work done so far, etc.

You can review the current iterations here (we will be combining these ideas in a new iteration shortly):
Version 1
Version 2

Usability Pain Points

Use this section to list pain points. Include the use case(s) / workflow(s) where it occurs and some idea of severity of problem (using 1 to 10 scale where 10 is the most urgent). Let's try to keep these sorted by severity.

Chunk headings aren't very visible

(michael) The contact view screen isn't very well chunked - sometimes it looks like a big long list and it is hard to differentiate between headings and field names.  headings currently change format they are expanded which is confusing and makes it unclear that they are headings.

Repitition / things that should be removed

(michael) Print icon on right hand side is repitition / not in the right place

Sub optimal grouping & naming of the groups

(Xavier) The first group is named "Name and Greeting" however, it contains fields like the source, the website and the external ID. Name and Greeting is probably not the best name (or these fields shouldn't be grouped that way)
Moreover, for what I seen from the data entry practice, you tend to input the name and primary contact details together. Basically, what you have on a business card. Right now, these information are spread between the Name group and the Primary location. As soon as you use the Communication Preferences and custom fields, that's spread over a long distrance.

It would be useful to be able to define what are the blocks, their order and what fields they contain.

[brian] Even if the ability to modify the order of the blocks (through the interface) is put on hold for future consideration, there should be greater effort to keep layout consistent and more logical between the summary and edit forms. For example, currently the address blocks show up below the name/greeting and comm pref blocks in summary view. In edit view, the custom field blocks are below name/greeting/commpref and the address is way at the bottom. There should be consistency between the summary and edit modes:

• Contact details
• Communication preferences
• Addresses
• Demographics (integrated into contact details block?)
• Custom inline fields
• Tags and groups (integrated into contact details block?)

(Gregory) Source and external Identifier are definitely in the wrong "grouping" of fields.  They seem like that should be together on their own, and most often are probably used when IMPORTING contact data, not when entering it manually.

Too many fields "I" don't need

(Xavier) On our case, I fill less than half of the fields, and I suspect that's the case everywhere, but that isn't the same half.  Moreover, you have fields that are useful for a type of individual (eg. the volunteers) only.

(Michael) a) Some of the information on the summary screen my clients aren't that interested in, but other parts that are really interesting aren't visible.  For example, LIOs really want to be able to see employees of an organisation on the organisation summary page, but they really aren't that interested in an organisations communication preferences as that tends to only apply to individuals anyway.

Expected behaviour of the tabs (back button or bookmark) is broken (general ajax issue)

(Xavier) As discussed here, moving from one tab to the other isn't properly stored in the browser history, so back buttons and bookmarks for instance don't work. There are js methods so ajax interfaces works like expected (based on adding a #tabid on the url). Worthwhile investigating if we start adding more and more ajax goodies (eg in the list navigation on the contact search as well...)

http://forum.civicrm.org/index.php/topic,6852.0.html

Solution Concepts

Use this section for ideas about general approaches - with rationales (how does this approach fix things, what pain points does it address, what use cases does it serve / serve better than the current approach).

(Dave) Excellent mockups / suggestions from our users can be found here: http://forum.civicrm.org/index.php/topic,4862.0/topicseen.html

(Dave) See Xavier's forum post here for one possible approach: http://forum.civicrm.org/index.php/topic,6350.0.html . However Lobo and I are concerned about a Profile-style approach to the contact edit form due to concerns about having a good tight layout for the "core elements" of the form (e.g. name, phone, email, address etc.) - dynamically generated forms like profiles generally are just vertical lists of fields in our experience.

(Xavier) In my mind, each of these block (Name and address,demographic, Communication preference...) is a "profile", you will have more than one in the edit form. I suggested the profile precicely because it already provides the solution to what Dave mention: using custom layout (eg CRM/Profiles/Forms/nn/Edit.tpl) you can put the fields the way you want.

(Michael) re dave's comment above - Dave a tight layout on a high resolution monitor is a too wide layout on a low resolution monitor.  I think if you had less fields then you wouldn't have to worry so much about how tight it was, plus I think there is a lot of space that could be saved by taking off a couple of pixels here and there.  I think two colums is the max you would want - perhaps that could be defined as part of the profile.  Number of colums (1 or 2).

(Michael) re a) it would be great to define what relationships are visible on the summary screen, i.e. all employees of an organisation are visible on the summary page of an organisation.  you could see this as an extension / replacement for the Current employer that appears on an individual page, which is essentially one use case of this.

[brian] I don't like the idea of making these pages/blocks controlled via profile. It might make field control easier as it can be done through the interface, but it would limit how much flexibility you have to add custom content to the pages. I also would be afraid that end users would get in to the profile management and start messing around with stuff without appreciating the potential consequences.

[brian] I've attached a few mockups of summary/edit page modifications I made for a client some time back. Note that they are still using v2.0. I never really "finished" implementing layout modifications, so some sections are sort of half-done, as functionality took precedence over layout/style. Anyway, my philosophy of layout was: tighten everything up so that the end user can see as much on the screen as possible without compromising readability; use better styling to distinguish field labels and field data (better visual references); add simple styling for tables (borders, etc) for layout clarity; use a better small font (verdana is more readable in small sizes than arial, which is the default admin font in joomla).

[brian] I *really* want the vertical scroll inside each tab to go away (visible when content extends beyond fixed height). I just find that very annoying. Scrolling should be handled by the browser, not the tabs.

Use case

The most common usage we have is to input a contact from a mail received, and the format is "John Doe" <john@doe.com>

It would be the easiest if somehow we could simply paste it and automatically fill the first+last+email fields instead of having to copy paste 3 time.
Not sure at all what is the best place to do that within the contact form, or if it's better to put it elsewhere, just that I'm sure that "paste from email format and split it in the 3 fields" would be a
feature that makes thinks easier.

What do you think ?

(Gregory) What if you could forward an email to civicrm and it could parse the headers and create a contact, similar to the way dopplr and trippit can parse the info in travel reservation emails?  An alternative could be a "create contact(s) from email headers" form that would let you cut and paste an email address blog that might contain MULTIPLE names and email addresses and turn them into contacts that you could then edit with additional information.

[Joe] Other CRM's offer an Outlook plug-in to allow users to quickly add a contact to their CRM without having to leave their browser. Would that help? While I know that Outlook has a strong prensence in the general email client market, I'm not sure what its share is of the CiviCRM user space.

Use sub-type

As you don't have the same fields for the Individuals and the Organisation, it should be possible to have different fields for a provider and a political organisation, or between a politician and a volunteer. Right know, all the fields for an Individual have to be present for all the Individuals, no matter their "sub type".

This takes space with fields that aren't used, but it also makes the training and usage more difficult, because you have to remember that "political party" has to be filed for a politician, and hotline number has to be filled for a provider.

• [brian] This is an interesting concept. Were you thinking of this specifically in relation to custom data fields, core fields, or both? What would be the basis for the distinction? --- membership, tags, groups?

Specifications

Use this section (or a separate page) for detailed specifications for the chosen solution(s).

in place editable view of the contact

It would be ideal that from a contact view page, you can click on the name or phone about any field and modify it directly (eg with jeditable http://www.appelsiini.net/projects/jeditable ) without having to go through the complete edit form.

Another added benefit is that it'd be easier to have a more detailled change log (ie. "18/03/2009 Xavier new main phone: +001 283 2939 (was +001 283   597497)

• [brian] I second this idea. The current usefulness of the changelog is very limited. I can imagine that tracking a ton of details would bloat the database pretty quickly, but it would be useful to at least get a little more info into the system. This is probably part of that larger discussion that took place a while ago about deleting contacts vs. trash/recycling can capabilities.