About this talk
This talk discusses the redevelopment of the Harvard Medical School flagship website, focusing on the migration of the MD program site from OpenScholar to the flagship platform. The speaker outlines the project's history, its key objectives including modernizing the site's content architecture, overhauling the news section, and enhancing user experience through improved navigation. He emphasizes the need for stakeholder engagement throughout the process and the use of in-house resources to manage limited budgets and timelines. The development team combines agile methodologies with project management strategies to ensure effective communication and progress tracking. The session highlights successful project milestones, including the migration of 150 web pages and the seamless launch of the new site, while addressing ongoing challenges such as technical debt and legacy code integration.
Full transcript
recording, so nobody will ever know who we are. Uh Uh so again, I'm Tony Salvador I lead the web development team at uh Harvard Medical School for who's joining us in the recording. Uh this is our talk on >> recording, Tony? Yeah, I am. No, no, no, you shouldn't be recording. Uh yes, we I am now. Of course, it was going to happen. It's not the first
time that I've not done that. Uh our learning objectives uh for today are on how to plan and execute a multi-faceted development project keeping all stakeholders in the loop. Just as the uh slide says, how to outsource part uh of the work that would otherwise uh hold up the project. Uh we have a small development team, so that's uh becomes necessary. And how to balance that small
development team's workload between project work and ongoing support. We cannot forget about the people we are supporting on our daily work. Take away. Yep. Thanks, Tony, and thank you all for being here for this. This is actually my first time presenting at a conference, so it's an honor and I'm excited that it will be about the refresh project. So, to start, um this project was born out
of several needs. Um first, our MD program needed a new home for its website. For years, that program was using a platform called OpenScholar, which Harvard would no longer support after 2025. Uh sorry, November 2025. Um different options were weighed, and ultimately the decision was made to bring them into the HMS flagship In addition to helping our students navigate HMS, the flagship website also serves as an
editorial product. Our Office of Communications and External Relations, which we also refer to as OSER, uh frequently publishes news stories about research, big events for students like Match Day, and enhance enhancements to education on campus. Our news section needed an upgrade in order to meet that editorial charge. And we were also due for some structural and visual visual improvements on a website that, when the seeds for
this refresh were planted, was one of the oldest flagship websites at Harvard. So, let's dive back. Let's dive into our website's history a bit. Um since 1782, our website Just kidding. Since the early 2000s, our website has been served as the place to learn about our community, our campus, and our research. Our previous website on the left here reflected design and technical capabilities from that era. And
then a major project was done to redesign that website. It gained a modern feel and many of the design and navigational elements that we're still using today. Since then, improvements have helped our website meet our community's needs. What you're seeing now is what the website looks like today, a little over halfway through our refresh. Time for a little bit more history. So, this was the MD program's
website when it was on Open Scholar. You can see its design and content structure is very different from the flagships, and this created some exciting challenges for the migration, which Adam will tell you about in a bit. As this need As this As the need for this work became clear, so did five distinct objectives. And here they are. The first is modernizing the public theme and content
architecture. This involves making key updates to the website's front and back end, so future work can be more focused and efficient, and Tony will talk about that in detail. Our second objective was to launch the MD program section on flagship. As I mentioned, the MD program needed a new home, and this would be it. The third objective was to overhaul our news content. So, this meant creating
a an updated news landing page, updating the look of our articles, and also creating a new search page for our news The fourth objective was to revise navigation menu functionality. The navigation really needed some work to address clarity, accessibility, and mobile compatibility. And our last objective was to update the basic inner page design. The basic inner page, which is the most used content type on our website,
required some UX enhancements to address functionality and design. So, these are the five objectives that sort of compelled the project into being. While we were working on the project, we also identified a sixth, because five's never enough. The sixth objective is to integrate magazine content. Our stakeholders shared the importance of being able to syndicate content from the Harvard Medicine Magazine website into flagship, specifically in the future
news component and the all news listing. We faced some constraints during this work. The first one I want to highlight is limited time and budget for this effort as a result of financial difficulties that our university was facing in 2025. Second, and relatedly, we were not in a position to create an entirely new website. We decided that continuing work on the existing website would be more economical
and sustainable than embarking on a multi-year full-on redesign and rebuild project. Third, we decided to do the work in-house. Not fully outsourcing the project would allow us to take advantage of our small but experienced web development team, which Tony leads. So, here's what our journey has looked like so far. Um and right right from the bat we decided to combine sprint processes our web team had perfected
with project management structure from our project and then portfolio management office. In January of last year, HMS IT hired me, um the new director of communication and UX strategy, and chose me to oversee the web team and guide this flagship refresh. In February of last year, the web team at OSR agreed that I would serve as a project manager. So, this is my first time being a
project manager, very exciting. Um I started that work by creating vision and governance documents. And then in April of last year, a project kickoff was held. This really formalized those governance documents um and established a project steering committee. And then we can really start on the development and design work. So, from May to September of last year, we focused on that MD program, creating a new home
for it, and moving content, which Evan will talk about quite a bit. Um and then in September of last year, we launched that new home. Uh at that point, we were able to start focusing on the news content, so refreshing those pages, um and then we launched that in January. During that period, we also identified that new objective around magazine And then from February until now, we've
focused on syndicating magazine content, refreshing navigation, and modernizing the theme. I want to close my section by sharing a small glimpse, and I realize these are probably really small, but small glimpse into some of our project management artifacts. On the top left, you can see the vision slide, which captures our various objectives and guiding principles for achieving them. Below that is the timeline of those And then
on the right, you'll see a screenshot of one of the reports that I send bi-weekly to project team members, sponsors, and steering committee members. This ensures that everyone is up to date, whether they're able to attend meetings in person or online. And with that, I will send it over to who will talk about the MD program and vendor collaboration. Hello, thank you so much. So, I'm Evan.
I'm kind of in a unique position because up until two months ago, I worked at at and the staff of the MD program and was largely responsible on the sort of stakeholder side of of this project. And then OCS, which for a reminder is the Relations, cuz we have so many acronyms. I'll just keep saying OCS and that means the communications team. OCS approached me towards the
end of the the MD program launch and that's where I work now, but I'm pretty much speaking to you from the perspective of the the MD program itself and being the kind of stakeholder component of the project. And so, to reiterate, the history here was the MD program had its own web presence. A lot of this was kind of due to aspects of historical timing. The program
wanted certain presence and functionality to coincide with some important curricular changes that were happening about a decade ago. And at that time, the institution wasn't really ready to accommodate that. Then by the time the institution updated its website, the MD program's website was still pretty new, so it wasn't time to change again and there was always this kind of off-cycle challenge. But the change was then forced
by the sunsetting of that OpenScholar platform, which we had a few years notice to work ahead of, but it's a big project nonetheless. So, it wasn't a given that we would migrate the program's web presence into the Harvard Med School flagship website. Could have potentially gone with another Harvard platform offering, or maybe an unnamed third offering that we never really considered, but could theoretically have been on
the table to still have its own website. And so So, the first step of this was to actually decide um what its home should be. Uh and we did retain it at some help from a consultant, OHO, to help us with this. It ended up breaking down into two really important phases. One was to really take stock of all of our content and really have a sense
of what's on the website. Uh is it there for the right reasons? You know, it had been some time uh since we really, you know, since a lot of things had been put there. And probably without a really sophisticated you know, a quality audit of any kind. And so, OHO really helped us go through, interview stakeholders at length, um really take a look at who we think
our audiences are, how we think the content is supposed to support that, and then kind of compare the two and and you know, use the analytics and other things at our disposal to help us determine like uh how are we, you know, performing on our promise here. So, at the end of uh that engagement, the decision was ultimately made to migrate into the flagship site, which many
of you are probably thinking like, that makes the most sense, honestly. Why couldn't you have just skipped to that? But I will say, you know, it's not necessarily a given, and you will see um other programs, especially in complicated health systems, where medical schools do have their own presence or programs have their own presence within that. Um so, we were able to make this decision, you know,
with a great level of uh you know, it being informed by information and data. Um but by the I will say that it was a bit of a protracted uh situation, where by the time this decision was made, we really had kind of less than a year to then do the work. Uh and that's not a lot of time. So, we decided to retain OHO for another
engagement to help us strategize how we were going to do that. And really what that means is like deciding what we need to do as quickly as possible to get this to happen before you run into a wall. And so that pretty much consisted of doing a competitor audit. Competitor is kind of weird to talk about with medical schools, but let's just say like peer schools and
other schools that our prospective students might be looking to to apply. Seeing what the trends are, what's the latest and greatest, how are people kind of orienting information on their sites. Took us through the entire journey of site mapping. Now that we were going to be downstream of the institution's website, calls into a lot of you know, calls governance into question a little bit, you know, who
gets to own what, where are there areas of shared content, where it kind of supports the institution and the program, and who gets to say, you know, who gets the final say on certain aspects of content development. And then the budget unfortunately did not accommodate having the consultant do any actual writing for us or staging of content or multimedia production, nothing like that. So it really was
kind of like a guide, you know, that was the deliverable. It was a good one and we got some workshops and it was very hands-on. But in the end, you know, the task was to take people who don't do this for a living, namely med school administrators, and say "Add this other job during a busy summer where you're also trying to take vacation and all this stuff."
And now put some words and pictures on a page and have them be in the right place. So that it's it's challenging, but here moving along we'll see what our approach was. It was time to do yet another site reinventory, which is really just to make sure, you know, it's no node left behind kind of situation. And we had to kind of re-engage all the stakeholders who
had contributed to all of this content over the years, make sure kind of roles and responsibilities were understood, and kind of you know, really get across the point that we had a content strategy. It was informed by work and signed off by program leadership. So, when something changed or was deleted or added, there was a reason for it and there just simply wasn't time to ask permission
to do everything from everyone who might be affected by the decision. We were able to take advantage of a really great new partnership or kind of like a re-envision partnership between the MD program and Ocer. Ocer had done a lot of content strategy and kind of brand activation and messaging architecture work in the years leading up to this, maybe one year leading up to this. And that
was those were great hooks for us to hang our coats on because we could say like, well, if we're going to write really important things in the in the headers here, they should really be on brand with what else is on the site for different, you know, audiences or the same audience kind of going on different journeys within the site. I will say that we received really,
really strong guidance from OHO that we should prioritize the site around prospective students, not to the exclusion of faculty, staff, and other stakeholders, but that it was it's really liberating to say like, no, but this is really how when we put words on a page, the reason that we're putting them here is to protect, you know, primarily activate that audience. Then we had the task of kind
of integrating with the information architecture of the flagship site. Most of that went pretty smoothly, but of course like you can't have two home pages, you know, so you can't just sort of lift and shift the entire site. Sometimes it does work, but there were really important areas where details of that were called into question and we just kind of had to wrestle with that and see
what was the best best option. We then retained another vendor to help us with some front-end design. Won't go into I won't go into too much detail about that. It wasn't just for the MP program, but we benefited from it particularly on our landing page to have some really new and compelling ways to present information on the landing page. And then there was the actual migration. And
we only had a few months to actually stand up all the content. And that means there wasn't enough time to develop and code a sophisticated data migration tool or something where you would just hit go and all the content would come over. So, this is taking away all the glitz and glam. This basically meant that a team of several people, two of whom are presenting in this
talk, had to roll up their sleeves and do a lot of copying and pasting. Um, and you know what? Sometimes that's the way to do it, but it also it basically ensured, again, no node left behind. Like, we we were totally human human-ing it all the way. Um, and because of that time limitation, a lot of decisions just sort of have to be made and not go
back to the stakeholders for details like, "I'm going to take this bold away." or "I'm going to add a comma here." Sometimes it just had to happen. Um, and so, really, to you know, under the code that just looks like a really sophisticated not sophisticated just a really long Google Sheets that lets us assign tasks and know exactly whether something is done or not done or blocked
for some reason. And then looking ahead, we can see how that all nicely rolled up into something that we were really excited to see went went progressively more towards green and less towards pink, orange, and and red. And I had blue in there for some reason, too. But, I'm happy to say that everything became green well ahead of schedule and that was really satisfying. Um, so, let's
see what our end results were. So, the working with that that additional vendor of Interactive Strategies, here are some examples of homepage content where, you know, we see a really pretty strong pairing between what the designs look like and then what was built. Tony will go into more detail about this. But, here's a great example, too, of like just the decision we had to make without, you
know, might maybe it's really important to somebody, maybe it's not, but we see, "Hey, it's going to take a lot of resources to develop this charcoal gradient that that you see in the design. Um maybe that's not worth it and we can move on to other things that are really important. I'm sure I'm like really downplaying what goes into these decisions. Um but, you know, I could
then step in, you know, representing the stakeholders saying, "I'm pretty sure no one's going to know if that's not there." That would be an okay thing to deprioritize and we end up with something that performs just as well, looks good across a couple different viewports, as you can see. Um on the next slide we see another really great component. Again, taking that prospective student audience into into
consideration saying like, "How do we actually make the landing page for the MBA program provide value right there in place?" This is a great way to do it. This is an example of a component that didn't exist before. We have this great design from Interactive Strategies for statistics that kind of bring really important facts and figures out in front of prospective students and other audiences. Um and
we see that it's like pretty much identical in the in real life, again, looking really nice in different different screen widths. And then we see kind of top to bottom what we ended up with. You saw the hero and the statistics already. Um we also have just some, you know, like I think what we end up with is a way to still have identity, like a a
unique identity within the site. No other kind of landing page looks like this on the site, but it still is totally on brand. If you were to go to the site, you wouldn't be confused as to, you know, or where are you? Um, but we do have ways to make sure that uh for that prospective student audience, the right links are um you know, up front and
uh there's kind of diversified ways to present them uh and you know, kind of have things that look like little sub menus and stuff like that, which maybe aren't technically those things. So, we see that link list component um and we also see uh additionally um uh just above the bottom there, we have uh another way of kind of presenting like a little in-in page menu. In
which we call general navigation cards, and that was actually a redeveloped existing component. Um so, just to refresh, this is where we started. It's a perfectly aesthetically pleasing website uh here on the Open Scholar platform, but not not integrated at all branding-wise or in other kind of like subliminal ways with the school or the or the school's website. Um the other thing I'll note is again, we're
talking about bringing value right to the page, and I think if you were a prospective student and you landed here, this is the homepage, and the first action you might want to take is not engaging with this page, it's going to be to figure out how to get off this page to where you want to get to. Um and in some cases, that might even take you
to another site, uh and that might be disorienting. Um so, uh I think that we whether we realized we were going to achieve this or not, when we look ahead to where we are now, and we can see a bit of a preview, uh little little motion-activated preview, um scrolling through the page, I think we we ended up delivering on a promise we didn't know we were
making, which is uh to really have a a lot of value add to this landing page. Um and with some really diversified ways of presenting things visually, um not being like uh uh you know, too jam-packed with anything, um but making sure it's the right mix of information and kind of that table of contents need because people are here to explore so many different interests that they
may have, especially as a prospective student. So, uh just you know, our just to sum up our results, we migrated around 150 web pages in under 3 months. We were able to leverage the existing components, find really good fit for that wherever possible, and that way any new newly developed components or redesigned components or variants of existing components were really being worked on because of uh high
priority or high value add. We were able to retire the old site uh 2 months ahead of the instep location um and archiving everything. We had a really seamless cutover. We had no 404s, no no no IT tickets, nothing on the day that we launched. Um some some of that was due to an extensive redirect mapping, so even if someone had an email from 5 years ago
and with a URL that was supposedly still working, they would actually end up at at a useful place and not just like the homepage or something. Um and everything that that the MD program is benefiting from in terms of new and enhanced components get to benefit other areas of the site and other stakeholders as we move ahead into the future. So, thank you for your time. I'm
going to toss it back over to Tony. Thank you, Evan. So, everybody can hear me, right? Awesome. Uh so, I'll talk about the progressive rebuild, so the more uh technically challenging part of the uh part of the project, uh which, by the way, is still ongoing. I may have written some uh parts of the of the abstract to this conference talk as if we'd already been done
it. No, this is going to take a while to complete. Um so, we had some goals and these are only some of our goals uh throughout the process uh throughout the process. they're kind of scattered. I mean, there supposed to be previous goals and that, but I I these are the four important ones and the two that are bolded are even more important uh and and I
will talk about them more in details. Consolidate our component library was one of them. I don't think we should have gone into this kind of project without um taking a good look at what our component library, which again was largely built 8 um and uh progressively, you know, you know, had additions to it and and all that. We shouldn't have gone uh through the process without inventorying
what we had both visually and from a content architecture point of view. Um, rebuild the interface. We couldn't have done this without also demolishing our entire theme and uh starting from scratch. But also, we didn't do that. Um, so we're trying to do that. Um, sort of yeah, we're we're on the plane and everything is we're we're flying and, you know, the engines are sort of falling
off, but they're not falling off. You're You've seen it. So, that's what Evan showed is all live stuff and so it's uh it's happening. Um, I wanted We wanted to allow restart easy restyling of existing components. We didn't want throw We didn't want to throw everything out. We just wanted to be sure that it whatever new we were receiving from our uh design vendor would uh keep
working or could be applied to uh existing components. Uh, and finally, remove technical debt. We're not there yet. We won't be there uh for a while, but I'm uh confident. Our constraints, the age of the website, 8 years old, started in Drupal 8. There's been a lot of changes since then. Um, the state of our content and visual components, I'll go into more details about this. There's
a lot of inconsistencies there, old design principles, a lot of old code that we needed to deal with. the need to integrate new designs without breaking existing ones. It's not just about re-skinning old components. It's about making sure that the ones we're not re-skinning are going to still work, um still appear where they need to appear while we add new ones. Also, my team manages about 200
sites. 40-ish of of these are based on the same So, eventually we're going to have to Well, 35-ish, I guess. Uh eventually we're going to have to migrate and let's use the word migrate to switch over, I guess, these other 45-ish sites to the new to the new version of the theme. So, we need to take that into account as well. We need to make sure that
what we do isn't going to get in our own way a year from now or 6 months from now, hopefully, when that starts happening. Um so, we that's always on on our mind. And again, resourcing, from my point of view, this is about how to employ my team in a productive way, um and also how to not over-employ my take take away resources from the day-to-day, from
support, cuz these other 35 sites still need to be maintained. They still need to be upgraded to Drupal 11.3, which we haven't done on those yet. Um they're on on 11.2, however. The advantages This sounds like the first of the advantages may sound like nothing, but it was huge. If we had to migrate all the image fields on our flagship site to the Drupal media library as
part of this We wouldn't have done it. I mean, we I mean, it would have been a different But, this was done in 2024. We have about 23 GB of images on the site. So, and they're all scattered across different fields that all work differently. They have all different names, different constraints, and then there's the WYSIWYG like now let's not start about that. So, it's a lot.
And also, we updated the site the site to Drupal 11 in 2025, which is great. We can especially now that it's on 11.3, we can truly use the latest goodness. I I'm a fond of object-oriented hooks and things. I've been waiting for those for a while. So, yeah. I was about to advance, but I don't control the slides. So, thank you. how to rebuild the interface. Our
some of our main issues are a lot were are still a lack of true front-end modularity. We have a giant had still have. Sorry, I'll keep doing that. Forgive me. It's It's hard to to speak in the past when it's still for pretty much in the present. We have a giant CSS file. Before I started the process, it was over 20,000 lines of CSS. Um so, not
pretty. because of something that I'll mention in a bit, our utility classes are out of control. I I don't like utility classes. I think they have a I guess utility. But, I think when there's there there are too many sometimes. And so, I wanted and that the consequence of that is that the old version of the theme had a lot of custom template for very specific needs.
And I wanted to make sure that we could abstract a little more and have fewer specific templates, more generic ones. And so this was getting in our way for that of that. Idiosyncratic component configuration, we have different components doing similar things, not visually but structurally. For example, one component has a title field, another component has a title field, they're not named the same and so they're styled
differently even when they look the same. So that's a mess and one of the things that I want to fix. Approaches. My favorite thing is every layout. So if you don't know every layout you should know every layout. it's a website, they call it a book but it's really a website. You can download It was published by Andy Bell and Hayden Pickering. They are gurus of CSS.
It provides layout guidelines to just build any kind of layout from the ground up in a very straightforward way. I I will show a couple of things about about It's easier to just read what it does than than truly to explain the value that it brings at 69 bucks. So it's low cost high value kind of situation. I wanted to embrace Drupal's best features starting from single
directory we already use display modes because why wouldn't we but we I I wanted to rationalize how we how we use them and um and introduce layout plugins into the mix and make better use of field formatters as well as sort of like a more micro approach to to to building our layouts. I will talk about an independency between themes and modules in a bit. Um One
of our main issues is also that we had component specific modules that were sort of assuming that our theme existed but we're really depending explicitly on it. I am progressively I progressively get away from that model model because I don't think it's a good model to have. But I I I do I I will show how I did I'm speaking in the first person this is all
my my brainchild so I did create a tiny bit of dependency between module and theme but it's intentional. It's there for a reason and hopefully I'll have enough time to to explain what that reason is. And progressive releases. We had two major releases of the flagship site since September. One was for the MD program section when when it was when it was launched in September. But again
as Evan said it wasn't major as in everything breaks we we got to start from scratch. No, it was major because of the effort involved and because of the amount of code that we were going to replace. And another one in in January for the refresh news section. But for the rest this model allows us to release individual components whether new or refreshed on a sprint to
sprint basis I guess every few weeks. Now we we're running on four week sprints cuz we want to be a little bit more relaxed and have more time for QA so so that's what we're doing. Results. Intended results and partly you know attained results. Let the theme run the front end not have modules run the front end. I want to always know where my front end is
being built visually speaking and then there's there are exceptions when it comes to layout, but at least from from from a purely graphic branding point of I want to know that I can go into the theme, know exactly where this component is being built, and I have to worry about it. Separation of concerns. Instead of a giant CSS file, use libraries. Maybe I have too many libraries
now, but they're being auto attached based on say entity types, bundles, display modes. I'm letting the theme run that so that if I want a a new library for the news node, I know how to add it. I don't need to attach I don't need to have a specialized template to attach it. It's just going to happen automatically. I like that. And ultimately consistent layout fundamentals in
different components, so that if I'm building a card here, I'm building a card there, even when those cards look different, they're still built the same. I can use the same layout plugin, and I just need to style them visually differently. So, they kind of look and work similar similarly. Next. So, these are our building blocks. Every layout is producing is giving us a bunch of stuff. The
most important things are the modular scale which helps with spacing and sizing of anything from fonts to um elements to padding and margin. It's all in there. And layout primitives, which I will go into in a second. The every base theme. So, the base theme is now called every because I couldn't find a better name. So, that provides us with built layout primitives based on the guidelines
from every layout. Built layout patterns. Every layout does not give us patterns. Like, if I want to build a card, it doesn't tell me how to build a card. It gives me the the sub components to build a card. Uh so, that card would be a pattern, and the every theme does that for us. Raw SAS modules, I can talk about SAS for an hour. Right now,
we're moving away like progressively. Maybe in a couple of years, we'll be able not to use SAS at all. Still use SAS. I like SAS, and it's it's still a useful tool for us. Um raw SAS modules that give like that allow us to to apply primitives and patterns to existing elements, and single single directory components, which build on top of of all of this. We have
a specialized layout specific module called HMS layouts because we're lack imagination. I lack imagination. Um which gives us layout plugins for our not really the components yet, but the the the foundations of our components, field formatters, which sort of work in a similar way, and specialized single directory components. For example, when it comes to we have well, what you might call what we all what we call
the hero regions, for example. Those are very specific to our our built in a very idiosyncratic way, but we have single directory components for for those. Um The Harvard Medical theme, that's been the name of our front end of our Drupal theme for ever for the past 8 years. I don't know before that cuz I wasn't there. Um we decided to keep it because otherwise it would
have meant rebuilding the site from scratch. It gives us select template specific libraries, as I component specific layout and visual styles, and the legacy code, which I'll go into in a sec. And yes, it needs to die. That's what it means. I don't know if you can see it. There's a little skull and bones there. Eventually, it will die. Next, please. So, primitives are from every layout.
This is the kind of stuff I'm talking about. How to stack things on top of each other. You all think you know how But if you want consistency, you need to think it through a little more. And the first time I saw this, I was like, I know how to stack things. I didn't know how to stack things. Boxes, how to apply padding in a consistent way.
So, if I'm building a a card, I'm going to put a stack inside a box. And if the card is horizontal, I'm going to put a weird stack inside it. It's a it's different. I'm going to put a switcher in there. But it's a topic for a different day. And all that. This These are not all the all the primitives that every layout is giving us. It's
just to give you an example of what it does. So, if I want to build a card, as I said, I'm going to use a bunch of stuff from from all the different building blocks that we have. The every theme is going to give us a couple of raw SAS modules, primitives for box, stack, and cluster. Again, for the horizontal variant of the card, for example. It's
going to give us a card pattern and a heading pattern. That I'm separating the heading here because the heading pattern that we use inside cards is actually its own thing. It's its own single directory component. It's its own layout plugin as well, so it can apply to other things. I wish I could show you all of this. It's There's just not enough time. And it gives a
single directory components again for a heading and card. The HMS layouts module is giving us a layout plugin for card, so that we can apply to display modes. And the Harvard Medical theme is is taking it the rest of the way with layout and component specific libraries. So, they look pretty as much as possible. So, and this is an example of the combo layout with single directory
component. This is the card in its horizontal variant. If you go to hms.harvard.edu/news/search, these are the search results and this is and these are our horizontal cards with a heading on the side and which has an eyebrow, it has a deck and and all sorts of stuff and it's responsive and it's uh I think it's it works pretty well. Oh, I mean, you can't see it's responsive
here. You can see it on the left. Uh next. So, how to remove technical debt? I don't know. It's it's such a mess. No, no, no. I It's a lot of work. Our main enemy It's a It's a mess because our main enemy is the fact that the that I want to say used to depend on the on the foundation, but it still does in a in
a way. So, removing that and I know we're not the only ones. I know there are a lot of people a lot of organizations, a lot of sites out there that are in the same situation. We're we're with their foundation at the base um doing a lot of work that's not always necessary and producing a lot of CSS that's never Uh so, we ended up with a
giant CSS file, which by the way duplicates another giant CSS file. And in the case of our what we call our microsites, there's another one which fortunately we removed a few months ago. Uh there are thoughtless thoughtless interdependencies as I mentioned before and component modules that don't do anything. They just declare configuration and now Drupal has better ways to to deal with that, and so we'll eventually
get there, too. First thing I did before the project last year, about a year ago, I started removing the explicit uh theme dependency while keeping the code. I basically took Zurb Foundation. I felt dirty doing this. Don't get me wrong. I felt dirty. Um but now I feel better about it. I took Zurb Foundation, stuck it in a legacy uh directory inside our theme, reconnected all the
wires. Uh that allows us to progressively eliminate all the uh obsolete code. Anytime we remove a component that has certain dependencies, certain uh underpinnings, we can safely remove that code, and nothing happens most of the time, so that's good. Uh eventually, we're also going to convert uh config-only modules to recipes. That's That's less urgent, but I I definitely want to get to that. uh the road to
zero legacy code is long. I'll show you in a sec how long that I'll give you a sense of how long that is. Um but at least now we are starting to know where things are happening. Uh modules are doing their specific thing. The theme is doing a lot, but not but hopefully in a rational way, in a standardized way, which will make it easier for us,
current iteration of the team of the team, to maintain the site, and eventually, maybe a future iteration of the team to uh take it on and and not yell at us because we did things in a weird way. But also sometimes yell at us. Um uh no config modules uh config-only modules, as I said, one day, cuz that's a long uh longer objective here. I think I
have a little chart in the next one, and then I'm done. Uh so, reduction of legacy code. Don't be fooled. Uh look at the Y axis, cuz So, since March last year that 4.0.0 was March. Um so, and and 5.7.1 was last week, I think. It's a 5% reduction. Uh but, one day those those lines are just going to disappear into the ground. Well, not the the
green one at least. The other one, unfortunately, we're still going to have to run some code. Uh so, or fortunately. So, but the green line one day is just going to run into the ground. So, I'm looking forward to that. I think I'm done. Thank you, Tony. Um we're going to have a one more slide of review. Just uh talking a little bit about our takeaways from
this experience. Starting with mine on formalizing large efforts as a capital P project. Adds structure and clear objectives. Preserves existing web team workflows, which is very important. Enforces deadlines and creates a consistent way to report progress to our stakeholders. And providing frequent, transparent stakeholder communication builds trust and understanding, especially when timelines shift or changes must be delivered incrementally. Which is often a requirement in this project. Uh
over to you, Evan. Yeah, on the stakeholder side, it really meant uh becoming kind of anointing yourself as a decision maker where it was clear that there might be decision maker gaps um and trying to do that with tact. Uh but, really that meant proving that you were bringing together a lot of input from a lot of different sides of the projects and making it clear that
anything you were doing was informed by good, you know, for a good reason um if or maybe just a really good instinct. But, uh everybody's doing their best to keep things moving ahead. Um and when it comes to me, uh to uh so, my takeaways I mean, I I I guess I kind of knew this uh stuff into the project. I I'm I'm happy to to feel
like this is being confirmed. Uh technology follows requirements. I don't think we should ever start with technology uh going into any project. But, going into a project where the technology already exists, uh it can't whatever technological changes we are uh adding or or applying to a project cannot be an afterthought. We're going to need to uh mold back the requirements based on what we have available and
what we we can uh possibly do. Um and embracing new technology doesn't have to be an all or nothing. We can't We don't have to say, "Oh, we want to redo the site and so 5 years from now it's going to be done and we're going to have all these new things. We're going to have Drupal 16 or whatever." I don't know. Um we can do it
progressively and thoughtfully. Um in a way I kind of have these two opposite goals. One is to redo the entire site without anybody noticing, but also redo the entire site while everybody notices every single time. So, uh these are in conflict with each other. I understand. Uh but it's kind of like what I what I want to I don't want it to be disruptive, but I want
it to be meaningful and important and and I want it to be something that lasts. And that's our QR code, which is also on that table somewhere, so. So, questions? Yes. You said with all those images, how are you handling accessibility? How do we handle accessibility for images specifically? Yeah, I mean did you did all the images already have tags? They're already all labeled. So, uh yes-ish.
No, not all of them. Um so, if I remember correctly, cuz it was 2 years ago, many of them already had uh all text that we could access and in in most cases we were able to put it in where needed into the media uh entity and all that. Uh there might might be some stragglers there which still don't have. Uh but the guideline there is if
you can't find if it's not we we tell the uh editorial team just put it in. It's again, there is always some manual approach in this kind of situation. Anyone else? Yes. I would imagine probably for someone on the phone though. When you're working on this project, I think I heard them say there's content strategy expertise in the Central Communication Office. What led to the decision then
to hire a vendor for the content strategy work? Uh sorry, did you say why or what was? Well, how did you make that decision to hire a vendor? Yes, so this is this is for Evan, what how was the was the decision made to uh hire a vendor for content strategy work? I really I I I wasn't part of the project actually when that decision was made,
but so I hope I'm not misrepresenting it, but I really think it was just um really necessary to augment uh what the team could do on its own. And you know, back to one thing I said about like this isn't a hat that anybody's really wearing full-time. Nobody really like there is if we had we were part of the communications team it might be different. Um but
it's really just a lot of things that aren't kind of bread and butter to people's day-to-day. Uh even some of the basic stuff. We do have one or two staff who are working in a more regularly than the average staff person. But for most people even just learning like accessibility rules and things like that is a daily grind. Um so it was it was quite necessary to
to augment what we were doing um with some real expertise. Just a congratulations on the launch and not having any 404s >> Thank you. Do you consider the URL redirect map that you built part of your technical Do we consider the URL Sorry, the So you you mentioned you built a a robust URL redirect Yes. Yeah. that you have, Oh, if that's part of our technical debt?
Right. Do you view that as something to contend with over time or I think I I think it's a it's a question for me mostly, right? whether the the URL redirects are are part of our technical debt. Um Now you're making me you're going to you're you're giving me nightmares, probably. Um I want to say yes and no. Uh the no part is be cause we unfortunately
a lot of our flagship our flagship has a lot of redirects that are living there and will live there forever and ever. Um and I just think it's part of this kind of uh operation to move a site into it and and I even if I do partly believe that it's inevitably uh we can't get rid of it. And uh it's just it's just going to sit
there. Can I Can I respond to you? Yeah, please. Absolutely. >> Yeah, yeah, and cuz I think as a cuz I'm actually a colleague of his and um we deal with this all the time. And I would say that we've had redirects which I didn't necessarily want around, but they existed for 10 years, but they were serving a purpose. And so as long as it's serving a
purpose, I would say it's not technical debt. The moment it does not serve a purpose, so you guys probably are going to have some redirects which are going to exist for quite a while. >> Yeah. Would it be great for them not to exist? Sure. But if they're serving a purpose, I wouldn't consider it technical debt. It's only like, "Oh, yeah, we could have gotten rid of
that like 18 months ago." Then it's just like bad developer. No, I feel like if we go through our redirects uh table and and there are some that haven't been accessed in 5 years, it's probably okay. Maybe one day somebody will complain if we if we remove them, but uh it's probably okay. Anyone else? Otherwise, I'm going to stop recording.
