StudentNET UCISA Presentation

Editor's Notes

• #2: Good afternoon – thank you for joining us.My name is Philippa Spratt and I am the Head of Corporate Information Services at Canterbury Christ Church University. This is Josef Lapka, Senior .NET Application Developer.We’re here to talk about our student portal called StudentNET.
• #3: Started - In Sept 2006 serious problems with students failing to re-enrol (assumed enrolments – auditors not happy)Academic Registrar DIY in Access NO!CIS fast tracked development of first SN service – kept it simple – 20 days - AR compromised, simplified BP’s, pilot for 2000 - successful outcome - exceeded 70%By following year five SN in operation – all Registry servicesAround this time growing focus on improving student services, building new learning resources centre, largest investment in single buildingMajor infrastructure projects underway – building CMP, implementing CMS and developing staff intranet – start of a differentiated online exp to serve different audiences
• #4: 2007- Inspired by IWMW presentation by Edgehill University – see a way of bringing together all the ideas we were havingSupport the student from the cradle to grave – concept of browser (anonymous person looking at our website, clicking on study here, interested in what we have to offer, enquirer (email address), through to applicant – applied thru UCAS etc (studentID), full enrolment (Computer account) and finally alumniIdea was to build something that students recognised as they progressed through each stage, relationship building tool , consistent, engaging & interesting, want to come back to, keeping warm agenda, heavy emphasis on look and feel matching or exceeding what was available commercially & what students were using. Web 2.0, facebook – STICKY Put together a roadshow presentation – artists impression – strong impact - 6 stages included accepted (UF) Gateway to external apps, transparency of data that we hold on students, wrong stage on SRS – no access Positive reception – strong buy-in - everyone said great – when?
• #5: Following major presentation to university management group and approval by senior managers, design phase began.Challenge was to turn vision into reality – detailed technical specification, future proof product, knew build one element at a time, design to include all stages, built in ability for students to be in multiple stagesFull integration with central systems, loosely coupled so that we could change our SRS or any other propriety system if necessary.We reviewed several potential products including Sharepoint (MOSS integration), full in-house development and DropThings framework.
• #6: I’m going to take over now to talk to you about the architecture of StudentNET. The Dropthings framework comes with a granular architecture that allows us to control what students see on the page BUT also critically allows our users to make choices about what they want to see on the page. It all starts with a concept of the PAGE. Each user can have one or multiple pages. We have currently limited this to one page. Each page holds a [click slide]
• #7: One or many columns. These columns are architectural not look and feel. We have currently fixed the framework to contain 4 columns. Each column contains [click slide]
• #8: A zone is an a usercontrol that has the ability to dynamically load widget instances which I will come to in a moment. There are three types of zones in our framework. We have an app area widget zone, side area widget zone and a regular widget zone. The original framework comes with only the regular widget zone. We have extended the Dropthings framework to allow us to provide users with necessary options and features.The app area zone is designed to host app area widgets, which I will come to later on. The side area zone is designed for general widgets that cannot be moved around on the page.The regular widget zone is the default which allows widgets to be moved around.All these zones have something in common though, they are built to dynamically load widget instances and each zone can contain [click]
• #9: One or many widget instances.These widget instances are pieces of code that allow us to dynamically load actual widgets. These widgets are referenced via URL.Widget instanced also allow us to save different types of state information for each live widget. This information can be, for example the number of articles a user sees in his or her RSS feed widget.There are four types of widget instances again to allow us to provide the users with the necessary features and to ensure that the design that we came up with at the very beginning of this development can be met. These widget instances are the same as the types of widgets that we offer.[click]
• #10: There are four types of widgets which are called by the previously mentioned widget instances. A widget instance can reference only one widget at a time.We have the fixed widgets, which do not have the ability to be moved, removed, or amended within the framework.We have loose widgets which, came as standard part of the framework and can be moved around the page within the designated zone.We have app widgets which are used to host in-house built applications and are designed to open at the top of the page and stretch all the way across the width of the page.And we have the webnote widget. The reason why this is a special widget is that it has been loaded into the movable zone, but overridden to be fixed.Widgets are basically .NET usercontrols similar to the way that Sharepointwebparts are built. During our migration from the old framework to this one, most of our aspx website code was kept, with only slight alterations to javascript, state information management, and code order within the .net page cycle.
• #11: With the front end architecture covered, I would like to draw your attention to the communication aspect of our portal. A big win in our promotional tour of the vision, that Philippa was talking about earlier, was the ability to communicate and send alerts to students. With this in mind we have fixed the WebNote widget in the centre of the studentNET page. Through this widget we are able to send personalised messages. The architecture of this widget is so granular that we are able to send one specific message to one student. Because of this granularity we are not restricted in any way. We can send messages to any number or any type of students and student groups. For example, based on campus location, programme code, module code, current student record system status, and so on. There are also two ways of mechanisms we are currently working towards providing. A manual send mechanism, providing an admin interface for staff sending messages, such as notifications about cancelled lectures.And an automatic send mechanism which works on the bases of your status within the student record and finance systems. For example automatic messages would be generated to all students on stagecode ‘PRSRTR’ prompting them to re-enrol.We are also in the process of making this page a compulsory homepage on all university computers when students go online, and it supports single sign-on when on the campus. This means that students are more likely to get these messages before logging into their hotmai/facebook/etc accounts.
• #12: Now, as I mentioned before all that a student sees on the page is controlled by our client management. And I would like to spend a little bit of time to illustrate to you how we have integrated StudentNET with it as well as with other corporate information systems.A mixture of user data (from our datawarehouse) specific rules applied to available services allows our client management system to decide on service entitlement. The process there in the middle is a lot more complicated, however for the purpose of service provision to StudentNET, this is it.When we develop new widgets for the university, the service or widget owners would be involved in deciding the manual mapping of widgets against services.Once the services is mapped against the widget and service entitlement is decided, a scheduled code takes STudentNET relevant messages and puts them into the service endpoint. At the moment this is scheduled at once every hour, but we are looking to reducing this time to once every 15 minutes, which would mean that from changes to the source systems, such as our student record system, students are able to see the changes within 30 minutes.This combined with the user’s settings, makes up the page that the students sees.
• #13: The integration of other corporate information systems with students has also been a straight forward process. Again because of the granularity of StudentNET we are able to seamlessly integrate most of the univeristy’s information systems. Some of our current integration includes [look at slide]And we are also investigating future integration with the following. [look at slide]I was not sure whether we would have any internet connection, or whether we would have some time to cover this, but what I thought I would do now is show you the portal live, online, just so you can put all of what we have been talking about today into prospective. And then we will take questions.