"Identify" interface design

[nimmolo]

Opening a discussion about a new "Identify" interface for rapidly identifying observations.

Prompted by @AlanRockefeller on Slack:

I just tried timing myself identifying 30 mushrooms on both Mushroom Observer and iNaturalist. On Mushroom Observer it took me 20 seconds each and on iNaturalist it took me 4 seconds each. It's a lot faster to use the identify interface to flip through observations that need ID than to open up lots of tabs and ID on MO.
The URL I use on iNaturalist is: https://www.inaturalist.org/observations/identify?taxon_id=47170&without_taxon_id=54743%2C117869%2C152030%2C152028&place_id=1

My initial idea was to

• Make a menu link to a new Observation index view, Observation.without_name.order(created_at: :desc)
• That page would be coded to display each obs in a simplified version of the "matrix box" with cheaper queries and not so much info. You could click on an "Identify" button in any matrix box, and have a popup "Identify" interface appear in a modal window.
• The interface would in effect be a "HTML content slider" (not a photo slider, but one containing arbitrary HTML content) where you could flick through simplified info about each unidentified observation in the current page of the index. That window would stay active as you browse through identiable observations, navigating right and left with your cursor keys if you like, or swiping.
  Each "Observation slide" would be a very simplified version of a "show observation" view.
  -- Image or images
  -- Info about the obs, where, who, when etc
  -- Naming form
  -- ?

Questions (please add more)

• Should the Identify index show only observations without a name, or observations with name confidence below a threshold?
• Should the identification interface be a popup modal window with the index still in the background, or a dedicated view without the background noise?

[mo-nathan]

