CiviCRM Community Forums (archive)

I think the organization of tree on the  "Administer CiviCRM" page could be improved and simplified.

The areas that I think are fine and would not change are: CiviContribute, CiviMember, CiviEvent, and CiviMail.

But "Customize", "Configure" and "Manage" all need rework.  These three words are all synonyms for "Administer" which is the part of the page title!   They do not add any information!   

I would also bring all the choices under "Global Settings" up so that they appear in the tree.  The links for "Mapping and Geocoding" and "Payment Processors" should be moved to the "Option Lists" area of the tree.  ( After all, mobile phone providers is already there, why not mapping and payment options? )

The "Misc" term under Global Settings should be eliminated.  That is a meaningless word.     

This is how I would suggest the tree should look:   

- Security
  -- Recaptcha
  -- Uploads/filetypes allowed
  -- Secure URLS allowed/required
  -- Debugging


- Host/Environment specific information
  -- Settings for Joomla/Drupal
  -- Update Directory Path and URL
  -- Upload Directories
  -- Outbound SMTP
  -- Owner Organization ( was renamed from "Domain Information" )
  -- Email sending preferences ( was email preferences from "Domain Information" )



- Appearances and Cosmetic 
  -- Templates
  -- Message Templates
  -- Site Preferences

-  Localization
 --  Date formats
 --  Addresses ( was renamed from "Settings - Addresses")
 --  Language and Currency
 --  Contact Address Fields - Selection Values ( was on Localization page)
 --  Multiple Languages Support

- Searches
 -- Any settings anywhere that control/impact search behavior.
 -- Saved Searches settings
 -- Profiles that are used for searches.

- Getting user input / data collection
 -- Custom Fields
 -- Profiles that are used when collecting input.

- Managing data
 -- Find and Merge Duplicate Contacts
 -- Import/Export Mappings
 -- Synchronize Users to Contacts

- CiviContribute
  -- no changes from existing system.

- CiviMember
  -- no changes from existing system.

- CiviEvent
  -- no changes from existing system.

- CiviMail
  -- no changes from existing system. 

Another approach to some of this is to examine use cases and make it easier for users to do what they are trying to do when they need to do it.

Let's say a person is creating a new Event. They need to capture different data than before. Right now they'll tend to realize this when they are part way through creating the event, then they'll save their partially completed event in order to go elsewhere to create a profile, and then have to break out of that to create a few custom fields, then they'll be to go back to complete the profile, then go back to complete the configuration of the event. Would be nice if they could be able to handle those tasks within the CiviEvent configuration context.

In a few ways like this, the current menu system is set up more along the lines of taxonomic groupings than used at the same time groupings.

Joe

I think the "create a new x" should appear inline with the activity as well as in the Admin area.  I am thinking of these things as if we can "tag" the step.  For example the step called "Create a new Mapping Provider" should be tagged with "Create a new Event" , "Display Contacts on a Map" and "Admin Area"       There are many settings that are used within many activities or use cases.     

The step called "Collect custom fields" should be tagged with "Create a new Event", "Create a new Contribution Page", "Create a membership sign up/renewal page", "Front end update of contact", and "Admin area"

That way if I am in the middle of a use case, I can create extra settings within the screen/wizard I am in. The jumping around should be eliminated.  As well as have everything well-organized in the Admin area. That way I don't have to create a new event just to change the mapping provider.

The Admin area should also show "orphaned" settings. Such as custom fields that are not used in any event or contribution page.  Or payment processors that are not used for any paid events or contribution pages.

I think the "create a new x" should appear inline with the activity as well as in the Admin area.  I am thinking of these things as if we can "tag" the step.  For example the step called "Create a new Mapping Provider" should be tagged with "Create a new Event" , "Display Contacts on a Map" and "Admin Area"       There are many settings that are used within many activities or use cases.     

Sarah - Thx for your thoughtful feedback. One piece that I'm not quite understanding is your use of the word "tag" (as in the above quote). Do you mean that the user should be able to click some UI item that would inject that form / task into the steps of the primary task they are working on? If so, how would you imagine that "looking"?

I think we can make progress in reducing the "jumping around" problem over the next few releases - as we get more experience with the jquery library. However we also want to make sure that we present these secondary task "paths" in such a way that it doesn't increase the perceived complexity of completing the task "at hand".

Examples of specific interfaces in other web apps that handle these types of chicken / egg problems elegantly would be helpful to share.

Sarah - thx for the clarification and the examples in the mockup. I've added notes about these improvement suggestions to our list of feature candidates for 2.3. I think both the "---create new---" pattern as well as injecting a div with a set of configuration fields are good approaches / applicable to quite a few Civi tasks.

Thx Sarah - Google has been making interesting (and I think mostly good) changes to Gmail interfaces recently and I like that one too.