 session. And we have Marjorie Tong-Wai with Consolidation, a GovCMS SASS story. Basically, she works for the Australian government and she does Drupal. So thank you everyone for turning up today. It's awesome to get some people to come to see what we're going to talk about. So we'll be talking about how we consolidated 14 websites into one over a period of two years. I mean, it was on time on budget using GovCMS SASS. The talk will be covering why we did the project, my method of actually migrating an additional site and then a range of technical and non-technical achievements that we did as a team. So a little bit about me. I'm a web dev from Canberra. I've been sort of involved in technology for like the last 20 years. But then found my thing with Drupal about seven years ago. I enjoyed long walks. I enjoyed beer. I enjoyed cricket. And yeah, I enjoyed Drupal. I absolutely love my job. So we did this project in response to the government's digital transformation agenda to reduce and improve departments web presence in a way that complies the whole of government requirements set out in the digital service standard. The discovery phase identified that there were 40 websites in our portfolio using various content management systems. Information was fragmented across a number of websites and the content was often outdated, inaccurate or contradictory. It was difficult for users to find the right products and services. Some sites had content being updated centrally by the department's web publishing team, while other sites were being updated by someone who had drawn the short straw in their program area. The department chose to use GovCMS SASS for the website consolidation project. Decision was reached after considering other options, including SharePoint online and GovCMS PAS. GovCMS SASS ticked all the boxes required. Of 40 websites identified in this 14 were marked to be consolidated into one. Eight of these sites were hosted internally using SharePoint and six of them were using Drupal that hosted externally. We also marked a 15th website to be migrated, which was also a Drupal site. As for me personally, I was well aware of GovCMS, but would never thought it was something I would have to use. My GovCMS journey started in July 2017 after I was asked to work on a long-term project to consolidate a number of sites into Drupal, starting in a few weeks time. At this point, I'd been using Drupal 7 without any restrictions for about five years, and I had four SSH access to my site, so I could, and we used A-gear as year to host our site, so that's the sort of setup I was used to. I'd also started actually planning out migrating these sites to Drupal 8. I was aware of the consolidation project, but from where I was sitting, it's sort of just appeared to be on hold, so it might as well skill up and go into Drupal 8. At the time, GovCMS was actually only available in Drupal 7, so it felt like it was a step backwards for me, not learning Drupal 8. I began by investigating the SAS distribution, and I was just sort of had my head in my hands going, how am I going to build anything with these modules, and how am I going to do anything without being able to easily extend it. I was also the only full-time Drupal developer at the department at the time. I had a previous colleague that I'd been working with for four and a half years, but he'd recently had a promotion, so I was sort of all alone doing my little Drupal thing, so in preparation for this, I actually found a couple of people to train up, just to do security updates, but I looked after these websites for another 20 months after I trained them. Our minister's site was a direct migration from playing Drupal 7 to GovCMS, Drupal 7, and was not part of the larger project, so I had a chance to sort of chip away at this myself, so I could see how it would work for the larger project. So the way I started this was by creating a list of the current modules and then the modules available in the SAS distribution, and I sort of categorized them into either available, equivalent, available, not required, testing, need to find a solution, and then request to GovCMS to actually have something added. There's only one module that I requested for GovCMS to add, which was the taxonomy managing module, and this was the lucky last module ever added to the GovCMS Drupal 7 distribution. So in October 2017, I installed the GovCMS distro onto our external server, which were all our other Drupal sites were, and imported, so the content types, taxonomy terms, and also the users. I then went out to test the best way to actually import the content using the feeds module. Luckily, there was no files to import, and there's only a handful of images, so it made my job a lot easier. So I used the views data export module to export things into CSV files, and there's a mix of plain text and HTML fields that I used for that. So I'll export all the loads in plain text, and then I'll also export them in HTML as well and sort of copy and paste this into a spreadsheet, which I fed in. So this is just an example of one of the CSV files. It's pretty simple. There's nothing too crazy going on there. So yeah, in this one, so minister, subject, interview, and the tag column are just in plain text, and then the body and the summary are in HTML. So after a couple of test runs, I'd feed everything in and actually went really smoothly. It probably took me a day to import all the content. But given that there's multiple ways to do things in Drupal, I realised later that using the feeds tamper part of feeds would have actually, I wouldn't have had to export things into HTML. I could have fed things in and told it to import differently. But there's only about 1200 nodes, so it wasn't much of a time saver in the end. So the site was essentially ready to go live in December 2017 as there was very little theme changes required. I just lifted the theme into the new environment. It wasn't an issue at all. But we still needed the taxonomy manager module to actually be included in the distribution. So after waiting a few months more, it was eventually included in March 2018. But unfortunately, the project team decided this would be put on hold until the larger project had progressed a lot further. And the site eventually went live in August 2018, which is a relief because I'd been dual publishing for about 10 months by that stage, so I was very happy to see that one go. So as for the larger project, the consolidation project team for Alpha, Beta and Live was formed in August 2017. And over the coming months, we hired another web developer, a user researcher, a tester, a business analyst and a number of content designers. The team was complete by March 2018. However, we did not have a UX designer, service designer or a change manager. A lesson that I'm resourcing was that having these three extra roles would have allowed us to build a more sophisticated user interface identifying issues earlier and allowing team members to concentrate on their own roles instead of filling the gaps or doing sort of other jobs. We followed a job methodology and we worked in two weeks sprint. And we used Visual Studio to create our backlog of work. But in saying that there was a lot of updates to Visual Studio, and it would just start showing us other people's work or other things. We're like, what is this? This is not our work. This is not fun. So the final months of the project, we actually went to like a physical can ban wall with lots and lots of post-its. As you can see, there's a lot in the done pile there. But that was our life for the last few months. But in saying that, it gave the team our stakeholders and executives a clearer picture of all the tasks we were actually doing. Whereas in Visual Studio, it was because it's all online, no one could see it. So it was a bit like, you know, what are you doing in this way? It was just easy to people could walk past and go, oh, wow, look at this, look at that. So that was a real positive. So during the time I was marketing the minister's site, we had all worked together to decide what a minimum viable product would look like for our alpha site. So we had to consider what content would we add, what colours would be used from our palette and do we want to use icons or images or all that sort of stuff. As we didn't have a UX designer on board, we all looked at that basically everyone in the team just went to different government websites and sort of, you know, like, we like this, we don't like this, let's try and do this. You sort of picked and chose what we thought would work for us. Once the design was agreed upon and a basic content loaded, user testing started in February 2018. Feedback on this design included, if I came here as a business and I saw community in government, I wouldn't think there was anything for me. And also, where is business and industry? I would expect to see these as they're in the department name. I can see government and community. To address this particular trend of feedback, we changed the design to six equally sized boxes or with images and changed the language so that the focus was not on the user types, like community and government, but instead pointed to services and content under the headings, community activities and government to government. The headings will continue to be reviewed as we add more content and test with users. So as an example, community activities has now been renamed to client services to better suit the incoming content. The beta site was launched and we continued to collect feedback and this time it was much more positive. An example was, I like the beta, it looks clean and the labels and categories are intuitive and another one was very good use of styles. As someone who has made a website, this is decent for a government website and it's definitely better than the old one. So based on further user testing and feedback, we worked hard to improve the site before going live six weeks later on the 7th of July 2018. We also scored ourselves a third full-time Drupal developer for the second half of the project, which is a relief. So developing an agile environment has its challenges, especially for a new site that goes through a lot of user testing. So if there was strong feedback about a label, it just simply got changed, which is awesome for the users. They get what they want, but the poor developers are stuck with some interesting things to work with. So this type of chopping and changing overflowed into the content types too, with labels being updated to better describe what the field actually does. This example shows what happens when a label is updated for the benefit of the publishing team. The label on the left doesn't look or even sound like the machine name on the right. Plus typos often occur because we felt like we were rushing to get it worked on. And while overall it doesn't affect anyone except the developers, it actually slows development down because you're looking for the wrong machine names to update stuff. So Si Hobbs is actually doing a talk on content modelling with Drupal in this room, the next session in this room, and it has tips for naming fields like the machine names and also how content modelling interacts with the layout and styling. So I recommend going to that one session. So another huge part of the project was user research. We had a dedicated user researcher on board to make the DTA standard requirements and to ensure that the site would benefit our users. Every project team member contributed to at least one user research session. Many of the sessions were held face-to-face across six cities including Canberra, Sydney, Melbourne, Cairns, Darwin and Adelaide with remote testing happening all over the country using Optimal Workshop. Face-to-face sessions consisted of one person from the project asking the user to do a particular task whilst the other records what sets were taken to reach or not reach the desired goal. We had over 450 external users and 130 departmental staff to assist us with user testing and we also received over 1700 feedback emails via the website form, feedback form, that we were triaged and taken into consideration. We initially had a 61% rate of users finding content on the old industry.gov.au website, 85% during beta and 93% once live. Content development work took up the most effort and resources in the whole project as pieces of every single piece of content was rewritten. Only critical content was to be created on the new website. Our core content principles are making sure that it meets our legislative disclosure and reporting requirements. It explains the department's purpose, responsibilities and strategic intent within the portfolio and that is user focused and explains what the user can do, needs to do or needs to know. The content designers engage with subject matter experts to discuss their content before the rewriting starts. We refer to this as pair writing. So pair writing is just the content designer sitting at a desk with the subject matter expert editing a document together. It's just as simple as that. The SME would make sure that the content is factually correct and the content designer ensures that it's written to our standards and user needs. After pair writing, only a small amount of time was spent entering the content into the site once it was approved. A lesson learned when developing content is that pair writing process was an effective way of collaborating. We appreciate that they're the experts in the topic but our content designers are the experts in writing for users. Another lesson learned is that using diagrams and images like this iceberg was a better way to communicate complex tasks. Our stakeholders responded better to simple diagrams on white boards rather than text and emails or face-to-face meetings without the aid of images. So the developer experience in SAS. So building the site in Acrea Cloud and then using site factually wasn't the most fun I had had. Not having access to the file system and not being able to install modules was really frustrating. When I'd done the minister's site, I still had the freedom I needed to import users or content. It was just so much more simple. I guess one of the less than ideal things that happened was our department of often changed its ministers and once again we had to update their minister's site and did a blue-green switch. So you take the original site down and you put the new one up with the new ministers and so on. It was definitely one of the less than ideal situations I've been in because it took more than half an hour for the new site page to show up and once it did show up it kept flipping between the two because it was a caching issue and previously on the platform I had full access to it was I could just clear a cache. I could go in, do my typy typy, clear advantage cache and the site would be up there and it was awesome. This time it was really frustrating. I found out later that we should have actually informed the GovCMS team that we were doing this but to me it didn't actually occurred to me that I have to involve more people to do something I'd always done by myself. So as I previously mentioned it makes the restrictions make developing much slower. A theme change meant waning an unknown amount of time before it was visible to the team and as I said previously I had clear a cache via command line for immediate results. We worked off 4G Wi-Fi from our own laptops as access to tools and online repositories wasn't possible via the work computers or a protected network. This wasn't that new issue for me as all my previous Drupal work had been off my personal laptop and a 4G connection but internally we kept hitting brick walls when trying to find a better solution. I'm grateful that the department's network team understood our needs and unblocked some ports on the office Wi-Fi so there's less reliance on 4G. The developers didn't have a standard local development platform. I used a LAMP stack on Linux, another used a LAMP stack on Linux via the virtual machine off Windows and the third was using a Queer Dev desktop on a Mac. A change in hosting providers for GovCMS in November 2018 required us to relearn deployment processes. However, with the switch to Solstromazy we also started using Docker for local development which gave us a much more even platform to work on. As well development not going to plan it turns out celebrating doesn't always work out the way you expect either. This pitch was taken just over a year ago at our product manager's house so we'd recently consolidated four more sites and it was time to celebrate. We enjoyed destroying a Lego head pinata and completed a quick sprint review and retro while eating. Other people had enjoyed the trampoline before me but as luck would have it I jumped on the sweet spot and it fell through. Lying on the ground I wondered where I'd gone wrong before finding the silver lying, not a drop of my drink had been spilled. We investigated this issue as a team before trying to hide the evidence and moved on to something less harmful like playing with nerf guns. Post-trampoline issues and Christmas the team started working with the National Measurement Institute and the Anti-Dumping Commission at the start of this year. These are our two biggest clients I guess I would say they took up a lot of time to do. So for the first time the devs actually got to work with the subject meta experts to find out the pain points of because they were both using a share point so we went to find out what they disliked and what they want in their new world. We could definitely see better ways for their content to be input into Drupal and certainly improve the way it looks in functions to the end user. But we had to consider what was the best and fastest way to import all their content considering that NMI had over 3,000 files and ADC had over 8,000 files. After stuffing around by ourselves, it turns out that doing ourselves wasn't an option so we collaborated with our SharePoint developers and they were able to extract the files and the corresponding HTML vibes and PowerShell scripting and they supplied all the data neatly in a CSV for us to manipulate and then use the feeds module to smoosh it back into the site. This is an example, one of the more simple exports from the Anti-Dumping Commission website after it had been prepared for import. The data is being imported into a content type called ADC cases. These columns were mapped to the corresponding fields in the feeds importer setup and then I would run a small batch through and perhaps save five rows and then I would make sure it mapped correctly before importing large chunks of data. After importing, I would spot check newly created nodes and make sure that it worked properly before passing the task onto our test to check. In future, I would probably use the taxonomy ID rather than the taxonomy name in the CSV file as it would cause less issues for taxonomy terms within a hierarchy or have spaces in the names. In this example, status, commodity, case type, countries and next milestone columns are all taxonomy terms. We also had the opportunity to improve the way data was displayed. On the previous site on the left up here was a table that the Anti-Dumping Commission publishers had to manually edit each time a new row was added or removed. They now publish a node per row and it automatically appears in the correct position in the table which is created in views. Because many of these fields are taxonomy terms, we were able to turn them into filters which turned out to be a huge deal for them. I've never seen anyone so excited about filters. It was amazing. It was a great afternoon. I blew their minds. It was great. And we also have evidence that the filtering and sortable table columns are being used for the cases content type in the table view. This heat map is generated from hotjar and it indicates that the filters are being used to some extent and one column in particular, the last updated date column is being used for sorting frequently. Lastly, we can see that the users are selecting the hyperlink through to the full record. This picture is an example of a case page that the end user would see after selecting the link from the table beforehand. The case page is actually made up of the fields we imported at the top as well as data from a different content type displayed in the table below. Although these records at the bottom don't contain any HTML, they were imported with a mix of taxonomy terms, date fields and plain text including a crucial entity reference field which allows these records to be associated with the correct case page via the content title field. In this example, the entity reference field would have been 518. Process wise, it was easy to import what is mostly simple fields into the second content type. For context, there were around 300 cases and over 8,000 records associated with them. At this stage, the highest number of public records attached to a single case is 416. This one only has seven which is a nice little one. Each public record would also have a file attached to it and some had multiple files. Files were definitely the tricky part of importing this data into the website. The files had to be pre uploaded to the site in batches and it's path referenced in the CSV file so it could be attached to the node. Because we couldn't access the file system and although we had our upload limit increased, it would simply take too long to load everything at once. If a record had multiple files, the path name and the display name would all need to be put into the same file path and name would have to be put into the same cell separated by a comma and the same for the corresponding file description cell. As you can imagine, there's plenty of opportunities to get this wrong. I used a mix of Excel on Windows and the Linux equivalent spreadsheet as well as using a plain text editor to look at all the data but a spreadsheet was definitely the way to go just looking at so much stuff. Taking a step back to even finding the files I needed, the first issue I had finding them was when the SharePoint developers grabbed all the files, they only put them into one great big folder of 8,000 or so files. But as frustrating as that was, it was probably going to be faster than me trying to do a site scrape or something even worse which is going into SharePoint itself. My main issues were a lot of the files had very similar names. A lot of files had extra full stops in their name. This was an issue when uploaded in a bulk zip file as the site didn't recognise the file and would just simply skip it. So you think, yeah, awesome, I've just imported 30 files and there's two, like wherever I've gone wrong, it's just the full stops. So I tried a different approach. It was just putting the files in date order, the date that they were pulled from the site and that was a bit more accurate but still it skips like 1, 4, 5, 2 and 3. But luckily this was probably that a lot of them were actually in the correct order and it was, once that one clicked, my job got a lot faster. I could not tell you how many CSV files and corresponding zip files are loaded into the website. All I know is that I worked around 80 hours, one week to get it over the line. So after two and a half weeks of importing data day and night, our test has spent one and a half weeks painstakingly cross-checking the pages to make sure everything had come across. Mistakes were fixed and all around everyone was happy with how it panned out. However, it wasn't until a week later that I'd realised that the public records that I had multiple files had an issue with the file size displaying. Initially I thought they were quite clever, like how did you get all the file sizes the right size, same size as each other. But I figured it was too good to be true. No one had picked up on this though, not even our tester, no one in the team, not even the subject matter expert at this stage. And after some testing I realised it was just taking on the first, whichever file was listed first, the row of them would take on that size. Anyway, I can't tell my subject matter expert who confirmed she hadn't seen it and then she promised not to tell us all. I went back into the view and tried to figure out how to fix this. It turns out the view needed to be modified slightly to use a rendered file where previously I'd used the generic file with some rewriting. I then modified the file entity download link code and placed it into the template.php file. And just like that, the file sizes were correct. But overall it was an absolute pleasure working with these people as they were so keen to improve their website and the way that the data was displayed and we were able to help them do this. We received positive feedback from these internal staff about how easy it is to publish their content since they started using Drupal and there is now a reduced load on their client services team as the users are now able to find what they want without requiring assistance. By the completion of the consolidation project, we have reduced the number of content pages users can view from over 5,500 to under 1,000 or 80% less pages. And just to note on that that it doesn't take into the account all the content I just mentioned so potentially there could be 20 nodes to make up a single page so it's not less nodes but there's less content pages for people to sift through. As seen on this image, the number of pages originally vary greatly from site to site. The smallest had two pages and the largest had over 3,000. The site was developed following the digital transformation service design and delivery process and has been assessed by the DTA to meet the standard. The site also meets Australian government web best practice and accessibility requirements. And because we like a challenge, we migrated two other sites into GovCMS during the project timeframe. The minister's site was, as previously mentioned, was migrated in-house as planned and the Anzlik site was migrated by a third party in April 2019 after we had major and ongoing issues with our external hosting provider. Thank you to OPCIT and the GovCMS teams for working with us to quickly migrate the site in under a month. So with Anzlik, this also brought our first Drupal 8 site into the department. It also marked with the issues we had. This also marked the end of my ongoing support of the old Drupal sites, although it ended much more abruptly than I anticipated. The project team had a role in building digital capability across the department. Communication was done via closed invite board meetings, open invitation showcases, master classes, workshops, presentations, as well as creating standard operating procedures and providing content management system training for our departmental publishing team and select others who have a specific publishing role. The project team engaged with over 200 staff in 37 workshops to identify critical content and did 12 showcases and hosted a number of meetings to share our GovCMS SaaS experience with other departments. We were also invited to present at our department's agile guild to our colleagues at business.gov.au and at the Digital Transformation Agency. Now that we're post-consolidation project, we need to ensure return on investment. We require a retention of capability via resourcing applications and organisational change. We need appropriately skilled people to support a modern digital channel including content designers, service designers, user experience designers and Drupal developers. We need ongoing licensing in training and analysis in testing and website management tools such as Google Analytics, Optimal Workshop and Funnelback Dashboard. User research activities need to continue. We need to test both remotely and in person to ensure content is performing as expected and that the website evolves with changing business priorities and user needs. And then we need to upgrade to Drupal 8 and then to 9 which we're getting there. We also need to improve the safety of my gear. I turned up to work on Monday recently and I was missing my external monitor cable for my laptop. I was led to believe it was in one of these boxes so I laughed a bit and then someone came, someone went out and nicely bought me a brand new cable so that was good. But these are the sort of things that slow you down. Yeah, it goes missing. Being part of the project has been an amazing experience for me. Two years is a long time and your team feel like family. Initially I was skeptical about being part of a multidisciplinary team and having to use a product I wasn't sure about. I'm thankful that the Gov CMS community, much like the Drupal community, is open and willing to help others. I appreciated that our team have supported each other and taught each other new skills. I was able to teach our lead content designer to use views and panels before they decided it wasn't for them and I got nice compliments like you write well for a dev. We had created a high-performing team who continually delivered results so we tried to make sure we had some downtime together. We celebrated birthdays with a morning tea or lunch and project milestones with after-work drinks. Lessons learned for a high-performing team is that everyone really needs to be on the same page and wanting to reach the same goal. We were still able to make progress even when key team members were absent. Because of this shared goal and dedication, we were able to deliver this project on time, on budget, using Gov CMS Sus. That is the end of my slides. Thank you very much for listening. Are we doing questions or not? No? Does anyone have any questions? Is it working yet? Firstly, well done. That's a huge project. Thank you. It's all me. If you could do it again, what's one part of the project that you do differently? We'd have all the right people to start with. I found it because we had a very staggered approach to pulling all resources in. You sort of felt like each time a new person or two new people would start on the same day. You'd feel like you're starting at the beginning again, sort of explaining, this is the project, this is how we're doing it. If everyone was brought in together at the start at the same time, I think we would have flowed a lot better. And the LS explaining over and over and trying to convince people that what we're doing is a good thing. Thanks. Anyone else? I'd like to just point out that all your photos had women in them. Can you talk a bit about the structure of your team? Well, it was mostly girls. At the start, yes. The original five of us, which is the first five of us, they were together in August, September. And I'm not sure how it happened. This is the right people, yes. It wasn't done on purpose, it's just who we interviewed, they had to do the right people. The two other devs were guys, so I was the only girl. Thanks again for the last second question. I was just trying to figure it out. Oh, thank you very much, everyone. Thank you. I was just going to look up what the deal is with the next.