Pubblicato
2009-04-15 17:19
A major focus for the next version of CiviCRM (v2.3) is improvement and optimisation of the user interface and its usability. During the last few weeks, together with our Advisory Group, we've been busy investigating different options for changing the way CiviCRM looks and behaves. This project will has quite a large scope, and will span over at least two versions.
For version 2.3, one goal is to unify the way different functions are being handled from a user interface perspective. We'd like clean up the HTML and CSS for as many templates as possible, and introduce stable standards for building user interface elements. From a technical point of view, one of the efforts is to make heavy use of jQuery and jQueryUI, but that seems like the easy part. Much more difficult is figuring out how to make our user interface easier to use, provide solutions that will allow people to perform everyday CiviCRM tasks quickly and effectively - and also how to make it look nice. :-) There is ongoing discussion within core team and Advisory Group on this, we are experimenting with different solutions. We will be asking you for opinions and feedback as we move forward with this part of the work for CiviCRM 2.3.
One important piece is improving the contact add/edit screen, which is one of the most crucial parts of the system. It is used quite frequently and is also quite complicated. We've built a mockup screen to share our draft "re-design".
We had a few iterations of work on this screen, and we've come to the stage where we would like you to give us feedback on whole idea. Two main goals behind the changes:
- Provide a simple and quick way to input the most important information - name and contact information. This has been approached by moving email, phone and IM fields together with first name, last name etc into to first section.
- Make the user interface on this screen more compact and make it easier to get to the sections you want to edit with minimal scrolling.
Filed under
Comments
hi,
suggestions:
1. Move nickname up on the same line as first/last name. Maybe enclose in parenthesis?
2. If you think #1 is a good suggestion, either remove nickname from "Communication Preferences" and add a check box to "Use Nickname" or autofill nickname and add the same checkbox.
3. I'm of two minds about the position of the address information. My first reaction was that it should be moved up directly under the "Current Employer" boxes, but I guess that depends on what information folks want to see first.
If you did move it up I would suggest collapsing it so that folks would not have to deal with it if they didn't want to.
4. Address information is missing a drop-down for location type e.g. home and also a check box for "Primary". Speaking of which, I prefer (no pun intended) the work "Preferred" as opposed to Primary but that's not a big deal.
5. What about the button to "Check for Matching Contacts"?
thanks for listening,
Cynthia
I have a hang up about the whole presentation of the name in that it's just hard to read in three fields split across the screen like that.
I find visually that I'm almost wanting to see a view only business card at the top with key details (and empty fields suppressed) and then to look for the items I want to change below.
Hi,
Ive experimented with an ajax background call to check if there is a duplicate when adding a name. Works nicely IMO. I'll discuss it with the core later this week.
X+
Xavier,
We were thinking about the same. Please raise the topic as soon as possible. :-)
Ad 3. That'll probably be a part of next phase discussion.
Ad 4. We forgot to include address type dropdown in the mockup. :-)
Ad 5. There is still discussion going on about it. I'll include the button in next version of the mockup.
I agree that nickname should be with the name, since an end user may not open up communication preferences each time they view the record.
I also wonder about the "website" field being with the name and employer. Is there a reason why website is not associated with a location? thus allowing users to have multiple websites? This could page the way for using "website" for urls to various social media and networking sites, like linkedin, twitter, facebook, etc... Each "url" field could have a second drop down the way that the phone field does to indicate if the number is a phone, cell, fax, work, main, etc...
I realize that this is more a data structure suggestion than a user interface suggestion, but i figured i would make it anyway. the url field has always confused be since it is right along side the current employer, if it stays there it should probably be labeled "employer website" just to be clear.
also, "contact sources, ids, and notes" One of these things is not like the other: Notes. Notes should be its own grouping since a user can have multiple notes, and I do not associate the notes field with the source (where the contact was imported from) or the external identifier. I could see limiting a user's access to that info, while wanting to give the user access to the notes fields. The other thing that could be added in that section is info about the contact's user account on the drupal or joomla website, ie cms user name, member since, link to user record, for example....
The address section is missing the "address type" drop down (home, work, summer, main, other, etc...)
I have several clients with CiviCRM installations and have had a chance to watch some of them as they have been using CiviCRM. The biggest hurdles I've seen in every case have been related to how long it takes to get things done in CiviCRM.
A good example is CiviContribute or CiviEvent. If they have a dedicated processor handling event registrations or contributions into the system, it's a nightmare to go through that process. You have to search for the contact, go to the contributions tab, log a contribution, go back to search and repeat again. That doesn't include loading and scrolling time during the searches. There are several options on how to rectify this, but one in particular keeps hitting me.
Offer "New Contribution" and "New Event Registration" screens. I know this is a bit of a step away from the usual idea of a CRM, but it would help a lot. You could use the same AJAX search look up tool you have in the quick search area to select the contact you want to log the contribution/registration for.
I think the above idea is quite neat and would be useful to quite a few folks. I also think it is relatively easy and would be a great community contribution. Since you have quite a few clients with this need, wanna step up and do so? We are glad to help out on the IRC channel
As an open source project, community contributions are important to the health and vitality of the project. If you are not a developer consider sponsoring a developer to do the required coding
lobo
Lobo,
I'd love to make a contribution... the question is whether I'll have the time to do that. In the meantime, where would you recommend that I research on the essentials of developing for CiviCRM? I've done some hacking on core files before so I can find my way around most of the system, but I'm by no means familiar with the framework.
rather than in blog post comments. http://civicrm.org/architecture/ is a good staring point. You can also catch most of the developers on IRC
While using wordpress again recently after a break of about 3 years, I noticed how much more usable their system has become. The quick add on the dashboard is great but also when you want to edit a post you can click on quick edit (which shows up on rollover) to make common changes. I think being able to do a similar thing from a contact list in search would help no-end. It might include a fair amount of javascript though.
Given that a massive % of fundraising for most non-profits is till direct mail. I would like to see a batch entry system for this kind of thing.
3 steps
1.) Enter the # of gifts and total amount of gifts as a check
2.) Enter the individual gifts (Amount, date, type, etc...). It's also nice ot have the value for the last gift be the default for the next that way people can pre-sort the returns in order of type/date.
3.) check total entered = step #1
The trick to this kind of thing quickly becomes how much to you let people enter the individual records to make changes noted on the individual returns (ie new e-mail, phone number, etc...). If you let people leave batch entry you have to store all the values to return to when they save the record.
I'm really excited about both CiviCRM and Drupal's recent pushes on usability. This is an area in which both projects can really benefit from focused effort.
Here's a few thoughts on the new contact add form:
- Why the question marks? on some checkboxes? does it indicate something different about this checkbox compared to one with no question mark?
- The demographics and tags & groups fieldsets don't open in mac FF3.
- The help links don't open in mac FF3.
- There's a textfield and a textarea with no labels under "Contact Source, IDs, and Notes"
- For emails and phones it's not obvious that the "add" links are in fact clickable links.
- Perhaps the "primary" radios should only show if there is more than one email/phone etc. If there is only one then it must be primary, and we could just remove the radio to keep it cleaner. I'm a big fan of keeping things as simple as possible and only adding complexity when necessary.
- Similar to the above if "Use Household address" or "use employer address" is selected, the address fields should hide. Conversely we might only include those checkboxes if there is a household or employer address to use.
- It might be an idea to have help links for "on hold" and "bulk mailings". The meaning behind these is not obvious to new comers.
- I think it would help to have labels for a set of checkboxes to be styled differently (perhaps bold) from the labels of individual checkboxes. For example for Communication method, it might help for the label "method" to pop a bit more so that we understand what those checkboxes specify. Also it might help to have the word "preferred" in there because just "method" is a bit ambiguous. Also why are they checkboxes and not radios? There can only be one preferred method. Allowable methods are anything not on the "do not..." list.
- "and also how to make it look nice". I think that can largely be done with jQuery UI themes. I'd be happy with CiviCRM out of the box to have the default jQUI look and feel.
- I really like having the main fields grouped into the first fieldset.
- "allowing administrators to enable/disable fields" +1 for that. This could be simple switched at /civicrm/admin/setting/preferences/display
- "allowing administrators to change order of fields and sections as needed" -1 for that. I think we need to be cautious of option-itis. I like Drupal's philosophy of having UI for the common things, and an API do do anything else. For fieldsets you can do this via hook_civicrm_links. For fields we can do this with templates. I have a hard time visualizing how to do this programatically for fields without rendering the templates useless.
But great work so far. I think this will really help streamline things.
> - Why the question marks? on some checkboxes? does it indicate something different
> about this checkbox compared to one with no question mark?
Well, question marks are the leftover from initial versions of mockup, where there was very little space in between columns and labels were mixing up. Question marks were setting boundaries for labels back than. :-) I think they'll go away in final version.
> - The demographics and tags & groups fieldsets don't open in mac FF3.
Weren't implemented in this version of the mockup.
> - The help links don't open in mac FF3.
As above.
> - There's a textfield and a textarea with no labels under "Contact Source, IDs, and
> Notes"
Mockup perks. *blush* :-)
> - For emails and phones it's not obvious that the "add" links are in fact clickable
> links.
Agreeed.
> - Perhaps the "primary" radios should only show if there is more than one
> email/phone etc. If there is only one then it must be primary, and we could just
> remove the radio to keep it cleaner. I'm a big fan of keeping things as simple as
> possible and only adding complexity when necessary.
The idea was to have "Primary" visible, but disabled for single field. When more fields is added, "Primary becomes active. We've been discussing that a bit within the team, and from what I remember, I couldn't figure out what to do with column label, when there is no field. "Primary" label above empty column was looking a bit wierd, and hiding the label was actually hiding available functionality until user clicked something - which I think is a bit misleading.
> - Similar to the above if "Use Household address" or "use employer address" is
> selected, the address fields should hide. Conversely we might only include those
> checkboxes if there is a household or employer address to use.
What if they were disabled and filled in with household or employer address data? This would have additional advantage of "previewing" the address that is being chosen.
> - It might be an idea to have help links for "on hold" and "bulk mailings". The
> meaning behind these is not obvious to new comers.
True. Will include that in next mockup.
> - I think it would help to have labels for a set of checkboxes to be styled
> differently (perhaps bold) from the labels of individual checkboxes. For example
> for Communication method, it might help for the label "method" to pop a bit more so
> that we understand what those checkboxes specify. Also it might help to have the
> word "preferred" in there because just "method" is a bit ambiguous. Also why are
> they checkboxes and not radios? There can only be one preferred method. Allowable
> methods are anything not on the "do not..." list.
I'm not sure personally what was the history behind this choice. I'll make a note to raise it for discussion here.
> - "and also how to make it look nice". I think that can largely be done with jQuery
> UI themes. I'd be happy with CiviCRM out of the box to have the default jQUI look
> and feel.
We're aiming to have that as a part of long term usability improvement process. :-)
> - "allowing administrators to change order of fields and sections as needed" -1 for
> that. I think we need to be cautious of option-itis. I like Drupal's philosophy of
> having UI for the common things, and an API do do anything else. For fieldsets you
> can do this via hook_civicrm_links. For fields we can do this with templates. I
> have a hard time visualizing how to do this programatically for fields without
> rendering the templates useless.
It's quite a popular demand to be able to customise CiviCRM for specific organisation data entry workflows, and that's just planning for providing that. As mentioned somewhere above, it's going to be a separate discussion.
Thx,
m
I like the way the Apple Address Book works on a mac. If you want to add any new field like email, phone or street address you can just click on a little plus (+) icon and the field appears ready to be filled in. You can then choose what type it is from a drop down. This means that you don't have to do an entire block of new data if you don't have it. Just a thought. Plays havoc with the current civicrm data structure though I bet.
It's a bit difficult to find good UI design for this kind of approach, since different fields have different "additional attributes" (email - On Hold, Bulk, etc, IM - service) and also each "category" has "primary" concept. Didn't figure out a good way to represent especially the last thing in Apple Address Book-like UI. If you saw good example of such solution or have an idea on how to implement it, would gladly follow up this idea.
I think the use of the accordion is great. Perhaps a small button top right of it could expand all sections out or contract. This way it cuts out extra clicking when doing mass data inputting. Also would be good if after clicking save & new the tabs that were open last stayed open (just a feature that might help without people even noticing it's there).
I see there is now an 'Expand all tabs' link at the top - nice. How about changing the link to 'collapse all tabs' if all tabs are currently expanded?
Great work! So much better. I just have a few things to add in addition to the other good comments:
* I'm in favor of being able to control which fields appear on this screen, their order, and whether they're collapsed or not. The more options we give with such an essential part of CiviCRM, the more power you give to the end user and administrator.
* I agree nickname should be up in the contact details box
* Where would custom fields go? Would each new custom field group be its own "tab?"
* This isn't so much usability, but another option I would like to see is more control over which of these fields are required or not.
* Hopefully the tags/groups section will formatted in a way to allow the easy addition of tags and groups. On the current new individual screen, a group's description doesn't wrap pushing out the tags field off to the right. Very unfriendly.
* Last, this might be a good time to add the field, "addressee" to communication preferences. This has been a long time request and would help a lot with mailings. Again, not usability but comes up when i think about the end-user workflow.
Again, overall, very nice.
Tony
Some quick thoughts on your propositions:
> * I'm in favor of being able to control which fields appear on this screen, their
> order, and whether they're collapsed or not. The more options we give with such an
> essential part of CiviCRM, the more power you give to the end user and administrator.
This will most probably come in next iteration of screen improvements.
> * I agree nickname should be up in the contact details box
Will move it to contact detail box in next mockup.
> * Where would custom fields go? Would each new custom field group be its own "tab?"
Each group will be in their own tab right now.
> * This isn't so much usability, but another option I would like to see is more control
> over which of these fields are required or not.
Again, subject to discussion on next iteration.
> * Hopefully the tags/groups section will formatted in a way to allow the easy addition
> of tags and groups. On the current new individual screen, a group's description
> doesn't wrap pushing out the tags field off to the right. Very unfriendly.
True - will try to propose something about it in next mockup.
> * Last, this might be a good time to add the field, "addressee" to communication
> preferences. This has been a long time request and would help a lot with mailings.
> Again, not usability but comes up when i think about the end-user workflow.
Probably a good thing for forum post. :-)
I like the changes with putting more of the essential, often-used info at the top, like e-mail and phone. However, I also really like having the nickname field at the very top, or at least, I would want nickname displayed where it currently displays at the top in parentheses when you are looking at an existing contact.
I agree that the form could benefit from being more configurable. For example, we never, ever, collect IM info. It would be nice to be able to drop that field out of visual existence.
Overall, I think it's a big improvement.
This looks great. This will really save time for the user from scrolling back and forth to look at different information.
I have a couple of questions about the custom fields. Can they be grouped with base civi fields and also exist in different sections?
Can we customize these sections to be visible or hide?
So, basically being able to configure these sections will be very important for us.
Great job!!
We didn't plan on any functionality for grouping base fields with custom fields for now. As mentioned in the post, next stage after base screen optimisations will be making contact editing screen more prone to user configuration, but that will be a subject of separate conversation. Same applies to visible/hidden idea.
I'm sure others have made this comment, but I would like to add my vote for some method of notifying the user whether or not the other tabs on a record (contributions, events, notes, etc) contain information. When I am looking at a record and am trying to remind myself what we know about this person, I have to click on every single tab to see if there is information, and mostly, there's not and it's a waste of time. It would be great if the tabs which did have information were automatically a different color, or bolded. Any visual notification.
That would be a huge improvement for me.