CSS Grid and New Order

Hi! 👋 I gave my website a makeover. I gave it many makeovers! Here’s how that went for me last Sunday, bored and unwilling to do actually-productive and meaningful things. This is what I did and a love letter to CSS Grid Layout.

Before

old site

First, here is what I was starting with, my previous website. Fine, minimal, Josephin Sans and Open Sans courtesy of Google Fonts, with skeleton for a CSS framework, normalize.css on top of that, and some light customization on top of that (link colors, et cetera). I didn’t need that framework though, even though it is pretty and the filesize is petite.

So I stripped the site down to essentials, plain HTML. I fixed some structural issues, but overall things were already looking fine because the site is just, like, a series of paragraphs and lists with one image at the top starring me at the Pop Century Resort, 90s Section. I then added a bit of CSS to get my own basic framework in place, based on CSS Grid.

If you don’t know about Grid Layout, it is the best. I wanted to rejoice in Grid and other CSS3 features that are now functional across browser platforms, because laying out pages and designing for the web has FINALLY caught up with the way my brain thinks about things, which is from pen-on-paper and my traditional print-design education, obsession with Adobe Illustrator, structure, honoring grids while breaking them, whitespace, typography, et cetera, whatever. Here is a guide put out by Mozilla for learning more about it. This Complete Guide to Grid is good, too.

Anyway, I’ve been listening to a lot of New Order, and it also sort of felt like New Order songs were chasing me around every bar in the New York metro area for two months. Inescapable. When the season started to change at the end of summer, every year for years I would only want to listen to Boston twee pop band Pants Yell!. This time, it’s New Order, and I like to think that signifies some sort of deep emotional maturity in me, like when I was told in college that I had to be at least 30 to appreciate 10cc songs (this turned out to be true) but I don’t think it signifies anything at all. The point of this paragraph is New Order was in my head, so New Order it is. Honestly, I didn’t put a lot of thought into it because I was ready to make it happen.

Constraints

new old site

Next, I piled on the design constraints, which is the easiest way to get myself to chill out and actually focus on the task at hand.

  • CONTENT: I dedicated myself to tackling the first six New Order albums, so I could eliminate the stress of thinking about how much I liked some of the others but also saved me (because I counted Substance) from having to look at the Republic cover ever again.
  • SPACE: I can’t modify the HTML structure just because it’s convenient. I also can’t add images because it helps.
  • TIME: I want to start and finish on Sunday and not exceed Sunday and also do other things on this day.

Action

So I got to work! I spent a lot of time on Movement, because it is beautiful already, and not a lot of time on Brotherhood, because I thought it was ugly no matter what I did to it. In a lot of ways, I relied on what happens “above the fold” in the introduction portion of the website and I focused a lot of trying to assess which font that I could easily (lazily) integrate for free that would match the liner notes of each album. For the image-heavy album covers, especially Power, Corruption and Lies, I had to focus on the minimal elements of the design itself, since I constrained myself to not adding anything else, including sneaking images in through CSS. This also made Brotherhood difficult because I had to figure out how to do a metallic effect without adding any texture, and instead had to rely on CSS gradients happening all across the page.

new order
new order
new order
new order
new order
new order

After feeling accomplished (enough) with the layouts, I then had to make them work with clicking actions. I added a super tiny bit of javascript for this:

for(let btn of document.querySelectorAll('.makeover')) {
  btn.addEventListener('click', (e) => {
    document.getElementById('neworder').href = "css/" + btn.id + ".css"
  }, false);
};

And it was all good! I spent way more time than anticipated configuring the taskbar that I set at the top of my webpage into actually looking not like garbage, and unfortunately it still kind of looks like garbage (both at the front and underneath in the codebase). I was getting annoyed and impatient, because it was at the end of the day and the fun stuff had all been done already, otherwise it might look better. Maybe it will look better one day.

And then

