Computer Availability App is here!

Posted on January 15, 2013 by Maurice Savage

If you want to see where free computers are around campus then you’re in luck. The Edge Hill computer availability web app is up and running in some key locations around campus (@ehu.ac.uk/computers). And here it is!

Each area’s unfoldable map shows which computers are free (green is free!). We chose a salmon colour for used computers, because salmon are busy fish what with all the swimming and laying eggs. Or maybe it has something to do with being distinguishable from green for colourblind people.

Like salmon, people move around really quickly so you might find the computer you were hoping for has gone by the time you get there, and another one has appeared. So you can use the app to get a general idea of which computer area would be good to aim for. That’s why we used the signal strength indicator – so you can see at a glance your likelihood of finding a computer in that area.

That means likely.

There’s also a link to the room booking system, so feel free to come here just to book a room.

As well as showing computer usage, it also just shows where there are computers, which can be useful to new students who haven’t fully explored yet.

There’s a shiny new building overview page, that unsurprisingly gives an overview of the computers used in buildings. You might see this around screens on the campus.

There’s also a series of single map pages, just focusing on one computer area:

These single maps will be part of a slideshow shown around campus. We have one for the library which will rotate through the single maps and overview screens, so people can see at a glance where computers are being used. It should hopefully save some time in students’ days so they can so they can find a place to study more easily.

Responsive

The app is responsive – a liquid version that fills to fit the container device window – so use it on your phones and tablets as well.

And that’s it. The plan is to expand to show more computers around the campus. So go ahead and use it, and let us know what you think. Feedback is what sculpts the greatest software. So what would you change to make it better? Does it help you? Let us know.

webteam@edgehill.ac.uk

The Tales of Xcri-Cap

Posted on November 26, 2012December 4, 2012 by Maurice Savage

One of the first projects in my new job here at Edge Hill was JISC’s XCRI-CAP. Where would we be without acronyms? I was thoroughly pleased to have some new ones. Here’s the definitions:

JISC – a company that pushes innovative digital technology into UK education
XCRI-CAP – eXchanging Course Related Information, Course Advertising Profile. It’s a UK standard to describe course information for marketing.

JISC’s goal with XCRI-CAP is to share course information with the organisations who publish it, such as hotcourses.com.

Xcri - eXchanging Course Related Information

We’re making a feed for our Health CPD courses in the XCRI format so prospective students can find the course they’re looking for.

We moved all our health courses onto WordPress – our CMS (Content Management System) for most of our course information now. It was a good clean break, as we got to redesign the information’s structure to fit the XCRI specification. With the health courses in the CMS, we made the XCRI feed. It passes the course information to the feed aggregators so they can share the information.

Here’s a little information about each phase:

Database Mapping

This involved translating the old database content into the new xcri fields, where possible, and retaining the other useful information. We used the opportunity to strip out any useless information.

This was the ‘get out your spreadsheet and be very thorough’ phase. It was pretty important because the information had to be labelled right so websites could understand it and use it properly.

We continued to the content management system…

Built a new Content Management System (CMS)

We actually extended WordPress, the CMS we use for most of our courses, by making a plugin that saves the health CPD modules. WordPress makes it fairly easy to add new functionality by providing hooks you can latch onto to adapt the software – basically slots to inject your customisations in.

Using WordPress’s custom post types we added courses and presentations to the CMS, and customised the admin area with the right input boxes. A presentation is a living instance of a course – for example, on the Tissue Viability course the Feb 2012 intake and July 2012 intake are different presentations.

WordPress makes it quite easy to add functionality by using existing plugins. We wanted more precise control over the admin page, so we did some of the building ourselves.

Customised WordPress admin menu

Once the CMS was done we transferred the course information into it.

Built new web pages

We made a page template that displays an individual course’s information.

Front end website page template

We’ve still got some work to do on the template, like adding side navigation that links to similar courses.

Making the feed

