Created attachment 77307 [details] Screenshot showing the authority hierarchy tree in the OPAC If the AuthDisplayHierarchy system preference is enabled, authority hierarchies in the OPAC and staff client are displayed as a tree via a jQuery plugin, jsTree. Rather than try to keep up with plugin upgrades, I propose that we replace the dynamic tree with a static one styled with CSS.
Created attachment 77308 [details] Screenshot showing the authority hierarchy tree in the staff client
Owen, on the mailing list, you ask: Are authority hierarchies often so "deep" that having a collapsible display is preferred? If so, could clicking to show or hide the entire tree be a viable alternative? The response is yes and no. The current behavior is really important for large thesaurus. By default, the tree is compact. You scan quickly the first level of terms. You choose to develop a branch. Then you scan the second level of terms. You develop one term. Etc. The scanning process will be much more difficult on a entire developed thesaurus. It seems possible to have such a behavior in pure CSS: https://codepen.io/anchen/pen/rGDjI
(In reply to Frédéric Demians from comment #2) > The response is yes and no. The current behavior is really important for > large thesaurus. Thanks Frédéric-- do you know of a public OPAC which would be a good example?
Hi. I might work on classification hierarchy (opac-browser) for a library, checked Koha code and found we use jstree. Glad I also did a search on bz. I don't think we actually tried to keep up with plugin upgrades, given that we bundle 1.0.-RC3 from 2011. :P Static won't work for my use case. It will be a local solution anyway, given that the feature in Koha only works for french Dewey, but I'd prefer to use what Koha uses. I'll watch this thread to see where it goes.
Hi Mirko, I think you might mean a different thing? This is for the authority detail page, not for the older opac-browser feature.
(In reply to Mirko Tietgen from comment #4) > I don't think we actually tried to keep up with plugin upgrades, given that > we bundle 1.0.-RC3 from 2011. :P If it turns out that a tree display is the best solution, then we'll certainly upgrade. I just want to make sure we're not missing an opportunity to simplify if it's appropriate.
I'm going to close this, because my proposal doesn't seem to be robust enough for everyone's needs.
Hi Owen, do you remember the issue here? I fail trying to activate the feature right now, following my own cataloguing instructions from bug 8523 comment 19