-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: adding breadcrumbs for users to easily navigate back to search … #501
base: dev
Are you sure you want to change the base?
Conversation
…results on record pages
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks really nice!
A couple cases for which I'm not sure is the right way to handle things:
-
if I keep clicking different drugs and genes, it'll send me down a chain of record pages, but "Search Results" still points back to the original search. I think that's correct, and the alternative would be like a growing chain of random drugs and genes (complicated to retain, could get too big) but it's a little unexpected also
-
If you click on a gene in Browse Categories, the breadcrumb is still "Search Results", and it points to the last search you did in that session. It would be really nice if we could set ourselves up to ensure the breadcrumb goes back to Browse Categories, and if the link opened the tab for the category that you clicked from (would probably entail some non-minor lifting on that page though).
-
If you are looking at a gene/drug page, and then put in the URL for a different gene/drug page, the breadcrumb will point back to your previous search results (even though you technically didn't get there via searching). Opening a new tab fixes this, but I'd say it's unexpected behavior.
thank you so much for testing this thoroughly and leaving this amazing feedback!!
|
I think the way this is implemented currently is the correct way to handle. I think the growing chain of drugs and genes could be useful actually, but I agree it has the capacity to grow really unwieldy very quickly. We can use the current implementation and loop back to this if it becomes a requested or desired feature.
Also agree on this point. How much of a lift is non-minor?
I am actually having a hard time thinking about if this is a problem or not. In this case, I think the expected behavior would just be either:
We already kind of discussed that we don't necessarily want the behavior in option 2, but I don't know that the user would care about the implementation of option 1? I feel like they might actually want to get back to their own initial search results easily (but maybe I'm wrong about this) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree that this looks really nice! We are missing one common use case though, and that is for interaction pages.
Currently if you click on an interaction table row to navigate to an interaction info page, there is no breadcrumbs on that page.
…results on record pages
I had to adjust some styling for this. The 404 Not Found page may look a little silly, but I will fix it up and add a container for it once #500 is merged
close #339