Skip to content

Category: Tools and Technology

Information Architecture, from information about architecture

I’ve just started work with a team of people who are going to be redoing our library website’s information architecture. Maybe some design, but mostly the structure. So of course I do that thing that I do so often and try to figure out how to think about the problem at hand before actually diving into the problem at hand. And this time I seem to be doing that by reading about architecture.

I’m not the first one to do this, by any means. There’s a great talk by Dr. Molly Wright Steenson from this month’s MinneWebCon that lays out lineage of current artificial intelligence work, including the inheritance from architecture. And her talk reminded me that this is exactly what I needed to think about again in order to think about our website structure.

So I went down into the stacks and checked out Christopher Alexander’s two most famous works, A Pattern Language and The Timeless Way of Building. These are two very very large works of architectural philosophy, so there’s no way that I’ll be able to read and apply them thoroughly to my current project, but something is better than nothing, right?

And then, on page 55 of The Timeless Way of Building, the primary claim from Chapter Four jumped out at me:

We must begin by understanding that every place is given its character by certain patterns of events that keep on happening there.

This is “the user is not broken” stated a different way. Spaces are set up, and people will behave in relatively consistent ways in those spaces depending on the affordances of the environment. If they do things we think are wrong, and especially if they do them consistently, then we have clearly set up a space that invites those events. The user was not broken; our design was broken. But Alexander’s formlation works better as an aspiration to achieve rather than a resignation to past failures. If we can know these patterns that environments evoke, we can design environments that evoke patters we want. If we set up a space (physical or digital) that invites the kinds of events that our community wants and needs (actions, reactions, experiences), and invites these events consistently, then that is a space that has Alexander’s “quality that cannot be named” that animates every successful design. (He goes into detail about definitions of that quality in chapter 2, but I won’t do the same here. You can go puzzle over that chapter if you want to, but my big short-hand for it all is “it works beautifully.”)

He then usefully qualifies his thesis:

This does not mean that space creates events, or that it causes them.

For example, in a modern town, the concrete spatial pattern of a sidewalk does not ’cause’ the kinds of human behavior that happen there.

What happens in much more complex. The people on the sidewalk, being culture-bound, know that the space which they are part of is a sidewalk, and, as part of their culture, they have the pattern of a sidewalk in their minds. (72, emphasis original)

And, in the same way, the patterns of events which govern life… cannot be separated from the space where they occur. (73, emphasis original)

So what are similar structural digital elements that we could switch out for “sidewalk” here? Search box? Menu? Bullet point? We have to keep in mind that in our culture, these things call on a whole network of cultural-bound events. We cannot say “well, we know that search boxes you’re familiar with when doing research are boxes that search through the full text or at least a paragraph of text, but this particular search box searches through a list of library research tools instead.” (Incidentally, this is part of what makes the MLA International Bibliography so hard to use and teach.) People will fall into patterns and perform topic searches in that search box, and they will do so over and over again. And they will wonder why our search box is broken. These patterns are patterns that we can often predict, and good intentions won’t matter if you ignore these predictions.

That said, we can help shape the patterns that happen again and again. For example, we don’t have to blindly follow our novice patrons to their best-known patterns just because many of our patrons are novices. We have to know what they expect and their habitual patterns, and also the expectations and patterns of the experts on our campus, and we have to create systems that invite useful events for all. This may mean educational events that help the novices learn the patterns that are typical of the new culture they have entered. This may involve educational events that help experts navigate evolving systems and patterns and academic cultures. But these educational events can’t happen unless we build bridges for the inhabitants of our spaces (digital and physical) from the patterns they have known to the patterns they are developing.

Alexander, Christopher. 1977. A Pattern Language: Towns, Buildings, Construction. New York: Oxford University Press.

———. 1979. The Timeless Way of Building. New York: Oxford University Press.

Comments closed

Chicago Manual of Style, 17th Edition, for EndNote and Zotero

I haven’t tested it extensively yet, but Zotero has released an updated Chicago style. I see that my version of Zotero automatically updated itself to include this new style, but if yours doesn’t for whatever reason you can always load it from the Zotero Style Repository.

Meanwhile, EndNote hasn’t yet released Chicago 17, so I spent some time this week developing that. Here’s a zip folder with an EndNote style for Notes & Bibliography and another style for Author-Date. In the style description for each one, I’ve also added some help text for how to manage a couple of things that weren’t very straightforward in the EndNote style coding. Feel free to use, share, and improve upon these styles.