At the end of all of this, I posted it on twitter because that’s what I do when I have completed a minimally viable product and want people to see it and maybe make it better, because I never do anything that isn’t open source unless I am forced under capitalism to do so (cats gotta eat). One friend of mine, Travis, jokingly asked where the Unknown Pleasures easter egg was going to be, and I went into a witch-cackle laughing frenzy until it came into existence, which took only a few minutes. I won’t tell you where it is, but it’s also pretty obvious. I also had forsaken using viewports to trick the Movement stylesheet into working well, but I ended up making it come back so things resized better on phones, and then had to patch the kinda-shady methods with which I was causing things to come together, but it was imperfect. Another pal, Aidan, who happens to be a designer-who-misses-CSS, seemed to be bored enough at work to fix some problems for me, including the aforementioned one, which is ideal. It’s nice to collaborate and iterate!

old site

What’s next?

Yeah, like, this could get way more slick, I just didn’t want to keep spending time on it. Like, soft animations can go a long way in making the site more polished and more welcoming, so I’d like to add some of those. I also still want to add the U.K. edition of Ceremony which I think is really visually appealing in a way I’d like to make work on the web? I also tested this on three browsers, desktop and mobile and mobile-simulation, but I’m sure things fail in “edge” cases (Hey, is that why Microsoft rebranded IE in that way? Genius.).

Thank you for reading!

Accessibility and Archivability

Okay, so this is the follow-up post to this (or, rather, that was the aperitif post to this one). I was at the Joint Meeting of New York City & Mid-Atlantic Archive-It partner groups at METRO a little while ago, and a question came up about how to best guide creators towards good practices in the website development stage, to better support future preservation efforts. There are some guides in place for this (jump to the bottom of this page for additional resources). But, like, I’m a developer. I threw out the idea that a good guideline to use was that if a website is accessible, it should also be archivable, that these guidelines can go hand-in-hand. And people building websites should already be concerned with accessibility and aware of related best practices (and if not, they are bad at their jobs and you should replace them with good people). That sounds good, but am I right? Am I wrong? I decided to make sure I wasn’t totally full of shit, and here are the results.

The point of this post is to be able to communicate better with people who build websites, so their websites are more likely to be archivable in the future. (And I’m intentionally holding myself back from using technical jargon here.)

pc pc pc pc pc pc

What does it mean for a site to be accessible?

There are plenty of great resources to explain the basics, but fundamentally a website should be able to be accessed and understood by anybody, regardless of their level of ability. WebAIM summarizes the four major categories as visual, hearing, motor, and cognitive. Some quick ways to assess a site without any additional programs are:

  • Does the structure of the website look OK and make semantic sense?
  • Can you use your website using only your keyboard?
  • Can you size up to 200% and your site won’t break?

There are SO MANY other things to consider. That’s just the tip-top level for testing without installing tools for that purpose or having knowledge about how websites are built.

What does it mean for a site to be archiveable?

Obviously there’s a lot less written on this, but a website should be able to be saved as a WARC file by some sort of web archiving process (like Wayback Machine or Webrecorder) and look&function the same as it did when it was “live.” Can everything be “played back” in the future just as well as when it was captured for posterity?

pc pc pc pc pc pc

And how do these work together (or do they)?

Web crawlers are little robots that save your things and play them back again. Thanks, lil dudes. And one of the core principles of accessibility practice is a website’s ability to work using assistive technology (like screen readers), and those are also like little robots that read things. For accessibility in general, the content of the webpage should always be clear regardless of the way in which it is being accessed. It makes sense that if one works well, the other should work well too.

Below are a few examples that hopefully highlight how care towards accessibility helps archivability.

Example 1: Internet Girlfriend Club / Asynchronous loading

This site was loading CSS asynchronously, after everything else had loaded on the page, and it used JavaScript to do that. I don’t really know why, I guess that has a usecase somewhere, but it wasn’t necessary here. CSS is not necessary for accessibility here (but not to say that it isn’t important) – IGC passes these tests – but if something more significant was loading up in a delayed way with JavaScript, like links, it wouldn’t know how to save them because the Wayback Machine is taking things at initial-load face value. Webrecorder doesn’t have this problem, although the problem was evident by the flash of white before each page would load. Bonus note: this pattern is known as Flash of Unstyled Content (FOUC)! Fortunately, this is my website (meta-hyping here), so I was able to fix it right away. Archive yer heart out! JavaScript doesn’t have to be avoided, but it should be used carefully and correctly (and not flippantly, which I was guilty of!)

