Digital Marketing & Communications

We've seen 1s and 0s you wouldn't believe

Digital team sprint notes 26 January - 8 February

📥  Sprint notes

February has seen the plague sweep through Digital towers, but we soldier on!

What we did

  • Extended the character limit on titles (and updated guidance about doing this).
  • Allowed visitors to filter the lists of content its owning organisation.
  • Changed how we display the list of available content types from landing pages.
  • Made the content type label on each item link through to the filtered list for that type.
  • Worked with colleagues at the University of Bristol to arrange testing of our information hierarchy.
  • Created a beta of the backend of our UG Prospectus application (the frontend was waylaid by all our designers being ill!).
  • Ran beta CMS training for some new staff.
  • Created templates in MS Word to allow us to collaborate with infrequent contributors to bath.ac.uk
  • Audited the popular news items on the current bath.ac.uk

What we will do

  • Contact the universities of Exeter and Cardiff (as part of the GW4 Group) to arrange more testing.
  • Ensure that we are listing all content items on our filtered lists.
  • Turn the owning Organisation or Group displayed at the top of each content item into a link to the relevant filtered list.
  • Stop Google indexing the beta for a little while.
  • Unpublish most of what we've published so far in order to prepare for a real site to go live!
  • Review all of the Student Services content in the beta in order to put it into acceptance testing before it goes live.
  • Prototype some course discovery tools.
  • Audit the events on www.bath.ac.uk
  • Transition our content design guidance to the beta CMS.

 

What tech we use to test our CMS: Minitest and Capybara

📥  Development, Tools

tumblr_lmht06jDfG1qhed3yo1_500

The road less travelled

For the Editor side of our new CMS, we have made a couple of choices in testing that are a little bit off the beaten track.

For starters we are using Minitest instead of RSpec. Most Rails devs will pick RSpec as that's what comes out of the box. And Rails devs who have been around for a few years are already familiar with RSpec.

tumblr_mg57quMO7h1qj8u1do1_540

You say shoulda, we say assert

We favoured Minitest because of the low barrier to entry it provided us. As a dev house that had mostly written apps in Java in the past, we're already comfortable with unit tests. We're also already familiar with the assertion style. We felt that as a new DSL to learn it's a much smaller and easier set to absorb than compared to RSpec.

On top of that we're using Capybara to run functional tests. This is yet another DSL to learn. We could've overwhelmed ourselves with DSLs! This is again written in Minitest assertions.

This is not without any downsides.

With RSpec and specs being the most common approach, examples and documentation are almost all written in that way. So we still have to negotiate the nuances of spec tests when reading examples. But because we're still unfamiliar to spec tests they're slightly impenetrable. On balance we've lowered the barrier to adoption and got to shipping code quicker. We were already on a learning curve with Rails itself so the early win was worth it.

The wider picture

With our stack we have 2 discrete services, glued together by Redis. Our current problem is that we only have tests for the CMS Editor and not the end to end publishing process. We do have some unit tests on the CMS Publisher middle layer. This is the bit that receives data from the CMS Editor (via Redis) on publish (or preview) and calls Hugo to render out our pages as static HTML. What we want is a way to test the functionality from the point of creating a new piece of content all the way to rendering it out as a final piece of HTML. Currently the impact to the front end from changes we make on the CMS Editor (for example) are obscured from us.

What we'd like to do is make use of something like Docker and auto deploy all the apps via our CI server Bamboo. We'd then have an end to end containerised system we could run full functional tests against. We'd also end up with the front end outputs which we could run regressions tests on.

This is all stuff we plan for the future. Hopefully the next time I post we'll have achieved some of that!

 

Digital team sprint notes, 5 - 25 January

📥  Sprint notes

This was an extra-special three-week sprint to get our timings back in line with some of our other meetings, and it means we got some bonus work done!

What we did

  • Fixed several publishing and preview bugs.
  • Changed the position of the "Supporting information" section on the Campaign content type.
  • Removed the 'subject' field from the Case Study content type.
  • Allowed publishers to filter content in the CMS by its owning Organisation.
  • Contributors can no longer change the owning or Associated Organisations or Groups of a content item.
  • Established a set of design benchmarks using the most popular combinations of browser version, resolutions and operating systems which our visitors use.
  • Designed the styles for the links at the top of each content item.
  • Reallocated all of the Organisation Landing Pages to the correct Organisations.
  • Resolved 152 tickets in our support queue, 98.4% of which were resolved with the first reply.
  • Moved all of our podcasts into the University's official Soundcloud channel and wrote guidance on how to manage this.
  • Reviewed the usage of person profiles in the beta and on competitor sites.
  • Analysed existing news stories to see which should be transitioned into the beta.
  • Updated some of our content guidance and CMS usage instructions.

