Quire—A Sustainable Digital Publishing Solution for Museums of All Sizes

This 60-minute panel features an in-depth look at the creation of 50X50--SJMA's first digital publication using Quire, the J. Paul Getty Trust's new digital publishing platform. Participants hear from three project contributors--each with their considerations-- about how to plan successfully, scope, and develop the web platform to accommodate a variety of content and media. A part of MCN 2020 VIRTUAL

Transcript

Unknown Speaker 00:00
Hi, everyone. Thank you for coming to our session. At the top, just some housekeeping, we are using the q&a window for questions, and we will address questions at the end of the session and using the chat for any technical issues that come up. So, my name is Amanda Helton, I'm the manager of digital strategy at the San Jose Museum of Art. I thank you again, all for enjoy joining our session. And we're really excited to share this project with you and we really look forward to your questions and discussing the project with you. I will be covering an introduction to the project and project planning and management portion. And my colleague, Eric Garner will take us into a discussion of the underlying technologies of Quire what it does, why we used it, and finally Kathryn Wade will wrap us up with a discussion of crafting content for the web.

Unknown Speaker 01:06
So

Unknown Speaker 01:12
50 by 50. Stories visionary artists from the collection is a digital publication, celebrating 50 years of the museum and and highlighting the artists whose whose work has entered the collection in the last 50 years, conveys the museum's support for artists as visionaries. And it began as a way for the museum to become Museum of the 21st century. And to really start to move into the digital space as a museum. It was really important to us that the project be free and highly accessible, online, and also available worldwide. It includes documentation of artworks, exhibitions, artists studios, and it shows the professional lives as well as the everyday lives and processes of artists in our collection.

Unknown Speaker 02:18
The museum received an IMLS grant for funding for two kind of two big projects. One was collections digitization for the permanent collection, and then a digital publication for our 50th anniversary. The museum was aware of the lopaka Cohen study in 2017. And lopaka, Cohen had actually assisted the museum with some strategic planning around the museum's goal to become more borderless, and digital platforms and digital initiatives. Were something that the museum was looking at to play a role in kind of helping us grow in that space. And that digital initiatives have a lot of promise for providing more points of access for visitors. And to help us to reach more people so that our offerings are extremely accessible. valuable, and yes, and so sorry, I'm having one of the main studies, the online scholar scholarly catalog initiative was really influential in terms of how we started to think about this project when I came on in 2017. And so that was an initiative that was really about rethinking the museum catalog for the digital age. And out of that came a Drupal based toolkit that a few different museums that were involved in the initiative, were able to use to create digital publications. And so the project really got started around around 2017. And when I came on around that time, I realized in reading the oski research, and looking into the toolkit that it really was more of an experiment. And so our museum had been considering it as a platform for this project. And it became immediately clear to me that that that was not going to be a viable way forward for our project, in part because the toolkit was determined through that initiative research to not really be particularly fiscally sustainable, especially for small digital teams that really don't have a lot of resources to begin with. discoverability on the web and longevity were major issues and there was also concerned about vendor lock in in terms of the toolkit was on a dream Pull based platform. And so that really indicates a real commitment that you're making to that particular platform. So this is just a very brief, condensed timeline of our project and a sense of my various roles on the project, which were early prototyping and platform research, as I've mentioned, digital asset management, and often editing of assets, project management generally and grant reporting, as well as rights and reproductions. So you can see we started really selecting artists and researching in 2017, and recently launched the publication in full in July. So sort of going back a bit to the platform research conversation, in realizing that the toolkit was sunsetted, essentially, in 2017.

Unknown Speaker 06:09
Sorry, I'm kind of these tools, I'm learning the tools as I'm going here. And I can't see, okay. And so that research of reading the oski initiative and sort of looking at Digital publications in the world of museums, we were able to sort of identify what kinds of things were important in this space, and what things that we would need out of a platform. So one of those things is that a really high level of content flexibility is important for accessibility, as well as longevity so that that content can continue to live different lives as technology changes. And that static site publishing, and in particular, a publishing tool called Quire, really floated to the top as being particularly user friendly for groups who want to make digital publications but aren't developers or have no real coding skills. There's also an incredibly sustainable solution that provided some protection from technical obsolescence. And it didn't require a lot of infrastructure like a back end database, or a CMS to maintain over time.

Unknown Speaker 07:33
So these were the real basic criteria we were looking for. This was a 50th anniversary publication. So we knew it needed to stand the test of time, we knew we had a very small project staff, which at most points was one to two people. So we knew it needed to not require a lot of maintenance over time, and to sort of be able to stand alone and continue to function. And definitely, we were also concerned about vendor lock in. And we wanted to make sure that the original content we were creating could continue to live beyond this project into the future. And it became really clear during my research, that multi format publishing was really important element to be able to offer to users but also for distribution, and for and version control. for project management, search engine optimization, accessibility, mobile optimization, these were all things that we knew we really wanted. And we needed to find a way to deliver those, but in a low impact way for our team.

