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.
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:
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.
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.