What we will do

  • Turn the owning Organisation and content type at the top of each content item into links to the relevant places.
  • Enable lists of content items to be filterable by owning Organisation or Group.
  • Begin a series of regular user tests.
  • Deliver a beta of our UG Prospectus application.
  • Begin a three-month trial of desk.com to manage our support helpdesk.

 

Who can do what, and where

📥  Beta

We now have over 100 people using the new CMS, drawn from 48 organisations and 28 groups. We also recently crossed the threshold of 1,000 content items in the CMS (woohoo!) And aside from organisations, all those numbers are bound to go up.

How do we make sure that users:

  • see only the content that's relevant to them, rather than every single thing in the CMS?
  • can edit only the content their organisation or group is actually responsible for?
  • can feature only the most relevant content on their landing pages?

The answer comes down to permissions – both for users, and the organisations or groups they belong to.

(more…)

 

How we implemented file uploading in our CMS

📥  CMS, Development

"dude-wheres-my-file

The setup

We have built into our CMS the ability to attach files to our Publication content type. Here I'll go cover the steps and hurdles we went through in implementing this very common feature.

On our first pass we took the often sensible approach of keeping scope small. We decided to build the ability to attach one file. Then we would iterate towards multiple attachments in later sprints.

Our first decision early on was to pick Thoughtbot's Paperclip library to help us implement this feature. Thoughtbot have a strong reputation among the Ruby community and we admire their approach of keeping things simple.

As part of our first iteration we had to do a ton of work around infrastructure set up too.

  • we needed dedicated network file storage for:
    • staging
    • training
    • and production
  • plumb in these file mounts to the CMS Editor so that we can show the file back to the user
  • changed our Mina deploy scripts to add an alias into RAILS_ROOT/public
  • and then copy the file on publish to the web server along with our HTML static page outputs

Simple!

The twist

After we shipped this first iteration we discovered a bug. Once you uploaded a file and hit save, if you encountered a Rails validation error you would lose your new attachment. So you'd fix your validation error but you wouldn't know that you had to upload that file again. This was especially bad if you were editing to change the attached file. If you had to fix other changes, you wouldn't realise that the attachment reverts to the original.

Twisting further

But Paperclip can handle this right? Wrong! It's a known bug (since 2009) that they won't fix! The most commonly suggested fix to this bug is to re-implement with an alternative library called CarrierWave.

A developer having a bit of a rage

Rage!

Act two: So CarrierWave...

...fixed this bug. It involved a rewrite of the code, but at least we could re-use all the infrastructure we'd set up. Next up, multiple attachments!

Another twist!

Our first attempt at implementing multiple attachments brought back the bug...

A developer having another rage

Double...

A developer having even more rage

...rage!

The final act

This time CarrierWave wasn't caching the attachment because we had applied it on the parent object in our polymorphic model. The fix was to re-do the code (again). Thankfully this time not as drastically as before. We are still using CarrierWave after all. We simply (!) applied CarrierWave to the Publication object itself rather than to its parent.

This model is closer to what we started with in our first implementation as well.

So now it's all simpler.

Still...

Despite all the hardship I was reminded that 10 years ago when we built the LMF we had to support file uploading. In that time we had to do a lot more of the work ourselves. Even though we had things like Apache Commons' IO library, all that gave us was binary streams and we still needed to write code to handle output to disk. That all took much, much longer than this rollercoaster attempt we made in Rails many years later. It's been an interesting contrast.

 

Digital team sprint notes, 8 - 23 December

📥  Sprint notes

A slightly longer sprint in the lead-up to Christmas and here's what happened:

What we did

  • Provided preview functionality in the new CMS.
  • Implemented content type strata on organisation and group landing pages.
  • Changed 'Able' to 'Available to supervise research degree projects' on Person Profiles.
  • Restricted access to your items in the CMS to just publishers in your organisation or group.
  • Created a prototype of the Beta homepage for testing with users.
  • Created a new 404 page for the new site.
  • Fixed a bug with page deletion.
  • Updated the lead publisher guidance for several content types.
  • Reviewed six sections which have been transitioned into the new CMS.
  • Supported the Winter Graduation ceremonies.
  • Said goodbye to Ross!

What we will do (5 - 18 January)

  • Fix some bugs in the publishing and previewing workflow.
  • Provide filterable lists across all content types.
  • Allow publishers to filter the list of content items in the CMS by Organisation.
  • Add a new section to landing pages to display specially curated content items.
  • Make sure that all landing pages are allocated to the correct Organisation or Group.
  • Document our standards for testing UI on different devices and configurations.
  • Review the next four transitioned sections.
  • Discover some inventory and usage details for our podcasts.

 

The design function Christmas wishlist 2015

📥  Design, Tools

After a busy year, the onset of Christmas always provides a brief moment to step back and reflect upon everything that has happened over the last 12 months.

2015 has been our year for honing workflows, trying out new tools and technologies, and shipping, shipping, shipping.

This intensive regimen has left us shouting "This is great!" almost as much as "Why can't you just work, dammit!" Here are the top five things the Digital team design function would really like to find under our Xmas tree to make us feel all happy and fuzzy.

5. A GUI Git client with interactive rebasing

42 un-squashed commits in that PR? You have fun with that…

My chosen Git tool - Tower - lacks the functionality to make interactive rebases. This means I end up having to drop into the command line to squash commits for my PRs and that’s just asking for trouble.

Please Santa, can we have a well-designed, feature-rich Git GUI client with interactive rebasing for Xmas?

4. sudo vagrant ‘please just work’

Vagrant has been a real boon allowing us to run up an exact copy of our publisher and editor apps on our local machines. However it can be a bit of a nightmare to manage if you don’t lean towards the technical side of things.

Please Santa, can we have a better way of managing/configuring Vagrant boxes that doesn’t mean I have to know what my $path is?

3. Web fonts that work everywhere

As a design team we’ve really gone hell for leather with regards to our implementation of web fonts this year. Although we’re very proud of what we’ve achieved, it has been hard work tackling cross-browser rendering issues, OpenType hassles, caching and pre-loading, font verification and much, much more.

Please Santa, can we have a standardised web font format that works perfectly on EVERY browser and platform?

2. A version of Sketch with the line-height bug fixed

We’ve pushed almost all of our preliminary design work through Bohemian Coding’s Sketch over the last 12 months. I've been working with Sketch since the heady days of version 1.0 but the software was completely new to Liam. Although he could see the benefits of the stripped-back interface and laser focus on interface design, he was constantly infuriated by Sketch’s little ‘eccentricities’ and general bugginess.

Please Santa, can we have a version of Sketch that’s stable, reliable and fixes that awful line-height bug once and for all?

1. Project Comet to hurry the heck up

Adobe’s last great hope? Maybe that’s a bit dramatic, but Project Comet is looking like a genuinely interesting contender in the race to grab the interface design crown.

Please Santa, Comet looks better than anything Adobe has made in ages. Can you get them to speed it up a bit? (Or at least get us on the Beta.)

Have a very merry Christmas and a happy new year! May all your workflow wishes come true!

 

End note - Keep being ambitious Bath

📥  Team

On December 17th I will be saying goodbye to the University of Bath.

My move obviously creates a number of changes in the Digital team. But the central message is one of continuity. Improving digital communication remains a priority for the University, and the central team has the expertise to deliver on that goal. Leadership of the team and its projects will be provided by Phil and Rich, who are stepping up to head the team as an already proven partnership.

This is my opportunity to say a massive thank you to Bath Digital team - you are awesome and there is much to be proud of in terms of achievements. (more…)

 

Digital team sprint notes, 24 November - 7 December 2015

📥  Sprint notes

What we did

  • Supported transitions of Academic Skills Centre and the Library.
  • Made it clearer on Person Profiles when an academic is able to supervise research degree projects.
  • Restricted access to your items in the CMS to just publishers in your department or group.
  • Created a prototype of the Beta homepage for testing with users.
  • Prepared to support the Winter Graduation ceremonies.
  • Published 2016 Entry UG and PG fee updates.
  • Received 6 new content maintenance requests and resolved 13.

What we will do (8 - 21 December 2015)

  • Provide preview functionality in the new CMS.
  • Extend character limits on content titles.
  • Implement content type strata on department and group landing pages.
  • Implement basic filtering on content type index pages.
  • Implement filtering of content in the CMS.
  • Support Winter Graduation ceremonies.
  • Hold a One Day Upgrade session.
  • Have a Christmas party!

 

Digital roadmap update for December 2015

📥  Roadmap

Version 16 of our Digital Roadmap looks ahead from December 2015.

Progress made in November 2015

  • New functionality and design features were added to the new CMS and site in preparation for launch
  • New ‘mobile first’ course information and search pages were prototyped and tested with users
  • A prototype of the Worldwide section of bath.ac.uk was deployed to beta.bath.ac.uk/collections/worldwide
  • Discovery research was carried out on requirements for forms on bath.ac.uk
  • Widening Participation, Finance and HR carried out the first steps of transition to new CMS
  • A first iteration of the new UG recruitment marketing plan was produced

Priorities planned for December 2015

  • Decommission old PHP applications
  • Support next group of lead publishers in uploading and creating new content in the CMS
  • Release the first sections of the Beta into the public domain
  • Run discovery research around requirements for a course finder tool
  • Produce the next iteration of the undergraduate content marketing plan
  • Create a register of official social media accounts, their managers and their purpose
  • Use Funnelback usage data to improve site search results in preparation for the launch of the Beta

Next update

University staff and students can find the detailed version of the Digital Roadmap on the wiki via go.bath.ac.uk/digital-roadmap.

The next version of the Digital Roadmap will be Version 17 and is scheduled for release w/c 11 January 2016.