Accessible digital experiences are something we strive for at Comic Relief – we’re not perfect at it, but we’re trying to make sure that we can embed inclusive design at the heart of our product development*. In this article, I’ll be sharing some of the peaks and troughs of our accessibility work and the progress we’ve been making to ensure our digital experiences are accessible to all users.
Working in the charity sector you learn to be pretty resourceful when you need to be, and that doesn’t stop at blagging free stuff (obviously we never do that ;)).
One of the most significant things we learnt from amalgamating our campaign sites onto a single platform was the efficiency that emerged from reusing code and functionality.
So when our Schools and Youth team approached us with an objective that was new to all of us we did what anyone else would do, look at what we’d done already and could copy!
It’s always reassuring when you meet a person from your field who gets you and the daily gripes you face in your day-to-day job. So imagine how it feels when there are 1500 of you thrown together into one grand auditorium – it makes you understand how cults come into fruition.
Friday 8 September saw yet another ragingly successful Mind the Product (MTP) conference at the Barbican, London.
I’ve thrown together my top takeaways from each speaker at the MTP conference 2017. If you didn’t make it, for whatever reason, I should have you up to speed by the end of this post, and if I don’t you can get all the talks from the MTP website: boom.
Recently we reviewed our current approach for automated regression testing for one of our products here at Comic Relief. In this post I will discuss about our new approach for automated regression testing for Giving pages project.
For the past four months, the Platform Squad at Comic Relief has been working on a content migration from the old Drupal 7 code base to our beautiful new Drupal 8 platform. Anyone who’s been near this blog in the past year will have heard tons about the new platform (available here on Github) – but what today’s post is about is the final stage of the migration, ‘Going Live’.
For those who aren’t familiar with the concept of Pattern-Lab (or a Pattern Library), it’s essentially a living style guide; a common tool in modern web development. At their most basic, they are continuously updated documents that help documenting common design styles for web components, bringing together the intended look & feel with the images and codes to build them.
I started to look into this idea around a year and half ago because I found that each time a new project started, I needed to redo much of the same styling work. Even worse, when the main project was still in development, it was hard to keep an eye on the minor changes that affected other projects, so they would quickly get out of sync with each other. There wasn’t a centralised place to store reusable components. Unfortunately, my initial attempt to push a “shared Pattern-lab” idea didn’t work too well because we had difficulties integrating with various tools and workflows across teams.
Drupal 8 at Comic Relief
Over the last year a key objective for the Technology team at Comic Relief has been to build products not websites. Tech Lead, Peter Vanhee, explained in a previous blog post how we’re using Drupal 8 to create a reusable platform product for building campaign websites. Since then the team have been working to deliver another website using the platform codebase and also preparing to open-source the codebase.
We have now opened up this codebase – you can find it here.
10 years ago (at the end of 2006), Drush appeared to make it easy for Drupal developers to do some common tasks, it wasn’t immediately popular as it was a Command-LIne tool and a lot of people didn’t appreciate the idea, but year after year it’s popularity grew as did its functionality.
By the time Drupal 7 came out it was unimaginable for most developers to build a site without Drush because of the incredible boost they got in their development process and the option of generating a site from a makefile and avoiding the need to add in their project contrib code or risk of people hacking the behaviour of this module and unfortunately this was a common practice.
But Drush with the makefile wasn’t good enough, if they update some module the makefile won’t show any update, sometimes some releases breaks other modules and it wasn’t a clear way to say “I need up to this version of that module”, indeed the whole update process itself wasn’t very automated at all, and it was only useful for download a specific version of a module and with his dependencies (it gets the latest version of them without check if they are compatible)
I talked about our journey of building a product to power all our editorial websites at Comic Relief (see my previous blog post), and focused on three topics: editor experience, automation & streamlining, and using decoupled services.
Check out the video of my presentation (audio+slides),
Hey, I’m Leigh. I’m a digital designer at Comic Relief and this is my first post for the Comic Relief Tech Blog! I’ve just started working on a new digital storytelling product and thought it might be interesting to blog our journey, through our processes, what’s working, our challenges etc. In this first post I’ll start by giving a little context to the work.
The story so far
Digital storytelling is a technique we have been using to educate people about the issues that Comic Relief supports. Not only to raise awareness about the problems but also talk about where the money goes and celebrate the progress. We have delivered this through films, personal stories, editorial, case studies, photography, infographics, stats, maps, interactive stories and social media takeovers.