The See Also Literature and technology Book Club discussion

The book talks about the often ignored "edge cases" where users in special situations are often written off as unimportant and not worth addressing. The author reframes this concept as "stress cases" where designers are encouraged to anticipate a variety of different situations a user may be going through, so that extra care is taken to address the needs of a wider variety of people, and build a better product overall.

Can you share an example of a situation you have encountered that was handled as either an edge case or a stress case, and how the outcome might have changed if the situation were handled differently?

There is constant friction when managing collection sizes between buying and maintaining a collection for mainstream tastes and making sure that areas have representation. In Greenwich, I sense that many view the community as much more homogenous than it is. I think there are built in biases here and it is important for selectors and collection managers (those that weed a subject area for those not familiar with how we do it here in Greenwich) not to rely to heavily on what he or she thinks who a Greenwich resident is.

The case that comes to my mind is librarians arguing against bilingual registration forms and choosing not to enable the Spanish language option for the online catalog. The reasoning was that these changes would encourage Spanish-speaking patrons to use their libraries, which didn’t have adequate materials or Spanish-speaking staff to support that part of their community.

I think this was a huge missed opportunity. At a time when libraries are struggling with declining usage, I know I would welcome the possibility of reaching an untapped patron base.

A Pew Research poll from 2015 shows that "Hispanic immigrants who have made their way to a public library stand out as the most appreciative of what libraries have to offer”.

The language barrier seems like even less of an issue considering that the poll also identifies one of the most important things the library can provide to this population as simply being "a quiet, safe place”.

Even if the library doesn’t currently have adequate materials or staff for their Spanish-speaking population, those are both things that could be changed. If a community has a significant population of Spanish-speakers, then these changes are probably overdue anyway. Even if the changes only happen in small steps, that will still bring us closer to meeting the needs of an underserved community much faster than if we do nothing.

I had the revelation about "edge cases" several years ago when I was building a library catalog. We used the Agile method, but in a waterfall environment, and it didn't end up working too well. Agile forces an artificial usually-three-week launch timeline, but that forced us to frequently cut back on fully developed features, especially that had been thoroughly tested. What the principal developers deemed as edge cases were tossed out to keep up with this aggressive approach.

Once the project was terminated (after only existing in production for two years), I decided edge cases were test cases. And that proved true in that experience. We had features break when people used them in unexpected ways. Once that happened, we could cycle it back into the development flow, and our method improved, so everyone benefited.

I appreciate the intention of Agile, but in my short lived experience with it, I don't see it as viable if one wants to treat edge cases as test cases and take unit testing (especially those based on test cases) as a serious and real part of the development workflow. Perhaps it was the size of the features that "broke" Agile for us.

Amy, do you think the launched reductions would have been better if the process were slowed down? I know that it s impossible to attempt to envision all test/stress cases but what do you think is a good balance between getting a product out fast and getting it out tested?

In retrospect, what would have been an improved process includes a formal QA phase that wasn't just testing links to find broken logic but encapsulated a broader definition of "QA" and more diligent/detailed user story creation upfront.

Having the QA testers trained in UX would have really helped, and just a general awareness of emotional/cognitive considerations. We had accessibility and general usability, but from a very narrow lens. I'm not sure more extensive QA testing would have slowed down the initial launch... we even had to to cut out basic load testing to meet constantly artificial deadlines, which would have pointed out several logic faults in the code.

Management was not happy when the launch date moved three times (based on an external design firm's estimate, even though we did all the coding internally) from late December, to March, to May, and finally a beta launch in July.

It was a stressful approach, where management demanded we explain ourselves, which slowed it down even more (we were to the point of daily hour long meetings, we lost a lot of time we could have been working on those issues). Because a firm, that had no idea how to build a catalog, gave us a timeline that we said from the beginning was unreasonable.

^ This may still be a sore spot for me. ;-)

Amy wrote: "In retrospect, what would have been an improved process includes a formal QA phase that wasn't just testing links to find broken logic but encapsulated a broader definition of "QA" and more diligen..."

Yikes, I had no idea. You mentioned that the firm did not have any experience building out an OPAC but did they have any experience working with libraries?

Eric wrote: "Amy wrote: "In retrospect, what would have been an improved process includes a formal QA phase that wasn't just testing links to find broken logic but encapsulated a broader definition of "QA" and ..."

No, they were a web design firm without experience with a library website that I can recall. They were excited to do one though.