The Keywords plugin

November 8, 2012 by · Leave a Comment
Filed under: RedFeather 

The last plugin I’m going to talk about during this initial period of RedFeather development is the keywords plugin.  While the ability to add keywords to a resource is desirable enough to be a candidate for inclusion in the RedFeather core itself, I’ve decided to keep it separate for the time being since it serves as such an excellent demonstration of the plugin architecture.  It acts as an example implementation of many of the different features a plugin might provide, in this case:

  1. Modifying the metadata schema.
  2. Adding field to input workflow.
  3. Adding field to output views.
  4. Adding a new page.
  5. Adding a new toolbar item.

So, let’s start by addressing the metadata schema.  This is stored in the Advanced Configuration section of the RedFeather source and is defined in the $CONF as a simple string array called ‘fields’.  However, this list by itself has no function and is merely a contract that defines what fields RedFeather will look for when it tries to perform actions involving metadata.  In other words, it is the responsibility of a RedFeather plugin to provide support for each field specified – fields themselves provide literally zero functionality on their own.  This is implemented using function pointers (like I mentioned in an earlier blog post, EVERYTHING is function pointers in RedFeather).  All a plugin has to do is loop through the fields and call a different handler function for each field in the schema.  In order to maintain code readability, each of these functions should be given a descriptive name following the RedFeather conventions.

The RDF plugin for example, provides individual functions that understand how to convert the field data into triples.  This means that the function “generate_rdf_field_title” should return an RDF:description involving dc:title whereas the handler for processing the uploaded file needs to return both dct:hasPart and rdf:type.  This perfectly illustrates exactly why the metadata definition is entirely abstract – there is literally no way to automatically determine how to process any given field, and the additional code required to implement a system flexible enough to support this level of description outweigh any possible benefit it may give.

In the case of the keywords plugin, this means implementing additional functions for the existing core modules: resource manager, browse/view, rdf and rss.  The resource manager module is responsible for generating the edit workflow so this needs to be supported first.  The workflow generator automatically looks for functions in the form ‘generate_input_field_xxx’, which it concatenates to the bottom of the form.  There are no explicit restrictions on what these functions return as long as they include the required <input> elements for that field.  In simple cases, such as for the title, this leads to an incredibly simple, single-line definition.  However, the keywords field is actually a multifield (in that it can have more than one value) so is slightly more complicated.  Fortunately, RedFeather also provides a simple way to automatically support multifields, which is also utilised in the creators field.

Workflow with multifield keyword added.

The browse/view module is responsible for actually displaying this data, since it provides the implementation for the metadata generator.  This is implemented in a very similar way to the resource manager but instead looks for functions of the form ‘generate_output_field_xxx’.  This consistency when dealing with plugins and fields exists throughout RedFeather and is vital in maintaining code readability in a swamp of functions.  Output fields are much simpler than input fields and just have to return the html in the form of two-column table rows, which are combined to form the metadata table.  The RSS and RDF field implementations are also impressively compact so I will move on.

That is all that is needed to implement the ‘data’ aspect of the keywords plugin.  Appropriate input boxes now appear on the workflow and the fields manifest in the browse view, resource view, and alternative data views (RDF, RSS and JSON).  However, no keyword system is complete without a pretty tagcloud to go with it.  Implementing one requires us to create a whole new page (for the tagcloud itself) and a way to get to it from the main repository (in this case, a simple menu item).

As I mentioned in my earlier post on the RedFeather architecture, pages are implemented within RedFeather using function pointers.  In this case, all we need to do is write a new function in the form ‘page_xxx’ (which is then automatically accessible at index.html?page=xxx).  Page functions are used by RedFeather to output data or html to the web; this can be done either manually, or using the RedFeather templating system (which I talked about in great detail in a previous post).  The tagcloud is intended to be  normal page within the site, so it should use the template.  The system then accesses the global resource data and builds the tagcloud by writing html to the $BODY global variable; this is then written to user by calling “render_template”.

Example tag cloud

Adding a menu item to allow users to access the tagcloud from the browse page is a case of simply writing a new function in the correct format.  This is then processed by the toolbar renderer and added to the menu.

New menu item

This consistent, concise architecture allows even intermediately skilled programmers to very quickly create exciting new plugins and features for RedFeather.

RedFeather: Summary of Outputs

November 8, 2012 by · Leave a Comment
Filed under: RedFeather 

