Sprint 1 Notes - LocalGov Drupal: Microsites

Sprint 1 started with a shift of energies. Ekes and Finn came back from DrupalDev Days in Ghent, having chatted with anybody they could collar about Drupal distributions, Group, microsites and all things LocalGov Drupal (LGD). New papa Stephen also returned to bolster the back-end team, joined in standups by swaddled daughter Jessica. Meanwhile Maria was the next in line to catch covid, hampering somewhat the progress of the front-end stream.

By sprint-end, though, we had all rallied well and were able to demo a suite of decisions that gets us much closer to being able to start building. 

We have made significant strides on: 

  • how council admins will be able to create sites; 
  • how user permissions will be set; 
  • what content types and blocks will be available to site editors; 
  • how we will build the ability to customise the theme; 
  • and how the interface for managing those customisations will look.

Sprint highlights

  1. A refined categorisation of council microsites 
  2. Proof of concept: how to customise the front-end theme
  3. Proposal: content types, page regions and Paragraphs
  4. Conversations with the University of Oxford Mosaic team
  5. Proof of concept: site creation and user permissions and content and configuration
  6. Proposal: site administrator user interface
  7. Planning for testing
  8. “Business as usual!”

1. A refined categorisation of council microsites

We were unsure that the categories of site we had identified in the previous sprint were adequate, so we re-examined fifty existing council microsites in order to understand them by their primary purpose, their primary audiences and their visual vibe.

Summary

Information and advice. Most are some version of this type of site, in which the content is on a particular topic and often structured in the form of a service or searchable database.

  • Visually these sites might appeal to a specific demographic (eg young people) and may have their own branding, but as often as not still feel like formal, authoritative communication channels.

A directory of resources, such as courses, jobs, market stalls. Many of these are third-party resources, but may also include rooms or venues for hire from a council.

  • In terms of their appearance, these sites tend even more towards the official and functional.

An attraction, such as a museum, a stately home, a fair or a Christmas market. The intention is to drive traffic to the attraction in real life.

  • These sites bring elements of joy, consumerism, leisure, heritage and value to their choice of images, typography, language and colours (especially warm colours)

A site that advertises a commercial service, a project or a campaign.

  • These sites are competing with businesses or are trying to persuade about a policy or initiative. As a result, they typically look dynamic but trustworthy. Often they lack clear calls to action.
Sticky notes on a Miro board, showing the functional categories of the sites along with their audiences and visual design vibe.

2. Proof of concept: how to customise the front-end theme 

Site administrators will need to be able to apply a custom theme in order to give the microsite a distinct look and feel. This is one of the primary distinctions between a core LGD install and a microsite install.

Mark developed the customisation options agreed in Sprint 0 and evolved them into an impressive prototype in Drupal to pull the configuration in from the microsites configuration. This very early proof-of-concept is not meant to reflect the final presentation, just the mechanics of the architecture of configuration to theme. You can watch a demo of the footer aspect. 

3. Proposal: content types, page regions and Paragraphs

The front-end stream moved forward the discussion on desirable content and layout options during the sprint, culminating in a proposal to the Working Group of representative councils at the end of the sprint.

The proposal eschewed the traditional MoSCoW prioritisation in favour of a KYIV schema. Our working hypothesis is that the following is in scope for the project (marked as ‘Keep’ or ‘Yes?’ in new money):

Content types

  • Directory (for Info and advice, and directory functions)
  • Event
  • Article (for all timebound content such as news and blogs)
  • Section page (including homepage)
  • Content page (a basic page for non-structured content) 

Page regions

  • Hero (for main images and display of key fields per content type)
  • Content (for Paragraphs)
  • Related content 
  • ‘In this section’ menu

Paragraphs

  • Text
  • Image
  • Video
  • Button
  • Attachments
  • Promo blocks [aka “featured teasers”]
  • Media with text
  • IA block (menu block)
  • Embed block view
  • Quote
  • Accordions
  • Table