We built an example feed that holds dummy information first. We passed this through the Xcri 1.2 validator to make sure it was right. Eventually it stopped telling us we had made massive human errors, so the feed was right. Here’s the static version:

We made the real feed by passing the course information into this template from database.

And that’s where we are so far. Its nearly finished, and hopefully will make it much easier for people to find the right course.

Wiki Progress

Posted on December 22, 2010December 21, 2010 by Maurice Savage

In an earlier blog post we talked about big changes to the staff intranet. We intended to move all the content from the staff intranet into a wiki. Each department would have a space created and they could manage their own content. Most departments have now got a wiki space and are actively using them.

The Wiki is a web based tool that you can use to add content, edit content, add documents in most formats as attachments, add images even add and display video. It was set up to take over from the intranet.

The Intranet is difficult to maintain and Web Services does not have the resources to read every page on the intranet nor do we have the knowledge to know what content should be there. We have to rely on departments informing us of content changes. Some of the content has not been revised for some time. Therefore we can not be sure of the timeliness or validity of the content. In fact we could be sure that some of the content was out of date. Hopefully the Wiki would help address this.

Our vision
We wanted to supply a system where departments could control and take ownership of the content that they use. Staff could keep content up to date everyone in a department would be able to contribute. Documentation would be better organised and there would be one true source for the information they control. Email size would be reduced as staff would just send links to documents instead of long email or email with documents attached being sent out to everyone.

Our Testing
Most of Web Services had set up or installed Wikis but we did not actively use them prior to the install of Confluence and the creation of the webservices space. During our initial test we found:
• The wiki easy to use
• Easy to add content, attachment and other media
• Easy to keep track of changes
• Search was very good
• Finding pages or content quick
• Structure was easy to control

This let us feel that the Wiki would be easy to implement and roll out across the University.
Spaces where set up for all departments that had an intranet site. We set up some basic training based on our test. The departments where informed about the existence of the Wiki spaces and that training was available. Access was given to the spaces and training was delivered.

Training
We spoke about the Wiki what it is and what to use it for. The training was an overview of all the basics in the Wiki:
• Creation of pages and links
• Editing pages
• Add attachments
• Add images
• Browse pages
• Search
• History

Wiki in Practice
There was an under estimation of the amount of work involved in getting the content imported into the Wiki. Departments had to read over all the content they had in the intranet, copy relevant content, delete duplicated and old content, edit out of date content, create new content and organise in to the correct areas.

The support mostly focused around visual design, we did not anticipate the amount of work involved in the design of the pages.
• Created the homepages for the departments
• Created the section homepages or team home pages
• Sourced images for the homepages from creative commons
• Helped with suggestions of what should be in the Wiki
• Gave one to one support were necessary

Better Approach
There is no ‘right’ way to use a Wiki. The Wiki is not built as such but evolves as content is added by the people who use them. The structure of a Wiki, and how it is used, reflects how the people using it want to structure it and how they use it.

