Project Observation page doesn't show all observations in Grid view

I wasn’t sure where else to put the post… there should be a section for, “Is this a bug or a feature” as there are often elements of how iNat is set up that are intentional, but really feel like a bug to the end user.

1 Like

I’ve never had opportunity to canvas “the vast majority of users” for what they know or how they would expect this to be…

General discussion section can be used to discuss whether something is a bug or a feature.

I have to say, the default response from IT folks tends to be, “It’s a feature, not a bug,” but that simply doesn’t hold water in many cases and doesn’t contribute to the conversation. Sure, certain things may not technically be a bug, but if the behavior of the software returns a result that behaves like one, and the only work-around is a non-intuitive multi-step process for which there is little to no documentation, well… that’s a bug by any other name.

Clicking the button that says “Identify” seemed intuitive to me for a way to add IDs to the project observations. And clicking “Search” seemed what would be necessary if I wanted to view a certain subset of the observations. I don’t personally like endless scrolling through observations. Easy to lose my place.

Perhaps it should offer a “View all” link at the end of the list on the project page rather than simply truncating the list to the most recent obs?

Or are you saying you would prefer the endless scroll?
image

Or pagination?
image

3 Likes

To keep it simple, the paginated view should be the default; keep it the same as the “search” option with no other filters selected. Bottom of the page should have a 1-10 (or whatever) list plus a “last”/“first”/“oldest” observations" page link.

That meets the criteria of showing the most recent posts first and preventing and endless scroll, plus doesn’t give the mis-impression that what you see is all that you get (a complaint I’ve gotten from my staff who I’ve gotten involved in iNat - and who are now absurdly enthusiastic about it -, and from visitors to my area, as well as other users in the country I’m working in ans elsewhere).

The way it’s set up now early observations rarely ever get identified and if there are a lot of users (or just a couple of particularly active users) even many of the recent observations don’t get IDs b anyone other than the initial observer or maybe by any followers they may individually have.

The key of all this is that iNat is supposed to be user based and user friendly, making it easy and intuitive for users to contribute in a meaningful way.

iNat has grown enormously since its early days and there are parts that are great, but that feel like they were independently bolted on without a clear process of user experience integration being considered, and when those are brought up the standard IT, “feature not bug,” line is trotted out. Now, in some cases that’s the case and real though has gone into the issue, but in other cases it’s difficult to see how it’s anything but an oversight or a result of cutting a few corners in order to roll things out faster.

It’s a small team working on iNat. If you have an actionable recommendation that would be an improvement to your user experience, then make a feature request listing the specific changes. How it would improve your experience, example URLs, and maybe even graphics mocking up what you’d like to see are helpful to include. I made this one: https://forum.inaturalist.org/t/display-all-observations-on-project-pages/4951

Identifying through the project page (or observation/Explore page) would be a really frustrating way to work through these types of observations. Click “Identify” and sort observations in the project by date added, with the oldest first: https://www.inaturalist.org/observations/identify?order=asc&project_id=cat-ba-island-and-surrounding-area

2 Likes

Oh, I’m aware of how small the iNat team is and I greatly appreciate how much everyone does and how active the team is. The iNat team is now much larger than when I got involved with iNat many years ago, and larger than when I later accidentally would up making friends with Ken-Ichi via a separate, but related set of activities.

In my experience, a lot of users do exactly the click-on-project-page approach to look at and ID observations. For the users I know it’s less about actively thinking, “I’m going to go identify some observations,” as it is thinking, “Let’s see what’s come up on the observations page,” followed by an epiphany moment of, “Oh, I know that, I can ID that.”

I don’t have any numbers on what percentage of users take that approach, but in my experience, it’s pretty much all the users unless they have a very specific interest in a particular suite of species or in a particular area. Even the users who do have that interest, in my experience, often don’t know how to get to a particular place, or to use the interface effectively.

I do what can to help, but there are so many oddities and quirks with the interface that I don’t know a lot of the ways around iNat and when I do look for how to do or find a specific thing the documentation is often either lacking or insufficient.

This isn’t to complain or cause problems, it’s to see if we can figure out the best way to ensure that iNat is an effective tool for users everywhere and that it’s easy, intuitive, and streamlined.

1 Like

Disclaimer: I am a software developer.

