Yesterday, Alex, Tony and I went to the University of Bath to meet with staff from UKOLN, who have agreed to be our proxy users for developing the supporting materials for the JISCPress project. Tony has just blogged a few thoughts ‘On the Different Roles Documents and Comments May Take in a Commentable Document’ and here are a few of my own.
The recent funding we received was to help ensure the sustainability of our initial project. We were awarded funding based on the proposal to address an accessibility review that had been commissioned on the digress.it plugin and to develop supporting materials for users of the WordPress/digress.it platform, which JISCPress is a version of.
At yesterday’s meeting, we introduced the project to people that knew very little about JISCPress and most of whom had not used it. Throughout the two hours of the meeting, a number of ideas about the use of the platform were discussed, some of which Tony has just blogged about. Whereas Tony’s reflections concentrate on the types of documents, I came away with a better understanding of the type of users the platform has, and when developing supporting materials, who they should be aimed at.
I can identify three type of user and therefore three areas of documentation that need to be developed:
- Site administrators
- Document Authors
- Document Readers/Commenters
In essence, the ‘benefits and realisation’ funding is concerned with ensuring the sustainability of the digress.it plugin through the uptake and sustained use of the plugin by these three types of users. For site administrators, guidance on how digress.it can work well with other WordPress plugins to assist with the efficient set up of a new site would be useful. For authors, advice on document construction, authoring tools (i.e. pros and cons of desktop clients vs. copy and paste from Word), guidance on comment moderation and suggestions on how to engage readers and sustain their engagement, came across as important from yesterday’s meeting. Likewise, document readers may need clear guidance on how a document site is constructed and can be navigated, but might also want advice on how to quote paragraph sections from the document on their own websites, or circulate references to a paragraph in an email to alert other people to a point in a document, for example.
Everyone felt that the documentation should be written so that it shows how the authoring and reading of a document using digress.it, can be embedded in the work flow of each type of user. It may be that certain changes must be made to that work flow, but as long as the plugin doesn’t rupture the work flow, it remains potentially useful to some people and some use cases.
In general, what do we need to try to ensure that the use of digress.it is sustained? Here’s my list:
- Useful code (i.e. a plugin that works)
- A community site
- Email discussion list
- Written documentation
- Visual support (screencasts)
- Examples of different types of use
- Examples where its use is probably inappropriate
- A comparison of alternatives
- Bug tracker/public code repository
Some items on this list are already in place; the rest will be in place by the end of September. In the meantime, Alex has addressed the accessibility review in his new theme, Eddie has nearly completed the next version of digress.it which has been significantly refactored and is now much quicker, leaner and easier to adapt, based on work he’s doing for regulationroom.org. There will also be a relaunch of the digress.it community site where the documentation and videos will be posted.
I’m on leave now until the end of August but will draft the documentation and plan the video tutorials as soon as I return to work. I’ll post them here and on the digress.it mailing list for comment, as well as seek detailed responses from staff at UKOLN before completing them at the end of September.
If you have any suggestions to add to the list above, do leave a comment. Thanks.