search taxon: select one or more entries

[synrg]

This is a rather large proposal that needs to be broken down into multiple sub-issues. The goals are:

1. provide a means to select more than one entry
2. include a more informative summary of a candidate item, allowing users to decide whether any item is one they want to keep in the selection without having to display the full record first
3. provide a means to advance to the next/previous item matching the search query, not just the next/previous page
4. provide persistence for the selected entries and allow them to be referred to outside of the the current display/channel/server

Approach

1. The mechanism here could be a selection "cursor", e.g. > in the list of matches showing which entry would be selected for display if the user were to press the selection reaction to display it (see the last point from 3 below)

2. The more informative summary could consist of two parts:

• set the thumbnail for the embed to the square thumbnail image for the item under the cursor (initially the first item in the results, but can be changed by the user via reactions)
• include a 2-line summary of the currently selected item at the top of the search results, e.g.

Genus Megachile (28640 observations)
in Family Megachilidae (59708 observations)

3. This would be best achieved as follows:

• change the letter reaction behaviour to move the cursor position to that entry, showing its thumbnail & summary instead of performing a full taxon display
• provide a pair of navigation buttons to move the cursor up and down in the list, e.g. 🔼 and 🔽
• provide a select reaction (perhaps ✅) to select the item currently under the cursor, generating a display for it (i.e. equivalent to typing ,t taxon name for the currently selected taxon)

4. Persistent multiple selection could be implemented as a bookmark feature:

• a 🔖 reaction could toggle adding/removing the item under the cursor in bookmarked items
• each new bookmarked item would be kept behind the scenes as an ordered list, with the most recently added items at the top
• the bookmarked items for a user could be retained in Red's user Config store so that they persist beyond the current command/display
• an indicator could be shown per entry in the current display to show that the user has bookmarked it
• additional commands could be provided to show and perform other actions on all bookmarked items, e.g. ,bookmark (alias ,b) to show/page through all bookmarked items or ,b # to retrieve the most recently bookmarked item for display in the current channel

Points 1 through 3 should be implemented together as phase one. The 4th point should be split to its own issue.

Future plans

Finally, a separate but related idea (which needs its own issue) is to provide a history of all user interactions, where an interaction is:

• typing a command (e.g. ,t taxon name or a dot-taxon mention, e.g. .WTSP. in a message)
• pasting a URL to an observation
• pressing any reaction button on a display (e.g. the every-popular #️⃣ reaction)

Unlike the bookmark action, which is an intentional user action, history tracking would happen for everything the user does. Therefore, it would be disabled for users by default, and they would have to change it in their user settings to enable it.

Like the bookmark feature, history items would be stored behind the scenes as an ordered list with most recently added items at the top, and users would be provided with commands and reactions to perform actions on their history, e.g. ,history (alias ,h) to show/page through all history items or ,h # to retrieve the most recent item in their history for display in the current channel

Example history interactions:

Finding something off-channel & then retrieving it in channel

• User performs a ,s megachile in #bot-commands channel and then pages through the results, looking for the right one.
• When they find it, they press ✅ reaction, selecting it for display.
  • Note: only the ✅ reaction would cause it to be entered into the user's history, not the navigation buttons.
• They return to #id-confirmation channel where theywere responding to a request for help IDing their megachile bee and type ,h 1 to retrieve the most recent interaction.

Sharing something seen in a different channel

• User spots a cool mine on a leaf in an observation that another user shared on #plants-and-algae and wants to share it in #plant-parasites
• They react to the observation (maybe 👍 or 👀 or even Reply to the observation might count as an "interaction" with it) so that it is now in their history.
• Then they go to #plant-parasites to share it. Perhaps it could even be retrieved using the dot-taxon mechanism, so they might share it like this:

We found this cool mine .h 1. in a megachile observation over on #plants-and-algae. any idea what it is?

[synrg]

Here's a prototype of how the observation search might look:

And here's the command using EmbedUtils to generate the prototype (wrapped for easier reading):

c.embed fromdata
{
  "type": "rich",
  "title": "Order Diptera (Flies) by benarmstrong",
  "url": "https://www.inaturalist.org/observations?taxon_id=47822&user_id=545640&verifiable=any&include_new_projects=1",
  "thumbnail": {
    "url": "https://inaturalist-open-data.s3.amazonaws.com/photos/5974873/square.jpg?1483823410"
  },
  "footer": {
    "text": "1-4 of 540 observations"
  },
  "description": "** **\n
  \\\uD83C\uDDE6 ***[Calliphora vicina](https://www.inaturalist.org/observations/71823661)***\n
  \u2003\u2002**(Bluebottle Fly)**\n
  \u2003\u2002\\\ud83d\udfe8 \\\ud83d\udd163 \\\ud83d\udcf76 \\\ud83d\udde812\n
  \u2003\u2002**Apr 10, 2021 by benarmstrong**\n
  \u2003\u2002**at Timberlea, NS, Canada**\n
  \\\uD83C\uDDE7 [Superfamily Oestroidea](https://www.inaturalist.org/observations/71824553)\n
  \u2003\u2002(Bot Flies, Blow Flies, and Allies)\n
  \u2003\u2002\\\ud83d\udfe8 \\\ud83d\udcf7\n
  \u2003\u2002Mar 12, 2021 by benarmstrong\n
  \u2003\u2002at Lakeside, NS B3T, Canada\n
  \\\uD83C\uDDE8 [Superfamily Oestroidea](https://www.inaturalist.org/observations/71824553)\n
  \u2003\u2002(Bot Flies, Blow Flies, and Allies)\n
  \u2003\u2002\\\ud83d\udfe8 \\\ud83d\udcf7\n
  \u2003\u2002Mar 12, 2021 by benarmstrong\n
  \u2003\u2002at Lakeside, NS B3T, Canada\n
  \\\uD83C\uDDE9 [Superfamily Oestroidea](https://www.inaturalist.org/observations/71824553)\n
  \u2003\u2002(Bot Flies, Blow Flies, and Allies)\n
  \u2003\u2002\\\ud83d\udfe8 \\\ud83d\udcf7\n\u2003\u2002Mar 12, 2021 by benarmstrong\n
  \u2003\u2002at Lakeside, NS B3T, Canada"
}

[synrg]

Unfortunately we found in testing (thanks, @mws) that iOS doesn't handle the unicode emojis. so we went back to discord emojis instead. :label: works well for an IDs indicator.

[synrg]

using original Discord emojis and en-spaces for the indents

[synrg]

On Android (Xiaomi Mi A2, 6" display, 1080x2160 pixels, 18:9 ratio)

The compromises made here maximize use of vertical screen space and I hope make it tolerable on very small displays:

• The hanging indent is achieved with a Unicode en space. This is necessary to avoid blockiness.
• Tried and rejected blockquote style > because it uses far too much space on mobile.
• Grouping all indicators at the top of each entry, aligned to the left margin helps with visually jarring misalignment of indicators from one entry to the next, a problem with our current search output which places them at the end of the first line (which varies in length).
• Changing from letters to numbers fixes appearance on iOS devices: letters do not stand out well enough against dark theme background. Originally, we had used letters when we thought there could be more than 10 entries per page in the longest such displays. But it later became evident that such displays are far too tall, even if fewer lines are devoted to each item.
• Unless we implement automatic paging to the next API call, the last embed page should have a footnote explaining where the other pages went and what to do about it (e.g. we could support a command option to start at a specific page)
• Unfortunately, with four entries, the display is just slightly too tall to see all at once without scrolling on smaller displays. Reducing the number of entries per page to three would very likely be a nuisance, since users would have to navigate through more pages to get to the entry they wanted to see. I think this is a decent compromise.
• Moving the number of observations to the top and using italic & underscore style sets it off from the text that follows yet keeps it from using extra vertical space.

[synrg]

c.embed fromdata {
  "type": "rich",
  "title":"Order Diptera (Flies) by benarmstrong",
  "url":"https://www.inaturalist.org/observations?taxon_id=47822&user_id=545640&verifiable=any&include_new_projects=1",
  "thumbnail": {
    "url": "https://inaturalist-open-data.s3.amazonaws.com/photos/5974873/square.jpg?1483823410"
  },
  "description": "*__1-4 of 540 observations:__*\n
  :one: :green_square: :label:3 \ud83d\udcf76 \ud83d\udde812\n
  \u2002***[Calliphora vicina](https://www.inaturalist.org/observations/71823661)***\n
  \u2002**(Bluebottle Fly)**\n
  \u2002**Apr 10, 2021 by benarmstrong**\n
  \u2002**at Timberlea, NS, Canada**\n
  :two: \ud83d\udfe8 \ud83d\udcf7\n
  \u2002[Superfamily Oestroidea](https://www.inaturalist.org/observations/71824553)\n
  \u2002(Bot Flies, Blow Flies, and Allies)\n
  \u2002Mar 12, 2021 by benarmstrong\n
  \u2002at Lakeside, NS B3T, Canada\n
  :three: \ud83d\udfe8 \ud83d\udcf7\n
  \u2002[Superfamily Oestroidea](https://www.inaturalist.org/observations/71824553)\n
  \u2002(Bot Flies, Blow Flies, and Allies)\n
  \u2002Mar 12, 2021 by benarmstrong\n
  \u2002at Lakeside, NS B3T, Canada\n
  :four: \ud83d\udfe8 \ud83d\udcf7\n
  \u2002[Superfamily Oestroidea](https://www.inaturalist.org/observations/71824553)\n
  \u2002(Bot Flies, Blow Flies, and Allies)\n
  \u2002Mar 12, 2021 by benarmstrong\n
  \u2002at Lakeside, NS B3T, Canada"
}

[synrg]

Yellow square & green square are closer to the "needs ID" and "RG" icons used on the website than green checkmark and yellow diamond. I think our rationale with the shapechange is if you don't put letters in them, you want something other than color alone to tell them apart (accessibility aid for the colorblind).

Therefore, we might retain the original icons by default, but allow custom emojis to be used for these for servers that want them. For example, Needs ID might be:

RG would be similar, a green badge with white R on it, and casual could be a grey badge with C on it.

Alternatively, we could go for 2 and 3 letter icons: RG, NID, CAS (cf. 🆕, 🆘, 🆗, etc.) though to fit 3 letters on, I don't think we could retain the distinctive penant-style (chevron indent on the right) of the iNat website icons.