• Observations with names below a threshold would be sweet or there should be a boolean for folks to say they think this is the best it can be (which is distinct from them saying that they have reviewed this observation and don't want to see it again).
• I'd go for a dedicated view.

[nimmolo]

Thanks Nathan.

• What would the "I think this is the best it can be" boolean set in the db? A confidence level/vote_cache?
• If we go with names below a threshold, I imagine we'd want to load the namings interface, rather than a simple "propose name" form. That's fine with me, but definitely slower, although we can load it conditionally. (I believe Jason mentioned awhile back, in another context, that the namings query is one of the slowest on "show".)
• Feels like maybe we should enable comments and notifications interface in this simplified view too.

[pellaea]

If we're just throwing things out there... I would love to see this be a configurable search like any other observation index. Can we have this be an alternate view for the existing /observations index page? If we want to save the user a click (as opposed to 1. search for Fungi, 2. click on "Switch to Identify Interface" in the resulting index), we can add shortcuts, e.g., in the left hand column ("Identify interface" or equivalent), or maybe even as another option in the search pulldown ("Observations (identify interface)" next to plain old "Observations")... or even make this the default view for observation indexes. It might behave pretty similarly until you start popping up observations(??) re: "I think this is the best it can be" boolean -- I really feel strongly that this should be per-user. I would personally prefer mildly that it be called "seen" or "reviewed" or something like that, but the name is less important than that it remember which observations *I* have seen and acted upon. Note, re: thresholds, that the search bar already allows for the specification of a threshold, although maybe it only covers the "vote > N" case, and what you're talking about is "vote < N". But I also recognize that it might be more user friendly to make this a standard one-size-fits-all thing to reduce complexity, or a convenient configurable pulldown option so that the user doesn't need to remember the syntax of the pattern search filter parameter. And I also recognize that other filters might be worth applying, such as "no votes" or "rank > species". It can definitely get complicated, which is why a one-size-fits-all compromise that combines all these subtle factors for the user might not be a bad idea. Maybe we could accept additional standard filter parameters in the search bar, too -- region:USA, lichen:yes, etc. Ah, here's an idea that might make implementation of this part dead simple: add a new filter parameter "needs_review:yes", which applies this complex set of the thresholds, etc. that we deem best for this purpose. That's just basically a scope, just like all the other filter parameters like in_region, lichen, by_user, of_name, etc. Then you would get the ability to further refine the scope for free. You can use all the existing machinery for indexes as-is, and just pop this in as an alternate view. Users will not have to remember the syntax, because there's the handy "Identify Interface" (or whatever) button in the left hand column that takes you directly to an index with this new view based on a search "needs_review:yes new:yes". (The "new:yes" would tell it to omit observations you've already reviewed, just an off-the-cuff suggestion for syntax.)

…

On Sun, Jul 17, 2022 at 5:11 PM andrew nimmo ***@***.***> wrote: Thanks Nathan. - What would the "I think this is the best it can be" boolean set in the db? A confidence level/vote_cache? - If we go with names below a threshold, I imagine we'd want to load the namings interface, rather than a simple "propose name" form. That's fine with me, but definitely slower, although we can load it conditionally. (I believe Jason mentioned awhile back, in another context, that the namings query is one of the slowest on "show".) - Feels like maybe we should enable comments and notifications interface in this simplified view too. — Reply to this email directly, view it on GitHub <#1098 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAYTNNKQI2AM4P5RUM4XNNTVURZHPANCNFSM532IVK5Q> . You are receiving this because you are subscribed to this thread.Message ID: <MushroomObserver/mushroom-observer/repo-discussions/1098/comments/3167174 @github.com>

[nimmolo]

Would this describe setting an interest then? (Isn't that a kind of user-target join?)

re: "I think this is the best it can be" boolean -- I really feel strongly
that this should be per-user. I would personally prefer mildly that it be
called "seen" or "reviewed" or something like that, but the name is less
important than that it remember which observations I have seen and acted
upon.

[nimmolo]

I definitely like the single new scope, further refinable.

To be clearer, what's proposed here are two new views:

• a "new" index view (or maybe a param on the current index) showing a new type of simplified matrix box

...and (if we go with Nathan's preference)

• no popup interface, but rather a new simplified show_obs view, linked via an "Identify" button from the simplified matrix boxes, that's just for proposing names on observations needing review, and thus much quicker to load, and has "next" "prev" buttons that can be activated via cursor left-right clicks

The drawback of the dedicated show_unidentified_obs view is that it requires a new query every page load, while a popup "slider" could be built invisibly in the index page using the original index query (plus an additional query for all images of each obs), and populated so that the assets are lazy-loaded as the person clicks right and left — no page loads with fresh queries.

A third option is to put the slider in the index as a popup, technically, but have it pop up entirely covering the index, giving you a clean, focused UX. This makes the cursor next/prev navigation easier to code, and allows for preloading queries and lazy-loading the assets.

[nimmolo]

Note to email readers: i edited the previous one for clarity, visible on #1098 (comment)

[JoeCohen]

I generally favor things that make it easier for experienced users to identify unID'd Observations. Users have requested something like this for years. It's #1 on the list of desired features. See https://mushroomobserver.org/pivotal/index; https://www.pivotaltracker.com/story/show/13472707
I will add other comments separately in order to make it easier to follow sub-topics.

[JoeCohen]

Could we go with (or at least start with) the simplest implementation that would work? https://wiki.c2.com/?DoTheSimplestThingThatCouldPossiblyWork
For instance:

• We don't need popups, js, updating every template to a new version of Bootstrap, in order to have an ID interface. See "Identify" interface design #1098 (comment), https://mushroomobserver.org/pivotal/index; https://www.pivotaltracker.com/story/show/13472707.

[nimmolo]

This is a great reminder to keep it simple, and it's certainly right.

• JS — it should be as quick for me to implement an interface with js as with a new ERB template for a simplified show view — the JS just puts the templated ERB into a slider. I can use the existing Bootstrap 3 version's JS modal and carousel, adding one library that i've used many times in the past, RoyalSlider.
• It sounds like we're going for "pep" with the identifier, so seems like the way to do that is to make a simplified matrix box and show_obs for the identifier views, since they are so slow to load. We can try it with the existing templates first, but based on how slow it's been in my experiments locally, i think results are going to be frustrating.

[JoeCohen]

Would it be possible to complete the big pending PRs before embarking on this?
There are so many moving pieces that I'm personally intimidated from working on user-facing improvements while they are pending.

[pellaea]

Hey Joe, I feel like this general topic has come up before, and I've gotten animated about it (for which I apologize). I want to clarify that my primary goal is to help you feel comfortable working on things while big PRs are pending (or while an old API is gumming up the works or whatever the specific case may be). To that purpose, realizing that we each feel however we're going to feel and I don't want to make it sounds like I think you're categorically "wrong" in feeling intimidation , but I would love for you to be able to reframe how you think of these blockers: I encourage you to think of them "taking care of themselves". In the case of these PRs -- and noting that I have two myself, so by no means am I trying to heap anything onto Nimmo here -- it means that keeping the outstanding PRs up to date with respect to master is the owner's responsibility, not yours. Obviously, it's preferable to work together, keep the PR owners aware of your work, ask if they'd prefer you wait a day or two, or whatever. That's just common decency. But I assert that all developers feeling free to work on what they deem important and/or interesting trumps any considerations of trying to minimize other people's work in maintaining dangling PRs or legacy code or whatever. That developers feel free and excited to work -- not intimidated! -- is really, really important to me. And that's why I get animated and keep going on about these things. I wish we were working together in the same physical facility, because I feel certain we could come to a better understand of each other then. Hey, what about this. Try turning it about: if you were working on some big dangling PR, would you want everyone else to feel like their agenda were on hold until you finished? I assume not. I ask that you grant the rest of us the same right to not want to hold everyone up! :)

[JoeCohen]

Thanks @pellaea !
Just ignore me ;-). This morning I'm feeling especially tired and timid.
Thanks for reminding me about responsibility for keeping PR's in sync with master, and good point about keeping others aware of one's work and communicating before merging.
And thanks for being so animated.

[nimmolo]

Not to worry — i may not get to this before the family vacation, starts Saturday and I have to pack and plan.
But I wanted to haul the discussion over here from Pivotal, to get it percolating.

[JoeCohen]

Something like this would be useful for reviewing other objects, e.g., Names, Glossary Terms.
Please keep that in mind during development.

[nimmolo]

I'd like to do those interfaces in separate PRs, based on the JS in this one, but using different templates.

[nimmolo]

Question: Could those who know about votes please propose a threshold value for vote_cache that would select the appropriately unconfident Observation identifications?

(And maybe please commit that value in the appropriate place in the new Observation model scope needs_identification on the scopes PR...? 🙂 )

[pellaea]

re: user-target join, interests -- Yes, similar to interests. We have done polymorphic relationships both of the typical ways: comments and interests have both target_type and target_id; and rss_logs have separate columns for each target type -- observation_id, name_id, etc. In general, I think both Nathan and I prefer the rss_logs model. For example, you cannot eager-load targets from comments. (Fortunately, I think you can the other direction.) But you can eager-load both to and from rss_logs. There are other subtle differences, too, I think, but I'm not remembering off the top of my head. Anyway, my point is I would recommend either an rss_log-style general "reviews" (or whatever you want to call it) table, or (my preference, I think) a separate table for the reviews of observations, names, etc.

…

On Mon, Jul 18, 2022 at 6:26 PM andrew nimmo ***@***.***> wrote: Would this describe setting an interest then? (Isn't that a kind of user-target join?) re: "I think this is the best it can be" boolean -- I really feel strongly that this should be per-user. I would personally prefer mildly that it be called "seen" or "reviewed" or something like that, but the name is less important than that it remember which observations *I* have seen and acted upon. — Reply to this email directly, view it on GitHub <#1098 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAYTNNOE6JJAGAPCKVVXGSLVUXKXVANCNFSM532IVK5Q> . You are receiving this because you were mentioned.Message ID: <MushroomObserver/mushroom-observer/repo-discussions/1098/comments/3175431 @github.com>