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

General
1

When I check the observations in the project I’m running and look in Grid View only a small portion of the total observations appear. These are all the most recent ones.

The Grid view is useful as the images are large enough to quickly scan, but having only about 200 of over 1500 observations showing and no ‘next page’ option limits its use quite a bit.

Is there a work-around for this or a plan to add an option to extend the number of observations visible in the grid view?

Relevant project: https://www.inaturalist.org/projects/cat-ba-island-and-surrounding-area?tab=observations

If it helps, I’m viewing the project using the current build of Chrome on a Windows 10 x64 computer.

1 Like
2

https://www.inaturalist.org/observations?place_id=any&project_id=cat-ba-island-and-surrounding-area&subview=grid

3

Ok, that’s weird.

If I go to the project observations page and click on the grid view I get this address ( https://www.inaturalist.org/projects/cat-ba-island-and-surrounding-area?tab=observations&subtab=grid )

That page locks out at something like 200 views with no option for viewing further pages.

If I use the link you provided ( https://www.inaturalist.org/observations?place_id=any&project_id=cat-ba-island-and-surrounding-area&subview=grid ) then I get the option to look at further pages.

Why does clicking on the grid view of the project not default me to that second and more useful link, or at least to a link that behaves in the same manner as the second link?

The vast majority of participants in a project will be looking for observations using the project page, not via the round-about observations -> place, etc pathway.

It seems to me that it would be a good idea for the grid view on the project page to behave in a manner that allows a used to see all the observations made for that particular project.

1 Like
4

I agree, but it could also be a resource friendlier method that they use for that project page, resulting in the limitation. In other words, for the majority of visitors to that page, the shorter result set is ample for what they need, a brief view into what the project is picking up.

You can use the search button on that page to access the link I provided above, and it then has further capability to filter and reduce the result set.

5

I understand the need to resource conservation, but if very few people will ever use that approach (or even know to do that) it means that you’re losing a lot of functionality.

For with identifications, for example, people go to the project page, look at the gird view, and all they see is the most recent observations. That means that they never see any of the older observations and then the majority of them never get any community identifications.

At the minimum the grid view should allow a user to see all the observations for the project as the default.

Having a separate and more detailed way to sort through is fine, but its very much a minority of users who know to do that, and an even smaller portion of them who actually will do that.

6

sorry, I may have confused you a little… I edited my reply above I think while you were writing your reply…

I think it works well this way.

If I am following a project, then I go into this page to see what the latest additions are.

If I am wanting to ID observations from it, I click on the Identify button and it takes me to the Identify page with filters appropriate for idntifying observations from this project (with the sometimes annoying default place filter from my settings, in my case “New Zealand”, so I have to cancel that part of the filter to see the needs ID list)

If I want to look at all observations, then I just click on Search to go to the Observations page with filters for that project, and again I have to cancel the place filter, otherwise it works well. I can narrow down to the leps or aranae, etc… and there is page control to keep the page manageable.

Possibly renaming the “Search” button to be “All Observations” would be the only improvement I can see…

1 Like
7

What I am getting at is it is not a bug… it was intended behaviour…

8

I get that, but the thing is that the vast majority of users either don’t know at all to do that, or don’t do it due to the extra steps.

1 Like
9

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
10

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.

11

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.

12

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?

image
image.jpg1239×531 227 KB

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

Or pagination?
image

3 Likes
13

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.

14

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
15

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
16

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
17

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
18

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
19

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
21

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).