The main public outcome of the Bebop project is the BuddyPress plugin, which allows a BuddyPress user to import resources (slides, images, video, etc.) hosted on third-party websites (Slideshare, Flickr, YouTube, etc.). The plugin has two homes:
If you run a WordPress/BuddyPress site, you can install Bebop from the Plugins panel in your site Administration area. Bebop works on both standalone and network/multisite installs of WordPress. Of course, you must have BuddyPress installed on the site, too.
Developers may be interested in extending Bebop as a flexible, general purpose social media aggregator. Documentation is provided on how to create new Bebop extensions for additional resource providers.
Our partner on the Bebop project was Boone Gorges, lead developer on the CUNY Academic Commons project and committing BuddyPress developer. We were keen to involve the Academic Commons project in Bebop due to their in-depth knowledge of BuddyPress and great success in using it within a university. Boone offered extrememely valuable review and guidance to Dale McKeown, the main developer working on Bebop. Prior to Bebop, Dale had not developed for either WordPress or BuddyPress, and Boone’s feedback on his work proved very helpful. With permission, we’re publishing the raw email exchanges between Dale and Boone to demonstrate the value that an experienced developer of a particular technology can bring to a project. Although we’ve been using WordPress at Lincoln since 2008, we have done relatively little bespoke development for our platform and the addition of Boone to the Bebop team resulted in a better quality plugin being released to the public and, just as importantly, helped improve Dale’s skills, too.
It should be of interest to developers working with WordPress/BuddyPress, but also to developers in general, who are in the positions of either mentoring or being mentored themselves. The benefits of pair-programming and code review are well known and we hope this exchange provides further evidence of why technical projects benefit from this type of external review.
This blog post discusses the overall ouput of the Bebop project, referring back to the diagram below, which we included in our initial funding bid. Click on it to have a good look.
You might also want to open a new tab on your browser and take a look at the reference sites, too. Here’s a link to the Staff Directory home page, and here’s a link to my staff profile. You could also try searching for something, too, such as ‘prof’ or ‘Library’ or ‘science’, to see how it works.
The Directory is published to the web using the HTML5/CSS3 Common Web Design presentation framework that Alex Bilbie has developed. Over time, the CWD has integrated more and more features from other common HTML5 frameworks, so that now CWD v4 is mostly a branded Twitter Bootstrap framework that is distributed to multiple sites via Rackspace’s Content Delivery Network. Changes to the CWD are then made immediatley available to all sites to which it is served, which means that changes like our recent switch from a Minerva logo to the University Crest, can be rolled out easily.
As you can see from the diagram, the database behind the staff directory is Nucleus, our warehouse of data for application development. Nucleus is a NoSQL MongoDB database that holds a variety of non-sensitive data collections, such as basic information about people, bibliographic data, geo data about our campus buildings, curriculum data, and timetable data.
Working with BuddyPress (pre-Bebop)
To develop a phone book into a tool for managing and publishing staff profiles, we decided to use BuddyPress as an additional source of data because it already provides a convenient way for a user to update and maintain their own profile information. It is a social network afterall and people are at the heart of social networks. We’ve been running BuddyPress at Lincoln since 2009 and because all staff (and students) have access to a BuddyPress profile (here’s my example), we felt that it was a tool already available to us and that by requiring staff to use BuddyPress to maintain their profiles, they would also be exposed to the WordPress blogging platform and therefore social media in general.
BuddyPress has a fairly rudimentary form builder for profiles and having decided what information we wanted staff to fill out, we added the extra fields to the BuddyPress form. In addition to pulling in data from BuddyPress, we also pull in data via RSS from our ePrints institutional repository, so that under the Research tab you see each academic staff member’s research outputs. If they have not deposited anything in the respository (i.e. they are non-academic professional staff), the repository section of the profile won’t show at all. That is, as information from BuddyPress and ePrints is provided, the person’s profile visibly grows with the addition of new sections.
We have also experimented with displaying blog posts which the individual has written using blogs.lincoln.ac.uk. More or less any information can be added to the Directory as and when we have it. We just ‘plug it in’ to the Staff Directory block in the diagram above.
Working with BuddyPress v2 (post-Bebop)
All of this was in place prior to the Bebop project. Over the last six months Bebop has made two significant contributions to the Staff Directory. Dale has written a new profile editor for BuddyPress which provides a much more structured form for staff to use when adding information about themselves. We found that with free text fields, different people offered similar information in quite different ways and this led to a number of presentation errors when pulled into the Directory from BuddyPress. The code for our new BuddyPress profile editor is on Github and may prove a useful starting point for other organisations wishing to use BuddyPress in this way. Note that it’s not as straightforward as installing and activating the plugin. It requires additional development dependent on your specific use case.
Most notably though, the Bebop plugin has provided a way for staff to publish a curated list of their teaching resources, which can be displayed on their official Staff Directory profile. As you can see in the screenshots below, we’ve added a new ‘Teaching’ tab to the Directory and moved any ‘Teaching Resources’ from ePrints into this tab, along with any items from Bebop, such as slides on Slideshare, images on Flickr, videos on YouTube, etc. Bebop also harvests RSS feeds, so staff can create a university WordPress blog to publish their teaching resources if they wish. WordPress offers a very flexible way of publishing OERs, as we found during our ChemistryFM project. Here’s a screenshot of the Bebop plugin being used on a BuddyPress profile. The information curated here is automatically pulled into the Staff Directory profile.
The images below shows a staff profile with the new ‘Teaching’ tab, where resources from Bebop will be displayed. The second screenshot, shows a teaching resource harvested by Bebop and originating from ePrints. The third image shows resources originating in Slideshare, but again, being fed to the Directory via Bebop. We still need to do work on styling the Slideshare links, so that titles are hyperlinked, rather than the raw hyperlink displaying.
These changes to our Staff Directory have not gone live yet… but they will do soon, once we’ve migrated the existing profile data over to the new BuddyPress profiles – a task which requires a certain amount of data cleaning first. Once the new profile editor is in use, the more structured data that staff enter will be checked against any existing data we hold and used to improve that data thereby helping to validate information which we know may not always be accurate. By giving staff a greater opportunity to directly maintain their own staff profile, we are assuming that the information will be kept more up-to-date.
The Bebop project has further developed our initial use of BuddyPress to provide a flexible way for staff to update and maintain their professional profiles. By processing data from a number of sources, we have re-presented it in a way that helps improve the corporate website, helps validate and update existing data about staff, and mandates staff to use a social networking tool in order to maintain their public, professional web presence. Furthermore, the Bebop plugin, provides a way for staff to link to teaching resources which they are publishing on a number of platforms and aggregate them into their staff profile, alongside information about their research and other professional responsibilities. The work of teaching is therefore given more equal standing alongside the work of research and ‘teaching in public‘ through the publication of OERs is promoted and better supported at the University of Lincoln.
Today, a new version of Bebop has been released, and I wanted to write a short blog post to explain a couple of things that have changed, and why.
After feedback from several users in the WordPress/Github community who have been using v1.0 and v1.0.1, Bebop version 1.1 is here. This version improves functionality and performance, as well as providing some bug fixes.
Comments from feedback suggested that users might want to import content directly to the activity stream. So we built an option into Bebop which allows the OER verification process to change from user authentication to no authentication at the push of a button. This means the admin can decide whether content needs to be verified by users before it appears in the activity stream. If the admin does not want content to be verified, it is added to the activity stream as soon as it is imported into Bebop.
Other feedback highlighted some small bugs which have been fixed. As a result Bebop is now much more reliable, and people are starting to use and trust the plugin. Incredibly, Bebop has been downloaded almost 100 times.
As hinted to above, user input, evaluation and reviews have had quite an impact on Bebop. Hopefully people will continue to make valuable contributions, and hopefully I will be able to comply!
There is still some work to do on Bebop. We are yet to import content from Bebop into our Staff Directory, but this will be coming soon, at least as a proof of concept. It requires some changes to how our staff directory works, and is also reliant on a BuddyPress ‘profile editor’, which we need to finish implementing.
Bebop Goes Live!
I am proud to announce that Bebop version 1 is now live on WordPress.org, and can be downloaded from WordPress.org (or directly through the “search installed plugins” section of a WordPress site). You can also checkout the code repository on Github. This is a fairly early release considering this is a rapid innovation project which still has 6 weeks to go; but we decided we wanted to gather some feedback for improvements before the project comes to an end.
The features released in version 1 are pretty much inline with what we wanted Bebop to achieve at the beginning of the project. This of course, focusses on the aggregation of user OER content into BuddyPress profiles. We have also managed to extend the original specification somewhat, by allowing multiple feeds to be linked for one user. This allows content to be aggregated from multiple accounts into a single BuddyPress profile, which could be incredibly useful for academics who want to share content from more than one group.
Bebop is now producing multiple RSS feeds for each user. Content is published individually for each OER provider (such as SlideShare or Vimeo) which allows users to export specific content into other systems. All of the users OER content can also be imported, and the RSS feed allows up to 250 items to be exported.
A new version (1.1) of Bebop is already being developed, which will feature a more ‘WordPressy’ feel to it, with additional functionality for the discovery of user RSS feeds, as well as some important bug fixes and performance updates. The twitter extension will also be updated, following the release of updated Twitter API’s.
Another aspect of this project was to see how we could reuse the OER content collected by Bebop for other purposes. To accomplish this, we have decided we shall add a ‘Teaching Resources’ tab to our Directory which will automatically import and display contentfrom our BuddyPress platform. This will be made possible by through the use of the RSS feeds which Bebop creates, as described above. We will be working on this over the next couple of weeks.
I would like to take this opportunity to explain some of the technical issues we have faced when developing Bebop. The initial problem we faced was using WordPress/ BuddyPress as a development platform. Having never developed using the rather unique code structure WordPress uses, it was slightly confusing and difficult at first. Fortunately, WordPress is documented rather well, so problems were solved relatively quickly. BuddyPress is not documented as well as WordPress, and it was often difficult to find answers and solutions to problems. Thankfully, Joss had recognised this potential issue before the project began, and enlisted the help of Boone Gorges, a BuddyPress lead developer. Boone’s help and technical guidance has been invaluable on many occasions.
The second technical issue which we found particularly challenging was importing data into Bebop. This may sound strange considering this was the main focus of the project, but let me explain. The main issue was every OER provider does things differently. RSS feeds, OAuth API, API’s returning XML, API’s returning serialised PHP, etc. This posed problems when trying to standardise how the extensions in Bebop work, while trying to keep things as simple as possible. In the end, we decided it was best to have a custom import script which would create a standard array of data for each OER. This data is then passed into another function which deals with all the nitty gritty validation, content checks, and database queries. This turned a rather complicated and messy process into a simple 2 stage process, which is essentially find and sort and then pass it into the processing function.
A problem which I foresee in the future is keeping Bebop up to date. The main concern here is when updated API’s are released. For example, the Twitter API’s have just been updated, and the Twitter API Bebop currently uses will be depreciated within the next 6 months. While we will be able to update API’s up until the project ends in the middle of October, it will be a little more difficult to keep Bebop up to date once the project ends.
Viewing Message: 1 of 1. Notice