An understanding of the constraints and benefits of different technologies

Within the undergraduate MBChB programme, the student selected component module aims to develop students’ research and data analysis skills, alongside their personal development, through investigating a clinical topic as part of a group and publishing findings within a blog/website interface. As the technical lead on the project I first set out to fully understand the programme’s requirements for the platform (and what wasn’t required) over email and in face-to-face meetings. This allowed me to advise on the use of possible technologies and begin to look at creating efficient workflows, for both administrators and its end users.

Initial discussions amongst the team included the possibility of using either WordPress or PebblePad for the module, so this is where I began my investigations. Both systems were familiar to me and the programme team, who had used them both in previous projects. There was a need however to investigate which platform would provide the best possible solution for the management and delivery of this module; for staff and students. At the time of investigation PebblePad was being piloted within another area of the undergraduate programme, where I had been involved in the training of users. Through discussions with other users of PebblePad from the wider University community, I was made aware of the collaboration tool. Further research of this led me to understand how students could co-own their assets (content) and share the same edit, share and publish permissions, which are all key components of the group task.

After experimenting with the tool, it was clear there would be an onus on the students to complete small setup and administration tasks, which I wasn’t keen on. I voiced concerns over the likelihood of an increase in support required, as it would increase the chances of students experiencing difficulties with additional administration tasks. Student participation should only involve the creation and publishing of their academic content; this is what they are graded on. One of the advantages of WordPress was that the technical and/or academic team could complete all administration tasks, leaving students able to create and publish their content, without having anything else to do.

As a free and widely used blogging tool, that supports users in publishing content, WordPress provides an effective interface that can be administered by the school. Its out of the box functionality for managing a collection of separate websites would mean little in the way of bespoke development and workflows. WordPress was chosen over PebblePad, as clear communications from the programme team indicated they wanted the best possible experience for students; a system that did not require the setup of sharing workflows and allowing them concentrate of the creation of academic content. My previous experience of WordPress was also an influence in using this tool as I knew its constraints, and could advise on where best to make adjustments to fit the specific needs of the school. Members of the school administration team had also communicated positive experiences with the tool in other projects; ensuring minimal training should have been anticipated.

Using WordPress Multisite also meant group websites in future semesters and years could be set-up within the same instance, reducing the effort required before each academic year.

Discussions with the wider University community was a worthwhile activity, as I was able to witness similar examples of group work across different disciplines, some using different technologies to complete similar tasks. This is something I will continue to do in future projects; maintaining relationships with others in the institution in similar roles, allowing me to expand the knowledge and experience pool I can call upon for advice and opinions. Alongside continuing conversations, I’d like to think I could question the community about possible technology fits before starting to look at possible solutions. With this project, there were already two platforms on the table. Going into conversations at an earlier stage with a clear mind may have allowed for a wider range of solutions to be reviewed. Evidence for this communication is provided in the form of a list of technology enhanced learning events attended within the University (See Fig.J).

Technical knowledge and ability in the use of learning technology

Although WordPress ticked all the boxes in terms of what the team needed, it also had additional functionality which was not required. The aim of the module is to create a research experience, and whilst it allows students an opportunity to improve their digital skills publishing content online, they weren’t being graded on making colourful, good looking websites. Once the module was complete and graded, the sites were to be made openly available, for general access and to serve as portfolio items for students. This was a key requirement, and a workflow I created meant this was achievable with minimal clicks.

With my background in web development I am familiar with the programming language that WordPress is built on; PHP. To ensure our instance was fit for purpose I needed to remove a number of tools, and I did this via multiple methods, including creating a child theme and writing a script to hide certain functionality (see Fig. A). Installing additional plugins from the user interface gave the admin team the power to hide functionality to certain user roles within the interface (see Fig. B). Using this mix allowed certain customisation tools to be completely hidden and others to be switched on/off as required. This meant the team could setup sites knowing their consistent naming convention would not be altered when students began adding content. Having knowledge in web design I was able to create a sample site, which gave students an insight to what they could create, with the permissions available to them. The content used in this sample site included instructions for students on how to use the platform, and acted as a user guide to them (see Fig.F).

