Digital Marketing & Communications

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

Topic: Development

Using Rails

📥  Development

After ten years of Java and PHP, the Digital team have started writing all new applications, including our new CMS, in Ruby on Rails.

There are two reasons why now is a good time for us to do this. The first is that Rails is considered old hat, which means that it's now a tried and tested platform. The other is that improvements in our server virtualisation infrastructure mean that we no longer need to wait for Ruby packages to be available for our Solaris servers, because we can create new Linux servers as and when we need them. Solaris was a big blocker because the most recent Ruby package for Solaris is 1.8.7, which was released all the way back in 2008.

We are happy with our Java and PHP applications, and won't be looking to rewrite those in the near-term. We will continue to write applications in those languages where appropriate but are convinced that the Ruby community has shown itself to be strongly united behind Rails, making updates and community support much better than it is for the many competing Java and PHP frameworks.

Rails isn't perfect. It has regular security vulnerability announcements and then, assuming the patch is simple, we need to schedule the downtime to patch our applications. We have a channel in Slack which is subscribed to the rubyonrails-security mailing list and so we find out about new vulnerabilities quickly.

We're not currently planning on hosting public-facing applications with Rails, keeping them for internally-facing applications like the CMS editor. This will give us time to understand how to scale up our servers and applications appropriately and, since the CMS creates static HTML files it means we will be able to leave our powerful webservers doing the job they're already optimised for.

There's been a lot of learning involved in going from a blank-slate to a production-ready Rails application, and there'll be more to come, but we're happy with Rails and confident that it will serve us well in the coming years.

 

Our Github workflow

📥  Development

We are only 10 months into adopting Github Enterprise for our version control system and have many things still to learn. Near the start of that period we needed a workflow for managing the contributions that our team of devs, designers and editors make to our projects.

We decided to have a look at what was out there first and adapt something to our needs, taking into consideration our relative inexperience with Git in general.

Pick one

This helpful guide by Atlassian to some workflows was good at giving us an intial overview. We were able to discount the various workflows for either being to complicated for us (Gitflow) or too basic (Forking workflow).

We looked at the Github Workflow as well and found it suitable for our level of experience and how we wanted to work.

Change it

There are a couple of minor things we do differently though in our team. First of all we don't work against a branch called master.

What we have instead are staging and production branches. These reflect our platforms that we deploy to. staging is actually the default branch of all our project repos.

We always branch from staging to work on our features. Our Pull Requests are for merging back into staging. We then merge into production from staging. This last bit is still a bit clunky as we have to issue another PR for that merge.

Push it

Salt n Peppa - Push It

 

The staging branch for a project deploys automatically. Changes to repos send triggers from Github to Bamboo (using the built in Bamboo Service Hook) to run build and deploy plans. For production we'd rather have control over when this happens. So while builds are still automatic for production, we manually trigger deployments at the push of a button.

We are using mina to push our apps to our servers, executed by Bamboo. Bamboo has an official Ruby plugin which we are using. This includes running Bundler tasks.

More polish?

What we have so far is a little bit rough still on some edges (the PR to production for example), but overall we are finding that this workflow model is working well.

This is not to say that as we gain more experience we won't revisit the various models of workflow in the future.

 

Alpha site release notes, 12 - 19 January

📥  Beta, Communication, Development, Style, content and design

On Monday 12 January, we launched an alpha version of our site to internal users, including a new external homepage and the about section, which is controlled by our new CMS alpha. Collectively we've been referring to these as the Alpha site.

The Alpha site is still a work in progress, and we're testing it with our internal users now because your feedback will help to shape its development. We want to see how you use it, whether it meets your needs as a user, and what problems you encounter — so we can fix them before they wreak havoc on a larger audience.

What we did this week

We've had a lot of useful feedback from our users already, and we've fixed some of the issues you've raised, as well as continuing to tackle pre-planned work from the Alpha backlog.

  • Fixed issues that meant some maps were difficult to find or unavailable, including updating redirects from old URLs and changing which page included the map links.
  • The homepage is now served statically, which will lead to performance improvements and better stability if the CMS is unavailable.
  • Improved how the lead image on the homepage displays on smaller screens. A much larger proportion of the image is now visible and editors can select the alignment for how the image is cropped.
Screencap of the homepage Alpha.

Image cropping on small screens before.

Screencap of the homepage Alpha.

Image cropping on small screens after.

  • Worked on a first iteration of an editorial calendar for the homepage to ensure it's frequently updated with interesting, relevant content.
  • Replaced the National Student Survey graphic in the homepage footer with a better-looking SVG version.
  • Standardised design elements in the header and search bar across the Alpha site.
  • Reordered the link lists on the about landing page so it now leads with our mission and values.
  • Changed the wording that links to location pages on team overview pages from "The team is located in [location page]." to the more flexible "Find out more about this team's location in [location page]."

Keep it coming

Please continue to share your feedback with us. Your feedback is most helpful when it's specific - let us know what task you wanted to accomplish on the website and what stopped you, and we'll look into how we can fix it.

 

Building alpha.bath.ac.uk

📥  Beta, CMS, Development, Tools

We've changed just about everything to do with how we manage bath.ac.uk for the alpha, and this includes the underlying technology.

The live www.bath.ac.uk is hosted dynamically from a monolithic Java-based CMS (OpenCms) running on Solaris servers with Oracle as a back-end database and all the code is in Subversion.

The alpha site is being served from static HTML files generated by Hugo. The inputs are provided by multiple Ruby on Rails apps running on Linux servers using MySQL, MongoDB and an off-site service for data storage, and all the code is in our local GitHub Enterprise installation and is deployed from Bamboo by Mina.

The difference could not really be much bigger! It's certainly been a challenge to get up to speed with so many new things all at once but we think that this stack, or some version of it - that's what alphas are for! - should be more future-friendly than our existing infrastructure.

We'll go into more detail on how we're using each piece of technology in the following days and weeks.

Show & Tell, November 21 2014

📥  Communication, Design, Development, Show & Tell

Back in our spiritual home after the impromtu reshuffle that made our last Show & Tell session so special, we had a full roster of presenters and a diverse range of topics.

Ruby Idioms - Kelvin

Our developers are working more and more with Ruby — Rails in particular — and Kelvin has been challenged with providing instruction and direction to the team on the subtleties of how we should write Ruby differently from Java and PHP (other previous go-to production languages).

Far too much to cover in five minutes, we instead had a whistle-stop tour of the top ten seven things to be aware of, from not using unless statements with an else block, to replacing do...end blocks with curly braces if they are a single line.

A full rundown can be found in Kelv's github repo: https://github.bath.ac.uk/mnskchg/ruby_idioms_show_and_tell.

Less stuff - Dan

Still with me? Excellent. Next up was Dan, who talked us through taking a pragmatic approach to webfonts to provide a better user experience. A large part of the work was reducing the filesize of the font manifest file by 66% - theoretically providing a significantly improved loading time for those viewing the website on slow internet connections. The key was looking at the different weights of font being served by default, and making careful design choices that allowed us to provide maximum clarity and aesthetic with the minimum variety of styles and weights.

Dan then went on to propose a manifesto of using less as a starting point for design - tying in aspects of user-centered design, progressive enhancement, the mobile-first approach, and our existing delivery principles.

What do I do? - Katrina

Six months into her new post as Research Marketing Manager, guest speaker Katrina gave us the lowdown on what her job entails. It turns out that a fair amount of it is commercially sensitive, so I'll be skipping over that - no secrets for you.

Katrina spends a large amount of her time planning and coordinating large-scale campaigns to cement relations with University stakeholders. Currently we are tapping into the large amount of water-themed research that our academics are involved in and Katrina is putting the finishing touches to a six-month campaign relating to this.

When not devising ways to get our research the recognition it deserves, Katrina acts as a single point of contact between our academics and the various marketing teams that exist on campus at all different levels - from research teams, through departmental and faculty right up to the University Marketing and Comms. This aspect of her role has been extremely well-received on campus, as busy professors delight in having one single consistent person to deal with concerning their marketing.

The tale of BrowserStack - Tom

Continuing his series of talks concerning security, Tom Natt used the real world example of the recent attack on BrowserStack to illustrate what can happen when things go wrong.

Essentially, BrowserStack had an old computer that nobody used or maintained but was still connected to their network. A hacker discovered this and used the Shellshock vulnerability to take control and gain access to the API key for their AWS (Amazon Web Storage). From this they discovered the database password and attempted to download their entire customer database. This was when BrowserStack became aware of the hack and acted quickly to shut them down. It is still reckoned that 1% (approximately 5000 users) of the database was compromised.

We were about to use BrowserStack to assist us with some work, so this attack and the way that BrowserStack handled it (in terms of securing their system and managing their public profile) went a long way to reassuring us that they were still a suitable partner. Tom also made the point that having just been hacked, they were likely to be awake to the danger right now because of their recent experiences.

Alpha update - Ross

Our the last seven weeks the team has been working on several alphas (CMS, homepage, events, prospectus) and these have all been presented to members of our Digital Steering Group - which is comprised of almost all of our pro-vice-chancellors as well as the movers and shakers in senior management. The feedback has been overwhelmingly positive, with very enthusiastic engagement with aspects of the homepage and the CMS in particular (our most 'mature' alphas). Our plan was always to get the new homepage and areas of the site controlled by the new CMS in front of staff and students as soon as possible, and with the full support of the DSG, we are looking to do this in December.

 

Show & Tell, October 24 2014

📥  CMS, Design, Development, Show & Tell

We celebrated 11 months of Show & Tell last week with another Show & Tell. On the agenda this week: editorial calendars, rebasing, analytics and some exciting new alphas.

Flow - Charlotte

Last month, Rhian talked about how she and Charlotte had searched for an editorial calendar tool that did everything they needed, but didn't come packed with superfluous features. After initially turning to Google Spreadsheets, they've now spent two weeks trialling Flow, and Charlotte updated us on their first impressions.

They particularly liked how Flow offers:

  • a clear calendar view, with the option to drill down into the details
  • quick scheduling and tagging of items
  • dragging and dropping items between dates
  • the option to look at individual calendars, or an overview of everything.

Overall, we like Flow and we might use it for more editorial calendars in the future.

Ace of Rebase - Tom N

We've been using GitHub more and more for our version control. Mostly this has been a happy and prosperous time, but one aspect of Git has been repeatedly responsible for screams of horror in the office: rebasing. To provide some context for the screams, Tom talked us through what rebasing is, why you should do it and what can go wrong.

Git allows multiple people to work on a project simultaneously and engage in jolly cooperation. One master copy of the project exists, with everyone working on different features in their own individual branches, which are copied from the master. You can then merge these branches back into the master copy and combine everyone's work.

But what if other people have merged their branches into the master copy before you? Your branch is now out of date. You may know the feature you've been working on will still play nice with the new master, but if you try to merge it back in normally, you might overwrite work that people have done since.

This is where rebasing comes in. Essentially you need to change history and pretend your branch started with the current master, not the one you actually started with several versions ago. You can then add your work to the project without wiping out anything else that's been done since you started it.

Boromir: "One does not simply Git rebase it!"

Boromir, who destroyed the fellowship of the sprint team after overwriting the repository.

Rebasing is fiddly stuff - when it's done right, it's great, but get it wrong and you could lose a lot of work on a project. Tom's top tip for avoiding extreme pain and suffering was to use interactive mode when you rebase, or everything goes boom.

bath.ac.uk analysis - Takashi

Are we putting the right amount of effort into the right places? Takashi recently did a top level analysis of bath.ac.uk to compare the size of our various sections with how much attention they get from our users. He presented his findings, which included:

  • our study section gets the most traffic
  • the Computing Services section is our biggest in terms of size and number of files
  • many CMS users have edited less than ten pages in the last six months, but some have edited over 500
  • the rate of users accessing bath.ac.uk from Google is rising, while traffic from Facebook is dropping
  • visits from social media tend to be shorter and less engaging.

