Welcome

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

Content

• 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. ✓ ✗

 Infrastructure

• Authentication refactor – carried forward ✗

Digital style guidelines

• Version 1 complete and online ✓

Format review

• 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.

Infrastructure

• 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.

Life events

• 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.

Content

• 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 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

The test engineers manually promote the successful build to the integration test environment using an automated deployment job. The integration test environment is designed to run all automated tests i.e. accessibility tests, End to End (E2E) tests and browser layout tests. If a feature change completes all automated tests with no failures then it will be promoted to the exploratory test environment.

The exploratory test environment is designed to run session-based exploratory testing and browser testing on multiple devices using the ‘Ghostlabs’ software. On completion of successful exploratory testing, feature changes will be promoted to the performance test environment.

The performance test environment is designed to run performance tests i.e. smoke tests, load tests, stress tests, soak tests and security tests. On completion of testing, the feature changes will be demonstrated to the product owner and other stakeholders.

• Smoke – check to see that there has been no significant drop in performance between builds
• Load – check that the site can handle an acceptable level of users (currently set to 1,000)
• Stress – check that the site can either handle or break gracefully for an extended number of users (currently set to 5,000 users)
• Soak – check that there are no memory leaks over a longer period (currently set to a day)

On completion of the demo, testers record the component versions and save this as the ‘last known good version’, after which relevant artefacts are pushed to the build repository server.

Every Monday, the mygov.scot team will create either a blue/green off-line production environment using the ‘last known good version’. Smoke testing is carried out on the off-line environment before it is switched over to being the live, production version.

Types of test

There are many different types of test we perform – the starting point is the user story, written for each new feature before work begins. Before a feature is even validated against the user acceptance criteria we validate against system quality attributes – performance, accessibility and security. Once we complete these tests the next stage is exploratory testing, to validate the story.

We look to ensure that we have:

• Complete functionality on a range of different browsers. This includes Internet Explorer (versions 8 to 10 running on Windows 7), Chrome (running on Ubuntu), Safari (on Mac), native browsers on iOS devices (versions 6 to 9) and native browsers on Android (versions 2.2 – 5.1).
• HTML code in line with WCAG 2AA accessibility standards, tested via the open source tool Pa11y
• A good level of readability, tested via ChromeVOX
• A secure site through automated security tests performed by ZAP, which scans and validates the site against the top 10 attacks (as identified by OWASP)
• Consistent visual standards and UX design, tested via the GALEN framework layout testing which captures an image of the page if elements of the page are not where they should be.

Improvements

Testing takes time – performance tests run in the background and can take up to a day to run per test, manual tests take several hours per day. With every new test added the quality of our work goes up, with every test automated or moved to an earlier stage in the process we can spot and correct issues earlier. We’re working to include performance testing as part of our continuous integration server process as this will allow us to spot code which has the potential to slow the site down and correct it much earlier.

Security testing is currently more reliant on manual processes and is something we are also working to increase the automation on. We are also looking to expand the number of devices and browsers that we test on – we cover a good number already and we are looking to up that number.

Follow the team via @mygovscot on Twitter for more updates. Want to comment? Let us know below!

You can find out more in the original blog post introducing the web analytics initiative.

Progress

Things are progressing well considering resource and other activities which are being undertaken within the programme. So it’s great to be able to say that we now have access to around 34 web properties out of all of the websites within the web analytics initiative, which is hit rate of about 12.7%. In addition, 180 of the websites we know about are considered ‘core websites’  – an area of knowledge we wish to grow.

Learnings

We’ve begun to spend time aggregating metrics for each website to build the ‘big picture’. This includes data from places like Majestic SEO and Google Analytics. There is potential to add our own metadata to group and classify websites as well, providing additional analysis potential, for example:

• Education
• Health
• Justice
• Environment
• Housing
• Local
• Tourism
• Transport
• Business
• Young People
• Culture & Arts
• Other

It’s rough right now, but we’re aiming to refine and improve this in the coming months. In the future, this could allow us to produce visualisations that highlight topics most linked to on the web. In it’s original form, the below visualisation can be used to help us understand that political websites are some of the most well linked to, which includes Scottish Parliament.