Example 2: Karlie Kloss / Wix

Karlie Kloss’s site is built in Wix, which is not very good for accessibility or archivability (this seems to be the general consensus). Accessibility-wise, trying to use this site without a mouse is impossible – it highlights something, but what is being highlighted is unclear. Fumbling, I accidentally opened a link I couldn’t see (because tabbing took me to the bottom of the page – what?), and it was this article about learning how to code. I found it in an auto-rotating carousel, above a gif. And the top nav, which is only a lil “hamburger” (the widely-hated hamburger menu), is unclear. This website is all-around bogus for a lot of other reasons and I hope Karlie calls me to fix it.

The latest version of her site shows nothing in the Wayback Machine and acts weird when making an attempt in Webrecorder, so I don’t have a lot of faith in its archivability. Karlie is just not going to make it into the archive.

awkward karlie

Example 3: Larry Polansky / Clear navigation

Lorena sent me this webpage as an example of a site that looks simple, but was difficult for her to archive. Not necessarily for technical reasons, but “it’s a rabbit hole of confusion because there is no site map and you can’t tell if you captured all the pages cause you don’t know what there is.”

Likewise, this site looks totally accessible, right? No carousel, no models, no Flash… but it’s very important to remember the website’s structure when designing/developing for accessibility and archivability. I actually laughed out loud when I looked at the HTML:

small.. small.. small

WHAAATTTT?? Hahaha. Imagining trying to get to the link on this page without being able to click on it. A screen reader might have to go through small … small .. small .. small .. until it gets to the content, and even then it is confusing.

Okay, this is a contrived example because I thiiiink a screen reader will skip past these tags because it can identify them as insignificant as it relates to the content, but this is just an example of a messy, confusing site structure. This is a good time to mention that ARIA tags should be present on websites for navigational support and those are not present, either.

Clear navigation for the entire website is crucial to archiving, and clear navigation on each page is crucial to accessibility.

Et cetera

That’s all for now, thank you! I know it’s not that much and I am missing a LOT of granularity. I didn’t even talk about Flash and other kinds of JavaScript, well-known enemies to both of these concepts. Even though Webrecorder now makes a lot of this possible, it doesn’t mean it is preferable. (Also I wasn’t willing to install Flash on my computer to test it out. 😘 ) So much more work can be done here (and I’d like to see that), with more research and better examples, but I am just one little human with a finite amount of time to spend on this!

pc pc pc pc pc pc

Resources, Accessibility

Resources, Archivability

Thank you again Karl. Thanks to Samantha Abrams and Lorena Ramirez-Lopez for sample links. I learned a lot about web accessibility in my previous role at the New York Public Library when I worked with Willa Armstrong, an expert in this area of digital ideation. Willa is the best!

How do web archiving frameworks work?

pc pc pc pc pc pc

“If you wish to make apple pie from scratch, you must first create the universe.”

If you wish to explain how web archiving works from a technical standpoint, you must first understand the ecosystem. I was anticipating (jk - it’s live now, here!!) writing a blog post about website archivability from a development perspective (“How can I make my website more archivable?”) but realized I needed to provide an overview of web archiving in general (even if just for my own comprehension). I don’t feel like this information is especially clear and available on the web – but if I am just missing out on a solid resource, let me know. Likewise, if I’m wrong about something (which I probably am), let me know. BIG THANKS to Karl-Rainer Blumenthal for speaking at the Joint Meeting of New York City & Mid-Atlantic Archive-It partner groups at METRO last week, which gave me the inspo, and for clarifying my questions on the above information (and correcting my incorrect assumptions).

OK COMPUTER

pc pc pc pc pc pc

Some champion frameworks (not counting top-dawg Wayback Machine) in the web-archiving ecosystem funnel are Archive-It and Webrecorder. There are other methods (good ol’ wget, e.g.), but these get a lot of hype. And I feel like they are frequently pitted against each other, even though they serve different purposes, so they shouldn’t be thought of in this way. Archive-It and Webrecorder are platforms that allow people to easily use the underlying web archiving technology. When unhappy with one or the other, it’s probably mostly comments on the provided design experience rather than the backend frameworks.