Unknown Speaker 08:48
So we did consider a few different third party options, which were generally more costly, like I mentioned, Incorporated certain amount of vendor lock in and a lack of those essential features that we were really looking for. So overall, we we came to see Quire as providing really the most cost effective and user friendly technology solution for our publication. And so we decided to just go all in and really commit

Unknown Speaker 09:17
to that.

Unknown Speaker 09:22
And so some of the lessons learned from this project, from my perspective, and this is certainly not all of the lessons learned. But one of them is that really need to for projects like this balance objectives with funds, personnel and the expertise that you have and the expertise that you need. Consistently reevaluate your timeline readjusted as necessary. and identify the most essential components of your project ahead of time so that you can determine what that baseline is for evaluating What platforms might be appropriate? And then think about what's important to you? Is the project, open sourced? Is it accessible, sustainable? Do you want it to be compatible with existing systems or infrastructure in your organization. And then, you know, really just scoping your project very realistically, doing a lot of deep dive research to figure out exactly everything that you need to include in your project plan. And in your budget, including copyright fees, there's a lot of sort of hidden little things that that kind of pop up that we weren't really 100% thinking about when we when the museum wrote the grand narrative for this, these projects. So one of the things just things is just kind of accounting for everything. And then really scoping it to match your resources. And now, I will introduce my colleague, Eric Gardner, to take us through an overview of the Quire platform, what it does and how it works. So you can take it away here.

Unknown Speaker 11:11
Thanks, Amanda. So let's see if we can go to the next slide, please. So hi, everyone, my name is Eric Gardner. And I'm a software developer at the Wikimedia Foundation. We're the foundation behind things like Wikipedia and Wikipedia comments and things like that around the internet. But prior to joining Wikimedia, I worked for many years in the publication's department at the Getty Museum. And I want to give a shout out here to Greg Albert's and Aaron dunnigan, who I believe are both in the audience who are still managing and developing the project that I'm going to talk about, I was involved with its initial creation, and then I had an opportunity to kind of come back a few years later and sort of use it as an end user. And I actually think that there's a certain amount of like software developer karma involved in that where you have to live with the decisions that you made years, years in the past. And so I'll talk a little bit about that, you can go ahead and skip to the next slide. So I'm going to talk about Quire, which is the tool that we use to build this publication. So it's a digital publishing framework that, like I said, is, is being developed by the Getty Museum. It's currently in beta. So it's, it's still being refined and improved. Eventually, everything will be released in an open source way. It's built on top of other open source software. But for now, people who are okay with being an early adopter, like Amanda was, can request access to the beta. And I'm sure that Greg and Aaron would be happy to, you know, help them figure out how to get involved. And what's great about that is because the software is still being developed, you know, the feedback that ordinary users have of you know, how this works, whether or not it suits their needs, that helps us to improve the software going forward. So I would definitely encourage folks to take a look at Don't be shy if you think you could use this. So the past summer, I had a chance to kind of come back in as a consultant and work on this Quire publication. So the decisions had already been made that Amanda talked about if they wanted to use this platform, and I had a bit of knowledge about it. So I stepped in to help. So next slide, please. So these are just a couple of screen grabs from the publication, I figure it's nice to show something visual before we talk about the process of actually making it. But you know, the idea behind Quire was to kind of be able to make like a digital coffee table book. I'll talk a little bit more about what that means and what features we think were an important part of that. But we wanted to have a high quality, immersive, you know, nicely designed experience. That would be kind of similar to what somebody would get from, you know, being in a physical exhibition space or flipping through a physical book. Next slide, please. So, I wanted to start by kind of defining a couple of terms here. So I think the first thing I'd like to talk about, it's just what is digital publishing, you know, it's kind of a nebulous term. On a certain level, you could say that everything on the internet is digital publishing, you know, the Library of Congress's archiving tweets, for example, that's Digital Publishing. But the you know, the the whole web goes back to digital publishing itself. This photo here is a picture of Tim berners Lee, who's kind of regarded as the creator of the web back in his days at CERN, which is a particle accelerator in Europe. So the web was, you know, the basic idea is you have these hyperlinked documents. It's a way to publish data to publish, originally scientific data. Obviously, we've moved away from that a little bit. And I think a lot of things about Quire involves kind of trying to get back to the roots of what was the web really designed for? What are its strengths? How do we work with those. So Quire is designed around the specific needs of scholarly publishing, especially for art and media, heavy content. So like I said before, the idea of kind of a digital coffee table book. So, you know, one of the goals that we had, when we were first developing this platform was we wanted to take some of the best things of print publishing, like permanence, the opportunity to have like a beautiful design, things like that, while surpassing the limitations of a physical book. So you know, something, I think that's especially relevant now, where everyone is trying to connect with people share the things that their museums do, you know, in a time of quarantine and social isolation. So next slide, please.

