I was reviewing my maintainance logs of a tractor. Some of the logs are auto-named, and does not provide any useful info when viewing all maintainance logs.
So, I’d wanted to edit them, and copy some info from the note field.
Saved the first log edit, and that takes me to viewing that edited log.
But I have poor possibilities of getting back to the list of the tractor’s maintainance logs.
My easiest option is to go back a few times, and see a table not updated with the latest change.
This can be done with 3 mose clicks at the same spot, or ALT+left arrow x3.
I can tap the tractor asset, selct logs, and maintainance and see the updated list. (But I already did that in the first place) Anyway it takes 3 clicks at different places.
The tird option is the breadcrumb urls.
When I’ve saved the log update, the breadcrumb looks like this:
It definately feels natural to click on Maintenance to get back to the list.
But clicking Maintenance takes me to an unfiltered view of all maintenance logs
And Logs shows all Logs.
This feels wrong since I first selected the tractor asset.
The breadcrumb should take care of this, and filter correct.
That’s an interesting idea @pat. Basically, what you’re describing is a breadcrumb that reflects the user’s navigation history, instead of the navigation tree/hierarchy that it reflects now.
Something like that might be possible in theory. The first thing to figure out is how/where to store the additional “state” this would require. By “state” I mean temporary information about which pages the user was on recently, which would be different from moment to moment.
It also raises some questions. The potential combinations of user navigation flow are endless, so what would the specific rules look like for this?
If you went to a log record directly by typing in its URL, what would the breadcrumb show?
On the other hand, if this is the main problem you’re running into, maybe there’s another solution. Maybe the breadcrumb isn’t the best option to explore.
I believe there’s some special browser caching when you use the browser’s back button that means it didn’t reload the page from the server - at least for recently visited pages. The answer here is to refresh after going back.
You can avoid a few of the clicks by long pressing (click and hold) on the back button, then selecting the “Maintenance logs” page from the resulting history menu.
In this sort of scenario I usually open a new tab for each log I need to edit, then close it once I’ve finished editing/saving that log update. (Tree Style Tab or Sideberry makes this way easier to keep track of.)
Another strategy like that would be to enable a module that allows the edits to be done directly without navigating - e.g. Edit in-place field | Drupal.org or I think there was a some discussion in the past of a way to open the entity (log in this case) editor in a panel on the side.
This is kind of implied by Mike’s answer, but to expand on that; the reason the breadcrumbs don’t work that way right now is that they are based only on the data for the page you’re currently on - not how you got there. In this case, the maintenance log might apply to multiple pieces of equipment or might reference other assets so there are lots of ways one might have gotten to that log page. (Drupal can’t tell from the current page which of those you’d like to return to.)
I’d caution against recreating browser history controls, but it’s worth pointing out that doing so on the front-end would be pretty easy since the browser’s history stack is already available in javascript. That strategy also avoids the problems that server-side storage would have with multiple/closed browser tabs.
Yea, I see this is not an easy solution.
I’ll manage and make my way around.
But I just feel there is some logic missing in the navigation sometimes.
The user should be able to return to a previous “level”.
At least after an edit.
So, what about this:
When you edit something, you first select the item from a table.
If the url to the page showing the table is saved, it could be inserted as a back-button somewhere on the page you are taken to.
And quite nicely, it would also work if the table was filtered.
Also, it could work when adding a new log or asset. It could take you back to an updated version of the page you visited when creating the new log.
One nifty option that Drupal provides is the ?destination query parameter. If you go to /log/1/edit?destination=asset/1, then after you submit the log 1 edit form, you will be redirected to asset/1.
We could potentially add that in more places, so that you return to the place you originated from when you clicked “Edit”.
The limitation is: ?destination only works when you load an edit form URL with it. The links on log lists go to the Log’s “View” page (not “Edit” form). If we added ?destination to those links, it wouldn’t work, because there is an additional user click required to get to the “Edit” form, and the ?destination is lost in that step.
One thing we could do is add an “Edit log” link to all log list items, which pointed directly at the /log/[id]/edit path with a ?destination parameter set pointing back to the log list page. This would take you directly to the log edit form, and back to the list after the form is submitted.
New features aside, @Symbioquine’s approach is what I would recommend right now too. Browser tabs are a very powerful navigation tool. I always open new tabs for individual records I want to edit, just out of habit at this point.
That could be a useful, but as @Symbioquine says, it may take too much valuable space.
I was thinking of the action drop-down menu too, but that’s also kind of unlogical navigation for editing just one log. Don’t think I would be using it.
But Ctrl-click and Ctrl-W works fine. I use it a lot too