Takashi also wowed the room with some good-looking treemaps and fielded some questions about his information visualisation secrets (Google Spreadsheets).

Prospectus alpha - Rhian and Liam

Rhian, Liam and Tom T have spent several weeks working on a new app to collect and update the information in our prospectus.

We want our prospective students to get a consistent experience, so we need to integrate the content we put on the web and print versions of our prospectus.

Rhian and Liam gave us a demo of the shiny new Ruby app and showed us how adding a new course would work. User testing has already given the team some very useful feedback, so they'll be testing it with more of the app's future users as they continue to work on it.

Future iterations will tackle workflow and version control, and we hope the new app will be an improvement for the people who create the prospectus and the people who read it.

CMS alpha - Dan

The CMS alpha is the biggest project we're working on at the moment, and Dan's been handling the user interface (UI) for the editing app.

The UI for the CMS needs to be:

  • clear
  • concise
  • consistent
  • accessible.

After setting out these requirements, Dan gave us all a demo of the UI he's been working on and showed us what editing different content types will look like.

Ros from Monsters Inc with "FORMS" in big letters

Sometimes you've just gotta have them.

The new UI looks much more straightforward and user-friendly than our current CMS, and it also confirms to Level AA of the Web Content Accessibility Standards.

Work on the alpha continues this week. If you want to find out more, have a look at Ross's blog post about our plans for the CMS.

We are changing the University of Bath CMS

  , ,

📥  Beta, CMS, Development

We are changing the content management system (CMS) that is used to update www.bath.ac.uk. This is a significant development in the University of Bath’s efforts to deliver world-class digital communications. The new CMS is currently at prototype stage and will go live in early 2015.

The importance of digital publishing

Groups across the University depend on our website in some measure for engagement, marketing or delivery of services. As a result, they also depend on the CMS being fit for purpose.

There are around 13,000 HTML files managed through the bath.ac.uk CMS. These have been produced by the 325 members of University staff who have a CMS account. Over 50% of these publishers have used the CMS in the past 6 months. Of the ‘active’ users, around 25 make use of the CMS on a daily basis.

The Digital team follows trends in digital publishing and, based on the example of other large institution websites, it's clear that we should be getting more from our CMS. More importantly, our publishers - both regular and irregular - have told us through their support requests and in person that they are frustrated by the limitations of the current CMS.

Making a CMS fit for our purposes

We want to make our website more interesting and useful, and to help us do that we need to make publishing to that website quicker and easier. By making the CMS less onerous to use, publishers will have more time to concentrate on quality creation and curation of content.

An obvious question is, which CMS will we use? But the more important question is, what do we need the CMS to do? What features will it have?

Based on our analysis of publisher needs at the University, the core feature set of the new CMS will include:

  • dashboard-based interface to make it easier to find and manage content
  • structured content templates making publishing choices more straightforward and pages quicker to create
  • markdown and a compact WYSIWYG will replace HTML to simplify formatting
  • category tags to knit content together
  • clearly defined publisher roles and permissions
  • access to the CMS without classroom-based training
  • direct access to content performance data to inform editorial decision-making about what to publish and when.

These ‘starting features’ and those that follow on from them will be sequenced on a CMS product backlog (a webpage containing prioritised cards on which each feature is represented). Publishers will be able to subscribe to the board and keep track of the progress of feature developments they are particularly interested in.

Starting with an alpha

Setting up a new CMS and transitioning all our publishers and content across to is a complex undertaking. So we have to start small-scale and develop the capabilities of the CMS on an iterative basis.

It all starts with an alpha phase. The objective of the alpha exercise is to build a working prototype of the CMS. This will be used to test our approach and help us understand what it will take to deliver the CMS on the scale that’s needed to support our entire university website.

The development of the CMS alpha is underway. In November 2014 we will start using it to manage the content in bath.ac.uk/about. In January 2015 we will report on the results. Between then and now, we will be running regular demos and user research workshops with publishers around the University (details of which will follow).

Digital team member doing a demo of the CMS

Prototyping the publishing interface for the CMS alpha

Putting users first

From February 2015 we will take the learning from the alpha and begin rolling out a beta phase of the new CMS and the process of moving our publishing activity to this new platform. It will take a significant effort but the rewards will be worth it.

Let us be clear, better digital publishing will not be achieved by changing our software alone. Nevertheless, a simplified application will make publishing and editing quicker, help improve content quality and make our site more useful and engaging for the millions of people who use it each year.

Monitoring and alerting

📥  Communication, Development, Tools

Almost all of the services the University provides are run on servers based on campus and which are managed by the Computing Services department.

Although many of these servers are now virtual, we're not yet at the point where the failure of one server prompts another to be automatically created to replace it, or where it is easy to do that replacement by hand at short notice.

This means that we sometimes have unplanned downtime.

Five months ago we expanded our usage of the off-site monitoring system Pingdom to check not just the availability of our homepage but also nine of our most popular pages and services.

It checks the web addresses of those pages and services every five minutes (or every minute in the case of www.bath.ac.uk) and if it detects a problem it emails our support desk and sends me a text message.

When we've found out what the problem is, we put a brief explanation up on our web status Tumblr and again when the problem is resolved. This supplements the information published by Computing Services on their Twitter feed but also allows us to provide more specific information when we need to.

This is early days in exposing our service availability, and we'd like to get to a point where we can summarise recent data in a way similar to GitHub's status page but we probably need a bit more research on what our users would like to see first. There's also lots more fundamental work we can do in ensuring that visitors to our services don't simply get a 404 or blank screen when something isn't available!

So, what information do you think we should be making available, and how should we be doing it?

Update: I forgot to mention that Pingdom lets us make our service availability public, and you can browse that data in detail.

 

A more accessible landing page for staff

📥  Design, Development

In a large organisation such as ours the range of input and navigation methods covers a wide spectrum ranging from mouse/pointer and touch screens to screen readers and voice recognition. We have a duty to ensure all users can access our information no matter how they navigate the site. Our delivery principles reinforce our commitment to put users needs first and foremost.

I've just completed a sprint to resolve a number of accessibility issues on our internal staff landing page - a high traffic page used by university staff on a daily basis. Some of our colleagues had raised issues regarding their ability to efficiently navigate the multi-tiered menu that provides access to key online tools and services for staff.

University of Bath staff page

Some visitors to the staff landing page had problems whilst accessing submenus

The issues

  • Accessing the Javascript-powered flyout submenus was at best erratic and at worst completely impossible using only keyboard input
  • Contextual feedback for assistive technologies was absent. Users unable to see the visual indicators were not aware the links had related submenus
  • 'Clickable' links were not explicitly declared as such
  • Some links were only used as 'hooks' for the Javascript functionality. These links were navigational dead ends for users unable to access the submenus

Our solutions

  • Increased the 'touchable' link area to encompass the image and the title. A small win for touchscreen device users 🙂
  • Added relevant ARIA roles via HTML and Javascript. These provide additional information to visitors using assistive technologies regarding the role and status of elements on the page
  • Rewrote the Javascript functionality to ensure the menu is fully navigable via keyboard

But does it work for everyone?

Not quite yet. But we are working on it…

Although these changes are a positive step towards unlocking our content for all our users the solutions implemented above only really deal with those who navigate via keyboard, mouse or touch.

We're now actively looking at ways to give our users with voice recognition software the best possible experience on the University of Bath website. Simplifying navigation options and avoiding jargon will go a long way to helping those using only their voice to get around.

 

A Week With The Digital Team

📥  Communication, Development

Hi,

I'm Rob, an A-level work experience student who was fortunate enough to be given the opportunity to join the digital team last week.

The past week has been a great experience, after being introduced to the self proclaimed king of the nerds and the rest of the team it was straight to work with Tom on the development of a replacement application for the old go.bath URL shortening service which is the first Padrino application to be shipped by the team.

Ship It

It was a great week working with the team, and I am very grateful for the skills that they have helped me to develop; from working amongst them in the twice weekly coding-practice sessions, to the weekly show and tell presentations and also being a part of the agile development practices.

Thank you very much for having me!

Thank You