Most of these are already in LGD core. We feel that there is a virtue in reducing the complexity from LGD to streamline the content management process for microsite administrators and managers This means not including some of the core LGD content types (such as Services, Subsites, Step by step, and Guides) and Paragraph types (Fact box, Key facts, Tabs, Key contact block) that are useful for main council sites but less appropriate to microsites. However councils could enable and configure these other content types and paragraph types if they wished, with a little additional development time.

The Microsites Working Group confirmed that this set would meet their needs, although they did also request a greater range of Paragraph options at launch.

4. Conversations with the University of Oxford Mosaic team

It’s always invaluable to spend time talking with people who have tackled similar problems and we reached out to the people behind Mosaic, a system developed by the University of Oxford IT Services team. Mosaic serves up microsites to research projects and departments within the University; some of our team had worked with it before and in many aspects it fulfils the same needs as LGD microsites: balancing configurable design with architectural consistency; catering both for typical and edge-case functional requirements; handing over content, user management and design control to site editors.

Ruth Mason and John Tarling were very generous with their time, and our conversation roamed widely from how to encourage uptake, things they would do differently (eg giving site owners fewer initial config options but with the opportunity to add custom code, so long as they took responsibility for it), automated accessibility testing, anecdotes of recovering deleted data, as well as Agile Collective’s experience in migrating content from Drupal 7 to Drupal 9.

5. Proof of concept: site creation and user permissions and content and configuration

Ekes and the team have been homing in on a preferred technical architecture for several weeks and, having finally rejected Organic Groups and other solutions, landed on the combined power of Group module and Domain module.

The demo that Ekes created consisted of two microsites on the same install, with content specific to each. Adding users to Groups can only be done at the council level, which means that we will have two admin areas: one for the council admin to provision the site and manage the domain settings and a second for the site administrator for an individual microsite.

We have found it surprisingly difficult to come up with names for each of these two roles that are clearly comprehensible! Both are administrator roles, but one is the provisioner of many sites and the other is responsible for managing the content of just one.

6. Proposal: site administrator user interface

Inspired by Mosaic and by the default user interface (UI) offered by Drupal 9 and the relevant modules identified by Ekes, we mocked up the sort of interface we are proposing for the microsite administrator. A combination of menu items and horizontal and vertical tabs, the interface might seem at first a little confusing, but initial responses from the Working Group were that we had introduced sufficient visual hierarchy and clear terminology to make life easy enough for microsite owners.

Wireframe for the site admin options template

7. Planning for testing

So… testing will be essential and, while we are taking proposals and proofs-of-concept back to the Microsites Working Group, we are lining up Sprint 4 for dedicated testing with real users.

It’s early stages for our planning here but by working out what we need answers will encourage us to focus our energies in the next two sprints on delivering the basic functionality. We are looking to test:

  • Experience of provisioning a microsite
  • Ability to set user permissions
  • The site admin’s experience of configuring site settings, theme settings
  • Adding content to a basic page via a range of Paragraphs

8. “Business as usual!”

As we beaver away on the microsites project, LGD core also needs some upkeep. Over the duration of the sprint Stephen (with Jessica’s help), Finn, Ekes and Andy have:

  • updated Lando configuration to run PHP 8.1, and in doing this fixed all the known issues with running LocalGov Drupal on PHP 8.1, potentially saving our 26 councils a lot of money;
  • started listing things that we need to do to get Drupal 10 working. Looking far into the future!
  • Streamlined the testing architecture to 
    • test on multiple versions of PHP (7.4 and 8.1)
    • Only run coding standards and PHPUnit tests on the project code in question, not against the entire distribution for every pull request, saving significant time.

Throughout the Microsites project the Technical Group and the wider team continue to fix bugs, onboard councils, review pull requests and push LocalGov Drupal core forward through our regular Merge Monday calls and other Technical Group meetings. If you are developers working in councils or suppliers, please join us to help keep things moving, (More meeting details on the public calendar) or email finn@opencode.uk to get added to invites.

Back to blog