Finding departments that are interested in using a Wiki and individuals willing to get the project started. Identify a good project to implement (Staff Handbook, Manuals and Guides or FAQ (Perhaps a Wiki for induction new starters could go in and leave messages about themselves or about University).

When using a Wiki we need to check to see if everyone understands what it is and that they are open to using it. Using a Wiki and getting acquainted with it can be difficult.

We should change Wiki training so that we still give an overview of what the Wiki is. The group can then discuss which content is to be added then together add the content to the Wiki. People come along expecting to learn how to use the Wiki, they can interact with other users as they work gaining knowledge of how the Wiki works while adding content.

Give everyone in the department edit rights (remember there is a full history of edits in the Wiki and we can always restore previous version if mistakes are made). Also there is an advantage to mistakes being made as this will encourage staff to use the Wiki in order to fix the erorr. < see you would fix that if you could. There are different ways users will get involved with their Wiki: • Consumer: Read the content • Editor: Make edits as they see them • Contributor: Add new content • Maintainer: Organised the content look for and add new features A Wiki works best when it is being used, it's important for the homepage to look fresh. We could have a panel on the homepage that shows a list of pages that have recently been added or edited, or a list of pages which have a particular label. We need to get people visiting the Wiki on a regular basis this can be done by creating content that people like to read, want to read or need to read. At Edge Hill the weekly updates that are currently sent out by email) could be added to the Wiki this would help to get people using the Wiki. We need to develop good templates that are easy to use. Pages that have a nice format will encourage people to enter content knowing it will look good. This would mean getting the templates ready so we where confident each one would work as intended. Also a couple of tweaks to the CSS could format the text better. A Wiki user group would also be good as this would help with passing on information about how the Wiki spaces can be used. The group could also inform us of any issues they have with the Wiki.

Homepage

Posted on December 22, 2009December 25, 2009 by Maurice Savage

A selection of www.edgehill.ac.uk homepage screen shots from the end of 2008 to the beginning of December 2009.

Homepages

View more presentations from MoSavage.

A load of “Gobbledigook” from an online form

Posted on December 12, 2009December 11, 2009 by Maurice Savage

You have Spam!

Web content editors, designers and developers have all worked hard to make their website interesting, attractive and functional.

A lot of time and money is spent promoting the website. People find the website talk about it and link to it from their website, blog, wiki, bulletin board ect.

Search engines then trawl through the internet looking for links and keywords (among other things). The more links the search engine finds the more interesting the target website must be (all these people linking to it, it must be good)

The search engine goes away tots up all the scores. The one with the most incoming links is the winner. They will be at the top of the search engine ranking for that month (Its not really that simple but I think this is basically what the spammers tell their clients).

The Gobbledigook you receive from the form submission always contains links to websites. The spammer is not trying to get you to click the link. Spammer wanted a link published on a website by filling in a form that would update the blog, wiki ect. Spammer is trying to get as many links as possible pointing at the clients website, increasing the site’s search engine ranking. The results can then lead to the site being listed ahead of other sites for certain searches, increasing the number of potential visitors and paying customers.

How is it done?

A computer programme is used this searches for publicly accessible forms. Once a form is found it adds content into all text fields, a non existent email address into the email field and HTML containing a link into the text area field usually comment, content or message field.

All websites that accept content via a form are at risk of receiving spam via their forms.

Solutions

Disallowing multiple consecutive submissions
Spammers often reply to their own comments. Checking that the users IP address is not replying to a user of the same IP address would help reduce the spam flooding our in boxes.
This however proves problematic when multiple users, behind the same proxy, wish to submit the same form which is quite often the case here.

Blocking by keyword
Spammers have to use relevant and readable keywords so the search engines can index them effectively
Spam could be reduced by blocking the keywords they use simply banning names of casino games, popular pharmaceuticals and certain body enhancements.

Drawback the list could be quite extensive and would have to be maintained.

CAPTCHA
Is a method used to display an automatically generated image of a combination of numbers and letters. The user then enters the letters in to a text field to validate the form.
A computer programme can not read the image and the form will not validate.

Drawbacks sometimes difficult to read and the form needs to be refreshed or submitted several times before you get a readable image.
This system can prove difficult or impossible for the visually impaired who rely on screen readers. Providing an audio version of the characters can resolve this.

CSS
Use CSS to hide a text field. A programme will find the field enter data our validation checks the field if it contains data the submit fails.

Drawback if a screen reader is used it will find the form filed and ask for data the form will then fail validation.

Distributed Solutions
Originally developed for use on blogs but now most form data can be submitted to one of the services.
When a user submits a form the content is sent to one of the services. The content is then filtered. The service looks for links and keywords it also compares the content against a database of known spam content already submitted. The content is then given a score and sent back to your server. The server then accepts,flags or rejects the content based on the values you set.
Akismet, Defensio, Mollom are some of the web based distributed services.

Drawback Valid users can be blocked. If a user is wrongly flagged as being a spammer it can be difficult for that user to post data to websites using the same service.