Unknown Speaker 16:07
So Quire is a digital publishing framework. So I'm going to talk about a framework to so this is something that you hear a lot in software development, a framework basically ties together a lot of disparate pieces of software, so they can be used as a single tool. And this is how a lot of things are done. In the world of software development, we're always kind of standing on the shoulders of people that come before. I've got some logos here, you know, WordPress, Drupal, Ruby, on rails, these are all widely used software projects that kind of tie together multiple other things, you know, a database framework, user interface framework. There's lots of small pieces of software, but something like rails ties them all together into a coherent package, that's pretty easy to use. And one thing I want to say is that, you know, like with many of these other tools, Quire, we're, we're stitching together, things that already existed. And so that means that on one little, nothing that it does is particularly unique. It's more about trying to combine existing functionality into an easy to use package and the goldmine that is to try to empower small or solo teams when resources are limited. So like Amanda mentioned, you know, they were evaluating some of these more complex pieces of software, which might be great if you had a dedicated IT team, but a lot of museums and galleries, but I don't necessarily have a ton of resources of that department. And I think that that was one of the target audiences that we had in mind is, you know, you should be able to publish your, you know, the knowledge that your your institution is, is collecting or preserving, without needing a giant, dedicated ITT and at least publish it at a basic level. And, you know, as Amanda can attest, I think that people in the digital humanities world often end up having to wear a lot of different hats and juggle a lot of different responsibilities. And so, um, I think the Quire is especially useful for people who are kind of in it's jack of all trades, master of none position. So let's see. Next slide, please. So some of the goals that we had when we were first developing Quire, back a few years ago, and some of you might have, you know, come to some talks in previous years, where Greg or myself talked about some of the earlier versions of the software and what we were doing. But those goals have remained the same. One of the main goals as long term availability. There's a story that I like to tell and maybe you've heard it before, where there's an interesting project, one of the first big digital publications that people tried to do in the early days of the internet was called the Domesday project, which was supposed to celebrate the 1000 year anniversary of the Domesday Book. So it's a BBC project in the UK, so it's in the like, late 80s, or something like nine 989 until like, you know, 1989 ad. And they created this amazing like, interactive, basically digital publication on these giant like LaserDisc style CD ROMs, it kind of needed a special computer just to run it. It was the result of, you know, a tremendous amount of work. And almost immediately was obsolete and impossible to access because technology moved so quickly that they were left behind. So there are, you can actually, there were people that were able to kind of bring it back and make that software run again. But it's certainly worth looking up if you're interested in this the Domesday project. There's some interesting things written about it in the BBC website, or I think the Guardian had a good piece on it. But anyway, this is a problem. In digital publishing, you kind of you're in a paradox where you want things to be cutting edge and interactive and use all the good things about technology, but you also want things to persist and to be useful, especially in a scholarly format. And so technology moves at a very fast pace scholarship. button groups at a much slower one. So solving that paradox is one of our main goals. Another goal is we wanted to have the ability to output multiple formats from a single kind of input. And I'll talk about how we do that. But so Quire gives you the ability to produce not just a website, but also a PDF EPUB, things like that from a single set of text files. And this also kind of ties into long term availability, because, you know, hopefully, one of those formats will still be accessible, 10 years in the future, 20 years in the future, even if it's just the source text files, rather than being locked in some, you know, database or some blob of code, you know, anybody should be able to read that stuff. And the PDF, you can generate a physical book from that, which might be the thing that lasts longer than anything else. Another goal was to deliver an engaging experience. So we do want to lean on the things that technology gives you without having to, you know, pay the trade off have a short shelf life. And finally, like I said before, the goal is to make something that can be used by a small team. The next slide, please.

