We're proud to provide Drupal 8 services.

Hide additional information on this project
Show additional information on this project Expand
Drupal powers San Francisco's accessible emergency preparedness hub.

  • Agile/Scrum
Team Leadership

San Francisco takes emergency preparedness seriously.

As the fourth largest city in California, the city also serves as a center for business, commerce and culture for the West Coast. To support the City of San Francisco’s commitment to emergency preparedness, the Department of Emergency Management designed and developed a campaign to drive citizens to better understand how to be prepared in the event of an emergency. And in the unfortunate event that disaster does strike, the platform transitions to a communication platform where citizens can find the most up to date information directly from the City.

DEM had invested significant effort into creating a very engaging website to communicate to the public about emergency preparedness. However, the site was developed in a way that did not facilitate quick and easy content changes - a critical need when up-to-the-minute accurate information is needed. The site also fell short on a number of accessibility metrics.

How we did it.

When it’s business as usual, the site serves as a platform to generate awareness for how someone can better prepare themselves and their family in the event of an emergency. Visitors can download checklists, and complete forms, in addition to reading about how to prepare for different kinds of disasters, like an earthquake or tsunami. However, in the event of an emergency, the City can quickly enable a separate emergency home page which presents visitors with vastly different dynamic content updated in real time specific to the emergency, including an embedded interactive Google Crisis Map that displays information aggregated from a variety of external sources managed by the City.

Last Call Media provided a direct replacement of the existing site in Drupal 8, leveraging the out-of-the box D8 accessibility features and the user-friendly D8 in-place content editing interface. We also reduced the maintenance burden by bringing the blog, which had been a separate site, into the main site.

Our accessibility audit revealed that the original color palette used for the site designed relied heavily on colors that did not meet WCAG 2.0 contrast requirements. We were able to identify a compliant color scheme that remained within the existing brand guidelines for the new site. The site also relied heavily on icon fonts which were not taking advantage of Unicode’s private use area, and the HTML elements displaying the icons did not use appropriate ARIA attributes. Rebuilding the icon font and HTML markup to take advantage of those tools helped to greatly improve the screen reader experience for the site.

Another area that needed improvement was general accessibility related to interactive elements. Sections like flyout menus and tabs were difficult to navigate via keyboard, and were missing ARIA attributes that make them easier to understand and use. During the rebuild we switched away from using mostly-homegrown CSS and JS, and leveraged the Foundation CSS/JS framework instead. This change provided a couple of benefits - many of the missing accessibility features are included in the components provided by Foundation out of the box, it helped keep the nuanced details of the styling more consistent across different areas of the site, and it expedited the development process as well.

The City of San Francisco now has a means of communicating its emergency preparedness message with a site that is engaging, nimble, and robust.

Hide additional information on this project
Show additional information on this project Expand
Let’s make moves!

Team Leadership
  • Art Director
    Molly Taaffe

This summer, Last Call Media teamed up with Blackboard to build a new customer-facing site, using a component-based design system that could afford content editors novel flexibility while still reaping the benefits of a content management system. 

In building out Blackboard.com in Drupal 8 this summer, we found a fresh opportunity to position Blackboard as a user-friendly, customer-focused, and modern brand — the big idea was to introduce subtle elements of motion design into the theme in order to create a more engaging user experience. 

So, once we’d built out the new site architecture, components, and theme, we shifted our focus to visual refinement; our goal was not only to guide users through their experience through the use of animation, hover effects, and motion design, but also to delight visitors in subtle, unexpected ways by thoughtfully introducing some of these elements into the theme.


The main goal of this effort was to liven up the site and encourage users to interact with elements on the page. As an unintended consequence of implementing a highly flexible component-based theme — in which pieces of content could be mixed and matched in basically unlimited ways on any given page — the overall look and feel had come out very clean and organized, but at the same time more boxy and “dull” than we’d anticipated! Alongside this, there was also the challenge of giving the theme an institutional, educational feel that still felt friendly and helpful instead of overly corporate and austere. 


