Author Archives: Maurice Savage

Wiki Progress

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.

A load of “Gobbledigook” from an online form

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.