The outputs listed below represent a summary of the outputs from RedFeather.  They are everything that we originally promised to achieve to fulfill the RedFeather use cases.  RedFeather is looking fine and dandy.

Outputs List
RedFeather Core The primary deliverable of this project is RedFeather itself, which provides an out-of-the box repository solution in a single php script. It distills the complexity of a full-scale repository platform to provide a feature set that we believe satisfies 90% of users who want to share OERs but don’t have the server infrastructure or expertise to do so.You can read more about  the RedFeather Core here:http://blog.soton.ac.uk/oneshare/2012/10/31/deliverable-redfeather-core/ RedFeather is an open-source project and is available for download here:http://redfeather.ecs.soton.ac.uk/downloadThe latest development version is available on:GitHub at https://github.com/mattrosstaylor/RedFeather.
RedFeather Core Plugin Framework RedFeather is implemented as an extensible plug-in Framework.Each plug-in is a single php file which is can be installed by simply copying it into the webspace alongside the main repository.The plug in framework maintains consistency within the system:  with the framework,  there is no difference between a plugin and the RedFeather core itself.In effect, the  RedFeather core is  a collection of the most useful plug-ins.You can read more about  the RedFeather Framework here:http://blog.soton.ac.uk/oneshare/2012/10/30/plugin-architecture/ RedFeather is an open-source project and is available for download here:http://redfeather.ecs.soton.ac.uk/downloadThe latest development version is available on:GitHub at https://github.com/mattrosstaylor/RedFeather
Alternative Data ViewsRedFeather  supports  a number of views of the data ( The Resource and its metadata) for humans and for machines.  This allows OERs in redFeather to be more discoverable on the web.
RedFeather HTML View Plug-in This is the human centred  view, providing an on line, inline preview of the resource, directly on the resource page.You can read more about  the RedFeather  HTML view here:http://blog.soton.ac.uk/oneshare/2012/07/06/embedding-previews/ RedFeather is an open-source project and is available for download here:http://redfeather.ecs.soton.ac.uk/downloadThe latest development version is available on:GitHub at https://github.com/mattrosstaylor/RedFeather
RedFeather RSS Export Plug-in RSS is intended more for digesting the repository as a whole. It  is accessible as a feed from the index page.The RedFeather RSS plug in provides a  key link  to OER indexers such as Xpert .  RedFeather will provide a lightweight gateway through whichto make a small source of OER, such as an independent RedFeather installation, visible to the wider community.You can read more about  the RedFeather  RSS view here:http://blog.soton.ac.uk/oneshare/2012/11/02/alternative-data-views/ RedFeather is an open-source project and is available for download here:http://redfeather.ecs.soton.ac.uk/downloadThe latest development version is available on:GitHub at https://github.com/mattrosstaylor/RedFeather
RedFeather RDF Export Plug-in RedFeather provides an RDF view to support linked data and semantic searching. http://blog.soton.ac.uk/oneshare/2012/11/02/alternative-data-views/ RedFeather is an open-source project and is available for download here:http://redfeather.ecs.soton.ac.uk/downloadThe latest development version is available on:GitHub at https://github.com/mattrosstaylor/RedFeather
RedFeather JSON Export Plug-in JSON is both the simplest and most versatile data view since it is easily understood by both humans and machines.  As JSON support was only introduced in PHP v5,  it cannot be including in the RedFeather core.  It is only available as a plugin for users with PHP v5.You can read more about  the RedFeather  JSON view here:http://blog.soton.ac.uk/oneshare/2012/11/02/alternative-data-views/ RedFeather is an open-source project and is available for download here:http://redfeather.ecs.soton.ac.uk/downloadThe latest development version is available on:GitHub at https://github.com/mattrosstaylor/RedFeather
Social and Recommendation Plugins Facebook Connect RedFeather is an open-source project and is available for download here:http://redfeather.ecs.soton.ac.uk/downloadThe latest development version is available on:GitHub at https://github.com/mattrosstaylor/RedFeather

 

RedFeather Extras

When we had finished what we promised for redFeather, we didn’t stop there.  As a result of feedback from our early adopters,  we have developed more features for RedFeather than we originally planned.  These  are the extra RedFeather outputs:

Extra Outputs
Extensible Workflow Plug in The  ‘out of the box’  RedFeather has a simple workflow that will fit the majority of users needs. The  Workflow plugin allows advanced users to easily customise the workflow to meet their specific needs. RedFeather is an open-source project and is available for download here:http://redfeather.ecs.soton.ac.uk/downloadThe latest development version is available on:GitHub at https://github.com/mattrosstaylor/RedFeather
Reskinning Plug in The default RedFeather template has a very simple but modern style that can be used directly out-of-the-box.  This allows less technical individuals to quickly deploy a site without having to worry about writing their own HTML or CSS.  The Reskinning Plug in allows the user to very easily create a new appearance either to match the look and feel of an existing site or just out of preference.  Read more about the Reskinning Plug-in here http://blog.soton.ac.uk/oneshare/2012/11/02/reskinning-redfeather/ RedFeather is an open-source project and is available for download here:http://redfeather.ecs.soton.ac.uk/downloadThe latest development version is available on:GitHub at https://github.com/mattrosstaylor/RedFeather
Keywords Plug in The keyword plug in adds a new field to the RedFeather workflow that can be used to add arbitrary tags to a resource. It also includes a simple tag cloud that can be accessed from the browse page.  Read more about the Keywords Plug-in here http://blog.soton.ac.uk/oneshare/2012/11/08/the-keywords-plugin/ RedFeather is an open-source project and is available for download here:http://redfeather.ecs.soton.ac.uk/downloadThe latest development version is available on:GitHub at https://github.com/mattrosstaylor/RedFeather

 

Extra, Extras

When we finished the extras, we found some more things that we wanted to do: We are working on these extra, extra features

Extra Extras
Edshare Connect EdShare Connect Plug-in is a simple export feature  to  deposit the contents of a RedFeather repository into an EPrints/EdShare repository

Simple how to screencasts and guides The project team are putting together some ‘How to’ screencasts, videos and guides on how to deploy RedFeather, use it, and customize it using thje plug-in framework

 

RedFeather Dissemination

The Project team have spread the word about RedFeather internall and externally through seminars, conferences and the web, and will continue to do so,  We have a draft paper submitted to OER13.

Dissemination
RedFeather at OR12  Repository Fringe The RedFeather team presented RedFeather at the international Open Repositories 2012 conference.You can watch the video here:http://vimeo.com/45751142 You can read more about it here:http://blog.soton.ac.uk/oneshare/2012/07/18/redfeather-at-open-repositories/
RedFeather  Project Blog The RedFeather project blog is available here http://blog.soton.ac.uk/oneshare/category/redfeather-2/
RedFeather  Project The Redfeather Project website is available here.It provides access to  the RedFeather downloadAnd hosts a live RedFeather demo repository http://redfeather.ecs.soton.ac.uk/
RedFeather  live demo Redfeather has a live demonstration repository http://redfeather.ecs.soton.ac.uk/demo
Redfeather submitted to OER13 The project team has submitted a draft paper on RedFeather to OER13: Creating a Virtuous Circle

 

RedFeather  Live
RedFeather deployments RedFeather is deployed at these projects at the University of Southampton to provide them with a repository of their project working documents and outputs:The Southampton learning Environment projecthttp://slep.ecs.soton.ac.uk/The Southampton Student Dashboard projecthttp://www.sle-dashboard.ecs.soton.ac.uk/overview/with more to follow

 

RedFeather: A Final Round-up

November 7, 2012 by · Leave a Comment
Filed under: RedFeather 

RedFeather is a lightweight repository alternative that makes it easy for individuals or small groups to contribute OERs

Open Educational Resources promise a new engagement between educational institutions and the public, and potentially a widening of educational opportunity in society Although much has been said about the challenges for larger institutions engaging with OER there has been far less attention paid to how individuals or smaller groups can engage.

Currently there are significant barriers to these kinds of small-scale OER contributor, not least in where and how they publish their materials. Traditional repository platforms such as the research repository EPrints require significant configuration and investment to deploy and even extensions such as EdShare (that provide simplified workflows and improved tools focused on teaching materials) still require significant technical skill to both deploy and maintain For a small or personal collection of OER, the overhead required in hosting such a system often far outweighs the perceived value of sharing.

It is still possible for these types of contributors to upload their work to a public website, but rich media is effectively dark to search engines without adequate metadata. In addition they may forget important licensing information, and materials published this way are invisible to national indexers like Jorum or Xpert.

The lack of simple solutions for sharing OER resources is a serious limit on the take up of OER and the growth of the OER community.

