Closed AntWeb-org closed 1 year ago
@bpescador, @chrisgrinter, @rich-keller
Inconsistency between Browse COs and Browse CEs.
Browse CE is getting a rewrite for sure. #3222. We'll use this as an opportunity to further refine the icon cluster.
Additional options under 'Go'/Navigate button are cryptic (due to non-intuitive labels) and seem like overkill.
We disagree that they are overkill. All options reflect real-world requests from curators. We found that none of our active curators use the next/previous by ID (internal, not catalog number). All wanted specific based on the current process they engaged in. For example, find my next record, becuase I know I made edit mistakes in a row, or "show me the next record missing this data", etc. Our curators use temporary tags a lot, navigating through these sets is very effective.
In our discussion today we came to the conclusion that perhaps what we are all asking is to navigate within some filtered set of results. We will work to implement this as the key solution. So you would see special buttons, when in that context "Next in filter", "Previous in filter". This is already actually possble using default tagged sets, but we can decreases the steps and have it act on (small) filtered sets.
Requiring two clicks to navigate previous/next is tedious. Fix: revert back to ‘Previous/Next’ by ID options
See work around to use next/prvious in set in part. If we do add visible buttons they must be more carefully considered than next/previous by (intenral) ID, because in practices, with a task in front of one, they are not particularly useful. For example, if you are updating a set of records because they need new determinations, or because they are missing some data, then this is not reflected in the sequence of ids, or if it is, it's by chance. We can do better in scoping these stepwise tasks.
Some of the information shown in the display may be irrelevant or confusing to the average end user, and either should be hidden by default (e.g., Timeline) or rearranged. Fix: The display of information on this page should be carefully designed in sessions with the end user to maximize usability and minimize confusion and cognitive overload.
carefully designed in sessions with the end user to maximize usability and minimize confusion and cognitive overload.
We agree. I think we need to tease this out. We agree that some elements are confusing, but the definition of an "average user" is infinitely discussable. What I think we are getting at is that the display of information only matters in the context of the task being undertaken. Tommy, for example, in reviewing data, finds the timeline the most important quick overview. He's doing a quick overview. I suspect that the types of things you are thinking about are much more specific, for example you want to do 1 thing, for 10 records, so you want the focus on that things.
Can we outline specific scenarious, perhaps as new issues, that might have more direct correlation with what "should be shown"? Remember that it's OK to design and ask for tasks that meet (very) specific needs. Consider in these what specifically is being done ("I'm updating determinations, I"m updating stage or sex").
Why are the Collecting Event field/value pairs shown most prominently at the center top of the page, when this page is all about browsing the Collection Object?
Here is our thought process. We heard from Ant-web folks that "we wanted to see everything". The top row is the raw data. The bottom row is reports, summaries that aggregate, and infer in some ways. You will change values from the top row. Rows in the bottom may require changes in one or more places. The collecting event data is the core data that can be changed. Note that you can click on some fields and change them there! You can't do this in the context of inferred (perhaps appended together) views in the bottom. An experiment for sure.
The Collection Object information is shown at the very bottom of the page under ‘Darwin Core representation’. Few, if any, domain end users will know what ‘Darwin Core’ is all about. But they will be interested in the CO attributes and values displayed.
As noted inferred views are on the bottom. All the underlying data, as represented in TW, are on the top row. The DwC view is on the bototm precisely because "Few, if any, domain end users will know what ‘Darwin Core’ is all about." and the raw data are on the top.
The display frame entitled ‘Buffered’ is very prominent, but it is empty, and unclear (to us, at least) what should be in this box and what the buffer is all about.
It's very prominent because it is central to the workflows for digitizing new specimens in TaxonWorks. I.e. if you are a collection that is actively digitizing then you will likely take advantage of them. They mean nothing for those records imported.
We think some of this will be addressed if we implement #3244 as requested in various places.
This is where I get bogged down in the naming: "We found that none of our active curators use the next/previous by ID (internal, not catalog number). "
I thought ID in this instance referred to the catalog number/identifier since the button seemingly scrolled through catalog numbers in the BCE, or at least, I thought that was the case.
We did make the catalog number next/previous much faster. I do see the argument to have these arrows out, so we'll see if we can make them appear after loading in the background.
Here is our thought process. We heard from Ant-web folks that "we wanted to see everything". The top row is the raw data... The collecting event data is the core data that can be changed. Note that you can click on some fields and change them there!
It confuses me that you think about the CE data as the core data that can be changed. We are browsing COs, not CEs. (Yes, they are related.) But when I am browsing COs, I want to see and change the CO data, not (necessarily) the CE data. Isn't that right? Instead, I see the CE data up top and I have to hunt for the CO data down below in DwC format, noless. The CO data is not all derived, it is raw data too. Each CO has a core set of raw data, and we want to see that up front and center, and be able to change it.
What I think we are getting at is that the display of information only matters in the context of the task being undertaken. Tommy, for example, in reviewing data, finds the timeline the most important quick overview. He's doing a quick overview.
Totally agree, what's important is contextual. If users could specify roles, then the displays could key off the user role to display "the right" information in the right place. Short of that, some customization capabilities seem the best way to satisfy most users. Or maybe the customization should be at the project level.
I have to hunt for the CO data down below in DwC format, noless.
Which data are we missing up top? This shouldn't be the case.
But when I am browsing COs, I want to see and change the CO data, not (necessarily) the CE data. Isn't that right?
First and foremost to me, in a summary task like this, I want to make sure that 1) I'm in the right place, and 2) that the data on the specimen label in front of me aligns with that of the record. This includes collecting event information.
I increasingly think that we need to indentify maybe a top 10 of things we want to be doing while editing, and see if we can isolate those to specific workflows. Browse, by definition, means general, and untargeted, we're not sure what we might find. It has to permit discovery, and draw attention to gaps. I feel that you are discussing a scenario when you are arriving somewhere, "with intent".
I am going to close this issue, some parts have been resolved with a new experiment (for example navigation has been updated) and have the Antweb team open individual issues each remaining point, or derivative thereof. While this is a bit more work for you I think it will focus things for us.
I think this was being discussed in a potential Browse CO lite, basically swapping the Timeline panel and the CE panel. CE data is good to see but the initial data we'd like to review/edit in a CO record is the catalog number (namespace and identifier), OTU, determiner, det. date, field number, life stage, preparation, repository, secondary repository (located at), specimen notes, MOL project notes and type status. The CE data is good to glimpse but not the main data we need to update or change in a CO record. I look forward to playing around with the new navigation.
Feature or enhancement
Location
Task - Browse Collection Objects
Screenshot, napkin sketch of interface, or conceptual description
No response
Your role
No response