+11
Started
Matthew Gow (Community Facilitator) 5 years ago • updated 5 years ago 15
Support through the web configuration of custom fields for contacts, accounts, campaigns etc.

Answers

Answer
Started
This is largely completed in terms of functionality. However, it is still in progress because...
  • improvements to the UI design for the admin screens are still under discussion
  • A few bugs may yet be lurking so additional QA testing and bug reporting is appreciated
  • We need to write up how this feature works and/or provide a screen cast
Latest UI mockup ideas proposed by Mike Dvorkin (feedback welcome)

Create custom field
Uploaded with Skitch!

Custom fields
Uploaded with Skitch!

A few comments:

  • Instead of horizontal buttons I suggest to show the sidebar and create a menu widget. We can use slightly different colors/shapes to distinguish the menu widget from static "Recent Items" panel.
  • There is no explicit notion or extra step of creating a Field Group. User is entirely focused on creating custom field and nothing else distracts her from this goal.
  • Within [Create Custom Field] form user can a) create or select a group (which is required) and b) create a select group tag (optional). Implementation might be a bit tricky since we want to reload available tags when selecting a group, but I think it's doable.
  • Going forward I think it makes sense to use autocomplete control instead of standard dropdown for "create or select" fields. As I recall there is a fork that does that for Account field in [Create Contact].
  • Listing custom fields is pretty much self-explanatory. There are edit/delete controls shown on mouseover for individual fields and groups. Editing a group invokes a short form with two fields: Group and Group Tag.
  • Expanding/collapsing groups (i.e. clicking on [-] or [+] icon next to group name) is nice to have but not required.
PINNED
Please share your thoughts about the proposed design for the administration UI of this feature by reply to this comment.

My thoughts on Michael's proposed design.
  • I think we'll find that having a secondary navigational element will be quite useful in a variety of contexts moving forward. I'm okay with using a widget in the left-hand column. I agree that it would be good to differentiate it from the other widgets so it is clearly navigational. On the topic of left hand widgets, I think we mix our drinks a bit by having the details of things like accounts in a widget over on the left but the edit control for those fields all the way over the other side of the page and the fields someplace in the middle. If we use a left-hand widget for secondary navigation then it will have to be at the top which is another nail in the coffin of using the left-hand widget for display of object details.
  • Tucking the group creation functionality away and keeping the user focused on field creation is fine by me. It could be nice to somehow visually tie the group and tag selection items together. There isn't much room in there for instructional text but a hover "?" icon should suffice right?
I'm using the current git repo to test this. Firstly, it isn't clear to me whether I have to create a "field group" in order to create a field. Secondly: field group created for Contacts, and one custom field of type "short answer" created. If I return to ffcrm, I can't edit any contact. The console from which rails is running reports:

Let me know if you need more info -

Keith

We'll take a look at that bug.

Improving the usability of that interface came up a little earlier and this was a proposed change.
http://screencast.com/t/370Pm5Ys

At a future date we were also considering making it possible to modify and re-order the default fields.
But this is still being debated.
This was a ruby 1.8.7 issue fixed on master in https://github.com/fatfreecrm/fat_free_crm/commit/dbc62a1c545b275da3d922de35ef370f4ff817c7
The original problem I reported is fixed: thank you. However, it isn't possible to edit custom fields on the Admin screens. When I hover over a custom field, I get the "Edit | Delete" links appearing. "Delete" does what I'd expect; "Edit" does nothing.
Very sorry about that. It was the same 1.8.7 issue in a different place.
I've fixed it, and have tested all the other custom field functionality to make sure it works too. Please update your code from master and try again. Thanks!
Oh... scratch that, I'm too slow. Nathan has fixed it. Guess I'll go delete that new bug report! :)
Still not sure the best way to use UserEcho for our needs Keith. But I'm going to try posting your comment as a stand-alone bug so that the guys will see it when they filter for a list of bugs... ummm but that will mean you don't get notifications about it being fixed unless you reply to that topic I'm guessing.
Answer
Started
This is largely completed in terms of functionality. However, it is still in progress because...
  • improvements to the UI design for the admin screens are still under discussion
  • A few bugs may yet be lurking so additional QA testing and bug reporting is appreciated
  • We need to write up how this feature works and/or provide a screen cast
Latest UI mockup ideas proposed by Mike Dvorkin (feedback welcome)

Create custom field
Uploaded with Skitch!

Custom fields
Uploaded with Skitch!