Software developers (henceforth “devs”) use a different definition of the word “bug” than you seem to be applying here. Yours seems to be close to “a problem which needs a solution”. Devs use a definition close to “The system isn’t doing what we designed it to do”. Devs have in their minds a large amount of information about how their system works, so there’s an important difference for them between finding an unexpected behaviour and changing the system so that it behaves as expected, and changing the system so that it behaves in a new way. The latter requires the devs change their mental models of the system as well as changing the system itself. I say “mental models”, but one can add “design documents”, “behaviour of experienced users”, “other software which uses this feature”, and “other parts of this system which interact with this part of the system” to the list of things which have to change when the system starts doing something new, as opposed to stopping the system from doing something no-one ever expected it to do.

In a large project with many devs, the devs have to coordinate, so all their mental models are in-sync. For this reason, it’s often easier to have all the devs sit down and redesign a subsystem together, making a lot of related changes at once. A bug, on the other hand, can often be fixed by one dev without requiring that they coordinate with all the other devs.

The important thing to remember is that once a bug is identified, it can often be fixed right away, while a feature request, no matter how well thought out it is, often has to wait until the entire team of developers is scheduled to work together on a particular part of the system.

From the point-of-view of a user who starts knowing nothing about the system, and learns along the way, a “bug” might be any case where the system isn’t behaving as the user expects. But in many cases a user has expectations about how the system behaves (or should behave, given the problem they’re trying to solve) which don’t match a dev’s expectations about how the system actually behaves. So there’s a rich source of confusion and miscommunication there when a user says something is a bug and a dev takes them literally, or when a dev realizes that what’s actually being talked about is changing a feature of the system, and the user sees the change from “bug” to “feature request” as the developer choosing to downgrade the priority when it’s really the developer recognizing that the change is going to require a lot more work than fixing a bug would.

So, to summarize:

  • A “bug”, to a developer, means something which behaves in an unexpected way, and a “feature” means something which behaves as expected.
  • Changing how something is expected to behave requires changing all the things which expect it to behave that way, or else things break.
  • When a developer says “It’s a feature request, not a bug report”, they’re trying to tell you something about what’s required to deal with the issue, not brushing you off.
  • Misunderstandings during communication are much more common than is obvious. That’s probably the main reason for the “Assume people mean well.” rule in the community guidelines.

That said, “It’s a feature, not a bug” is the punch-line to a well-known (among developers) but often misunderstood joke about behaviour which was not intended by the developer but which others noticed and started to expect, turning a simple bug-fix into a lot more work. So that line does get trotted out too often, sometimes in contexts where it doesn’t make sense. It may have turned into a shibboleth.

7 Likes

I can shed a little light on things we talked about during the design and development process for collection and umbrella projects. The way projects are associated with observations is through their search parameters, and you could think of them as fancy saved searches.

We knew these projects would essentially be showing search results, and we didn’t want to duplicate existing user interfaces that already deal with search results. We figured we’d show a summary of observations in the project and allow the user to click out from the project page to get to more specific tasks like exporting those observations (exports), identifying them (identify), or further exploring/searching/filtering them (explore). So we added buttons at the top of the project observations tab to reach these other existing UIs that people would be familiar with to do these tasks.

I can see how may be its not immediately obvious those buttons are there, or what they do. I like the idea of adding a “View all”, or “View in Explore” link when you’ve reached the end of the subset of observations that are shown. I wouldn’t be completely opposed to adding pagination here if people really want it within projects. But if we’re talking adding further features like filtering the observations within a project - in my opinion that should be the exclusive job of the Explore interface. It’s easier to develop and maintain the code when it’s consolidated (less code and less duplication), and I think it’s less confusing to the user to have fewer user interfaces to learn.

So that’s a little of why this intentional design decision was made. We’re happy to make a small fix here to make things less confusing.

8 Likes

Not everything can (or should) be reduced down to a single click…

In my view this page works fine the way it is, and the only change I would make is to the wording on the Search button, to change it to All Observations.

1 Like

An analogy if it helps:

I can get into any car that I am not used to driving, and I could list several dozen problems with the setup. Let’s take the handbrake:

If it doesn’t work, then it’s a bug (fault) and needs to be fixed

If it’s on the wrong side of the seat, then it is a feature that I need to get used to using

If it’s unable to be used as a handbrake because it can’t be reached on that side of the seat, then it would be a feature request to have it moved elsewhere.

It is unrealistic to expect every car manufacturer to alter their vehicles to be exactly like every other car on the road… but of course there are some things you would expect to be the same. If everything is the same, then how does the technology develop and improve?

I guess what I am saying, when I say it is a feature and not a bug, is that it is designed that way and new users should try and learn to use it that way. Just saying “the vast majority of users think this is a bug” does not make it so… If you can show that it is routinely being interpreted incorrectly, then that is a different story…