One useful resource I created included a white list of third party plugins (see Fig.C) on our team wiki. Throughout the first semester, a number of plugins became apparent that improved the administration of the service. As this was the first instance that our team had created (in terms of supporting student blogging), the plugin white list proved invaluable for future projects, I have been able to call on this documented research for other similar projects. Due to the nature of adding third party plugins meant for endless possibilities. Whilst being adaptable to a schools need, it was important that I made them aware not to add additional functionality without contacting myself, or a technical expert first.

Of all the plugins utilised, the one which I intend to use going forward for similar University projects would be the plugin which worked alongside our University EASE login system; HTTP Auth. The ability to link WordPress accounts with those within the University’s infrastructure allowed for seamless logins, and users weren’t required to remember another password for another system. One key practice I took from this was understanding how I could lock down levels of the website, meaning I could control what level the login (and University secure) would be required at, via .htaccess (See Fig.H).

The decision to create a child theme allowed me to make bespoke edits without affecting the core theme, allowing for any future theme updates that may have been available. In similar projects since this, I have since always created a child theme of any chosen theme, to avoid the risk of errors during developments. I have also been keen to reduce the reliance of third party plugins. Whilst they provide quick solutions in most case, they do raise concerns with security and compatibility upgrades going forward. The white list (described above) contains a variety of plugins that improve the administration of the sites, without significantly increasing the levels of support.

As a result of now experiencing the full lifecycle of the module delivery, it has become clear that I could have created a test instance earlier, possibly at the same time as creating the live environment. This would have allowed me to test possible updates and inclusions within a safe setting. I created a test instance towards the midpoint of the module when issues arose surrounding word count calculations. Many students were creating content within Microsoft Word and pasting it into their sites, only to find a reduced word count. Whilst the decision was taken to make students aware which system’s calculations would be considered the standard, I could have reacted and investigated this in a more efficient manner had their been another instance available to test on.

The benefits of using this platform for students were that it provided:

• A password protected group area to publish content (both private and open)
• A dedicated link to their group research content, for portfolio purposes
• An opportunity to improve digital skills

The benefits of using this platform for the school were:

• Ownership of the administration of groups and users (unavailable in previous system)
  • Allowing external NHS staff access to private areas, who may not have a University account
  • Single sign-on was also made available for University staff and students
• A scalable platform that could accommodate hundreds of group sites
• Minimal training required; staff were given training and user guides, whilst students were given a sample site which included instructions on how to create pages, posts etc.
• Professional output of websites using a tailored template

Supporting the deployment of learning technologies.

In terms of supporting users, the sample site for students contained a selection of key step-by-step guides required in creating pages and content within their group sites. I created a further user guide (link provided in evidence below) including visual step-by-step guides aimed the programme staff who would be administering the platform throughout the year. It was hoped that this would cover the majority, if not all support and administrative tasks related to the module. The WordPress platform is included in the overall school support package for any technology enhanced learning services. All stakeholders were aware of the processes to take should additional support be required. This process involves emailing our main support email address, which I currently administer. Whilst this was believed to be enough, I have recommended that in future projects there is a face-to-face, or online session with a technical and/or support staff member to walkthrough the documented user guide with the administrators. As a result of the full module lifecycle there were no support issues reported from students, and overall feedback for the platform (over the previous) was very good (See Fig.G). A high number of general administrative support calls were received from the programme team, which surprised me (see Fig. E). At the beginning of the project I was led to believe the school had the knowledge of the WordPress dashboard management within the team. I feel with an improved training provision, to include face-to-face training at either the beginning of the module or at the midpoint, or both, that these calls will have been vastly reduced, and increased the knowledge within the school. One alternative approach which I have witnessed elsewhere would be to train a ‘champion’ of WordPress within the team, allowing them to act as a triage before passing on any technical issues they cannot solve.

Evidence

Admin User Guide- SSC & Reproductive Systems Student Blogs in WordPress