RedFeather is our proposed solution to this problem. RedFeather is a lightweight server-side script that fosters best practice OER sharing without the overheads associated with the installation and use of a full-scale repository platform. By eliminating the need for complex server infrastructure and emphasizing a concise, simplified workflow, RedFeather provides an out-of-the-box solution for users wishing to quickly annotate their OER and make them available in a variety of formats (including HTML, RSS, RDF and JSON).

With RedFeather we have created a system that should satisfy the majority of small-scale contributor requirements (in-line previews, commentary, organisational tools, and high quality, indexable OER metadata) with minimum configuration, while still allowing straightforward customisation through a plugin architecture and design templates.

Our hope is that RedFeather will make a significant impact towards the democratisation of the process of OER contribution, and unlock the long tail of potential contributors.

RedFeather Impact

November 7, 2012 by · Leave a Comment
Filed under: RedFeather 

The lack of simple solutions for sharing OER resources is a serious limit on the take up of OER and the growth of the OER community.

RedFeather is our proposed solution to this problem. RedFeather is a lightweight server-side script that fosters best practice OER sharing without the overheads associated with the installation and use of a full-scale repository platform. By eliminating the need for complex server infrastructure and emphasizing a concise, simplified workflow, RedFeather provides an out-of-the-box solution for users wishing to quickly annotate their OER and make them available in a variety of formats (including HTML, RSS, RDF and JSON).

With RedFeather we have created a system that should satisfy the majority of small-scale contributor requirements (in-line previews, commentary, organisational tools, and high quality, indexable OER metadata) with minimum configuration, while still allowing straightforward customisation through a plugin architecture and design templates.

Our hope is that RedFeather will make a significant impact towards the democratisation of the process of OER contribution, and unlock the long tail of potential contributors.

Impact visibility

We expect impact to be visible in a number of areas exemplified by scenarios of RedFeather use

  • Access to the benefits of OER sharing are widened to users with small, simple cases without the need for an institutional repository
  • Previously hidden resources will become available through access to simple OER good practice, increasing the breadth and number of OER resources.

The small project.

SMART is a JISC funded OER project to collate and release the diaries and writings of Christopher Strachey as a rich collection of computer history teaching resources. The project is a collaboration between four different institution’s libraries. Between them they want to collect all their materials together so that they can visualise the whole collection and determine which are of most value. At the end of the project the materials will be deposited in Jorum.

There are too many resources to email and even then the individual files would still need to be annotated. SMART are initially attracted to a teaching repository but soon realise such a system is over-specified for their needs since this is a one-off project and won’t have ongoing community activity. They identify RedFeather as a low-maintenance alternative.

SMART’s deploy RedFeather on  project’s website so that all the files can be uploaded to one central point, where they can be visualised and annotated and reviewed. They use the RedFeather RSS Feed to import the whole collection into Jorum.

The solo sharer.

Joanna is a physics lecturer. She would like more people than her immediate students to benefit from her teaching materials by making them openly available. Whilst her institution does not prevent her from making these resources available, do not provide the means to do so. Joanna finds that RedFeather provides a comprehensive solution without any significant technical requirements. She is relieved to find out that all he has to do to install RedFeather is upload a single PHP file to her staff webspace.

The default RedFeather annotation schema, page layout and styling is perfectly adequate for Joanna’s needs. Her students are now able to browse all her resources from a central location and use the provided keywords and description metadata to find relevant material. Joanna also uses the RedFeather embeddable resource viewer to include her teaching materials in her personal blog.

The solution-oriented admin.

David is a systems administrator for the Language department at his University. The department want to release their teaching materials as OER to increase the profile of teaching in the department. Deploying a full teaching repository is a long term aim but David is able to deploy RedFeather to provide a rapid interim solution that will also help the department to learn about OERs and see the value of sharing.

Since David already uses PHP for the department website he can deploy RedFeather the same day. As an advanced user, Dave is able to change the stylesheet to fit the university branding and customise the workflow and metadata to suit the needs of the academics. David uses RedFeather to add the department resources to both the Xpert search and ROAR. He knows that when he has time to deploy a full solution he can easily migrate from RedFeather.

Evidence of Impact

RedFeather is already in use supporting small projects, deployed for

Alternative Data Views

November 2, 2012 by · Leave a Comment
Filed under: RedFeather 

It is important to make sure that a repository is accessible to machines as well as humans as this allows it to be indexed more efficiently and thus more discoverable on the web.  RedFeather currently supports 3 alternative data formats: JSON, RSS and RDF.  Additional representations, including schema.org markup, were considered during development but taken out of scope for this initial version of RedFeather.  They do, however, make ideal candidates for further work.

