I’m really pleased to be sharing our Digital Comms roadmap for the next quarter. It’s the first time we’ve publicly shared it. It’s our way of explaining what we’ve done, what we’re doing and what we think we’re going be doing next.
As it’ll be a new concept for some, I’ll use this post to explain more about it, how we created it and how we plan to use it. (more…)
Digital officers Katie Manktelow and Hazel Jackson have pair written their top tips for pair writing.
As the saying goes, two heads are better than one. Pair writing is two (or more) people writing together. Introduced by agile software developers who were writing code, it’s now common practice in content design teams including our own. We use this approach to write copy for the website.
Any two people can pair write and produce better results than writing alone.
Ideally the pair is made up of one subject matter expert (who knows about the subject in depth) and one content designer (who specialises in writing for the web). Both people play an important role in writing valuable content.
6,000 members of staff and almost 28,000 students, six faculties, 28 schools and departments, 12 institutes, over 250 research groups, groups clusters and networks, and 14 divisions… The University of Bristol is, if nothing else, a complex institution.
The impact of our work reaches far beyond the boundaries of the campus. It addresses some of the most challenging issues facing the world. Personally, this is what makes working here so exciting. At times it can all seem a million miles from the day-to-day job.
But for those of us not on the front line of academic pursuits there is pride in being part of this community and finding new and innovative ways to help tell the story of the University of Bristol.
I published a post last summer about the positive effect a new project management framework was having for us and those we work with. A lot has happened since then, but, through it all, DPAB has doggedly and determinedly continued to meet every Wednesday to triage, assess and prioritise. We couldn’t do without it. So, what is DPAB and why do you need one?
What is DPAB?
Digital Projects Assessment Board (DPAB) is the governance function that assesses, approves, and controls project progress on behalf of the Digital Communications team.
DPAB was formed to provide oversight and control of incoming and in-process requests for work. This means all significant workstreams within Digital Communications can be supported to continually deliver user and business value. We demonstrate this value through effective and clear benefits realisation.
DPAB meets every Wednesday, like clockwork. We’ve only missed a few and that’s not because of C-19 or being too busy. It’s because we weren’t quorate.
My colleague John Bourne recently wrote a post about our clearing application process covering the user experience improvements. In this post I’ll be delving into some of the technical work behind these.
First, an introduction; I am a front-end developer for the Digital Communications team here at the University of Bristol. This will hopefully be the first of many dives into some of the technical work we do.
Last year we identified that the process for updating clearing information was convoluted and vulnerable to mistakes. A manually coded HTML table was used to display current vacancy information for all the courses involved in the clearing process. This would have to be completely re-written and published after any change within a separate system maintained by our admissions team.
A-level results day is one of the most important days in the University calendar, and that applies to us in the digital team. One of the most important tasks for us is ensuring that any A-level students who enter clearing have all the information they need from our website to make a decision about whether (or not) they’d like to join us.
Deciding on which university you want to go to is a huge decision for anyone to make and the whole process means often these decisions have to be made in a hurry. To mitigate the stress, we have to make the user experience of our Clearing pages and systems as simple as we can.
We’ve been investing significantly in an intranet for University staff and postgraduate research students (PGRs). Previously our intranet content was scattered across our external website, seriously old internal content management systems, wikis and random crevices that only staff who’ve been at the University for decades would be able to find.
As we’ve just moved it out of beta and into live I thought it was a good opportunity to detail the design principles we’ve been using to inform its development.
It’s important to add we’re still at the early stages of a long journey. There’s a large roadmap of development ahead. But we believe that by sticking with these principles we can continue to build an intranet that will prove invaluable to all our staff and PGRs.
The third part of digital officer Charlotte Brewer’s series on content sprinting.
This post was actually writtena while ago. We planned to release it as part of our series on ‘Content Sprinting’. Then lockdown started.Hitting the publish button fell down the list of priorities. Despite lockdown, and despite everyone working from home and all the challenges that has brought, we’re actually still working in exactly the same way. We’re still sprinting. We’re still doing everything we did before. Everything in this blog post remains accurate. The only difference is that all our meetings and our conversations are via Skype. (more…)
When colleagues from across the University come to us for help with their website, the first thing we ask them is: what’s your problem?
That sounds a bit rude and abrupt. Let me explain.
In any digital project or product this is the single most important question that needs answering. If there’s no problem to solve then there’s no work needed.
What do we mean by problem? What we don’t mean is that your website looks ugly, that it doesn’t look good on a mobile device, it doesn’t have the right tone, or that it’s not structured in a way that mirrors your team’s structure.
These aren’t problems, they’re solutions looking for a problem. (more…)