In this two-part blog as part of Open Access Week, Nilam McGrath and Dru Riches-Magnier outline the approach they took to develop the COMDIS-HSD website from 2012 to 2018.

Hello…

Firstly, an apology. The COMDIS-HSD website that we are writing about no longer exists in the glorious form in which we left it in December 2018, but the learning we describe below, we hope, remains valuable nonetheless.

Setting up a website can be a minefield, and unless you have dedicated institutional support, or a very tech-savvy friend, it’s difficult to know where to begin. It took us four years to get the COMDIS-HSD website to where we wanted it: accessible, user-friendly, optimised for multiple devices, populated with relevant content, and looking clean and fresh. Our starting point, however, was anything but these things. Over 6 years ago, when we first started working together, the website looked very different. We changed substantial elements incrementally each year until, eventually, from 2012 to the end of the programme in December 2018, the website had been transformed (see Figure 1).

Figure 1. The website in 2012 (left) and after the transformation in 2018 (right).

Very different from our starting point, isn’t it? But it took us a while to get to there.

In the beginning…by Nilam

Before we outline our process and rationale, it’s worth noting that (1) I dedicated around 2–4 days per month to developing the website, and (2) Dru was hired for a minimum of 3 hours per month before I was recruited, but he hadn’t been briefed about any changes to the website for around six months by the time I was in post; a simple case of ‘The RU Manager we’re recruiting will sort it’. We continued with the 3 hours per month minimum, increasing the hours to complete certain activities as and when needed.

Top Tip 1: Carve out dedicated time each week/ month to progress website development. If either you or your supplier (or both) have very few hours to devote to specific creative projects, it’s really important that you carve out dedicated time when you will (a) complete any work needed to progress the project, and (b) communicate with each other on the progress and next steps.

Top Tip 2: Treat your website like the essential communications tool that it is. Websites aren’t a luxury anymore. They are an essential communication tool, so make its development and maintenance part of your workplan and routine; upgrades and updates are important.

Communicating with each other
I used a monthly ‘rolling list’ with Dru. This was a simple list of work that needed to be completed that month, prioritised in order of importance. Typically, it was only really the first two or three activities on that list that were necessary to make huge leaps in progress each month, for example, specific actions to change the content and navigation of the journal articles page (some larger tasks would roll over into the next month). I emailed this list to Dru in the body of the email (no attachments). As Dru began completing the bigger structural changes in those early years, the list became populated with a greater number of smaller refinements that could be completed within the hours Dru had allocated for that month.

Top Tip 3: Make sure you include your website name in the subject line when you email your supplier. ‘You’d be surprised how many clients just write “website changes” in the subject line’, Dru once said to me. ‘I deal with websites all day, every day, and some clients hire me to do more than one website, so which one are they referring to when they email me?’ I learned my lesson very quickly after that.

Our starting point
The website theme had been set up in WordPress in early 2012, but it essentially lay dormant for most of the year as there was no-one in post to brief Dru. The COMDIS-HSD ‘brand’ at that stage had a dedicated YouTube channel, Twitter account, Facebook account, and various free email accounts with numerous app providers, none of which were being fully used.

Dru and I met (in a windowless basement room in London) at the beginning of 2013 to review everything. That first meeting was hugely successful simply because we met and discussed ideas, expectations, and roles in person and not over the phone; it lasted 3 hours and we flip-charted the hell out of it.

Top Tip 4: For larger or long-term projects, meet your web developer beforehand. Meeting (or at the very least, a dedicated video chat if location is an issue) before any website development begins will help you understand the web development process and share ideas. Plus, it’s just a nice thing to do; you’ll establish a good rapport and that’ll make things altogether easier in the long-term.

Our brainstorming covered everything from the website’s aim, to its content and accessibility, and we were pretty brutal in our assessment, as we were both coming at it with fresh eyes. We both knew that technology and design protocols had moved on rapidly since the first iteration of the website a year earlier. We also knew that with WordPress we had a solid, malleable platform to work with, and that Dru could make it sing and dance with some fancy coding if needed. There was one thing we couldn’t change (for now): the logo. Everything else was fair game, and there was a lot to sift through.

We knew we had to be flexible about prioritising some of the changes, and thought of it more like a house renovation (where changes in one location would possibly throw up more problems elsewhere) and so rather than become committed to a detailed implementation plan with fixed deadlines, we worked out what we could broadly do NOW, SOON and LATER – a fabulously simple prioritisation technique used by community development workers that works equally well for small-scale project planning.