The first step in the process of adding microinteractions was to make sure the interactions were unified in their intent. For example, a rise on hover means the item is clickable, and if implemented on something that doesn’t click, would confuse the user.

Hover is a near universal sign for “this is clickable”, so we utilised a hover effect with shadow for the menu. For buttons, we opted to change from a simple color fade on hover, to a left to right swipe to change the color. This is more engaging than a simple color change, but it isn’t distracting from what the call to action is asking the user to do. It also matches the movement exhibited in the menu when items are hovered over. This addition of motion design to the menu helps users better understand where they are in a detailed navigation, and have a stronger understanding of the menu and product hierarchies.

menu interaction example

Some other elements of movement added, purely for aesthetics and to engage the user, were a hover effect where the background shapes move behind a product shot when moused over. This added interest to otherwise somewhat repetitive images of computers, and hopefully caused the user to take a second look. Another was a fade and slide in of images, from the side the image is on. This creates a very welcoming feeling as you scroll down the page. In addition, we added a video background to the banner area of the homepage, tinted Blackboard blue so as not to distract from the text and call to action button over it.

pause video example

In order to maintain our accessibility standards we had to think about users that may not be comfortable with the video at the top of the homepage, so we included a pause button to stop it from playing.

pause video example


The team at Blackboard is happy with the results of this effort, and it brings a really fresh engaging experience to the site. We would love to do another round of user testing (link to solution story about that) to see how or why these additions add to the site for users.

Microinteractions are a great way to engage the user, and add a wow factor to your site. However, we believe that handling these specifically and thoughtfully is the only way to achieve an effect that really makes sense to the user, rather than just a decoration. This means that every movement and reaction should be consistent and rational, with a meaning and result that are predictable to the user after a short period of interaction. We look forward to bringing what we learned here to anything we work on to add another level of sophistication.

Hide additional information on this project
Show additional information on this project Expand
Localization means more than multilingual.

  • Agile/Kanban
Team Leadership

Blackboard is a global education technology company whose product offerings differ in various parts of the world, and in different languages. In order to provide relevant information for site visitors in different markets Blackboard’s new Drupal 8 site had to not only provide content in different languages, but also content specific to each visitor’s geographic location. It also needed to be faster and cheaper for Blackboard to spin up sites of varying complexity in new markets. 


The goal of localization for Blackboard’s corporate site was to provide site visitors from around the world with content specific to their region in their region’s language. This means that in addition to displaying content in different languages, we also needed to be able to incorporate regional and dialect-specific (think “color” vs “colour”) versions of content. Also, since not all product offerings are available in every region we needed region-specific navigation as well (to avoid linking to irrelevant content for some users). All of this variation needed to exist between each regional site while allowing some content types to be shared across each region, such as dynamic “resources”, “case studies” and partner content.


Location Detection: Not only did we need to provide the ability to display regional content, we also wanted users to be aware of it. In order to do this, we use Acquia’s GeoIP service in order to determine where the user is visiting from. If their country doesn’t match the regional content that they are viewing, we present a modal dialog to show them that we have a section of the site that may be better suited for them. Once they either follow the link or indicate that they are happy where they are we set a cookie so that they don’t continually see the alert. If they leave the section that they have selected, we again alert them but provide the option to stay where they have navigated to.

Regional Sections: In order to provide the regional sections of the site we relied heavily on the “group” module. Each region is a “group” entity, with its own content. We have several “group-level” fields that allow us to define things like language, navigation menus that will appear in each section for each group, region-specific 4xx error pages, and the alias that serves as the beginning of the alias for each page belonging to the group.

Each page node is a part of exactly one group. There may be pages in different groups with similar titles and content, but this model allowed us to have content in the same language and still handle regional colloquialisms, dialects, etc. While the distinct page nodes were distinct for each region, we still had to recognize that there were some types of content had to be reused across regional sections, because creating new educational resource nodes with identical content for each region would not be sustainable. Those content types are allowed to belong to multiple groups. Content listings are built in a way so that they only display content that belongs to the regional section that is currently being viewed.

