Comment 7 for bug 1869898

Revision history for this message
Jane Sandberg (sandbergja) wrote :

Thanks, Bill! The catalog is looking very good, and I'm excited to get more eyes on it. My signoffs are force-pushed to that same branch, user/sandbergja/lp1869898-ang-staff-cat-default-rebased

I also have two thoughts that came up during my testing:

1) The Broadcast Channel in the Holdings View is very helpful. It would be nice to have it in the Item Table too (one common frustration with the traditional catalog is that staff will click on Edit or Add Holdings from the item table in the embedded OPAC, do their work, and then not see those changes reflected in the item table when they get back). This would be nice to have, but not necessary; we could open a separate bug for that after merging this.

2) Angular's SPA approach means that initial load time for the Angular client can be quite long, but subsequent navigation is very quick. We are getting to the point where many staff members (not just administrators) will have to flip between AngJS and Ang interfaces to complete routine workflows. This means that staff members will regularly have to wait for the Angular client to load, but will seldom reap any of the benefits of the subsequent navigation before heading back to AngularJS.

Clearly, the solution is *more* angular, not less. But I wonder if we can re-prioritize porting interfaces to Angular. If we port over more heavily used interfaces (say, patron search and patron record), it will provide a great performance increase to a large number of users. I'd love to get rid of the last remnants of dojo too, but the performance is a more pressing concern for me right now.