TOPIC:

Hi All on the Xerte forum,

Customisation code with Xerte, version install over-riding customisation & support to those authors who have customised using code.

As users become more experienced and brave with Xerte development, customising Xerte with code: html, styles, scripts, please can someone let me know the consequence of an Xerte version upgrade installation?

I realise that my next question is open to a reply which is an opinion, but I welcome responses please.

Perhaps some of you are of the opinion that from a support point of view, when Xerte authors develop Xerte LO's using code, support is tricky because the Xerte LO’s may be affected on an upgrade.

I think if I remember correctly it has been mentioned that a Xerte version upgrade installation may have a risk of affecting customised Xerte LO’s?

But what is your opinion about staff being prevented from customising?
Or what is your opinion regarding Xerte LO's which have been customised and the need to ensure that the author can, and will edit the new version with the code they have previously added.

I think that from a support point of view, would it be fair to say that support on customised Xerte LO’s is not available and that users (authors) need to ensure maintenance of their Xerte LO’s they are author of, making sure that the Xerte LO's are sustainable and future proof, even by colleagues, should the staff member (author) leave the organisation. Many software companies will support ‘Out of the box’ but not when system is customised.

Please let me know how you deal with this.

Likely to be a variety of responses. Thank you in advance for your comments.
My main concern is the legacy of having customised Xerte LO's with bespoke pages, and where the staff have left the organisation.

Anne

Hi Anne

My initial thoughts...

You can't really stop staff customising projects as even if you removed the 'script' & 'styles' optional properties from your install, all the text area fields in the Xerte editor can be turned to source view and css & scripts can be added directly there.

I doubt that the majority of upgrades would affect any customisation as even if pages are changed we normally keep the id names and classes of elements on the page the same (otherwise it causes more work for us too having to update all the stylesheets!)

To be realistic I think that there are very few staff members (here at Nottingham anyway) who would be likely to do the kind of customisation that could be affected by upgrade. I know of a handful here and the approach I normally take is after upgrade I test out a couple of their projects to make sure nothing is obviously broken. The responsibility does eventually lie with the author though for making sure their customisation still works so we make sure users know an upgrade is happening & notify them when it's complete.

Our release notes for an upgrade will let you know if major changes have been made to a page model so these are worth publicising before upgrade. These major changes happen rarely to be honest & the last page I remember properly rewriting was multiple perspectives which must have been a couple of years ago now. Just a new feature or option added is unlikely to break customisation I would have thought as we add them so that existing projects without the option added will still work in the same way.

Regarding users who leave the university - I don't know if there's much I can recommend about this issue to be honest. It's down to the staff member themselves to remember that someone might need to maintain their projects in the future after they leave & in my experience they rarely think of this! We hope the management pages will be changed in an upcoming version to make swapping projects from one user to another easier so this will help from an admin point of view but how staff members pass on their knowledge of any customisation they've done in their projects is out of our control. I can't think of an occasion this has come up as an issue at Nottingham though and we have 20300+ projects!

Overall I think you need to be a little careful about what customisation you recommend & to who. CSS changes should be fine & relatively risk free (even if the element names do change so styles aren't added it shouldn't stop projects from working).

I don't know if any of this helps!
Fay

Hi Fay,

Thank you so much for the information in your reply.

I use 'Announcements' here to communicate to staff with regard to Xerte.
I agree that after a Xerte version upgrade installation, it is the responsibility of the member of staff to ensure that a Xerte plays if it has been customised. I agree that it is the responsibility of the member of staff to share with a colleague what and how they have customised. Staff who leave know that they need to use 'Give this project' function, to give the project to a colleague before they leave.

Yes this helps all of us.
Best wishes
Anne

Hi all
just to add a few comments to what has already been said...

Custom code added to a particular learning object is not likely to break an entire installation and at worse should only affect the particular LO and any copies made of it containing the same code. There's also a world of difference between customisation within an LO and customisation of the core code within an installation e.g. When you say "Many software companies will support ‘Out of the box’ but not when system is customised." customisation within an LO isn't the "system" but customisation of the core code on the server itself is obviously the "system" and should be avoided unless whoever is doing that is well informed and doing that customisation in the correct way. Ideally contributing back to the Xerte project too.

Furthermore there's arguably a big difference between custom css added to an LO and custom script added to an LO so we can't just generalise with the term custom code.

Your question Anne seems to focus on the consequences of an upgrade on the LO's containing custom code. Obviously the answer to that really is it depends on the code and what it is doing and whether it is referring to things that have changed with the upgrade. It's impossible to say as each bit of custom code will differ. However in my experience in most cases if the customisation is working in a current installation it is usually likely to continue working in an upgraded installation and if there happens to be a conflict it's probably only the customisation that will no longer work rather than the whole LO but that's a generalisation and impossible to know for sure because it depends on what the code was doing and how it was doing it.

The most important aspect of all this though is that for the most part the ability to add customisations within an LO is a really powerful and beneficial thing to be able to do. Any individual that does so does need to check that everything works and continues to work but that's just as true and arguably even more so of whether the learning content works pedagogically. e.g. if learners report a techical issue you need to resolve it, if learners report an accessibility issue you need to resolve it and if learner feedback suggests your learning design needs to improve you need to improve it. In my experience some of the best LOs contain some form of customisation and often have been co-authored by those with design expertise, subject expertise, developer expertise etc etc. I see many more arguably broken LOs due to poor learning design than due to custom code and technical restriction obviously isn't the answer in that case either.

HTH
Ron