Unknown Speaker 21:08
So how do we do this? How does Quire work Quire is built around a program called a static site generator. So no database or server is required. This means your content, the source text of the book, or the website is just stored in a bunch of plain text files, just regular text files, you could open in any text editor, they remain human readable. They might have a few special codes and like snippets in them that do different things. But overall, anybody could look at the source content, and at least understand what's going on and still get what the authors put in, they could still see that. So then these files are run through a program that transforms them into a static webpage. And this is where you can add stuff to enhance the presentation, like CSS, JavaScript, interactive elements. And the great thing is that once you run that code once, you can kind of set it and forget it. So the site that's published that people see will not change until the program is run. Again, this is different from something like WordPress, or Drupal where there's a database that's always there and an application server that's always there. And it's rebuilding those pages on the fly every time a new request comes in from a user to view something. So it's great if you need up to date content. But the whole point of a publication is it's kind of frozen in time, and it's persistent. And so we didn't need that. So next slide, please. So just kind of a diagram of that you've got your text files, your generator, and webpages. And this is not unique to Quire. Every every static site generator works this way. Quire is built around a static site generator called Hugo. But there's many other programs that do the same thing, we just kind of add a few other useful features on top of that, basically, next slide. So again, just kind of an illustration of that, you can see sort of the input and the output of a given page in the 5050 publication. So this is the sort of landing page for given artists read the solace, really amazing artists from the Black Mountain College community. And, yeah, so you know, the the content itself is all there, there's some special code that controls presentation, like, what kind of page to use options about how that page should be configured. But that's it really excellent. So there are a lot of advantages of working this way. One thing is there's very little like a break. Again, you know, once you you can set it and forget it. So once you've built your site, you don't need to run that code again, until you need to change something. There's no server that's running all the time. So there's very little that needs to be secured. You know, most web servers are very good at serving static files, you don't really need extra software like special, you know, PHP, or Ruby code or anything to run this stuff. So no updates, no security patches or vulnerabilities to worry about. Static websites are also quite fast, because you're not recompiling these pages, every time your user visits, it's all ready to go. And, you know, the other thing is, the word used is static. But because of all the things that you can do in a browser in, you know, 2020, it can still be a really interactive experience. It's just that everything that you need for that interactive experience is prepared ahead of time. It's not assembled at runtime. And so Quire publications can showcase things like zoomable images of really high resolution artwork, interactive maps, data visualizations, all this kind of stuff is totally compatible with this approach. And in some ways, it even works better. So next slide, please. So the other big part of Quire is this idea of multi format output. And so this is one of the things we built on top of the static site generator out Core, I'd say it's one of the more unique features. So you can generate additional kinds of output beyond just webpages. So in addition to HTML Quire, can generate EPUB and PDF versions level publication from the same set of files. And the PDF files are actually print quality. So I know at the Getty, we were able to had a born digital manuscript or born digital product that could also exist as a print on demand physical book that could be purchased in the bookstore. And I think that's a really nice way to work. You know, if someone is taking a book into the field, you know, maybe they're on an archeological dig, and they need a catalog of ancient figurines or something that they're they're working on. to reference, it might be a lot easier to have a dead tree version of that data, then to internet connection. And also, ironically, it's a lot easier to get things like ISDN numbers or Library of Congress. Registration, if you have a physical book, the systems are still designed around print. And so you can kind of tie things together with the printed version too.

Unknown Speaker 26:05
So So yeah, I think that, again, this also just makes it more likely that some version of this book will persist over the long, the long haul. Next slide. So one thing that Quire includes in the spirit is trying to be you know, user friendly, and easy for maybe a digital humanities department of one to utilize is these pre designed templates. So Quire includes pre designed themes. I think, right now, there's a classic and a modern one. And they're designed to provide a high quality reading experience, as well as to be responsive and work on different kinds of devices, like a mobile device. The frameworks include all kinds of out of the box tools to support common features. So this is things like citations and bibliographies, zoomable images, the ability to search text, a lot of this stuff you get out of the box with Quire. Sometimes you have to include a little snippet of code a very short, like one line of code on a page that's like, this is a figure, you know, show it this way. But you get all of this by default. And also, these templates are optimized for SEO and accessibility. Next slide, please. So you can get pretty far, I think, as a sort of a solo user enquire, as someone who's maybe not a coder, if you're willing to use the default themes, and you can configure them a little bit. It's possible to go beyond that. At the end of the day, it's just a website. It's just HTML and CSS and a few other things. And so anything is possible and customization is needed. There's not a lot of back end code, there's not a database. So really, most of the code that's there is presentational. The one downside I will say is that when you're supporting multiple outputs, you need to every new thing that you make has to do double or triple duty. So we created this custom artist page like landing page. And we had to also create custom print layouts for it like what does this mean when you turn it into a book. So that's something that you should be aware of, if you're going to customize, it might take more work. So so basic usage, like I was saying can be done with anyone who is who's digitally savvy, willing to learn a few things. Deeper customization probably does require help from a professional developer, I think there are limits to what you know, any system like this is going to do. And it's a trade off something like a WordPress site might be easier for an end user to log in and customize, but that CMS has a lot of additional software that needs to be maintained, it's secured, we took a different approach in Quire. So customization might be a little bit of a challenge as a trade off. Next slide. So that's kind of my conclusion of my tour of Quire, I will say it's been really great to have an opportunity to come back into this world after working on a lot of very different kinds of things in the last two years. So I want to thank Amanda for, you know, inviting me to help out with this project. It was really fun. Um, also, I will say, overall, things still work, which is great. I'm really excited about this. So Quire was designed to be simple. One of my takeaways from coming back to it now I think it could actually do to be a lot simpler. Like we could be even simpler. I think that one thing that Quire would really benefit from is a bare bones set of templates without any styling or JavaScript. That would be really helpful for someone like me, who is a web developer to come in and have total freedom to customize the design thing about Quire that is the most valuable in my opinion, is it pre you have all of the logic about how does the proper citation look, you know, in Chicago or MLA style, all of the bibliographic tools are all there things that I don't really know about because I'm not a scholar or curator. So if that could be somehow taken away from presentation and I could just get the correct formatting of these things, then I could make it look however I needed that might be useful for you. Certain use cases where people want a very customized experience. Finally, I just want to say again, the Quire is collaborative software. It's open source. There's like a project to bring in people get feedback. So I'm sure that Greg and Aaron and other folks at the Getty would love to have input or suggestions from people that are interested in using this. And that, that's it. one more slide here is a couple of links, which I do recommend folks to come back to if you're interested. And yeah, I just want to say again, thanks to Amanda, and Kathryn for inviting me to talk and I hope you all find this product interesting.

Unknown Speaker 30:38
Okay, awesome. And now we have Katherine.

Unknown Speaker 30:46
Can you go to the next slide? Yes.

Unknown Speaker 30:49
Thanks. Um, hi, everyone. I'm Kathryn Wade, I'm assistant curator at San Jose Museum of Art. And I started working on this project in mid 2017. And in that stage, we were in the artists selection process, can you go to the next stage, or the next slide.

Unknown Speaker 31:10
Um,

Unknown Speaker 31:13
when I joined there had, there was already a decision here to break from a a more traditional exhibition or collection catalog that might emphasize a particular object, and instead emphasize stories about artists to show the lifelong work of modern contemporary artists in the museum's collection. As a curator on this project, my roles were in artists selection, asset selection, and writing. The artist selection and asset selection were collaborative, they were done by a, our entire curatorial team to some degree, and, and the writing I, I took on on my own, I'm the Can you go to the next line. But asset selection then was of documentation of exhibitions, studios, classrooms, neighborhoods, all assets are images that would tell stories of an artist's creative process, the development of an idea, and we wanted to emphasize Art's contribution to society. And a quote from Los Angeles artists, Judy Baka really guided this this ethos, and I'll read it to you here. The creative act is one that begins at the very point of research or thinking, that is the beginning of art. Make no mistake about it, I am a painter, I love painting. Paint, to me is like magic. It's liquid light. But painting for me has never been enough. It has always been those interactive processes that determine what I paint and how I paint and who I painted with and whether I paint at all. All of that is about the process that is created to make that work.

Unknown Speaker 33:25
Go to the next slide things.

Unknown Speaker 33:30
So in thinking about our collection, and selecting artists, we really focused on on four criteria. One was exceptional holdings in our collection. So this is where the San Jose Museum of Art has a large body of work. The museum has been a long standing support of California artists. And we want it to represent that new media San Jose Museum of Art is located in Silicon Valley. So artists that engage in technologies and experimental media, again, you know, a web based publication is conducive to show new media documentations. So that's a that was a part of that decision making as well. And of course, their global significance. San Jose is a global city and we want to represent that. We go to the next slide. 50 by 50 is a visually rich publication. And we really wanted to use images and video assets to guide the content. And the first instance that you see of this is a sense of coming face to face with an artist on the land. page. And so that's includes an artist portrait and a quote by the artist to send her the artists words, I was recently talking to a classroom of writing master's level writing students. And they said they were really felt a lot of empathy when when looking at our artists page, the way that we laid it out, because they looked into the eyes of the artists and the artists eyes caught them. So again, this is people based rather than object based. And you know, of course, you see that and social media as well we know that this is something that works for for online users, we go to the next page. The other way that we set up each artist page is to really use images that are biographical or an artist at work to use images that came are of objects in the museum's collection, exhibitions, histories. And those could be from our collection from our own archives, or they could be from the artists archives, or from significant exhibitions and the artists life. Um, here we have an example. Would you mind just going back quickly? Okay, the this is just an example of a draft artist page. So you can see here, these different kinds of images, and then, and then a little hook or storyline that would come out of each of those images. Because the kinds of assets vary. For every artist, it was really important for us to be flexible in this content.

Unknown Speaker 36:54
And

Unknown Speaker 36:57
not create too many criteria that had to be the same across artist. The next slide. Um, and so this is really when I think I took on my relationship with 5550 was when I began just when I began writing for it, and are we our approach to building multiple voices and multiple points of entry into the catalog is this nonhierarchical rhizomatic approach that really takes advantage of the web based platform itself. And you see this here, there's an example of artists, Alison Saar, who is who, who is given whose This is a video interview with Alison Saar, and so you can hear the artists voice here, but then even within the text, we have linked citations, so you can hear one interview with the artists here, you can also hear another interview with the artist by going through the links in the in the pop up citations.

Unknown Speaker 38:20
Go to the next slide.

Unknown Speaker 38:25
Um, and another. Another aspect of writing for the web is that yes, we have this kind of general audience. But identifying a target audience within that general audience is really helpful. You can see that the writing for this is all about for each for each asset, there is about 150 to 250, word, short form piece of writing that you could see as a kind of extended caption, there are these hooks that we use for naming each each asset, so something like history is a verb. And then again, it was students and researchers became really a another specific target audience. And, and so as I was writing, I was thinking a lot about what kinds of roads Can I map out from, or what kinds of roads can extend from this short caption, what kinds of ideas can this open and to go ahead and provide access to those? Um, I think we're going to move into q&a now. If everybody would, please put your your questions in the q&a, and Eric and Amanda I will do our best to answer them.

Unknown Speaker 40:07
Okay, the first question is maybe I'm directed at you, Amanda, I noticed it was a three year project. Often our organization is encouraged to produce things very quickly, how do you advocate for the resources? And especially the time to produce content like this? Hmm.

Unknown Speaker 40:25
How do you advocate for the time and the resources? Yeah. I mean, I think, honestly, for me, in this particular on this particular project was just, you know, doing your research and building a really compelling argument for what you want to do what your vision is. And, you know, I just, I talked to so many colleagues and I read so many things, when I was sort of putting our, our kind of plan together, and when I was researching Quire, and so I think it's about sort of communicating that you have, like a broader vision of what you want to do, and just sort of helping to bring people along with you. In every meeting, you know that you're in about the project, you're just kind of planting those seeds of like, if we do this, then it means we're set up for this in the future, or, you know, sort of having this like, long tail, I guess more than, you know, I'm always kind of thinking about things in terms of, of that longer term, like strategy so that our projects aren't sort of one offs. And so I think that when you approach it like that, and you're really prepared, and you build compelling arguments that speak to longevity, that, hopefully people will listen. And I was fortunate to have people listen. But you know, another thing is that this was extremely new territory for our museum. And so I think this project took a lot longer than initially, we thought it would, because we didn't even realize how new the territory was. And we were learning as we went, you know, about things that we should be having our eye on and thinking about, and so it was really, also a huge learning curve, for the institution. And, and for, for us individually on this project. That's an excellent question.

Unknown Speaker 42:39
I'm going to move to a somewhat related question, which is, are our publications team and IT departments have historically been very separate? How did you? Or did you have to change your workflow, I'm trying to imagine what it would take to shift towards this kind of publication process.

Unknown Speaker 42:59
Right. So I think if I'm being totally honest, what ended up kind of happening with this project is a lot of that burden of the sort of learning of new technical skills and things really kind of fell more on me. And which was, you know, another reason why we chose the platform that we did, because I knew that I would be able to get it done, you know, being just one person doing the data entry, and things like that. But, you know, something that I think that we're looking at, as an institution, you know, is, hopefully, you know, kind of adapting the way that we work on projects like this, so that they are more cross functional, and so that, the skills and I'm hoping that the skills that I've learned on this, this project in terms of static site generators, and how they work, and, and everything, that that those are skills that I can share with my colleagues and that we can like, move forward on projects together with like, greater understanding. And that's, that's not something that's quite happened yet for us. So, but it is something that I think we're much better primed for now that we've done this project and sort of learned the things that we've learned. So it's, I kind of think it's just a matter of like, jumping in somewhere. And, and kind of finding your footing and then gently bringing people along,

Unknown Speaker 44:38
hopefully,

Unknown Speaker 44:40
and I'll just follow up to say that we did. When we started the project, we worked with a project researcher who was gathering a lot of the while all of the research that I've been based my writing off of, and the project researcher and Amanda had a lot of interaction initially The project researcher was identifying, or was was addressing rights and reproduction. And that's something that ended up becoming Amanda's responsibility. So, so in some ways, Amanda was the merger of the it and the and the publication's department. And I do think that things got a little more a bit more streamlined when then Amanda and I likewise started working just the two of us. So honestly, having a small team and that sense did end up, benefiting us.

Unknown Speaker 45:41
Hmm. Yeah. And I think I think that's something that like, you have to evaluate as you go. And it's something that I had to evaluate a couple of different times, sort of re scoping the project, the last time very significantly cutting it down, basically, in half in terms of how many assets we were pursuing copyright permissions for. Because the reality was that I was the only one doing it. So I only had enough time to do about 200 is what is what I kind of estimated, not the almost 800 that had been identified by the the curator who was doing the initial research. So that's another thing too, is that just like those, that reality of like, what's practical, in terms of scope is something that, you know, you might have to advocate for in in that space. You know, when I did that re scoping, it was a matter of like trying to keep intact the curatorial intention, but accepted, accepting the reality that we weren't going to be able to include all of the content that had been identified. So yeah, just be practical.

Unknown Speaker 47:02
One, real quick thing I'll add to that question, before we move on is, you know, when we were working on these books at the Getty two, I think we found people had to kind of meet in the middle. So there was the tech people and the curatorial or the editorial side. And things worked the best one, like those of us doing software stuff, and those of us doing, you know, curatorial, or editorial stuff, could each learn a little bit about what the other person was doing, and why they needed certain things done in a certain way. So I learned a lot about like book editing processes, during my time in this project, and that helped, that informs my decision to the software similar lately, like Amanda has been able to go in and learn a lot about coding in the course of this project. And that means we can have a more direct conversation about, you know, we can do this, but there's a trade off. So to the extent that people are willing to cross train, it makes these projects a lot more likely to run smooth, I think.

Unknown Speaker 48:02
I'll go to just one other somewhat related. Question is hum, how might the process of creating a digital publication differ from a traditional one? And I'll just start by saying and creating a digital publication is as much work on the content and as creating a print publication?

Unknown Speaker 48:28
Yeah, I would 100% agree with that. And definitely, it's not necessarily any cheaper or easier. And I'm not just like, the truth. So if there's just a lot, there's a there are new considerations, you know, that you don't have with a print publication. with, you know, ours in particular, we have it available as a PDF. And so they're the more formats that you're offering the user, the more sort of editing that you have to do on and sort of iteratively edit on those different formats. So that's another element of scope to a project like this is thinking about what what can you offer? What can you maintain over time, and that sort of thing?

Unknown Speaker 49:27
And, Eric, this is a question for you. What tools and skills do you need for additional customization or to create new templates or themes?

Unknown Speaker 49:37
Yeah, sure. So at the end of the day, everything is just dealt with basic web technology, HTML, CSS, JavaScript, like with any other website. But in terms of customizing what Quire gives you, there's kind of a spectrum there's like, a little bit of customization, which is pretty simple. And then there's like really deep customization in terms of we need completely Different ways to present certain kinds of content. And that means getting in like a little deeper. And so for the kind of like, hey, I need to change some fonts, I need to change some colors like, but the overall look of things, it's fine Quire makes it possible to like inject your own styles and inject your own scripts to modify things a little bit. And so that's similar to what you do in like a WordPress theme, for example. at a deeper level, which is kind of what we were doing and 50 by 50, you would be basically developing a custom theme, the same as you would for any other website using the static site generator called Hugo. That's the underlying like software that Quire is built around. So Hugo has its own way of structuring templates and its own programming language that you use for that it's written in a language called go. And there's a special templating language for go. And so you'll have to get it if you want to really change things around at a lower level, you'll have to look at the Hugo documentation, and kind of learn how to do that. So Quire has higher level documentation for the end user about short codes and predefined widgets and things that you can add to a page. But if you want to actually create new versions of those things from scratch, you have to go one level deeper and look at a Hugo. So that's the short answer to that.

Unknown Speaker 51:20
And another question for you, Eric, is there any reason you couldn't do an initial launch with one of the templates and do some customization to add bells and whistles later on sort of like an expanded edition?

Unknown Speaker 51:35
Yeah, so all of that is totally possible as well, again, it's, there's this underlying software that lets you you know, change the templates around or add different themes. So you could always change something after you go, that's one of the great things about web projects is you're not locked into something, you could change it after the fact, the one thing to keep in mind is Quire, expects certain data, like data that you need for a publication to really exist in a formal way. And so you'll have to make sure that that data is there. And that you can still like use that data in whatever new things that you add. So that's the kind of stuff where that's an extra layer that Quire brings that your average static website might not care about your ISDN numbers and bibliographic information. So but you could start with what Quire gives you and then gradually add new things if you need to, there's a way to override existing functionality, like piece by piece, for example.

