Custom fields

[issmirnov]

A core challenge of any product is that every user is different, and if you satisfy all of them you face feature bloat. I'd like to open the floor to dicussing the idea of implementing a modular metadata system for person records.

Ultimately, every user of the app has different metadata they care about. Additionally, within a single user account you have different types of people: family, coworker, gym buddy, etc. It doesn't make sense to add the "favorite workout" or "job title" field to every single person. As such, I feel it would be a neat solution to allow users to add templates for people. As long as the core UI framework is capable of supporting the different types of values, from a developer standpoint your work is done.

In my opinion, three types of metadata inputs are enough:

1. free form text - for notes and general musings.
2. lists of strings - groups of people the person belongs to, food allergies, favorite bands
3. key value pairs - wife's name, dog's age, birthday date, etc

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

What do you think? It makes the API a bit more complex, since you have unstructured data, but ultimately this provides freedom to all users to manage data the way they prefer.

[Kovah]

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

id	name	surname	...
1	John	Doe	...

contact_meta

id	user_id	key	label	value
1	1	phone_number	Phone Number	123 555 456
2	1	cat_name	Cat Name	Mr. Charles
3	1	food_dislikes	Food Dislikes	Fish, Beans

[djaiss]

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.

[ocdtrekkie]

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.

[issmirnov]

@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?

[Kovah]

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();

[Nebucatnetzer]

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.

[Nebucatnetzer]

@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: https://github.com/monicahq/monica/issues/79#issuecomment-306728877 correctly the information would be unique to the contact.

[Kovah]

@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

id	name	surname	...
1	John	Doe	...
2	Jane	Doe	...

custom_fields

id	key	label	value
1	phone_number	Phone Number	123 555 456
2	cat_name	Cat Name	Mr. Charles
3	food_dislikes	Food Dislikes	Fish, Beans

user_custom_fields

user_id	custom_field_id
1	1
1	2
2	2
2	3

[Nebucatnetzer]

Yes, exactly. This way you could record all the cat names for each contact without having to rewrite the fields each time.

On 13/06/17 15:31, Kovah wrote:

@Nebucatnetzer https://github.com/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|

id name surname ... 1 John Doe ... 2 Jane Doe ...

|custom_fields|

id key label value 1 phone_number Phone Number 123 555 456 2 cat_name Cat Name Mr. Charles 3 food_dislikes Food Dislikes Fish, Beans

|user_custom_fields|

user_id custom_field_id 1 1 1 2 2 2 2 3

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/monicahq/monica/issues/79#issuecomment-308116486, or mute the thread https://github.com/notifications/unsubscribe-auth/ACLmdTEPXjWXk8prLaOTL4Fr5gdQzZdIks5sDo8agaJpZM4NyT0Q.

[jeremydenoun]

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

[djaiss]

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

[djaiss]

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

[djaiss]

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.

[jeremydenoun]

Can you consider a placeholder value ?

[djaiss]

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

[jeremydenoun]

Default value appear more usefull but both can have sense

[djaiss]

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.

[jeremydenoun]

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)

[djaiss]

@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.

[jeremydenoun]

so this is perfect ^^

[luisfavila]

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

[djaiss]

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

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

[wunter8]

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?