Take a restaurant that has cutlery set out on a table. If, as a new diner to that restaurant, I sit down at that table and pick up a piece of that cutlery and try to cut my steak with it, but it is a fork and doesn’t do the job very well, I might suggest that they put a sharp edge on every implement so that no matter what piece I pick up it will cut the steak. Or, I can realise that this restaurant sets out the table a little differently to how I normally experience, and I can look before i pick up the cutlery and get the right one. With a little pracise, I will be able to know which one to pick up without looking… but it certainly isn’t going to be a need to change how the restaurant operates. This is what i mean by a feature that is working as designed, and that the user just needs to learn to use. compare that to a “westerner” in an “eastern” restaurant, where there are no knives and forks, and everything is eaten by chopsticks. If the market is westerners, then they would be best to design the cutlery around western diners, or at least to cater for them by having dual options.

iNat is a system with a few “hidden” or undocumented features, and most software and online systems are somewhat like that. It’s like walking into an eastern restaurant, knowing that things are going to be a little bit of a learning curve, and actively giving the chopsticks a go… the bug would be “my chopsticks aren’t on the table”. It’s not a bug if the chopsticks are there, but wrapped up in a serviette and you didn’t realise it.

Things aren’t broken just because they don’t work the way you expect them to work.

1 Like

The location of the buttons is fine, but it certainly seems to be a bug that Identify doesn’t default to a suitable location for the project. Many users will see a blank page with “No matching observations” and may not realise that they have to clear their personal default location in order to populate the list.

I assume it would be a fairly simple to add a &place_id=n parameter to the url to fix this. However, it might be tricky to work out which particular place to use, given that projects can specifiy multiple locations (or none).

UX bugs are definitely a thing, and need not mean that something has failed to pass unit testing. If something works significantly differently than a reasonable user would expect, to the detriment of their work, it can absolutely be logged as a bug — which, notably, the OP did not do without checking first. I think they did everything right here in the first place, actually — gave plenty of detail, a concrete example, and a statement of expected behavior, and altered the question slightly in response to the new information that there is already a less-obvious route to the requested information. As much as I like user education, all this talk about proper bug reporting seems like a bit of overkill in this instance.

1 Like

yeah sorry… “the vast majority of users” got my hackles up… but I stand by my assertion that not everything needs to be reduced to a single click… having to click twice is NOT a bug!

1 Like

It’s not about “multiple clicks”. That sort of intentional misdirection and over-simplification is one of the things that gets my hackles up.

It’s that it doesn’t do what it says it does. “View All” is not view all, it’s actually “view a small faction of the most recent observations”.

It literally DOES NOT DO WHAT IT SAYS IT DOES. That’s the issue. It may not be a software bug, but it’s certainly a conceptual bug.

If it says, “View All” than it should show all. It’s a simple as that. If it’s not going to “View All” then the button should be changed to “View Most Recent” or something similar.

The easiest and most logical solution would be for the “View All” link to simply go to the same page as the “search” button does. That way it’s actually letting the user “View All”, like the button says, and it’s not leading to an endless scroll. The most recent observations are still the first ones people see and it’s an easy matter to look further or for something more specific.

But that is not one of the three pages you linked to at the start of this. When did you change what page you were talking about?

ok, here it is specifically stated that it was intended behaviour. It is behaving exactly as intended, so it is not a bug, period.

I’ve just gone back through this entire topic and you have not once said there is a problem with the page you just gave that “View All” jpg link of. I agree that THAT page has a questionable button out at the right that should not say “View All”. If anything it should say “View More” or just “Observations”, as it effectively has the same functionality as clicking the Observations Tab.

Maybe you can point out to the people that you are showing this site to, that the button that says “Identify” will take them to a page where they can identify older observations?

Sorry, but I’m just a little annoyed by the fact that it’s taken 27 posts for you to finally get around to showing what page you actually have a problem with…

1 Like

You appear to be the only person who had difficulty understanding the issue. The page I showed a clip of has a button that says “view all” when you click that it takes you to the page you put up a clip of, and what this discussion has been all about, a page that very clearly does not “view all”.

Most users won’t know to then click on “search” to see all the observations, as “search” generally means that you’re looking for something specific, not everything.

This was clear enough that another of the iNat staff made that a feature request.

I understand the argument you’re making about summary vs search, but I completely and utterly disagree with it, especially as the first page of the search result is the summary of the most recent observations.

The approach taken has added unnecessary complexity and unnecessary confusion.

This conversation got side tracked. Everyone, please keep things on-topic and flag a post if you believe it’s off-topic or violates our Community Guidelines so moderators can look into it. There is a feature request related to this thread, so I’m closing it now.