Spider (portal)

The development of SPIDER is documented from its creation in 1998. The following bullet points give the main development from previous versions.[2]

• 1998 SPIDER: Approximately 120 students.
• 1999 SPIDER 1A: Move to dynamic, database backed system (Linux, Apache, MySQL, PHP).
• 2001 SPIDER II: Caters for around 550 students.
• 2002 SPIDER II/III: Improved content management system; new content creation tools; quiz builder.
• 2003 SPIDER III: SPIDER system modified to allow for faculty wide use, using "clusters" to allow different departments/ groups of departments to control own content.
• 2004: Authentication and integration with central university systems (LDAP/ADS, PEGASUS).
• 2005 SPIDER V Start of session 05-06 sees over 10,000 registered users.
• 2006: Around 900 classes from dozens of degrees use SPIDER to support their teaching.
• 2007: Classes climb to over 1000 in 11 clusters, with over 7,500 users logging per month.
• 2008: SPIDER has over 26,000 users (1,300 staff, 15,000 students, 10,000 alumni).
• 2009: Over 20.8 million visits for the year, delivering 1400+ classes for over 160 degree programmes.
• 2010: core of SPIDER re-written to improve database, data handling and form management; CSS reworked in combination with the core rewrite to allow for "SPIDER-mobile" .

The SPIDER system is organised into clusters. Each cluster represents an academic degree or a series of related academic degrees, which allows administration and management of classes and content to be handled by different departments. For example, all pharmacy related content is in the pharmacy cluster, chemistry content in the chemistry cluster and so on, with each cluster having its own administrator, sub-administrators and editors in charge of management and control of their own classes and materials.

The availability of clusters is one of SPIDER's unique features. It allows for much finer control and better organisation of content than typical VLEs which have a very flat structure, a single layer of classes controlled by tutors. There may be hundreds or even thousands of these classes, but there is no unit or department structure to allow for sensible grouping of classes and their control.

SPIDER's cluster system provides an extra level of hierarchy that allows for devolved administration by allocating each class to a department within a cluster. Administrators within the cluster then have complete control of their own classes and content, but have no control over those in other clusters. At the same time student users are able to view classes and content across cluster boundaries.

As a result of this cluster being available, many of SPIDER's tools have the flexibility to operate at both the class and academic degree/ programme/ unit level. For example, staff users on SPIDER are able to target news items at several classes in their cluster or even at year level. This news will only be seen by students in the matching cluster - so if a Pharmacy lecturer were to post news for year 1 pharmacy students, this won't be seen by chemistry or physics students. However, if the target is a class code (e.g. a mathematics class taken by chemists and pharmacists) the news will be seen by anyone in any cluster who has the code set in their news filter.

In addition the user object exists within a cluster, allowing suitably authorised users to view all the data corresponding to a user in their cluster. This would allow a year co-ordinator to see all a student's results across all their classes without having to own or be a tutor in every single class that the student is taking [3]

SPIDER makes use of an academic session to establish which content is current and which is archived. Class lists, group membership, class content, exam & quiz results and many other tools are 'session aware' so that the user is presented with the active data or can choose to view archived data. The session preserves the data in these tools as it was at the time the activity took place. This enables students who are viewing their previous classes for revision or resitting classes to see exactly the content and activities that were available at the time they took the class. Similarly staff can view session by session archives of the class as it was in previous sessions.