Out of the formats mentioned, JSON is both the simplest and most versatile since it is easily understood by both humans and machines.  Unfortunately, JSON support was only introduced in PHP v5 so it cannot be including in the core and so is only available as a plugin.

RSS is intended more for digesting the repository as a whole, and as a result is only accessible as a feed from the index page.  Since there tends to be a lot of variance in terms of what different stream readers expect from RSS we decided to stick with a minimal entry format to try and maximise compatibility.  However, the only truly critical important API is Nottingham Xpert, since that is one of the only feasible ways to make a small source of OER, such as an independent RedFeather installation, visible to the wider community.

Due to the inherent complexity of the format, the creation of an RDF export for RedFeather presented a few interesting challenges, most of which involved the ‘creators’ field.  The first problem was that of URIs.  Since RedFeather is implemented as a single php file, it’s not exactly overflowing with accessible URLs that can be used to resolve a URI.  This is compounded by the fact that RedFeather doesn’t really have any concept of “people” as an entity – there are no profile pages for individuals and the user account system is ONLY used for authentication.  In effect, a creator is just a single name field with an optional email address associated with it.  Further problems occur if a certain name appears on multiple items in the repository – how do you tell if they are the same person or multiple entities?  What if they are the same person but have changed their name or email?  What happens if you delete all the resources by a certain author and re-add them?  Will they still have the same URI?

Trying to solve all these issues and implement a complicated system which can deal with all the fringe cases above is ludicrous when you consider the elegant simplicity of the rest of RedFeather.  A better solution would be to just assume that two creators with the same name and email are the same person.  This will work in the vast majority of cases except in unusual instances where no email is known and their name is something incredibly common, like Bob.  We can therefore pretty much just concatenate the name and email together to form the URI – however, the URI still needs to resolve to a page that makes contextual sense for a person.  To solve this we just included a special page which contains a list of all the creators who have contributed to the repository.  The names on this list are then linked to using an anchor tag to give a final URI that looks something like www.example.com/index.php?page=creators#matt

 

 

Reskinning RedFeather

November 2, 2012 by · Leave a Comment
Filed under: RedFeather 

The default RedFeather template has a very simple but modern style that can be used directly out-of-the-box.  This allows less technical individuals to quickly deploy a site without having to worry about writing their own HTML or CSS.  The template also gives the user the capability to customise the colour scheme at their own discretion.  This can be done purely out of personal colour preferences (if you look fabulous in blue), or to try and match the colour scheme of an existing site.  In my earlier post, Deploying RedFeather, I explored how one might integrate RedFeather into an existing site using this method.  In this case, I was trying to add a RedFeather repository to the SLEP website, which has a fairly unusual magenta and indigo colour scheme.  Simple recolouring RedFeather to match this gave very poor results due to the strange contrast, so I decided to average the colours instead and go with a uniform lilac theme.  While this differentiated the site from a default ‘red theme’ RedFeather and would probably be acceptable to some users, I will be the first to admit that this wasn’t even close to a seamless integration.

It was obvious that it would not be possible to fully integrate RedFeather with another site unless you could replace the entire html template and stylesheet.  This is a much more complex customisation than simply changing the banner colour and can only be done by writing a custom plugin.  However, special consideration were made in the RedFeather core to make writing such a plugin much easier.  The first was simple, enforcing a complete separation within the code between the template and content.  This meant making sure that html elements making up the vital parts of the site (such as workflow items, or resource preview) were completely independent of the template and render properly even if all other styles are stripped out.  Furthermore, they were all given unusual element ids and classnames (prefixed with “rf_”) to minimise the chance that any new css rules on the custom template will interfere with them.

The first step to writing the plugin is to override the ‘render_template’ function and completely replace the output HTML; this will cause RedFeather to render pages exactly like the target site, only without any RedFeather content.  Adjusting the new template to include the required content is simply a case of inserting each element in the appropriate place.  Each template needs to include the following compulsory elements:

  • $BODY – the global variable containing the main content div for RedFeather.
  • $TITLE – the title of the page.
  • The global CSS and javascript (obtained by calling ‘generate_head_elements’) - should always be present in the html head element.
  • The error message list (obtained by calling ‘generate_message_list’).
  • The footer toolbar (obtained by calling ‘generate_toolbar_footer’) – contains a link to resource manager and RedFeather project page.

