Before we go on I’ve written an FAQ on the PROD wiki which you are all advised to have a look at…

The PROD Vision:

PROD is a dynamic directory of JISC projects providing an easy-to-use way to locate projects and get a view of their current status and activity. Through integration with the Standards Catalogue and e-Framework it will also provide an overview of interoperability standards used by projects and their rationale for doing so.

PROD draws information on projects from a number of sources including the JISC website, individual project sites and project RSS feeds. We have also developed import mechanisms for legacy spreadsheets and catalogues.

The data in prod can be exported in standard formats (including RSS, ATOM, DOAP and CSV) to facilitate re-use in other catalogues.

Progress report

People oriented activities:

We are currently looking at how this data can facilitate integration with efforts at OSSwatch and with the JISC PIM system. We had a meeting in London to discuss how we can leverage doap across the different systems to exchange data and avoid duplication of effort. Present included Ross Gardler from OSSwatch with SIMAL, Yvonne Howard and Dave Millard from Southampton with their e-Framework Knowledge Base, Neil Chue Hong from OMII in Edinburgh, and Simone Spencer who is heading up the JISC PIM. It was pretty satisfying to feel we all agreed that with a bit of work on our respective DOAP implementations we would be able share core project data and thus concentrate on the more individual value-adding aspects of our projects.

Here in Bolton we are holding a workshop tomorrow on how we plan to use PROD internally to help us with the process of ”technical audits” of projects and how we can go about integrating PROD with the other JISC CETIS web offerings.

Ongoing development work:

DOAP, RSS & CSV export for collections of projects through the browse/query interface. We’re also thinking about making widgets to embed this in other places (like the main JISC CETIS site – or your own personal iGoogle or Dashboard if you like!)

OpenID associations for existing users – this is part of the general OpenID implementation across JISC CETIS sites. Currently it works to enable commenting.

Selectively elevated privileges for project staff and programme managers. This will happen automatically through existing data where available, we will also put in a “claim” button to users to assert a relationship to a project where a connection is not already held.

General review of data held, sanitisation particularly around people, organisations, themes. This will include a manual trawl for project sites, feeds etc where they haven’t been auto-discovered. Administrative interfaces may also see some improvement.

Integration with Standards Catalogue. Users (CETIS staff, projects, etc) will be able to associate projects with relevant standards and comment on the rationale for their use or implementation. The standards catalogue bit is working fine now.

Integration with main JISC CETIS sites – highlighting relevant projects within domain pages and other CETIS output (blogs, e-learning focus etc). This activity will be of particular relevance to ongoing comms work including the “technology & standards briefings”.

Highlights of completed development work to date:
(Roughly in order of implementation)

• Core data model
• Core interface
• Old directory import
• JISC spreadsheet import
• DOAP export
• Search interface
• Funding status indicators
• AJAX editing (administrators only at the moment)
• JISC web-scraper
• RSS feed-scraper
• Data-sanitisation utilities (for admins)
• Activity indicators
• Comments
• Browse & querying interface
• OpenID authentication (for commenting)

There are a few processes going on; Mark, Sharon and Adam have been conducting a review of the community wiki aspects of the web presence and the e-learning focus team are considering where to go next with their magazine-style site with a view to merging it together with the JISC-CETIS page. The Communications team has been discussing the whole show from start to finish and back again.

My thoughts

1) You are in a twisty turny maze

There is a tendancy for people to get lost in the site. Removing some navigational elements (especially in the wiki) and applying some others (breadcrumbs, menus etc) in a coherent way will make a difference I hope – but the main proposal is as follows:

Merge the www.cetis page, the jisc.cetis page and the elearning focus site into one coherent magaziney all-singing portal.

Front page mockup v3

(old versions: v1 v2)

The mockup (v3) shows the main elements we have identified – with a monthly editorial, regularly changing “features”, and constantly changing “news”. It also gives prominence to the SIGs with a prominent bar on the left hand side…

To start off with, the news and features would actually be drawn from the blogs as the current aggregation is – only the editiorial process will be stepped up – with lead-ins and article filtering-selection done by the focus team. As is done with e-learning focus, articles may also be commissioned by external writers.

V2 has a horizontal-slice approach; Banners | Navigation | Editorial | News etc (3 streams) | Other stuff (4 streams)

