I'm interested in this topic. Related to pattern libraries, I've found component-based web design useful - in particular, Atomic Design by Brad Frost (http://atomicdesign.bradfrost.com/). A mini workshop at edUi 2017 (https://edui2017.virginiahumanities.org/sessions/atomic-design/) and Designing for Digital 2019 in Austin TX featuring Brad Frost as keynote, have been helpful. Based on these, at my library I've proposed creating a Design System, which would include a pattern library of sorts, for our library website. I speculate it would be useful for a variety of needs, including branding/customization across platforms.
For context, I am also a web team of one and responsible for web development, design, and extending/maintaining our CMS (including running application and security updates)... and UX testing and accessibility consulting as well. I have a positive relationship with our university IT, web, and marketing teams, even though they use a different CMS than we do. We use Drupal 8 and they use OU Campus as their CMS.
Web Services Librarian
Albert S. Cook Library
From: Code for Libraries <[log in to unmask]> On Behalf Of Kyle Banerjee
Sent: Tuesday, May 14, 2019 4:49 PM
To: [log in to unmask]
Subject: Re: [CODE4LIB] pattern libraries
On Tue, May 14, 2019 at 11:36 AM Birkin Diana <[log in to unmask]>
> Inspired by a University web redesign, a few of us in the Library are
> beginning to investigate "pattern-libraries" to help us make and keep
> the look & feel of our disparate systems more in-sync with one another....
> To those of you that use, or have experimented with pattern-libraries,
> or something similar...
> - Are they used widely across the different library systems you have?
It's an institutional requirement for anything served from our organizational domain.
> - Do you as developers, designers, etc embrace their use? Chafe
> under perceived constraints?
Embrace the concept, but reality is messy. Three major issues: 1) Such patterns are typically based on naive use cases that are totally out of whack with services that actually do anything ; 2) Patterns assume what systems can and cannot do as well as what the people working on them can and cannot change. These assumptions are often spectacularly wrong; 3) Even when (1) and (2) don't apply, patterns developed for on one system are very nontrivial to implement on a system created for a different purpose which is based on totally different technology stacks. Mimicking behaviors -- especially adaptive ones -- can be very nontrivial.
> - Are there "hierarchies" of adherence? i.e. do you try to
> 'mandate', say, the header & footer, while leaving other elements more customizable?
> Or does that unnecessarily invite chaos?
Ours are mandated and it dramatically reduces chaos. But sometimes the cure is worse than the disease. Reminds me of a snake oil salesman's solution in Tom Sawyer, "..Well, I’d been selling an article to take the tartar off the teeth—and it does take it off, too, and generly the enamel along with it..."
A related but different thing I'm curious about...
> Say you have some 'canonical Library elements', like a main Library
> header and footer.
This is controlled at the institution level. So the library gets the institution elements down to having every element of the footer defined, and so do the specialized services.
> The direct-point/load method makes it easier to disseminate updates
> across disparate systems.
The systems are so different in what they need to make things work and the trend has been towards one of increasing complexity. This update issue is only going to get worse for us.