Multilingual: Possibly the most obvious part of localization is enabling content to be displayed in multiple languages. Drupal’s standard multilingual functionality doesn’t really play nicely with a content model that supports multiple versions (product pages can vary between markets) of content in the same language (think spelling differences between American and British English). In order to accommodate the model Blackboard required, we decided to use Drupal’s language modules, but to leave content translation out of the equation. Instead, we would create different nodes for each language that content was to be displayed in. From the administrative side this approach caused us to lose the “translate” operation for nodes, but in turn gave us a huge amount of flexibility. We were still able to create a site that supports content being entered in 10+ languages (including RTL languages like Arabic), and accommodate localized nuance for each region as well.


Blackboard’s requirements were complex, and caused us to rethink our typical multilingual strategy. Instead of creating a site that supports content in multiple languages, the approach that was taken here grants the internal team at Blackboard to create their new regional sections on their site, taking into account available product offerings as well as language and regional nuance - creating a platform for a site that is not only multilingual, but truly global.

Hide additional information on this project
Show additional information on this project Expand
Migrating from Workbench Moderation to Content Moderation.

Team Leadership

When the Commonwealth of Massachusetts first built their Drupal 8 site, they started in Workbench Moderation that allowed their authors to write content and put it into various moderation states such as “draft” or “needs review”. With over 600 content authors on the platform, this is a vital piece to help ensure content on the platforms meets their requirements. At the time of build, Workbench Moderation was in core and Content Moderation had not reached a stable release yet. Drupal 8 introduced Content Moderation in core and as part of our ongoing engagement with Mass.gov, we were asked to help with the heavy lifting associated with the upgrade in an effort to keep their site supported and up-to-date. The Commonwealth found this to be a greater challenge than expected and relied on LCM to facilitate the right migration path.

Our first step in initiating the migration was to investigate what we were dealing with. At the time, mass.gov had around 600,000 revisions with a moderation state that needed to be migrated from Workbench Moderation to Content Moderation. We started off by digging into Content Moderation’s code to fully understand the complexities and layers of the switch. We found the systems to be very different and with no pre-designed migration path, we deduced that we needed to create a handmade migration path from scratch, outside of a standard Drupal 8 migration. Once the initial configuration of this path was set up, the process was just to keep building the migration through trial and error and figuring out the fastest plan of action.

We knew that switching from Workbench Moderation to the new core module, Content Moderation meant the mass.gov site and its authors would benefit. For a government site, security is always a concern and therefore a top priority. When working with a core module, it is actively supported for security and for any updates that core has as opposed to still running on a contributed module. 

After we felt sound on the coding portion of the switch, we wanted to make sure we were in alignment about expected workflows, transitions, non-transitions, and revision states. We started with around 20 transitions in Workbench Moderation that we were able to consolidate to 5 transitions in Content Moderation for a more optimized workflow. 

We also worked on rebuilding some views such as the “all content view” and mass.gov’s specific dashboard called, “MyContent Block”, which contains all the content the logged in author is watching. 

After a successful switch, mass.gov users are leveraging Content Moderation to moderate content. We are implementing a patch to Content Moderation for the view for “filter by moderation state”. This filter was missing some indices that would cause MySQL to incorrectly do a full table scan instead of an indexed scan of content that caused a lot of performance issues. We ended up writing a patch to include the missing indices that would bring down the query load time on the “MyContent Block” view from 15,000 milliseconds to 200 milliseconds. We plan for this patch to be made available for other sites experiencing the same issue with a lot of content like Mass.gov does.

Overall, the goal was to make the switch as seamless as possible and create little to no changes to the content authoring experience. On the module itself, content authors did get some smaller UI changes such as the submission process with dropdowns for moderation states. When it came to deployment, authors trying to make changes during this window would have experienced downtime but we were strategic enough to initiate migration on Memorial Day weekend and experienced no content loss.

When we started the migration path, the expected migration time was 15-20 hours. When we executed deployment, we got the time down to 4 hours through our optimization efforts. The migration was incredibly successful on deployment and we experienced no issues!