Add the Groups to the People View

[voronwe]

Hi
As I started with the Face recognition and added Persons there, you can put each person to a group.
But I could not find a display of the groups in the People View, there is only one list of all people.

It would be nice to if there is a way to group these people , so that you can see e.g. only the members of a familiy.

Bonus: Having the possibilty to add subcategories for groups (like the normal category folder) and having the possibilty to add a person to more than one group.

Greetings

Thorsten

[Mario]

One of the leading ideas of the People View (and all "people features") was simplicity, without becoming too "Apple-ish" and reducing features to a minimum to not confuse the user base

The ability to add a person to a group allows you to color-code persons easily, and to quickly search for persons in a specific group.
When you search in the People View by the group name, you can quickly locate all members of a family (assuming you are using groups to denote families).
Using groups to manage families is not necessarily ideal.

At this point, I'm not able to say if, and how, the People feature will evolve in IMatch 2021, or which features/properties are added in this area of IMatch.

[voronwe]

Hi Mario

ok, I see this is not the highest priority.
However, this sounds to me like something for an App (which I could try to write).

As far as I see, the Person-DB is connecte to a General-DB, isn't it?

And I saw that it is possible to export the Person-DB as a JSON-File.
Is this JSON-File only for internal use in IMatch, or is the idea behind this that it can be used by external application?
Meaning is: If I use this file, can I expect the Data-structure to be stable or can it be changed without notice in future releases?

It seems to me, that, when reading this JSON to an existing IMatch-DB, it only imports new persons, but does not update the information of allready existing persons? Is this correct?


Reasons behind this questions: An Idea came to my mind to combine this Person-DB with an external programm, which also stores the relations between Persons (e.g.  a program for genealogy)
And also having an App which can sort the persons by Groups or Keywords.

Thinking about this, the only feature Request so far would be to have the possibility to add a Person to more than one group

There is nothing detailed planned so far, I'm just thinking...
I took a look into the description of APP-Programming, but so far I did not find the API for the Persons-DB (reading out the whole Person-DB, select one or more Persons, change Persons data)

Greetings

Thorsten

[Mario]

The import and export feature uses a JSON file, correct. But the structure is undocumented and subject to change without notice.
New IMatch versions bring enhancements for the people and event features and I deliberately don't document the JSON format so I don't have to version it and keep external documentation up-to-date and also versioned.
That said, JSON is a pretty easy to understand and manageable file format.

The same applies to the IMWS endpoints related to people and events. They are changing frequently and not having to keep them stable, documented and backwards compatible gives me a lot more freedom and allows for faster development cycles. If many users would write apps, I would invest more time into this. But not many users write apps.

Why don't you use groups as families? Do you have to many different families to manage that this is unfeasible? 10 or 20 families can easily be managed via person groups.

[voronwe]

The import and export feature uses a JSON file, correct. But the structure is undocumented and subject to change without notice.
New IMatch versions bring enhancements for the people and event features and I deliberately don't document the JSON format so I don't have to version it and keep external documentation up-to-date and also versioned.
That said, JSON is a pretty easy to understand and manageable file format.

I know that it quite to understand, and normally a well structured JSON (like your one) does not need a documentation of it's own.
My question was more into the direction whether I can rely on the structure or whether I have to rewrite the Parser with a new Update of IMatch

But as I said, as far as I can see, allready existing Person were not updated when I changed the JSON and reed it back (at least not for the Name of the Person), so this seems to be a dead-end-way.

But this came to my mind, so maybe I will try to dig myself into the App-Programming

Why don't you use groups as families? Do you have to many different families to manage that this is unfeasible? 10 or 20 families can easily be managed via person groups.

Please do not stick so much on families, that was only an example. Normally, people are organised in Groups, like Families, Companies, clubs, and espcially with clubs, they are members in more than one.
So it would be nice to say a person is Member of Family A, Company B and Club C and D
BTW: I found out that it is also possible to add only profession: There are people who have more than one.

I understand your point that you want to keep the Person view as simple as possible, but having only limited possibilities for grouping make it confusing when having a database with a lot of people (Well, of course, thats why we use IMatch to handle big databases  )
It could be done with the keywords, but somehow that doesn't sound right.

[Mario]

I understand your point that you want to keep the Person view as simple as possible, but having only limited possibilities for grouping make it confusing when having a database with a lot of people (Well, of course, thats why we use IMatch to handle big databases  )
It could be done with the keywords, but somehow that doesn't sound right.

This is my view: Since releasing the people feature in February 2020, not one user requested more than one profession, families, teams, groups, corporations, parties or whatever.
The design of the people feature is extremely flexible, but I don't put work in where it is not needed.

Naturally, there are a small number users who may have additional requirements. But, my impression is, the current feature set apparently satisfying for the majority of the user base. Which is perfect.
I don't say that I don't have plans for enhancements, but the thing I've learned is:

People like simple.
Not too many options.
Not too many choices.
Do not complicate things for the majority of users just in favor of the odd chance to be able to handle specific use cases or scenarios encountered by a small number of users.

For example you can always enter "Doctor, Physicist, Chess Master and member of the council" for the occupation of a person. No real need to have multiple choices or inputs...

This feature request board contains literally tons of feature requests which have many views, but not a single comment or +1.
Which basically means that only the posting user cares for that feature...

[novaca]

+1

[voronwe]

Hi Mario

playing again around with the People view, I have at least one other request:

Could you make it possible to add in the search for persons the "Erweiterte Suche", so that keywords like AND, OR etc. can be used?
I mean the "Nach Personen suchen ..." at the top of the Person View.

This would be quite helpful to filter Persons