2016 is off to a great start – we spent last week looking back on our work in our previous 100-day drive and looking ahead to plan our next 100 days of work.
This month sees the start of our new Programme Director, Ross Ferguson. Ross has joined us from the University of Bath, where he headed up the team transforming digital publishing and service delivery across the university. We’re looking forward to hearing lots from Ross as he settles into our team. Welcome aboard!
Update on the last 100 days
- Justice – review and final iterations to Victims and Witnesses content following on from peer review – further content team research and ideation, incorporating a number of usability testing suggestions ✓
- Justice – Research and creation of content around eligibility and the application process for Legal Aid ✓
- Education – providing content to cover the school-leaver journey (applying for financial support and applying to higher education) ✓
- Business – discovery and production of high-level exporting content including extensive collaboration with stakeholders in the Scottish business community, represented by the Customer Alignment Group ✓
- Housing – holding stakeholder planning workshops and writing content for buying, selling and building a house, including information on grants and help to buy schemes ✓
- BAU – managing the content inbox, working with GOV.UK via Zendesk, creating a content mapping process, writing content based on enquiries to the Central Enquiry Unit ✓
Publishing Platform features
- Adoption of a tabbed interface on the content editing interface ✓
- Implementation of a markdown editor ✓
- Image and PDF storage – backend work complete, front-end work carried forward ✓✗
- Notifications of expired content – expired content displayed in Publishing Platform interface, push notifications carried forward ✓✗
- Creating Help and Support pages and linking them where relevant for gov.scot and mygov.scot ✗
- Implementation of new content formats for gov.scot ✓
- Design and implementation of UI – partially complete, carried forward. ✓ ✗
- Authentication refactor – carried forward ✗
Digital style guidelines
- Carried forward as part of next phase of work ✗
Usability and accessibility testing
- gov.scot user testing, mygov.scot accessibility testing and Victims and Witnesses content testing ✓
- User testing carried out on mobile devices for 50% of tests ✓
The next 100 days
In terms of what we’re looking to achieve next, the five main areas of work are:
Publishing Platform features
- There’s a lot that we want to do to support the needs of users of the publishing platform and to better service the needs of users of our site. One big piece of work is to aid the editorial workflow through the additional of new roles and privileges.
- Another area we want to sort out is the ability to link to content in a new way – at the moment we use the slug URL but sometimes content has to move around. Whenever content moves we need to go back and rework the links to that content – the next step will be to link to content by ID, allowing content to move without affecting links.
- On the flip side of maintaining links inside our site, we are also looking to improve the monitoring and tools around maintaining links out of from our site – often outside organisations make large structural changes to their sites and their content moves. We want to pick these changes up on a more routine basis as part of our day-to-day work and are looking to build a small feature around this.
- We have some ambitious goals around reworking our publishing platform’s authentication, maturing it to offer the features and tools required by a large publisher user base.
- We are also going to look at how we can better surface content when a user searches within our site. Recently there have been some niggles where the way some of our content formats are indexed hasn’t allowed the content to appear as highly for some terms as we would like.
- Things in this digital world are changing and another area we’re looking at is to stay current – one of the frameworks we use, Angular, has just moved on to a new version (2.0 is in Beta). We are going to look at what it will take to upgrade as part of our next batch of work.
- One of the most powerful aspects of our site is the way we can help a visitor to a site in a time of need. For example, if you have just lost your job you might just be looking for one piece of content (information about your legal rights) but our site can surface different threads that become a part of that (debt, stress or mortgage advice). We are going to do some research around how we portray life events on the site, how users might want to interact with these, and how we can surface the right content in search.
- Our content work roughly forms into two categories – business as usual on the work we’ve already started and have in our pipeline, and the commitments that we’ve taken on for new content. We’ll share more about this content in the coming weeks.
Programme level work
- We are going to refine our process for getting links to our content.
- We are going to refine how we are approaching sites for decommissioning.
- We are going to put in place a clear route for how we transition citizen-focussed gov.scot site content onto the mygov.scot site.
We’ll update you on our work over the coming weeks. As always, if you are keen to get a closer look at our work then give us a shout on Twitter or Yammer and come along to one of our product demos.
Follow the team via @mygovscot on Twitter for more updates. Want to comment? Let us know below!
This is a post by Rajesh Yarlagadda and David Vidal, our test engineers.
This post is the third post in our series covering how we approach continuous delivery, covering our approach to testing.
Testing is an essential component of each and every phase of the mygov.scot development process, with quality being “baked in” to the product at every stage. This blog post provides an overview of how we approach testing, and some of the tools we use. Feel free to get in touch if you’d like to know a bit more about a particular technology or our reasons behind using it.
After creating a new feature to meet a particular user need, our developers submit changes to our version control system – this can include source code, environment modifications and configuration files.
Following a commit to the version control system, the continuous integration server will do the following:
- Trigger a build
- Run automated unit tests
- Perform sonar code quality check
- Automatically deploy the successful build to a development environment
As we’re almost at the end of the year, we’d like to thank everyone who has contributed to the mygov.scot site over 2015. We have had a huge amount of input from fact-checkers and subject-matter experts and we really appreciate all of the work that has gone in to ensuring that the information that we make available to citizens is accurate and easy to understand. A sincere thank you from all of the mygov.scot team.
The office will be a bit quieter from the 23rd of December but we will still be monitoring the content mailbox daily, as well as ensuring continuity for the public-facing site. Technical support will also be available for our content writers throughout the holiday period.
We’ll be back to normal on the 5th of January and looking forward to kicking off our next 100-day drive – see you then!
This is a post by Reece Cargan, one of our content designers.
Over the past 12 months, I’ve seen lots of changes when it comes to content on mygov.scot – in terms of its appearance and the way we approach content creation. This is due to a number of factors:
- we work in an agile environment
- the technical evolution of our publishing platform dictates a content change
- UX input, usability audits and user feedback help us improve content
We’re constantly evolving our offering in an attempt to ensure user needs are met, and hopefully exceeded.
Meeting the local needs of our users
One of the biggest changes has been the way we meet the needs of users who are looking for local services, like council tax or bin collections. As our colleagues at GDS have already established, people shouldn’t need to understand the structure of government to be able to access services.
So, how do we create content that’s appropriate for Scotland as a whole, yet manages the expectations of our visitors looking for services from local authorities?
This is a post by Sam Tilston, one of our user researchers, and Scott Langley, one of our user experience designers.
As part of our on-going accessibility work on www.mygov.scot, we recently carried out a round of accessibility testing. It’s an important part of our overall accessibility strategy to carry out testing with real users as they can help identify issues that automated tests and expert audits won’t find.
We interviewed 10 participants over a two-week period at a number of locations across Scotland. We asked the participants to carry out representative tasks on the site and explored a number of key areas, primarily to evaluate the site and ensure it is usable for users with disabilities and users of assistive technology.
We recruited a spread of participants who had either a physical, cognitive or visual impairment. Although we segmented the participants into these three groups it is important to be careful with categorisation, as there can be large differences within in each category and the severity of the impairment can vary greatly. Additionally, it is common for people to have multiple impairments.
We tested across a variety of platforms and participants made use of their own assistive technology (including screen-magnifiers, screen-readers, styluses and other input devices).
This is a post by Kate Saunderson, one of our user researchers.
I was part of a team that designed and delivered a discovery workshop to explore the barriers that SME’s face in raising funding. At the full day event, we explored barriers and solutions with 56 SME’s, advisors and funders. During lunch, an attendee told me that he had been attending similar events for over thirty years. “This one has a lot more dynamism but what do you plan to do next? Usually nothing happens afterwards”. The hard part, a surprise to many, is not undertaking research with your end-user, it’s continuing the dialogue. It is important to talk about what you are doing next, what you are not doing, and how stakeholders can continue to engage with you.
This post explores how to design a discovery workshop and how to build in feedback to ensure attendees can continue to see the value in the work.
Planning a discovery workshop
When planning a discovery workshop, our user research and engagement team recommend starting by asking three basic questions:
- What do you need to understand?
- What will you do with your findings?
When satisfied that you are able to answer these questions then you can begin to think about who to work with, when, and how best to engage with them.
This is a post by Gordon Clark, one of our Infrastructure Engineers, and Jono Ellis, our Social Media Manager.
This post is the second post in our series covering how we approach continuous delivery, covering the tools that we use.
We are not precious about our servers, they are just tools for a defined purpose and when they’ve reached the end of their usefulness we can get rid of them. They are disposable. This is something you can only do with cloud computing – we don’t own a physical server anywhere; instead we create and configure servers from our cloud providers. The benefits are the speed and agility that this setup offers us. As an example, in order to test a proof of concept we could spin up several servers to do a task, gather whatever stats we needed, and then we could destroy them. With no physical server needing to be purchased, set up, powered, etc. there are significant environmental benefits to this approach.
We use several tools in order to facilitate our server configuration management:
- Puppet – provisioning and configuration of hosts (we use Puppet in a masterless way);
- Packer – definition and creation of our base image;
- Base images – assignment of a role and an environment (based on the rules for the role a host is given, the host will self-provision. This means that the host gathers packages and configuration from a known artifact repository such as Debian);
- Vagrant – deploying Puppet runs locally for testing purposes.
Roles and Profiles
The role a server is provided with equates to a business need i.e. a web server, an application or a database server.
Each role (e.g. web server) has an accompanying module in Puppet. This Puppet module in turn contains one or more technology profiles, which are also described in Puppet. Each host can only be assigned a single role but each role can contain multiple profiles (which is turn can contain multiple modules). The modules are directly related to an individual technology, e.g. NGINX, Java or PostgreSQL. The diagram below shows how the hierarchy is arranged. It should be noted that the modules are generic, they can be used in any environment and do not contain any configuration related to an individual host. The configuration data is abstracted to Hiera.