Custom fields about monica HOT 23 OPEN

I think the first iteration should be pretty simple.

Here what we could do:

• list of fields
  • textfield
  • textarea
  • date
• indicate where to place the component
• indicate whether it's a list or one-time item

I have a problem with the placement of the custom fields. We have several possibilities to place them on a contact sheet

• Below all existing, native fields
• Above all existing, native fields
• Let the user decide. This will lead to:
  • Much more complexity. We would need to let users choose the layout of a contact sheet. I think it's a great idea, but it's a huge feature and would take weeks (if not more) to implement.
  • More settings. I don't like settings at all, but the nature of the product dictates it to be customizable and therefore, with a lot of settings.

In the future, we would allow new field types:

• dropdowns
• booleans
• ability to add automatic reminders
  But this is like v3.

Initial design:

One more thing: in the initial comment, there is this paragraph:

Common patterns can be combined into templates, such as "coworker" or "gym buddy", and selected when creating a new person.

This is an excellent, excellent idea, but will greatly make more complex the codebase as well as the product. But I'd like to make it happen.

from monica.

At the moment all contact information is saved directly in the contact table. I would rather move all meta data to a second model e.g. ContactMeta. This model may only have a key, a label and a value besides the contact ID.

This would allow the app to store unlimited and very flexible meta data for contacts. The app could provide some standard labels for the meta data like telephone and so on. But the user may also add a custom label and name it 'Food Allergies'.

contacts

contact_meta

from monica.

Using Laravel relations it couldn't be easier to run any type of queries.

$contacts = Contact::whereHas('contact_meta', function ($query) {
    $query->where([
        ['is_developer', true],
        ['cat_name', '<>', ''],
    ]);
})->get();

from monica.

You are talking about custom fields here, basically. I like the idea but the implementation can become incredibly hard if not done well. Before we do anything about this, I'd like to discuss the concept further. Thanks a lot for the discussion though I'm super excited about this.

from monica.

I would highlight that in many cases, it's preferable to only use custom fields for stuff that the app has no intention of doing anything "smart" with. Aka, stuff users choose to add themselves. Any sort of sorting or searching is a lot less complicated on normal tables.

from monica.

@ocdtrekkie What are the smart processors enabled so far? Looking at it from the perspective of a user journey, I can think of the following queries:

1. People I met last year in California
2. People who work as developers and have cats
3. People who go to the gym, and dislikes Tofu

Each of these seems like you could have a mapping of the query to the potential metadata. Using your contact_meta sample, the queries then become something like this:

1. People I met last year in California (unchanged, location part of core meta)
2. select * from contacts as person where person.contact_meta has cat_name (we then perform a proper join over the contact_meta field, obviously this query is simplified)
3. (same as 2, but with different meta field)

Do you all feel this is feasible, or would be too cumbersome to develop?

from monica.

Custom fields would be useful.
However it can probably a bit tricky if there are too many and if we limit it
there will be for sure a person who would like to have more than the
maximum allowed.

As for the standard type I wouldn't add more than the current ones and probably
even remove the social media links.

from monica.

@Kovah wouldn't it make sense to create a new table for custom fields so that they
can get reused by other contacts?

If I understand it correctly your suggestion here:
#79 (comment)
correctly the information would be unique to the contact.

from monica.

@Nebucatnetzer Could you specify what you mean by reusable? Do you mean that values like cat_name => 'Mr. Charles' should be unique and sharable between users?
If yes, sure you could easily convert that one-to-many to a many-to-many relation and may safe some database rows.

contacts

custom_fields

user_custom_fields

from monica.

from monica.

For help with this subject maybe we can add to scope :

• bool field (yes/no)
• "mandatory" custom field

I think we can inspire from e-commerce product editor and be careful with :

• edition/deletion process
• migration consistency

from monica.

Feedback from user. This gives an idea of the type of information he wants to store

Some other things I have in my spreadsheet are:

• Activities which this person likes/which are a good fit to do with (e.g. hiking, playing videogames, talking about the meaning of life, etc.) and doesn't like/are not a good fit to do with
• Political opinions (I created this column but never used it, in fact)
• Topics this person likes to talk about, topics they don't like to talk about and topics it's better to avoid talking about
• Music they like and don't like
• Things I appreciate about them and things I don't appreciate much about them (including good things they do/have done for me and things I'd better remember, for example if I anticipated money for them for a present to a common friend and they didn't give me the money in the end)
• Nicknames

from monica.

Another feedback

I need info like family, ocupation, recreation, dreams, fears, etc and fill that fields as soon as I I know better that person. I see I can choose only where is employed, but I would need more for example, witch groups is a member, more entry data not just linkedin. And I would need a field to choose if this person is a part of my family, a prospect, a client, a business partener, an influencer, etc

from monica.

Can you consider a placeholder value ?

from monica.

@jeremydenoun you mean a real HTML placeholder? Or a default value?

from monica.

Default value appear more usefull but both can have sense

from monica.

Feedback from various users:

With that said, I can't say I identify with your use cases for the custom fields. Part of the problem is that the people in my network are diverse. It's hard to think of fields that are relevant to a large chunk of them. Sports teams... maybe. But I would probably just write that as a note. I'd prefer more work on improving search to be a full text search, a way to log past/multiple companies, a way to link a child across both parents' profiles without having to create a separate contact, or Gmail address book sync. These are all features that are more directly useful to me.

I probably would not use custom fields. The default fields cover everything I've needed and anything custom is usually specific to an individual person, in which case I put it in that person's log, or if it's an important pattern it ends up as a tag.

I don't think I'd use that feature. Just have a big 'notes' textarea field and let me type whatever (you probably already have this. I can't remember).

The custom fields sounds too complicated to me. I just use the Notes field to add important information about the person (favorite sports teams, activities they like, etc.). Maybe I don't see the advantage to having the custom fields over using the Notes field. Could it be so that you can search by custom field more easily? For instance, to search for all of my contacts who like the San Francisco Giants? Not sure I would need that feature. Or maybe it's just to display the information in a cleaner more consistent way? If that's the case, then I'm not sure it's worth the development hours.

I think I would not use the feature you are describing. I think most of my relationships do not share enough similarity to have a pattern for the fields. I think the simpler version, where I can define a custom field (like Political Opinion), then apply that field to contacts I choose, would be powerful enough for my needs.

from monica.

AMHO they miss real power of custom fields, if we easily imagine advantage to structure the data (filters, compute, sort easily)

if you add APIs capability on it... this open external plugin compatibility and third-party apps to others developers... I imagine application like smart social link finder and I think my contact manager shouldn’t lock me with fixed structure or impose to use a single unstructured text fields like database..

Finally this kind of behavior is implemented into reference protocol (VCard) since some decade (https://tools.ietf.org/html/rfc2426#section-4)

from monica.

@jeremydenoun when we'll have custom fields, everything will be available through the API as well. I don't want any data that can't be manipulated by the API in some ways.

from monica.

so this is perfect ^^

from monica.

I see the PR was closed. Has this been discarded? @djaiss

from monica.

I see the PR was closed. Has this been discarded? @djaiss

Yes but actually no. Work has started again on this.

from monica.

I see that "work started on this again" almost 4 years ago and that the "tasks" feature was added in March and referenced this feature request. I think custom fields would be helpful outside of just "tasks", though. Are custom fields still going to be added?

from monica.