Make deleting and comment-adding easier in identification portal

From the identification portal, if you want to delete an ID just after you’ve added it, it requires you to go to open a new tab. Similarly if you want to edit the ID to add a comment within the ID box itself. Can we not have the edit on the drop down menu just open up within the same tab as it does in observations now?

Screenshot 2021-07-15 at 11.55.31

It’s a minor detail across 1 or 2 IDs but when you do 100s it adds up and just seems a needless hindrance.

Deleting or editing comments or deleting IDs are often problematic, unless they are performed immediately (as a means to correct mistyping etc.). The main problem is that the sequence of IDs and comments on a given observation may become hardly intelligible when comments are heavily edited or when parts of the sequence are missing.

So any agreement with the proposal put forward here should be associated with clearcut restrictions.

My proposal is that while these operations of deleting or editing could certainly be simplified, they should be authorized only for the last ID or comment in a sequence, that is until no other ID or comment is added by someone else in the observation.

1 Like

I’m still out of votes, but it’s a perfect proposal, opening more tabs all the time is very tiring!

3 Likes

@odole
Not sure I wholly understand what you are saying.
But there is nothing in play at the moment that restricts deleting or editting in the way you describe in either portal and I don’t see how the restrictions you mention would be that beneficial tbh. Most people have common sense around what they delete or not as far as I can see. Atm editting and deleting is just more time-consuming in the identification portal than elsewhere (the place where ideally it would be the least time-consuming ).

For me, as an identifier it’s also not so often I revisit an observation through the identification portal as you seem to describe. If I come back to observations down the line ( e.g. because someone has commented on my ID ) … it will almost always be through clicking a notification - which will take me to the observation portal from where I can delete or comment without having it trigger a new tab. Any deleting or commenting I do within the identification portal is almost always performed immediately.

Are you saying you are against parity between these two spaces?

I also wouldn’t agree with the solution to the issue you mention ( if it is even an issue, which I’m not convinced of! ). But I think a less limiting way to deal with a potential lack of clarity in a timeline would just be to keep the edits accessible, in the same way the edits on forum comments are saved and can be seen. Anyhow - this is quite a different thing to debate imo.

2 Likes

I agree that would be best, but I suspect that the observations web page is not easy to modify that way (I tend not to agree with your “just” term…).

Normally I would withdraw instead of delete to preserve the “id record”, but increasingly I’ve been running into a major issue when using a touchscreen to select an id from the pulldown (in Identify modal).

If id’ing plants coarsely to Magnoliopsida for instance, simply typing d for dicots and tapping Magnoliopsida onscreen from the pulldown works fine for a while- until the site(?) decides to start parsing that tap location randomly as eg, Anisoptera, Diptera or Anatidae (which are “d” choices themselves, but not at the screen location).

I haven’t yet figured out the triggers for when it’s going to start acting up or get back to normal selection. So when the behavior gets real bad, this feature req would be most welcome!

2 Likes

Yes I typically only use delete in the moments after the initial ID.
Usually when I can’t recall the ID at the time but then it comes back to me a few observations later.
Or realise I’ve made a mistake and have been hasty in making it overly coarse or overly specific.
I don’t feel leaving the ID there to preserve history in those cases is particularly important.

I totally agree though that leaving a record of an ID in other circumstances (over a longer period) makes sense and can be important in keeping the sequence of IDs and comments coherent.

1 Like

I also often make ID mistakes - mistakes meaning typos or clicking on the wrong choice - when using Identify and get annoyed that it’s difficult to delete that mistake, so I’d be for this. I think in those cases deleting an ID is not particularly harmful.

3 Likes

If you make a mistyping/clicking mistake for an ID or mistype something in a comment, there is no problem in deleting it, but why would you do it if someone else has added something below , in many cases addressing your mistake ?

If that happens, why would it be a problem to keep your mistake visible ? You would still be able to withdraw it (if it was an ID) or to correct or clarify or further comment on it with some text (if it was a comment). Such a possible comment could be “sorry, I did not realize this obvious mistyping soon enough”.

Nobody is saying you would or should.
I think you misunderstand this feature request.

In the instance you mention, I would agree you should leave your original ID and withdraw it to retain evidence. As mentioned though, I would deal with this in the observation portal following a notification. There is nothing in this interface which limits you from deleting if you choose.
Whereas the interface in the identification portal makes it more difficult.
I am just asking for parity between the two interfaces.

1 Like

Why a misunderstanding ? I am asking to put a constraint on both features concerned by your feature request.

The above is the current feature request.

This should be submitted as a separate Feature Request, since this would affect the existing Observation Detail view, as well as the proposed change to the Identify interface.

3 Likes

Because nobody checks new ids in identification tab, no human goes there to do that, they open notifications and open observation itself. Anyway there should be nothing that could stop you from deleting anything you added.

1 Like

Except that it would be very useful for the benefit of others to leave a trace that something was deleted, with the maximum information that you would gracefully authorize.

As staff said about deleting accounts that user always will be able to delete it all, it probably affects ids/comments, when I delete something community shouldn’t care, deleting is not adding, so you can’t really screw something with it if we talk about ids, with comments it’s more complicated, maybe if there were comments from multiple individuals, trace should stay of one deleted, but still there’re so many accidental or just plain wrong (and obvious for author) things added, why we need to see it at all and take storage place for it?

1 Like

I will create a feature request and hopefully there will be a solution to all possible concerns. This point is quite critical.

1 Like

Will do. Thank you for the very clear summary.

1 Like

Just adding that I can’t guarantee that such a request will be accepted, because

is correct. Staff have been emphatic in the past that they will always allow a user to completely delete any or all of their content. But they have also been open to finding ways to anonymize content, which might be a solution to your concerns.

3 Likes