tag:blogger.com,1999:blog-55445303533810108262023-11-16T11:59:42.088+00:00Modular e- administration of TeachingThis is an informal blog from the e-admin project team.Anne Clarkehttp://www.blogger.com/profile/07312177913654529374noreply@blogger.comBlogger29125tag:blogger.com,1999:blog-5544530353381010826.post-62297588257888744382010-06-09T16:08:00.001+01:002010-06-09T16:09:15.778+01:00And there's more! User experience for groups on campusAs a follow-on to this project, we're going to be undertaking a study of group management user experiences for an institutional group management service, with the goal of creating designs for a group service user interface which matches genuine academic and scholarly behaviours and needs. <br />
<br />
<b><span style="font-size: large;">Background </span></b><br />
<br />
The MEAoT project explored two teaching administration tools - the teaching load database (allowing departments to track how teaching tasks are allocated across staff and research groups) and the Student Choices module. Both the main academic departments in the project had separately developed teaching administration systems in house, to support organisation tasks around teaching, and on closer analysis these were functionally ways of creating and managing groups of people, and then doing things with the groups (assigning tutors or lab sessions, emailing them, sharing files with them, and so on). The teaching load and student choices systems also had strong groups themes. We realised that tasks around groups of people were key to a variety of teaching administration, as well as other academic tasks, and that group management software might be the right common foundation for creating other specialised interfaces to support activities like teaching load, without the backend services burden we had in our project systems. We are interested in taking this forward by exploring and investigating in more detail the ways in which faculty, administrators and students think about the tasks they undertake which involve groups (even indirectly), and creating designs for systems which exploit group management to deliver powerful end user functionality.<br />
<br />
There is a broader interest in the UK HE community around group management. One tool which has been proposed in this space is <a href="http://www.internet2.edu/grouper/">Internet2’s Grouper</a>. This is a groups management toolkit which enables project managers, departments, institutions and end users to create and manage institutional and personal groups. It puts control of a group in the hands of its steward and enables the person to manage the membership and what resources it can access. Groups can then be used in all kinds of other applications, including teaching administration (as explored by our project), research management, and so on. <br />
<br />
The Grouper toolkit is developed by the Internet2 Middleware Initiative, and is supported by funds from Internet2, the University of Chicago, the University of Bristol, the NSF Middleware Initiative, and JISC.<br />
<br />
Like any group management suite, Grouper fits alongside an institutional identity management system and access management; it is an institutional level system and requires stakeholder buy in throughout the university to deploy, as policy and business rules must be established and agreed, as well as resources to implement. These are areas of increasing interest and engagement in the sector in the UK. We are aware of UK deployments of Grouper (e.g. Newcastle University), but we haven’t seen a user-friendly administrative interface for self-service by end users.<br />
<br />
<br />
Grouper is middleware, meaning there is no “public face” - no user interface which enables university decision makers to properly understand what it could do for their institutions. We intend to undertake user-centric research to explore the underlying needs of university academics, students and administrators around groups, and to prototype designs which would provide attractive and user-friendly potential user interfaces for Grouper. <br />
<br />
The availability of an attractive UI is expected to significantly increase the understanding among academic decision makers of the potential for Grouper as a key enterprise service. Greater adoption will make group services available to those promoting Service Oriented approaches in their institutions.<br />
<br />
In addition, our work will provide outline designs based on real academic needs for other groupware solutions, and group-oriented systems. These designs will stimulate debate and discussion within the sector and within institutions around the critical functions of group and identity management, and will provide a truly user-oriented focus, which will be of value in ensuring deployed solutions are usable and beneficial. <br />
<br />
In addition, they could form the nexus of new systems (similar to those of our MEAoT project) built using light weight development principles, to deliver novel end user functionality on top of campus-wide group management suites. This may also allow us to further develop our <a href="http://modular-e-admin.blogspot.com/2010/04/computing-for-person-in-street.html">“simple software” tenets</a>, which we uncovered during MEAoT, which if followed enable those who are not software specialists to maintain and modify useful (and possibly niche) tools.<br />
<br />
<span style="font-size: large;"><b>Benefits to the Institutional Innovation programme and to the sector</b></span><br />
<br />
Our focus on group management reflects the growing use of centralised IT services within institutions, and supports existing and ongoing institutional-level strategies around identity management and its application to IT services around and across the university. <br />
<br />
We address two key areas of ICT concern in HE today: how to support academics and students engaged in teaching, learning and research with emergent and social technologies including self-service systems, and e-administration; these are two of the four areas targeted by the Institutional Innovation programme. Group management is a recognised cross-departmental and cross domain problem with core applications in each of these areas, which fits within the e-Framework for Education and Research (being based upon open standards and service oriented approaches), and is where appropriate technology and processes can support people by allowing them to make a greater contribution to the core business of their university. <br />
<br />
Academics and students expect more from their institution’s ICT provision, as they become used to more engaging, interactive and social user interfaces in their personal web and technology use. They increasingly demand the easy to use self-service systems they have encountered elsewhere within their ICT at work and study; the question of how these emerging practices may be supported within institutional IT systems is a critical one addressed by our proposal, and others in this programme. We will explore how these interfaces can be integrated into groupware, which will work in conjunction with other IT platforms within the university environment, using service oriented approaches such as those of the e-Framework. The ideas of group formation and using groups of people for access control and organisation of information - on an institutional scale and across institutional systems and departmental systems - also naturally encourage reuse and remixing of data (groups, who is in them and what access they have) within different systems.<br />
<br />
As well as being a strong match for the key concerns of the programme, our plan fits well within the Institutional Innovation project types, in that it investigates and explores a potential technology solution, including engaging, interactive and user friendly user interface designs. It is a relevant follow on to other user interface work in the <a href="http://www.jisc.ac.uk/whatwedo/programmes/programme_users_and_innovation.aspx%20">Users and Innovation (U&I) programme</a>, and the more recent <a href="http://www.jisc.ac.uk/fundingopportunities/funding_calls/2008/02/circular0108.aspx">Institutional Responses to Emergent Technology pilots</a> under the e-Administration programme, which addressed individual and institutional aspects of next generation technologies. <br />
<br />
Our work will lead to further technical prototyping and pilot projects, which will enable universities and the sector to trial systems with their users, and demonstrate that this area offers value to make it worthwhile to move into larger scale pilot programmes. The output designs of this project will help senior stakeholders and decision makers to start to appreciate and understand the value of ICT investment in the area of groupware and related systems.<br />
<br />
Group management systems are also often critical for delivery of powerful e-administration tools, which attempt to coordinate and control business process information within academia, for greater efficiency and effectiveness. Access control and authorization for university data creation, access, management, archiving, disposal etc is a key part of e-administration, and group-based controls are ideal for these functions. Groupware also supports the diverse range of resources being created and managed by various parts of institutions, including libraries and departments, and enables easier management of remote access to these resources.<br />
<br />
<span style="font-size: large;"><b>Outputs</b></span> <br />
<br />
This work will help us build upon the nascent expertise from our <a href="http://www.jisc.ac.uk/whatwedo/programmes/institutionalinnovation/academicsocialnetworking.aspx">JISC Institutional Innovation </a><a href="http://academic-networking.blogspot.com/">Academic Social Networking project</a>, as well as increasing the resources we can share for others in the sector to reuse in the area of user-centric design within HE.<br />
<br />
We anticipate working with JISC to disseminate our final designs for exemplar group management user interfaces, which will apply to Grouper backend services as well as other groupware solutions. These designs will act as a focal point for debate around group management solutions in HE, as well as a powerful starting point for innovative development of user interfaces for them. We will also share our learnings online during the process of the project, around user-centric design and group management within HE.<br />
<i><br />
As a result of this work we will produce a set of user interface designs which will allow other projects and institutions to explore, prototype and pilot user-friendly group management systems on campus, with a substantial kick-start from our user-centric design work. Alongside this we will create and distribute “sales” material which will explain the designs and their significance to senior management in university IT, administration, teaching and research, enabling their institutions to discuss and evaluate groupware in a more meaningful context. Other projects and institutions will be able to take our learning and designs to give themselves a headstart (avoiding the challenges of understanding real user needs in this tricky area) in investigating and deploying group management tools.</i>Unknownnoreply@blogger.com2tag:blogger.com,1999:blog-5544530353381010826.post-82276382068860441462010-06-07T08:08:00.001+01:002010-06-07T08:08:52.567+01:00the MAW of HEFCEProf. Peter Barrett writes in the <a href="http://www.timeshighereducation.co.uk/story.asp?sectioncode=26&storycode=411787">27 May TES</a> about a HEFCE-funded project on Managing Academic Workload, led by him and Lucinda Barrett at the University of Salford and involving 20 partner institutions. The project has recently published a report; "<a href="http://www.research.salford.ac.uk/maw/cms/resources/uploadsbarrettfinalsept09%282%29.pdf">Management of Academic Workloads: Improving Practice in the Sector</a>".<br />
<br />
It is interesting to see such a rich analysis of the benefits of 'confidently transparent' workload allocation and of being 'roughly right not precisely wrong'. Also notable is that despite having developed an institution-wide system, the report nevertheless affirms the importance of leaving workload allocation decisions in the hands of departments, in whose management staff are more generally willing to place some trust.<br />
<br />
MAW has open-sourced a spreadsheet-based system originally developed by Prof. Barrett and now used by all departments at Salford University.aewp2http://www.blogger.com/profile/05865087342440641011noreply@blogger.com0tag:blogger.com,1999:blog-5544530353381010826.post-76343937777839330762010-04-30T13:06:00.003+01:002010-04-30T13:09:43.549+01:00computing for the person in the streetOr in our case, the person in the teaching office!<br /><br />Our "<a href="http://modular-e-admin.blogspot.com/2010/04/developing-simple-software.html">tenets for software that can be maintained by non-specialists</a>" might have some things in common with Jef Raskin's "<a href="http://library.stanford.edu/mac/primary/docs/bom/anthrophilic.html">Design Considerations for an Anthropophilic Computer</a>" (28-29 May 1979). Simple hardware is not that unlike simple software: dispensing with multiple modes, interfaces with other systems, no libraries you can't find or understand...Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-5544530353381010826.post-75184180223332085582010-04-27T12:27:00.001+01:002010-04-27T12:28:16.998+01:00Closing summary<span style="font-style: italic;">We reproduce here the executive summary from our final report:</span><br /><br />Most universities have a central IT function. Despite this, or sometimes because of it, individual departments and academics are frequently motivated to develop ʻhome grownʼ IT systems, to fulfill unmet needs or to support particular departmental processes. These systems are often small and minimally complex, but highly fit for purpose, and likely to be of wider benefit.<br /><br />This project took two such e-administration modules, originally developed (or part-developed) for internal use by the departments of Physics and Engineering at the University of Cambridge, and sought to extend their use to other departments, including those which would not have considered developing their own software internally.<br /><br />The Engineering Department took the lead in developing and deploying a staff teaching duties allocation module generally known as the Teaching Office Database, or TODB. The Department of Physics took the lead in developing a module for recording and managing studentʼs course options, known as the Student Choices module. The Centre for Applied Research in Educational Technologies (CARET) provided project co-ordination and development staff.<br /><br />Student Choices attempted to follow a standard software development and deployment process, in which the needs of a variety of possible users are met (or traded off) within a single piece of software. Users would be expected to maintain the project beyond the development phase using common OSS practices, contributing patches to a central version or ʻtrunkʼ.<br /><br />TODB followed an innovative ʻtrunklessʼ model. Instead of complicating the software by making it meet many peoplesʼ needs at once, each user received a version customised for their specific needs. By this expedient the software is made simple and is easily related by users to their working practices, so that they are comfortable taking full ownership of it themselves. At the conclusion of this part of the project, TODB has been successfully customised and deployed to seven different departments.<br /><br />Although the Student Choices module did not find users beyond the Physics department, its development has served as motivation and specification for the Universityʼs centrally-administered student information system, which has decided to offer similar functionality to the University as a whole. The inclusion of Student Choices in the e-Administration project also provided a valuable alternative perspective on sustaining ʻorganically grownʼ IT sytems.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-5544530353381010826.post-56595263595334690702010-04-26T12:10:00.005+01:002010-05-17T15:23:45.341+01:00Project OutputsContinuing our wrapping-up theme, we've put together a list of links to code, demonstrations and documents we've produced during the project. The final report of the project has been posted on the <a href="http://www.jisc.ac.uk/whatwedo/programmes/institutionalinnovation/modulareadminofteaching.aspx">JISC website</a>, but we promised to include all the links right here as well so here they are:<br />
<br />
<b>Final Report</b><br />
<ul><li><a href="http://www.jisc.ac.uk/media/documents/programmes/institutionalinnovation/meaotfinalreport.pdf">Final Report of the e-Administration of Teaching Project</a></li>
<li><a href="http://www.jisc.ac.uk/media/documents/programmes/institutionalinnovation/meaotappendixa.pdf">Appendix A - Overview of differences between departmental TODBs</a></li>
<li><a href="http://www.jisc.ac.uk/media/documents/programmes/institutionalinnovation/meaotappendixb.pdf">Appendix B - e-Administration Requirements Specification</a> </li>
</ul><br />
<span style="font-weight: bold;">White papers</span><br />
<ul><li><a href="http://www.caret.cam.ac.uk/wp-content/uploads/2008/12/Principles-of-Simple-Software-Development.pdf">Principles of Simple Software Development</a><br />
</li>
<li><a href="http://www.caret.cam.ac.uk/wp-content/uploads/2008/12/The-Trunkless-Development-Model.pdf">The Trunkless Development Model</a></li>
</ul><span style="font-weight: bold;"><br />
Project web pages</span><br />
<ul><li><a href="http://modular-e-admin.blogspot.com/">This blog</a><br />
</li>
<li><a href="http://www.caret.cam.ac.uk/page/modular-e-administration-of-teaching">Project page on the CARET website</a><br />
</li>
</ul><br />
<span style="font-weight: bold;">Google Code sites</span><br />
<ul><li><a href="http://code.google.com/p/todb/">TODB Google Code site</a><br />
</li>
<li><a href="http://code.google.com/p/studentchoices/">Student Choices Google Code site</a><br />
</li>
</ul><br />
<span style="font-weight: bold;">TODB documentation</span><br />
<ul><li><a href="http://todb-demo.caret.cam.ac.uk/">TODB demo site</a><br />
</li>
<li><a href="http://todb.googlecode.com/files/Teaching%20Office%20Database%20Installation%20Configuration.pdf">TODB installation and configuration guide</a><br />
</li>
<li><a href="http://todb.googlecode.com/files/Teaching%20Office%20Database%20Developers%20Guide.pdf">TODB developers' guide</a><br />
</li>
<li><a href="http://todb.googlecode.com/files/TODBUserGuide.pdf">TODB user guide</a></li>
<li><a href="http://todb.googlecode.com/files/TODB%20Modification%20Journey.pdf">TODB modification journey</a> (sequence of customisations)<br />
</li>
<li><a href="http://todb.googlecode.com/files/TODB%20How%20To.pdf">TODB 'How To' guide</a><br />
</li>
</ul><br />
<span style="font-weight: bold;">Sakai</span><br />
<ul><li><a href="http://confluence.sakaiproject.org/display/GROUPS/Sakai+3+Groups+Home+Page">Sakai work on 'groups' concept</a><br />
</li>
</ul>aewp2http://www.blogger.com/profile/05865087342440641011noreply@blogger.com0tag:blogger.com,1999:blog-5544530353381010826.post-41808301336747657512010-04-23T19:05:00.004+01:002010-04-23T19:14:06.976+01:00Comparison of software development approachesFollowing on from our last post, about 'trunkless' software development, we want to share some thoughts about when it might be useful to consider that model. Many thanks to Matthew Jones, now of the <a href="http://www.sasa.org.za/sasri_overview615.aspx">South African Sugar Cane Research Institute</a>, who developed much of this thinking.<br /><span style="font-weight: bold;">Centralised systems in the Cambridge University context</span><br />The University of Cambridge is, to a greater degree than most, a loose collection of independent or largely-independent colleges and departments. Each department (and each college, if the TODB is extended this widely) prides itself on its independence, so there is potentially large diversity in the way that teaching is organised in different departments. This independence is fiercely guarded as part and parcel of academic freedom. These conditions create considerable scepticism about centralised 'one-size-fits-all' software. The University’s cultural memory records the deployment of recent centralised IT systems as being painful experiences. This strengthens the distrust of centrally-provided software. The organic, per-department approach followed with the TODB avoids running foul of this by customising the software for each department and allowing each instance to be locally managed. From departments’ point of view, this avoids the risk and overhead of engaging with central bodies who have many other priorities to balance and may deliver an unsatisfactory one-size fits all solution.<br /><span style="font-weight: bold;">Quick and dependency-free operation</span><br />One of the advantages offered by small, independent and non-centralised software is that the usual dependencies that might apply bluntly in a large institution will not necessarily be enforced. For example, under most teaching circumstances, a member of staff will be appointed formally, will appear on a central staff database, and their information eventually trickles down to where it is needed. In a situation where a representative of industry gives a single lecture, they need not be formally appointed as a member of staff for the duration of that lecture. In the TODB, if the people list was 'formal' and enforced, it would be difficult to accommodate such people unless special provision was made in the system. By severing links with central systems, it is very easy to add that person as a member of staff – or even assign a job to them without them appearing in the people list. The work is accounted for. Centralised systems require far more prescription, consistency and formality in their operation in order to adequately handle their greater scope – and this is not necessarily how a Cambridge University department operates, or is willing to operate. The cost of course is the inability to synchronise information when this is desired – when a new member of staff joins, or someone retires.<br /><span style="font-weight: bold;">Iterative participation</span><br />Rather than trying to develop a set of requirements from discussions about abstract concepts in the first phase of the project and then going ahead and developing the software, the constant to-and-fro between the developers and the project participants made for a very much richer interaction and engagement. It is felt that better software resulted – and not only this; as the stakeholders have been present in the software development process for up a to year already, those individuals probably feel that their contributions to the software have been substantial and worthwhile, and will feel a much greater desire to use the software.<br />The centralised, phased alternative is far less personal: each individual's contributions become diluted by time and the necessity to manage conflicting requirements for the software (where multiple stakeholders are consulted for the development of a single centralised piece of software). With the TODB approach, rather than an individual's desires having been 'taken into account', they are, in general, reflected in the implementation. That said, the phased/centralised model usually has one or more feedback iterations anyway; nevertheless, it is felt that this software development approach supported true engagement with the project's stakeholders. In fact, this could be considered an outstandingly successful aspect of the approach taken.<br /><span style="font-weight: bold;">Use of an initial prototype</span><br />A number of participants expressed the view that an important success factor in this project was the availability from the start of a prototype system: the original, developed within Engineering. The prototype gave concrete form to what would otherwise have been a hard-to-visualise and far-off concept. It also meant that rather than being expected to develop ab initio for each department, customisation was limited to adapting the prototype, reducing to manageable proportions inter-departmental differences. It should be noted that the development and distribution of a ‘prototype’ originating in a particular department is a key part of this software development model. Developing a prototype remains a fairly substantial software development exercise, but where a prototype is available, this model is highly appropriate.<br />We have also seen, in the case of TIS, that software originated by individual academics or departments can be both motivation and specification for others, including central institutional IT departments, who wish to take on, extend, productionise and institutionalise the software.<br /><span style="font-weight: bold;">Resource allocation considerations</span><br />It is worth noting that the trunkless model is not free - it simply offers an alternative division of resources. The cost is borne by the funder of initial customisation and roll-out - JISC in this case - and by departments, in slight but ongoing hosting and maintenance duties for their computer officers.<br />The TODB process consumed substantial resource in terms of project staff time. In future it should be considered whether beneficiary departments will realise sufficient value from the software to justify funding a developer for some time - two months in the case of TODB - to customise and support their adoption of it.<br />Without knowing the extent of stakeholder differences, it is difficult to predict how much software development work will be required for a 'trunkless' project. Unexpectedly high variability would require more customisation. Much of this risk is easily controlled by engaging potential adopter departments with a prototype before beginning the project, and setting expectations in terms of development priorities rather than an ‘all you can eat‘ menu.<br />Even though structural differences may be present at department level, at a broader level University departments are roughly similar: students are lectured and examined by representatives of the department and colleges. Given this large commonality, it would seem likely that software that assisted and addressed teaching issues at this level would be useful. Generally speaking, larger budgets are allocated to projects with larger numbers of clients – so where a centralised systems is viable, it might be expected to be a more polished, feature-rich product.<br /><span style="font-weight: bold;">Software simplicity and functionality</span><br />The 'locally-maintained' or ‘trunkless’ aspect of this unconventional software development approach requires a careful approach to software complexity. Given the profile of the expected person in charge of further development of TODB in a department – an interested academic, a computer officer, possibly a summer student – the software really does need to be simple and straightforward, placing a higher value on this than even ‘best practice’ computer science conventions (highly structured abstractions, data models, etc).<br />This leads to two issues for consideration:<br /><ul><li>What is simple software? What are the conventions to be avoided? Essentially, how is the line drawn between acceptably-simple and unacceptably-complex coding approaches? In this project, the TODB had been initially developed by a non-expert, and was extended in a similar style. Although PHP and MySQL had already been chosen as the underlying technology for the TODB, these can be considered relatively easy technologies in which to acquire basic competence. </li><li>To some extent, a tradeoff exists between complexity and functionality. This certainly does not hold in all cases, but there are definite situations where the code required to achieve a certain level of functionality will be more complex than might ideally be found in a 'simple, straightforward' system designed to be maintained and extended by non-experts. In practice, in such situations, either the complex functionality was not included in the software, or small sections of code within the TODB have complexity that exceeds the ideal target. Overall, however, it is felt that the software abides by the 'simple, straightforward' principle.</li></ul>Further, computer scientists will argue that many of the conventions that have evolved in professional software development are intended to ease and simplify the software development process. Use of mature and proven software libraries comes at the cost of learning the libraries and applying some forethought to avoid situations where the use of the library limits possibilities; in return, it provides a clearer and more maintainable software source, which is also more likely to work properly because a smaller proportion of the total product is new and relatively untested. Writing 'simple, straightforward' code – that avoids using libraries because of their learning curves – is actually more difficult, because developers are required to develop and test more from scratch. It is possible then that this approach is more costly in time and effort. Code that uses well-known libraries tends to be clearer and easier to follow if the reader is familiar with the libraries; in such cases, understanding the code of a completely built-from-scratch system can be a formidable task in itself.<br />In the specific case of TODB, it was noticed that in order to ensure that the database is as simple and straightforward as possible, the SQL queries in the code are more complicated than they might otherwise be. This appears to be another tradeoff, where the complexity is defined more by the functional requirements than by how the solution is implemented.<br /><span style="font-weight: bold;">Software support</span><br />The development of a software product usually also develops a software support problem. For an institution like CARET, apart from allocating the resources required to liaise with users and write the code, people need to be trained for support as well. Criticism of the software development methodology used with the TODB has been leveled at the difficulty in supporting software that, at the time of release, has eight slightly different versions, and may have been independently modified further without knowledge of changes being fed back to the support team. The simple answer is – there is no support burden! The whole point of the trunkless, decentralised model is that departments are self-supporting. This is a 'launch and forget' model. Were such a model used more widely, it would be wonderful for software developers, who traditionally enjoy developing new things and despise the 'housework' of ongoing support. The temptation to compromise the constant focus on local maintainability must be held in check, however.<br />In practice, it is possible that departments who make few changes to the software might require some support. CARET will provide support as required to Cambridge departments using versions of the software, as part of our institutional contribution to the project. Those departments which engage with the software to the point of making substantial changes to the code are likely not to need support – as their own competence at that stage will be quite sufficient to address any TODB-specific support challenges they encounter.<br />The Google Code site7 used to make the generic code widely available also supports community features including a mailing list, wiki, and bug tracking, creating an infrastructure for community-based support in the style of a ‘trunked’ OSS project. Although in future it might be expected that some users will develop their TODB instances away from being in a position to offer mutual support, it might also be expected that they would be replenished by new adopters. Support within Cambridge will be mediated by a group mailing list and a backed-up CARET SVN repository containing all versions of the software, plus Cambridge-specific documentation.<br />Departments have been warned that although CARET will provide support this will not include further code customisations and will not be of the intensive level available during the project.<br /><span style="font-weight: bold;">Project scale</span><br />The approach of developing a rough prototype and then working individually with eight departments approximately in parallel was excellent for a product of the relatively small scale and complexity of TODB.<br />Each instance of the TODB is somewhat different. Maintaining eight independent branches means each time a change is made to one that might be useful to all, a rather laborious merging process is required to ensure that the new functionality is available in other departments but does not overwrite some other department-specific changes. This was manageable for the e-Admin TODB project development, but if the application had been much larger, or if there had been many more departments involved, it might not have been. On this basis the approach is very favourable for small projects and may be untenable for larger ones.<br />The situation might be retrieved using the approach, previously discussed, of separately modularising ‘core’ and ‘custom’ code - as long as this can be successfully reconciled with the need to eliminate avoidable abstraction. It is worth noting also that Biochemistry, the last department to join the project, benefitted from a relatively mature TODB and required very few customisations. This suggests that the support requirement may not scale linearly with the number of departments, as early lessons are incorporated and it becomes progressively harder to find new bugs or feature requests.<br />It will be interesting to monitor how future development by departments is merged, or not, with the generic version after the end of the project. CARET will monitor this as part of our evaluation of the processes discussed here, including beyond the end of the project.<br /><span style="font-weight: bold;">Specification-variability considerations</span><br />Where proposed software is required to accommodate large variability between 'branches' (such as in this case, between departments), the TODB development model scales elegantly and well: where variability is small, the development approach more closely resembles a more conventional software development project; and where variability is large, this approach allows each instance to be quite different and for the differences to be pursued independently. This makes it a powerful model. Centrally hosted and supported software has its advantages, however, and the TODB development model could be changed to a conventional centralised model if it transpired that inter-stakeholder differences are very small. The only danger of such a decision might be that the architecture of the system might be inappropriate – as software designed to be maintained by 'non experts', and so free of abstractions, use of 3rd-party libraries and so on, might, perversely, be less efficiently maintained by 'professionals'.<br />Inter-instance compatibility<br />In general, it does not matter what each department does with its instance of TODB after release. The one caveat to this is with the benefits that would accrue to have TODBs communicate with each other. Being able to view the activities of a staff member in another department (in a shared lecturing environment) can be extremely valuable. There is a danger that this communication mechanism could break down through uncoordinated changes.aewp2http://www.blogger.com/profile/05865087342440641011noreply@blogger.com0tag:blogger.com,1999:blog-5544530353381010826.post-33097936349432655242010-04-23T18:56:00.002+01:002010-04-23T19:05:10.431+01:00'Trunkless' developmentFollowing on from our last post, about developing simple software, we'd like to describe how we used this in practice, taking the Engineering Department's TODB software, making custom versions for six other departments, and making them feel able to take responsibility for maintaining and supporting it into the future.<br />We plan to publish this also as part of a companion whitepaper to the e-Admin project final report.<br /><span style="font-weight: bold;">Overview</span><br />A method of spreading user-originated software in HEIs, which allows each user a ‘made to measure’ customised version of the software, for which they are subsequently able to take complete responsibility.<br /><span style="font-weight: bold;">Model summary</span><br /><ol><li>Prototype developed by originating user</li><li>Other users interested</li><li>Central, one-off funding obtained for development</li><li>Software is genericised, with a view to making expected range of stakeholder-specific customisations manageable</li><li>Software deployed and customised user by user. Users and developers agree priorities for development.</li><li>Lessons are incorporated back in to generic version and pushed to previously-addressed departments</li><li>Detailed, tested documentation and handover to users</li></ol><span style="font-weight: bold;">Prerequisites</span><br /><ul><li>A working prototype exists</li><li>At least some partner institutions have expressed an interest in evaluation with a view to adoption</li><li>Institutional IT systems are unlikely or unable to assume similar functions in the project timeframe</li></ul><span style="font-weight: bold;">Suitable projects</span><br /><ul><li>Small to medium-sized applications in which the use of frameworks, large or numerous libraries, or substantial amounts of abstraction is unnecessary. It is worth noting that lots of ‘big’ projects are actually small, once all the abstraction and configuration capability needed to handle different user requirements is stripped out.</li><li>Projects with a user base of approximately 3-20 users, each with distinct needs. If the numbers are larger or the requirements uniform then a traditional open-source approach is likely more efficient.</li><li>The risk of having to apply similar and significant changes to all systems subsequent to deployment is small.</li><li>It is not critical that all systems interoperate consistently. If it is, then centralised systems are likely to be more effective, as the overhead of 'softly' maintaining interfaces will offset the advantages of locally-maintained, locally-modified software.</li><li>Administrative tools are in general likely candidates. </li></ul><span style="font-weight: bold;">Model benefits</span><br /><ul><li>Software which, being created by academics, addresses their particular needs very well, can be genericised and then customised repeatedly for other users. Traditional, centrally budgeted and supported systems would not be able to provide such customisation at a reasonable cost owing to ongoing support requirements, and in any case are unlikely to invest a great deal of effort on behalf of relatively limited numbers of users, unless there are substantial financial or educational benefits.</li></ul><span style="font-weight: bold;">Model limitations</span><br /><ul><li>Originators are by definition able to resource a modest level of formal or informal development, and are likely to be able to do so again, if necessary. However, without the benefit of JISC or other capital funding it is not possible to re-engineer and distribute systems in this way. </li><li>Less well-resourced adopters will be able to maintain the software, but not to extend or make significant modifications.</li><li>The model is good as long as it is not subsequently necessary to apply similar but significant changes to all the deployed, customised systems, in which case support cost has been multiplied. </li><li>The model accommodates large variations between sets of users, and becomes leaner, more efficient, and more like a conventional ‘one size fits all’ development approach as this variability decreases. It might become apparent that actually a one size fits all approach would have been appropriate, in which case architectural inefficiency might result from having followed the TODB approach initially. </li><li>This kind of project might benefit from having fewer staff, for a longer period; or from being able to draw on a developer ‘pool’. This would overcome difficulties in hiring great staff for a short term. Longer, lower intensity projects also allow more time to talk and work with other institutions, once the local systems and processes were established.</li></ul><span style="font-weight: bold;">Caveats</span><br />Because our partner departments are only now, at the end of the project, falling back on their own capabilities for maintenance and support, and because none save Engineering have as yet used the software over a complete academic year, we can not say that evaluation is finished. It needs a long view over coming years, which CARET will be providing.aewp2http://www.blogger.com/profile/05865087342440641011noreply@blogger.com0tag:blogger.com,1999:blog-5544530353381010826.post-20429090561629244562010-04-23T18:48:00.002+01:002010-04-23T18:56:15.519+01:00Developing Simple SoftwareThese are the principles we used to guide our development of software which would be deployed and maintained locally in university departments by non-professional programmers, such as computer officers, competent academics, even summer students. We are planning to also publish them as a white paper companion piece to the e-Admin project's final report.<br /><span style="font-weight: bold;">Appropriate to the task</span><br />Software involving workflow through numerous or systems or users, especially complex ones or those outside the maintainer’s sphere of influence, is inherently unlikely to be ‘simple’. Similarly for software which must be used by many different users, or which involves high-stakes or confidential operations. <br /><span style="font-weight: bold;">No external libraries</span><br />Libraries are ‘black boxes’ for those unfamiliar with them and make it more difficult to build a mental model of the software. Application frameworks are bad for the same reason - they might be great for professional programmers, but they introduce a huge amount of noise for novices. External libraries get updated, maintained and retired, adding work for the diligent application maintainer, especially if they are popular targets for security hacks.<br />This rule is flexible, within reason - sometimes a library or API might be the only reasonable way of achieving something, Shibboleth login for instance, but the impact on the maintainer but always weigh heavy in the balance.<br /><span style="font-weight: bold;">No abstractions</span><br />Abstractions are usually introduced to promote code re-use and support configuration for different users. Even if well explained and documented, they make it harder for someone unfamiliar with a program to understand how it works. Lots of ‘big’ projects are actually small, once all the abstraction and configuration capability needed to handle different user requirements is stripped out.<br /><span style="font-weight: bold;">Novice-friendly</span><br />Professional software developers will want to apply their ideas about best practice, appropriate tools, and software architecture. All this draws on considerable background knowledge and context, without which none of these things makes much sense. Put best practices to one side and consider the novice user. How would someone whose background consists of “PHP in 24 hours” approach the problem?<br /><span style="font-weight: bold;">The code is the configuration</span><br />Don’t try too hard to bring all possible configuration parameters into one place. Parameters such as text labels clearly benefit from extraction, but creating configuration abilities beyond that basic level requires increasing abstraction and alternative execution paths in the code, placing a larger barrier in the path of subsequent maintainers and developers, and risking the counterproductive situation where understanding the configuration language is as difficult as understanding source code. <br /><span style="font-weight: bold;">Users know what they’re doing</span><br />I.E., users have a reasonable mental model of the process and data structures. The tool should support that mental model, and not attempt to second-guess or restrict their actions. <br />For example instead of enforcing strict referential integrity, TODB provides operations that assist the user in locating anomalies, e.g. a query that lists all jobs allocated to people who are not found in the database6. In a typical database scenario it would not be possible to allocate a job to a non-existent person, but this is possible on paper, and in the mind of the teaching administrator, so that to impose such a restriction in the software would only interfere with their working and thinking process.aewp2http://www.blogger.com/profile/05865087342440641011noreply@blogger.com0tag:blogger.com,1999:blog-5544530353381010826.post-83954565188213441052010-04-23T11:18:00.002+01:002010-04-23T11:34:11.136+01:00tasty outcomesYesterday, the project team met to complete our programme evaluation. In our discussions, we summarised the outcomes of the project:<br /><br /><ul><li>two examples of a prototype user-generated software system providing a requirements definition or specification for use in further work</li><li>provided a model of how simple software development principles can provide a system which non-specialists can deploy and maintain</li><li>an example of a sustainable development model, where non-technical end users can maintain and modify their own software</li><li>an example of how experimental software development, merely by happening, can catalyse institutional change in policy and process; the software development may not be part of the eventual solution, but if the original need is met by other processes/systems, it is a good outcome</li><li>we learnt that arts, social science and humanities departments often have strong technical skills!</li></ul><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://farm4.static.flickr.com/3280/2638831430_afc0b9108f_m.jpg"><img style="display: block; margin: 0px auto 10px; text-align: center; cursor: pointer; width: 240px; height: 208px;" src="http://farm4.static.flickr.com/3280/2638831430_afc0b9108f_m.jpg" alt="" border="0" /></a><br />Photo by PetitPlat by sk_ - http://flic.kr/p/52bGDCUnknownnoreply@blogger.com1tag:blogger.com,1999:blog-5544530353381010826.post-5767105613601044312010-04-22T14:57:00.002+01:002010-04-22T15:00:51.023+01:00wrapping upThe project team is currently wrapping up the final loose ends for "MEAoT". I think one thing we've learned is that acronyms can be very ugly, and it might sometimes be better to stick with a nice meaningful name!<br /><br />We've had some people join us towards the end of the project, with Guy Chisholm working hard on the latest iteration of the Student Choices software, and Amyas Phillips coming in to help evaluate our work, and to check that our "client" departments had all had good experiences.<br /><br />We'll be sharing our final report, and associated other reports, here shortly.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-5544530353381010826.post-77202627758082590432010-03-11T11:53:00.001+00:002010-03-11T12:02:09.573+00:00Update from the Teaching Office Database SystemHere is an update on what has been achieved by the Teaching Office Database (TODB) project as it enters its final stages.<br /><br />We have worked with the Engineering Department and six other Departments to develop customised versions of the Teaching Office Database (TODB) system for them. Many enhancements made along the way have been ‘retrofitted’ to systems which were visited earlier in the development cycle.<br /><br />All of these 6 ‘new’ departments plan to use TODB for the next academic year and have claimed for the funding to cover their costs involved in participating in the project. Three of these now have their own copy of the software which they are running on their own servers. The other 3 are in the process of doing this. I have met with or arranged to meet with the Computer Officers from each department to make sure they feel confident to host and support the system. A mailing list for these computer officers will be set up to facilitate interdepartmental communication about TODB queries.<br /><br />A generic version of TODB, which is designed to be easily customised, has been developed and will be released under an Open Source Licence. Accompanying documentation will shortly be evaluated by an independent member of CARET. This includes a User Guide which is linked to a Help button in the application, an Installation and Configuration Guide, a Developer’s Guide and a ‘How To’ Guide intended to point to the solutions to normal requests and queries.<br /><br />We have recently had an enquiry from a new department who are interested in adopting the system. They have seen the generic system and feel that they will be able to take this ‘off-the-shelf’. This would seem to be verification that this process has produced a useful and tuneable product.Anne Clarkehttp://www.blogger.com/profile/07312177913654529374noreply@blogger.com0tag:blogger.com,1999:blog-5544530353381010826.post-51849533708873729942010-02-01T10:05:00.006+00:002010-02-01T14:42:04.792+00:00Institutional Innovation Exchange<pre wrap="" style="font-family:trebuchet ms;"><span style="font-size:130%;"><span style=";font-family:times new roman;font-size:130%;" >We all went out to Aston, on the little pond's shore line</span><span style="font-size:130%;"><br /></span><span style=";font-family:times new roman;font-size:130%;" >To trade products with some tokens, we didn't have much time</span><span style="font-size:130%;"><br /></span><span style=";font-family:times new roman;font-size:130%;" >Lawrie Phipps and the support team found the best place around</span><span style="font-size:130%;"><br /></span><span style=";font-family:times new roman;font-size:130%;" >With lots of coffee, food and good wine, we sold our stuff by the </span><span style=";font-family:times new roman;font-size:130%;" >pound</span><span style="font-size:130%;"><br /></span><span style=";font-family:times new roman;font-size:130%;" >Talks on the water</span><span style="font-size:130%;"><br /></span><span style=";font-family:times new roman;font-size:130%;" >and products in the sky</span><span style="font-size:130%;"><br /><br /><span style="font-family:times new roman;">----------------</span></span><br /></span></pre><span style="font-size:130%;"><span style="font-family:times new roman;">The "trade fair" in Aston University was an interesting event, allowing us to gauge interest in our "products" for the first time. Ours did not sell much, but we prefer to think of it as a niche product, suitable for the more </span></span><span style="font-size:130%;"><span style="font-family:times new roman;">discerning academic customer. We did get interesting comments, though, and we learned from this experiment.</span><br /><br /><span style="font-family:times new roman;">The JISC organisation of the event was flawless. We had very nice accommodation, decent food and lots of free caffeine. We couldn't really ask for more. The support team did its best to encourage us out of our shells and to present our projects to the "general" public.</span><br /><br />--------------<br /><br /></span><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiOTO9t8Snr6c-Ijh_cQvaxzZtR57yx0VyW_u9mjqvD-Bu_0dJe4YEC_sA0t9sJMOIVcoP50zOk6NfMGYSW3EKFEkERlXI628lu-DVUexB16OxDnDtHGe-Hur6ULTnFwR4E3gj2MIZ__Ju_/s1600-h/TODBv2.png"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer; width: 282px; height: 400px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiOTO9t8Snr6c-Ijh_cQvaxzZtR57yx0VyW_u9mjqvD-Bu_0dJe4YEC_sA0t9sJMOIVcoP50zOk6NfMGYSW3EKFEkERlXI628lu-DVUexB16OxDnDtHGe-Hur6ULTnFwR4E3gj2MIZ__Ju_/s400/TODBv2.png" alt="" id="BLOGGER_PHOTO_ID_5433284916931925234" border="0" /></a><br /><br /><span style="font-size:130%;"><br /><br /><br /><br /><br /><br /><br /><br /><br /></span>Unknownnoreply@blogger.com1tag:blogger.com,1999:blog-5544530353381010826.post-9501446034260249222010-01-21T12:30:00.001+00:002010-01-21T12:32:00.093+00:00We're all going to Aston...Avi Naim and Guy Chisholm will be off to the JISC Institutional Innovation programme meeting in Aston next week. Watch this space for the "outputs" we'll have for sale in the Trade Fair!Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-5544530353381010826.post-74991049428256267822009-12-11T11:26:00.007+00:002009-12-14T12:09:22.985+00:00Modular e-Administration of Teaching: Assembly ReportThe Centre for Applied Research in Educational Technologies (CARET) in Cambridge University hosted a JISC assembly for the Modular e-Administration of Teaching (MEAoT) project on Thursday, 10 December 2009.<br /><br />The list of participants included:<span style="font-size:100%;"><br /></span><pre wrap="" style="font-family:times new roman;"><span style="font-size:100%;">Richard Prager, MEAoT project PI, Cambridge University Engineering Department (CUED)<br />Laura James, CARET<br />Anne Clarke, MEAoT project, CARET and CUED<br />Guy Chisholm, MEAoT project, CARET<br />Avi Naim, MEAoT project, CARET<br />Cecilia Loureiro-Koechlin, JISC BRII project, Oxford University<br />Bridget Taylor, DAISY project, Oxford University<br />Jenny Mackness, JISC liaison for MEAoT<br />Rachel Tuley, Teaching Administrator, CUED<br />Jen Pollard, Computer Officer, Cambridge University English Department<br />Carmen Neagoe, Teaching Administrator, Cambridge University Judge Business School<br />Helen Marshall, Teaching Administrator, Cambridge University Physics Department<br />David Goode, Computer Officer, Cambridge University, Department of Divinity</span><br /></pre>The programme was designed to make the meeting a pleasant event. It started with a historical overview of the project (by Prof. Prager). This was immediately followed by lunch at a nearby restaurant, which helped break the ice and make everybody more comfortable.<br /><br />We then had five short presentations (15 minutes or less each). Three of these were by MEAoT staff (Prof. Prager, Anne Clarke and Avi Naim) and explained aspects of the project. The other two were by our guests from Oxford: Dr. Loureiro-Koechlin gave an overview of the BRII project and explained how it approaches potential customers. Dr. Taylor described the large scale DAISY project in the social Sciences division of Oxford University.<br /><br />A coffee break allowed free discussion between the participants and led naturally to the round table discussion of software distribution models. The forum was not very large but it was particularly varied, and this allowed us to get several different perspectives.<br /><br />We were discussing four approaches to distributing software, each the result of particular circumstances:<br /><ol><li>The Teaching Office Database (TODB) of CUED is the first part of the MEAoT project. It was conceived as a light-weight solution to the particular problem of allocating teaching duties fairly to members of staff. It was deliberately designed as an independent software, without any connection to other systems. In order to distribute it to other departments effort was invested in customization, with the explicit intention of the departments adopting the code and assuming full ownership of it from that point onwards. So far seven departments at Cambridge have received a customized version, and a generic version of the code is also available for other interested parties at future times, when the project team will no longer be available to customize the code for their specific needs.</li><li>The examination entries module for the Cambridge Physics Department is the second part of MEAoT. Unlike the TODB this module is required to integrate with a preexisting Teaching Information System (TIS) in Physics. The module is under development currently. Future adoption by other departments will crucially depend on the ability to make the TIS more generic, because it will be impossible for other departments to take the exam entries module on its own. Therefore in this case distribution of the software depends on making it more generic, not more specific as in the case of the TODB.</li><li>The BRII project collates data from various resources in order to create a searchable repository of knowledge for researchers. While the underlying software is monolithic, the various users around Oxford university need to interact with it in many different ways. Here the distribution of the code depends on separating a generic piece of code that works directly with a database (the back-end) from user-customized interfaces (the front-end).</li><li>The DAISY project creates a wide reaching system of internal administration within the Social Sciences Division at Oxford. It is developed as a large, monolithic system. The distribution of this software relies mostly on its provision of crucial services for costing activities. The fact that the various departments need these services makes them much more willing to accept a single large central system.<br /></li></ol>We attempted to understand how these distribution models work and what conclusions could be drawn from them for future projects. It was clearly stated by a computer officer (Jen Pollard) that she can see the benefit in adopting (and further adapting) the TODB software to the needs of her department. The other computer officer present (David Goode) agreed. The administrators raised the issue of having to "sell" such systems to their academic staff. Their ability to do so relied equally on the functionality provided by the system and its look and feel.<br />Cecilia Loureiro-Koechlin emphasized the point that the belief of each of her customers that they are getting something customized to their specific needs was the single most important "selling point" of the BRII software. This point was echoed by Richard Prager in viewing his experience of developing the initial version of TODB. Bridget Taylor talked about the provision of costing services as the "hook" with which to gain acceptance for the whole of the DAISY project across the division.<br /><br />The term "centralized system" is universally unpopular and should therefore be avoided when introducing new software in the academic arena, even if the software is in fact monolithic and centralized. The clear hurdle that should be overcome is the unwillingness of the users to try it out. Considerable effort must be put into working with the intended users in order to make them feel that they want to "own" the software. The willingness of TODB staff (Matthew and Anne) to work with the various departments, listen to their needs and change the software to suit them was mentioned as the best aspect of TODB, and the thing that set it apart from other software projects. The ability of Dr. Loureiro-Koechlin to "hide" the central aspects of the BRII system behind user-customized front-ends helped her in persuading reluctant users to try it out. Even the accepted centralized system of the DAISY project benefits from being characterized as "Divisional" rather than "University Wide".<br /><br />It was therefore expressed in several different ways that the most important aspect of getting new software accepted is the feeling of the intended customers that they are getting something that was prepared especially for them. Those functionalities of the system that serve a particular customer best should be emphasized over other functionalities (even if these happen to be more important to the system as a whole), and the look and feel of the system should be tailored to make the user comfortable with it (even if this means generating several different user interfaces for the same underlying software).<br /><br />The conclusion is that "customer-friendly" measures should be incorporated into the planning of software projects and allocated sufficient time and resources. The success of the project as a whole may depend of such measures.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-5544530353381010826.post-27505185469200571032009-11-13T09:53:00.002+00:002009-11-13T09:59:27.201+00:00TODB has new Team Member<span style="font-weight: bold;">TODB has new Team Member</span><p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal">Hi, I’m Anne Clarke and I have taken over from (couldn’t attempt to replace) Matthew Jones on the TODB Project.<span style=""> </span>I have had a varied career in IT which included working in a baby clothes warehouse near <st1:state st="on"><st1:place st="on">New York</st1:place></st1:state>, some time in Coutts Bank and working on Stock Exchange feeds for Reuters. <span style=""> </span>I am now back in <st1:city st="on"><st1:place st="on">Cambridge</st1:place></st1:city> where I took my first degree so am familiar with the academic system here.</p>It was good to get a chance to ‘meet’ people from both JISC and other JISC projects during the Elluminate Shaping Change session yesterday.<p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal">I have been reflecting on some of the points that Steve Outram made about managing effective change in his introduction and how they were later illustrated during later sessions:</p> <p class="MsoNormal"><o:p> </o:p></p> <ul style="margin-top: 0cm;" type="disc"><li class="MsoNormal" style=""><b style="">Support of Senior Management</b> </li></ul> <p class="MsoNormal" style="margin-left: 36pt;">Pretty much goes without saying but helps to gain the necessary staff commitment such as that needed for the steering committee used by the e-Assessment Project.</p> <p class="MsoNormal" style="margin-left: 18pt;"><o:p> </o:p></p> <ul style="margin-top: 0cm;" type="disc"><li class="MsoNormal" style=""><b style="">Early Engagement <o:p></o:p></b></li></ul> <p class="MsoNormal"><b style=""><o:p> </o:p></b></p> <p class="MsoNormal" style="margin-left: 36pt;">The Erewhon project choose to demonstrate an early working version to overcome resistence.<span style=""> </span>During the afternoon session we discussed that it was important to engage all who would be affected as early as possible.<span style=""> </span><b style=""><o:p></o:p></b></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal" style="margin-left: 36pt;">This has been highlighted in my own project, TODB, where the staff who use the system to enter data have given valuable input into what would work best for them.<b style=""><o:p></o:p></b></p> <p class="MsoNormal"><b style=""><o:p> </o:p></b></p> <ul style="margin-top: 0cm;" type="disc"><li class="MsoNormal" style=""><b style="">Sell Benefits <o:p></o:p></b></li></ul> <p class="MsoNormal"><b style=""><o:p> </o:p></b></p> <p class="MsoNormal" style="margin-left: 36pt;">The ECCILES project used a visit to a power station to show those who would be impacted by their project the importance of saving energy.<span style=""> </span>The TAG project encouraged student involvement in their project by showing them that this would improve their employability.</p> <p class="MsoNormal" style="margin-left: 36pt;"><o:p> </o:p></p> <p class="MsoNormal" style="margin-left: 36pt;">E-Assessment and ASSET both talked about starting small (1 faculty or a pilot) which allowed them to get things right before rolling out to other departments.<span style=""> </span>Again this is something we have been able to do on the TODB project where we have started with a working application developed for one department that we can demonstrate to others to show the benefits.</p> <p class="MsoNormal"><b style=""><o:p> </o:p></b></p> <ul style="margin-top: 0cm;" type="disc"><li class="MsoNormal" style=""><b style="">Support Risk Taking<o:p></o:p></b></li></ul> <p class="MsoNormal"><b style=""><o:p> </o:p></b></p> <p class="MsoNormal" style="margin-left: 36pt;">Innovative projects by their nature involve risk and funding from JISC can be used as a way of mitigating this risk.</p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal">Throughout the day, there was emphasis on the <b style="">final outputs</b> of our projects.<span style=""> </span>The format of the final report does need to comply with JISC standards for auditing purposes but it is important to also produce a package that allows the benefits of the project to be realised elsewhere.<span style=""> </span>Lawrie Phipps suggested the use of magazines and podcasts such as used by <a href="http://magazine.openhabitat.org/page/open-habitat-magazine">http://magazine.openhabitat.org/page/open-habitat-magazine</a>. <span style=""> </span>Ruth Drysdale said that the commenting on the learning from things you have not been able to accomplish were as valuable as your successes.</p>Thank you to everyone involved in such an interesting day.Anne Clarkehttp://www.blogger.com/profile/07312177913654529374noreply@blogger.com0tag:blogger.com,1999:blog-5544530353381010826.post-23184360593457767602009-10-02T09:31:00.001+01:002009-10-02T09:32:12.484+01:00TODB running locally in English FacultyWe have achieved a small, but I think significant, milestone in the TODB adoption process: the English Faculty have now set up TODB on one of their servers. Their entirely independently-hosted TODB is accessible here: <a class="moz-txt-link-freetext" href="http://www.english.cam.ac.uk/todb/">http://www.english.cam.ac.uk/todb/</a><br /><br />Installation took approximately 20 minutes and went without hitch on a SUSE Linux Enterprise Server (SLES), which was already running Apache, MySQL and PHP. The installation consisted of five steps:<br />1 - database creation<br />2 - database user setup (via script)<br />3 - database table/data setup (via script)<br />4 - installation of PHP files (tar file tree)<br />5 - apache setup (manual copy & paste & edit from conf file excerpt provided with distribution)<br /><br />Most reassuring was the fact that it ran 'out of the box' on a pretty standard web server.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-5544530353381010826.post-37481190945894559532009-10-01T16:52:00.004+01:002009-10-01T17:05:31.390+01:00Exam Entries Demo ReportThe initial specification of the examination entries module was based on discussions with the physics department of Cambridge University. However, it is difficult for potential future users of this module to imagine what it will look like in reality and so important points may be missed.<br /><br />In order to make it more tangible we prepared a Java-based demo and took it to the physics department. It emulates linking to a wider student information system and allows a student to log in and register for exams. These registrations are then checked against a list of registration rules, which are encoded into the system in a generic way. Once they pass this validation they are sent to the student's Director of Studies for approval.<br /><br />A separate tool was demonstrated that allows members of staff in the department to change, remove and add new rules. It was demonstrated that this simple system is capable of covering most of the needs of the physics department with regard to examination registrations.<br /><br />The feedback from Physics was enthusiastic and valuable advice was given on points that were not covered yet or were covered in an incomplete way. The full specification of the system will now be reviewed and improved, to be followed by a pilot module that will be deployed in Physics towards the end of the year.<br /><br />Based on the comments received we are very encouraged and believe that other departments will also be interested in the pilot module, once it is available.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-5544530353381010826.post-66431736987147763632009-09-22T09:40:00.002+01:002009-09-22T09:45:38.374+01:00Teaching allocation similarity map<div>After setting up, configuring and customising TODB instances for several departments, I am struck by the unexpected similarities between certain departments. It seems that the administration of teaching does not follow disciplines. I constructed a rough map of similarity, which is inserted below. The features common to all TODBs are not listed; only the specific overlaps between departments (Chemistry is omitted but will be added soon!).</div><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj0t-ZCzA-hztlutLliIwjKC_raf0sFem4zPLP1kl79z-YNvIYsth0GG1NuMJrg0TCQ4FpKBeggXWV_73QMkoeW-W92Sz7jaIs3PxtkgtrSxgqaMUNc4LJThxCOlN84u4r26Lma-Xq_AL8/s1600-h/Teaching_similarities.png"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;width: 320px; height: 222px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj0t-ZCzA-hztlutLliIwjKC_raf0sFem4zPLP1kl79z-YNvIYsth0GG1NuMJrg0TCQ4FpKBeggXWV_73QMkoeW-W92Sz7jaIs3PxtkgtrSxgqaMUNc4LJThxCOlN84u4r26Lma-Xq_AL8/s320/Teaching_similarities.png" border="0" alt="" id="BLOGGER_PHOTO_ID_5384210056013141346" /></a><br /><div><br /></div>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-5544530353381010826.post-84642908982764393442009-08-11T10:30:00.002+01:002009-08-11T10:43:25.469+01:00Departmental Deployments<blockquote></blockquote>The TODB is 'under deployment' in the following departments:<div><br /></div><div><ul><li>Engineering</li><li>Judge Business School</li><li>Chemistry</li><li>English</li><li>Divinity</li><li>Veterinary Medicine</li></ul><div>Engineering and the Judge are the most established users. Although our engagement with Veterinary Medicine began in December, for various reasons it has not been until very recently (this week!) that their TODB is now online. At the request of the Vet School a rudimentary timetable output system has been developed for TODB. This allows jobs data to be presented in timetable format if the 'timeslots' column is present on the jobs table and timeslot information is provided in a format something like 'Week x: Day time, ...'; e.g. 'Week1 Tu.11.30, Wk2 W.3' and so on. This has been designed to be reasonably robust.</div><div><br /></div><div>The Divinity site is also under development. A slightly different timetable approach is being developed for them, where we are attempting to generate output in a form compatible with the Cambridge Reporter. If this can be developed, it will save a huge amount of time for Divinity and staff of other departments who have adopted the TODB system.</div><div><br /></div><div>As each department is set up and as their particular needs are supported, a generic version of TODB is being developed on a parallel track. This is nearly ready for release - hopefully in the next week or two. As this is intended to be a formal release, it will include documentation, installation software and administrative tools. More on this soon!</div><div><br /></div><div><blockquote></blockquote><br /></div></div>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-5544530353381010826.post-53450447048006201952009-08-10T15:05:00.001+01:002009-08-10T15:07:48.712+01:00MEAoT at the BRII Oxford AssemblyMatthew Jones attended the BRII Assembly in Oxford on 9 June 2009. Access his full report - as published in the JISC-SSBR newsletter on 2 August 2009 - here: <a href="http://assemblies.inin.jisc-ssbr.net/2009/07/27/meaot-brii-assembly/">http://assemblies.inin.jisc-ssbr.net/2009/07/27/meaot-brii-assembly/</a>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-5544530353381010826.post-29900887014652131972009-07-10T15:12:00.002+01:002009-07-10T15:19:03.440+01:00JISC SSBR Elluminate Meeting 9 July 2009<span style="font-weight: bold;">Notes from the JISC Elluminate all-day meeting 09 July 09: Support, Synthesis</span><br /><span style="font-weight: bold;">and Benefits Realization, for the Institutional Innovation and Life Long</span><br /><span style="font-weight: bold;">Learning / Work Force Development programs.</span><br /><br /><span style="font-weight: bold;">General:</span><br />The meeting took most of the day and for the most part proceeded at a comfortable pace. My impression is that this is a viable way of conducting low-cost meetings.<br /><br />The technical side of the meeting was generally alright, although there were<br />some glitches with sound. Of the 80-odd participants less than 10 chose to<br />activate their web cams at any moment and most stayed silent for the whole<br />day. The breakout groups were divided seamlessly, although they were brought<br />back together rather abruptly due to lack of experience on the part of moderators.<br /><br /><span style="font-weight: bold;">Morning sessions:</span><br />In the first morning session <span style="font-weight: bold;">John Cook</span> gave a presentation entitled<br /><span style="font-weight: bold;">"Scaffolding the mobile Wave"</span>. His assertion was that new digital media (e.g.,<br />the mobile phone) can be regarded as cultural resources for learning. The<br />question he posed was how to bring together informal learning contexts in the<br />wide world with practices that are valued inside institutions. This must be<br />done with awareness to the critics who claim that social software and search<br />engines do not encourage collaborative work.<br /><br />JISC set a target for 2010 of widespread user-owned technology in learning,<br />but this is now acknowledged as unlikely. It is a fact that over half of the<br />world's population owns a personal mobile phone. Nevertheless, Cook quoted<br />research by Davidson and Goldberg who indicate that while learners use and<br />adapt to changing technology, the act of teaching remains largely<br />unchanged. What people tend to use their mobiles for is at best informal<br />learning, e.g., watching UTube clips on a mobile. This does not replace the<br />type of learning we do in formal education.<br /><br />Cook suggests using technology positively by scaffolding the learning, meaning<br />one more able learner helping a newcomer. "Google wave" is a hosted<br />conversation that lives in one place (like a live twitter). Some licensing and<br />privacy issues still need resolving.<br /><br />Two examples were given of courses using this technology in London: mobile<br />urban education and mobile cistercian abbeys. In both cases the students could<br />get information on site thanks to GPS locators, that enhanced their<br />understanding of the topic. The first example examines urban planning: as you<br />walk about you get feeds of historical pictures of the area. Schools, for<br />example, used to look like factories or prisons, becoming flatter in the 60's,<br />more "humane". When you stand in the street you get images of processions from<br />the 1930's. Students work in pairs. The second example concerns Cistercian<br />Abbeys, construction of which started in 1132. A mobile tour was developed<br />that shows a full structure as it once stood suprimposed on the existing<br />ruins. between 80% and 90% of students like it.<br />The big question is how do we go beyond it.<br /><br />Cook's vision goes beyond the usage of static, pre-defined information. He<br />would like to see learners "appropriate the mobile wave", e.g., using it for<br />time tabling, receiving alerts of room changes for lectures, locating fellow<br />students in their study set, etc. An example is the Contsens project (http://tinyurl.com/klvx6j).<br /><br />The discussion that follwed concentrated on technological aspects of Google<br />Wave and on cost. It was also pointed out that there is a divide between<br />higher education, where such material supports the more traditional teaching<br />materials, and further education, where this type of material may be the<br />backbone of a course.<br /><br /><br />The <span style="font-weight: bold;">second morning session</span> was dedicated to Institutional Innovations projects<br />reporting back from <span style="font-weight: bold;">assemblies</span>.<br /><br />1. The <span style="font-weight: bold;">BRII assembly</span> on <span style="font-weight: bold;">stakeholder engagement</span> was held in Oxford. Six projects<br />participated, each giving a short presentation, and in addition a guest<br />speaker was invited: the head of internal communications at Oxford, Susannah<br />Wintersgill. After the guest talk and presentations there were several<br />breakout groups for discussing various aspects of stakeholder engagement.<br /><br />The overall feeling was that the assembly worked well and since each proejct<br />faced different stakeholder problems, each came up with a unique solution as<br />well. This is all summed up on the BRII project blog. They feel that the<br />results of the discussions could be taken forward, perhaps for Benefits<br />Realization.<br /><br />2. <span style="font-weight: bold;">Data Centre Exchange Assembly</span> - hosted by University of East Anglia<br />The participating projects shared information on what has been done so far and<br />then split up to breakout groups. A successful meeting where each project<br />could learn from the other.<br /><br />3. <span style="font-weight: bold;">weCAMP and i-Borrow Assembly</span><br />i-Borrow is about a large number of netbooks with location tracking data.<br />weCAMP deliver a 3-d package of learning on campus.<br />The feeling is that there was scope for cooperation between the project as<br />each was more advanced in one common area and a little behind in another.<br /><br />4. <span style="font-weight: bold;">Academic Networks</span>: Laura briefly described the upcoming assembly.<br /><br /><br />We then had a general presentation about <span style="font-weight: bold;">Synthesizing the programme.</span><br />- The strategic environment is complex.<br />- The context of institutional innovation is wider than the physical location of the university, it is about commonly conected activities that pervade many institutions.<br />- universities can see themselves as global change agents, or an institutional improvement facilitator, for businesses, NGOs, other universities and government agencies.<br /><br />Data collection from phase 2 projects:<br />- create a 3d "matrix" featuring the projects, the bottom up emergent themes from them and the top-down themes from JISC and HEFCE. Looking for common themes.<br />- bottom up themes are derived from popular key words.<br />- elicited themes: open educational dialogue, ...<br />- top down themes: learning, teaching and assessment; research and development; business and community engagement; learning resources, e-Admin,...<br /><br />- LLL/WFD projects started 13 April and since then the team has been collecting key words and themes.<br />- analysed with wordle (www.wordle.net).<br />- many areas where projects can support each other.<br />- challenge: making the model practical, defining a scope for the innovation programme.<br /><br /><br /><span style="font-weight: bold;">Afternoon Sessions:</span><br />After lunch we split into breakout groups. At 2:30 we were all<br />brought back (rather abruptly) into the main room for concluding comments by<br /><span style="font-weight: bold;">George Roberts</span> and the meeting formally ended at 3pm. Several workshops<br />followed after the official end of the meeting.<br /><br /><span style="font-weight: bold;">Breakout group 3: Tech practices</span><br />The general feeling was that this group had very little time to discuss a lot<br />of questions. The questions are brought below, but there was almost no<br />discussion due to time pressure.<br />1. Where is the buy in?<br />- Is your project about technology, practice or innovation?<br />- Are you planning change or replacement?<br />- Who initiates change?<br />- Where are you embedding? e.g. financial systems, staff practice (takes time)<br />- How do you rate your institution’s ability to change? This may depend on the nature of the institution - devolved or centralized - and its’ ethos.<br />- Change agents - who drives change? Are you targeting the correct stakeholders?<br /><br />It was suggested to approach stake holders in a "divide and conquer" manner:<br />get senior people in or at least people who can nag them, and through them get<br />a wedge into the organisation and promote your targets. Another comment was<br />that change is seen as a managerial activity in the UK while in Spain and<br />Portugal (for example) it is seen more as a student-driven modification to<br />institution culture.<br /><br />2. When does embedding work?<br />- How are you getting buy-in? Sell the argument - give the tools for the need to change to be passed on<br />- How have you planned for user engagement: user and provider<br />- Are you embedding solutions, not enhancements?<br />- Can you create patronage?<br />- Do you have a user-friendly presentation?<br />- Can you leverage institutional reputation - what are the competitors using?<br /><br />3. What are the drivers for embracing technology?<br />- Are you addressing students and incoming staff?<br />- Have you taken into account relevant institutional strategic agendas?<br />- Will your results be credible?<br />- Do you have access to technology-wise institutional managers?<br />- Can you argue that risky times call for risky solutions?<br />- Do you know you key change agents - they will be the implementers? Or are you depending on middle managers when you should be going more senior – e.g. see it as staff development.<br /><br />4. How do I convince my stakeholders?<br />- What is your strapline?<br />- Are you solving non-existent problems? Do you have a good definition of the problems you are solving?<br />- Why would I support you?<br />- What problem do you solve for you me?<br />- What do managers want to hear - the management discourse? This is not the same as Web2.0 discourse.<br /><br /><br /><span style="font-weight: bold;">Workshop: Second Life</span><br />This short workshop introduced the concept and basics of Second Life. It is<br />clear that some people will find it an entertaining environment, and learning<br />could take place in groups that are physically separated, but it is not clear<br />how significant a component this can be as part of the studies towards an<br />academic goal, such as completing a course on time.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-5544530353381010826.post-70346132997644496132009-04-16T10:41:00.005+01:002009-04-16T11:27:46.450+01:00Progressing with TODB deploymentsThe Engineering department Teaching Office Database (TODB) has been deployed in the past month to the Judge Business School (JBS). This was a natural first deployment since JBS and Engineering share lecturers and students from each department tend to take some courses in the other. This was also a test case for the suitability of the TODB to a different environment than the one in which it was created (Engineering).<br /><br />Initial feedback from JBS is very positive. The local team has asked for several minor modifications, which were put in place by Matthew Jones who also deployed the system to JBS. Apart from those the TODB was taken as is and already proves useful to JBS.<br /><br />Encouraged by a first successful deployment we now plan to deploy in other participating departments. First up will be the department of English. They are much smaller than engineering and consequently staff do not belong to specific divisions within the department and can teach almost any course. They also allow lecture courses to belong to more than one degree path. These are new challenges for the TODB and will serve to further test its suitability to various environments. We expect feedback by the end of April 2009.<br /><br />Further deployments are planned in the departments of Chemistry and Divinity in May 2009. The latter is of a particular interest because they have no programmers locally and will not be able to modify the system they get in the future. They are therefore more likely to want "future proofing" and this may lead to new requirements.<br /><br />The hope is that the feedback collected by June 2009 will be sufficient for us to generalize the TODB schema and build an access API to the database that will serve future developments well.<br /><br />The examination entries module, to be developed by the Physis department, will benefit from ground-work laid down by the deployments of the TODB. The examination entries schema and database API will be built in accordance with those of the generalized TODB and will therefore become a first test case for it. In order to achieve this it is important to have both systems in the same place, and therefore it is only natural to deploy the TODB in Physics around June 2009. Feedback from Physics, which is a large departments with many inter-departmental courses, will inform the process of generalizing the TODB even further and at the same time give us the basis on which to develop the examination entries module.<br /><br />Our expectation is to have a proper design for both modules by July 2009 and move into development immediately after this milestone.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-5544530353381010826.post-19336315392365637382009-03-09T15:03:00.004+00:002009-03-09T15:21:57.260+00:00Thoughts about modularityThe Engineering and Physics departments provide us with a unique set up in which to design a modular system. Engineering has a working module to manage teaching duty allocations (Teaching Office DataBase). This module is being rolled out to the Judge Business School these days. There are some differences between the version rolled out to JBS and the original system, but crucially only one minor change at database level. This allows us to think of the Engineering module as the nucleus of a larger system, and of the JBS roll-out as the most basic extension to this module. Further deployments into other departments in the univeristy will test the suitability of this module and the degree to which its robust, simple design is sufficient to meet their needs. The challenge here is organise the code and the database schema so as to allow other modules to be added to it while maintaining it design. We might add tables to the database but will aim not to change existing ones.<br /><br />The Physics department's Teaching Information System is larger and more complex, and will be redesigned as a whole. The first module to be written there will be the second deliverable of the eAdmin project, managing student registrations for courses and examinations. The challenge in this case is to incorporate the Engineering TODB within this new system as is, while developing the second module around it. This will serve as a more serious test for the modularity of the emerging system.<br /><br />If we can demonstrate that the new system lends itself to the above two types of modular extension we will have achieved a lot. Proper documentation will then pave the way for future extensions of the same modular nature.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-5544530353381010826.post-44307276648971095522009-03-04T16:53:00.004+00:002009-03-04T17:10:25.951+00:00TODB at the Judge Business School<p>The Judge Business School (JBS) at the University of Cambridge has been associated with the Engineering TODB for some time, and is one of the cooperating departments in this project. The JBS currently uses an Excel-spreadsheet based teaching allocation system. An interesting challenge has been translating this into something the TODB can handle without fundamental changes. It is with satisfaction that we are able to report that effectively every peice of information stored in the spreadsheet can be stored in the TODB without modification to the database schema, with the one small exception of adding a field for 'points quotas'. User interface code is similar, except where support for using quotas is necessary.<br /><br />Two new reports were developed and added to the TODB for the JBS:<br /><ul><br /><li>A teaching points summary page, which lists point-sums in categories for teaching, supervision, sabbatical and so on by subject division and by course.<br /><li>An interactive faculty (staff) summary page which displays how many points each member of staff is 'earning' and how this is broken down by teaching activity.<br /></li></ul><br /><br />These reports replicate almost exactly the function and behaviour of the spreadsheet equivalents on which they are based.<br /><br />As the JBS version of the TODB has been developed in parallel with the Engineering TODB, it is effectively using TODB v1 code, where Engineering is now using TODB v1.1 code. It is necessary to attempt to converge these as much as possible prior to evaluation and use by the JBS. <p></p>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-5544530353381010826.post-72454782282003922722009-02-04T11:02:00.003+00:002009-02-04T11:05:08.682+00:00To web2 or not to web2On the e-admin project we're developing web-based tools to support teaching activity. We don't normally call these Web1 tools, or Web2 tools, but ultimately the modules we are creating are an emerging kind of technology. And perhaps with actual academics feeding information into these systems, they could count as "user generated content", and therefore Web2.0? <br /><br />Netskills are looking for information on how researchers, academics, and the people who support their work use emerging tools, such as Web2.0 services like <a href="http://www.twitter.com">twitter</a>, <a href="http://www.flickr.com">flickr</a> and more. This is part of work funded by the <a href="http://www.jisc.ac.uk">JISC</a> Users and Innovation (U&I) programme.<br /><br />Please help them out by taking their <a href="http://spreadsheets.google.com/viewform?key=pTnkkIqfu0dqkq_OKwrnmEg&hl=en">survey</a>!<br /><br />They will use information from the survey to create guides to help others see how emerging technologies can help in research and teaching.Unknownnoreply@blogger.com0