Organization of links for the "Administer CiviCRM" page

[SarahG (FountainTribe)]

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. 

[xavier]

Hi,

And where would you put the other items (profiles,custom fields...) ?

I'm working on a prototype, would it be possible for your to create an html list with these options ? I would be able to use it directly

<ul>
  <li>....</li>
...

[JoeMurray]

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

[xavier]

Hi,

Certainly like the idea, and it should in principle offers "create new X" to those having administer rights at these places.
It's already the case when the list is empty (eg empty search result...), but could be extended.

This being said, these are mostly "shortcuts", it should still offer a properly organised admin space. I'm wondering to what extend some configuration shouldn't be close to where they are used.

Eg the entry to the admin page for the messages template should be around the activity menu, not the admin (?)

X+

[SarahG (FountainTribe)]

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.

[SarahG (FountainTribe)]

I have attached an HTML version ( saved as a txt file) of what I think the tree should look like.

[Dave Greenberg]

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.

[SarahG (FountainTribe)]

I shouldn't have used the word "tag". Only the CiviCRM programmer should control what "steps" are part of a wizard. 

I created an example of what the "Create Event" wizard could look like. Check out http://www.poger.net/testjoom/ideas/create_event.html   Focus on the select lists for the "event type", "participant role", and the checkbox for turning on mapping.

In the case of the checkbox for mapping, I took the approach of adding a inline "configuration" icon to indicate that something can be changed there. The icon needs to be a bit smaller, but hopefully you get the idea.

For an existing website that handles this situation is Google's Gmail. They used this approach in adding contacts to groups.  In the same pull-down list, I can add a contact to an existing group; or create a new group and add them to it.  Although I do not like the JavaScript dialog window, I think they could have done a floating DIV instead. 

[Dave Greenberg]

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.

[SarahG (FountainTribe)]

I found a better example that handles the "create new" task. Within Google's Gmail application, they have a nice approach for adding labels to messages.   To see the feature: Go into the Inbox, then put a check mark next to 1 or more messages.  Then click the "Labels" button.  It should show all existing labels, plus "create new". Click on the "create new" then a modal dialog appears. The dialog can be positioned anywhere.

[Dave Greenberg]

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