Open brucejackson opened 2 years ago
Yes, you're right; this applies to all the "secondary objects" in Gramps that can have notes and attributes: media references, event references, child references, repository references ... in Gramps' data model, there are even crazier things like notes for attributes. While it's great to have that flexibility, I find it very hard to come with an intuitive UI to display (let alone edit) that information. Any ideas?
Thanks for the link to the data model. I will go through it and the ui and try to come up with some ideas that we can look at.
On Thu, Sep 30, 2021, 13:45 David Straub @.***> wrote:
Yes, you're right; this applies to all the "secondary objects" in Gramps that can have notes and attributes: media references, event references, child references, repository references ... in Gramps' data model https://www.gramps-project.org/wiki/index.php/Gramps_Data_Model, there are even crazier things like notes for attributes. While it's great to have that flexibility, I find it very hard to come with an intuitive UI to display (let alone edit) that information. Any ideas?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/DavidMStraub/Gramps.js/issues/29#issuecomment-931533156, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJJTVIK6FQASJ6LXJJFVRDUESO35ANCNFSM5FCQUXAA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
I tried to take a pass at doing that with the view I was playing around and experimenting with. You can find it at https://github.com/cdhorn/profileview
It is misnamed, should probably call it linked mode since the idea was to be able to navigate across all the objects to be able to view and edit anything.
Secondary objects that contain other secondary objects like the event reference above kind of throw a monkey wrench in the navigation. I kind of set it aside when I hit that to take a break for a while to spend some time on other interests. Hope to get back to it in another month or so.
This is my first thought about an approach (without yet looking at the ProfileView gramplet). I'm going to use the same data as above for simplicity.
Starting at the Event Tab for a person (https://host/person/I0394). I have Increased the size of the icons so they can be activate links. I changed how the table is linked. For each row the columns Date, Type, Description, and Place all link to the Event. The icons (photos, notes, etc) link directly to a Tab within the Events page (e.g. the photo icon leads directly to the Gallery tab in the event). I have added an icon, details (). This icon links to the EventRef information for this person.
I have mocked up the concept of the page to show the EventRef (https://host/events/E2129/person/I0394). The title of the page is written to try and illustrate that the tabs below reflect the information specific to the participant at this event.
I've created this example by editing the text in the my browser's developer tools, this is why the blank tabs are present - please ignore them.
Here are some real mock-ups for presenting the Event Reference. The first image could be the main view. The second image attempts a drill down to see the details of an attributes. I would see the Person name and Event Title linked to the appropriate pages. I'm trying to give the user context about the attributes by prominently showing the Person and Event. I am hoping this layout is extendable beyond this example to other Secondary Objects.
Main View
Drill down to Attribute Details
Thanks @brucejackson, great mockups & ideas!
What I would really like to avoid is having to have views with dedicated URLs for all the secondary objects. This would complicate the routing and I don't really see the necessity of deep-linking an event reference. Moreover, I am pretty sure for many people (e.g. myself), almost all of those pages would be completely empty. Actually, the reason I'm note using notes/citations on secondary objects is because I find them hard to find even in Gramps desktop!
In general, I also think we have to be careful to avoid mapping the Gramps data structure directly onto the structure of the user interface/navigation.
For instance, whether the note or citation above is attached to the person, the census, or the event reference is in my opinion a subtle difference. And it's great that Gramps is so powerful that we can make these subtle distinctions; however, in a web app, I think we should assume that the average user (~ my aunt) is not familiar with this data structure and these subtleties and will expect this information to be shown along with the primary object (in that case person) they are looking at.
I really like the idea of indicating the existence of event reference details in the event list view. I can think of the following possibilities, which would not require a new page/view/URL:
I agree that a lot of these pages would be blank. In my case, most of this information was populated by a Gramplet.
The cases where I know (and remember) that I add notes in secondary objects relates to Citations. For example, if I attach a death certificate of a child to the birth of their parent to demonstrate something about the parent (e.g. place of birth). In this case, I add a note to remind myself why this citation is used.
Thinking through ideas you've outlined. My preferences would be, in order: 3, 1, 2. Putting 3 before 1 is just because I'm not a big fan of pop-ups (purely a personal preference). When I try and visual Idea #4, it feels like information would be more fragmented.
Ok, I looked at the data model and the API to understand how many of those object types we have to implement if we want to cover all of them. I found the following:
Person/Family → EventRef → notes, attributes Person → Name → citations, notes Person → PersonRef → citations, notes Family → ChildRef → citations, notes All → MediaRef → citations, notes, attributes Source → RepoRef → notes ... → Attribute → citations, notes
It's amazing that attributes themselves can have citations and notes. What if someone adds a note to an attribute of and event ref?
What I also realized is that in the API call for a person with ?extend=all
, that is currently used to fetch (almost) all the info required for the person view, we don't have the details of the secondary objects (citations, notes, attributes), only their handles. In that case, having a collapsed detail view in the table is not that nice because expanding the element is not just a CSS operation but requires fetching data from the backend. So having a modal might make more sense.
Attribute is messy because SrcAttribute for Sources and Citations does not have notes and citations while a regular Attribute does. So the meaning of Attribute has basically been overloaded, and I think use of SrcAttribute would have been better for EventRef and MediaRef objects.
The Gramps view I have been experimenting with takes the 1 page per object approach and this misuse of Attributes greatly complicates history tracking for navigation. Kind of made me step back for a while hoping when I get back to it I'll have a fresh set of eyes and different perspective so the discussion here and both of your thoughts as to how to handle this in Gramps.js are of interest. I think you are right that using modals makes more sense.
Did you notice another issue in the Gramps model is with EventRef as it is missing citations? Every peice of information should have a supporting citation and it is the EventRef and not the Event itself that tracks the fact the Person participated in the Event and the role they played.
Update: EventRef will have citations starting from 5.2.
The UI for many of these objects has changed since the issue was raised, current status:
I am using the Forms Gramplet to capture Census Data. The Gramplet creates a single event that is shared among all household members. However, details about a specific household member are stored in the Event Reference Attributes (see image). The attributes are not visible in gramps.js. I believe these attributes are stored in the person data and not the event data.
I would be a nice enhancement is these attributes could be seen in gramps.js.
Thanks, Bruce