Conflux is a new Linux icon set that aims to be both beautiful but neutral – I think it succeeds at both. The author of Conflux said they struggled to find a “modern-looking” icon pack for their desktop, deigning many as overly stylistic, outdated or, in some cases, poorly designed. Another impetus to solve was the way un-themed icons look. “Conflux should blend seamlessly into your system”, reads the Github page, “so that you don’t even notice you’re using an icon theme.” It’s not flat, block colours and simplistic – which is refreshing. It won’t be for everyone, though. Few […]
You're reading Conflux icon set gives a modern look to Linux desktops, a blog post from OMG! Ubuntu. Do not reproduce elsewhere without permission.
Conflux is a new Linux icon set that aims to be both beautiful but neutral – I think it succeeds at both. The author of Conflux said they struggled to find a “modern-looking” icon pack for their desktop, deigning many as overly stylistic, outdated or, in some cases, poorly designed. Another impetus to solve was the way un-themed icons look. “Conflux should blend seamlessly into your system”, reads the Github page, “so that you don’t even notice you’re using an icon theme.” It’s not flat, block colours and simplistic – which is refreshing. It won’t be for everyone, though. Few […]
You're reading Conflux icon set gives a modern look to Linux desktops, a blog post from OMG! Ubuntu. Do not reproduce elsewhere without permission.
In this post, User Experience team intern Hannah Watson shares her work over the summer researching digital content accessibility with the EdWeb 2 publishing community.
As part of my internship with the User Experience Service, I have been investigating digital accessibility at the content level across University web pages, particularly on EdWeb 2 sites. Digital accessibility at the content level is about applying principles of accessibility to how web content is written and formatted. This includes, but is not limited to, content features such as heading levels, links, and alt text. It does not include anything that is not involved with content design or that is controlled at a higher level by the Content Management System (CMS), such as font, font size, or colour contrast.
The specific research questions for this project were:
More comprehensively, I was investigating the accessibility of:
For more detailed guidance on these topics, please refer to the University of Edinburgh editorial style guide.
Editorial style guide | Information Services
This research has been necessary for the User Experience team as it allows us to identify which areas of content accessibility are challenging for web publishers. From this, the team can adapt guidance and training to provide extra support on these more challenging areas where possible.
I started my research by setting up short, informal interviews with six University web publishers. In these interviews, I asked the publishers about their experiences of creating digitally accessible content. The aim of these conversations was to understand how publishers learned about digital accessibility and what challenges they face when making content as accessible as it can be. During the interviews, we referred to web pages that these publishers work on to get concrete examples that illustrate the topics we discussed. Through these interviews, I was able to identify a number of trends, particularly in the challenges that the interviewees and their colleagues face.
Following these interviews, I created a survey to further investigate the findings and collate more supporting evidence for these findings. The survey consisted of 10 questions, three of which were demographic based as a filter, with a final question asking permission to follow up with those who responded.
The other six questions asked about:
The findings from the survey were effective in making the information gathered in interviews more robust and provided further evidence for some trends that were identified previously.
To publicise this survey, I sent a brief statement explaining my research into two Teams channels, the Web Accessibility Special Interest Group and the EdWeb 2 Community. Overall, the survey received five responses, and while this is a limited number, I found that it helped to support the findings from the interviews.
The final method of research that I used to learn about the digital accessibility of content on University web pages was by looking at pages that were submitted within Effective Digital Content workbooks as part of the course. The course requires learners to choose pages from a University website and assess the effectiveness of the content. By looking at the pages that learners selected, I was able to use active examples and make note of content accessibility issues that were present on live pages. This process also highlighted a number of trends.
This method of research was also useful in that it provided two separate sources of data. Firstly, the answers in the workbook helped me to gauge learners’ understanding of the principles covered in the course. Secondly, the web pages linked by those taking the course allowed me to have live examples of content to assess against content accessibility principles. While there was not necessarily overlap between the answers in the workbook and the pages submitted as part of the workbook (as some people may not have been fully or at all responsible for the content on those pages, or the content could have been updated since the workbook was submitted), it was useful to see these things separately.
Combining findings from all areas of research for this project, I have identified a number of trends in the accessibility of digital content.
In the interviews and the survey, participants were asked what principles of accessible digital content they actively used when designing content. More than half of participants mentioned three principles in particular, with all participants mentioning at least two, which were:
Interestingly, while these principles were mentioned frequently by participants, and evidenced by the websites that we discussed in interviews, they are also principles that are often missed on University web pages. This is discussed in more detail in the corresponding sections further on in this post.
One standout finding from the interviews was that web publishers sometimes struggle to find an effective alternative to PDFs. While PDFs are not necessarily accessible, they do have benefits which make them useful for publishers. For example, they are downloadable, searchable, and cannot be easily edited without permission from the owner. There are ways to make PDFs more accessible, such as avoiding decorative images, adhering to accessible content design principles within the PDF, and checking colour contrast. However, the interviewees were more in favour of finding a way to turn their content into a webpage as this is more likely to result in accessible content.
Out of the survey responses, three also mentioned that they had recently chosen to publish content as a web page rather than as a PDF, highlighting their knowledge that a web page is preferable in terms of accessibility. However, their personal preferences or how difficult they found this is unknown as I was unable to follow up with these participants.
Across web pages that I assessed for correct heading levels, there were several which skipped heading levels throughout the page content, such as going straight to a heading 3 without that heading being nested within a heading 2 section. Additionally, headings on the University web pages that I investigated were often generic, instead of being specific about what a page or section will contain, which is the recommended approach.
The fact that the web publishers who were interviewed and surveyed were aware of the importance of correct headings levels and specific headings, and that the majority of these publishers have attended a staff training or used the editorial style guide, suggests that the guidance provided is accurate and useful for publishers.
To increase the use of correct heading levels, as well as clear and descriptive headings on web pages, participant responses suggest that increasing the reach and engagement of existing training and resources involving headings would be effective. This includes training provided by the User Experience Service, such as Effective Digital Content or Content Improvement Club, and the University of Edinburgh editorial style guide.
In three of the interviews, and in two survey responses, participants mentioned that they struggled to find the time to add alt text to images on their web pages. However, participants in the interviews also stated that they understood the importance of alt text, and what writing meaningful and clear alt text involves. This is reflected in the answers in Effective Digital Content workbooks. The course contains a question asking learners to write meaningful alt text for two images, and this question is often answered well. This suggests that web publishers understand how to write alt text, and that the obstacle in doing so is more likely to be related to time and resource.
One way that time constraints on adding alt text could be improved is to reduce the number of images on a web page, which will not only make this task more manageable but also is also more sustainable.
All five responses to the survey stated that they had explained an acronym or abbreviation recently. Although this did not come up in the interviews often – only once – the survey responses suggest that this is common practice for web publishers who are familiar with digital accessibility principles.
Participants stated that they understand the importance of clear link text as a principle and make effort to implement this into their content. However, similar to headings, this sentiment is not reflected across numerous University web pages. In some of the pages submitted as part of the Effective Digital Content workbooks that I investigated, there were frequent occurrences of inline link text, or link text that does not clearly describe the linked destination.
To increase the writing of link text on a separate line, as well as clear and descriptive link text, participant responses suggest that increasing the reach and engagement of existing training and resources involving links would be effective. This includes training provided by the User Experience Service, such as Effective Digital Content or Content Improvement Club, and the University of Edinburgh editorial style guide.
A trend from both the interviews and survey responses is that for many of the people involved with this research, their knowledge of digital accessibility started with a personal interest. Specific examples of this that participants mentioned include learning about accessibility as a student (and then going on to be an accessibility advocate for a student society) and working with disabled students and learning through experience.
During the interviews, multiple staff members mentioned that they believe, through their experiences, that a large part of issues with creating accessible digital content at the University surrounds communication. A combination of factors was discussed that had communication at the centre, including:
Job-based constraints were also mentioned frequently, such as limited time to add alt text to all images on a web page and working on a page where the lead publisher takes a design forward approach which can sometimes clash with accessible content principles. These answers were also reflected in the survey responses, with all of the responses mentioning either one or both of these problems.
The primary resource that participants mentioned using to learn about digital accessibility and develop their skills was University-provided staff training, with 10 of 11 participants mentioning this. Effective Digital Content was specifically mentioned twice, and Content Improvement Club three times. In the interviews, two participants mentioned more general staff training, with one survey response saying the same. In the survey responses, three participants also said that they used training provided by the Disability Information Team.
The Web Content Accessibility Guidelines 2.2 (WCAG) is another resource that was frequently mentioned by participants, with six in total saying that this is a resource that they use as guidance on accessibility.
The University of Edinburgh editorial style guide was mentioned by five participants as a resource that they used to provide guidance on digital accessibility, in which the guidance reflects what publishers learn in training courses, meaning that information they take from the style guide is in line with accessibility and content design training.
I learned a lot during my time researching how web publishers at the University of Edinburgh approach creating accessible digital content. I thoroughly enjoyed the opportunity to work with staff from a variety of different areas of the University. This helped me to learn how to identify commonalities in interview and survey responses despite the areas of work being distinct. I also enjoyed this because I was able to learn much more about the work that goes on across the University and what the work of other teams involved.
I also particularly enjoyed the format of my internship being a combination of individual work and working with other members of my team and the Disability Information team. This balance allowed me to set my own goals while still getting the opportunity to work and learn collaboratively as part of a team, prioritising my tasks between my own and those that I was working on with others.
A limitation of my work was that it was much easier to contact and work with staff who have a genuine interest in the subject area of accessibility, which does not lead to research that is representative of how University staff approach digital accessibility as a whole. Having done the research that I have so far, a continuation of the research would be most beneficial if it focused on the experiences and approaches of staff who are less familiar with digital accessibility requirements and principles, as this would create a more well-rounded understanding of web publisher accessibility approaches at the content level.
Furthermore, another limitation of the work was the time constraints which have restricted my ability to develop solutions to issues identified during the research period. This was expected to a degree, as the solutions depended on the outcomes of the research, which has taken the majority of the 12-week period. The positive outcome of this is that the research and findings will provide the User Experience service with information that allows for both further research and for adaptations to guidance and training if it is deemed necessary.
This research has helped the User Experience Service to assess their training and the resources that are available for publishers to learn more about digital content accessibility. Keeping in touch with the publishing community through projects like this helps the team to direct their effort to real challenges that publishers face on a day to day basis.
The research completed throughout the duration of this project will be supported and advanced by further investigation, particularly by communicating with web publishers who are less involved with digital accessibility as a whole. This will likely help in providing more concrete solutions to digital content accessibility issues across EdWeb 2 pages.
Content audits are a long-time staple of the user-centred website toolkit, but they take time and effort to complete, which many website owners struggle to find. In my ongoing AI experimentation, I tried using AI tools to help me with auditing web content.
Every day brings a raft of new AI developments. When choosing how to use AI, I’m less sold on getting it to do creative tasks for me because I like doing those myself. Instead, in pursuit of freeing up my time, I prefer to use AI to help me with the tedious tasks I never get around to, the ones I know will take me longer than I think, the ones I put off again and again. Here’s looking at you, content auditing.
When people come to the UX Service for help with their websites, they tend to use several phrases to describe their site. These have included: ‘It’s a mess!’ ‘It’s a bit out of control’. ‘It’s grown arms and legs’. None of this is unusual when you consider the lifecycle of websites. Over time, websites change hands. Pages once carefully crafted are easily forgotten as new editors take over. New content is created without knowing what’s already there. Very often, content needs to be published to a deadline and it’s quicker to publish a new page than seek out and amend an existing one. Seldomly do publishers want to get rid content that’s taken time and effort to produce.
Read some thoughts on content housekeeping by UX Service team members (current and past):
Digital housekeeping – applying content management practices to improve digital sustainability by me
Be a gardener by Ari Cass-Maran
Content Audit Findings and the 100k Challenge by Milo McLaughlin
How to get a grip of your website (and then keep hold) by Neil Allison
When people seek to bring order to disarray on a website it’s difficult know where to start, so typically, they start on the homepage with ideas to change images or add new content. While this gives sites a superficial makeover, it doesn’t really help site audiences in search of content. Fewer and fewer website audiences are starting out on homepages, instead they’re parachuting directly into site content from Google search and increasingly, from AI summaries. What does this mean? It’s more important than ever to make sure your web content is up-to-date, accurate, useful and relevant for your website users. Here’s looking at you, content auditing.
Read more about getting your content ready for AI from a recent Content Improvement Club session:
If audits are so important, why are they so easy to put off? Short answer, they can take prolonged amounts of time and concentrated effort. The larger and more complex your site is, it’s likely that there will be more content to review, and the more difficult it may be to maintain a consistent auditing approach. Going through multiple, long pages of web content, it can be easy to run out of the time you’ve allocated for your audit. Breaking the audit into chunks may lead to different results from different sessions as biases creep in. Bringing colleagues in to help can share the load, but can also introduce new perspectives and contradictory auditing decisions. There’s a need to maintain ruthless objectivity, to counter human subjectivity and avoid errors infiltrating. Here’s looking at you, AI.
Website content audits can be done for many purposes, but commonly, doing a content audit involves making decisions about what content to keep, what needs to go and what needs to be changed – all in pursuit of reaching a future state of your website. A good way to decide what content to keep is to consider who it’s for and the purposes it serves. If a piece of content doesn’t meet audience needs and doesn’t align with the site purpose, then it’s probably a candidate for deletion. A good content audit of a website therefore typically requires several things:
Considering each of these things as different pieces of data, where item 1 is data to be audited, items 2 and 3 are factors or auditing criteria used to decide what happens to those data (typically one of three outcomes: ‘Keep’, ‘Delete’ or ‘Modify’), I reasoned that I could give AI these data, tell it what a content audit was and and ask it to complete this process for a given website.
The University’s AI platform, ELM was the natural place to start experimenting with applying AI to aid content auditing. The ELM interface allows you to input a prompt, as well as add additional files and data sources. It also allows you to select different models to handle queries. I was curious to see the differences between the different models – both non-reasoning ones and reasoning ones so I needed to design a prompt that would work for both.
Read more about ELM and its models
ELM new model guides (University log in required)
AI comes with a significant environmental cost, which is highly dependent on the LLMs you use. Powerful models with more reasoning power are especially resource-intensive to run, so to avoid unnecessary wastage of tokens and other resources I’ve found it’s sometimes best to start with a smaller model and size up accordingly, as the need arises. The trade-off is that smaller models have limited reasoning power, however, so the responses they provide and the tasks they are able to complete can be limited.
Based on my previous experience of using AI and thinking about its potential application to a typical content auditing process, I had a hunch that providing a small model with something like a site inventory (such as a XML sitemap) and detailed data about website audiences and purposes could overload its context window and produce inferior results.
I therefore decided to begin with a lightweight prompt ‘Can you help me do a content audit of this website? (with a link to the website)’ to give a small model something manageable and learn how it approached handling the query. I chose a website that the UX team had recently worked on, so I was familiar with its content, and I entered the prompt, starting with the Llama 3.3 model – an open weights model (costed on computing power rather than per-token usage) which is hosted in University data centres (instead of being cloud-based). I toggled on the option to include web search so ELM was able to access the website.
Having starting with Llama 3.3, I moved on to other models: Open AI’s GPT 5 and then Anthropic’s Sonnet 4.6. To assess and critique responses from each, I adopted the mindset of a person reluctant to begin a content audit and looking for AI help to kick-start action on this, and used this as a roleplay to review and compare the responses.
Despite a glitch in formatting the response, Llama 3.3. provided some general information about content auditing. Its response included an initial assessment of the site, which made objective judgements of the homepage (assessing it as ‘well-structured, with a clear introduction’), the navigation menu (labelling it ‘easy to use with links to key sections’), content quality (noting it as ‘high-quality, informative and engaging’) and accessibility (pulling out that the site had an accessibility statement).
The response then acknowledged that in order to do a thorough content audit on the site in question there was a need to provide guidance on the aspects to focus on, and rounding off, the response noted some of the aspects a typical content audit would examine: content quantity, content quality, accessibility and consistency across different parts of a site.
Reviewing this response, I felt that if I was a site owner looking to improve my site, this response could very easily persuade me that I didn’t need to bother auditing it at all – and I wasn’t left any wiser about how to meaningfully provide guidance on the aspects to focus on if I did decide to proceed with an audit.
Likelihood to convince me to audit: 3/10
As would be expected from a reasoning model, the response when I used GPT 5 was more detailed than Llama 3.3’s. Arranged in two sections, the first part included preliminary observations using the site URL provided – which were split into the following categories:
The second part of the response outlined a plan for a full audit. The plan began by posing three questions to be answered:
The response then provided a suggested series of 7 steps to follow to complete the audit:
It rounded off suggesting a template structure for the content inventory (and offering to create this template as a Google Sheet), an idea for a scoring rubric, and reiterating different tools to use (naming products like Screaming Frog, Google Analytics and SEMrush). To conclude, it offered to do the audit, requesting answers to the three initial questions and asking for access to a sitemap, external tools and governance documents (such as style guide and brand voice guidelines).
Reviewing the response, which was presented as text content, I found it a bit too much to scan and digest, and putting myself in the place of someone facing content auditing with some reluctance, it felt that this large amount of detail could be off-putting to even start the process. I could appreciate the relevance of suggesting of external tools, but knowing that each of those would require setting up accounts and logins, as well as going through a process to integrate with Open AI, it had the effect of making me mentally push content auditing to the bottom of a to-do list.
Likelihood to convince me to audit: 6/10
The output from the Anthropic model stood out compared to the others from ELM since it was not just plain text, instead, it had been structured with headings, tables and icons. This made scanning and digesting this response much easier than the others.
The response was structured into 10 sections, as follows:
Content within each of these sections was comparable to that included in the GPT 5 response, but in the Sonnet 4.6 response, these sections referred directly to information from the site in question – for example, instead of making general assessments of site aspects like navigation and content coverage, it contained direct detail about the site itself with mention of specific pieces of content, noting what was already known (for example, referring to issues noted in the accessibility statement). Arranging this in tables with use of icons and red, green and amber priority indicators made it easy for me to pinpoint what to address and with what urgency, and having this consolidated in the final table was easier to parse than reading it in text format (as in the GPT 5’s response).
Reviewing this response from Sonnet 4.6, it was the best of the bunch from ELM, it contained enough detail to help me get started but not so much that it was overwhelming. Putting myself in the position of a time-poor site owner unsure where to start, I had clear pointers of the priority areas and a mix of quick wins and bigger tasks to choose from.
Likelihood to convince me to audit: 7/10
Three sets of two side-by-side screenshots, showing the output from Open AI GPT 5.5 (on the left) compared to the output from Anthropic’s Sonnet 4.6 (on the right) showing Anthropic’s more structured and visually appealing approach to presenting the responses
Models within ELM can also be accessed through interfaces provided by AI products. Two of the best-known AI products are Chat GPT (by Open AI) and Claude (by Anthropic). I was curious to see the responses each of these products would provide in response to my query asking for content auditing help so I prompted each of them in the same way. In both cases I used the free versions.
The response from Chat GPT was comparable to the output from ELM choosing an Open AI model, but the response was structured and annotated with tables and icons, in a style similar to the Anthropic response. It began with a suggested audit approach which set out different areas to consider and related questions. In the next section (headed ‘Initial observations’) it contained an analysis of the site itself, which included site strengths and highlighted the following six areas for improvement on the site in question:
The response concluded with an example audit table and some content recommendations, organised under ‘Keep’, ‘Improve’ and ‘Review’.
Reviewing this response as a whole, I liked the up-front suggestion of an auditing approach and the example audit table which was then supplemented with detail about the site itself and recommendations relevant to different aspects of the site in question. This helped me visualise what the audit outputs could look like, and I could see ways to get there.
Likelihood to convince me to audit: 7/10
A screen showing the output from Open AI after being prompted for help content auditing. The suggested audit approach laid out in a table with columns for the different areas of auditing and associated questions to ask in the right-hand column
Another screen showing the output from Open AI after being prompted for help content auditing. An example audit table is laid out with rows for each URL, and columns containing associated purpose, audience, quality and recommendations.
Another screen showing the output from Open AI after being prompted for help content auditing. Content recommendations are laid out with colour coding for ‘Keep’, ‘Improve’ and ‘Review’.
Anthropic’s Claude interface took a different approach to the other AI products, immediately asking about the main goal of the audit with options to pick. I picked ‘full inventory’. It then asked the desired breadth of the audit with another set of options, from which I picked ‘full site crawl’. The next screen asked me about the output format, and I picked ‘spreadsheet’.
From top to bottom, the interactive screens produced by Claude asking about the main goal of the audit, the breadth of the audit and the format for the audit output. Each has multiple choice answers to select
After approximately 2-3 minutes, with a running commentary of what was being done, Claude presented a list of ‘headline findings’ of bugs, orphaned content, out-of-date content and broken content (dead links, incomplete calls-to-actions etc). It also produced a downloadable Google Sheet with two tabs – the first containing a summary of the issues to be fixed, their locations and a reason why they needed to be fixed, the second with a full inventory, with one row for every URL in the site and columns logging the page title, content type, date, status (with colour-coded options: ‘Keep’ (green), ‘Update’ (amber), ‘Rewrite’ (dark amber), ‘Review’ (blue) and ‘Critical’ (red)) and recommended actions for each page.
Screenshot of the audit output spreadsheet produced by Claude, showing one row per page URL and different columns logging content types, date, status and recommended actions.
Reviewing this response, it was by far the most effective at making me feel I was starting the content auditing process and supporting me through it. Being presented with the opportunity to answer questions upfront meant I could control how the audit went, and having a spreadsheet created for me to review saved a lot of effort making this from scratch by scraping the site for a sitemap and page metadata.
Likelihood to convince me to audit: 9/10
If you’re looking to improve your website, doing a content audit is one of the best steps you can take – working out what you have, what’s working and what’s not will put you in a strong place to move forward and make positive changes. Depending on how well you know your site, and how much time and resource you have to spend on it, you may appreciate some help to get started auditing its content.
From my quick experimentation with the different AI tools available I learned that, with the exception of the small non-reasoning model, each AI product offered something to help initiate the content auditing process of a website. At a basic level, asking AI to look at your website will pull out something you may not find yourself such as an out-of-date page, an irrelevant CTA or an accessibility glitch. AI can also take a zoomed-out look at your site that you may be too close to adopt yourself – such as reviewing your navigation pathways, appraising your audience segmentation or analysing the consistency of your content voice and tone.
If you’ve never audited a website before, AI can offer a lot of guidance to get you started, and whether you choose to do it yourself taking recommendations from the AI on tools and/or processes or whether you prefer to hand the heavy-lifting to AI to get your audit spreadsheet started – leaving you to deal with the more nuanced decisions that require specialist knowledge and experience, these tools can save you time and effort and may just be the nudge you need to do this all-important website maintenance task.
As the Steam Deck slowly marches toward its fifth birthday next February, owners are likely eager for a way to extend its life rather than investing in expensive high-end competition. A new patch for AMD's Linux drivers could substantially reduce low-end frame hitches when the Steam Deck or other AMD-based gaming hardware is running in Energy Performance Preference (EPP) mode.
Writing on the Linux kernel mailing list (thanks, Phoronix), kernel coder David Vernet lays out the basic problem that games often face in EPP mode. When a busy thread frequently goes to sleep for short periods, the current AMD driver can misinterpret that behavior as a signal to lower its average performance target. When those threads wake up, they start at a lower-than-desired frequency, leading to increased frame latency, stale frames, and longer frame generation times at the low end of the distribution.
Shifting the processor to "performance" mode fixes this problem but eliminates the energy savings that EPP mode is supposed to provide. And simply boosting the affected thread's minimum performance target permanently actually makes low-end performance worse, thanks to the complexities of CPU/GPU boost management.
© Samuel Axon
I previously introduced QuillMark, a tool I built to help web publishers check content against the University’s editorial style guide. In this post, I explain the technical design and methodology behind the prototype.
My name is Shlok, and this summer I am working as an AI and UX Innovation Intern in the Information Services Group (ISG). During my internship, I have been developing QuillMark, a prototype tool designed to help web publishers check their content against the style guide. This post outlines the system design, methodology and AI pipeline behind the prototype, including how deterministic checks, language models and a MapReduce approach work together to improve reliability while keeping publishers in control.
QuillMark highlights violations in your existing text rather than generating an entirely new version. This:
Problem: The style guide contains a large number of rules, around 60–70. If all rules are sent to the LLM at once, the model may not check the text against every rule reliably.
Research: https://openreview.net/pdf?id=R6q67CDBCH
Solution → MapReduce (Divide and Conquer: Map → Collapse → Reduce)
Pipeline:
The deterministic checks are used to flag “obvious” violations that are directly detectable using regex or code. For example, this could include the use of a forbidden word, or a spelling convention such as using “benefited” instead of “benefitted”. These issues can be detected using a direct search of the page and do not require AI.
The second stage uses a smaller fine-tuned model. This model would be fine-tuned on the Style Guide rules and training examples. It would again be used to detect relatively “obvious” violations, but ones that are not simple enough to be detected reliably through deterministic checks. These issues are not highly complex, so they should still be visible to a smaller model.
After the publisher fixes the deterministic violations and the violations found by the fine-tuned small model, there are likely to be remaining deeper and more complex issues that both previous approaches did not pick up. The final large model can then focus mainly on these more complex issues. This means it spends less attention on obvious violations and more attention on issues that are easier to miss.
This improves the process in two ways.
First, it allows the final large model to focus on deeper issues. If the whole page was passed directly to the large model from the beginning, it would likely flag many obvious violations first and might miss some subtler issues. By fixing the most obvious issues earlier, the large model can focus more on smaller, judgement-based, or easily missed problems.
Second, it may reduce cost compared with running the large model multiple times. One alternative would be to run the large model once, fix the obvious issues + some deeper ones it finds, and then run the large model again to find the remaining deeper issues. In the first run, the large model may spend much of its output on obvious violations. In the second run, after those obvious issues are fixed, it may be able to look more deeply. The proposed approach tries to achieve a similar effect more cheaply by using deterministic checks and a smaller fine-tuned model before the final large-model review.
This pipeline is shown in Figure 1.
Based on personal experience with large language models, as well as existing research such as the Curse of Instructions, we cannot rely on a large language model to follow a very large number of rules at once. In this case, the style guide contains around 60–70 rules. If all of these rules are passed to the model in a single request, the model may not check the page against every rule properly. It may follow some rules, ignore others, or miss violations because there are too many instructions to apply at the same time.
To solve this, I propose using a MapReduce approach, which is a divide-and-conquer technique: Map → Collapse → Reduce.
The rules would be broken into smaller chunks, with each chunk containing a fixed number of rules. Each chunk would then be sent as a separate request, asking the model to check the page only against that smaller set of rules. This allows the model to focus on fewer rules at a time and check them with more attention.
After all the chunks have been processed, the responses would be gathered together and combined into one report. This is the collapse stage. The combined findings would then be passed through another large language model request in the reduce stage. This final request would clean up the output by removing duplicate findings, resolving overlapping issues between chunks, and filtering out possible false positives or hallucinated violations.
This approach makes the checking process more reliable because it avoids asking the model to apply all 60–70 rules at once. Instead, each group of rules is checked more carefully, and the final report is produced by combining and cleaning the results. This helps ensure that all rules are checked with more equal rigor, rather than relying on the model to remember and apply every rule in one large prompt.
The MapReduce approach is shown in Figure 2.
Update: Large-Model Cleanup from the Reduce stage was excluded from the prototype as the probability of duplicates occurring is low and the cost of such a cleanup is relatively high with minimal benefit.
Read more about the technical system plan: https://blogs.ed.ac.uk/website-communications/building-quillmark-testing-a-drupal-style-guide-assistant-with-web-publishers/
Watch a video demo: https://media.ed.ac.uk/media/t/1_yozad8ie
Future enhancements:
I introduce QuillMark, a Drupal prototype designed to help web publishers check content against the University’s editorial style guide. I reflect on how I developed and tested the tool with publishers, focusing on what their feedback revealed about usability and how it will shape the next version.
My name is Shlok, and this summer I am working as an AI and UX Innovation Intern in the Information Services Group (ISG). During my internship, I have been developing QuillMark, a prototype tool designed to help web publishers check their content against the style guide. This blog post explains the problem I was trying to solve, how I built and tested the prototype, what I learned from publishers and what I plan to do next.
Our style guide contains more than 60 rules covering areas such as spelling, punctuation, tone, formatting and terminology. Previous research showed that web publishers found it difficult to remember and apply every rule while writing and editing content.
This is understandable. Publishers are often working under time pressure, and checking a page manually against dozens of rules adds a significant cognitive burden. Even experienced publishers can miss small details, particularly when they are concentrating on the meaning and accuracy of the content.
I began exploring whether a tool could make this process easier. The aim was not to replace publishers’ judgement or rewrite their content automatically. Instead, the tool would identify possible style-guide violations, explain the relevant rule and allow the publisher to decide whether to apply or dismiss each suggestion.
This became QuillMark.
Read more about the Style Guide
Drupal is where publishers already create and edit web content, so it made sense to build the prototype directly into that environment rather than create a separate tool.
Before starting development, I attended Drupal in a Day to understand the platform, its content-editing interface and how a custom tool could fit into an existing publishing workflow.
Building QuillMark within Drupal meant publishers could check their content without copying it into another system. It also allowed me to test the tool in a realistic environment, using the same types of fields, buttons and interactions that publishers encounter in their day-to-day work.
Read more about Drupal in a Day
Before writing the prototype, I planned the system in detail.
One of the main design decisions was that QuillMark should highlight individual issues in the existing content instead of generating a completely rewritten version. Rewriting an entire page could introduce unnecessary changes and would require the publisher to audit every sentence. Showing individual findings makes it clearer what the tool has identified and keeps the publisher in control. This also prioritises the HITL (Human-in-the-Loop) framework, which I intend to use in my AI-based projects to ensure that people remain involved in reviewing decisions made by AI.
The system design proposed three types of checking:
The plan also used a MapReduce-style approach. Rather than asking a language model to apply all 60–70 style-guide rules in one prompt, the rules would be divided into smaller groups. Each prompt could then concentrate on a limited number of rules before the results were combined. This was intended to reduce the risk of the model overlooking instructions because it had been given too many at once.
The original design included an additional AI step to remove duplicate findings and resolve overlaps. I left this out of the prototype because duplicates were expected to be relatively uncommon, while the extra model request would increase cost and complexity.
Read more about the technical system plan: https://blogs.ed.ac.uk/website-communications/quillmark-the-technical-details-behind-my-drupal-style-guide-assistant/
I developed the prototype iteratively, beginning with a small number of style-guide rules and expanding the checks once the basic workflow was working. For development, I used Codex. I gave it my plan and asked it to design the architecture. After reviewing it, I asked it to proceed with the implementation.
The first stage used deterministic checks for issues that could be found reliably without AI. These checks searched the content for recognisable patterns and returned the location of the issue, the relevant style-guide rule and, where appropriate, a suggested correction.
The second stage used a large language model to identify issues that depended more heavily on context. I divided the rules into smaller prompt groups so that the model could focus on a manageable set of instructions during each request.
The prompts asked the model to return structured findings rather than a rewritten page. Each finding needed to include enough information for QuillMark to:
Publishers still had to approve or dismiss each finding. This human-in-the-loop approach was intentional. Style rules can depend on context, and an automated suggestion will not always be appropriate. QuillMark was designed as a decision-support tool, not an automatic editor.
Watch a video demo: https://media.ed.ac.uk/media/t/1_yozad8ie
Once the first iteration was complete, I adapted an existing usability-testing template to create a test for QuillMark.
I conducted three sessions with web publishers. Participants were asked to work through a series of tasks covering the main parts of the prototype, including running the checks, understanding the two stages, locating an issue in the editor, reviewing a rule and applying or reverting a suggested fix.
I observed how participants used the interface, where they hesitated and whether the information on screen matched their expectations. I also asked how they might use the tool as part of their normal publishing process.
The purpose was not only to find technical bugs. I wanted to understand whether the concept itself was useful and whether the interface communicated how the tool was intended to work.
The publishers thought the tool would be useful as a final check before publishing. They said they would still use their own judgement and would not automatically accept every suggestion.
Most of the feedback was about the usability of the tool. Some parts were unclear, such as the difference between the two stages and some of the button labels. There was also too much information on the screen, and some issues were repeated. The publishers also wanted to see what a suggested fix would change before applying it.
The testing suggested that the core idea is useful, but the user experience needs to become simpler.
Publishers do not necessarily need to understand which checks use regular expressions and which use an AI model. They need to know what issue has been found, why it matters, what the proposed change is and what action they can take.
The sessions also reinforced the importance of designing for scanning. More explanation does not always create more clarity. In a publishing workflow, concise labels, clear states and well-grouped findings may be more valuable than displaying every piece of supporting information at once.
My next step is to refactor and review the prototype code before making changes based on the usability feedback. This will include reviewing the AI-generated code to check whether each section is needed, whether the same result could be achieved more simply, and whether any parts repeat code that already exists. I will compare the generated code with the rest of the codebase so that it follows the same structure and does not add extra functions or files without a clear reason.
Where the code is longer than needed, I will simplify it by removing repeated checks, combining similar sections, and reusing existing functions. I will also keep individual files to a manageable size, generally no more than 1,000 to 3,000 lines depending on the file. Larger files will be split where this makes the code easier to follow, and hardcoded rules will be moved into the database where possible.
The next iteration will focus on:
The widespread introduction of AI-powered coding tools has led to some dramatic splits between those integrating those tools into their workflows and anti-AI absolutists who don't want large language model-generated code anywhere near their projects. When it comes to the Linux kernel, though, creator and top-level maintainer Linus Torvalds said he is "willing to absolutely put my foot down" in support of using AI tools to improve the long-standing open source project.
Writing in a lengthy post on the Linux kernel mailing list this week, Torvalds said that "Linux is not one of those anti-AI projects, and if somebody has issues with that, they can do the open-source thing and fork it. Or just walk away."
The statement came amid a lengthy thread arguing about the use of Sashiko, an "agentic Linux kernel code review system" that its creators claim can, in tests, independently find 53.6 percent of the bugs that would end up being fixed by human coders in later commits. But the tool can also waste maintainers' time by sending "false positive" reports of bugs that don't exist, at a rate Sashiko's maintainers estimate is "well within [the] 20% range."
© Getty Images
In March, I started my internship as a Digital Developer within the Website and Communications team. My internship focuses on exploring Figma, the industry-leading digital design tool, and the user interface (UI) component library that the University has been developing within it.
On my first day – somewhere between onboarding, learning a whole new set of acronyms, and unexpectedly getting free pizza – I began to get a sense of what the next few weeks might look like. I also met with colleagues I’d be working with closely on the project: Sonia Virdi (Human Centred Specialist in Web Strategy and Governance) and Mel Batcharj (Content Designer in UX and Digital Consultancy).
Looking back, that first week was a bit of a whirlwind. From getting to grips with the University’s structure, to navigating room bookings in the Edinburgh Futures Institute, to settling into the Forrest Hill office (and quickly becoming a fan of the huge monitors), it took some time to find my rhythm.
Attending my first stand-up and adjusting to a new way of working was all part of that process. At the same time, I began exploration and research, which quickly became central to my day-to-day work. What stood out most was how quickly the experience shifted from unfamiliar to genuinely engaging, especially as I explored the problem space in more depth.
Several platforms and tools underpin this work, helping us design, document and maintain digital components while ensuring consistency between design and development.
EdGEL is the University’s coded component pattern library. For those unfamiliar, a pattern library contains all the digital assets that are required when building and creating digital products and services. EdGEL’s underlying design framework is Bootstrap, which provides the starting point when developing coded components.
EdGEL is widely used across websites and web applications. It acts as a central source of truth for how interfaces should be branded, structured and implemented at the University. It was developed in 2015 when the first Drupal installation of the University’s central web platform, EdWeb, was launched.
The assets contained within EdGEL are currently documented within Pattern Lab, which is being replaced by the tool Storybook. Both tools provide a practical way for developers to explore the available EdGEL components and understand how and when they should be used.
Storybook implementation of EdGEL pattern library
Figma Design is an industry-standard tool used to create user interface designs (UI), prototypes and support teams through its collaborative features. It’s widely adopted by organisations (from startups to large enterprises ) because it brings design and development workflows closer together, reducing inefficiencies in how digital products are created and iterated on.
More recently, Figma has introduced AI-powered features for prototyping and layout generation, making it an exciting tool in the current digital software landscape.
What is Figma? (Figma article)
In 2021, as part of the University of Edinburgh’s design system project, Figma was adopted to develop a library of digital UI components.
Blog on the University’s design system project
The goal was to make the University’s branded EdGEL components more accessible to a wider range of colleagues, align the two libraries and streamline digital development workflows. Additionally, the project’s aim was to simplify the process of making design changes and improvements to the EdGEL components, ensuring they are fit for purpose across a broad range of University environments. The work to create the Figma UI component resource would support a variety of roles involved in designing and developing digital platforms.
The University of Edinburgh’s User Interface Library of components.
Figma was selected for several reasons:
The two aims of my internship both focus on Figma, however, they approach the challenge from different angles. The first is about understanding how staff across the University currently design and deliver digital work, and where Figma fits within that landscape. The second is about improving the University’s existing Figma component library to better support its users.
The primary aim of my internship is to learn more about how Figma supports digital development processes across the University. This involves assessing Figma alongside the other tools teams use every day and understanding where it could add value.
As a second-year computer science student, I was keen to move away from a purely engineering perspective and instead immerse myself in the user side – exploring not just Figma as a tool, but the people using it.
Understanding how staff design, collaborate, and deliver digital work is central to this. Importantly, we’re not just interested in Figma itself, but in the wider workflows and tools that people rely on.
To guide this work, we focused on a few key questions:
To help us understand how people work, we created a survey to reach a large proportion of internal staff across a range of roles. These included:
A key decision we made from the start of my work was not to focus solely on “designers.” Through discussions, we recognised that design isn’t confined to traditional visual design roles. People across the University make design decisions about layout, content, structure, and user experience, often using whatever tools are easiest to access within the University.
Our work is being supported by the design agency This Is Milk, who are helping us make better use of Figma’s newer features while improving the University’s UI component library.
This will involve:
Alongside our research, I’ve been developing my understanding of both design systems and Figma.
The internship has given me the opportunity to build on concepts I was already familiar with, like components and variant properties, while exploring newer ideas, including design tokens and more scalable system structures.
So far, the experience has shown me that designing digital systems isn’t just about creating components or choosing the “best” tools. It’s about understanding people, workflows, and the small details that make something either frictionless or frustrating to use.
Importantly, the internship has pushed me to think more from a user-first perspective, grounding decisions in usability, accessibility, and real user needs rather than focusing only on the tehcnical or visual aspects of a solution.
As my internship continues, I’m particularly looking forward to getting more hands-on with improving the design system and component library, as well as continuing to engage with staff to better understand how these tools can support their work.
Myself, Sonia and Mel will continue to blog about the project as it progresses. Our next post will explore the survey research in more detail, including how we carried it out, who took part and our initial findings.
A Linux vulnerability that allows untrusted virtual machines to gain root access to host machines is one of two high-severity flaws to surface this week in the open source operating system.
The vulnerability resides in KVM, which is, in essence, a virtual machine app included in the kernel of many Linux distributions. The vulnerability, tracked as CVE-2026-53359, allows guest virtual machines—such as those used in cloud platforms to isolate one user’s instance from the host OS and other user instances—to break out of that container.
The vulnerability affects KVM running on both AMD and Intel processors. It exploits bugs residing in the KVM guest-side, the portion of the VM that consists of only resources like the OS or drivers present in the guest VM, rather than resources present on the host machine. The threat went unnoticed in the Linux kernel for 16 years.
© Getty Images
UX Scotland is an annual two-day conference for people working in user-centred design. This year, I went along to the John McIntyre Centre to hear about the latest developments in UX. In this post, I’ll write about my highlights from the conference.
Joey Gartin presenting at UX Scotland 2026. Weird slide colours courtesy of my phone.
Out of all the talks I saw, this was the one that I found the most interesting. Joey Gartin, a content designer at Renfrewshire Council, told a story about a multiyear project to redesign the council’s website. It started with a familiar situation: the council had a large website that people found confusing and hard to use. Users couldn’t find things, and when they could, it wasn’t always easy to understand.
Renfrewshire Council needed to work out a better way to divide up and group the content on their website. Then they needed to name those groups in a way that made sense to people.
I enjoyed hearing about this because this is one of those problems that never seems to go away. When we work with digital content, whether that’s designing a homepage or tidying up a shared set of folders and files, we’re constantly looking for ways to group things. Then we’re also constantly looking for names for those groups that will make sense to people.
Renfrewshire Council approached the problem using methods from Object-Oriented User Experience (OOUX). This is an approach to digital product design that focuses on establishing the things (or ‘objects’) that matter to your users. The approach emphasises the importance of working out the nouns involved in your service before you move on to the verbs. I’d read a bit about it a while ago on Duncan Stephen’s blog:
Duncan Stephen writes about how the Scottish Government have used OOUX approaches
The argument in favour of focusing on nouns is that this approach is more closely aligned to how people think. When you walk around a supermarket, you have a shopping list of objects. To reflect this, a supermarket is typically organised into sections that reflect broader groupings of those objects: Fruit, Vegetables, Pasta, Cake, and so on.
In a similar way – the theory goes – people often approach websites with a list of nouns in mind. They are therefore scanning webpages for keywords that match these nouns.
But many council websites use a hybrid of verb-based groupings and noun-based groupings. So you get sections called Pay, Apply, Report and Request forming a core part of their information architecture. Here are two examples.
The City of Edinburgh Council:
Renfrewshire have not adopted this model. While their page titles often start with verbs, the groupings for these pages overwhelmingly use nouns:
Joey cited the City of Sydney as another public body using this approach:
With your objects figured out, the next step of an OOUX approach is to work out:
Joey talked us through this work. He also talked about how Renfrewshire Council used this as a foundation to create templated designs for common page types.
For example, take these two pages, both categorised as ‘service requests’:
Because they’re both service requests, you can see common sections on both pages.
For example, on the ‘Report a housing repair’ page, you have sections called:
And on the ‘Graffiti’ page, you have:
Joey showed us how this works behind the scenes. Renfrewshire Council use custom content types in Drupal to help structure the content writing process. So if you’re a content editor writing a service request page, you’ll be prompted to add a section on ‘Before you report it’. This helps content writers know what they need to include in a page. It also brings consistency to the website, which ultimately benefits users.
At Edinburgh, we use content types in our Drupal-based CMS EdWeb to create News and Event pages. So it was interesting to see another public sector website using a more extensive set of content types in Drupal. It made me reflect on how this approach might work for us. The context is so different: at Renfrewshire, it sounded like they had a more centralised approach to content management. The bulk of Edinburgh’s content publishing model is more devolved, which makes templated approaches to content more challenging. But there are clearly benefits available when you can make it work.
So lots to chew on from this talk, and it was a fun presentation to boot.
Sara Wachter-Boettcher’s keynote, “You don’t need more grit: breaking the burnout cycle in UX” was a run through of how and why burnout affects designers working in tech. It was a useful reminder to appreciate the limits of our influence within an organisation, and to be careful not to attach too much of ourselves to our job. It was cool seeing Sara in person. Her book Content Everywhere was one of the first things I read when I started in my role, and I thought it was really good.
Craig Abbott spoke about the risks and opportunities of using large language models for website design and fixing accessibility issues. One point that stood out was that LLMs are trained on some pretty ropey data. WebAIM estimate that 95% of the top million websites have detectable WCAG 2.2 failures, and these are the kinds of site that LLMs are trained on. So if you ask an AI to create a website, it will often produce something that superficially looks ok but is packed with accessibility problems.
The WebAIM Million: The 2026 report on the accessibility of the top 1,000,000 home pages
Craig showed us an example of a website he’d quickly created with AI and talked through the accessibility problems. He also showed us his other experiments. He’d had inconsistent results using AI to detect heading level failures or write alt text that took the context of an image into account. But he’d had some successes with using AI to complete more technical tasks with testable results.
James Chudley presented on bringing sustainability practices into digital design. The highlight for me was seeing his experiments with visualising page weight across a website. Taking inspiration from an infographic using colour bars to illustrate rising global temperatures, James had applied a similar idea to visualising where a website is using more energy-intensive design choices.
James has posted his slides here:
James Chudley: Presenting ‘Beyond human centred design’ at UX Scotland
UX Scotland was a good chance to hear from some leading lights in the field, catch up with people and hear about some case studies that are relevant to us at Edinburgh. The two days were well organised and it gave me a lot to think about as we continue to support UX and content work at the University.
I was pleased to have a talk accepted at the annual UCISA Women in Tech (WiT) conference. I went to Newcastle for a day of talks, workshops and networking. I left with a better understanding of the WiT community , and a reinforced appreciation of the need for inclusivity in Higher Education.
UCISA is an industry body supporting digital professionals working in the education sector. I have been actively involved in UCISA since 2022 when I helped set up the UCISA UX Group and became co-chair of this UK-wide community of practice. I’ve organised many UCISA UX events but had not attended one of UCISA’s flagship annual conferences, the Women in Tech event, until this year. My presentation about our project on staff profiles resonated with attendees, I learned a lot about diversity and representation in the sector from attending the other talks and I enjoyed connecting with other Higher Education professionals over shared inclusivity challenges. Here, I reflect on my highlights from an interesting day.
As well as the clear focus on inclusivity, one of the themes of this year’s WiT was real-world applications and problem-solving. I felt our staff profiles project spoke to this theme, so I submitted a talk to share what we learned from research and the steps we have taken towards finding a new profiles solution.
My session was well received – perhaps unsurprisingly, colleagues from other institutions shared the same concerns and challenges in designing a profile solution that showcases staff in the best light, keeps them findable in searches, and yet remains easy for staff to update. I valued the chance to make new contacts, exchange ideas, and learn about other institutions’ diverse approaches to the ‘profiles problem’. I resolved to stay in touch as we take steps towards implementing a profiles solution at the University, recognising just how universal this need is across the Higher Education sector, and seeing an opportunity for meaningful collaboration.
Read more about the staff profiles project in the blog post series:
Collected blog posts about staff profiles project
One of the core activities of the UCISA WiT committee is to regularly collect data to understand diversity within IT departments across the FE/HE sector. At the conference, WiT committee co-chairs Christi Hopkinson and Katie Wilde shared a preview of the results of the 2025 survey, completed by more than 200 respondents from 66 institutions, with 74.5% of the respondents identifying as female. Several findings stood out from the preliminary report in terms of risks and opportunities.
Responses to a question about progression routes revealed significant proportions of respondents had started in IT in the following areas:
Responses to a follow-up question about the roles respondents were currently working in showed continued representation in these areas, which indicated a degree of stasis when it came to progression in the sector. Areas where women were underrepresented included:
The survey results showed a third of respondents had considered leaving their institutions or the sector, citing pay, workload and progression as popular reasons motivating them to think about moving on. Common blockers to progression included:
Most respondents cited the following skills as important for the roles they were currently in as well as for progression:
This spread of skills reinforced the value of focusing training and development on non-technical abilities to complement technical skills, and to ensure expertise was appropriately directed to deliver on broader institutional goals.
Responses to questions about inclusion and belonging revealed positives and negatives about the workplace respondents were part of.
On the positive side:
On the less-positive side:
The spread of these numbers provided a clear steer of areas to focus on to achieve less exclusive, and better-balanced IT workplace.
The survey data gave a snapshot of the current state of inclusivity in the sector, however, anecdotes from individual presenters painted a more vivid picture of what inclusivity could look like. The WiT programme included several women sharing stories of their induction into tech and reflecting on their individual progression routes. It was refreshing to see the diversity of pathways they had taken and interesting to hear about what they had learned along the way, and their tips for success.
Monica Jones, Chief Data Officer at the University of Leeds acknowledged that career progression paths rarely run smoothly, and advised setting personal goals and milestones to work towards, to be best-prepared for promotion opportunities when these came up. Julia Lloyd, College Manager – Business and Law, at the University of the West of England, emphasised the benefits of ‘quiet leadership’ and shared tips to create space for different voices – such as thoughtful structuring of meetings, design of communication channels and rewarding contributions over confidence. A joint talk ‘The Not-So IT Crowd’ from Catriona Blair, Joanna Addison and Sasha Titus from the University of Kent, and a session by Amber Mothersille from the University of Northampton emphasised the value of non-technical skills in technical roles – recognising the need for empathy, trust-building and adaptability to strengthen teams and build excellent digital services.
A final takeaway from attending the WiT event was a call-to-action to question the way we work – specifically to foster inclusivity by making room for new ways of thinking and for fresh perspectives.
In an interactive exercise led by Katie Wilde, we considered five roles necessary for the operation of successful teams (the Navigator, the Connector, the Builder, the Challenger). In a period of honest reflection, we shared the roles we naturally adopted in team settings, and the roles we tended to overlook or disregard. Going through this exercise was a good leveller as well as a reminder to make room for diversity in everyday team settings instead of relying on familiarity.
The day closed with a thought-provoking talk on male fragility, delivered by Jake Dovey, a UCISA mentor. Drawing on personal anecdotes experienced through his involvement with UCISA, Jake’s talk described instances where men had overreacted defensively to being challenged and where women had inadvertently softened situations to avoid potential conflict and ‘keep the peace’. Jake challenged the women in the room to recognise these instances going forward, and prompted a call-to-action for all to recognise these harmful patterns and call them out to collectively help break the disruptive cycle.
WiT26 delivered a packed programme which encouraged me to think outside my work in UX and more broadly about the joint responsibilities we all have in creating and fostering an inclusive work environment. I came away with recommendations of books to read and concepts to learn more about, and a heightened awareness of embedding inclusive practices in my day-to-day work and activities. I am keen to see the full results of the WiT 2025 survey and to remain part of the WiT community going forward.
Drupal In A Day (DIAD) is an in-person training event, designed as a beginner-friendly hands-on introduction to Drupal, the open-source content management system. When the University hosted DIAD, several of the UX team took the chance to attend.
As content management systems go, Drupal is one of the mainstays. It’s been around for 25 years and is particularly famed for its robustness, reliability and flexibility – so much so it’s trusted to power websites of enterprises, governments and higher education institutions around the world. It’s open-source so there’s no proprietary lock-in – the functionality, features and innovation available in Drupal comes from a thriving worldwide community of contributors – as individuals, agencies and organisations.
One of the best places to learn about what Drupal is, what it stands for and what it aims to achieve is the blog site of its founder, Dries Buytaert.
In 2025, Hilmar Kári Hallbjörnsson taught the first Drupal In A Day on the final day of DrupalCon Vienna. Hilmar had been teaching Drupal to students at the universities of Reykavik and Iceland for many years and felt strongly that teaching Drupal to new generations, to inform them of its capabilities, and to inspire them of its potential was something the Drupal community needed, as a way to nurture the longevity and sustain the future of Drupal. Through a tremendous effort, he made the first Drupal In A Day happen in Vienna in October 2025. It was very well-received, successfully establishing the Drupal In A Day format going forward.
Read more about the first Drupal In A Day in Hilmar’s blog post from 2025
Hilmar travelled to Edinburgh to deliver Drupal In A Day with our own Web Development Team Manager, Gareth Alexander at the start of June 2026. Nick (Senior Content Designer), Shlok (AI and UX Innovation Intern) and Hannah (Digital Content Style Guide Intern) from the UX team signed up for the event along with other LTW interns and staff from the wider University with an interest in learning about Drupal. Here, they reflect on their experiences of the day.
I attended this training to bring my understanding of Drupal up to date. The last time I set up a Drupal site was in the early 2010s, and a lot has changed since then. With Drupal providing the backbone to EdWeb 2, I wanted to get to grips with some of the terminology and concepts that underpin conversations within our team about what our central CMS can do.
I was particularly interested to learn more about Drupal CMS, a new service that helps you set up a Drupal site more quickly and with less need for technical understanding.
After getting the required software set up on my laptop (thanks Kirsten), I clicked along with Hilmar and Gareth as they walked us through the various sections of Drupal CMS. We worked through steps to create a new content type and we created different Views to display the same content. We tweaked image formats. We also learned how to attach tags to a piece of content and how these tags can act as a filter for overview pages.
By the end of the day, I hadn’t suddenly become a Drupal expert. But I did have a better understanding of how EdWeb 2 works behind the scenes. In particular, I felt like I knew more about how EdWeb 2 takes the content you enter when you create a page and presents this in different ways elsewhere on a site.
Alongside that, I would now feel more confident in setting up a new Drupal CMS site, and I now have a better understanding of what this system offers in comparison to other ways of operating a website.
Finally, the day gave me a better sense of how the community aspect of Drupal is central to how this project keeps going. Hilmar and Gareth emphasised that there are various events in the calendar where people working with Drupal can meet up and collaborate. That’s a powerful message: that anyone is invited to learn more, become part of the community and contribute to how this system works.
Before starting my internship, Drupal was a completely new concept to me. I did not really know what a content management system was, how Drupal worked, or why it was used by universities and other large organisations. Because of that, Drupal In A Day was a really useful introduction for me.
I thought the format worked well because going through everything in one day helped keep a flow of information. It was quite intense and sometimes fast-paced, but that also meant we were able to cover a lot of concepts in a short amount of time. I would say I was able to follow around 70% of the session, which felt like a good start considering Drupal was completely new to me.
One of the parts I found most useful was the introduction to Drupal itself. It helped me understand what Drupal is, what a CMS is, and why the University uses it. I learnt that Drupal is valued because it is stable, secure, flexible and open source, which makes it suitable for large and complex websites like those used by universities. This helped me understand why Drupal is still used by many major institutions.
I also found it interesting to learn about the Drupal community and the different ways people can work with Drupal. Before the session, I assumed Drupal was mainly for developers. However, I learnt that people can build careers around Drupal in different ways. Some roles involve coding and development, while others focus more on design, content, user experience, training or project work. That helped me see Drupal as more than just a technical platform.
One point that really stood out to me was when we were told that Drupal has a steep learning curve at the start. This was useful to hear because it made the difficulties I was facing feel expected. Since many people find Drupal challenging in the beginning, it was reassuring to know that not understanding everything straight away was normal. It made me feel more comfortable continuing to learn.
During the practical parts of the day, I learnt about some of the basic Drupal features, such as creating and managing content pages. At first, this was quite confusing because the concepts were new to me. However, as the day went on, I started to become more comfortable with the terminology and the way Drupal is structured.
Another part that I found very helpful was the follow-up assignment where we had to build something from scratch. After learning so much in one day, I think it was important to have a task that allowed us to apply what we had learnt. It helped me consolidate my knowledge, see which parts I had not fully understood during the session, and become more comfortable with Drupal before starting work on my internship prototypes.
One thing I would have liked to learn more about was the command line and the use of terminal commands. We touched on some setup and development processes, but I think spending more time on what the commands do and how they fit into the Drupal workflow would have helped me. I would also have liked to learn more about the coding side of Drupal, especially how to build custom Drupal modules. This is particularly relevant to my internship because my work is focused on AI and innovation within Drupal.
If I could suggest one change, it would be to make Drupal In A Day into a two-day or three-day format. The first day could stay mostly the same, giving everyone a broad introduction to Drupal. The second day could be a slower guided session where participants build something with support from the instructors, similar to the assignment we were given afterwards. A third optional day could focus more on coding and custom module development for those who want to explore the technical side further.
I signed up for the Drupal in a Day training with very little knowledge of the CMS beyond working with existing EdWeb 2 sites, such as when creating prototypes of Style Guide pages or writing blog posts. So, I was interested in increasing my knowledge of Drupal as well as gaining the ability to build a site. Before the training began, I was unsure how well I would follow the instructions as a beginner, but Hilmar, Gareth, and all of the members of the Drupal community who were present at the training were extremely helpful, informative, and patient when it came to giving assistance at points where I was confused or behind.
Once I had overcome a technical error with my laptop and decided to use Drupal Forge, I was able to follow along with the instructions being provided and replicate the Artist biography pages that Hilmar and Gareth were demonstrating. The course was fast-paced and detailed, and while maintaining this pace was a challenge, it made the course engaging and the product of the day felt like a genuine accomplishment.
With the knowledge that I gained throughout the training, I feel that I have a strong foundation that will allow me to continue to develop my skills in building a Drupal site further in the future. In particular, I think the example site that we were creating during the training was incredibly useful in that it allowed us to try out several different aspects of building a site with Drupal, such as different content types, tags, and images, as well as exploring some different design options as well.
I was impressed to learn about how community centred Drupal is, and that contributions and developments to Drupal are made by users and members of the community. Gareth and Hilmar’s explanations of how this works really helped me to understand why Drupal is as adaptive and intuitive as it is (such as in its security and bug fixes), which is that these developments are a direct result of user experience. Furthermore, Gareth and Hilmar also emphasised the flexibility of Drupal, due to the ability to install ‘recipes’ that customise the functionality of sites that you are building.
Overall, I think Drupal in a Day was an extremely useful and practical training session that has equipped me with the skills to build a basic site and further develop these skills whenever I have the chance.
When it comes to Drupal, I am largely self-taught – pretty much everything I know has been gleaned from reading, attending/watching sessions from Drupal events, and (predominately) pestering people in-the-know with my questions. When Drupal In A Day came to the University, I pondered whether I should attend. I’ve contributed to the community since 2022. I’m on the Drupal leadership team. Surely I should know Drupal by now? I took a split second to reflect and realise that you never fully know Drupal. There’s always something new to learn, something to challenge what you thought you understood, or something to clarify an area you weren’t quite sure about. Conscious of not taking a space away from a complete Drupal beginner, I opted to sit in on the event, to follow along, while working on other things.
The day combined practical exercises with general Drupal knowledge. Hilmar and Gareth began with the basics, covering key parts of the process to get started and familiarise with Drupal – like setting up DDEV, using Drupalforge and creating a Drupal.org profile. As the day went on, it was great to see quick progression to experiment with some of Drupal’s flagship modules, especially Drupal Views which holds huge power for presenting and displaying structured content in a range of adaptive ways.
Drupal CMS, Drupal’s low-code product provided the playground for learners. Having worked on Drupal CMS since it began, I found it heartening to see it being used to introduce Drupal to new audiences, to help them learn what Drupal has to offer and to help them start ideating on how they might use it. Adopting a UX perspective, I tuned into comments from fellow attendees about Drupal CMS, noting observations to follow up and logging areas for UX improvement to carry forward in my ongoing Drupal UX contributions.
Reflecting on the day as a whole, it helped attendees achieve what is often the hardest thing about Drupal: Getting started. All too often people new to Drupal can find it overwhelming, and they find when everything is possible it’s hard to choose a direction. Drupal In A Day sets learners on a path to start discovering Drupal and making it their own, in other words, planting a seed from which the community can continue to grow.
Login