tab: identifications and species counts table row format

[synrg]

michaelpirrello asked if number of identifications can be added to the [p]taxon embed, just like we currently have number of observations.

Edit: see later comments where this has morphed from a request for [p]taxon functionality into plans to build it into [p]tabulate (alias [p]tab).

Design:

In order to keep the display uncluttered, here are our current thoughts of how this should work:

• the :regional_indicator_i: emoji reaction button shows on the taxon embed if there are user taxon counts present in the embed
• when this button is pressed, it toggles to identification counts mode
• in identification counts mode, all existing & new user counts added to the taxon embed are (re)calculated as identification counts instead of observation counts
  • and the "obs#" label in the chart header is replaced by "ids#"
• when the :regional_indicator_i: reaction button is pressed again, it toggles back to observation counts mode, updating all the counts accordingly

Resources:

• number of identifications API call:
  • http://api.inaturalist.org/v1/docs/#!/Identifications/get_identifications
• number of identification species API call:
  • http://api.inaturalist.org/v1/docs/#!/Identifications/get_identifications_species_counts

[synrg]

Thanks to mws for pointing out that special permissions would be needed to remove another user's reaction. Therefore, the design has been amended to just use a single button as a toggle, which appears to be how others do it.

[synrg]

mws also indicated there may be a problem with people toggling modes too fast. it's a valid point, but we should wait and see if it's an issue before planning any measures (caching, cooldown) to counteract that.

[synrg]

I think the whole idea of a toggle has to be scrapped because it breaks the continuity of the current conversation. Displays should not be replaced with entirely different kinds of displays.

Furthermore, I don't know if encouraging competition on numbers of ids on a taxon is helpful for our users & indeed iNaturalist as a whole, since data quality is a much more important aspect of doing identifications than mere quantity. That said, I do feel that setting and striving to reach personal goals is something we could do more to support. How about [p]my t <taxon_query>, which would be focused on producing a more complete display of personal stats for a given taxon? Then a person is just looking at their own data to try to dig more out of it, rather than holding it up against everyone else's for comparison. @michaelpirrello

[synrg]

Alternatively, we formerly had a mode of [p]obs (superseded by [p]tab which has not yet added back this mode) that makes a personal table where the rows are places:

[p]obs <taxon_query> by me from home

Once this is added back into [p]tab via the planned per qualifier, I wonder if this is a better place to start. my / rank are specifically about competition (projects) and showing ranks, whereas [p]tab I see as the command group under which various more complex sets of filters and table formats will eventually be added.

Note: I'm not dead set against the idea to parent it under [p]my, though. See #109 . It's just that ,my should just be syntactic sugar for by me sorts of commands, and not the primary place to put these commands.

So, getting back to [p]tab, right now, most of the expressiveness in the query is from the <taxon_query> selector and very little is offered to format the output. Adding a generic per format modifier to the query language would allow this feature to be delivered with a simple keyword in our first version:

[p]tab <taxon_query> by me per stats

That would be just like our old [p]obs by me from home, except substituting per stats for from <place>. My idea here is that we would show all stats (including ids) in each row, not just obs / spp, i.e. obs / obs spp / obs leaf / ids / ids spp / ids leaf.

This could be extended later with two axis per formats, such as:

[p]tab <taxon_query> by me per stats monthly to produce a chart of the same stats named above, where the rows are months from present time back to earlier months (via pager, of course). However, that would be outside the scope of this issue to implement.

[synrg]

The aforementioned [p]obs counts have been migrated over to the [p]tabulate ([p]tab) command, so I will edit the comment above accordingly.

[synrg]

Re my per stats idea, I may have conflated two distinct concepts that should be separated. As presented, it wouldn't be per anything so long as only one person is supported. It wouldn't be until monthly and other breakdowns are supported that per comes into play. What stats really functions as here is an alternate format, not an axis. So that likely needs its own separate qualifier format stats or similar, separate from per monthly (or less awkwardly phrased, per month).