V1 is an earlier attempt – and is more like the aggregation as it stands at the moment.

2) Re-work the SIG entry points

We made a decision quite early on that the SIGs would simply have a protected wiki page each to serve as their main site – giving them total flexibility to do whatever they wanted. Of course this approach led to inconsistency and an extra learning curve for staff. The result was certainly not easy to follow for the outside observer and generally quite unsatisfactory to my mind.

sig-page.pdf
I have in fact started working on it

So the plan would be coherent entry points combining the main details of the sig, good quality linkage with the events system and drawing in content from the main aggregation and wiki (by tag naturally). Crucially the co-ordinators need customisable space to do with what they wish whether it be posting up some powerpoints or pointing to some interesting resources online somewhere – I need another pass of Mark and Sharon’s work as well as a round of discussion with co-ordinators to figure out exactly what really needs to be done.

3) The project tracker

Already discussed somewhat in my post about doap and ohloh I have a chunk of time set aside for re-working the project tracking system so we can reliably keep tabs on what is going on with JISC projects. Again this needs to be nicely integrated.

Example Project page

One last thing

There is one last thing. I propose removing all traces of rounded corners in favour of the infinitely superior square corners. Trendy design at it’s best don’t you think

The issues with it are around:

• coverage – only a small subset are currently included
• maintenance – new projects need adding, old projects need reviewing, there is no admin interface
• added value – various kinds of information would add to the usefulness of the site
• comments, ratings and reviews
• more links and aggregations from blogs, wikis, repositories etc
• relationships between projects – same developers, similar category
• relationships with interop standards – it uses FOAF, it uses IMS QTI etc (this should be linking in with the e-framework service expression definitions)
• indications of code quality and other metrics

So to some research – how might we go about developing this, and what exists out there in the same space?

DOAP

DOAP or Description Of A Project is a useful looking RDF-XML spec for describing projects. It has elements for descriptions, names, URLs (including those for source repositories) and person information by hooking in the FOAF spec.

There are a couple of models by which we could integrate this into a project tracker:

1. Host the DOAPs: Projects and staff fill in a form on the tracker site – the tracker site produces (persistant) doap xml.
2. Aggregate DOAPs: Projects host their own doap files – instead of filling out the form on the tracker site they can simply point it to their hosted file – the tracker then picks up the project details, feeds etc. They would be periodically spidered for updates. The files can be generated by a third party tool (doap-a-matic).

The aggreagtion approach is rather attractive from the point of view that projects become responsible for their own information. It is unattractive for the reason that projects may not bother to maintain such files properly. There is a further positive argument to say that if they don’t maintain their DOAP files, they should just be considered worthless and dead – such tough love might be just what they need.

As I have alluded to in earlier posts I’ve had a couple of discussions with Ross Gardler from OSS Watch who is also engaged in activities around tracking JISC’s projects. He is also interested in using DOAP to achieve this in combination with his beloved Apache Forrest.

DOAP me up: some useful DOAP resources

• The DOAP home page
• Doap-a-matic web-form to generate a DOAP
• There SHOULD be a validator service however it doesn’t seem to exist these days. I suspect link-rot…. which doesn’t excatly inspire confidence in the whole DOAP initiative

Ohloh

Then again there is always the question – why are we bothering at all with our own tracker when there are better solutions out there in the world. One such is Ohloh.net which does much of what we need; user comments, reviews, feed aggregation and general project information – and it really does the business when it comes to automated analysis of source code. I ran it over a little open source project I created and was delighted to learn that my efforts would be worth over 100 thousand dollars if I were being paid, that my code is mainly written in php and that there is a small development team of 2 people.

Samxom in Ohloh

This is just marvellous – and could even be used directly in combination with instructions to projects to employ little careful tagging. The word JISC perhaps might do the job. While it might be very web-2 and very trendy the con with this is that it is out of our control – and I’m not quite sure of the provenance and policy of Ohloh.

The silver lining to this cloud is that it brings the dfl installation more in line with the other cetis and intrawiki instances – and the even gooder news is that those instances were not affected at all. It may also be worth having a little re-jig of the mediawiki instances on the server to make the whole business of running a farm a little more resilient. But that is one for some other time.

This content is password protected. To view it please enter your password below:

Password: