Pursuit is a centralised platform for The University of Melbourne to promote their research activities and their impact on the world to a public audience. It was conceived as a way of bringing together the hitherto disparate sources from around the university and to provide a central point for an audience to coalesce around.
The university’s internal web team were tasked to have it ready in four months so it could launch alongside a larger marketing push. And while a series of prototypes of the public-facing aspects of the site had been developed internally, there was still a gaping void between that and a finished platform. We were brought on board to make it happen.
Our role was four-fold:
- Establish and direct the scope and shape of the application as a whole. Balancing the requirements from stakeholders at the university against budgetary and timeline constraints.
- Design and implement a WYSIWYG authoring system that was beautiful, flexible, and usable by inexperienced users.
- Build a technical platform (using Ruby/Rails) that was maintainable by the relatively small development team at the university.
- Coordinate the development effort the teams at Icelab and the university.
The difficult part of development work is not the building, but the building of the right thing. We began with a series of workshops involving the stakeholders and internal team at the university to sketch out their ideas and establish plans for what the platform was meant to achieve. After those sessions we built up set of job stories in Trello that comprehensively described those plans as functional intentions. We wanted to gather as much information as possible about the shape of Pursuit as a long-term property so we could make informed decisions about the initial development priorities while considering future scope. From there we ruthlessly culled the job stories to encompass a set of features that was achievable and still met the primary aims of the platform.
The development process was collaborative and yet mostly remote. We shared a Slack room with the university team to discuss the ongoing development; held weekly Skype meetings to round-up that week’s progress and determine if anything needed to be adjusted; discussed individual job stories in Trello; and used GitHub — issues and pull-requests in particular — to discuss technical implementation. The development process was smoothed by using test-driven development practices, back by a continuous integration server, and alongside Heroku’s review-apps pipeline to allow in-progress development work to be passed onto users for testing at any given time.