You are currently browsing the tag archive for the ‘Drupal’ tag.
As with any project one of the key steps is to plan how you are going to go about your task. So with our library website migration we sat down to work through the stages we will need to go through between setting out the initial objectives, as described in an earlier blog post and the new site being launched. So in this blog post I’m going to cover the stages we are planning to break our website migration project into. Some will be unique to us as they reflect our particular circumstances, but others will be more generic.
We’ve arranged the stages as a series of workpackages covering different themes rather than as a straightforward set of tasks arranged by date. It tends to be a bit easier to work out where you are by grouping the tasks in themes or workpackages. To draw up the plan we’ve been using Excel as a high-level tool. It’s a bit easier for people to look at an Excel version of the plan (using a great Excel 2007 template for gantt charts) rather than having to use MS Project. For project management purposes we’ll use an MS Project version. So the Excel version looks like this:
We’re planning to split the project into workpackages that cover the different themes of the project, so, for example there are workpackages covering the technical preparation of the site environment, activities around reviewing and migrating content, a workpackage covering usability and accessibility testing, and another one around the creation of a mobile version of the website. [I’m still getting used to the idea that the mobile library isn’t a large bus full of books – too many years struggling to get reliable online technology onto them I suppose!].
Workpackage 1 – Site setup
This is covering our site preparation activities, from agreeing the URL, through setting up the test environment, loading the design templates, configuring the site structure and setting up the standard website features. In the main this work is being carried out by our website developer with help from other university colleagues. The bulk of this work happens in the first few months while we are on the development site.
Workpackage 2 – Content
This covers a wide range of tasks from reviewing the Information Architecture, through looking at User requirements, to reviewing the content, documenting new processes and then training staff, and the actual content migration into the new site. There’s a lot of preparation needed so it’s one of the earliest workpackages to start. So we’ve begun with some workshops to look at the current Information Architecture and user requirements. We’ve been looking at results from surveys, from user feedback and at analytics data to inform that work. One of the next steps will be to survey users with some specific questions about the website. This then needs to be pulled together into a prototype Information Architecture that can be tested with users later in the year.
Workpackage 3 – dynamic content and search
Our current website displays some content as lists taken from our library catalogue and other sources. These include lists of databases, ejournals and FAQs. Our analytics data show that these are the most popular elements of the site so we need to retain these in the new site. Generating them dynamically from systems where they are already being updated is much more sensible than having to create a separate static list and then update it. Search is also a very important element of our site, whether that is search of our electronic resources, library catalogue or the website itself.
Workpackage 4 – Help and Support
Analysing our site shows that a large proportion of our content is Help and Support materials such as FAQs, How To guides and other help materials. Finding a way of helping users find relevant help materials more easily on the new site is a key objective for this workpackage.
Workpackage 5 – Mobiles
We’ve had a mobile version of the website for a few years now. It gets a steady stream of users, mainly ipad and iphone but with an increasing number of android phone accesses. As part of this workpackage we are working with other university colleagues to create a new version of the mobile library website.
Workpackage 6 – Testing
Although the plan is very much to test as we go along, we’ve put our testing into a separate workpackage, as much as anything, to make sure it gets the attention it needs. We’re planning our accessibility testing using a range of devices we have such as screenreader software. We also plan usability testing with eye-tracker software to check the prototype site. And we expect to make the site available in ‘beta’ to gain feedback and allow us to address any issues before the final launch.
Alongside the workpackages are the usal activities around project management, reporting on progress, managing risks and issues and communicating to stakeholders/users about progress. As we go through the project I’m going to try to update this blog with thoughts and reflections on how the project is taking shape.
Over the next few months we are planning to redevelop our library website. It’s a long process, there are a lot of different stakeholders and a lot of stages to go through. I’m going to try to blog about the process as we go along to try to keep a record of what we do, how it goes and what lessons we discover as we go through the whole website migration project.
I ‘m going to start with covering why do we want to change the website. What is driving the change?
- Feedback from users – comments from surveys and questionnaires indicate that users don’t find the navigation easy, don’t like the design that much and don’t find it that easy to find relevant help information. They particularly have difficulty with finding access to electronic resources.
- Feedback from staff that they would like different things to be on the homepage to what students want, e.g. services such as book renewals and document delivery, which in our institution is mostly of interest to staff
- We have an increasing range of different types of users (students, academics and researchers for example) and partners who all have a slightly different need from the website. The current website offers a ‘one-size-fits-all’ approach and doesn’t allow users to have a view of it that meets their specific needs or to allow them to customise or personalise it.
- ‘To be where our users are’ – increasingly we are wanting users to access our services directly from where they are (in the VLE, or in Google Apps) rather than by having to come to our website. So we want to facilitate that.
- We want to make more use of dynamic content, which we do to a certain extent already by taking lists of resources from the catalogue and presenting in the website.
- The Information Architecture of the site was designed in 2008 and we want to review it to reflect changes in the way our services have developed.
- We want to update the design of the website to give it a more consistent University style
- The underlying website technology ‘Cold Fusion’ is no longer a preferred website technology for us and we want to develop the site using technology that is more Web 2.0 friendly.
- Library staff working with other University units has thrown up some different ideas about how we might present help and support on the website. This has lead us to thinking about trying to deliver it in a different way – in context, so users get relevant help and support materials prevented in context, rather than being sent to a help page and being expected to search through lists of pages, videos and podcasts.
So our key objectives for the website migration are:
- improved user experience
- easier to navigate
- improved search – [being addressed partially by introducing a new third-party search system from Ebsco]
- personalised – so students get things that are relevant to them, academics get services relevant to them etc
- context-specific help and support – placed wherever you are on the website
- easy to access information about how to contact us to get help
- a cleaner, fresher design
- in a more Web 2.0 friendly development environment that lets us develop new services to keep pace with user needs
- ideally that we can develop services once that can then be deployed to wherever our users are – a type of ‘build once, use many times’ approach
Next time I want to start to look at the approach we are taking and the steps we are planning.