Archive-It is built for institutional-level integration and scale. On top of archiving, it is able to perform scheduling and also exists as a hosting service that stores this data for institutions. Webrecorder can do this too, but isn’t built with this in mind as a business model. It expects the users to manage their own digital preservation storage, although you can still save and share “recorded” websites. Webrecorder’s tagline is “Web Archiving For All!” – it really does democratize and make-more-open what Internet Archive has been doing, which makes me like it a lot. But they are different!

So, technically…

pc pc pc pc pc pc

This section should really emphasize the power of open source tools. Are you ready?

First! All these tools produce the same output, the WARC (Web ARChive) file format. Standards are great. This is ostensibly an open format, although unfortunately standardized through ISO, so it’s not free to view. (But that is a personal digression…) The IIPC (International Internet Preservation Consortium) has put together an open warc-specifications page for more information about this, specifically here, which seems to be very close to what is probably in the official ISO that costs a hundred bucks. Anyway, WARC is essentially a wrapper for web-related materials, and it aggregates that information along with relevant metadata for future context. Like a zip file, but specifically made for websites.

Second! Here things get more complicated.

Internet Archive’s Wayback Machine is built on Heritrix (heritrix3), web-crawling software. Heritrix is built in Java. It does the heavy work of turning websites into web archives. The Wayback Machine used to use a Java-based framework for “replaying” archived websites, but it was re-written in Python, so now it uses that. It also depends on umbra a queue-based browser automation tool, to grab up those sites and dependencies.

Archive-It’s stack looks like the Wayback Machine, for the most part. However! Archive-It is transitioning to using brozzler and warcprox. Brozzler is built on top of Chromium, among other things, and is able to view and “replay” websites. warcprox is built on pymiproxy and helps with turning the websites into WARC files. Combined, and built on the tools below, they are able to do the work of grabbing (brozzler) and saving (warcprox) websites. For audiovisual material, it uses youtube-dl, an open source tool for downloading media (and not just for YouTube, despite the name).

Webrecorder, on the other hand, depends on pywb, a Python implementation of the Wayback Machine, for the “replaying” of the generated web archives. For capture, warcprox, I think, but not necessarily. Webrecorder is then developed on top of pywb (conveniently both primary created by web archiving developer superstar Ilya Kreymer!)

Nota bene Open source is great! We can do so many great things because people have shared their code and collaborated together, and have been able to build things on top of other things.

pc pc pc pc pc pc

More!

For more web archiving resources, see…

OK, stay tuned while I put together the blog post I originally intended to write, about web accessibility and website archivability, in which I argue with myself about both. Update: here.

The Collection Management System Collection

Crowd-sourcing a list of digital repository options.

Here is the spreadsheet!

Hey hey. It seems like every couple of months, I get asked for advice on picking a Collection Management System (or maybe referred to as a digital repository, or something else) for use in an archive, special collection library, museum, or another small “GLAMorous” institution. The acronym is CMS, which is not to be confused with Content Management System (which is for your blog). This can be for collection management, digital asset management, collection description, digital preservation, public access and request support, or combinations of all of the above. And these things have to fit into an existing workflow/system, or maybe replace an old system and require a data migration component. And on top of that, there are so many options out there! This can be overwhelming!

What factors do you use in making a decision? I tried to put together some crucial components to consider, while keeping it as simple as possible (if 19 columns can be considered simple). I also want to be able to answer questions with a strong yes/no, to avoid getting bogged down in “well, kinda…” For example, I had a “Price” category and a “Handles complex media?” category but I took them away because it was too subjective of an issue to be able to give an easy answer. A lot of these are still going to be “well, kinda” and in that case, we should make a generalization. (Ah, this is where the “simple” part comes in!)

In the end, though, it is really going to depend on the unique needs of your institution, so the answer is always going to be “well, kinda?” But I hope this spreadsheet can be used as a starting point for those preparing to make a decision, or those who need to jog their memory with “Can this thing do that?”