Depending on the structure of the new template, some of the RedFeather content might appear incorrectly.  This is probably due to a mismatch in element types (for example, if the template expects <h2> elements instead of the <h1> RedFeather uses), or missing CSS.  This is a problem that simply cannot be avoided, since we cannot make assumptions in the RedFeather core about the kind of templates people want to use.  However, it is relatively straightforward to use jQuery to transform any incorrect elements so the are consistant with the template.

I’ve include a pair of photos below to demonstrate the versatility of the templating system.  The first is a resource preview using the default RedFeather template, and the second is complete reskinning of RedFeather using a CC licensed template called “impeccable” by http://www.freecsstemplates.org.  This template was chosen because it differs from the default in a number of significant ways with a two-column layout, dark colour scheme, and unusual header style (notice that the resource title includes an image).  It also has a very narrow content area, so I’ve decided to install the vertical resource layout plugin, which switches the resource preview, metadata and comment widget into a single column layout.

Default RedFeather Template

Reskinned using Impeccable by FCT

Deliverable: RedFeather Core

October 31, 2012 by · Leave a Comment
Filed under: RedFeather 

The primary deliverable of this project is RedFeather itself, which provides an out-of-the box repository solution in a single php script. It distills the complexity of a full-scale repository platform to provide a feature set that we believe satisfies 90% of users who want to share OERs but don’t have the server infrastructure or expertise to do so. This includes independent teachers, those working for a university (or department) without an existing institutional repository, or small projects who only wish to share a small number of resources. In these instances it is very unlikely that the cost of setting up a repository can be justified so the resources are either never shared, or simply uploaded as simple files. This means that they won’t be properly annotated, attributed or indexed in any meaningful way. The RedFeather platform provides a solution that makes it feasible for almost anyone to benefit from the added value of OER without a significant initial investment.

By implementing the entire platform in pure PHP we eliminate the need for any additional software to be installed on the target server; it can even run without a database. Furthermore, the code is compatible all the way back to PHP 4 to truly maximise the number of webservers capable of running it. We feel this is approaching the theoretical minimum system requirements a repository could possibly have while still being locally hosted.

In the remainder of this post I’m going to describe the key features of RedFeather and talk a little about how they differ from those of a larger repository system.

Resource view

Arguably the most important part of a repository is the resource summary page, since this is what the consumers of OER will ultimately see. With a RedFeather resource, users are treated to a generous in-browser preview of the uploaded resource, a clearly layed-out metadata summary, and a variety of social networking options, including Twitter tools and a Facebook commenting widget.

An example RedFeather resource summary with in-browser preview, metadata and Facebook comment widget.

Like HumBox, there is a heavy emphasis on the resource itself being the focal point of the page as opposed to supporting metadata, which is usually of lesser importantance in a teaching and learning repository. The resource preview utilises the incredible powerful Google Docs Viewer, which allows us to embed a variety of file types, including Word documents, Powerpoint presentations and PDFs. Images are rendered as simple <img> html elements, while other media files type could potentially be supported with an additional plugin. Sadly, embedding rich media in html 5 isn’t currently feasible without browser plugins or server-side conversion tools, which would add unacceptable server side dependencies to the RedFeather core.

Index

The index page for RedFeather includes a customisable description of the repository, an ordered list of the uploaded documents, and links to the repository RSS and RDF. A simple resource filter is also provided so users can quickly find resources relating to a certain keyword or phrase. From here users can click the individual titles to visit the resource page for the item, or download the file directly using the link provided in the metadata box.

A typical RedFeather index, with filter box, RDF/RSS feed links, and the list of resources.

Resource Manager

Uploading a new file to the repository is remarkable straightforward and can be done directly from the RedFeather resource manager with only a few clicks. Once the file has been uploaded, the user is automatically taken to the annotation workflow where they can fill in the fields and make it immediately available. By streamlining the process of adding resources and employing an “upload first” workflow we hope to further reduce the barriers preventing uptake of OER sharing by inexperienced users. The resource manager also allows the user to delete or edit existing resources, and change the order that they will appear on the browse screen.

An alternative workflow is also available via FTP, which allows users to upload files directly to the webserver without using the browser. This is useful for extremely large files, or when first populating the repository (since you don’t have to upload each file individual). These unprocessed files appear in a seperate menu on the resource manager ready to be annotated at the administrator’s discretion.

