Preparing for user testing
User testing is an important part of software development and the opportunity to test with real users at an early stage is a welcome addition to any agile project. We are lucky enough to have access to future users from 5 councils in the Microsites Working Group, who were willing and able to give some time to test the early prototypes of the LocaGov Drupal Microsites system. We identified sprint 4 as a two week window in which we could perform user testing of the work to date, synchronising with half term and the extended bank holiday weekend which those with children were taking full advantage of. We aimed to test the architecture and user experience of creating new microstes, assigning users, configuring the look and feel and adding some content.
By the end of sprint 3 we had 15 interviews booked in with users from 5 councils.
This drew a distinct line in the sand by which we needed to be ready to test the assumptions and work to date.
Testing scripts
As we progressed towards the end of sprint 3, Richard, Maria and the testing team finalised a testing script based on the functionality available to test. We identified key user stories to test with which included:
- A microsites controller logging into the control site and creating a new microsite.
- A microsites controller creating a new microsite admin user and assigning them to have access to the new microsites.
- A microsite admin logging into the microsite to configure the look and feel of the site, making changes to colours, fonts, logo and footer content.
- A microsite admin creating some basic page content and paragraph components.
Fix all the things
An initial test run revealed a number of bugs and issues that needed fixing to be able to run through the testing script. This inevitably led to a rush of work towards the end of the sprint as the deadline approached, but the team rose to the challenge and pulled hard together to squash or work around all of the known bugs. Nothing like a deadline to focus the mind!
Automated build of the testing sites
When testing with multiple users from multiple councils, we need a number of testing sites ready for the users. This presents an interesting challenge as to how to present users with the same starting point while also making it quick and easy to re-install a site when needed.
Our sysadmin and dev-ops guru Stephen Cox set up a system to automate the deployment of testing sites. This was built on Jenkins and allowed everyone on the team to access push-button code updates, re-install of a site, execution of drush commands.
As we were testing with 15 people from 5 councils, we set up a testing site for each council and used the same site to test different types of user.
The automation of deploying and re-installing was pivotal as we had several user testing interviews back to back within a day and needed to ensure we could reliably replicate the testing environment when needed. Nice work Stephen!
Default content
When a site is first installed it is usually empty, but it can be useful to include some example content to illustrate the content type and the page components (Drupal paragraphs) that are available to the content designers. Where the microsite admin also has some control over the look and feel of the site, this could be particularly helpful to rapidly illustrate how configuration changes to fonts, colours, layouts and spacing options will affect content.
To this end we decided to deploy a page of default demo content with each microsite which would speed up the process of seeing how changes affect content for the user testing and also give the project team a consistent piece of content against which to test changes.
Building on our experience with the demo content in the LocalGov Drupal Demo module, we usedDrupal’s default content module (https://www.drupal.org/project/default_content) to export a single node of content with layout paragraphs and a number of example paragraph page components.
Longer term we think this is a good approach to providing some default content to illustrate the functionality available while also allowing content designers to edit or delete the default content if desired.
Business as usual (B.A.U.)
Meanwhile, back on the ranch, work continues on the main LocalGov Drupal distribution to fix bugs, respond to changes in upstream projects that we depend on and look at new features in the main distribution. Merge Mondays (every Monday at 2pm) continues to be an efficient way for developers from councils and suppliers to review, approve and release fixes and updates to the numerous projects that comprise the LocalGov Drupal distribution.
Technical Group Drop-in
After the recent reboot of the Technical Group, we’re having a weekly drop-in session to review and coordinate technical developments such as potential new features, upcoming Drupal versions, depreciation policies and such like. These are currently on Thursdays at midday but might be changing, so keep an eye on the public calendar and Slack channel if you’d like to join. This sprint we discussed a number of pertinent issues, including:
- Is it a good idea to add multiple geos to a directory venue?
- Add CTA buttons to service sub pages
- Do we need a map format?
- Do we want to recommend Entity Share?
- What's the process for bringing Waltham Forest search and events functionality to the distribution?
This last point led to a proposal to start a new working group to share the great work that Waltham Forest have been doing to customise Apache Solr configuration for a slick search experience. An optional LocalGov Drupal Solr Search module could save councils a significant amount of experimentation and set up time.
You can see notes on our discussions in a publicly available Google Doc.
In general, it has been really good to see more people joining these technical discussions from both new councils and new suppliers, so do please come along if you are interested in discussing anything technical.
