Ahhh, Lyle Lanley! A project manager’s worst fear. A shiny, charismatic confidence man who deftly convinces a group of mainly heuristic-based decision makers, to approve and prioritize a project that nearly obliterates a town. Meanwhile, the voice of more algorithmic-based decision logic, Marge Simpson, who wanted to repair the potholes up and down Main Street, is abruptly silenced with the reply, “Sorry Marge, the mob has spoken!”
Throughout the course of over 625 episodes, we have learned that Marge is usually right, and is the consistent purveyor of good advice and solid decision making. We also have learned that Homer has his own unique way of thinking through the outcomes of his choices.
However, despite Marge vs. the Monorail being one of the classic “What did Homer do now” episodes, it is fair to suggest that both styles of decision making voiced in the Springfield Town Hall have value. Heuristic decision making is based on quick and simple choices. Mental shortcuts, which can feel like the best decision in the moment but may not always be right for the longer term, or free from personal bias. Algorithmic decision making attempts to derive the “right” answer and eliminate anything irrational from the outcome, but algorithms take time and have difficulty factoring in nuances of human dynamics, like how regal that sash makes Homer look!
So, why did I want to blog about the 5 Whys? Well, much like the study of failure as insight into how humans think, so is the examination of how we ask questions and make decisions. At its core, asking questions is about problem solving. We ask questions to acquire and assess information about a topic, and use this as criteria to make decisions. It sounds straightforward, doesn’t it? We must all be experts at decision making, given that an average person makes hundreds of decisions a day, from what to wear, to your personalized Starbucks order, or about how close you think you are to the signal, as the light turns from green to yellow. But decision making can be a deeply challenging endeavor. Philosophers from Plato to Hume have wondered if there was room in decision making for anything other than pure logic, or if it should be reason that follows passion. Revisiting Plato’s ship of state metaphor, we know he believed that decision making should reflect both our knowledge and values. Socrates spoke about asking questions and decision making, in terms of developing citizens to “produce a flourishing city-state” through reasoning and logical debate. One could conclude that the objective of questioning and reasoning your way through issues, is to cultivate a culture of appreciative inquiry, with the outcome of improving the quality of work and life. This would apply to individuals, as well as teams and organizations. I mean we all want to know why, right?
Everyone has heard at least once, that the quality of our lives is directly based on the decisions we make. Such adages as, “you are what you eat,” or “you are what you read,” or “your face is a ship of state!” So, it would follow that good decisions are predicated on a robust process of inquiry for making them. Two notable techniques for asking questions to arrive at a decision/conclusion are the 5 Whys and the Socratic method. The 5 Whys is an attempt to identify root-cause by asking more probing and clarifying questions with each new piece of information received. Ideally, you work through the perceived symptoms of an issue until you reach the true problem. The Socratic method is a process of hypothesis elimination, wherein you search for general truths and analyze them to determine their consistency with other relative beliefs. The Socratic method also utilizes a sequence of questions, including asking opening questions to generate a discussion, then moving to several guiding questions to elaborate, and finally asking closing questions to summarize what feedback was provided and bringing the discussion back to the original problem statement. The 5 Whys and the Socratic method are only a few of the options available for approaching decision making. In general, a good first step is developing a habit of asking questions and advocating for information. Just as we would tell our patrons to do. Just as a democracy should function. Advocate for information!
With any decision making body, the goal should be to follow a consistent methodology that helps accurately identify the problem, business need, or functional requirement, so a valid and sustainable decision can be developed. If no investment is made in asking questions about the root problem/need, any investment made in a solution will be out of alignment. Some other approaches to help gather information and ask questions include peer review and benchmarking. Inevitably someone out there has attempted what you are considering, to varying degrees of success. Asking your peers questions about their decision making process and experience can produce invaluable insights. How did they evaluate the information for a decision? What were their resources and constraints? With hindsight, would they do the same again? Did it put their town on the map?
Evaluating vendors and making site visits are other helpful information gathering steps to take before making a decision. Throughout our implementation of the ArchivesSpace public user interface at Yale, we made multiple “site visits” talking with the good people of Harvard, University of Louisville, NC State, and Georgia Tech. They shared with us what they decided, how they did it, and how they were going to continue. In turn, we shared, and will continue to share, the artifacts of our project team, and outcomes of implementation. (In fact, I think we still owe GT our request de-duplication process). Part of the original intent of the 5 Whys was to physically go and see the problem being described, or the solution in place, and not ask questions from too far a distance. And following up with a vendor to validate they can deliver what they promised is essential. Don’t sign anything until you do!
There is an artistry to question asking. As a facilitator, or business analyst, you want to be mindful not to lead a person too much, or to ask only binary questions. Question asking should be designed to help us validate what we think or know, and help us determine what is unknown. It can be much harder to identify what is unknown, however even acknowledging that there are unknowns is an important step in decision making. An approach to try is called Humble Inquiry. Try asking each person to say one thing they don’t know about the proposal in front of them, and offer to go first to show there is no stigma with not having all the answers. The questions asked by a decision-making body should be constructed in such a way, that they can challenge any assumptions inherent in the problem statement, or project proposal. For example, if a member of the team states we should make decision A, “because it’s the best and others are doing it already” then there should be follow up questions that help document why it is the best (what are the points of comparison), and questions that document how your organization is similar and different from these other places. Advocate for that information. Another important question is “does the solution meet the stated business need?” And again, document how and to what extent it does resolve the need. Questions should strive to broaden our view of any problem or statement being presented. Questions should prompt us to consider alternatives, including low-tech, or no-tech solutions. They should also help an organization determine if the timing is right for a decision. Questions such as, “What if we waited 6 months? Or, a year?” are good examples to generate discussion about the issue and describe the near-term environment. Asking exploratory, or adjoining questions can be useful to take a proposed solution through several variations and perspectives. These could be “what ifs?” and “how does this idea relate to that idea?” And be sure to ask clarifying questions. Even in a one-on-one conversation, something can be misunderstood.
I believe revisiting former decisions is also a worthwhile exercise in an organization. Folks shouldn’t rush to say, “but we already tried that,” or “it didn’t work before.” The data points may have changed, or other variables may have become obsolete over time, or now newly introduced. The conditions of the markets we work in are always evolving. Developing a culture of question asking, or appreciative inquiry, requires investment from management. They need to set the example and incorporate question asking and information validation into the organization’s decision, prioritization, and planning procedures. As children, we ask questions to learn and process information about the world around us. Continuing through university, we are encouraged to learn and evaluate by asking questions, and engaging in intellectual debate and dissent. But post-university a shift begins to occur, and then greater power and value is placed on stating the answer. Being certain about your choice. Being right. Acting quickly. And then, asking questions may be viewed as disruptive, or an attempt to slow progress. So, the person who asks, “Is this the best choice for us?” or “Is this sustainable over the next four years?” may not be viewed as a team player, because they aren’t tacitly agreeing.
Using the 5 Whys is also useful for identifying user stories, or functional requirements in a project. “As a processing archivist, I want to unpublish selected components in a series, so that I may prevent sensitive data from appearing in a public search result in the brand-new fancy awesome Archives at Yale discovery tool.” You have to logically walk through not just what you want, but why you need it, and what value it generates. A good 5 Whys interview could result in not only process improvements, but better product design sure to please even the most intractable of stakeholders.
Another important time to ask questions in a project lifecycle is during the After Action Review. I have previously blogged about Before Action Reviews, but the AAR is another phase in the project lifecycle to spend time in reflection. These complementary, question-driven periods in a project help set the message that what we work on is important, and so is how we work on it. The AAR typically asks three questions, “What went well?” “What could have been refined?” and “What would you change next time?” The first two questions reflect on what has happened, and the third is gathering feedback on how the organization could change their process with future projects. And ideally, the information gained should evolve into knowledge applied. By conducting an AAR and asking these questions, you may be able to determine why a problem was not detected during a project implementation, or if it was, why that problem was not prevented (or mitigated).
The 5 whys will not produce a solution for every type of problem or proposal in an organization, but I mention it as a starting place for business analysts and project managers. Developing this skill as part of your workplace culture, should lead to more open conversation and better overall problem identification. A questions-positive culture is also likely to be more creative and innovative, by honoring ideation, iterative design, and exploration. And remember, sometimes it’s OK to just let go, knowing the cosmic ballet will go on, and with the help of science (and doughnuts) everything will resolve to a happy ending.
I like to say that projects such as upgrading servers and rolling out new software are not actually IT projects. They’re really, for lack of a better phrase, human projects. They’re about analyzing business needs, altering and optimizing workflows, and making work more enjoyable and effective for everyone who uses the product or service.
The IT side of a project, while it demands precise and strict planning, is just a part of the whole show. It’s the special effects. It wows the crowd. It requires painstaking attention to detail, many months of agonizing work, and at times an enormous budget. But without excellent writing, acting, and cinematography around it, the movie is nothing but a big digital T-Rex stomping through a city surrounded by exploding cars and time-travelling liquid metal robot men.
So, with your permission, I’d like to tell you a little bit about those special effects. Welcome to The ArchivesSpace Public User Interface Technical Integration Saga.
The principal concern of the Technical Integration group is that the physical, user-facing transition from YFAD to the ArchivesSpace PUI is a smooth one. This requires notifying our patrons that the change is coming, redirecting requests for individual finding aids to the PUI instead of YFAD, transitioning YFAD touch-points to the PUI, and giving the PUI the YUL look-and-feel.
It is critical to let our patrons and stakeholders know that the finding aid tool on our site is changing. Springing changes on patrons is a sure-fire way to welcome pitchfork-wielding mobs, earn one-star Yelp reviews, and eventually be escorted from the building. None of these things is particularly good.
On the day of the soft launch, notice will be posted on the YUL home page announcing the arrival of the PUI and the sunsetting of YFAD. The notice will include a link to try out the new PUI and information on when YFAD will no longer be available.
On the day of the official cutover, notice will be posted to the YUL home page that YFAD is no longer available.
Individual libraries will have many options on how to handle their own landing pages (such as library.yale.edu/mssa) during the soft launch and after the official cutover. These options are:
The ArchivesSpace PUI search box would replace one of the landing page’s existing search boxes in the area highlighted below.
The “ArchivesSpace PUI is coming” messages can can be displayed as green “info” type of message or red “important notice” type. Below are examples of the two.
The text of the messages will be determined by the PUI Branding and Marketing Workgroup.
There is a web form available for individual libraries to easily (well, I hope easily) choose from the above options.
The trickiest part of the PUI rollout is ensuring that requests for individual finding aids are redirected to their PUI equivalent. When a patron requests the YFAD finding aid for the Harvey Williams Cushing Papers in the Yale University Library, they should be brought to the ArchivesSpace PUI finding aid for the Harvey Williams Cushing Papers in the Yale University Library.
Therefore, we need to create redirects that turn a request for a YFAD finding aid into one for its PUI finding aid on an individual basis. Redirecting individual finding aids is a very good thing, as it ensures that all existing finding aid links continue to work. More, search results in Google and other search engines (does anyone even use Bing?) will also continue to work. Even better: The redirects are done in such a way as to cause search engines to update their indexes with the PUI URL. Epic win!
The brow crinkling part of executing the redirects is that the ArchivesSpace PUI URLs are significantly different from the YFAD ones. An example of a simple redirect would be going from
old.yale.edu/foo/bar old.yale.edu/bar/foo old.yale.edu/etc . . .
to
new.yale.edu/foo/bar new.yale.edu/bar/foo new.yale.edu/etc . . .
In the above case, all that is needed is “take everything after the old server name (the part in bold) and append it to the new server name.” Coding this is simple. More simple, probably, than just writing it in English.
The YFAD-to-PUI URL changes, on the other hand, are complex. Example:
http://drs.library.yale.edu/HLTransformer/HLTransServlet?stylename=yul.ead2002.xhtml.xsl&pid=mssa:ms.0160&query=voynich&clear-stylesheet-cache=yes&hlon=yes&filter=&hitPageStart=1
must be changed to
http://puitestarchivesspace.library.yale.edu/repositories/12/resources/4462
Yikes.
It’s apparent that what comes after the server name in the first example is not the same as what comes after the server name in the second. What’s probably not apparent is that what makes the first URL unique is not anything like the second. This eliminates the possibility of making wholesale programmatic changes such as “take everything after the server name and append it to the new.”
The solution is to take each individual YFAD URL and redirect them to the new PUI URL. Unlike our first example, coding the solution is considerably more difficult than writing it in English. The existing YFAD URL must be extracted for each finding aid, and the new PUI URL must be matched up to each finding aid. This will need to be done for more than 10,000 finding aids.
Again, yikes.
By far, the toughest bit of this is to actually get the list of old URLs to new URLs. Thankfully, Mark Custer did just that and delivered the list. I honestly have no idea how he did it. I owe him many beers.
Once this list was compiled, it was not hard to process it so the unique part of the YFAD URL redirected to the new PUI URL. It was a little hairy, sure, but the process was straight-forward enough to be documented and tucked away should it ever be needed again. We now have a complete configuration file that will redirect the old to the new. Rockin’.
Here’s where the spanner gets tossed into the works: The YFAD server is itself going to be decommissioned at some point in the future when YUL has declared the PUI a success. Installing the redirect rules into the YFAD server won’t do the job. When the server is no more, no one will be home to shuttle the YFAD requests off to their shiny new PUI home. Nuts!
What now?
With a little digital slight-of-hand, we can make this operation work. We take an existing server that we know will be around for the foreseeable future, and install the redirect configuration file on it. This server will now happily escort YFAD URLs to their PUI equivalent. On the day of the official cutover, we just need to configure the network to think that the YFAD server is this new interloper (which, incidentally, is named Sapphire after my lovely and tech-savvy kitty) . Once that’s done, hey presto! the existing YFAD URLs, duped by the network into going to Sapphie, will redirect to the ArchivesSpace PUI! Yaaaaaaay!
Sadly, due to the fact that search URLs are built on-the-fly and completely dependent upon what the patron entered into the search box, it will not be possible to redirect searches. This means that old search boxes and saved (“canned”) searches will not be redirected to the PUI with the results displayed as desired. Instead, they will be brought to the PUI search page where they can re-perform the search.
YFAD has a significant presence in YUL’s web environment. The website, LibGuides, and digital exhibitions all interoperate with YFAD to some degree. Making sure that these touch-points transition from YFAD to the PUI is going to be an important part of the official cutover.
Special care will need to be given to the touch-points that include search boxes. As mentioned above, the one thing that cannot be redirected from YFAD to the PUI is a search string. If a user attempts to use a search box that searches YFAD, they will be redirected to the PUI search page rather than their search results.
Search box widgets in the the *.library.yale.edu web space will be updated for the official cutover. We have worked with stakeholders to notify us about any YFAD presence outside of the library.yale.edu web ecosystem, where we can contact their web administrators and ask them to update links.
The ArchivesSpace PUI will be rolled out in a soft launch. This means that both YFAD and the PUI will be available simultaneously to patrons and staff for four to six weeks. When the PUI is in soft launch, it will not be a beta release. It will be the real deal. While we have prepared for issues and errors as much as possible, all staff are encouraged to use and review the PUI to help us find any integration points that may have slipped through.
To provide a professional and cohesive experience for visitors, a web environment should maintain consistent interface elements and visual cues. Pulling this off in the YUL web ecosystem is a challenge as we use many back-end systems to deliver our web content: The Drupal site, FindIt, Quicksearch, Orbis, YFAD/PUI, LibGuides, LibCal, Ask Yale, CampusPress, and Omeka. I’m probably forgetting a few.
It’s important that we integrate the PUI look-and-feel into the YUL website’s as much as possible. The Technical Integration group will bring the YUL identity to the PUI by carrying over the YUL color scheme and general branding. The Technical Integration group will also develop documentation and suggestions on what else can be done to make the PUI experience integrate more with the YUL website’s. Having a consistent and holistic web ecosystem goes beyond colors and fonts. Having consistent location, purpose, and actions of interface widgets, a clearly understood objective of each application or component, and seamless transitions from one touchpoint to another are the ultimate goals.
At the end of the day, we are providing a tool that must make it easier for our patrons to discover special collections material while streamlining and improving the workflow of Library staff. The ArchivesSpace PUI must work for them. To that end, we will be providing a feedback mechanism in the PUI that will collect the thoughts of staff and patrons throughout the soft launch period. The feedback will provide invaluable insight regarding which parts of the tool are working and which parts could be improved.
I hope this provides a behind-the-scenes look at the special effects of the ArchivesSpace Public User Interface rollout. It’s a complex and difficult part of an even more complex and more difficult whole. It doesn’t make the movie into a great movie on its own. Special effects have its own Academy Award, but ask yourself this: Was Total Recall really the best film of 1990 just because it won the Oscar for best special effects?
@YALELIBRARY
© 2022 Yale University Library • All Rights Reserved