As always, if you notice something that can be improved or that I got wrong, please let me know!

Comments closed

A librarian plays with javascript for the first time

A few times this summer my work with libguides left me turning to people for help with what felt like basic stuff, and each time the answer was “Oh, here are 2 lines of javascript that’ll solve your problem.” So I got jealous. I want to be able to know when two lines of javascript will solve all my problems, and what two lines those might be. Plus, I hate bothering busy people for tiny stuff.

Meanwhile, the other librarians and I were trying to figure out a clear and consistent way to link to catalog records from our Book assets in Libguides. Sure, there’s a URL field there, but over and over we’ve seen people think that if the title is a link, that means that the full text is behind the link. So they open the catalog, see what is clearly information about a book, and then proceed to use the catalog’s search bar to “search inside the book.” Then they’re confused when they just get results for more books. So they open their book again, and try it again. Endless frustrating loop. Also, we actually do have quite a few ebooks, so it’s extra confusing when some of those linked book titles go to ebooks and some go to catalog records. Not a great usability scenario.

So I thought “Well, we can just put a little HTML link in the book’s description box that makes it clear that this link, unlike the title link, leads to a catalog record. But 1) writing a bunch of HTML by hand can lead to errors, and worse, 2) not everyone is comfortable writing HTML by hand. But we did really want a second URL field with clarifying language, reserving linked titles for ebooks.

This, then, was the perfect project for me to learn Javascript. What could possibly go wrong? Here are my two methods of teaching myself from scratch:

  1. W3schools (especially fiddling with their “try it” setups to see if I can figure out how and why things work)
  2. Googling everything I want to do, one thing at a time, and hoping someone else on Stackoverflow has asked a similar question, and that whatever answers they got there will work if copied and pasted into my code.

I started thinking I could get away with making a bookmarklet, but since it turns out that browsers generally don’t allow you to access your clipboard except in very limited circumstances, and that many websites (including our catalog and libguides, the only two sites I cared about) don’t let me inject HTML to build a popup form to get around the lack of access to the clipboard, I finally had to admit that a bookmarklet would not work for me.

So then, according to the developers who helped and encouraged me along over on Mokum, it was time to start thinking about coding a browser extension. It took me a couple of days to admit this to myself because it sounded scary and complicated, but eventually I took this tutorial and its sample files by the horns and dived in. Along the way I got valuable hints from a friend to pay attention to the order of operations (at this point that means I just try things in various orders, but some day soon I hope to actually know what I’m doing), and to use the built in “Inspect” console in Chrome to debug the Javascript (which until now I’d only thought about as being a tool for HTML and CSS stuff).

And today, nine days later, I published my extension to Chrome and to Firefox! Now adding links to catalog records is quick and consistent for everyone in my department. (And if you want the unpacked files to mess around with, here you go, though I must warn you that I am NOT an expert so there may be stuff in here to make an expert weep, or laugh. Any and all suggestions for improvement are welcome.)

At this point I’m only just barely good enough to try lots of things in hopes that one of the things will work, and then to move on to the next thing. And I’m still very hampered by only having the vaguest idea what’s possible and (almost more important) what’s impossible. But who knows, maybe sometime soon I’ll have another tedious workflow that I can speed up by getting my computer to do a bunch of the tedious part for me. The world is my oyster!

2 Comments

Custom LibGuides Page Layouts, Terminology, and CSS

As you probably figured out from my last post, it’s been a Libguides kind of summer around here. We updated all our links to our catalog, got things ready to publish the Libguides databases list rather than our old other-CMS databases list, changed all internal links to database lists, migrated from WorldCat on FirstSearch to WorldCat Discovery links, and did the annual (painful) clean-up of the assets inventory (merging duplicate assets, deleting un-mapped assets, fixing wonky assets…).

For me the most fun part, though, was updating the custom page layouts, custom terminology, and custom CSS. And I thought I’d share my work in case it’s useful to others.

Custom Page Layouts

Under Admin > Look & Feel > Page Layout, I’ve customized several of our page types. If you want the code for these just let me know and I’ll share.

Guide pages now don’t display that tab name after the Guide name, plus various small tweaks.