Below, I outline what we focused on for the first 4 years:

Year 1

In all, our initial reorganisation of the website took 8 months, and we prioritised two things:

1. clarifying the structure and content; and
2. making the existing documents more accessible.

Clarifying the structure and content
This was really about culling; getting rid of anything I thought our audiences would find distracting or irrelevant and, crucially, structuring the layout and content by asking the following question:

How many times does a reader have to click on a link before they get to the information they want?
HINT: If it’s more than two clicks, you’ll need to rethink your structure.

I asked Dru to change the font and layout throughout, whilst I worked on making the content more relevant, adding new sections on research uptake, member profiles, the embedded approach, news items, resources, and a rolling news section that Dru coded so that it displayed and updated on the homepage automatically.

Web developers are not copywriters! I wrote everything and uploaded it onto the WordPress content management system (CMS), which I used to refer to as ‘the backend’ of the website. The ‘backend’ is not a technical term, it’s just my idiotic name for the CMS (editor’s note: that’s what we call it at R2A too!), but it made Dru laugh. Whenever I uploaded new content and it went ‘live’, if it looked a bit weird, or a link didn’t work, or the alignment was off somewhere, that’s when I would email Dru a link to that page with clear instructions on any specific changes I needed.

The major change that year was the structure of the ‘journal articles’ page to include a more sophisticated search function and user-friendly layout. The existing page read like a poorly formatted bibliography, with incorrect, broken, and non-existent links (see Figure 2).

Figure 2: The website’s journal articles page in 2012 (left) and 2018 (right).

The ‘before and after’ are poles apart. Honestly, when I saw what Dru had developed, I wanted to give him a medal. His inspired design was clean and led with the titles of each article rather than the authors. The new layout meant that if readers were interested in the article, then they could expand their selection to read more, and click through to the article hosted on the site. This meant that it was much easier to collate metrics about our articles from journal websites – for both our researchers and funders.

Other smaller changes – all ideas from Dru based on his extensive experience – included adding a cookie policy, ‘This is really important!’ he said (a legal requirement in the EU); experimenting with Google analytics (he was really patient explaining analytics to me); and experimenting with other platforms to share information.

These initial changes to structure and content meant that we moved from a static website to an interactive one with links to existing resources within a year. This included linking our YouTube channel to the website and using a new Flickr account to share previously unseen photos of fieldwork and research.

Making the existing documents more accessible
I knew from my conversations with partners, and from both reviewing logframe targets and writing the RU strategy and operational plan for the consortium, that the publications portfolio was going to become large over the next 4 years while the project was active. The go-to format for outputs is the PDF, but creating a PDF for each output didn’t sit well with me: a wall of PDFs can look somewhat impenetrable if structured poorly on a website and it creates ‘PDF fatigue’ or ‘blindness’. But I also knew that, for lots of reasons, this was the preferred format for many partners for NOW. The idea of experimenting with alternative formats to a PDF was something for LATER. To make existing information more accessible NOW, I edited existing content using plain English principles and continued writing new content along the same lines.

Year 2

My instinct about PDF fatigue/blindness turned out to be correct. A 2014 study by the World Bank showed that 31% of policy documents are never downloaded, and this could be attributed to the dreaded PDF format, a theory elaborated on in this Priceonomics article.

For these reasons I tried to counter convention by providing other ways to view research findings, particularly for people with poor internet connections and low bandwidth.

During my research I came across excellent guidance from Aptivate about designing websites and uploading content for users where low bandwidth is an issue (both poor internet connections or little or very expensive access to data on mobile devices). This led to my decision to also upload HTML versions of our documents, the slight deviation being with health guidelines which were uploaded as Word documents so health workers could adapt them easily. PDFs are data heavy and HTML was a smart way to ensure quick and easy access. Over time, our stats showed that the HTML versions of our briefs were approximately three times more popular than the PDFs.

This small but powerful change was one of many that I made over the years to ensure that the broader portfolio of outputs was accessible to institutions and individuals with fewer resources; a strategy that was commended by DFID in their programme completion report.

Another way of making our work accessible was duplicating our portfolio on an external site. With one eye on the future, I knew that the website would eventually be shelved in an institutional repository and perhaps not exist at all after the end of the programme, so it was important that the research evidence remained available on an easy-to-use platform.