The more we can learn about this web portfolio, the more we can share insightful and meaningful insights over the next few months with participating organisations.

There’s a real opportunity to begin to form closer relationships with performance analysis colleagues from across Scottish Government as well – something we intend on exploring over the next few months.

We’ll keep in touch.

We’ll be sharing updates on this, and much more on social, so follow the team via @mygovscot on Twitter for more. Want to comment? Get in touch below!

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!

Merry Christmas!

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?

What your local council does
Scotland’s 32 local councils are responsible for a range of public services. Their powers include:

• mandatory powers – such providing schooling for 5 to 16-year-olds, fire services and social work services
• permissive powers – such as economic development and recreation services
• regulatory powers – such as trading standards, environmental health and licences for taxis and pubs

First off, we ditched the term ‘local authorities’ in favour of ‘local councils’. This is the term people use and is in keeping with our manifesto of using plain English.

Then, we tried to not re-invent the wheel. GOV.UK uses a ‘postcode’ search to facilitate journeys to council websites. Behind this is a large database of links for each service at all the council websites in England and Wales.

Our regional drop-down

We quickly realised this approach wasn’t quite right for Scotland. Geographically we’re much smaller and our 32 local councils could be easily accessed via a simple drop-down menu.

We made sure our content designers have flexibility when using these drop-downs, including being able to:

• edit the title text
• place the drop-down wherever we want to on a page

This means users can read information on council tax, bin collections or planning permission on single pages, with deep links to their local council contained within the content. This enables us to set the national context while also linking to local government variations and devolved content within one page (and with one click).

Flexibility is important, as we need to be able to let people know when a service isn’t available in their area. For example:

• landlocked council areas won’t have coastguard services
• Scottish Borders Council doesn’t provide council housing
• some councils don’t pick up garden waste

Working with local councils

As mygov.scot is a citizen-led site, we aim to work closely and in partnership with public sector organisations to put users at the forefront of service delivery and design.

To help us prioritise our backlog and make sense of the landscape, we asked for help from 3 local councils – North Lanarkshire, Midlothian and Glasgow City. They provided us with web analytics and placed a survey on their sites, asking people why they visited and if they found what they were looking for. From this master list, we segregated the needs into 11 categories – mirroring the Scottish Navigation List to enable us to understand the services handled by local councils.

We interrogated the analytics and survey results to understand why users visited the sites. An area with high traffic for local council users was ‘rubbish and recycling’, so early in our evolution we ran a pilot on how we would represent this information on mygov.scot.

Users are presented with a simple drop-down list of local councils…

The link takes users directly to the appropriate page on the local council website

Future iterations

As we had already established that users don’t know (or need to know) who provides a service, we design task based content and deliver a ‘managed journey’ to the appropriate service provider based on a region.

Next steps

We plan to use this format in other contexts, like NHS boards, police stations, and our work with Marine Scotland that may see us linking to their Fishery Offices across Scotland. We are working on expanding the drop-down format to allow us to include contact information for organisations. We are also looking to add in functionality to visualise the areas on a map (especially important where only certain areas of Scotland are covered, or where another organisation may be listed as well as local councils).

We’ll be sharing updates on this, and much more on social, so follow the team via @mygovscot on Twitter for more updates. Want to comment? Get in touch below!

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.

Our approach

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).

Why it’s important

Accessibility impacts a large number of people as nearly one in five (1 million, or 19%) people of working age in Scotland are disabled. We also live in an aging population, and as we age, most people experience a decrease in vision, hearing, physical abilities, and cognitive abilities, which will in turn lead to an increase in the number of people requiring assistive technology to access the web.

However, more significantly, it is important to get accessibility right as it impacts everyone. If something is inaccessible for a user with an impairment or disability it is likely that it will impact all users. By improving the accessibility of the mygov.scot site we make it a better experience for all.

Findings relating to the mygov.scot site