A few comments:

  • Instead of horizontal buttons I suggest to show the sidebar and create a menu widget. We can use slightly different colors/shapes to distinguish the menu widget from static "Recent Items" panel.
  • There is no explicit notion or extra step of creating a Field Group. User is entirely focused on creating custom field and nothing else distracts her from this goal.
  • Within [Create Custom Field] form user can a) create or select a group (which is required) and b) create a select group tag (optional). Implementation might be a bit tricky since we want to reload available tags when selecting a group, but I think it's doable.
  • Going forward I think it makes sense to use autocomplete control instead of standard dropdown for "create or select" fields. As I recall there is a fork that does that for Account field in [Create Contact].
  • Listing custom fields is pretty much self-explanatory. There are edit/delete controls shown on mouseover for individual fields and groups. Editing a group invokes a short form with two fields: Group and Group Tag.
  • Expanding/collapsing groups (i.e. clicking on [-] or [+] icon next to group name) is nice to have but not required.
PINNED
Please share your thoughts about the proposed design for the administration UI of this feature by reply to this comment.

My thoughts on Michael's proposed design.
  • I think we'll find that having a secondary navigational element will be quite useful in a variety of contexts moving forward. I'm okay with using a widget in the left-hand column. I agree that it would be good to differentiate it from the other widgets so it is clearly navigational. On the topic of left hand widgets, I think we mix our drinks a bit by having the details of things like accounts in a widget over on the left but the edit control for those fields all the way over the other side of the page and the fields someplace in the middle. If we use a left-hand widget for secondary navigation then it will have to be at the top which is another nail in the coffin of using the left-hand widget for display of object details.
  • Tucking the group creation functionality away and keeping the user focused on field creation is fine by me. It could be nice to somehow visually tie the group and tag selection items together. There isn't much room in there for instructional text but a hover "?" icon should suffice right?
Just wanted to note here that there is currently no way to add a tag (apart from when creating other records: contact, account etc) so having the ability to do that on this screen might be quite useful... alternatively, we have another admin tab for managing tags but I feel like it fits quite well here if we can work it into the UI intuitively.
The case that the suggested design doesn't cater for is someone wanting to create a new group so they can just drag some existing fields into it. They must create a field in order to manage groups.
There's still some kind of problem. I've created a field group under Account, and added a "short answer" field, and that all looks fine. I went back to Admin and added a second field of type "long answer". Now I can't edit an account at all, and get this in the logs:

ActionView::Template::Error (interning empty string):
    17:                   - checked = YAML.load(value) if value
    18:                 = f.input field.name, field.input_options.merge(:checked => checked)
    19:               - if i == 0
    20:                 %td= spacer
  app/views/fields/_group.html.haml:20:in `_app_views_fields__group_html_haml___36689484__649292678'
  app/views/fields/_group.html.haml:11:in `each'
  app/views/fields/_group.html.haml:11:in `each_with_index'
  app/views/fields/_group.html.haml:11:in `_app_views_fields__group_html_haml___36689484__649292678'
  app/views/fields/_group.html.haml:9:in `_app_views_fields__group_html_haml___36689484__649292678'
  app/views/fields/_groups.html.haml:11:in `_app_views_fields__groups_html_haml__867802286__649535028'
  app/views/fields/_groups.html.haml:6:in `_app_views_fields__groups_html_haml__867802286__649535028'
  app/views/accounts/_edit.html.haml:10:in `_app_views_accounts__edit_html_haml___397045835__648717388'
  lib/overrides/simple_form/action_view_extensions/form_helper.rb:14:in `simple_form_for'
  lib/overrides/simple_form/action_view_extensions/form_helper.rb:13:in `simple_form_for'
  app/views/accounts/_edit.html.haml:2:in `_app_views_accounts__edit_html_haml___397045835__648717388'
  app/views/accounts/edit.js.rjs:27:in `_app_views_accounts_edit_js_rjs__569940200__648536868'
  app/views/accounts/edit.js.rjs:1:in `_app_views_accounts_edit_js_rjs__569940200__648536868'

- Keith
Keith, you're a champ for handling all this QA. We're shifting to a more sensible approach to releasing features in future so bugs should be fewer on the big features coming soon. A bug like inability to edit highlights the need for our CI to have a few tests for this kind of basic functionality. It shouldn't be possible for us to break that functionality without breaking the teat suite.
Agree, I will start writing some integration tests to cover these features. These tests will automate a browser to make sure that things like edit forms work correctly.
More than happy to do QA! I want to move us to using ffcrm for production use as soon as possible, so I'm only being selfish in reporting bugs...

Please do let me know what your plans are for documentation: we'd like to start making a positive contribution rather than just complaining about what's broken, and I believe we can do that by contributing documentation.