I did some research and settled on Scribd as a parallel platform; it could act as a useful backup for all our outputs should our website go into meltdown. Scribd allowed readers to download our briefs, guides, and grey literature for free. (It has recently started promoting a premium membership scheme that charges readers a monthly fee, but it is still possible to read and download documents for free if you open an account to upload documents.)

It was while exploring Scribd that I thought about replicating their thumbnail and description view on our website, particularly for our briefs and guides. Dru had created what I thought was a flexible and user-friendly format for the publications page, so I asked him to experiment. True to form, he delivered something that was exactly right (see Figures 3 and 4):

Figure 3: A resource page before the change (left), and after (right) with the thumbnails and descriptions.

 Figure 4: Guides before (left) and after (right), including icons to indicate the type of resource.

 

 Year 3

Many of the more fundamental changes were complete by the third year, so I continued to update the content, including revising every project brief and making these available as low-bandwith HTML versions. During this year, the website had over 10k page views, with almost 7.5k unique views. Our most popular pages were the journal articles and the project pages that contained all the rewritten project briefs.

Year 4

I knew that the programme funding was coming to an end this year, so my aim was to make sure that everything was as accessible as possible beyond the end of the programme. This meant converting as many documents as possible to HTML, making the creative commons licensing more prominent, and populating the site with research findings and evidence of uptake, news, resources, and other grey literature. I viewed this year as a chance to consolidate the legacy of the consortium. This meant addressing two specific internal concerns:

1. The COMDIS-HSD acronym was not readily understood.
2. The original logo didn’t actually state that COMDIS-HSD was a health consortium, but the masthead did.

Dru had already changed the background of the website to add more white space, and he suggested extending the white background to the masthead; a simple and effective solution to make the website less ‘top heavy’ that we could implement quickly and easily (see Figure 5). I suggested making some changes to the logo and strapline, which senior management approved, so we hired designers to produce new artwork that met our brief.

Figure 5: The original logo and masthead didn’t explain the COMDIS-HSD acronym (top), but the new ones made it clear (bottom).

At the end of year, at the eleventh hour, our programme secured funding for another 2 years. At that stage, I felt good about where the site was at in terms of its look, feel, and content.

Year 5

The extension brought with it a new set of challenges. Funders like to change things up now and again, and the programme extension came with a new set of indicators to monitor website metrics. This therefore became the year of investing in analytics. We had done basic monitoring before to report against our logframe indicators, but now the funder wanted a lot more detail.

To help capture information about and describe our users a little better, Dru adapted a quick and simple pop-up download form (see Figure 6) that he had designed for our partners Malaria Consortium and integrated this into our website.

 Figure 6: Pop-up form to capture audience information.

He also made our site design responsive to the many sizes and types of devices that people now use to access information.

Year 6 and our end point

The final year, and another stocktake. Social media and related analytics were a big part of our reporting, yet our Twitter presence had remained modest and was not very targeted. With a clear skills gap in our team, I recruited a dedicated digital communications officer. The positive impact was pretty much immediate: there was a dissemination schedule in place, our existing evidence was reaching more targeted groups, our evidence was being shared and commented upon online, our download capture form was helping us to identify our audiences and our most popular resources, and there was much more work on defining the analytics that our funder needed.

The most important development this year came for our partners ARK Foundation. They were ready to redevelop their website completely, and they liked our website. So, after some detailed conversations, we all thought: Why re-invent the wheel? Why not replicate our website for them? And so, that’s what happened, and here it is: https://arkfoundationbd.org/

For the second time in 2 years, I worked on consolidating the legacy of the consortium and on making the content accessible for policymakers, medical staff, implementing organisations, and researchers. As I’d predicted many years before, the site was to be archived by the university, which involved around 6 months of negotiation beforehand (another learning curve).

And then, it all came to an end. As I stated at the start of this article, our overall approach to making research evidence accessible via our website was commended by DFID, which I’m extremely proud of. I learned so much working with Dru and I couldn’t have achieved my vision for the website without his knowledge and expert skills. So, in addition to the top tips above, I would add that a good web developer is worth their weight in gold. I will also add one final top tip:

Top Tip 5: Good communication and understanding between you and your web developer is key.

In Part 2 of this blog (appearing on R2A on Thursday, October 24th), Dru offers some golden advice on what you need to think about when developing your organisation’s website.