Given that we’ve been through previous rounds of both usability testing and internal accessibility testing the site had a healthy starting point. However, we uncovered a lot of insight for areas to work on as well as things that we’d like to continue bearing in mind for future iterations.

• Consistency – sometimes formats changed when users navigated between areas of content. Some users, particularly those using screen-magnifiers, can lose their context if formats alternate e.g. from two columns to three columns.
• Headings are important– users tend to scan through pages and pick out headings and sub-headings to help them navigate, and is a key method of interaction when using a screen-reader. The headings also aid less tech-savvy users who are less likely to use the search function and rely on the main navigation. Therefore the words that are chosen are crucial e.g. it’s important to see a word such as tax in a navigational heading if the user is looking for where to pay their council tax.
• Prioritisation of calls to action – users of screen-readers missed some of our calls to action, as they tended to tab between headings and links. In future we need to be even clearer on our calls to action (whether it’s a dropdown list, a link, a button or a phone number).
• Terminology– with most of our content we write about the user directly e.g. your needs. This can be confusing in situations where the user is searching on behalf of someone else, such as someone looking for elderly care for a family member. We need to consider the words that users are familiar with and will use commonly, and furthermore how this applies to search.
• General usability – we identified a number of minor usability issues, which can be amplified for users of assistive technology e.g. content below the fold was occasionally missed by tablet users, some page elements could be slow to react, and there was a lack of use of the right hand side links. Once improved, the issues raised here will vastly benefit the overall performance of the site.
• We’re part of a bigger journey– users may well only be using mygov.scot as part of a bigger journey and we need to work even harder to ensure that users can easily see if they are being signposted away from the mygov.scot site and make the user’s journey as simple as possible – especially if we feel that the external site does not currently offer a good user experience.

Wider user research findings

There are also several points which are relevant to any website in the Scottish public-sector landscape:

• Online confidence and experience a bigger factor than impairments – we scaled all participants on their level of online confidence, as it was observed that a lack of confidence or experience online was often more of a hindrance to using the site than the severity of any impairment.
• Problem solving is required to complete some journeys – this means that some people will always rely on additional support in some form, whether that is digital hand-holding or real-world assistance. We plan to further explore cognitive issues through usability testing in 2016.
• Never make assumptions around literacy – the actual words that we use in the public sector as whole can cause issues. We’re already doing work to improve the readability of the mygov.scot site via SMOG tests but all of Government can learn to make content easier to read and understand by cutting out jargon, unnecessary technical terms and abbreviations.
• Accessibility is part of the bigger picture of Digital Participation – refining web accessibility is important but improving digital public services also requires the removal of other social, economic and cultural barriers.

Next steps
The mygov.scot team have several actions that have been directly created as a result of the work and accessibility testing and audits will be continue to be part of the iterative development process.

As well as this we are in the process of creating an ‘accessibility working group’ within the public sector in Scotland – if you are interested in being involved then drop us a comment below or on Twitter.

Our end takeaway is pretty simple – it’s everyone’s job to make content and the overall experience accessible.

We’re on @mygovscot on Twitter for more updates. Want to comment? Let us know below!

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:

1. What do you need to understand?
2. Why?
3. 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.

We worked through this process with the Scottish Government Business Development Bank team to developed the SME discovery day. As a user researcher some key insights that emerged were:

• Design and undertake the engagement collaboratively – We worked together to shape the design of the day and the interactions between the SMEs, advisors, funders and Scottish Government.
• Workshop structure – A common failing is to speak at people for an hour and then wonder why they have no questions to ask. To flip that, we develop a structure where the attendees are talking and we are listening. This is about asking the organisers ‘what do you need to understand?’, and framing the day’s activities around that. Remember to include an icebreaker – helping people feel comfortable to share their experiences is a key stage.
• What questions to ask – Your research question is different to the questions you ask your attendees – think about the language you are using, is it accessible and consistent? Is it open and exploratory?
• Use facilitation as an opportunity to listen directly to end users – I arranged for 8 colleagues from the Digital Directorate to act as facilitators. Having a facilitator per table helped to keep the day on track. Individuals from the teams taking the work forward were able to learn from their experience as well as being able to listen directly to what attendees were saying.
• Check in, review plans and keep moving forward – I was the most visible facilitator, introducing activities from the stage and summing up after tables shared with the room, but it is a team effort that makes the day run smoothly; from individually welcoming people through the door (and handing out name tags), to the key speaker outlining the focus of the day, to the facilitator on the table developing each group’s dialogue. It is the spaces between these people, the flexibility and check-ins that ensure the day runs smoothly. We checked in as a group in the morning to review plans. At lunch, we had 15 minutes break, to refuel, then came back to the room to clear up and check in with the morning – what worked, what didn’t, how will we handle the afternoon. At the end of the day, we tidied up, packaged up the data, checked in with how we felt it had gone and left with the task up writing up our thoughts from the day when fresh.
• Let them explore, but keep them focussed – It can be tricky to balance this and it’s a skill that emerges with practice. On my table, I had an individual from an SME, an experienced investor, a business advisor and an individual from Scottish Enterprise. This discussion explored different takes on the ‘financial club’, official structures (Scottish Government) and how SME’ s engage with both. The table had to be confident to share their own views, listen to others, and as a table develop a story to share with the room in 90 minutes. I acted as a scribe, but they edited the post-its, developed the story and shared it with the room.
• Give them a reason to come back – We expected a sharp drop off at lunch time, so after we had shared the work about barriers with the room we told the attendees why we needed them to come back in the afternoon. This was an opportunity to design solutions to the issues they had identified and communicate the changes they want to see. There was a healthy return in the afternoon, I would estimate we only had a 10% drop off in terms of attendees returning.
• Tell them what you will do next – We told the attendees that we wanted to continue this work. We will review the findings from the workshop and share a report from the day. If attendees have any further thoughts we asked them to email us or connect on Twitter.

Other considerations for discovery workshops

Supporting the engagement

• What questions to ask and how – within the workshop activities focus on asking questions which are open and exploratory, and ensure you use consistent language between the timetable and any PowerPoint slides.
• Listening to the room – the lead facilitator’s role is to ensure a theme running through the day, starting with the introduction. They then gather feedback from facilitators and attendees and report back to the whole room a few times across the day, – covering key points that can be actioned immediately or in the longer term. These key points can then be echoed in the closing speech.
• Social media engagement – although social media coverage is natural at most events it is still a newcomer to Government culture. The team set up the hashtag #HowWeDoSME for the day and although not used by many attendees it will remain in place to continue the conversation – a move towards open dialogue online.
• Supporting facilitation – The facilitators came from a mix of roles within the Scottish Government – to support their facilitation development we held a 1-hour training session in advance which had guidance, a hand-out and provided an overview of the session. On the day, I frequently checked-in with the facilitators to answer any questions. By bringing in our own facilitators, they experience first-hand discussions as well as developing experience and skills in facilitation.
• Tech support – we brought along a laptop and projector

Feedback

It is vital to feed back to attendees and to continue the conversation – this includes:

• analysing the data from the day
• workshop report
• ongoing social media contact
• blogging or emailing about the next steps taken

With the right approach, discovery workshops offer a huge opportunity for collaboration. If you are looking for more guidance on running a discovery workshop please get in touch.

Follow the team via @mygovscot on Twitter for more updates. Want to comment? Let us know below!

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.

Tools

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.

In addition to the role, each server is assigned to an environment (i.e. dev, test or production), and from that it picks up the appropriate state and configuration. We use Puppet because Puppet is good for saying what state something should be – what packages should be installed and how they can be configured.

The code below gives you an example of setting up the role of a web server which will be spun up with an Nginx profile.

Example role manifest: web_svr.pp

#- file: modules/role/manifests/web.pp
#- Class: role::web_svr
#
# Class to define a web server role
#
class role::web_svr {

include profile::base
include profile::web

}

Example profile manifest: web.pp

#- file: modules/profile/manifests/web.pp
#- Class: profile::web
#
# Class to incorporate all web components
#
class profile::web {

class { 'nginx': }

}