Unknown Speaker 52:33
Can you talk a bit more about how content entry works? It looks like it's basic text entry with some formatting tags required? Is that correct?

Unknown Speaker 52:43
Yeah, that's essentially correct. How we did it was I received word files from Katherine. And then I ran them through a program that would convert them to markdown using the terminal on my computer. So that was a way of sort of partially automating that process. So I didn't have to go in and manually add all of the markdown. But then I would then move those markdown files into the project, and then clean them up anything that didn't convert properly. And then just the other kind of things that were part of my workflow to add or augment on each page. And that's Yeah, that's essentially how the data entry works. And then there are, you know, short, some short codes that you use to indicate certain things and functions on those pages. But it's mostly, it's mostly the markdown that's really and the in the YAML that's kind of doing the work.

Unknown Speaker 53:53
And Amanda, is plain language being used on any of these projects. If so, are there any tools you'd recommend, like up go or five grammerly Hemingway editor, or otherwise?

Unknown Speaker 54:06
Oh, like, text editors. I don't have like a ton of experience with a lot of different text editors. But I used Adam and I, I like it a to M it's it has a lot of customizable features in terms of like how it looks which I like because I like to be able to look at like a darker screen dark background. I like basically dark mode for everything. But um, yeah, I don't have I don't super have a lot of other experiences beyond that. That was just kind of the one that was recommended to me, and I've ended up liking it.

Unknown Speaker 54:51
Could you speak about how the content integrates with other non Quire content both in toto as a catalog and as individual files such Just the artist interview video files.

Unknown Speaker 55:07
How the content integrates? Um, so I guess one part of that, and Eric, you might have a more comprehensive answer. Um, one of the aspects of that is the videos that are in the publication are more or less being hosted on Vimeo, or YouTube, there are a few that are coming from YouTube. And there's some things that Eric did on the back end to sort of assist with the way that we manage the images in the publication. I don't know, Eric, if you want to just beat that to that just real quick.

Unknown Speaker 55:48
Yeah, so as far as how like Quire would acquire publication would integrate with the museum website, everything is just linked documents. So you know, you could link back and forth, you can make it so a artist, or an artwork page would automatically link to a catalog page, if you put in the right ID number, like these are the kind of customizations that are not that difficult to do, by, you know, modifying templates a little bit, some of it might be supported out of the box into, like, the catalog page type, the Quire gives you already. And then yeah, for more complicated things, it's best to just rely on an external service, because the more that you can offload that stuff, the less you have to maintain yourself. So if you don't have to maintain a video streaming service, you can just rely on YouTube, or Vimeo that will simplify everybody's life. And yeah, image processing is something I know we're running low on time. But that's probably another thing where I think Quire could maybe try to make things easier for people where, you know, you're, you have these really high resolution images, because there's a print version or there's a zoom. But at the same time, you need to optimize those images so that people on like mobile devices without a ton of bandwidth, download megabytes per page. So we did some things to automate that. But if you can get large, the large file service, basically. But that made other things more complicated. So I think that there, that's an area of image processing specifically require could probably prove

Unknown Speaker 57:13
I'm going to try to answer a couple of these because we're running low on time together, which is about updates and maintaining it and whether or not there will be further additions. We there is I think one of the difficult things of a digital publication is week could make endless updates to it. We have just we have made two so far, and Amanda has trashed them as new additions, there will need to be some maintenance in terms of keeping up links that are in the citations. Um, and then in terms of audience response, I mean, I personally have just been in contact with a number of college students about it, who have been very engaged with it, somebody compared it to an art 21, which I think is hugely complimentary. Um, and another question is our people finding it through the website? and Amanda, maybe I do have an answer to that.

Unknown Speaker 58:27
I think it's kind of a smattering of like, a bunch of different things. I think a lot of people are finding it through our social media, because we've been kind of marketing it that way. But it is a broader question for us about how we're going to continue to distribute the publication and make it accessible and market it, which we really haven't done a whole lot of beyond our social media campaigns. But I think it's, it's kind of a right now it looks like kind of an even mix of kind of people directly going to the link finding it from our website, or coming to us to it from either Instagram or Facebook.

Unknown Speaker 59:21
And I believe they're going to cut us off at any minute now. So I don't think we have time to take any more questions.

Unknown Speaker 59:30
Thanks, everyone. And, you know, I mean, I'm in the MC n Slack. Yes, I think there's other ways to contact me if you still have questions, but thanks for tuning in. Yeah.