We don’t use the system-generated homepage and instead made a guide to use as a custom home page, entering its URL into the redirect URL spot under “Homepage boxes/Redirect.”

For Subject Pages, I flipped the order of the tabs so that people are presented first with useful databases for the topic and then with useful guides for the topic. And I completely hid the tab for blogs because we don’t have any of those and don’t plan to.

For Database A-Z pages, I changed things up so that our QuestionPoint chat widget could sit in the upper right-hand corner, and to hide elements we didn’t want.

Custom Terminology

I’d thought this was only to set the system language, like “English,” but no, there’s a whole section where you can change system-generated labels for things. Go to Admin > Look & Feel > Language Options, and then click on the Language Customization section. Behold, a whole trove of system language that you can tweak to match your local terminology.

Custom CSS

Here’s my custom CSS as of July 2017. You can feel free to take or modify whatever you like from my style. (If you’ve never done this before, just copy and paste everything in my text document into the code box in Libguides under Admin > Look & Feel > Custom JS/CSS and then delete bits or tinker with bits as you like. I use w3schools with wild abandon as I cobble together my amateur CSS.)

My guiding principles

  • Make it so that the librarians can let the CSS do most of the formatting work for them.
  • Clean, uniform looking lists of databases, assets, system-generated lists (widgets), etc, so that no matter how a librarian decides to add pointers in their guides, things will look relatively uniform.
  • Allow for the flexibility that our librarians really value. We value uniformity when that helps the users and when it helps us re-use each other’s assets, but we value the ability to make guides work for a variety of contexts and not tie one librarian to another librarian’s style (though I’m the CSS overlord, so my style is a little more equal than other people’s styles, I guess).
  • This is also why we have a Style Sheet for librarians who create guides, with the idea that the more specialized your work, the more you can do whatever you want, but if you’re doing stuff that others might want to pull into their own guides, some uniformity is useful. (It’s also a handy place to dump little “how to do this complicated thing” tutorials.)

What my custom style sheet does:

Since the Libguides CSS editor doesn’t seem to allow me to comment out my code, here’s some narration about what my code does.

  • First (from the line starting at “body” to the line starting at “li”), I lay down some ground rules for fonts and colors, especially changing links to be bolded rather than underlined, which worked better in our style.
  • The next several lines make the various kinds of things you can put into a box in libguides conform to the same style rules (so that book elements look similar to database elements or link elements, etc), and also hides some elements that we considered less necessary and more apt to contribute to clutter.
    • Removes bullet points and fiddles with spacing around asset lists and system-generated lists so that they’re all uniform.
    • Unbolds the names of guide owners under guides linked using the “guide list” feature in the add/reorder dropdown.
    • Makes book call numbers italicized
    • Hides ISBNs and publication dates in Book assets
    • Hides “last updated date” and number of views from “guide list” links.
  • The next section deals with the layout of some of the most common elements on research guides, removing shadows from boxes and setting fonts and basic styling for tabs and boxes.
  • The next section governs headings and block quotes – very basic stuff
  • Then comes four lines that clean up the Databases A-Z list, hiding the “share” buttons on database lists and hiding both the automatic search box that appears throughout Libguides and the “search within the databases a-z list” search box. This is because we have YEARS of data from our old cms showing that if there’s a search box on a page that lists databases, people enter search terms into it that make it clear that they think they’re searching within the databases. If they want to find a particular database, they use control-F on the web page instead. There was also an interesting talk at this year’s ACRL where people used eye-tracking software and found that people can’t help themselves — they’re drawn to search boxes. And if there are extra search boxes on the page it’ll just confuse the issue.
  • The .dont-break-out line in the CSS is a thing that librarians can employ if they need to display a very long URL and they want to make sure it won’t bleed out of its box, particularly on smaller screens. I didn’t apply it to the system as a whole because I’m not quite sure what all it’ll mess up, but on our Zotero guide I have to make it easy for people to copy and paste our OpenURL resolver link, and the thing is ridiculously long, and this was the only way to force it to wrap in Chrome. So in a Rich Text content item I wrapped the URL in a div tag that called this special class, thusly:
    And now even in Chrome at very narrow browser widths the URL wraps neatly onto new lines.
  • The remainder of the style sheet changes the way that image gallery boxes display, making things simple and clean, and usually even readable if there’s caption text.

So there you have it. That’s what I’ve been up to in the Look & Feel department this summer.

Comments closed