Example profile manifest: base.pp

#- file: modules/profile/manifests/base.pp
#- Class: profile::base
#
# Class to install the base requirements for any host
#
class profile::base {

package { "ntp":
ensure => installed
}

service { "ntp":
ensure => running,
require => Package['ntp']
}

}

We do things in the cloud but we’ve created some example code which will run on your own computer. At the end of this article we have included instructions and a link so that you can run this Puppet example on VirtualBox.

Configuration

A lot of our application configuration is externalised to the Hiera config repository as YAML files which contain the configuration. We have our Puppet modules which define technologies and Hiera config files which can contain things like port numbers, root directory, host name, etc. It’s a good idea to separate the Puppet modules from the Hiera config as this means that a module can be taken off the shelf and configured separately.

For example our environment/role configuration is arranged as follows in Hiera:

./dev/app_svr.yaml

./dev/web_svr.yaml

./tst/app_svr.yaml

./tst/web_svr.yaml

So, if a host is defined as a ‘dev’ ’web_svr’ (i.e. a development environment web server) then it inherits the values defined in the ./dev/web_svr.yaml file – in the provided files this means that the image displayed is a unicorn. If a host is defined as a ‘tst’ ’web_svr’ (i.e. a test environment web server) then it inherits the values defined in the ./tst/web_svr.yaml file – which means it uses the panda.png image.

The process we follow to apply our Puppet manifests/configuration is as follows:

• Puppet code checked in to Stash
• Packaged as a versioned Debian ‘deb’
• Pushed to Nexus and an apt repository
• Trigger Puppet run via Bamboo
• Package containing Puppet Module is pulled to individual boxes
• Installed
• Puppet Apply is run applying the new code/configuration

Why masterless?

• We don’t have to worry about certificates or scaling
• We can trigger a Puppet run across an entire environment
• We can version the Puppet manifests and promote them with the other code

We don’t have to worry about how to scale Puppet because it is self-contained and runs locally on the target box i.e. there is no Puppet master. We treat Puppet manifests as artifacts themselves so they can be tested and promoted through the pipeline accordingly. This agility comes into it’s own when news of a security vulnerability (such as Shellshock or Heartbleed) is announced online – we have the ability to make security updates quickly and with relative ease.

Many people use Puppet masters and both setups have their advantages, as do alternate setups using Chef or Ansible. We chose to go masterless as it was the best fit for us; we can version control Puppet, treat it like an artefact and orchestrate Puppet how we want. We are also not subject to scaling issues as there is no need for certificate agent. Any problem we can roll back or rebuild as appropriate.

Demo code

You can download and play around with our example following these steps:

• Download/clone our demo code from Github
• Install VirtualBox
• Install Vagrant
• Go to the ./puppettest directory & run the following:

  vagrant up --provider="virtualbox"

• This should provision 2 virtual machines on your local machine – 1 web server and 1 app server – provisioned as ‘dev’ environments.
• To change this to the ‘tst’ environment, simply modify the symbolic link ‘servers.yaml’ to link to ‘servers.yaml.tst’ by running:

  rm –f servers.yaml

  ln -s servers.yaml.tst servers.yaml

Once the VM’s are up and running, open any browser and navigate to https://localhost:8080 for the web server and https://localhost:9090 for the app server (the servers.yaml file has details of what ports are forwarded).

Useful links

Roles and profiles:

• https://rnelson0.com/2014/07/14/intro-to-roles-and-profiles-with-puppet-and-hiera/
• https://garylarizza.com/blog/2014/02/17/puppet-workflow-part-2/

Masterless Puppet:

• https://pierrerambaud.com/blog/devops/using-hiera-with-puppet
• https://www.digitalocean.com/community/tutorials/how-to-set-up-a-masterless-puppet-environment-on-ubuntu-14-04
• https://puppetlabs.com/presentations/de-centralise-and-conquer-masterless-puppet-dynamic-environment

We’ll be sharing updates on this topic, and much more on social, so follow the team via @mygovscot on Twitter for more updates. Got a question or want to comment? Get in touch below!

We’ve been thinking about how we can provide insight into the Scottish public sector web portfolio. The Scottish Government has a large web portfolio, with many organisations providing multiple websites – all with unique propositions. It’s important that we, as Scottish Government, increase our understanding of this landscape.

An exercise has already begun to understand aggregated statistics from this web portfolio. Our initial view focusses on a series of core websites – ones which act as hubs for information provided by organisations. This creates an initial list of websites that can be built upon in the future.

• Did you know we provide over 6 million content items to users that are available to find in search engines (e.g. Google)?
• Did you also know that over 31 million links point to these content items?

Launching the web analytics initiative

A few weeks ago our team began working on a new web analytics initiative to help us surface and gain access to web analytics data.

The initiative will help to provide:

• a collated view of the web portfolio;
• an opportunity to visualise the relationship between websites;
• an ability to understand demand from users;
• insight into the services we all provide.

We can also use the data to help educate our direction of travel for building www.mygov.scot.

The team
There is a small, part-time team working on the web analytics initiative. Communications and daily management are being handled by Rui Cardoso – so Rui will likely be an on-going point of contact for queries via performance@gov.scot.

Getting involved
The initiative has begun with requests being issued to an initial list of organisations from Scottish Government, alongside a number of other Scottish public sector organisations. We will grow this list over the coming months.

The activity to grant access to Google Analytics will likely need undertaken by an analytics manager, web manager or marketing team (depending on where Google Analytics control sits within the organisation).

Access will not be shared out-with Digital Public Services & Business Transformation in the Scottish Government. All access will be read-only as well, so there is no risk to the data itself. We would also like to identify a point of contact for web analytics and performance analysis within organisations – as we have ambitions for a future community to improve efforts across the public sector in this area.

If you would like to get involved and help us build a view of the portfolio of websites – get in touch with us via performance@gov.scot and we’ll let you know what you need to do next.

We’ll be sharing updates on this, and much more on social, so follow the team via @mygovscot on Twitter for more updates. Want to comment? Get in touch below!

What do Small and Medium Enterprises (SMEs), business advisors and funders think about the challenges faced by SMEs when they seek advice and funding to grow their business? That is the question that the Business Development Bank team, the user research and engagement team, and the mygov.scot team collaborated on to understand.

Together we designed and organised an SME Discovery day workshop to explore who SMEs are, the challenges they face and the changes we can make. Each team had a different role and agenda, but the core focus of the day was the user; the approach was with, not for.

Room capture from the afternoon session

The October workshop had 56 attendees, split over 8 tables. Each table grouped 7 attendees with 1 facilitator, whose role was to support the discussions and act as a scribe. The morning was devoted to understanding the background of each attendee and the challenges they faced. The afternoon was all about identifying changes and solutions that would help better meet their needs. The workshop day was just the first step – we plan to continue the conversation with the attendees by developing and sharing a workshop report. The next step after that will be to tackle some of the biggest challenges.

Thoughts on the day:

“I learnt more (about looking for finance) in the first hour than the last three weeks” – Discovery Day participant Rachel Gwyon, Head of Business Development Bank Division at The Scottish Government

“I found the day highly useful in that it reconfirmed my belief that there are a wealth of funding options available today for companies in Scotland. The challenge is in accessing this funding… but through information sharing, mentoring and access to networks a solution is at hand. I would be very supportive of future such events which bring together all stake holders in an open, collaborative environment. Thank you.” – Russell Dalgleish, Managing Partner, Exolta Capital Partners – Delegate

“During lunch I fell into a conversation with an attendee who told me that he had been attending events like this for over thirty years. “This one has a lot more dynamism… but what do you plan to do next? Usually nothing happens after.” The hard part, a surprise to many, is not undertaking research with your end-user, it’s continuing the dialogue about what you are or are not doing next, and how they can continue to engage with you. Feedback fatigue is rife – so how do we handle that?” – Kate Saunderson, Workshop facilitator and user researcher

