Not an urgent issue, but when taxon swaps are performed the removed ID history becomes overly dominating and I imagine, to newer users, quite confusing. I want to request that it could be a little more subtle. There are more extreme examples but :
I think this could be minimised. I’m not convinced the previous taxon swap IDs need to be wholly shown. Couldn’t it just say “Replaced as part of a taxon swap with Norellisoma spinimana” and delete / replace the old IDs ?
UPDATE:
If it’s essential there is history beyond the last taxon swap implemented, full taxon swap histories could open in a new tab when one clicks the existing taxon swap hyperlink.
Or, it could even not mention any previous nomenclature at all on the observation IDs and instead just say something like this:
i imagine that over time, there could be identifications resulting from complicated chains of taxon changes, and i’d like to be able to see the full chain. i suspect it’ll be easier to see the full chain if the ID history is displayed as it currently is.
There are ways of providing access to a longer taxon swap history without having it all taking up lots of space. This future scenario just sounds even more needlessly messy, confusing for users and in need of resolution to me. It becomes even more complex when you intersplice other user IDs which aren’t affected by taxon swaps into the picture.
I agree the history should be visible somewhere - but there is no need to show all the text and use all the space it uses at present.
Longer taxon swap histories could just be
…collapsible
…or visible via tool tip.
…or it could just show the last swap on the observation.
…and/or it could show the previous taxon swaps via link to them in a new tab of taxon swap history
…or a long list of other design interventions which would minimise the space dedicated to this in standard observation view
The vast majority of users will not be aware enough of the taxonomy for everything they observe to need this detail. I can’t think of a time in my history on iNaturalist thus far where having this information on immediate display has been of particular importance.
For you @pisum, this is the optimal presentation of the taxon swap history for an average viewer? There is nothing you would change and no other way you could imagine it presented?
ideally, i would mark the first set of withdrawals as resulting from taxon changes, but otherwise, for me, this presentation of the activity timeline is at least as good as any other. in my opinion, where it suffers from lack of compactness, it makes up for in completeness and contextual / temporal clarity.
when you try to merge identifications together – especially when there is other activity like comments mixed in there temporally – you have to make various design choices, each of which comes with pros and cons. for example, in your mockup (the second screenshot in the original post), you’re effectively choosing to show only the latest (post-change) IDs while eliminating the original IDs. so if there were comments that occurred between the initial IDs and the taxon changes, in your proposed design, then the comments probably would be displayed out of order / context in reference to the IDs. and if there were comments/notes embedded in the original IDs, it’s not clear to me how your proposed design would (or would not) display those notes.
i understand why you’re interested in decluttering the activity stream, but i don’t think your path to achieve decluttering (merging / eliminating IDs) is necessarily the best solution here. there are probably other ways to declutter that will better preserve context in the same view. i suspect the kind of design that would achieve that best would involve optional filters on the activity stream (ex. show current IDs only, show only activity with comments/notes, shrink withdrawn IDs, etc.), but i’m not sure…
Placement of comments from original IDs are an important point - but I’m not entirely sure what you are referencing. There would be no merging of IDs as the IDs wouldn’t be split in the first place (?)
I would argue retaining comments as well as taxon swaps within the original ID frame would add clarity and this is just another reason not to automatically split the IDs in the first place.
To be clear, I am not proposing a single solution per se - as I said, I think there are a host of options as to how to better it. I just wanted to broadly request a reduction in space allocated. I can update the original request if that is unclear atm though.
my opinion is that if you’re going to have a feature request, you need to make it specific. i don’t think you can have a very productive conversation on a request that is not well-defined or is shifting.
for example, i could make a feature request that would be something to the effect of “make the observation page faster”, but without a specific idea or set of ideas about how to do it, i’m not sure how that kind of request would lead to much action.
now if you want to brainstorm ideas for reducing space, then i’m not opposed to that, but i think that should be done as a general discussion first rather than immediately as a feature request.
i think this is technically a very different proposal than “reducing space”. if i’m interpreting what you’re saying here correctly, this would effectively change up the entire identification data model to include a history within any given identification. i suppose that’s doable, but it seems like that kind of thing would be super super complex, with lots of tentacles reaching out to many parts of the way the system works.
I’d argue your example is totally different…and that thrashing out finer details of feature requests within requests, as well as offering a range of solutions to a problem…has good precedence. But… this is tangential to the topic. I have updated the original request to add clarity and will try and be more thorough in the future.
just think about how you would capture identifications in a table structure. right now, each identification – including ones resulting from taxon changes – is captured as a row in an identifications table. the activity stream merely displays each record in the table as a separate item in the timeline.
the way i read your original proposal, the way the identifications would be captured in the table would not be changed, but the activity stream logic would be changed to exclude some of these rows from the main timeline, attaching them to records that were not excluded and potentially overriding the display of data from the included records with data from the attached excluded records.
but if you’re saying “IDs wouldn’t be split in the first place”, then to me that sounds like you’re proposing to not capture taxon changes as separate identifications in the identification table. so then only the original identification would be retained, and its taxon and update date fields would be updated. but then to preserve history, you would have to create a separate identification taxon change history table that stores each change. this shifts some of the burden of history consolidation from the code that delivers the data to the code that records the data. it probably doss make getting the data in a consolidated format easier, but that complexity is still there when you go to record the data. so you’ll have to change a lot more stuff to go down this road, and it’s not clear to me that this provides a huge benefit.
i’m not sure i’ve explained this properly, but if you don’t understand what i’m saying here at this point, i think you would really have to just go through an exercise of trying to create a table or tables that show how you would keep a record of identifications and changes to identifications resulting from taxon changes, along with how you think the system is storing that data now. if you end up with two different very different table structures, i think that’s asking for a lot of headaches.
Ok, yes, this is closer to how I imagined it I think.
I’m not sure I understand the necessity to preserve the nomenclature history for an individual ID. Why do you need a “separate identification taxon change history table”? Couldn’t one just replace the name on the original ID, tag it as having been affected by a taxon swap at date X and not preserve the history of the specific ID nomenclature? The link to the history of the previous nomenclature is visible on the taxon swap page for those who need to dig deeper.
Otherwise, if a more direct relationship to the history is essential, I would have imagined the exact history of each taxon change need not be connected to a separate table but could rather just point to a single shared taxon swap history table belonging to the taxon itself, not the observation ?
because you could have a chain of taxon changes that affect the original ID. if you just capture the latest change, you won’t capture the whole chain. theoretically you could try to trace back back by looking at when the ID was made originally and then try to work back through all the taxon changes, but the taxon changes don’t necessarily affect all IDs at the same moment, or even all IDs (in some cases where there’s a failure somewhere). if you need to research or roll back changes, it’s really hard to do that if you don’t keep a full history of changes at the ID level.
Ok, still not sure we’re on the same page… why separate, why not point the IDs to the single shared taxon history table which stores the full chain ? The date of the original ID should provide a clear reference point on the chain to indicate which historical taxon swaps impacted it.
because [see the second half of my previous reply].
there are lots of potential cases, but just suppose you take 2 species A and B and merge them into C. suppose you have an ID that is recorded on C post-merge. if you don’t have an ID-level history of taxon changes, how do you tell if that ID was originally recorded as A or as B?
How are merge histories stored at the moment?
In your example, couldn’t the link in a taxon merge be specific to the original ID?
e.g.
A will change to C but the hyperlink to the history could link specifically to the history from perspective of A. …whilst B will change to C but the hyperlink would then point to the history from perspective of B?
In any case, if this approach is indeed insurmountable from a coding perspective, then I just propose the taxon swap IDs retain their structural representation but their visual representation to the user is altered - e.g. hidden from view by default with options to toggle visibility (as you mentioned)…or nested somehow within the original ID.
think about what you’re describing here. it sounds a whole lot like capturing change history at the identification level to me.
it’s not a matter of whether it’s insurmountable. it’s a matter of whether the cost of a particular solution outweighs its benefit. i think the main goal of what you’re talking about here this thread is just decluttering the activity stream. trying to approach this by making fairly fundamental data model changes is going to have the highest cost because it would affect so many other things, and it’s not clear to me that this kind of approach offers any benefits compared to other alternatives for decluttering the activity stream.
earlier, i mentioned that providing optional filters for the activity stream might be one way to approach this. i think another way to approach this is to provide a companion table that summarizes the current identifications. i suspect that something like that could provide the compact view of identifications that some might be looking for. for example:
Ok - I think there were just some crossed wires on this discussion.
In any case - to be crystal clear on my POV to any who read, I am not proposing “fundamental data model changes” - just a shift in visual representation of that which already exists structurally. If the structural setup remains the same, the visual output can still be varied in any of the ways I originally proposed as far as I can see. This would be my (perhaps crude) understanding of how any implementation would work - what we see visually is just an arbitrary representation of the structure itself. If a taxon swap is performed then this updates something structurally… but visually to the user this action could trigger a new visualisation of an ID… an alteration to the existing ID…an update on a separate page… or a small unicorn to jump up and down on the home page. It shouldn’t matter what the specific visual output is - the structural methods for dealing with the actual data behind it all will remain the same.
I find that taxon swap display so untidy - have deleted my multiplied IDs from a post.
The info needs to remain accessible for curators who need it - but I would prefer not see the is, is not, battled out.
I only need to see old name once and new name from taxon swap once.
Perhaps we could have a setting to toggle on and off.