Resource Manager – showing existing resources (with options to reorder, edit, view and delete), the list of currently unannotated files (uploaded via FTP) and the main resource upload options.

The RedFeather annotation workflow with the default metadata schema.

Default RedFeather Template, Customisation and Plugins
The default RedFeather template gives the repository a modern look-and-feel with an unintrusive single column design and bold headers. It also supports a certain amount of customisation and the standard Red theme can easily be changed to use the colours and font-style of the administrator’s choice – it is also possible to change the name, tagline and description of the repository. More significant customisations of RedFeather can be achieved by writing a plugin to overrides the template. I talk about RedFeather’s versatile plugin architecture in great depth in my series of posts on the subject.

The RedFeather default template with a customised repository name, tagline, colour scheme and font.

RedFeather is an open-source project and is available on GitHub at https://github.com/mattrosstaylor/RedFeather.

Plugin Architecture

October 30, 2012 by · Leave a Comment
Filed under: RedFeather 

In this post I’m going to talk about how the RedFeather plugin system is implemented.  I’m also give a rough overview on how the rest of RedFeather works and provide a rationale for the decisions I made regarding the design.

Given that the primary motivation behind RedFeather is the desire for simplicity I hat to make sure that the plugin system was just as simple.  The first thing to consider was installation.  This is a particular problem with EPrints, where a plugin is usually composed of many files which need to be individually copied in the correct directories in the source in order to work.  While, the Bazaar package manager goes a long way towards making it easier for the user, it increases the complexity of both the plugin itself and the EPrints platform.  With RedFeather each plugin is composed of a single php file which is can be installed by simply copying it into the webspace alongside the main repository.  Depending on the complexity of the plugin, a small amount of additional configuration may be required but ultimately that’s all it takes.  This simplicity also translates to the loading process; plugins are activated by appending their content to the main RedFeather file using a PHP include – this means that there is no need to parse or process the plugins in any way.  It also maintains consistency within the system since there is absolutely no difference between a plugin and the RedFeather core itself.  In effect, the main RedFeather source is really just a collection of the most useful plugins.

So, how does RedFeather work?  Function pointers.

Literally everything in RedFeather is achieved via the clever use of functions: page loading, toolbar rendering, and workflow management.  Furthermore, ever single function can be overridden in a plugin, allowing you to change the behaviour of almost any part of RedFeather.  If you don’t like the layout of the browse page you can simply create a plugin that replaces that part of the system.  The challenge then becomes one of code factorisation – how do I best break down the code into functions in order to facilitate code reuse?  In the example where we’re editing the browse page there existing code is already broken down into various chunks; there is code to render individual fields, individual resources, the complete list of resources and the entire browse page itself.  If you wanted to adjust the browse page to include a description at the top, you would only have to edit the “page_browse” function (which only consists of a few lines).  Likewise, if you wanted to add an icon to each resource you might edit “generate_resource”.

This leads us onto a problem: too many functions reduces the readability of the code – made worse due to the fact that, as of the time of writing, the core RedFeather source code alone contains over 70 function.  There is where good code structure and consistant naming conventions become critical.  For example, functions prefixed with “render_” always write to the output buffer whereas functions beginning with “generate_” return html.  However, functions names also serve a far more useful purpose in controlling program flow.  The most obvious example is the prefix “page_”, which is used to denote the entry point for any URL access (for example, the url “index.html?page=resource_manager” will automatically call the function ‘page_resource_manager”).  This makes it very easy to write plugins to define new pages, since all one must do is define a single function.  I’ll talk more about function pointers in a future post.

In addition to the cunning function pointers there are also a number of global variables which are used to pass information around the program.  The $BODY and $TITLE variables are used as output buffers for the html body and title when rendering a page using a inbuilt template system (which I will talk about in a future post).  The $DATA variable is pre-loaded on every page with the metadata of all the resources in the repository and can be written back to persistance using the “save_data” function.  The $CONF variable is the most important of all and contains all the configuration information – from the repository name itself, to the width of the resource preview widget.  While it is generally considered “bad practise” to use global variables I felt they actually improved code readability in this case because they provide a consistent way to access frequently used values.  Also, passing them around would just add unnecessary overhead to every single function call.

I think that’s enough background on the RedFeather implementation for now – I’ll go into more detail in future posts.

Learning from existing plugin systems

October 30, 2012 by · Leave a Comment
Filed under: RedFeather 

