RedFeather Design Philosophy

One of the greatest barriers when deploying a full-scale repository platform such as EPrints is the amount of configuration required to take the software from its “out of the box” state to something suitable for teaching and learning.  Installing the EdShare suite of extensions takes you a great deal of the way by providing simplified workflows, in-browser previews of documents, collections, user profile pages and more.  However, tweaking these base settings to perfectly match your requirements still requires a certain familiarity with the inner working of EPrints itself.

With RedFeather we want to try and provide a system that will satisfy the requirements of 90% of users with almost zero configuration – the idea of a repository you can fully deploy in a single afternoon is very appealing to us.  Of course, we don’t want something that is not flexible enough to be useful to that final 10% of expert users who want to go the extra mile.

At this point in the project I’ve already done a great deal of work prototyping various different ways of providing customisation, ranging from highly granular configurations where each individual component can be seamlessly interchanged, to completely fixed configurations which are coded to only do exactly what we want. Both approaches have their advantages but the main motivation behind RedFeather is that the system should be simple and forsake all the complexity so inherent in existing repository platforms.  This has led me to the following philosophy for the design:

1 ASSUME ONLY MINIMAL VARIATIONS

Cater primarily for the 90% of people who will deploy RedFeather with the default workflow, metadata and look-and-feel but make it easy for them to change very minor parts of the site such as the header, footer and stylesheet.

2 PRIORITISE SIMPLICITY OVER FLEXIBILITY

Do everything in a way so simple that changing it is trivial for anyone with even basic knowledge of html and PHP.  Don’t try to anticipate how more advanced users will want to customise the code – just make it easy for them to understand the existing system and leave the rewriting to them.