URLs (aka web addresses) of any pages, if relevant:
Description of need:
In the Identify module, some people prefer to start at a higher-numbered page and work back to page 1 to avoid issues with the observations shifting if one has not ID’d every observation on a page or marked all as reviewed. (Discussed, e.g. here and the linked threads)
The pop-up that appears when one has looked at the last observation on a page provides several options: mark all as reviewed, see more unreviewed, and go to next page. If one wants instead to go to the previous page, one must close the pop-up, scroll down to the bottom of the page, and click on the left-pointing arrow or the number of the previous page. This is, to be sure, a relatively minor inconvenience, but it disrupts the workflow, particularly for those of us working on small screens.
Feature request details:
Add a button “go to previous page” to the pop-up screen in Identify, analogous to the current button “go to next page”. This would be a fairly minor change to the interface only, since the function already exists (navigation bar at the bottom of the page); it is merely not included on the pop-up screen.
Can’t you switch the “Sort By” to Ascending? Or is there something about your workflow where going to the previous page is different than just working through the observations in the opposite direction?
I have a workflow that would benefit from a back one page button or more accurately a back one page option activated by pressing left arrow on the first observation of the page much like a forward one page is activated by pressing right arrow on the last observation of a page.
I do not like using the reviewed option, because I feel that many of the observations could be worth looking at at a future time, and I never am IDing all of the options on a page.
If I have 100 observations to work through at 30 per page what I would see working forward is:
P1 observations 1-30 , I put an ID on 15
P2 observations 46-75, I put an ID on 10
P3 observations 86-100
As I ID through I never see observations 31-45 or 76-85. I can refresh each page and see piece by piece one extra observation, but it is really impractical.
If I go in reverse order I see
P4 observations 91-100
P3 observations 61-90
P2 observations 31-60
P1 observations 1-30
No matter how many I ID per page.
As long as the search string is below 10,000 working backwards is much more convenient for me because I can see every observation and I don’t have to review observations I don’t want to review to keep my page numbers aligned. It’s not a huge amount of time, and honestly I appreciate having to break my flow to reset pages, but it does affect me in a small way as well.
Sorting by ascending does not solve the underlying problem, which is not about the order I want to see observations in (oldest vs. newest), but the way the unreviewed observations are dynamically reindexed.
As discussed in the threads I linked to, if I only review a portion of observations on a page and don’t want to mark all as reviewed or refresh the page each time before I move on to the next, I will end up skipping observations.
If I ID 10 observations out of 30 on page 1, when I go to page 2 the observations I am shown are not the original 31-60, because observations I reviewed are taken out of the list and the next 10 observations take their place, so I am shown what would have been observations 41-70 and do not see 31-40. Refreshing the page is not efficient, because I am only shown a small number of new observations, and if I ID even 1 of them I would still need to refresh the page again before I move on.
This also comes up when using Identify to add annotations, since it will often happen that some portion of observations (say, life stage for insects) cannot be annotated because there is no applicable option. If one starts at page 1, the remnant of un-annotatable observations will accumulate until there is only one new observation each time one refreshes the page. Here it is quite likely that one might want to include reviewed observations in one’s set, so marking all as reviewed and going on to the next page is not going to resolve the problem.
As a result, some of us start at a high page number and work back to 1, because reviewing observations on a higher numbered page does not change the observations on the lower numbered pages.
There’s a without_ident_user_id url parameter that can be used to find observations where you haven’t added an identification. So a bookmark like https://www.inaturalist.org/observations/identify?reviewed=true&without_ident_user_id=yourid can be used as a handy starting point for re-reviewing (just add extra filters as appropriate).
Personally, I sort by random/ascending and ensure each observation I look at is marked as reviewed before moving on to the next one.
I’m aware of the url parameter, but it doesn’t do anything that isn’t available in Identify anyway, and it won’t stop the pagination from shifting if one reviews/identifies/annotates only a portion of observations on each page, which is what the “start at a high page number” workflow avoids.
For various reasons, not everyone wants to mark all observations we have seen as “reviewed” and there are some activities where one might want to include reviewed observations (annotating) that also results in shifting pagination.
This request is not asking for a change to how Identify works or for a solution to the shifting pagination (I don’t think it can be fixed except by having a non-dynamic list of results, which doesn’t seem desirable). All this request is asking for is the addition of a button to save a couple of clicks in an existing workflow that I know numerous people besides myself use.
Yes, it does - I requested the feature because there’s no other way to exclude observations that have already been identified by a specific user. The Identify dialog doesn’t have an option for that.
But in any case: I did not intend to express an opinion about your proposed solution. I was just pointing out that there are other ways to work around some of the problems and achieve effectively the same outcome.
How would being able to sort for un-ID’d observations rather than unreviewed observations solve the issue of observations shifting in Identify? Any action that takes an observation out of one’s current filters will cause the pagination to shift, whether that filter is un-ID’d, unreviewed, unannotated, taxon parameters, etc.
The fact that observations get removed from the set that one is looking at in response to one’s actions (because they no longer meet the filter criteria) is kind of the point of Identify – one is reducing the number of remaining observations in a particular “to-do” list. However, the removal of some observations just as inevitably results in the observations that are next in the queue getting moved forward, which results in observations getting skipped unless one reloads the page or finds some other workaround such a starting at the back.
The only filters that would not produce such an effect would be filters for characteristics that one cannot change by one’s own actions (for example, filtering for observations that someone else has ID’d, or observations that are missing data, or observations from a certain date), and most people probably do not have workflows that rely entirely on such filters to select the set of observations they want to look at.
There’s no pagination at all with random sorting, so that issue is completely bypassed. When the current random batch is completed, I just view-more to get the next batch. I always at least add/confirm annotations (if appropriate) and then either suggest an identification or mark as reviewed - nothing is ever skipped. If I keep going like that, sooner or later I will systematically work through them all (just not in any particular order). Thus, the queue is treated like a bag, where items are grabbed handful by handful until it’s empty.
At some point later, I may choose to re-review the observations that I marked as reviewed, but where I did not suggest an identification. To do that, I use the bookmark I gave earlier. In the unlikely event that I added identifications to all of those as well, there would be nothing left for me to look at.
The only remaining issue (for me, anyway) is annotations. There’s currently no without_annotation_user_id url parameter to help find observations I marked as reviewed, but where I did not add any annotations. However, I very rarely look at annotations in isolation, so that’s not something I personally miss at the moment.
In the long-run, I think this work-flow should achieve broadly the same outcome as your work-flow. The main difference is that it uses a to-do bag instead of a list.
It’s great that that workflow works for you, but other people may have other reasons for choosing different workflows. Not everyone will want to sort by random, and not everyone will want to mark everything as reviewed when they are done looking at a page.
I do indeed sometimes sort by random, but I don’t always wish to do so. It depends on what I am working on and what my goals are. I use “reviewed” strategically for specific reasons. Marking things as reviewed that I might want to come back to is not useful for me. because then “reviewed” becomes meaningless and I can’t distinguish between “actually reviewed” and “marked as reviewed just to take it out of the pile for now”.
I don’t see why I should have to defend my choice of workflow. Starting at a high page number and working back to page one works for some of my IDing activities and solves certain issues that come with working in the opposite order. I also don’t see why the response to asking for a button that would facilitate a workflow that I (and others) have found to be useful should be that I merely instead need to use some other completely different workflow that would “broadly accomplish the same thing”. It isn’t just about the outcome, but about the process.
The potential usefulness of a “go to previous page” button is not dependent on whether one follows the exact workflow that I do. I can imagine that even people who normally start from page 1 may sometimes want to go the previous page instead of the next page. Again, I am not asking for a new function, just a minor change that would make an existing function more convenient to access.
(Apologies if this is a bit testy, but some of the suggestions feel like solutioneering without fully understanding the workflow I am describing or the reasons for using it – i.e., assuming that it is illogical and would be completely unnecessary if only I were more versed in using the various functions of iNat and Identify. I am not a novice, and I have tried many different IDing processes. I am well aware of how Identify works, including its idiosyncracies. I have given thought both to possible solutions and alternatives and my choices are not random but the result of reasoned reflection.)
Nor do I - and I don’t see that anyone has asked you to do that.
The without_ident_user_id option I suggested is a solution to some re-reviewing issues mentioned both by you and another poster in the thread. (Ironically, my feature request for that option was partly motivated by problems very similar to the ones discussed in your own current feature request).
No problem - but I’m still a little baffled by the personal nature of some of your following comments. I can’t see that anyone has claimed (or even implied) that you were being “illogical” or were a “novice”. I explained my alternative work-flow because you directly asked me about it. I made no criticisms of either your own work-flow or of your proposed feature request, and I don’t see that any of the other posters has done that either.
Except that it isn’t a solution? This is where I don’t follow you. Your url doesn’t eliminate the phenomenon of the list of observations shifting when one goes from one page to the next – because if you ID an observation it will be removed from the results using this filter. All you have done is exchanged one filter (the default show unreviewed) for another (show un-ID’d).
The alternative that you describe requires a completely different workflow in which you sort randomly and mark everything as reviewed. However, if one has reasons for a) nevertheless wanting to go through observations in order or b) one does not wish to mark everything as reviewed or one is filtering to include both reviewed and unreviewed (as one might wish to do when annotating), this is not really a solution at all.
Perhaps my initial presentation of this request was misleading: I did not create this request because I wanted a solution to the issue of shifting observations. I already have a pretty straightforward solution that requires only a minor adjustment to the order in which I work through the pages (start at the back instead of the front). I mentioned my workflow because it is the context that led me to want a “previous page” button, and because I know there are other users who also start at the back for similar reasons and therefore might also appreciate such a button (i.e., it is not just limited to some personal idiosyncratic use of iNat).
Given that I have a method that I am satisfied with and my request was based on wanting to make it work a bit more smoothly rather than wanting to replace it entirely, suggesting a completely different workflow as a solution feels somewhat beside the point – unless one believes that my method is indeed not effective and it would make more sense to do something different instead. Probably not your intention, I’m sorry, but I didn’t expect that the idea that one might choose to start with higher numbered pages was something that would need explanation in the first place.
I don’t really have anything to add to my previous posts, which explain my intentions clearly enough. As I said earlier, I don’t wish to express an opinion about your proposal - but good luck with it anyway.
Sometimes when I am working backwards (up the page instead of down), I get to the top and I hit the left arrow key and nothing happens, and it takes me a moment to realize that’s because I have reached the top of the page. I expect it to work the same way it works when I am working in the other direction, because why shouldn’t it? Then I have to scroll all the way down to get to the arrow keys to go back manually, which is not a big deal, but it would be nice not to have to.
Why I am working backwards doesn’t really matter. (Sometimes I just feel like it!) It looks like it ought to work the same way going backwards as forwards, and it’s surprising and counterintuitive that it does not.
Really this is a pretty trivial concern, more of a minor annoyance than an actual problem, but also it seems like it would be really easy to fix.