One of the other defining characteristics of RedFeather is the fact that the core implementation comprises of a single PHP file.  Despite this, it still provides a highly extensible architecture capable of being customised and tweaked to suit different situations.  Plugins can be written to add new fields to the workflow, introduce new pages and functionality, or change the site’s appearance.  While the concept is nothing new, writing such an architecture while still maintaining the desired simplicity of RedFeather presents a distinct challenge.  By looking at existing implementations of plugin environments it is easy to appreciate the potential complexity of such a system and identify ways to simplify.

The first architectural style I analysed was the ‘hook system’ of plugin management, as used in both WordPress and MediaWiki.  In these programs, each plugin is associated with a special point within the code, known as a ‘hook’.  Each hook corresponds to a different point in either the execution of the code (for adding additional processing), or a point in the rendering a page (for adding content).  The advantage of this system is that is allows for the greatest possible flexibility while still maintaining complete control over how and where the program can be extended.

As you might expect, the code overhead associated with this system is considerable and would turn RedFeather into an unreadable mess of complexity.  Framework code would need to be written to support the processing of plugins in general, then additional code to handle each category of hook. Furthermore, every page and feature in the system needs to be written in a specific way to support the plugin environment.

The EPrints platform utilises an entirely different system which relies largely on inheritance.  Writing a new feature is done by creating a subclass of an existing one and adjusting the functionality as required.  Plugins are loaded automatically on server startup and configured using additional scripts within the cfg.d directory.  The main advantage of this system is that it is possible to entirely rewrite or extend any part of the platform, although a larger understanding of the core EPrints code.

In the interest of keeping these blog posts readable I shall continue this topic in my next post.

Lessons in dependency management

October 25, 2012 by · Leave a Comment
Filed under: RedFeather 

The approach I had to take when developing RedFeather was very different from my usual methodology due to the unusual motivations behind the system.  As I mentioned in my earlier blog posts, the primary goal behind RedFeather is to provide a system with installation and usage barriers as low as possible.  In this blog post I’ll be talking about how this affected the way I designed and implemented the system.

Limiting the amount of dependencies required to install and operate RedFeather was probably the biggest challenge during development.  It is a well established ideology that you shouldn’t constantly reinvent the wheel – if somebody has already built a component, it is usually better to use it then to redevelop it yourself.  This is why things like databases and software libraries exist; they have been developed to solve a very specific task and are usually mature, well documented, and proven technologies.  For example, no sensible developer would program his own video codecs from scratch if something like ffmpeg would be adequate for their needs.  However, every additional dependency included within RedFeather increases the overhead involved with installation and reduces the simplicity and self-containedness of the system.

The most important rule I imposed on RedFeather was to include zero server-side dependencies, thus eliminating any overhead associated with configuring the server environment.  In practise, simple overheads (such as access to a database server) are usually acceptable but eliminating them entirely allows users to install RedFeather quickly without having to involve system administrators.  However, programmers are accustomed to having access to these luxuries and often take them for granted.  Having to develop without them requires us to take a step back and make the most of the facilities that are available.  In the case of RedFeather, the most obvious alternative was to use the filesystem of the webserver itself which provides a convenient location to store both the resource metadata and files.

When you contrast this with a full-scale repository platform and you can see clear advantages.  In EPrints, for example, resource metadata is stored in the database using a complex multi-table schema while the uploaded files are placed in a special data structure hidden on the server.  Downloading a file involves first looking up the resource in the database, determining the file_id and then serving it using a custom file handler.  In RedFeather, the resource metadata for the entire repository is stored in a single file in a schemaless human-readable format.  The associated files are stored directly in the public webspace of the server and are therefore immediate accessible.

While the method utilised in EPrints is obviously far more flexible than RedFeather, I believe it is unnecessarily complex for 90% of cases and certainly over-specified for someone who just wants to share a handful of simple resources.  Notably limitations of RedFeather in this respect are the lack of explicit collections and multi-file resources.  However, neither of these features are precluded by this method of storage and could be added at a later date.

A harder lesson to learn was that certain features and functionality simply can’t be supported without external tools.  This includes complex file processing or conversion, and media rendering (video and audio are particularly problematic since HTML 5 only supports a small number of formats).  Exceptions had to be made for JQuery (which is indispensable for cross browser javascript) and the Google Docs Viewer (without which there would be no embedded previews). Fortunately, both of these dependencies are entirely web-based and therefore add no overhead to RedFeather’s installation process.

Next Page »