And of course, like many of my previous endeavors, this spreadsheet is OPEN and CONTRIBUTIONS ARE WELCOME! Help me make this resource better. I need help with adding software, adding consideration columns (lets not go too wild here though), and (MOST OF ALL!) filling in yes/no answers for each row.

Here is the spreadsheet!

Editing is open right now, but I will change it to comment-only when it is more robust.

Here is a guide to the columns:

Basic information

  • Name
  • Website

Administration considerations

  • Loan/request management (Can it manage sending stuff out and getting it back?)
  • Multilingual (Can it support multiple languages?)
  • Permissions (For user permissions within the organization, or for the public.)
  • Physical (Stores physical location of assets?)
  • Reporting (Exports data/spreadsheets/charts/PDFs for your boss.)
  • Rights (Copyright stuff)
  • Tasking (Can you assign tasks? Who is working on what? )

Interface considerations

  • Access (Does this come with a public online access portal?)
  • Batch edit (Are there ways to change data in ways more significant than one-at-a-time?)
  • Collection mgmt (Can it perform CRUD operations [Create, Read, Update, Delete]?)
  • Digital asset management (Suitable as a digital asset management system?)
  • Preservation (Suitable for digital preservation?)

Technical considerations

  • Open source (Is the software open source or not?)
  • Import/export (Getting data in, getting data out?)
  • API (Has an API and/or supports integration with other systems?)

Social considerations

  • Support (Can you ask or pay an organization to fix things for you?)
  • Community (Is there a large community using it, and support potentially found there?)

Thank you! Please help and contribute!

See Also

Thanks to Selena Chau for initiating this idea in my mind, and for her helpful research as an AAPB NDSR.

Thanks, team: My time at the New York Public Library

I said I wouldn’t write a cheesy (or grumpy) Medium post about me leaving my current job, so I guess it’s fortunate I have my own blogging platform and I don’t have to be a hypocrite about it! 😘

Today is my last day at the 🦁 New York Public Library 🦁, where I’ve spent the past two years as an applications developer. Like others before me (it is an honor to always be in Matt’s shadow 🗣), I spent some time reflecting on my work there and, more importantly, the wonderful people I spent time working with. 👩‍💻

🏛 For an overview of the infrastructure of my time at the NYPL for the majority of my tenure, I recommend this chart I made. 📈 I spent most of my time there in an amalgamation-team informally known as the repository team, managing all systems and processes related to a digital archival object’s life cycle – for digital images, audio and moving image assets, and (the ever-difficult) archival finding aids: three pipelines with dozens of applications, with some weight towards maintenance and new features for our Metadata Management System, Digital Collections, our public-facing API, our Archives Stack, a major media ingest initiative, and the links in between. 🍝 Juggling this many applications in a stack can seem at-first daunting and then seem exhausting, but I found it endlessly thrilling, with an immense number of problems to solve. 🥂 It was so thoroughly rewarding to be able to see a direct impact on the daily work lives of NYPL metadata creators, archivists, curatorial assistants, and catalogers and also to directly impact and benefit patrons located everywhere in the world. 🌞 It was truly a dream job while it was my job. ⚡️

I have a lot of people to thank for sharing this time with me. 🙏

💎 Kris and Stephen, how could I ask for a better duo of senior engineers to catch me up with the aforementioned myriad of applications served by the understated Repo Team? 🕴 Kris, I promise you Pretty Little Liars is the modern-day Twin Peaks, even more than the new Twin Peaks, and you just have to trust me on that, and I will miss discussing this with you. 💁 Stephen, you are the kindest code mentor I could fathom having and a true delight to have shared an office and multiple Spotify playlists with. You are my favorite person – just don’t tell Josh.

📝 Josh and Shawn, thanks for stepping in and being the best managers a developer could ask for, even as it was above and beyond your existing job duties. 🛰 Josh, you KNOW you are my favorite person (don’t tell Stephen) and I wasn’t kidding when I said I was going to print out a picture of your face and hide it in my refrigerator so I can regularly greet this symbol of you with the joy and enthusiasm you’ve become accustomed to receiving. 🔭 Shawn, you are a metadata genius and I have learned so much from you. I know we will still see each other often and I hope to work with you again in the future.