“It was great to see so many attendees at the SME discovery session. The attendees at my table all had the same view – events like this are held but it’s the next steps that matter the most. One attendee voiced his frustrations with the gap in the availability of funding between seed and A-round funding and is keen to be kept up to date with future developments.” – Angela Macfie, Workshop facilitator and Transformation Manager

“The Discovery Day gave us a great insight into the issues faced by SMEs; we’ll use that and involve them further as work progresses.” – Russell Bain, Business Development Bank team

“I facilitated the group of funders, so it was interesting to hear their frustrations. I came away with three strong messages from their perspective:

1. They all wanted to see businesses earlier in the process, and not at the point of critical need. They felt they could help to avert possible catastrophes by working over a longer period of consultation.
2. There’s a consensus among fund providers that a wealth of funding opportunities are being missed by businesses with growth potential. Businesses are being put off by lengthy application processes and less transparent eligibility criteria.
3. Directors are almost always wildly optimistic about the length of time it takes and the value of the return on investment.”

– Cath Hoult, Workshop Facilitator and Content Designer for mygov.scot.

Key finding #1: Terminology

The term innovation is an economically and politically topical term for business right now. Through discussions on the day it was noted that the term is being interpreted differently by different groups and organisations. One SME owner said he didn’t think he could apply for innovation funding as he didn’t see his business as innovative. His own interpretation of where his business fitted into the funding framework prevented him accessing funding opportunities. To give some background, the business in question is a recycling business (mainly focussing on hardware) which is a fashionable field for business investors right now – due to this there is a more proactive approach from funders.

Hanging a tranche of funding listed under an ambiguous term is potentially causing problems for accessing funding. We have encountered similar challenges to labelling in our engagement with other sectors. For example, if someone is defined by the system as a young carer but doesn’t identify themselves as a ‘carer’ we reduce access to that information. Another term SMEs had an issue with was the term creative – Government agencies saw a particular SME as a creative firm, but the company did not have the same view. Adopting a different label can affect how you pitch to investors and how investors see you. Asking ‘who are we as a business?’ could have wider implications in the context of the business plan. For the mygov.scot site we are having a discussion around how we can make funding more transparent by defining industry terms (such as innovation or creative).

Key finding #2: Categorisation

During discussions it became clear that across business organisations the classification of businesses is different. Sometimes the sector that a business thinks they are in does not conform with what business organisations and banks think that business should be in. New businesses often begin their business registration journey on GOV.UK’s ‘registering a company’ page (which gets over 1.98K page views a day). The business sector categorisation terminology used on the GOV.UK page is highly likely to influence the business’s own sector definition and so it makes sense for banks and business organisations to follow this same Companies House classification.

Key finding #3: Funding tool

At a couple of tables nobody had heard of the business funding search tool either on mygov.scot or, more worryingly, it’s predecessor on the Business Portal (business.scotland.gov.uk, which recently moved to be a part of mygov.scot). This raises alarm bells that our own government internal processes are failing to alert users to tools that may help them, and reminds us all in the mygov team that we still have a lot to do to get the word out about some of the great content on our site. From a user’s point of view, having a single point of information goes a long way to improving informed decision making. The more people who use the funding tool, the more traction we’ll have to drive evidence-based design. One participant had never heard of the funding tool yet when the feed updates with their “competition” it will display details of their fund – to not know is to miss out. It’s a fundamental flaw if such a powerful tool to aid advisors, let alone businesses, is not being used. And if there are problems we want to hear about them – the more users who interact with (and feed back about) the funding tool, the more data and feedback is analysed, and we can make tactical designs based on something better than opinion.

We talk about user journeys a lot in the mygov.scot team and in some ways this workshop was just one step in our own journey – work that began way back when when we started taking on the responsibility of the Business Portal site continues as we interact more with business users. Over the next few months our work on our business content will continue and we’re glad to have made a bunch more SME connections – our goal is to make business content (especially funding) simple to find and easy to use… and we’re glad to be well on that journey.

Follow the team via @mygovscot on Twitter for more updates. Want to comment? Let us know below!