Pennsylvania Integrated Library System began implementing the Web Client in early January; initially in test mode, but now several of our libraries are using it in production, and we are deploying to more of our 121 libraries as training allows. (Our new migrations never even get to see XUL.) Our experience has been much different. Now let me start by saying the our consortium carries an inherent bias against XUL. XUL’s slowness, especially in libraries with bandwidth challenges, is a source of many complaints and creates a barrier when trying to get additional libraries to join the consortium because people talk. Evergreen was getting a reputation in PA as the “slow ILS.” Given the substantial performance improvements with the Web Client (and some of the cool new Web Client-only features like emailing of receipts, User Buckets, and User Search in Place Hold), our libraries are willing to overlook some (mostly) minor bugs.
To date we have documented 56 issues that are affecting us. This was expected and not a cause for concern. Most are minor issues that can be worked around, but a few are very problematic for some of our constituencies. Our libraries that generate pocket labels by uploading a .csv from the Item Status grid into a 3rd party software are stymied by having authors and titles in lower-case. Our larger libraries are not pleased with the bug (probably a decision) to limit displays of non-bucket grids to 100 lines. We are fixing these. (More accurately we are contracting with another entity to have them fixed because we do not employ a developer that can contribute Evergreen code.) Evergreen belongs to us (all of us), and, if we don’t like something about it, it is up to us to fix it. Kathy and the original team who worked on the Web Client should be saluted for bringing it so far. Now additional libraries are starting to use it. Are we finding bugs? Sure. Do we disagree with some of the decisions made? Absolutely. (I will disagree with one thing Kathy said: over the year I have done several client changes with proprietary ILSs and always found very few bugs or problems, but these companies had a room full of testers. In an open source environment, the testing and reporting and fixing is on us.) If there are bugs that you find very problematic and, like us, do not have direct access to developers who can contribute code to Evergreen, contract with an entity who can. If you don’t have the resources to completely fund a bug fix on your own, post to this list and see if you can find funding partners. Again, we are just happy that our staff members no longer have time to get a cup of coffee while waiting for a patron search to complete. Scott Scott Thomas Executive Director PaILS / SPARK (717) 873-9461 [email protected]<mailto:[email protected]> [Description: Description: Training | SPARK – Pennsylvania's Statewide Library System]<http://www.palibrary.org/pails/> From: Open-ils-general [mailto:[email protected]] On Behalf Of Kathy Lussier Sent: Friday, March 16, 2018 4:55 PM To: [email protected] Subject: Re: [OPEN-ILS-GENERAL] discouraged >> Back in the Template Toolkit days, there was a tag we used in Launchpad that >> identified bugs we thought should be fixed before removing the old catalog >> from Evergreen. Maybe we could consider doing something similar for the web >> client. << I like that idea. Although our circulation staff have moved over to the web client for the most part, there are still some major roadblocks that need to be overcome in cataloging before we are able to move everyone over completely. I like the idea too, but, along with it, there also needs to be a commitment to make sure bugs with those tags get fixed before the old client is removed. IIRC, the old javascript catalog was removed before many of those bugs were fixed because nobody directed their developers, funded development, etc. to get those bugs addressed. I think the tag is a good way to organize the bugs and highlight the important ones, but it doesn't offer a guarantee that they will be fixed without that commitment. Kathy On 03/16/2018 04:20 PM, Terran McCanna wrote: >> Back in the Template Toolkit days, there was a tag we used in Launchpad that >> identified bugs we thought should be fixed before removing the old catalog >> from Evergreen. Maybe we could consider doing something similar for the web >> client. << I like that idea. Although our circulation staff have moved over to the web client for the most part, there are still some major roadblocks that need to be overcome in cataloging before we are able to move everyone over completely. Terran McCanna PINES Program Manager Georgia Public Library Service 1800 Century Place, Suite 150 Atlanta, GA 30345 404-235-7138 [email protected]<mailto:[email protected]> On Fri, Mar 16, 2018 at 4:08 PM, Kathy Lussier <[email protected]<mailto:[email protected]>> wrote: Hi Diane, I'm sorry to hear your frustration, but I can also empathize. While working on a recent project to sponsor more bug fixes for the web client, I also got discouraged as new bugs were reported, particularly when they were ones that would have made our priority list if we had known about them at the time we were selecting bugs to fix. To keep myself from getting discouraged, I found it helped to keep some things in mind. - Despite the current open bugs, the web client has come a long way just in the past year. Setting aside the addition of serials and offline, there has been a lot of bug fixing over the last months. In many cases, the fixes have been for what I consider to be showstopper bugs. I continued to see this work even today as I was going through my bug mail. It might be useful for the community to track statistics of how many web client bugs are getting fixed on a monthly basis to help us see the progress that's been done. Looking at the 3.0 point release notes is also a good way to see how much work has been done. - There were many people, including myself, who spent a lot of time testing the web client when the code was initially written, but, no matter how much testing was done, we knew that there are just some bugs that just won't be found until people start using it in production. This isn't unique to Evergreen or open-source software, but is something I've seen when using proprietary software as well. We tried to catch some of these bugs by having 2.12 available for trial use in production, but I don't think most sites really started using the web client heavily until 3.0, which was just released in October. I would say the flurry of bug reporting since that time is an expected part of the process of eventually getting to a more stable web client. This is also why we are keeping the xul client around through the 3.1 release, because we knew it would take time to get the web client to where it needs to be for all Evergreen users to move to it. I still remember the early days of the Template Toolkit catalog. I was equally discouraged about bugs and missing features, but as more sites started using it, they made sure features important to them were fixed or added, and we now have a stable and feature rich public catalog. - I'm worried about stating this the wrong way, but we also have to remember the number of bugs we've learned to live with under the xul client. I'm not saying we should just learn to live with the web client bugs, but they certainly are more noticeable now because they are new. There are also several xul client bugs we were able to close out because they were fixed in the web client. The important thing is that the bugs are open and known. Evergreen sites can see where the problems are and ultimately choose to focus on addressing the ones most important to them. Having said all of this, I do think it's important that if there are showstopper bugs in the web client (not annoyances, but things that really prevent you from using the web client), we need to identify those to increase the likelihood that they will be fixed ahead of other bugs. For example, one of the groups I work with recently set the bug priority to High for a handful of bugs they considered to be showstoppers. Back in the Template Toolkit days, there was a tag we used in Launchpad that identified bugs we thought should be fixed before removing the old catalog from Evergreen. Maybe we could consider doing something similar for the web client. Kathy On 03/16/2018 03:27 PM, Diane Disbro wrote: Good afternoon - I volunteered to keep track of Webby problems for the Missouri Evergreen circulation committee. I am pretty discouraged. My library began using Webby in December but there were so many frustrations that we stopped after about a month. My spreadsheet of problems now has thirty-five issue on it. Every time a new bug report is sent out my heart sinks. Diane Disbro Branch Manager/Circulation Coordinator Union Branch Scenic Regional Library 308 Hawthorne Drive<https://maps.google.com/?q=308+Hawthorne+Drive+%0D%0A+++++++++++++++++++++++++Union,+MO+%C2%A0+%C2%A0+63084&entry=gmail&source=g> Union, MO 63084<https://maps.google.com/?q=308+Hawthorne+Drive+%0D%0A+++++++++++++++++++++++++Union,+MO+%C2%A0+%C2%A0+63084&entry=gmail&source=g> (636) 583-3224<tel:%28636%29%20583-3224> -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128<tel:%28508%29%20343-0128> [email protected]<mailto:[email protected]> Twitter: http://www.twitter.com/kmlussier -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 [email protected]<mailto:[email protected]> Twitter: http://www.twitter.com/kmlussier