📖 Metadata Services Unit, Digital Imaging Unit, Digital Rights Unit: Thanks for your quick feedback and patience while bug-testing in our QA environments. I miss our regularly scheduled meetings. 📮 Sara, I will miss your expansive expertise. 📸 Eric, thanks for teaching me about Russian Caravan tea. 📜 Greg and Kaiwa, your work ensuring copyright for our assets is tremendous and invaluable, and I appreciate your dedication to creating policies as open and patron-serving as possible.

🏄‍🏙📚💃🎛⛵️ All my Labs ladies, thanks so much for the support, camaraderie, encouragement, gut-checking, karaoke sessions, emoji research, emergency black sesame soft serve invitations. I know we’ll be jamming out together far into the future so I will save the accolades. Thanks for always being 💖 and staying 💅.

🤠🚀🎼🍍😑👾🏆 All my Labs fellas, I love each and every one of you. Some of you, I didn’t get nearly enough time with. And others, I’m glad for the time we did have to work together, even under extremely weird circumstances, and for the time I spent working with your codebases despite your distance or absence.

🕵🏻 Front-end dev team (the FEDs) – Thanks for showing me your deployment patterns and all the strange ways older versions of React require workarounds. ⚛️ Edwin and Kang, thanks for putting up with my fumbling through a new code infrastructure. 🏃 Edwin, thanks for reviewing pull requests outside of work hours to keep me in place and successfully onboarded to your project even while you’ve been placed 100% onto other active projects. 💪 Rafael, thanks for being everyone’s unofficial physical therapist. 🍖 Ricardo, keep it real. 🏂 (Lack of a sk8r emoji is bogus.)

🎏 Ho-Ling, your enthusiasm is endless and endlessly contagious, you are infinitely funny and kind and so generous with snacks. 🔌 Greg, I will miss catching your face when you are trying to solve a particularly hard problem, and your pleasant demeanor even when we are both grumpy. 🎲 Kevin, I appreciate your board game night initiative and apologize for my partial attendance. 💻 Jobin, I will miss your optimism.

💾 Nick, when you first started I thought you were a jerk because you are sometimes bad at Twitter, but I was wrong. I now know you are a true ally and valuable asset to the digital preservation community, both within NYPL and globally, and look forward to scheming with you in the future. 📟 Alex, you are and always will be the foremost cyberpunk archivist out there. I’ve already missed you and our bi-weekly archives check-ins, but will miss your genius even more. 💽 A/V Preservation Unit and Special Collections Unit, wish we had more time to work together and glad to know many of you socially.

📱 SimplyE team, wish I had gotten an opportunity to work with all of you – you are a great team. As you know, and as the world knows, I use SimplyE exclusively to read library books and love it so much – personally and for its larger mission. 🍵 Courteney, you are a shining beacon of light.

⚖️ Natalie, I thank you for your ability to give us valuable self-reflection exercises during sprint retrospectives even if we seem like we are rolling our eyes at them. You are too kind and provide so many snacks. In the future, may you receive snacks ten-fold in return. 🖨 Courtney and Kendra, happy to share a single smushed long office desk with you for a couple of months and briefly get to work with you. Thanks for your content-production wisdom, your eternal insight and charm, your surprise and delight in the magic of the library. ✒️ Dan, we never got to work together but glad to know you through meetings and brief hallway interactions, always a friendly face.

📉 QA Team, thanks for covering our asses when our code suites were subpar, for your New Relic and rspec wisdom. 🐒 Joe, thanks for uploading the same blurry monkey video over and over while thoroughly testing our media ingest passageways.

🚥 DevOps, IT and ILS Teams, I don’t see most of you very often since moving up to 42nd Street, even those of you that moved along with us, but I appreciate our time sharing offices and I know no branch can party as hard as the IT Crowd on 20th Street.

🌀 Change is inevitable and I hope that one day, NYPL Digital will be a great and safe place for developers (especially femme ones 👯 and ones with library experience 🤖) to work again. Even if just coming in at the tail-end, I’m so glad to have been able to catch a piece of this innovative era of NYPL while it lasted. 😍 Onwards and upwards! 🚀